Re: Comments on Mandatory Ciphers and a Proposal

[Keith Moore <moore@xxxxxxxxxx>]

> >I'm willing to consider counter-arguments, but so far I haven't seen
> >any argument that is even close to persuasive.
> 
> Fundementally there is a security arguement that is being forgotten -- TLS
> is first a *security* protocol. Where interoperability and security
> conflict, the winner needs to be security. 

If you mean that a TLS-aware application should not be required to
accept a weak ciphersuite, I agree.  But the argument is that a
TLS-aware application should be required to implement at least one
strong ciphersuite.

> Applications have to be able to
> say that they are "conformant" to the TLS protocol even when they provide
> the result "we can't agree on a mutual security requirement". (Which, BTW,
> I think means they are sufficiently interoperable.)

If a customer buys a POP+TLS client from one vendor and a POP+TLS
server from another vendor, and they won't talk to each other because
they don't each support a TLS ciphersuites of sufficient
strength... somehow I doubt he would agree that they are sufficiently
interoperable.

> Allowing Alice Attacker to focus on breaking any MUST cipherspecs, or by
> putting in place a MUST ciphersuite that will have to be replaced in a
> couple of years for security reasons, or that the market just doesn't
> accept that the IESG's decision as to what is "secure enough" is good
> enough -- all of these are bad ideas. There is no harm to strongly
> encouraging with a SHOULD certain ciphersuites, the harm is not mandating
> them.

If we specify only SHOULD ciphersuites and no MUST ciphersuites, some
vendors will fail to support the SHOULD ciphersuites and claim
compliance with the spec anyway.  These products will either fail to
interoperate with other products, or the users of such products
will have their security compromised.  This is harmful.

No ciphersuite that is "going to have to be replaced in a couple of
years for security reasons" should be in the MUST set.  Are you
claiming that 3DES is falls in this category?  Even if so, I doubt
that omission of 3DES from the "MUST set" would result in better
security...rather, it would allow "export" implementations to claim
that they're compliant with the spec.

Keith