Re: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2

[Yoav Nir <[e-mail]>]

Hi, Dave

I believe that ultimately this does not solve the issue raised about 9.2.2 on the httpbis list.

The issue there was that a client would propose AES-CBC and AES-GCM (forgive me for shortening the grouping suites) with “h1” and “h2”, and then it’s up to the server to know that the AES-CBC and “h2” combination is prohibited by the HTTP/2 spec. This could be done either by the HTTP layer checking on the TLS layer, or by adding callbacks and APIs for the HTTP layer to make the choice of ciphersuite for the TLS layer, or by incorporating some HTTP/2 specifications into the TLS layer. People claimed that this was either ugly or hard to implement.

The issue does not go away with your proposal. The reason servers support “h1” at all is to support legacy clients, and the reason clients propose “h1” and non-AEAD ciphersuites at all is to support legacy servers. What your proposal does is move the pain point from ciphersuite selection to version selection. A client would still propose TLS 1.0, TLS 1.1, TLS 1.2, and if it’s updated, TLS 1.3. A server would still have to know that the “h2” and TLS 1.2 combination is invalid, and the complexity remains.

It’s true that the current requirement in HTTP/2 has this issue anyway, as it prohibits TLS versions under TLS 1.2, but I’m in the “rip out 9.2.2 and live with whatever the TLS layer negotiates” camp.

Yoav