- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 23 Sep 2014 07:42:55 +0200
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: Jason Greene <jason.greene@redhat.com>, Greg Wilkins <gregw@intalio.com>, Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Eric, On Mon, Sep 22, 2014 at 11:21:52AM -0700, Eric Rescorla wrote: > > Ok but then if you wait on HTTP/3, 9.2.2 then precludes your ability to > > select a more modern cipher category like the Aero example. So it doesn???t > > seem to really meet the former case, and it certainly doesn???t meet the > > latter. > > I don't think that's true. 9.2.2 doesn't say you can't do non-AEAD. It says > that you can't do stream or block. Rather: > > "Clients MUST accept DHE sizes of up to 4096 bits. HTTP MUST NOT be used > with cipher suites that use stream or block ciphers. Authenticated > Encryption with Additional Data (AEAD) modes, such as the Galois Counter > Model (GCM) mode for AES <http://http2.github.io/http2-spec/#RFC5288> > [RFC5288] are acceptable." > > I would assume that any new cipher spec would come with a "this is OK for > HTTP2" bit (or not). So I don't see the interop problem. I think it's not easy to tell what will exist in the future, however we can exhaustively list what existing ciphers we don't want to support. Thus, shouldn't we instead enumerate a list of properties that are incompatible with HTTP/2 ? That would leave the door open for new ciphers. HTTP/1 has benefitted from TLS evolutions for almost 20 years, and I would find it sad that we have to emit a new HTTP version just to make everyone support a new cipher. This is instead a property of the TLS layer and both sides upgrade progressively to support new versions. Regards, Willy
Received on Tuesday, 23 September 2014 05:43:31 UTC