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

Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 5 Sep 2014 16:34:27 -0700
Message-ID: <CABcZeBP6XsJu9MJp959GNDfCQbTonLHYc5ZVv61jvJQDatn0og@mail.gmail.com>
To: Michael Sweet <msweet@apple.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Simone Bordet <simone.bordet@gmail.com>, Patrick McManus <mcmanus@ducksong.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Sep 5, 2014 at 3:35 PM, Michael Sweet <msweet@apple.com> wrote:

> Martin,
>
> Responses inline...
>
> On Sep 5, 2014, at 5:44 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> > ...
> > I can't really do anything about that without overturning a standing
> > decision.  I'm not the chair, but I'm guessing that you'd have to
> > exhibit more than discomfort for that to happen.
>
> RFC 5246 requires a conforming implementation to be able to negotiate
> TLS_RSA_WITH_AES_128_CBC_SHA.  HTTP/2 requires conformance to RFC 5246 but
> forbids negotiation of TLS_RSA_WITH_AES_128_CBC_SHA.  Do you not see the
> problem this creates?
>

This is actually not a conformance problem, since RFC 5246 has an explicit
escape hatch for applications (https://tools.ietf.org/html/rfc5246#section-9
)

   In the absence of an application profile standard specifying
   otherwise, a TLS-compliant application MUST implement the cipher
   suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5
<https://tools.ietf.org/html/rfc5246#appendix-A.5> for the
   definition).


Note: I'm not saying that requiring AEAD is wise or unwise, but merely

that it's not a process problem for HTTP to do so.


-Ekr
Received on Friday, 5 September 2014 23:35:36 UTC

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