Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > There is a description of doing an SSL transaction in single round > trip. The browser contacts the domain name system and gets back in > single transmission the 1) public key, 2) preferred server SSL > parameters, 3) ip-address. The browser selects the SSL parameters, > generates a random secret key, encrypts the HTTP request with the > random secret key, encrypts the random secret key with the public key > ... and sends off the whole thing in a single transmission > .... eliminating all of the SSL protocol back&forth setup chatter. You still need a round trip in order to prevent replay attacks. The fastest that things can be while still preserving the security properties of TLS is:
ClientHello -> ClientKeyExchange -> Finished -> <- ServerHello <- Finished Data -> See Boneh and Schacham's "Fast-Track SSL" paper in Proc.ISOC NDSS 2002 for a description of a scheme where the client caches the server's parameters for future use, which is essentially isomorphic to having the keys in the DNS as far as the SSL portion goes. In any case, the optimization you describe provides almost no performance improvement for the server because the load on the server derives almost entirely from the cryptography, not from transmitting the ServerHello [0]. What it does is provide reduced latency, but this is only of interest to the client, not the server, and really only matters on very constrained links. -Ekr [0] With the exception of the ephemeral modes, but they're simply impossible in the scheme you describe. -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]