Re: Stricter TLS Usage in HTTP/2

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 <ekr@rtfm.com> wrote:

> 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 (陈智昌) <
> willchan@chromium.org> wrote:
>
>> 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.
>>
>
>