RE: 9.2.2 Cipher fallback and FF<->Jetty interop problem

To sum up: HTTP/2 spec imposes restrictions on TLS cipher suites.

Pros: 
1. "h2 is an opportunity to update to current best practice. If you design a pure h2 service you can be more confident in its security properties."
2. Is there anything else?

Cons:
a) TLS code now needs to filter ALPN IDs based on the negotiated cipher  suite, or the HTTP stack needs to filter cipher suites based on the enabled HTTP versions.
b) The server's security policy (e.g. allowed TLS protocol versions and cipher suites) is now coupled to the supported HTTP versions. System admin cannot change these (seemingly orthogonal) things independently.
c) More code complexity, deployment complexity, possible interop issues, failing connections...

So far the cons look more convincing to me than the pros, but maybe I am missing some important pros?

Cheers,

Andrei

-----Original Message-----
From: Michael Sweet [mailto:msweet@apple.com] 
Sent: Friday, September 5, 2014 1:36 PM
To: Martin Thomson
Cc: Simone Bordet; Patrick McManus; Greg Wilkins; HTTP Working Group
Subject: Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

[If these suggestions are acceptable, please let me know how you'd like these chopped up and I'll file issues accordingly...]

Martin,

After reviewing the issues I am still uncomfortable with having a list of proposed TLS 1.3 standard cipher suites and feature restrictions made required in the HTTP/2 specification.  These choices haven't even gone through TLS WGLC, and judging from the amount of discussion on the TLS list I would not want to make any decisions based on what may or may not be in TLS 1.3.

I am OK with the wording in section 9.2.

For section 9.2.1, the requirement for SNI makes sense, although it seems strange to put the core requirement on the TLS implementation; maybe:

   HTTP/2 implementations that support TLS MUST also support the Server Name
   Indication (SNI) [TLS-EXT] extension to TLS.  HTTP/2 clients MUST indicate
   the target domain name when negotiating TLS.

   (you might change "indicate" to "specify" here, but that's purely editorial)

The prohibition for compression probably only belongs in the Security Considerations.  I notice that compression is already a SHOULD NOT in the current version of TLS-BCP, and I think it is OK to make it a MUST NOT and cite the BREACH attacks.  Maybe provide a forward reference to section 10.6 at the beginning of 9.2.1 for all of the security-related feature prohibitions?

The prohibition for renegotiation needs to be considered carefully - this is an area of intense discussion in the TLS WG and I expect there will be some form of renegotiation/rekeying in TLS 1.3 to address long-lived connections (at least).  You *could* prohibit renegotiation to obtain client credentials, but even then I would make it a SHOULD NOT and cite interoperability and potential security concerns, and any SHOULD NOT/MUST NOT for security reasons belongs in section 10 (security considerations)...

I am VERY uncomfortable with Section 9.2.2 as currently written.  Basically it makes it impossible to use a TLS/1.2 [RFC5246] implementation since you are prohibiting the only required TLS/1.2 cipher suite (TLS_RSA_WITH_AES_128_CBC_SHA).  I would be much more comfortable requiring base TLS/1.2 (TLS_RSA_WITH_AES_128_CBC_SHA) and recommending the rest.

Finally, there is nothing in section 10 about the TLS-BCP recommendations; in addition to the two prohibitions from section 9.2.1, you could throw in the "MUST NOT negotiate RC4" and highlight other important stuff concerning TLS and HTTPS.

Last (editorial) issue: there are lots of TLS-foo references that really should be RFCnnnn references...


> On Sep 5, 2014, at 1:38 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On 5 September 2014 10:29, Simone Bordet <simone.bordet@gmail.com> wrote:
>> I could not find any discussion in the mailing lists about what 
>> ciphers to include or exclude, so can you please provide context 
>> about when there was a consensus to choose these particular ciphers ?
> 
> There was a discussion in Zurich, where we had a large contingent of 
> TLS folks.  That was where the original decision was made.  You can 
> find issues that track the decisions on github.  There was also a 
> discussion around cipher suite choice at the last two meetings.  All 
> of that should be minuted (and in recordings).
> 
> There are a few different things we're talking about here, but if you 
> want to talk about ciphers, then #498 is probably most appropriate.
> #318 is the meta issue.  You can see #357 relates, as well as many of 
> the other ones here:
> https://github.com/http2/http2-spec/issues?q=is%3Aissue+is%3Aclosed+TL
> S

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Friday, 5 September 2014 22:15:17 UTC