Re: Concluding discussion on #612 (9.2.2)

I've created https://github.com/http2/http2-spec/pull/626

I've taken Eric's more precise wording for 6.2.2 and gone a bit further.
For TLS1.2 it now simply white lists DHE and ECDHE key exchange and black
lists block and stream ciphers.     This should be about as unambiguous as
it gets.

I've made TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 support only a SHOULD, as
it is conceivable that a vulnerability in that cipher will be discovered
while TLS1.2 is still in use.

I have moved the h1 fallback to a section 9.2.3 which is written so that a
Client may not offer a cipher that it subsequently rejects due to
inadequate security.  This addresses my fragile handshake concern, so that
if circumstances for implementations to violate 9.2.2, it will not result
in communications failure.

For those who don't like reading diffs, the resulting text is:

9.2.2 TLS 1.2 Cipher Suites

The set of TLS 1.2 cipher suites that are permitted in HTTP/2 is restricted.

HTTP/2 MUST only be used with ciphers that exchange keys with either: ephemeral
Diffie-Hellman (DHE) [TLS12] with a minimum key exchange size of 2048; or
the elliptic curve variant (ECDHE) [RFC4492] with a security level of at
least 128 bits. Clients MUST accept DHE key exchange sizes of up to 4096
bits.

HTTP/2 MUST NOT be used with Null or Standard Stream Ciphers (Section
6.2.3.1) [RFC5246] nor CBC Block Ciphers (Section 6.2.3.3) [RFC5246].

The effect of these restrictions is that TLS 1.2 implementations could have
non-intersecting sets of available cipher suites, since these restrictions
prevent the use of the TLS 1.2 mandatory ciphers. To avoid this problem,
implementations of HTTP/2 that use TLS 1.2 SHOULD support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256 [FIPS186].
  9.2.3 Cipher Negotiation

A Client that advertises support for the HTTP/2 protocol, MUST NOT
advertise support for a cipher suite that it will subsequently reject with
a connection error (Section 5.4.1) of type INADEQUATE_SECURITY. For the
purposes of backwards compatibility with HTTP/1 Servers, a Client MAY retry
a failed connection with ciphers prohibited by the above restrictions, but
it MUST NOT offer HTTP/2 support with the retry.







On 9 October 2014 06:23, Jason Greene <jason.greene@redhat.com> wrote:

>
> On Oct 8, 2014, at 11:37 AM, Brian Smith <brian@briansmith.org> wrote:
> >
> >> - It is confusing, especially some of the examples confuse instead of
> clarify
> >>  (the mentions of AEAD and AES-GCM are the worst[3]). And getting these
> >>  things wrong causes interop problems.
> >
> > I agree that the attempts to clarify in 9.2.2 that AEAD cipher suites
> > and AES-GCM are acceptable seem to be having the
> > opposite-from-intended effect on clarifying things.
> >
> >> - It wrongly assumes DHE and ECDHE are the only PFS key exchanges.
> >
> > Do you have a suggestion for improving that?
>
> Yes, require TLS 1.3, or alternatively a revision to TLS 1.2 that
> introduces a 3, 4 version, and 1.3 becomes 3, 5 :)
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
>


-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.