- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 5 Sep 2014 14:44:57 -0700
- To: Michael Sweet <msweet@apple.com>
- Cc: Simone Bordet <simone.bordet@gmail.com>, Patrick McManus <mcmanus@ducksong.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
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