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.
Sorry, there were two pieces being discussed.
The part about SSL being a burden/load on servers ....
and the shorten SSL description taken from another discussion. The shorten SSL description was (in fact) from a discussion of the round-trips and latency ... not particularly burden on the server. In the original discussion there was mention about HTTP requires TCP setup/teardown which is minimum seven packet exchange .... and any HTTPS chatter is in addition to that. VMTP, from rfc1045 is minimum five packet exchange, and XTP is minimum three packet exchange. A cached/dns SSL is still minimum seven packet exchange done over TCP (although XTP would reduce that to three packet exchange).
So what kind of replay attack is there. Looking at purely e-commerce ... there is no client authentication. Also, since the client always chooses a new, random key .... there is no replay attack on the client ... since the client always sends something new (random key) every time. That just leaves replay attacks on the server (repeatedly sending the same encrypted data).
As follow-up to doing the original e-commerce stuff ... we then went on to look at existing vulnerabilities and solutions .... and (at least) the payment system has other methods already in place with regard to getting duplicate transaction .... aka standards body for all payments (credit, debit, stored-value, etc) in all (electronic) environments (internet, point-of-sale, self-serve, face-to-face, etc), X9.59
http://www.garlic.com/~lynn/index.html#x959 (standard)
http://www.garlic.com/~lynn/index.html#aadsnacha (debit/atm network pilot)
Replay for simple information retrieval isn't particularly serious except as DOS .... but serious DOS can be done whether flooding is done with encrypted packets or non-encrypted packets. Another replay attack is transaction based ... where each transaction represents something like performing real world transaction (send a shirt and debit account). If it actually involves payment ... the payment infrastructure has provisions in place to handle repeat/replay and will reject. So primarily what is left .... are simple transaction oriented infrastructures that don't have their own mechanism for detecting replay/repeats and are relying on SSL.
I would also contend that this is significantly smaller exposure than self-signed certificates.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
