Subject: Stricter TLS Usage in HTTP/2

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 22 May 2014 12:58:12 -0700

I've been coding up https://http2.github.io/http2-spec/#TLSUsage in
Chromium. When implementing this, I talked to agl@ about what to
ciphersuites to allow. We ended up deciding to be stricter than the spec.
For example, we only allow AEADs.

agl@ thought it'd be nice if we could change the spec to reflect Chromium's
stricter stance here (https://codereview.chromium.org/291093002/#msg14). Is
this controversial? Can we change the spec's guidance here to be more
strict?

For exact details, my current patch is at
https://codereview.chromium.org/291093002/diff/140001/net/ssl/ssl_cipher_suite_names.cc
:

 *348* bool IsSecureTLSCipherSuite(uint16 cipher_suite) { *349* CipherSuite
desired = {0}; *350* desired.cipher_suite = cipher_suite; *351*
*352*void* r = bsearch(&desired,
*353* kCipherSuites, *354* arraysize(kCipherSuites),
*355*sizeof(kCipherSuites[0]),
*356* CipherSuiteCmp); *357*  *358* if (!r) *359* return false; *360*
*361*const CipherSuite* cs = static_cast<const CipherSuite*>(r);
*362*  *363* const int key_exchange = cs->encoded >> 8; *364* const int
cipher = (cs->encoded >> 3) & 0x1f;  *365* const int mac = cs->encoded &
0x7; *366*  *367* // Only allow forward secure key exchanges. *368* switch
(key_exchange) { *369* case 10: // DHE_RSA *370* case 14: // ECDHE_ECDSA
*371* case 16: // ECDHE_RSA *372* break; *373* default: *374* return false;
*375* } *376*  *377* switch (cipher) { *378* case 13: // AES_128_GCM
*379*case 14: // AES_256_GCM
*380* case 17: // CHACHA20_POLY1305 *381* break; *382* default:
*383*return false;
*384* } *385*  *386* // Only AEADs allowed. *387* if (mac != kAEADMACValue)
*388* return false; *389*  *390* return true; *391* } *392*  Cheers.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 May 2014 13:22:15 -0700

On 22 May 2014 12:58, William Chan (陈智昌) <[email-masked]> wrote:

> agl@ thought it'd be nice if we could change the spec [to be AEAD only].
> Is this controversial? Can we change the spec's guidance here to be more
> strict?
>

Andrei, can you comment on the availability of AEAD ciphers in schannel?
[1] shows them as only being available with ECDSA certificates.

One data point that might be relevant to this discussion is that TLS 1.3
*only* supports AEAD modes.  But this proposal seems to go a little further
than that by selecting a very narrow set of acceptable suites.

--Martin

[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 May 2014 13:27:58 -0700

I have mixed feelings about this.

This is a not-unreasonable cipher suite profile (indeed, it's pretty much
what we
are planning to require in TLS 1.3). I wouldn't be really upset if HTTP
decided to
require this. OTOH, if Chrome has a stricter set of requirements than HTTP,
that seems like it's going to have some pretty negative impacts on user
experience if some servers deploy with only ciphersuites which are not in
Chrome.

-Ekr

On Thu, May 22, 2014 at 12:58 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> agl@ thought it'd be nice if we could change the spec to reflect
> Chromium's stricter stance here (
> https://codereview.chromium.org/291093002/#msg14). Is this controversial?
> Can we change the spec's guidance here to be more strict?
>
>  *348* bool IsSecureTLSCipherSuite(uint16 cipher_suite) { *349*CipherSuite desired = {0};
> *350* desired.cipher_suite = cipher_suite; *351*  *352* void* r =
> bsearch(&desired, *353* kCipherSuites, *354* arraysize(kCipherSuites),
> *355* sizeof(kCipherSuites[0]), *356* CipherSuiteCmp); *357*  *358* if
> (!r) *359* return false; *360*  *361* const CipherSuite* cs =
> static_cast<const CipherSuite*>(r);  *362*  *363* const int key_exchange
> = cs->encoded >> 8; *364* const int cipher = (cs->encoded >> 3) & 0x1f;
> *365* const int mac = cs->encoded & 0x7; *366*  *367* // Only allow
> forward secure key exchanges. *368* switch (key_exchange) { *369* case
> 10: // DHE_RSA *370* case 14: // ECDHE_ECDSA *371* case 16: // ECDHE_RSA
> *372* break; *373* default: *374* return false; *375* } *376*  *377*switch (cipher) {
> *378* case 13: // AES_128_GCM *379* case 14: // AES_256_GCM *380* case
> 17: // CHACHA20_POLY1305 *381* break; *382* default: *383* return false;
> *384* } *385*  *386* // Only AEADs allowed. *387* if (mac !=
> kAEADMACValue) *388* return false; *389*  *390* return true; *391* } *392*
> Cheers.
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 22 May 2014 16:01:01 -0700

Can you explain the negative impact on user experience? We're coupling this
change to draft HTTP/2 implementations and SPDY/4+. So this won't break any
currently live server. It's true though that it would negatively impact
user experience when servers update to HTTP/2 and SPDY/4+. That however,
will be their problem based on the Universal Rule of Users: the last thing
that is updated is to blame. So, if we think these are good cipher suites
to encourage (do people think so?), then I don't immediately foresee a
problem with Chromium having a stricter set of requirements than the spec.
It'd be nice for the spec to agree with us, so when servers try to test
their updates to latest HTTP/2 versions, there will be a convenient place
to find out why we send them GOAWAYs with INADEQUATE_SECURITY.

On Thu, May 22, 2014 at 1:27 PM, Eric Rescorla <[email-masked]> wrote:

> On Thu, May 22, 2014 at 12:58 PM, William Chan (陈智昌) <
> [email-masked]> wrote:
>
>> https://codereview.chromium.org/291093002/#msg14). Is this
>> controversial? Can we change the spec's guidance here to be more strict?
>>
>> kAEADMACValue) *388* return false; *389*  *390* return true; *391* }
>> *392*  Cheers.
>>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 May 2014 17:09:20 -0700

On Thu, May 22, 2014 at 4:01 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> Can you explain the negative impact on user experience? We're coupling
> this change to draft HTTP/2 implementations and SPDY/4+. So this won't
> break any currently live server. It's true though that it would negatively
> impact user experience when servers update to HTTP/2 and SPDY/4+
>

This is the scenario I am concerned about.

> . That however, will be their problem based on the Universal Rule of
> Users: the last thing that is updated is to blame.
>

I'm not sure I agree with that :)

-Ekr

So, if we think these are good cipher suites to encourage (do people think
> so?), then I don't immediately foresee a problem with Chromium having a
> stricter set of requirements than the spec. It'd be nice for the spec to
> agree with us, so when servers try to test their updates to latest HTTP/2
> versions, there will be a convenient place to find out why we send them
> GOAWAYs with INADEQUATE_SECURITY.
>
>>> static_cast<const CipherSuite*>(r);  *362*  *363* const int
>>> key_exchange = cs->encoded >> 8; *364* const int cipher = (cs->encoded
>>> >> 3) & 0x1f;  *365* const int mac = cs->encoded & 0x7; *366*  *367* //
>>> Only allow forward secure key exchanges. *368* switch (key_exchange) {
>>> *369* case 10: // DHE_RSA *370* case 14: // ECDHE_ECDSA *371* case 16:
>>> // ECDHE_RSA *372* break; *373* default: *374* return false; *375* }
>>> *376*  *377* switch (cipher) { *378* case 13: // AES_128_GCM *379* case
>>> 14: // AES_256_GCM *380* case 17: // CHACHA20_POLY1305 *381* break;
>>> *382* default: *383* return false; *384* } *385*  *386* // Only AEADs
>>> allowed. *387* if (mac != kAEADMACValue) *388* return false; *389*
>>> *390* return true; *391* } *392*  Cheers.
>>>
>>
>>
>

---

From: Andrei Popov <[email-masked]>
Date: Fri, 23 May 2014 23:53:33 +0000

Hi Martin,

Disabling/removing obsolete TLS versions and weak cipher suites, when possible, is a good idea. UTA maintains a TLS BCP aiming to provide reasonably current recommendations for secure use of TLS: http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-00. These recommendations are meant to change over time, so in my opinion it is best for application protocol specs to reference the TLS BCP, rather than duplicate snapshots of BCP recommendations or turn them into requirements.

Unless of course it can be shown that e.g. HTTP/2 is more vulnerable than other application protocols, when used over TLS with e.g. a CBC cipher suite, and therefore requires stricter TLS usage.

Regarding the availability of the AEAD ciphers in schannel, [1] does not include recent updates:
http://support.microsoft.com/kb/2929781/en-us#appliesto
Basically, schannel supports GCM cipher suites with ECDSA and RSA certs.

Cheers,

Andrei

From: Martin Thomson [mailto:[email-masked]]
Sent: Thursday, May 22, 2014 1:22 PM
To: William Chan (陈智昌)
Cc: HTTP Working Group; Adam Langley; Andrei Popov
Subject: Re: Stricter TLS Usage in HTTP/2

On 22 May 2014 12:58, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:
agl@ thought it'd be nice if we could change the spec [to be AEAD only]. Is this controversial? Can we change the spec's guidance here to be more strict?

Andrei, can you comment on the availability of AEAD ciphers in schannel?  [1] shows them as only being available with ECDSA certificates.

One data point that might be relevant to this discussion is that TLS 1.3 *only* supports AEAD modes.  But this proposal seems to go a little further than that by selecting a very narrow set of acceptable suites.
--Martin

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx