Re: Comments on Mandatory Ciphers and a Proposal

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Keith,

Keith Moore wrote:
> 
> > >         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*.

  Well this argument seems to me anyway to support the argument or lack
of flexibility.  Comments?

>  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.
> 
> 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.
> 
> > >         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.

  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.
> 
> 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*.

  I think you are partly correct with respect to a paticular
application.
But they should be "Recomended and provided" cipher suites rather than
"Mandatory cipher suites".
> 
> Keith

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. 
Phone :913-294-2375 (v-office)
E-Mail jwkckid1@xxxxxxxxxxxxx