Re: Comments on Mandatory Ciphers and a Proposal

[Ned Freed <Ned.Freed@xxxxxxxxxxxx>]

> > From: Ned Freed <Ned.Freed@xxxxxxxxxxxx>
> > To: Lewis McCarthy <lmccarth@xxxxxxxxxxxx>
> >
> > Actually, what is surprising here is that you think you can say "TLS
> > compliant" in the absence of a mandatory set of ciphersuites and have
> > any meaning attach to your statement. Saying that you are conformant
> > to something that effectively doesn't have conformance requirements
> > which guarantee interoperability is vacuous as far as a cusomter is
> > concerned.

> Not vacuous at all.  My idea of a "TLS-compliant" product is one which
> executes every ciphersuite that it claims to support correctly and in
> accordance with a testable spec.  If it doesn't claim to support any
> particular algorithm, then it's non-implementation of that algorithm
> has no compliance implications.

Sure sounds vacuous to me -- what you are basically saying is that I can claim
full compliance trivially not doing anything.

> It's always risky to do analogies, but I'll stick my neck out anyway :-)

> Imagine the IETF does standards for VCRs, and it has well-defined
> specifications for the Beta and VHS form factors. You want the IETF to
> say that in order to be an IETF-compliant VCR, you MUST do Beta.

Sigh. Please reread what I've said more carefully, as this isn't even close.
What I've said is effectively that were the IETF to develop a standard for VCRs
it should say "here is what a generic VCR must do and here is a set of extra
requirements that apply if you want to do the default, which happens to be to
support VHS." And then if someone wants to define a new standard for, say,
VHS++, they can use the specification for VHS as a starting point and their job
will be easier because they don't have to fight through the VHS-specific
specification process again.

And if the IETF were to develop a standard for Beta VCRs as well, well of
course it would be silly to require that it also handle VHS, so this additional
standard would simply say "the default VHS requirements given in a separate
section of the base VCR specification don't apply here, and here are the
additional requirements which replace the VHS requirements." Clean and simple,
and what is more, proven to work.

I've also said that I personally think it would be acceptable to have a
specification which says "here is what a generic VCR has to be able to do, but
this is not a complete specification and as such it is meaningless to claim
compliance with it alone. Oh, and here's a list of the things that must be
added to make this into a complete specification." Again, the IETF knows full
well how to do specifications of this sort and how to advance them on the
standards track.  I've also said that while I like the idea of a generic
TLS component suite I'm not sure the IESG will, as this approach has a somewhat
dubious track record in the IETF when it comes to security.

> I want the IETF to say that in order to be compliant, if you claim to
> do Beta you must do it this way, and if you claim to do VHS you must do
> it that way.  And, by the way, you can write a spec for 8mm next year
> without invalidating the current spec.

No. What you want the IETF to is sign on a specification that has no clear
interoperability guidelines and no clear procedures for insuring that such
guidelines are in fact added when this specification is actually used to build
a complete end-to-end protocol. Or, to put it into the terms of your analogy,
you want someone who comes up with a cassette holding 1" tape to be considered
compliant. Or 1' tape, for that matter. Heck, a cassette the size of a Mack
truck would also be fine. Or one the size of a pinhead. Anything goes,
everything complies.

> It's specious to claim that compliance to a standard of the second sort
> doesn't "have any meaning".  It has a well-defined and valuable meaning,
> it's just not the meaning you want it to have.

I never claimed that it didn't have meaning. Again, please reread what I have
said more carefully. Of course it has meaning. But it doesn't have enough
meaning to guarantee interoperability when it is used as part of an application
protocol.

> "IETF-compliance" of the sort requested by the IESG presumes that
> consumers are smart enough to configure their products to enable secure
> interoperability.  (Jeff has said that the MUST algorithms must be
> present in the implementation, not that they must always, or even ever,
> be enabled by users).

Actually the IESG presumes pretty much the exact opposite -- not only do they
presume that consumers will not be able to make such choices, they presume that
application protocol designers won't either. (And frankly, the more I hear of
from this list, the more I'm beginning to think that the IESG may be right and
I'm being unduly optimistic.) I, on the other hand, believe (for now at least)
that application protocol designers will be able to make the right choices, but
only if the TLS specification sets up a framework that clearly lays out the
choices that have to be made. We did this sort of thing with the SMTP
extensions framework, for example, and people had no trouble building this
framework out in a wide variety of ways. And there has been little if any
confusion as to different uses the framework has been put to.

> But those same consumers are presumed to be not smart enough to read a
> brochure and buy a product that supports the algorithms they intend to
> use.

> I don't buy that argument.  Sure there will be people who can't
> understand anything more complicated than a Yes/No IETF stamp of
> approval.  But those people aren't going to be able to set up a secure,
> interoperable system even with such a stamp.

It isn't a question of understanding. It is a question of not wanting to be
bothered. People really don't like to think, and won't do it unless they have
to. So if the IETF says "bless this TLS in all of its magnificent glory and
multitudinous options" what will happen is that people will simply install the
stuff and run with whatever intersection of security methods happens to fall
out of the implementations they use. They won't even bother to look at what
security they are getting. And the only time there will be trouble is when they
get two implementations that don't have a suite in common. And then they will
complain, and when they find out that the IETF let this happen they won't be at
all happy.

> Sure there are people who can't get the 12:00 on their VCR to stop
> blinking.  But even they can tell the difference between tape formats.
> They don't need a standards body to require that one format must
> always be supported.  They just need to know that if they buy a Beta
> tape, it is guaranteed to play in their Beta VCR.

> (The analogy breaks down in the case of multiple-algorithm
> impementations.  Multiple-format VCRs are relatively rare because of
> the expense.  But multiple algorithm SSL/TLS servers are the norm.
> Perfect interoperability is achieved when all servers support A and B,
> thin client 1 supports only A, and thin client 2 supports only B.

Ah, but what happens when thin client 1 has to talk to thin client 2? And
please don't say this cannot happen with your approach -- it can because you
aren't requiring that each application space have a mandatory suite, and hence
clients 1 and 2 could be different implementations of the same application
protocol. The approach I'm advocating, on the other hand, makes this
impossible, because the only way that two compliant clients could end up with
noninteroperating suites is if they are different sorts of applications
entirely.

> MUST-implement requirements preclude this type of system design.)

Actually my experience has been that they do the exact opposite -- far from
precluding this type of design, a carefully laid out framework actively
promotes it in ways that no other approach can.

				Ned