Re: #612: 9.2.2 and ALPN

> On Nov 12, 2014, at 9:31 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
> On Nov 12, 2014, at 5:38 PM, Eric Rescorla wrote:
>> I think we may be talking past each other. A server that behaves this way will
>> simply appear as broken to every user of every client which behaves
>> as I indicated above. I suspect that may not be what they wanted.
> 
> I am well aware of what you are stating.  It is simply wrong.  Such a
> client has a bug because it requested a secure session using what it
> considers an insecure cipher.  

Hi, Roy

Much as I agree with you about section 9.2.2 and the behavior that it prescribes being inappropriate for this document, the working group has considered this argument months ago, and then again weeks ago and rejected it.

What’s more, I don’t think anyone has argued that TLS_RSA_WITH_AES_128_CBC_SHA is insecure when used with TLS 1.2. It is a fine, secure ciphersuite. Nevertheless, the CBC construction has in the past been a source of vulnerabilities, all of which could be worked around, but which required changes to deployed products. GCM-based ciphersuites are faster and AEAD constructions are considered to have more robust security. That is not to say that TLS_RSA_WITH_AES_128_GCM is more secure than TLS_RSA_WITH_AES_128_CBC_SHA, just that we believe the likelihood of the next BEAST, LUCKY13 or POODLE happening in the latter is much greater than the likelihood of it happening in the former. For this reason the working group has decided that the new protocol HTTP/2 will use only AEAD ciphersuites.

Would you object less if the error code was named INAPPROPRIATE_SECURITY rather than INADEQUATE_SECURITY ?

> If the client sends an h2 request on that
> connection, I simply don't care how badly they break when they get an
> h2 response.  The h2 server isn't going to do anything about it because
> it has no control over the chosen ciphers.
> 
> The client is fully capable of interop in that case.  If it chooses not
> to try again with a good cipher, then it has failed its own user.
> 
> ....Roy
> 
>

Received on Thursday, 13 November 2014 07:56:43 UTC