Re: Discussion of 9.2.2

[Jason Greene <[e-mail]>]

On Sep 26, 2014, at 10: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

I saw that one, but it does not seem to allow me to say aead or anything stronger. Code written against this API would fail with aero for example. So we would need an AEAD+ like construct.  Today this is ok because AEAD is the latest. However, if a few months from now NSS adds it, the application will not be able to use it without a code update.

> 
> 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).


Here are the requirements we have assembled:

1. A TLS 1.2 connection without an ALPN for HTTP/2 can use any cipher allowed by TLS 1.2 that has not been blacklisted as a vulnerability
2. A TLS 1.2 connection with an ALPN for HTTP/2 can only use the subset of TLS 1.2 that 9.2.2 allows.
3. A TLS 1.3 (and later) connection can negotiate any cipher allowed by the spec

Further we have the existing common industry practice of separation of concerns, that an administrator can pick up new ciphers (and TLS versions), by simply updating a common TLS library on the system which is shared between application protocols (e.g. http stacks). While browsers have traditionally hard coded cipher suites, servers and other non-browser clients typically leave this to the TLS stack.

Do we agree on at least this? If so, how is an API I describe not necessary to meet all of this? Is there another way I have missed?

> 
> -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
> 
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat