Re: Comments on Mandatory Ciphers and a Proposal

[Keith Moore <moore@xxxxxxxxxx>]

> Keith Moore wrote:
> > 
> > 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).
> 
> This is where we fundamentally disagree.  As Dan Simon explained so
> eloquently, in a security protocol sometimes the right thing is to NOT
> allow communication.  

That's absolutely true...sometimes.  But for some applications that
are going to use TLS, the right thing is to allow communication in 
degraded mode, and let the application act appropriately, either 
by issuing an error message, or refusing to grant certain privileges.
Imagine an SMTP server which supports TLS...  if you can authenticate 
yourself to it, it will let you use the TURN command.  If you can't 
authenticate yourself to it, it will still let you send mail.

> If there's no intersection between the two sets of
> supported cipher suites, the correct "fallback" is to display an error
> message stating that the application can't communicate because of a
> mismatch of security policies.

Not in all cases, probably not even in most cases.  Applications that 
use TLS need to be aware that they're using TLS, and modify their 
behavior accordingly.  Applications have to implement security policy
anyway, because there's a lot more to security policy that what 
the TLS layer can enforce by itself.

> >> 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.
> 
> Okay, but I have to wonder what you consider a standard protocol.  Do
> you mean IETF standards, or are other standards okay?  

IETF can make rules for itself, and suggestions for other standards
bodies that use TLS.

> Does the standards
> body that defined the basic standard also have to define the profile for 
> TLS when used with that protocol, or can some other standards body?  

No.  But we try not to step on each others' toes.

> These may seem like silly questions, but I'm very serious, and I don't know
> the answers.  I want to do the right thing, and I don't want to lie to
> my customers.  What does "implements the TLS protocol" mean?

Here's a stab at an answer:

1. The TLS RFC should specify a default set of ciphersuites to be used 
in the case where there is no specification for FOO+TLS, or if the spec
for FOO+TLS doesn't override the defaults.

2. The TLS RFC should state something like:

a. Because the default set of ciphersuites might not be appropriate,
widespread deployment of a TLS-aware application in the absence of
a standard specification for doing so, is discouraged.

Any application FOO which simply claims conformance to the TLS spec, 
rather than a spec specifically written for TLS+FOO, is assumed to 
support the mandantory ciphersuites in the TLS spec.  (though 
applications should always be able to have their security policy set 
to enable or disable any of the ciphersuites supported by their TLS layers.)  

b. Anybody (not just IETF) who writes a spec for FOO+TLS, who doesn't 
think the default set of ciphersuites is appropriate, should specify 
a different set.   If that spec doesn't specify a different set of
mandantory ciphersuites, the default set in the TLS RFC is assumed.

c. A TLS layer, as opposed to an application using TLS, should claim 
compliance to the TLS spec *and list the ciphersuites it supports*.

(overall, I find it much easier to specify what "compliant TLS-enabled 
FOO" means, than I do to specify what "compliant TLS implementation" means)

> Here's another case:  what if two different standards bodies standardize
> the same protocol (such as PKIX is doing with X.509)?  Who gets to
> decide what the profile is?

Anyone can define a profile.  Implementations should claim compliance
to one or more particular profiles, e.g. RFC FOO or IS-XXXX-99 or X.###.
That's the only way to be unambiguous.

> > 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.
>
> This is a very subtle distinction, which is probably beyond most users.
> And I guarantee that marketing will always say "TLS compliant" or
> "implements TLS", rather than "conforms to the TLS profile for protocol
> foo".

And that's the rub.  We want to make it difficult for marketing people
to mislead people.  Of course, that's what they're best at :)

We can't keep marketing people from claiming "compliance with TLS",
but we can specify what "compliance with TLS" means.  And if we publish
standards with titles like "Standard Profile for SMTP with TLS"
we can at least hope that those RFCs will be referenced.

Keith