Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

On Wed, Sep 17, 2014 at 12:32 AM, Ilari Liusvaara
<> 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.


Received on Wednesday, 17 September 2014 07:53:08 UTC