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>

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>

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

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]

Reply via email to