Victor Duchovni wrote:
Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds round-trips to SSL warrants some evidence (it is very temping to express this skepticism more bluntly).With unextended SMTP for example, the minimum RTT count is: 0. SYN SYN-ACK 1. ACK 220 2. HELO 250 3. MAIL 250 4. RCPT 250 ... n recipients RCPT 250 4+n DATA 354 5+n ... stream of message content segments <CRLF.CRLF> 250 so it takes at least 6 RTTs to perform a delivery (of a short single-recipient message), but only 1 of the 6 RTTs is TCP "overhead". This is improved with PIPELINING: 0. SYN SYN-ACK 1. ACK 220 2. EHLO 250 ... PIPELINING ... 3. MAIL RCPT(n times) DATA 250 250 (n times) 354 4. ... stream of message content segments <CRLF.CRLF> 250 Here the application protocol is pipelined, and 5+n RTTs becomes 4 RTTs. The solution is not replacing TCP, but reducing the number of lock-step interactions in the application protocol. If someone has a faster than 3-way handshake connection establishment protocol that SSL could leverage instead of TCP, please explain the design.
You are asking for a layered design that works better than the existing layered design. My claim is that you get an additional round trip for each layer - which your examples have just demonstrated.
SSL has to be on top of a reliable transport layer, hence has to have an extra round trip. I was not proposing something better *for* SSL, I was proposing something better *instead* *of* SSL. If one takes SSL as a given, then indeed, *three* round trips are needed before the client can send any actual data - which is precisely my objection to SSL.
The TCP handshake adds a 1-RTT delay at the start of the connection. What 0-RTT algorithm will allow the server to delay creating expensive connections to clients until the client acks the server response or discover the MSS before sending the first segment? With TCP, at least SYN floods require unspoofed client IPs. Most of the application protocols we wrap in TLS are not DNS. Sure if you can guarantee a single packet response to a single packet request, TCP is not the answer. Otherwise, claiming that SSL is less efficient over TCP smacks of arrogance.
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
