Re: Ciphersuites (was Re: Mandatory to implement cipher suites)

On Sat, Jul 19, 2014 at 7:28 PM, Martin Thomson
<> wrote:
> On Jul 19, 2014 3:33 PM, "Brian Smith" <> 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,
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).



Received on Sunday, 20 July 2014 04:01:57 UTC