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

Let me try to break it up in response.

On 5 September 2014 13:35, 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.

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.

For some of what you are requesting here, some of that also requires
revisiting old decisions. You can find a lot of the records of
discussion and conclusions in the mailing list archives, or the closed
github issues if you need to reacquaint yourself with the particulars.

> For section 9.2.1, the requirement for SNI makes sense, although it seems strange to put the core requirement on the TLS implementation; maybe:
>
>    HTTP/2 implementations that support TLS MUST also support the Server Name
>    Indication (SNI) [TLS-EXT] extension to TLS.  HTTP/2 clients MUST indicate
>    the target domain name when negotiating TLS.
>
>    (you might change "indicate" to "specify" here, but that's purely editorial)

So you want to make this conditional?  Is that all?  Since this is a
section dedicated to TLS usage, I don't much see the benefit there.
The first sentence in 9.2 establishes conditionality.

> 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.  Maybe provide a forward reference to section 10.6 at the beginning of 9.2.1 for all of the security-related feature prohibitions?

I don't believe in concentrating all the security considerations in
the security consideration section, but a pointer makes sense (I see
we have none).

> The prohibition for renegotiation needs to be considered carefully

It was.  We've spent a lot of cycles on this issue since Brian first
raised the concern before the Zurich meeting.

We're not getting renegotiation in TLS 1.3, unless someone finds a
reason to overturn the consensus in the TLS WG (yes, it's not
unanimity).  There *might* be rekeying, and there *might* be some form
of spontaneous client authentication (the former seems more likely),
but there won't be the same generic renegotiation that TLS 1.2
provides.

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

The suite we require is not especially new, and all the
implementations I'm aware of support it.  Impossible is definitely too
strong a word.

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

See above regarding the concentration of security considerations.  We
already suggest that the BCP is worth referencing, but we decided not
to wait for its completion.

> Last (editorial) issue: there are lots of TLS-foo references that really should be RFCnnnn references...

Those are just the symbolic reference labels.  Labels that were
purposefully selected.

Received on Friday, 5 September 2014 21:45:25 UTC