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

[Yoav Nir <[e-mail]>]

Having this intermediate version also makes supporting HTTP/2 more difficult

The most common platform for an HTTPS server is Apache + modssl. Getting HTTP/2 support into Apache involves installing modhttp2. No way of getting around that necessity. But your proposal would require a new version of OpenSSL to be installed. That makes the administrator depend on the release schedule of OpenSSL. That’s a problem.

Yoav

> On Nov 6, 2014, at 9:50 AM, Dave Garrett <[e-mail]> wrote:
> 
> 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