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

On Fri, Sep 5, 2014 at 3:35 PM, Michael Sweet <msweet@apple.com> wrote:
> 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?

On Fri, Sep 5, 2014 at 4:02 PM, Michael Sweet <msweet@apple.com> wrote:
> Brian Smith wrote:
>> It was a mistake for the TLS 1.2 specification to say
>> TLS_RSA_WITH_AES_128_CBC_SHA is mandatory-to-implement at all, for the
>> reason that you and I both gave. But, that is in the past. And, note
>> that the TLS 1.2 specification allows an application profile of TLS to
>> override that requirement.
>
> I must have missed that - everything I see in there says it is unconditionally required in order for TLS/1.2 implementations to interoperate.

http://tools.ietf.org/html/rfc5246#section-9 says:

   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 for the
   definition).

The HTTP/2 draft is defining an "application profile standard
specifying otherwise," so an application profile standard isn't
absent, so there is no requirement that TLS_RSA_WITH_AES_128_CBC_SHA
be implemented for HTTP/2. In other words, the TLS specification was
written specifically to allow the type of thing that the HTTP/2 draft
is doing.

Also, logically, we seem to agree that it is a bad idea to specify
specific cipher suites as mandatory-to-implement, so I don't think we
should worry too much about requirements in specifications that have
made that mistake. Instead, let's just not make that mistake any more.

Cheers,
Brian

Received on Friday, 5 September 2014 23:16:28 UTC