Re: Concluding discussion on #612 (9.2.2)

On Wed, Oct 8, 2014 at 9:30 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> 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 don't really understand the reasoning here. This consideration applies
for the existing MTI cipher suite, which is inherited by HTTP1, and yet
it is still a MUST. The impact of this change is that there would be
no guaranteed interop cipher suite.


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.
>

This seems like an extremely problematic suggestion, for at least two
reasons.

1. It is going to have a negative impact on performance on clients
which offer H2. The reason is that a significant fraction of the existing
H1 servers on the Internet do not support TLS 1.2 and therefore will
not be able to negotiate with the client if the client only supplies AEAD
cipher suites (as required by your 9.2.2). In those cases the client will
have to fall back to a new TLS handshake, with obvious latency impacts
Much of the point of ALPN is that you can offer H2 support without risk,
because sites which don't want to support it can just ignore ALPN, but
this change breaks that invariant and effectively penalizes clients for
offering H2.

2. Unless I misunderstand, this change allows an attacker to force you
down from H2 to H1 by simulating a negotiation failure (note that these
are not authenticated in TLS) and then causing you to reconnect with
H1 only. There may be ways to mitigate this, but it would require some
thought to design them and they might well require changes to TLS.


Moreover, I don't understand what this change achieves. In the current
case, if the client and the server disagree about which ciphers are
acceptable for H2 (and specifically if the server likes some cipher for
H2 that the client does not) then you get a successful TLS connection
but the H2 stack generates an error. At this point, the client could retry
if it wished.

With the design you propose, the server generates a TLS-level failure
(probably handshake_failure) and then the client retries. How is that
better?

-Ekr


> 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.
>