Re: Stricter TLS Usage in HTTP/2

On Thu, May 22, 2014 at 4:01 PM, William Chan (陈智昌)
<willchan@chromium.org>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.
>
> 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.
>>>
>>
>>
>