TLS ALPN Proposal

Simone Bordet simone.bordet at
Mon May 25 14:09:23 UTC 2015


On Mon, May 25, 2015 at 3:57 PM, Michael McMahon
<michael.x.mcmahon at> wrote:
> Perhaps, though it seems there are specific ALPNs for HTTP/1.1 ("http/1.1")
> and for HTTP/2 ("h2"). So, I think you would use ALPN itself to do that
> negotiation.
> An incoming TLS connection without the ALPN extension is just assumed to be
> HTTP/1.1

Sure, but I can see a client looping over a list of domain names (e.g.
to check whether the sites support HTTP/2) and therefore not having
any knowledge of whether it should or not add the ALPN extension.
This client will always add it, but the server must force http/1.1 for

> There aren't very many different "applications" envisaged yet. There are
> a couple of NAT related protocols registered. But, actually having thought
> about it
> again, client certificate selection happens in the X509ExtendedKeyManager
> class
> and that implementation could presumably call
> sslEngine.getHandshakeSession().getApplicationProtocol()
> and select the client cert using that information. It doesn't do that now
> obviously
> but I think it could in future if necessary.

Sure, unless the protocol is not available because ALPN code has not run yet.
For what I understand, currently cipher selection and certificate
selection happen at the same time, please correct me if I am wrong.

If that's the case, then we have a chicken-egg problem: you can't call
ALPN code before the cipher is selected, but you need ALPN to select
the certificate.
If those two steps can be split, then ALPN code could be put in
between and all is solved.

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