ALPN & HTTP2

[Simone Bordet]

Hi,

below you can find few considerations about the interaction between
HTTP 2.0 (from now onwards just "h2") and ALPN.

The h2 group at the IETF is having a big debate about section 9.2.2 of
draft-14 [0].
This section basically put a very strong requirement on the ciphers
that can be used to talk h2.
However, clients are entitled to offer weak ciphers and strong
ciphers, but only the strong ones can be used to talk h2.
With this, there is a dependency between the ALPN protocol chosen and
cipher selection; note that cipher selection should happen before the
ALPN server lambda invocation (as I proposed in the other email).

The algorihtm proposed by the h2 editors would be that h2 could only
be chosen by the ALPN server lambda IFF:

!cipher.isStream() && !cipher.isBlock() && cipher.supportsForwardSecrecy()

There is a big resistance among the h2 experts to have this algorithm
defined in the h2 spec, for many reasons. However, the h2 editors are
very resistant to changes (I have to say, backed by the TLS editor).
The fact that almost all TLS implementations out there don't have at
least one (or all) of the methods above (so basically the algorithm
above is not implementable) is not seen as a good enough reason to
remove section 9.2.2.

Furthermore, there is not direct correlation, in the TLS handshake,
between ciphers and protocols.
Speaking of the server side that I know better, the case is that I
take Jetty and run it in the shiny just released JDK 9. The TLS
implementation of JDK 9 adds new ciphers, one of which is named XYZ.
Jetty receives a TLS connection request, with cipher XYZ and ALPN
listing h2. The JDK Jetty runs on has XYZ, but Jetty has no idea
whether this cipher is good for h2 or not.
Jetty may pick XYZ and h2, thus succeeding at both cipher negotiation
(both client and server can use that cipher) and at protocol
negotiation (both client and server can speak h2), but when the client
receives the ServerHello, the client may say "oh, no, XYZ is not good
for h2, I offered it for HTTP/1.1", but now it's too late and the only
possible solution is to close the connection, and reopen another one
excluding h2 from the protocols sent to the server (or excluding the
cipher XYZ - but how the client knows if a different cipher will
succeed ?).

Ironically, 9.2.2 may hamper h2 adoption.

Hopefully the h2 group will come to a better decision about section
9.2.2, perhaps without entangling protocol negotiation with cipher
negotiation, but we don't know yet.

In any case, I would suggest that the OpenJDK security-dev leaders
consider to add the capabilities to query a cipher for its properties
to OpenJDK.
There already exist a javax.crypto.Cipher class that perhaps may be
enhanced to expose those methods, along with a way to obtain the
selected Cipher instance from SSLSocket/SSLEngine.

On the same theme, it would not be too far fetched to think that a
server may want to provide h2.domain.com over h2, and h1.domain.com
over HTTP/1.1 for the same certificate *.domain.com.
For this to happen, the server ALPN lambda would need to extract the
SNI extension name, compare it with some virtual host configuration,
and then take a decision about the protocol to speak.
Again, a full fledged TLS Extension API would simplify this:

String sni = SSLEngine.getRemoteExtensions().find(SNIExtension.class).getName();

SNIMatcher won't be able, for example, to match regexp'ed virtual hosts.

In conclusion I'd like to point out the fact that a ALPN API into JDK
9 is a mandatory requisite to implement h2, but may not be sufficient,
since additional methods on Cipher and other TLS classes may be
needed.

Thanks !

[0] http://tools.ietf.org/html/draft-ietf-httpbis-http2-14

-- 
Simone Bordet
http://bordet.blogspot.com
---
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