Re: Comments on Mandatory Ciphers and a Proposal

[Keith Moore <moore@xxxxxxxxxx>]

> > > 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*.
> 
> That's not how I interpret what Jeff said.  His statement above seems
> to indictate that any implementation that does not support MUST ciphers
> IS NOT TLS.  Period.

Perhaps we should distinguish between "bare TLS" and "an application
that incorporates TLS".

First, an analogy: Internet Protocol version 4 (IPv4) has several
features that can be implemented.  Only a few of these are "required":
ICMP, subnets, broadcast, and broadcast with subnets.  The reason
that, say, TCP is not required, is that some kinds of hosts
(e.g. routers) might not need TCP.  If a host can get by with just
UDP, or just IP, or some other protocol layered on top of IP, there's
no reason it should implement TCP, and the requirements reflect that.
But if you want IMAP on that host, then TCP will also be required.

One can make a case that "Bare TLS" is much like "Bare IPv4".  Like
IP, TLS is a generic layer that can be reused in many applications,
each with different requirements, and therefore should not be
over-constrained.  Following this argument, either there should be no
required ciphersuites, or perhaps the only required ciphersuite should
be "null authentication, null encryption" (so that an application can
recover gracefully from a failure to negotiate something better).

The counter-argument is that nearly all applications expect a minimum
level of security from TLS, and "Bare TLS" doesn't provide that level
of security without mandantory ciphersuites.


> > 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.
> 
> So, what you're saying is that we say it's "MUST implement", but hey, if
> you don't feel like, you're free not to.

Depends on what you mean by "you".  You as an individual can use TLS
however you want with your own protocols.  And nobody is going to try
to stop you from adding a TLS layer to a standard protocol, for your
own private purposes, if you want to.  

But if you add a TLS layer to a standard protocol, and don't include
the mandantory ciphersuites for use of TLS with that protocol, and
claim to your customers that your implementation conforms to the
standards -- that's misleading and perhaps even dangerous.  It might
not provide adequate security for that application, and it might not
interoperate with other implementations -- including those that follow
the standard for using TLS with that application.

Looking at all this, it's probably inappropriate for any application
to claim that it conforms to the TLS spec -- it should instead claim
conformance to a profile of TLS for use with that application.

Keith