Re: Comments on Mandatory Ciphers and a Proposal

[dpkemp@xxxxxxxxxxxxxx (David P. Kemp)]

From: Ned Freed <Ned.Freed@xxxxxxxxxxxx>

-------- Begin included message -----------

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

--------- End included message -------------

Precisely!

I believe that someone who implements a tape the size of a Mack truck
*should* be able to claim compliance, and duke it out in the marketplace
with the welterweight Walkmans.  Shouldn't be much of a contest.

Beta was arguably technically superior to VHS, but in the end consumers
spoke and we had, for a short while, near universal interoperability
based on VHS alone, *without any regulatory intervention*.  (The people
who guessed wrong and bought Beta were orphaned, but all they need to
do to recover is toss out the old machine and spend $250 on a new one.)

Later 8mm came along, and now DV.  Consumers have choices based on
their priorities, but they don't have standards-body-enforced universal
interoperability.   I don't see that as a negative consequence, I see
it as a positive.

Standards bodies should be forums where implementors who want to work
together can work out the details for allowing themselves to do so.
Standards bodies *should not* be so full of hubris that they attempt
to mandate what they *think* is best over the near-unanimous objections
of the people who are actually writing code and developing products.


I admit that your "framework" approach is far more sophisticated than
anything I've seen from the IESG or in previous messages from your
co-worker, and it may have potential for satisfying the concerns of
people who don't want a simplistic MUST-implement statement in the base
TLS specification.  But it will take time to study, and no one has
actually come forth with a concrete draft that we can argue about.
The TLS draft is here now, and it's long overdue for standardization.
(Not as overdue as IPSEC, but that's a different story :-).  Can we
just get a simple baseline spec out the door now with a couple of
SHOULD recommendations, and discuss the broader compliance framework in
the Application-over-TLS working groups?

Given that subsequent RFCs can override anything they want, is there
any reason why a baseline TLS RFC with SHOULD-implement is incompatible
with the framework you envision?

Alternatively, could you post the complete text of what you think the
TLS RFC should include in the way of compliance requirements, so we
have something concrete to discuss?  Maybe it will win quick agreement,
maybe not.


> I did not mean to be dismissive of the specification. I respect the
> work that's gone into TLS and I think it is a good protocol design
> overall. But this just strengthens my resolve not to let this group
> piss away all this good work by embarking on a course of action where
> implementations will be able to claim conformance without
> interoperating, which will then be lambasted in the technical media (a
> group always alert for this sort of gaffe on the part of standards
> writers and implementors), and which will then turn the moniker "TLS
> compliant" into a joke.

That's a remarkably pessimistic world view.  The technical media
coverage seems to focus on implementation details and deficiencies of
particular products.  I have yet to see an article that labels a
standard "a joke" because of the presence or absense of feature
compliance requirements.

Specifically, I've seen complaints that frames work differently between
Navigator and IE.  That's perhaps due to an inadequately specific
definition in the HTML spec of how frames are intended to work.  But
I've never seen a complaint in the press that the HTML RFC does or does
not REQUIRE support for frames in the first place.

I've seen criticism in the press of particular implementations of
random number generators, but no criticism that the lack of a mandatory
IETF standard for random number generation was the cause of the
problem.

If, for example, WebTV chooses to implement only RSA/RC4 and the TLS
RFC says DSS/DES is a SHOULD-implement, I find it almost impossible to
envision press coverage blaming the IETF for not making DSS/DES a
MUST-implement.  The coverage would either blame WebTV for ignoring the
IETF recommendation (if consumers are inconvenienced) or congratulate
them on achieving interoperability despite ignoring it (if consumers
are happy).  DSS's status as a recommendation vice a requirement would
be nearly irrelevant.

Perhaps if you could cite some actual negative press coverage devoted
specifically to the lack of a MUST-implement clause in *any* IETF
standard, I would be more inclined to believe that this is a real
problem, not just a rhetorical flourish.