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

Re: h2 ciphers

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Sat, 17 Oct 2015 02:08:17 +1300
To: ietf-http-wg@w3.org
Message-ID: <5620F6C1.9080200@treenet.co.nz>
On 16/10/2015 11:35 p.m., Stefan Eissing wrote:
> In the documentation at https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility the "modern" compatibility specification includes the following ciphers:
> 
> ECDHE-RSA-AES128-SHA
> ECDHE-RSA-AES128-SHA256
> ECDHE-ECDSA-AES128-SHA
> ECDHE-ECDSA-AES128-SHA256
> 
> ECDHE-RSA-AES256-SHA
> ECDHE-RSA-AES256-SHA384
> ECDHE-ECDSA-AES256-SHA
> ECDHE-ECDSA-AES256-SHA384
> 
> DHE-RSA-AES128-SHA
> DHE-RSA-AES128-SHA256
> DHE-RSA-AES256-SHA
> DHE-RSA-AES256-SHA256
> DHE-DSS-AES256-SHA
> DHE-DSS-AES128-SHA256
> 
> but RFC 7540 includes TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ECDHE-RSA-AES128-SHA) and all those others as a MAY for INADEQUATE_SECURITY.
> 
> Now, assuming I got the cipher names correct, what am I to check for? Shall I be liberal in what I accept - again?

The RFC is the specification. If a browser does not follow it that is a
bug in their implementation (or maybe just their documentation), do not
make matters worse by adding a bug to your code.

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. Methods of extending the
protocol are also explicitly defined and explicitly negotiated when used
to make feature support (or lack of it) a defined state within the
protool itself.

Amos
Received on Friday, 16 October 2015 13:09:29 UTC

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