Discussion of 9.2.2

We’re burning a lot of cycles on the TLS cipher suite requirements, and producing much heat but little light. Discussion seems to be looping, in part because people either aren’t reading the current spec language, or are drawing the wrong conclusions from it.

The actual requirements there are:

1) HTTP/2 MUST only be used with cipher suites that have ephemeral key exchange [plus details].
2) HTTP MUST NOT be used with cipher suites that use stream or block ciphers.
3) Clients MAY advertise support of cipher suites that are prohibited by the above restrictions in order to allow for connection to servers that do not support HTTP/2.

<http://http2.github.io/http2-spec/#rfc.section.9.2.2>

Further discussion needs to be directly related to this text — if you draw conclusions, please do so by illustrating how THESE requirements will result in an interop problem.

As discussed, the TLS WG has been consulted on the current text; there is not a process problem inherent here. Furthermore, an implementation roadblock in a single platform, while unfortunate, is not grounds for changing the protocol on its own. 

That being the case, those who still think we have a problem need to convince the rest of the WG that this is the case — so far, I don’t see that happening.

—

My personal observations (no chair hat):

AIUI, the crux of the purported problem is when a new cipher suite X is introduced, and a client offers it. If the server supports that cipher suite but the HTTP/2 implementation has not decided that it is conformant to these requirements, INADEQUATE_SECURITY will be thrown.

It seems to me that a few editorial changes would help here. 

a) Explicitly note that INADEQUATE_SECURITY is thrown in 9.2.2 (it’s implied by 9.2 but let’s be explicit). This should happen regardless.
b) Change the start of #2 above to “HTTP/2”. This should happen regardless.
c) Change #2 above to “HTTP/2 MUST NOT be used with cipher suites that are known to be stream or block ciphers.” This emphasises that it’s a blacklist, not a whitelist, and avoids throwing INADEQUATE_SECURITY when encountering a cipher suite with unknown properties.

Regards,

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 24 September 2014 11:17:30 UTC