Re: Comments on Mandatory Ciphers and a Proposal

[Keith Moore <moore+tls@xxxxxxxxxx>]

> >         Mandatory to implement means that a protocol implementor MUST
> > implement the mandatory portion of the specification. It does *NOT*
> > require that end-users use that portion. In other words we are *not*
> > demanding that all users of TLS use 3DES (or DES), we are just saying
> > that implementers MUST give them the option to in compliant products.
> 
> Which is exactly the problem.  If it's mandatory to implement, it gives
> protocol designers no flexibility as to the encryption choices that are
> right for their applications.  

I don't think so.  The "MUST implement" ciphersuites are defaults, to
be used with most protocols.  That doesn't meen that they're deemed
adequate for all purposes, and a particular application that uses TLS
might want to specify some other mandantory set of ciphersuites *for
use with that application*.  There will surely be uses of TLS for
which 3DES isn't considered to be of sufficient strength, and there
may even be uses of TLS for which DES40 is considered adequate.  So
there's no problem with a particular application protocol using TLS as
a component, and specifying its own mandantory ciphersuites, and we
should expect this from time to time.

And yet, TLS should in most cases be a layer that can be reused and
shared by different applications on the same platform.  So it does
make sense to specify a mandantory ciphersuite set for TLS, and not
only on a per-application basis.

> >         I would be willing to buy into the following compromise (of
> > course before this would be approved by the IESG, the rest of the IESG
> > would have to buy in as well):
> > 
> > Have: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA *and*
> >       TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
> > 
> > as mandatory (along with the anonymous variants as well, for a total
> > of four cipher suite in all. In fact this is the same set that Tim
> > Dierks proposes as "SHOULDs" in his message).
> 
> Per the Danvers Doctrine, I don't like any export crippled cipher being
> a MUST.  Since any exportable implementation is going to be non-compliant
> anyway, I don't see that there's a compelling reason to include one.

Not sure.  If we accept the premise that some (nonconformant) "TLS"
implementations will have no better than 40bit encryption, then we
should ask ourselves the question "are there situations where the
ability to negotiate 40bit encryption is better than the inability to
negotiate encryption?"  (in other words, are there situations where we
would rather communicate using 40bit encryption than to either
communicate in the clear or refuse to communicate?)  Clearly, such
situations exist, and probably in significant numbers.  (I personally
want to use TLS with applications for which authenticity and integrity
guarantees are essential, but for which privacy is nonessential.)

Every application that uses TLS should (a) allow the application layer
to specify a minimum acceptable security level (equivalently, the
allowable set of ciphersuites), and (b) communicate the negotiated
security level (or ciphersuite) to the application.  For instance,
even if the parties are able to negotiate a mutually-acceptable
ciphersuite, a cgi script on a web server might want to behave
differently depending on which ciphersuite were actually used.

For this reason, I would include at least one uncrippled
"authentication only" ciphersuite, as well as the "no authentication,
no encryption" ciphersuite, in the mandantory set.  But I'd also state
that each application should enforce a minimum TLS security level, or
a specific set of ciphersuites, *for that application*.

Keith