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

[Dave Garrett <[e-mail]>]

For clients wanting to attempt a fallback, yes, this might not be a perfect solution. It is, 
however, far better than the current state. Ciphers would not have to be assessed and implementation 
of the restrictions would be far more simple and clear. Moving the painpoint, as you say, would be a 
notable improvement. One simple check vs. a handful of possibly complex checks.

At this point, Greg Wilkins' proposal looks to be the best available option getting any discussion:

http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0481.html

An HTTP/2 handshake would not be able to include any legacy ciphers, and if this fails then the 
client could then fallback and retry with HTTP/1.1 instead. It gets a more robust handshake in 
exchange for a slightly slower fallback if the server does not support any modern ciphers. I should 
note that this is already something Mozilla is implementing with respect to RC4. The plan is to do 
the initial handshake without RC4 and only offer it as a possibility if the more ideal cipher set is 
rejected. (fallback order becomes: 1.2-RC4, 1.2+RC4, 1.1+RC4, 1.0+RC4)


Dave


On Thursday, November 06, 2014 02:21:02 am Yoav Nir wrote:
> 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