W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: h2 ciphers

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 16 Oct 2015 16:04:52 +0200
Cc: ietf-http-wg@w3.org
Message-Id: <C5B48ECA-219D-4017-B7A2-32DD7768F18C@greenbytes.de>
To: Julien Vehent <julien@linuxwall.info>

> Am 16.10.2015 um 15:23 schrieb Julien Vehent <julien@linuxwall.info>:
> 
> On 2015-10-16 09:08, Amos Jeffries wrote:
>> HTTP/2 was designed to be implemented from a clean-slate situation.
>> Everybody is building new code based on the same spec, so there is no
>> legacy behaviours to be tolerant about.
> 
> (I'm the author of the Mozilla guidelines).

Thanks for that wiki!

> This is correct: the recommendation is for HTTP/1.1 where a significant amount of backward compatibility is required. The modern guidelines guarantee strong crypto on somewhat recent clients, but we can certainly do better for http/2.
> 
> We'll probably revise the guidelines in the coming months. In the meantime, on a h2 endpoint, I would recommend limiting it to these ciphers:
> 
> $ openssl ciphers -V 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384'
> 0xC0,0x2F  -  ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(128)  Mac=AEAD
> 0xC0,0x2B  -  ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(128)  Mac=AEAD
> 0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH  Au=RSA    Enc=AESGCM(256)  Mac=AEAD
> 0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=AESGCM(256)  Mac=AEAD
> 
> Note: we don't recommend ECDHE-RSA-CHACHA20-POLY1305 because it's not yet a standard and our mozilla servers don't implement it, but feel free to use it :)

Now, Apache httpd will most often not be a "clean slate" h2 endpoint, but having to serve old, intermediate and modern clients and, among those modern ones, some that announce 'h2' in ALPN. 

When this arrives in Apache, the code needs to decide if it answers h2 or http/1.1 in an ALPN callback from the TLS layer
- the TLS layer has not yet decided on a cipher
- the TLS layer has no concept of a h2 compatible cipher list, best case it is configured with a "modern" list and server-order preference.
- the client cipher list is, I believe, not visible (and even if it was, we could only guess what the TLS layer selects later)

*crickets*

Am I overlooking something?
Received on Friday, 16 October 2015 14:05:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC