TLS ALPN Proposal v3

Simone Bordet simone.bordet at
Sat Jul 25 17:26:41 UTC 2015


On Fri, Jul 24, 2015 at 9:38 PM, Jason Greene <jason.greene at> wrote:
> 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. 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.
> 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.

Had TLS 1.3 been released before H2, we would not need to choose the
cipher suite based on ALPN + TLS version, because any TLS 1.3 cipher
would do, and the support for ALPN would be much simpler (probably
akin to SNI).
The current situation is a temporary glitch produced by the H2
specification, and requires clients and servers to implement hacks to
support H2 (sorting ciphers, etc.).

Another thing to remember is that clients and servers may implement
different ways of selecting the various TLS parameters.
While server have to choose among TLS protocol versions, ciphers,
application protocols, etc., the client can only react to what the
server chose.
For a TLS implementation, it may be simpler to implement a client
(like browsers do) than a server; I think the server algorithm would
work for clients, but not necessarily viceversa.

Tradeoff between A) change radically the OpenJDK implementation to
support an iterative processing of TLS protocols, extensions (all of
them), ciphers, aliases, etc. that would be future proof (if that is
even possible) and B) hack in just enough of what is needed to support
H2 today (for which we already have working examples) ?

Would it be possible to fit the ALPN solution that would have been
implemented if TLS 1.3 was out before HTTP/2 to support the current
situation ?

Simone Bordet
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

More information about the security-dev mailing list