Re: [tcpm] Faster application handshakes with SYN/ACK payloads

On Tue, Jul 15, 2008 at 1:52 PM, Joe Touch <touch@isi.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Data could *always* come in the SYN/ACK (i.e., in a SYN), but often it's
> just ignored. So this option is just a hint to the server that the
> client won't ignore that data. It doesn't change any rules about data
> delivery; once the SYN/ACK arrives, the client can send that data up to
> the user as per conventional rules, AFAICT.

Although I've not tested it, I suspect that you're correct here. I
should reword that section of the draft.

> I'm really not sure what buying a single RTT will do for TCP, though.
> Very few exchanges that need reliable transfer of a single packet need
> TCP, IMO.

Although it could be used for single packet exchanges from the server,
I would be surprised if any one did. My expectation is that protocols
would use it to shave a RTT from the TCP connection setup latency. My
personal motivation for this draft is hinted at in section 2:

"This also allows existing protocols to be extended with encryption
with no additional round trips and with transparent fallback."

Consider a web browser which sets the SYNACK permitted bit and a web
server which includes an elliptic-curve Diffie Hellman key in it's
static SYNACK payload. When connecting to a normal webserver, the
browser will see that no SYNACK payload was received and carry on as
normal. But for augmented webservers, the browser calculate a shared
key and include its own ECDH key just before the HTTP "GET" request,
carried in the final ACK of the 3-way. Thus we have opportunistic
encryption and no additional latency in either case.

(Also, that's not just idle speculation: the firefox build that I'm
writing this email in is such a web browser and the lighttpd I have
running at home is such a web server.)

Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm