Re: [TLS] Encrypting ALPN and other unused extensions

[Watson Ladd <[e-mail]>]

On Sat, Apr 26, 2014 at 12:37 AM, Michael D'Errico <[e-mail]> wrote:
> Watson Ladd wrote:
>>
>> On Fri, Apr 25, 2014 at 11:20 AM, Gero, Charlie <[e-mail]> wrote:
>>>
>>> SNI and ALPN can be used to alter the path the rest of the handshake
>>> takes (and for many hosts, will be the case).
>>
>>
>> For SNI this is true. But ALPN? Remember it was introduced to handle
>> HTTP 2.0 vs HTTP 1.0: I don't see people rushing out to use different
>> certs per protocol.
>
>
> It's a bit premature to inter ALPN when it hasn't yet been published as
> an RFC.  Why don't you like it?

"Like it"? The question is whether or not the flexibility gained from
letting the server pick its certificate in response to ALPN is worth
the cost in protocol complexity. The usecases I've seen do not involve
doing this. Remember I'm not proposing removing ALPN: I'm proposing
changing the flow to work better with 1-RTT TLS and HTTP.

Is there a cost in protocol complexity in supporting this usage? Yes.
We haven't figured out a good way to encrypt SNI for much the same
reason: how do you know what key to use to encrypt and decrypt data
that will tell you which key to use. If we want 1-RTT to require
foreknowledge of a key, this solves that problem partially, but at the
cost of complicating the implementations that want to take advantage
of 1-RTT.

Sincerely,
Watson Ladd