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

On Fri, Sep 5, 2014 at 1:35 PM, Michael Sweet <msweet@apple.com> wrote:
> After reviewing the issues I am still uncomfortable with having a list of proposed TLS 1.3 standard cipher suites and feature restrictions made required in the HTTP/2 specification.  These choices haven't even gone through TLS WGLC, and judging from the amount of discussion on the TLS list I would not want to make any decisions based on what may or may not be in TLS 1.3.

Michael,

I agree with you about one thing: It is a mistake to mention that
specific cipher suites must be implemented, because, like you noted in
your previous message, such requirements tend to be made obsolete
faster than the rest of the protocol is. I had previously argued that
here: http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1268.html

> The prohibition for compression probably only belongs in the Security Considerations.  I notice that compression is already a SHOULD NOT in the current version of TLS-BCP, and I think it is OK to make it a MUST NOT and cite the BREACH attacks.

I think it is better to put all the TLS requirements in one place. I
think it is good to mention *why* TLS compression is prohibited in the
security considerations, but the statement that it is prohibited is
best left where it is, to reduce the chances of it being overlooked.
Note that BREACH is one issue, but the overall problem that is being
avoided is more general than BREACH.

> The prohibition for renegotiation needs to be considered carefully - this is an area of intense discussion in the TLS WG and I expect there will be some form of renegotiation/rekeying in TLS 1.3 to address long-lived connections (at least).  You *could* prohibit renegotiation to obtain client credentials, but even then I would make it a SHOULD NOT and cite interoperability and potential security concerns, and any SHOULD NOT/MUST NOT for security reasons belongs in section 10 (security considerations)...

Renegotiation doesn't compose properly with HTTP/2 connection
coalescing, and that's why it is prohibited in HTTP/2. I think the
decision made was a reasonable trade-off and I don't think it is good
to revisit it now. It does mean that if your server requires
renegotiation and you can't get rid of that requirement, then HTTP/2
cannot be used by your server. But, I think everybody (Martin in
particular) is trying to get that resolved in a timely fashion so that
there are solutions available not long after the initial HTTP/2 spec
is finished.

> I am VERY uncomfortable with Section 9.2.2 as currently written.  Basically it makes it impossible to use a TLS/1.2 [RFC5246] implementation since you are prohibiting the only required TLS/1.2 cipher suite (TLS_RSA_WITH_AES_128_CBC_SHA).  I would be much more comfortable requiring base TLS/1.2 (TLS_RSA_WITH_AES_128_CBC_SHA) and recommending the rest.

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.

Although I disagree with mandating any particular cipher suite, the
more general HTTP/2 requirement that a forward-secret cipher suite be
used is appropriate.

> Finally, there is nothing in section 10 about the TLS-BCP recommendations; in addition to the two prohibitions from section 9.2.1, you could throw in the "MUST NOT negotiate RC4" and highlight other important stuff concerning TLS and HTTPS.

It is likely HTTP/2 will get finished before TLS-BCP is finished.
Let's not create process problems by trying to cite the TLS-BCP
document. Also, IIUC, the TLS-BCP RFC can update the HTTP/2 RFC to
improve it after HTTP/2 is published, if there ends up being some
unforeseen conflict.

Cheers,
Brian

Received on Friday, 5 September 2014 22:30:23 UTC