[114419] in cryptography@c2.net mail archive
Re: Dutch Transport Card Broken
daemon@ATHENA.MIT.EDU (James A. Donald)
Fri Feb 1 09:21:09 2008
Date: Fri, 01 Feb 2008 18:24:25 +1000
From: "James A. Donald" <jamesd@echeque.com>
To: 'Cryptography' <cryptography@metzdowd.com>
In-Reply-To: <20080130194746.GY17469@np305c2n2.ms.com>
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 majordomo@metzdowd.com
