Re: [tcpm] SYN/ACK Payloads, draft 01

["Adam Langley" <[e-mail]>]

On Wed, Aug 13, 2008 at 11:16 AM, Eric Rescorla
<[e-mail]> wrote:
> I'm srory, I don't understand what you're saying here. Does this
> data appear to the application to be part of the data stream
> or not?

Yes, the data is part of the application stream. However, including a
payload in the SYN/ACK frame is permitted by TCP. Thus application
protocols in which the server speaks first could include payloads in
the SYN/ACK today, with no changes. Admittedly many stacks will only
ACK the SYN flag and not the data, so the data has to be
retransmitted, but the changes needed don't need any standard work.

The option proposed here is just for "client speaks first" to escape
that mode and switch to a "server speaks first" mode.

> OK, this wasn't entirely clear from reading the draft.

I didn't include it in the draft because it seemed out of scope, but
maybe I should since attentive readers are obviously picking up on it.

> But the premise of this scheme is that people don't do TLS
> because of either (1) latency or (2) lack of opportunistic
> negotiation. As far as I can tell, neither is correct. Rather,
> it's concerns about server performance. And server performance
> can be improved by a number of mechanisms within TLS that
> are (1) backward compatible with TLS and (2) don't require
> modifying the kernel.

(1) is certainly a concern today. Even a single round trip. Most
actual numbers on this are considered secrets by the organisations in
a good place to gather them, but here's one soundbite:

"every 100ms of latency costs Amazon 1% of profit"
http://radar.oreilly.com/2008/08/radar-theme-web-ops.html

(2) is also a concern: simply put, users type http by habit.
Additionally, getting TLS certificates is a pain for small sites. As
for server load, curve25519 can be performed in 240us on a Core2 and
Salsa20/8 runs at 2 cycles/byte (same hardware). That reduces server
load.

But, really, I don't really know the reasons why TLS isn't ubiquitous
even with ubiquitous support. But, given that it isn't, I'm looking to
the best that I can with a very low-cost (i.e. computation, latency)
system.

I should also add another point of the opportunistic encryption scheme
that isn't covered in the draft:

When in effect, servers may return an X-ObsTCP: header that specifies
an https URL to a document that contains a list of Diffie-Hellman
public values and validity time periods for each. (The hostname is
required to match.) It's hoped that client's can cache it and validate
keys in the future. (Credit to Markus Gutschke from the Google
security team for that.

However, as you point out, there's another route here: additional TLS.
One of the tags that I have penciled in for the SYNACK payloads is
"TLS upgrade" - e.g. the server can advertise TLS support without a
round trip. With client-side context caching, that can be setup with
only one extra RTT in the optimal case (2 otherwise I believe).

The reason that I didn't include that as an explicit example is
because it can be downgrade attacked (obviously) and so, it might
actually be counter productive because it wouldn't teach users to type
"https".

However, if you have ideas for a zero RTT TLS, please send them my way
(possibly off list in that case). If there's a possibility to use
something standard(ish) with no additional latency I'll use it.

> That said, if you're willing to burn even very small amounts
> of data in the SYN, you can do something TLS-compatible by
> passing a compressed ClientHello of some kind + FastTrack.
> This only works with static RSA one the server side, but
> so does the scheme you propose.

I can reasonably fit 14 bytes in a SYN frame. I did consider trying to
get RSA in the SYN (because then the computation costs could be mostly
put on the server), but I don't think I can fit anything useful in
there. (Not even a good elliptic key).



AGL

-- 
Adam Langley [e-mail] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm