Re: Comments on Mandatory Ciphers and a Proposal

[Ned Freed <Ned.Freed@xxxxxxxxxxxx>]

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

I regard it as axiomatic that sometimes the right thing for an implementation
to do is to fail to interoperate. I don't even regard this as something unique
to security protocols -- it can and should happen all the time in all sorts of
other contexts.

The problem here is that you are confusing two different sorts of
noninteroperability. Noninteroperability that results from bad credentials,
improper configuration, as a result of site policy, or even as a result of
implementations that don't comply with the specification is fine. It is
expected to happen all the time and does so in practice.  And I feel 100%
confident in saying that it is absolutely not the IESG's intention to eliminate
any of these failure cateogires.

But all this isn't what the IETF concerns itself with. (Actually, I wish the
IETF would concern itself more with incompliant implementations, but at present
it does not.) The IETF is concerned with the sort of noninteroperability that
isn't on the preceeeding list, the sort that happens when two different
implementors implement a specification full of SHOULDs and not MUSTs, decide to
pick nonintersecting subsets of MUSTs, and, when a site elects to use both
implementations in their network, they find that not only do the don't work,
they cannot even decide which one is busted because both follow the letter of
the specifications we've written.

Suppose a site decides that some particular cipher suite that isn't on the
mandatory list is the right one to use. Suppose also that the site also decides
that all the mandatory cipher suites are crap and that none of them are to be
allowed. Is this a problem for the IETF? ABSOLUTELY NOT. What this site
has done is elect to use technology for which a simple "complies with
IETF standards" selection criteria is insufficient. No harm, no foul, at least
as long as they don't delude themselves into thinking standards compliancy
is sufficient to interoperate in their environment.

Sites have been establishing and following policies of this sort for as long as
the IETF has been in existance, in the context of security protocols as well as
elsewhere. There is nothing new, or even particularly exciting, about wanting
to do this with applications that use TLS as well.

The problem this presents to the implementor, of course, is that what the
standards say ends up only being a starting point. The point of the standards
is to provide this starting point, so that compliant products used in
out-of-the-box installations with no additional expectations will
intereroperate properly. Once you throw in the realities of a given
environment, however, it becomes a whole new ball game. For example, Internet
standards say that domain names must be fully qualified. So most products
now support fully qualified domain names in compliance with the standards
and hence will interoperate in out-of-the-box installations where fully
qualified domain names are used. However, the reality is that a phenomenal
number of sites are lashed together using shortform names. So implementations
have to be flexible enough to handle networks where shortform names are the
norm. And some very large vendors have made some very costly mistakes when they
didn't take this particular point into account. 

The implementor's art, therefore, lies not only in implementing according to
the standards, it also lies in assessing the needs of the market that lie
outside the scope of the standards process. But all this, while vitally
important, is outside the scope of the IETF.

				Ned