Subject: Mandatory to implement cipher suites

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jul 2014 17:01:36 -0700

In consultation with ekr, I've put together a proposal for addressing
#498, listing mandatory to implement cipher suites.

The text is short:

+ Implementations MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
+ <xref target="TLS12"/> and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+ <xref target="TLS-ECDHE"/> with P256 <xref target="FIPS186"/>.

 -- https://github.com/http2/http2-spec/pull/562

The reason I'm posting is to confirm that adding what is called a
"downref" is OK with this group.

A "downref" is a normative reference to a non-standard document, in
this case, an RFC that is in the Informational category [RFC5289].
This is allowed in the IETF process, but it requires that the choice
be made quite explicit.  Read RFC 3967 if you want all the gory
details.

Note that the TLS working group is currently debating whether or not
to put the relevant ECC RFCs on the standards track, which could make
this question moot.

If you want to debate the merits of the particular choices, I'd
request that you start another thread for that purpose.  I only want
to track the procedural issue here.

---

From: Nicholas Hurley <[email-masked]>
Date: Thu, 17 Jul 2014 11:18:33 -0700

> to track the procedural issue here.
I'm 100% fine with this downref.
--
Peace,
  -Nick

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Jul 2014 21:40:12 +0300

I fail to see why we need both a DHE and ECDHE ciphersuite. I prefer that we have only the ECDHE.

DHE depends on the server sending down secure parameters, which the client has no way to verify. It’s also slower. If we’re not including AES-CBC+HMAC-SHA1 we might as well drop DHE as well. 

Having said that, I would have preferred to not have this requirement at all, and leave it to a TLS standard to have mandatory-to-implement ciphersuites. There is nothing special about HTTP(S) that makes some ciphersuite appropriate here while being less appropriate for SMTP. But if we’ve made up our minds to specify an MTI ciphersuite, I suggest we specify only one, and make that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 13:07:50 -0700

> Having said that, I would have preferred to not have this requirement at all, and leave it to a TLS standard to have mandatory-to-implement ciphersuites. There is nothing special about HTTP(S) that…

I'm afraid we can't really do that without a risk of interoperability
failure.  TLS mandates something that we prohibit the use of.

Now, assuming that the TLS WG can produce a recommendation (probably
in the context of 1.3), we will use that.

I'm amenable to your suggestion of just ECDHE.  One being better than
two when it comes to MTI.  I'll note that this is probably something
we should continue in the TLS WG; as we've done so far.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 13:39:20 -0700

> we should continue in the TLS WG; as we've done so far.

I'm sorry, that was a lie: I've included these values because TLS
haven't delivered us an answer at this time.  I'd prefer if they
deliver.

---

From: Brian Smith <[email-masked]>
Date: Sat, 19 Jul 2014 12:33:07 -0700

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

> we should continue in the TLS WG; as we've done so far.

I agree with Yoav that it is better for the HTTP specification to
*NOT* specify a mandatory-to-implement cipher suite. The other
TLS-related recommendations that the HTTP specification makes all seem
good and likely to stand the test of time. However, the current set of
cipher suites that are currently considered reasonable are still
problematic for various reasons. For example, nobody has demonstrated
an AES-GCM implementation that is both correct (free from side-channel
attacks) and efficient on common ARM processors. That should
automatically disqualify AES-GCM cipher suites from being made
mandatory. So far, we have not yet standardized cipher suites that are
both efficient and able to be implemented correctly everywhere, but
that might happen soon with the ChaCha20+Poly1305 or similar cipher
suites. Even if/when such cipher suites are standardized, I think
there would be too many objections to making them mandatory to
implement for HTTP right away. Conversely, I don't think the lack of a
specified mandatory-to-implement cipher suite hurts HTTP in a
practical way whatsoever. HTTP/1 did not have it and we figured out a
way to make things work regardless.

Besides my general objection, I object specifically to making any
TLS_DHE_* cipher suite mandatory to implement, for similar reasons to
Yoav. There are *draft* proposals being written to solve the serious
safety and interoperability issues with TLS_DHE_* cipher suites, but
they haven't been standardized, deployed, or tested yet. Also, I am
concerned that encouraging or mandating any TLS_DHE_* cipher suites
may cause complications for the 1-RTT and/or 0-RTT handshakes in TLS
1.3. In particular, I am concerned that it may be too inefficient to
presumptuously generate ephemeral DHE keypairs for use in the
ClientHello, especially in addition to one or more ECDHE keys that
will have to be presumptuously generated too. I understand that there
are some procedural issues to overcome regarding the use/requirement
of ECDHE in IETF protocols, but I don't think those procedural
concerns outweigh the practical benefits that ECDHE has over DHE.

Also, I'm surprised people from Mozilla are recommending that
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 considering that no Mozilla
products support that cipher suite and considering that Mozilla made a
conscious decision to specifically NOT support that cipher suite.

Cheers,
Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 Jul 2014 14:16:50 -0700

On Sat, Jul 19, 2014 at 12:33 PM, Brian Smith <[email-masked]> wrote:

> Also, I am
> will have to be presumptuously generated too.

Responding just to this point:
The current TLS 1.3 draft [0] does not require clients to provide DHE
shares for every possible key exchange mechanism, nor would I expect
us to require that. Therefore, making DHE mandatory would not require
clients to optimistically generate DHE shares. Clients can simply select
the groups they believe represent the best tradeoff between correct
guessing and CPU cost (or bandwidth cost, which seems to be more
serious).

Of course, it's possible that if we make a number of different groups
MTI, that there will be disjoint sets of server support and that therefore
clients will have to send a lot of shares or run the risk of multiple
round trips. However, I don't think that's made much more likely
by specifying integer DHE.

-Ekr

[0] http://tools.ietf.org/html/draft-ietf-tls-tls13-02

---

From: Martin Thomson <[email-masked]>
Date: Sat, 19 Jul 2014 19:28:45 -0700

> interoperability failure? What is TLS mandating that we prohibit the

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.

Your other points are noted. I'm not sure what I can do about them without
a time machine.

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?

---

From: Brian Smith <[email-masked]>
Date: Sat, 19 Jul 2014 21:01:30 -0700

On Sat, Jul 19, 2014 at 7:28 PM, Martin Thomson
<[email-masked]> wrote:
> suite that is guaranteed to be present in a 1.2 implementation.

> But it does

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.

> 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

---

From: Brian Smith <[email-masked]>
Date: Sat, 19 Jul 2014 21:26:05 -0700

>> will have to be presumptuously generated too.

<snip>

> by specifying integer DHE.

This is exactly my concern, but I do not share your optimism. Also,
Mozilla was able to convince multiple vendors to accelerate the
process of shipping ECDHE support and/or backporting ECDHE support to
older products, in part by having an open discussion of our cipher
suite policies, and in part by refusing to support the non-ECDHE
AES-GCM cipher suites. Debian is a good example of that because
there's nothing confidential about that case: First, they asked us to
enable non-ECDHE AES-GCM support, and we refused. That, at least in
part, motivated them to make an exception to their backporting policy,
and they just recently released a backport of Apache 2.2 with ECDHE
support to Debian Stable.

Consequently, there's evidence that shows that insisting on ECDHE and
not DHE on the client increases the rate of deployment of ECDHE on the
server, which in turn would affect how often optimistically offering
P-256 ECDHE in the ClientHello will likely work in TLS 1.3. That, plus
the security/interop issues cause by the lack of a parameter
negotiation mechanism, as well as poor performance, are the main
reasons why I'm opposed to making any TLS_DHE_* cipher suites
mandatory to implement and why I think nobody should encourage their
use.

Cheers,
Brian