RE: Concluding discussion on #612 (9.2.2)

TLS 1.2 introduces the GCM ciphers that have the "holy grail" properties, so
there's nothing wrong with parts of 1.2, it's just a question of how to deal
with the legacy ciphers. But an API that gives a version number check won't
draw the line at the right place.

-----Original Message-----
From: Jason Greene [mailto:jason.greene@redhat.com] 
Sent: Tuesday, October 07, 2014 11:59 AM
To: Mark Nottingham
Cc: HTTP Working Group; Martin Thomson; Greg Wilkins
Subject: Re: Concluding discussion on #612 (9.2.2)

Can we please consider simply requiring TLS 1.3 as a replacement to the
wording in 9.2.2?

Failing that we really need a commitment from all major TLS stacks to
provide the APIs necessary to implement 9.2.2 with HTTP 1.1 compatibility.
Failing that I argue that 9.2.2 should be abandoned, as its proper
implementation will be mutually exclusive with HTTP 1.1 support.

The API requirements for TLS implementation are:

A) The TLS stack must provide clients with a way to order forward DH & aead
(and future stronger cipher classes) with a higher preference than block and
stream ciphers. This should be specified using characteristics instead of
hard coded cipher names, as hard coding cipher names excludes future
ciphers. Alternatively stronger cipher classes do not need to be allowed if
9.2.2 is restricted to TLS 1.2, and 9.2.2 provides a hardcoded list of
ciphers.

B) The TLS stack must provide servers with a way to order h2 *acceptable*
ciphers (DH & aead & anything stronger) above other ciphers in contradiction
to the client's preference list. (Same note on characteristics based or TLS
1.2 hardcoding as above)

C) The TLS stack must provide a characteristics based introspection API to
determine whether or not DH & AEAD were used after negotiation.

Note that a simple requirement on TLS 1.3 is vastly superior to the
implementation complexity of the above, since the protocol
negotiation/handshake is part of the cipher selection process, whereas in
the TLS 1.2 case, we rely on ordering magic and abstraction breaking APIs.

On Oct 7, 2014, at 12:57 AM, Mark Nottingham <mnot@mnot.net> wrote:

> I'd like to get to a call for consensus on
<https://github.com/http2/http2-spec/issues/612> very soon.
> 
> To help get us there, I've prepared a wiki page that I think summarises
the issues that have been raised:
>  https://github.com/http2/http2-spec/wiki/TlsRequirements
> 
> Martin has made a proposal in the form of a pull request:
>  https://github.com/http2/http2-spec/pull/615
> ... and it looks like there's general support for incorporating it. Does
anyone have a reason not to?
> 
> Greg has made a number of proposals, listed in short form at:
>  
> http://www.w3.org/mid/CAH_y2NH=skUXk0QwCs4uVqWE=iOLhi5K+kvARDUQ7uMeogr
> w9A@mail.gmail.com
> 
> Martin and Greg, do you need time to develop your proposals any further?
> 
> Greg, you made quite a few proposals -- did I miss any others, or do you
want to selectively nominate one or more of them for consideration?
> 
> Finally, does anyone else wish to make a proposal?
> 
> Regards,
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

Received on Tuesday, 7 October 2014 18:34:16 UTC