W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Stricter TLS Usage in HTTP/2

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Thu, 22 May 2014 12:58:12 -0700
Message-ID: <CAA4WUYi6Oc=VRK1dq-o57nnkmubz1MYrPvfiAQUhGOpcJiGWCA@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>, Adam Langley <agl@google.com>
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.
Received on Thursday, 22 May 2014 19:58:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC