Re: Discussion of 9.2.2

[Michael Sweet <[e-mail]>]

Eric,

If you have a multi-protocol client that opportunistically uses HTTP/2 (which will likely be the case for a very long time for any web browser at least), then you can't simply require TLS/1.2 or omit non-HTTP/2 cipher suites from negotiation because that will cause existing HTTP/1.1 (and SPDY) servers to stop working if they don't support the specific TLS/1.2 ciphers or cannot negotiate TLS/1.2 at all.

So that leaves clients in the position of asking for h2 without HTTP/2 specific ciphers and then verifying the cipher suite and protocol version (>= TLS/1.2) are good after the session is established.

On the server side you are in a similar situation - if you are unable to influence the negotiation of cipher suites based on ALPN protocol (and I know I can't with any of the libraries I use, and only a few have a notion of preferred ciphers that might help in general) then you have to add "oops" code that tells the client to go away after the session is established with an unsupported cipher suite or protocol version.

We can't simply look at this as a "negotiating HTTP/2 over TLS" problem.  HTTP/2 has to interoperate with the existing web.


> On Sep 26, 2014, at 8:09 AM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> On Fri, Sep 26, 2014 at 7:55 AM, Jason Greene <[e-mail]> wrote:
> Has there been any discussion and buy-in with the major TLS implementers (OpenSSL, LibreSSL, Microsoft, NSS, etc) about the need to provide a characteristic-based priority and introspection API that also allows for different policies per TLS version?
> 
> According to Michaels investigation it looks like all of them fall short of this.
> 
> As I indicated previously, NSS provides the necessary introspection API.
> 
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2296.html
> 
> You don't need a priority API to correctly implement these requirements, nor
> do you need one that provides differential requirements for different TLS
> versions (other than the ones that are encoded in the TLS specifications
> and implemented by the library).
> 
> -Ekr
> 
>  
> At a minimum we should at least have a commitment that a complete solution meeting the needs of future ciphers, legacy compatibility, and the rules of 9.2.2 will even be possible. While this still falls short of “working code”, there is at least a chance that it can be implemented without breaking standard industry usage patterns.
> 
> On Sep 26, 2014, at 7:17 AM, Michael Sweet <[e-mail]> wrote:
> 
> > I think the lead-in paragraph (everything below only applies to TLS 1.2) is confusing when the first item after it then says "this isn't just limited to TLS 1.2".  Since all of the others are now explicitly TLS 1.2 requirements you can probably drop that lead-in paragraph to avoid the confusion...
> >
> > And FWIW I still have no interoperable way to implement these restrictions in a client or server that supports both HTTP/1.1 and HTTP/2 with the current TLS libraries, so I'll have to use the sub-optimal negotiate-and-then-give-up-forcing-a-new-connection approach if I want to enforce the 9.2.2 cipher suite and minimum TLS version requirements.
> >
> >> On Sep 26, 2014, at 1:08 AM, Martin Thomson <[e-mail]> wrote:
> >>
> >> On 24 September 2014 12:17, Mark Nottingham <[e-mail]> wrote:
> >>> <http://http2.github.io/http2-spec/#rfc.section.9.2.2>
> >>
> >> I've updated my pull request on this subject.  There are a few
> >> editorial changes in the mix, but the commit log shows exactly what
> >> changes are involved:
> >>
> >> https://github.com/http2/http2-spec/pull/615
> >>
> >> I believe that these changes resolve the issues people have raised.
> >> That is, other than the one which states we shouldn't have this
> >> section at all.
> >>
> >
> > _________________________________________________________
> > Michael Sweet, Senior Printing System Engineer, PWG Chair
> >
> >
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair