Re: Updated 9.2

On Oct 11, 2014, at 9:54 AM, Greg Wilkins <gregw@intalio.com> wrote:

> 
> I am MUST NOT fail to handshake when there are mutually acceptable cipher/protocol pairs available - even if 9.2.2 implementation is not perfect.

That is problematic for writing servers in a modular way, separating the HTTP layer from the TLS layer.

The way the requirements are set in 9.2.2, if the client sends a ClientHello that says “will do AES-CBC or AES-GCM, for H1 or H2”, the TLS layer that is processing this message has two options:
 1. It can know internally that the combination of AES-CBC and H2 is invalid, and never choose that, or
 2. It can have no knowledge of this and sometimes choose that combination.

Now you can reduce the likelihood of that combination getting chosen by telling the TLS layer to prioritize AEAD ciphers. I don’t like that much, because priorities are better set by performance from all sufficiently secure ciphersuites.

#1 mixes layers in an ugly way. I’d rather not do it. If we’re left with #2, then there will be some cases where the TLS server picks a bad combination, and the HTTP part of the server should be able to deal with it. Otherwise we’re forcing the logic in 9.2.2 into the TLS layer.

So since the working group is not willing to drop the requirement altogether, I think the proposed wording is the right way to go.

Yoav

Received on Saturday, 11 October 2014 21:52:32 UTC