- From: Brian Smith <brian@briansmith.org>
- Date: Wed, 17 Sep 2014 00:52:40 -0700
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Sep 17, 2014 at 12:32 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote: > On Wed, Sep 17, 2014 at 03:44:52PM +1000, Greg Wilkins wrote: > The current ciphersuites are not the problem. It is the future ones. E.g. > if something like Google's nonstandard Chacha20-Poly1305 gets added (IRTF > CFRG has working document on cipher, after that is sent to RFC editor, > expect request for adoption on document on using that with TLS). Type: AEAD. When those new cipher suites get standardized, you (the product developer) will become aware of them, probably WELL before your TLS stack vendor actually implements them. As a responsible software vendor, you've already made it easy for users of your software to install updates of your software, so you can simply write a patch to extend your pattern matching logic. Given that, you can maintain a whitelist of cipher suites (or patterns of cipher suite names) that you will negotiate HTTP/2 with, knowing that very rarely you will need to issue an update that expands that whitelist. If a cipher suite is not on your whitelist, you negotiate HTTP/1. In parallel with that effort, you can work with your TLS stack vendor to extend their API so that their API can answer questions about supported cipher suites, such as "Is this cipher suite using ephemeral key exchange" and "is this cipher suite an AEAD one?" After your TLS stack vendor implements said API, over time fewer users of your software will rely on your extremely rare patches to update the HTTP/2-allowed cipher suite whitelist. By the way, the browser has to do the same thing, in order to decide which cipher suites to block for HTTP/2, and they manage just fine. And, if you simply have your server enable the TLS_ECDHE_*_AES_*_GCM_* cipher suites (using the NIST P-256 curve), and prefer them ahead of all others, for both HTTP/1 and HTTP/2, you can entirely avoid doing even the stuff I mentioned above. Cheers, Brian
Received on Wednesday, 17 September 2014 07:53:08 UTC