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

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

On Wed, Aug 13, 2008 at 10:27 AM, Eric Rescorla
<[e-mail]> wrote:
> S 4. Opportunistic HTTP Encryption
>
> As I understand this mechanism, what's being proposed is this:
[snip]
> Do I have that right?

Yep,

> 1. The PPExt payload is overloaded here. First, it's signalling
>   a transport message "it's OK to put stuff in the SYN/ACK". Second,
>   it's signalling an application layer message "It's OK to send me
>   a crypto handshake as the first thing you send." Note that in
>   an ordinary HTTP connection, this data would be invalid.

Actually, it's only signaling the application extension. The SYNACK
payloads are valid in any TCP connection, although this spec does make
some guarantees about weather the stacks will process them.

>   This overloading seems fairly unwise, since it would preclude
>   any other use of this SYN/ACK payload in the future.

The format of the SYNACK payload for this scheme is similar to the
option space: i.e. it's a tagged, extensible payload.

> 2. It's not clear to me that opportunistic security for HTTP is that
>   great. Unlike, for instance, SMTP, HTTP fetches are nearly always
>   the result of some URI, so it's very easy to simply indicate
>   in the URI that the server supports HTTPS. This is superior
>   from a security perspective for the usual reasons (referential
>   integrity, etc...)

I believe that there's a use for a low-cost cryptographic scheme, such
as this. Despite widespread TLS deployment, most traffic is still in
the clear, including semi-sensitive information. I would rather that
traffic be protected with TLS but, since that isn't happening, I would
rather this than nothing.

Opinions on this vary. Some folks think it's a great idea (including
some working on implementing the TLS Fast-Track you cite below), some,
like you are unimpressed. Fundamentally, I'm only asking for an option
number to try it out.

> 4. Some of the latency benefit you're getting here is from not
>   negotiating the crypto algorithms; this is why in TLS the
>   client speaks first. This isn't an issue for the symmetric
>   algorithm since the server could provide a list, but it's
>   a real issue for the asymmetric algorithm, since it provides
>   no agility in the case of upgrade or compromise. If, for
>   instance, someone successfully attacks this curve but there
>   are other, strong curves available, then we'd be hosed.

Firstly, this isn't rigorous crypto, so the primitives here are in the
enviable situation of being good enough if it's infeasible to break
them in near-real time. If you want real security, use TLS.

As mentioned above, the SYNACK payload is a tagged structure. Since
there are very tight space constraints it probably wouldn't be
possible to offer several elliptic curve points, but if curve25519
were totally broken there is a gradual upgrade path by upgrading
clients and then switching servers to offer another tag with a
different curve. Older clients would fall back to no encryption, but
it doesn't require a flag day.

> It's true that SSH latency is really bad, but it's really much
> worse than you suggest, since the authentication handshake takes
> several exchanges as well. [GutXX] It's not clear to me that removing
> 1 RTT helps here. I'm skeptical that there are really that
> many applications that involve bringing up and tearing down
> a lot of SSH connections.

You're correct. This isn't the greatest example, I was just looking
for some diversity to suggest that this isn't limited to HTTP.

> S 6. Compressed HTTP Headers
> I don't know how much value this adds, but note that the server's
> indication that it supports compressed headers lives in the same
> section of the datastream as the crypto stuff from S 5. So, we
> now need some sort of framing mechanism for this data to allow
> clients which know about opportunistic crypto but not compressed
> headers to ignore that advertisement.

Yep. Again, the framing mechanism already exists, although it's not
specified in the draft because it's not in scope for a TCPM draft.

The framing mechanism also allows for any other crazy HTTP (or any
other "client transmits first") protocol extensions in the future. I
think that, even if you don't much care for the opportunistic
encryption, that's fairly powerful.


Cheers


AGL

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