Re: [TLS] The risk of misconfiguration

[Yoav Nir <[e-mail]>]

On May 8, 2014, at 4:06 AM, Salz, Rich <[e-mail]> wrote:

>>> The solution to avoid accidental use of NULL ciphers is in the client 
>>> API, no client HELLO should ever include a mixture of NULL and 
>>> non-NULL ciphers-suites.
> 
>> Why not make that a MUST in the RFC, and the same for anonymous DH?
>> I think this solves most of the configuration issues without making any uses impossible.
> 
> I think this is worth serious consideration.

I agree that it’s worth consideration, but we have to be clear on what we’re making a MUST here.

We can mandate that clients don’t mix NULL and non-NULL ciphersuites in the ClientHello. In that case, if some client does send a mixture of NULL and non-NULL, we can point to the implementers and say “your client is not compliant with the RFC”. And they could reply that it’s possible to configure their client to comply. I don’t know how much that helps security, but it seems like a strange way to force something that is basically a  UI/API issue. BTW: does 40-bit export level DES go with the NULL or the non-NULL? Don’t answer that. That’s just me being facetious.

The other thing we could mandate is that servers validate the ClientHello, to make sure that it doesn’t contain ciphersuites of both kinds. That would actually help, because it would drive misconfigured clients off the Internet rather than into potentially insecure modes, but that’s one reason server makers would resist having this change.

Regarding ADH I’m not sure. It makes sense that clients that don’t require server identity should not be blocked just because the server insists on authenticating itself. OTOH you could make the same argument for clients that don’t require confidentiality. So I don’t know where I stand on this.

Yoav