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
