Am Fri, 24 Jul 2015 14:38:36 -0500 schrieb Jason Greene <jason.gre...@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
