Re: Comments on Mandatory Ciphers and a Proposal

[Keith Moore <moore@xxxxxxxxxx>]

> >  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.
> 
>   I agree.  However this argument does not support a requirnment for
> a MANDITORY cipher suite as part of the spec.

Nope.  It's okay for a feature to be a SHOULD if failure to implement
that feature doesn't compromise interoperability.  

TLS claims, by its very name, to provide security.  If two TLS
implementations fail to agree on a ciphersuite of adequate security
because one of them decided not to implement a SHOULD ciphersuite,
then the specification does not provide interoperability.

It's fine for the general TLS spec to have one set of mandantory
ciphersuites, to be used with most applications, and for any specific
application to have its own set of mandantory ciphersuites.  But in
either case there MUST be a mandantory ciphersuite for every
standards-track TLS-aware application.

> > 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 don't see the logic in your argument at all here.  In fact both of
> you arguments (Above) point the other direction instead IMHO.

If several TLS-aware applications run on a single host, they should be
able to share a single TLS library.  That TLS library needs to have
enough ciphersuites to support the minimum requirements of all those
applications.  

> > 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.
> 
>   Ok.  Than these considerations seem to point to a "Should Use"
> sensrio rather than a "Must use" senerio.  Hence a mandatory
> cipher suite or set of sipher suites seems non-valid according to
> your perposed requirnments here.

It's fine with me if the 40bit ciphersuites are in the "SHOULD
implement" category, as long as the DH/DSS/3DES ciphersuit is "MUST
implement".

Keith