- From: Brian Smith <brian@briansmith.org>
- Date: Sat, 19 Jul 2014 21:01:30 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Yoav Nir <ynir.ietf@gmail.com>
On Sat, Jul 19, 2014 at 7:28 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On Jul 19, 2014 3:33 PM, "Brian Smith" <brian@briansmith.org> wrote: >> > I'm afraid we can't really do that without a risk of interoperability >> > failure. TLS mandates something that we prohibit the use of. >> >> Martin, I'm not sure what you are referring to with the pronouns in >> those two sentences. What can't we really do without the risk of >> interoperability failure? What is TLS mandating that we prohibit the >> use of? > > TLS1.2, our minimum version, mandates RSA+AES-CBC. That is the only cipher > suite that is guaranteed to be present in a 1.2 implementation. > But it does > not permit PFS, and it's not AEAD, so we have declared it to be verboten. > That leaves a real possibility that two implementations of HTTP/2 fail to > have a valid suite in common. That is the case regardless of whether the HTTP/2 spec lists a mandatory-to-implement cipher suite or not. History shows that. For example, despite what the TLS 1.2 spec says, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA is not guaranteed to be available in a TLS 1.2 implementation. In fact, there was just a thread on the open-to-the-public Mozilla dev-tech-crypto mailing list about the exact topic of servers that support TLS 1.2 but refuse to negotiate TLS_RSA_WITH_AES_128_CBC_SHA due to fears of BEAST [4]. (That thread, as well as several other threads in the mailing list [2][3] also contains discussion about what Firefox doesn't support the TLS_DHE_*_WITH_AES_*_GCM_* cipher suites.) More generally, even if a specification says that support for a particular cipher suite is mandatory, in practice that requirement is frequently ignored regardless of whether MUST or SHOULD is used in the spec. And, that ends up being tolerable and sometimes even good. For example, I wish *ALL* TLS 1.2 implementations ignored the requirement in the TLS 1.2 spec that TLS_RSA_WITH_AES_128_CBC_SHA is mandatory to implement, because that requirement is harmful. That's my main point: The HTTP/2 spec, once finished, is going to live a *long* time, and any "mandatory to implement" cipher suite that is put into the spec is likely to become outdated quickly. And, people are already working on improved cipher suites that will make any/all currently-standardized cipher suites obsolete. Consequently, it would be harmful to fossilize requirements to support about-to-be-obsolete cipher suites in the HTTP/2 spec. > Your other points are noted. I'm not sure what I can do about them without a > time machine. No time machine is required. Just don't specify a mandatory-to-implement cipher suite in the HTTP/2 spec, just like there wasn't one in the HTTP/1 spec. Instead, let's put cipher suite recommendations into a separate BCP that can be updated much more nimbly and which has the proper audience of people working on it. > Regarding the DHE suite, I only have my phone, but I did check that the DHE > suite is listed and enabled by default in NSS code. Did I miss something? NSS's defaults and Firefox's defaults are different. See [1] and [2] and also see the Firefox source code (nsNSSComponent.cpp). Cheers, Brian [1] https://briansmith.org/browser-ciphersuites-01.html [2] https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/gFfKw3EOffo [3] https://lists.mozilla.org/listinfo/dev-tech-crypto [4] https://groups.google.com/forum/#!searchin/mozilla.dev.tech.crypto/road$20rc4/mozilla.dev.tech.crypto/A_oCI0w9YF4/lFmpmTiYidIJ
Received on Sunday, 20 July 2014 04:01:57 UTC