TLS ALPN Proposal v3

[Bernd Eckenfels]

Am Fri, 24 Jul 2015 14:38:36 -0500
schrieb Jason Greene <jason.greene at redhat.com>:
> The truth is that there is a gap between the current capabilities of
> TLS stacks and what the specs are trying to achieve. Ultimately the
> desired semantic the specs are trying to achieve is that every ALPN
> protocol can have its own TLS requirements.

Not sure if this is desireable, it was I guess the motivation, but see
below:

> In this case H2 wanted
> TLS 1.3 behavior before it was released. This is basically social
> engineering, the newer protocol is the carrot for updating your TLS
> stack. However there are other potential scenarios, such as protocols
> which desire to be encrypted but unauthenticated.

I think it is fine to define a minimum security level together with an
application protocol. If the protocol is supported the TLS stack needs
to provide the desired features, and given the fact that it will
negotiate the "best" protocol version you can just deny H2 if the
cipher is not good enough.

However:

> To truly resolve this gap in a future proof manner, TLS stacks need
> to support cipher suite selection based on the combination of ALPN
> protocol and TLS version.

If each ALPN can select different security parameters, this would be a
configuration and interop nightmare. Dont go that route. I would not
provide any features to enable it, nor require them. Having said that
H2 should really be less demanding.

(not sure whats the best place to discuss it, not part of the H2 group).

Gruss
Bernd