W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Discussion of 9.2.2

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 26 Sep 2014 08:09:19 -0700
Message-ID: <CABcZeBPUihY6-i7EEhWq35=RNA--ZHMqnjkJQnO+_OZkfwoPdQ@mail.gmail.com>
To: Jason Greene <jason.greene@redhat.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Michael Sweet <msweet@apple.com>
On Fri, Sep 26, 2014 at 7:55 AM, Jason Greene <jason.greene@redhat.com>
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 <msweet@apple.com> 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 <martin.thomson@gmail.com>
> wrote:
> >>
> >> On 24 September 2014 12:17, Mark Nottingham <mnot@mnot.net> 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
>
>
Received on Friday, 26 September 2014 15:10:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC