[e-lang] Fwd: Chat with kpreid at waterpoint.org

[Bill Frantz]

erights at gmail.com (Mark Miller) on Saturday, September 19, 2009 wrote:

>On Thu, Sep 17, 2009 at 10:11 AM, Thomas Leonard
><tal at it-innovation.soton.ac.uk> wrote:
>> One thing that is slightly bothering me is that it doesn't seem to use
>> SSL/TLS. I found this page:
>>
>> http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html
>>
>> but it is dated 1998. I think I will have a hard time trying to convince
>> people that E's custom system is secure / will be updated if problems
>> are found. It would make my life easier if I could just say it uses the
>> Java SSL libraries for transport layer security.
>
>...
>
>* Switching from our custom DataComm to a VatTP layered on top of TLS.

I think the attributes we want to preserve from the existing VatTP are:

   Perfect forward security - Symmetric encryption and MAC keys exist only
   for the duration of the connection. They can not be recovered after the
   endpoints have removed them from memory.

   Distributed public key authentication - The sturdy-refs held by a vat
   contain enough information to authentic the public key sent by the
   remote vat.

   The system uses only known-secure algorithms, modes, and protocols.


When I wrote the web page Thomas referenced above, there was confusion in
my mind between supporting SSL/TLS and using SSL/TLS. In our case, we want
to use SSL/TLS, and do not need to worry about any of the many CipherSuites
(for example TLS_NULL_WITH_NULL_NULL), which are not applicable to our
use. The CipherSuites (from RFC 4346 and RFC 3268) which seem most
applicable to VatTP are:

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA - This CipherSuite uses the same
algorithms as the current VatTP. All are somewhat dated.

TLS_DH_DSS_WITH_AES_128_CBC_SHA and TLS_DH_DSS_WITH_AES_256_CBC_SHA - These
update 3DES to the spiffy new AES.


When two vats connect, they exchange public keys. The vats check the public
key they receive against the SHA1 hash in any sturdy refs to be used,
providing assurance that the remote vat is indeed the correct vat. This
procedure is quite different from the certificate authority procedure used
by standard SSL/TLS. It is not clear that all SSL/TLS libraries will have
the user-exits to support this form of authentication. It may be necessary
to adopt an new approach to provide distributed public key authentication.


Note on the crypto algorithms:

3DES is old and well tested. It's 64 bit block size can cause some
weaknesses when large quantities of data are transmitted, so connections
should be re-keyed periodically. (I can't remember how much data it takes
to become exposed to this weakness, but I'm fairly sure it is greater than
2**32 bits.)

DSS - The largest DSS key is 1024 bits, but there are obvious extensions to
longer keys. RSA and ECDSS are other algorithms of interest for Vat public
keys. 1024 bits in both DSS and RSA is getting a bit short for the very
paranoid. Since the hash of the public key is the VatID, changing to a
different public key while maintaining vat identity is an unsolved problem.
Life in the crypto protocol world would be nicer if we didn't have to solve
this problem, perhaps by allowing sturdy-ref replacement in running
distributed applications.

AES - Recent work has shown that AES256 is only a bit stronger than AES128,
so it probably isn't worth supporting AES128 unless it just falls out of
all the libraries we use. Since the symmetric crypto algorithm is chosen at
connection establishment time, we can easily adopt new algorithms as they
become available and refuse old ones as they become broken.

SHA1 - Attacks against SHA1 have been getting better and better at an
impressive rate. NIST is currently involved in a process to select a new
secure hash algorithm. Most observers think SHA1 should last until that
process finishes. For people who want more security than SHA1 now, the
recommendation is to use SHA256. SHA256 shares may of the design approaches
as SHA1, so attacks on SHA1 may generalize to SHA256, but the extra bits
will probably greatly expand the number of computer cycles required to
actually mount an attack.

SHA1 is used to calculate the VatID, so adopting a new secure hash
algorithm is as much of a pain as changing the public key of the vat. Also,
any new secure hash algorithm is likely to have a different length output
than SHA1's 160 bits.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"After all, if the conventional wisdom was working, the
408-356-8506       | rate of systems being compromised would be going down,
www.periwinkle.com | wouldn't it?" -- Marcus Ranum