Hi, On Thu, Jun 4, 2015 at 6:50 PM, Xuelei Fan <xuelei....@oracle.com> wrote: > Hm, I see your point now. But I may not agree with your ALPN "MUST > happen after" protocol/cipher suite negotiation conclusion. > > I parse this section as, a H2 server must be strong enough(comply to > RFC7540), and a H2 client must also be strong enough (comply to > RFC7540). Otherwise, both side may terminated the connection, and > cannot declare as complying to H2. It is not necessary for an > application protocol selector to detect whether a H2 server/client > comply to H2 or not. > > If "H2" is requested, it means that the client supports H2. Otherwise, > it's a client application bug.
Not that simple, see below. > If "H2" is selected by a selected, it > means that the selected server supports H2. Otherwise, it is a selector > implementation bug. If something wrong in either client or server, it > is expected to terminate the connection immediately, rather than > downgrade to a not-strong enough level. > > From the points above, I think an application protocol selector may not > need to know the negotiated protocol version and cipher suite. No. The client may send ciphers that are valid for http/1.1 (but invalid for h2), along with ciphers that are good for h2 (as well as http/1.1 of course), plus the list of protocols it supports. The client has no idea what the server supports. When the server sees that the client supports h2, it MUST pick a cipher that is valid for h2. Alternatively, the ciphers on the server are sorted so that those valid for h2 have higher priority (they are attempted before all the others), so that there is a high chance that a h2 valid cipher is chosen (but no guarantee) before choosing the application protocol. When the application protocol selector callback is invoked, it can only pick h2 IFF the cipher is h2 valid, otherwise it has to fallback to http/1.1. With your reasoning, the client can send [h2_invalid_cipher, h2_valid_cipher], the server may pick h2_invalid_cipher, then the application protocol selector is invoked, which will only look at the protocols, pick h2 since it's supported by client and server, and now you have an invalid connection: the h2 protocol with h2_invalid_cipher. We have been through these issues for months in the RFC 7540 expert group, and the outcome is that protocol selection, for h2, depends on the cipher. We have also been through a number of scenarios where both the client and the server send h2 valid ciphers, but their intersection is empty (this may happen when a very old client talks to a very new server, think TLS 1.2 vs TLS 1.4, or viceversa). Same outcome: to pick h2 you MUST have a h2 valid cipher in common between client and server, so application protocol selection, for h2, depends on the cipher. A bit of warning here: we are designing an API for ALPN, not for HTTP/2. The ALPN API should be flexible enough to implement *at least* HTTP/2, possibly even more complex scenarios (for example alias selection), but IMHO it should not be tied to HTTP/2. Again, I see 2 cases: either the JDK implementation picks the TLS protocol, the cipher and the alias like it does now, and then invokes the "callback" to pick the application protocol (current Jetty ALPN behavior), or the implementation must be reviewed to perform TLS protocol, cipher, alias and application protocol selection at once, with a "callback" that will be invoked possibly multiple times until it can find the right tuple to return. The latter would be the optimal solution, the former has certainly working implementations. Hope this clarified. Thanks ! -- 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
