Re: Comments on Mandatory Ciphers and a Proposal

[dpkemp@xxxxxxxxxxxxxx (David P. Kemp)]

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

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.

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.

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.


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

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.

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.
MUST-implement requirements preclude this type of system design.)