Re: Intra-host CapTP (was E language over I2P)

On Fri, Feb 29, 2008 at 11:32:08AM -0500, Kevin Reid wrote:

> We will indeed need to authenticate the vat on the other end of the  
> socket (otherwise a malicious third vat could perform an introduction  
> which invalidates our mapping of VatIDs to connections); if TLS  
> supports requesting a null cipher then that might be a good way of  
> doing so.

Standard TLS includes three ciphersuites

RSA_WITH_NULL_MD5
RSA_WITH_NULL_SHA
RSA_WITH_NULL_SHA256 (in TLS 1.2)

Which perform key exchange (and potentially mutual authentication,
&c), along with message authentication with HMAC but without any
encryption.

This does have some unfortunate limitations in that, for example, you
can't use DSA certs, or empheral Diffie-Hellman (which would provide
perfect forward secrecy on the MAC keys - though that doesn't seem
like it would matter too much anyway given that recovering a MAC key
for an old session doesn't buy an attacker anything); TLS ties
together the key exchange/auth mechanism, the cipher, and the MAC into
a single value called the ciphersuite, and only the static RSA ones
above provide the NULL (no-op) cipher.

I'd say making the distinction between localhost and not isn't a good
tradeoff here regardless: in return for saving a few cycles (AES is
pretty darn fast), you leave open the possibility that a vat could be
tricked into not using encryption when it should. For instance,
consider two malicious proxies that are on two different machines,
that proxy for (and record the conversation between) a vat on another
machine:

Machine 1                                   Machine 2

  Vat 1                                       Vat 2
   ^                                            ^
   | (local domain socket)                      | (domain socket)
   v                                            v
  Proxy 1   <-------------- TCP -----------> Proxy 2

Since the TLS key exchange is still secure (perhaps at least; making
the kex secure against MITM attacks is a different issue) and the
messages are MACed, the proxies cannot modify the conversation but
they can observe it (which would seem to be enough to cause
substantial damage in many cases). Each vat think it is talking
to another vat on it's local machine, so it thinks NONE is safe
to use when it's actually not.

I don't know the details of the vat communication protocol, so that
particular method might not work at all, but in general it seems like
this is creating complexity in return for very little gain. (There's
my $.02)

-Jack