Dutch Transport Card Broken

James A. Donald jamesd at echeque.com
Fri Feb 1 03:24:25 EST 2008


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 at metzdowd.com



More information about the cryptography mailing list