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

Re: Stricter TLS Usage in HTTP/2

From: Yoav Nir <ynir.ietf@gmail.com>
Date: Wed, 4 Jun 2014 07:05:33 +0300
Cc: "William Chan (陈智昌)" <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Adam Langley <agl@google.com>
Message-Id: <5623E329-A917-4BD2-8C26-8ED38C26AC23@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>

On Jun 4, 2014, at 1:17 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> 
> On 22 May 2014 12:58, William Chan (陈智昌) <willchan@chromium.org> wrote:
> 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?
> 
> I've opened https://github.com/http2/http2-spec/issues/491 to track this.  The feedback I've gotten from Mozilla folks is that this would be acceptable to them, though unilateral action from Chrome is not.

I don’t understand the objection. Chrome, as a TLS client, can propose any list of ciphersuites that is acceptable to its developers. Just as IE unilaterally disabled RC4, and pretty much all browsers have disabled RC2 at some point (each doing this unilaterally), why is it unacceptable for Chrome to do this now for the non-AEAD version of AES-CBC? (yes, there’s an AEAD version [1], although no TLS ciphersuites are defined)

As for the proposal itself, the HTTP version is negotiated in the same ClientHello as the list of supported ciphersuites. Making the chosen ciphersuite depend on the version of HTTP selected introduces some new logic to TLS. I don’t think this should be added to the HTTP spec.

Yoav

[1] http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2



Received on Wednesday, 4 June 2014 04:06:00 UTC

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