Re: Comments on Mandatory Ciphers and a Proposal

[Ned Freed <Ned.Freed@xxxxxxxxxxxx>]

> The fact that procedurally it is possible for one RFC to modify or
> replace sections of another RFC does not mean that it is desirable to
> do so.  It would be far better to design the first RFC in such a manner
> that it could be incorporated into subsequent documents *without*
> modification.

I disagree. I think having extensible specifications is a Good Thing in
practically all cases.

Now, this doesn't mean that specifications that are written to make
modification confusing or difficult are a Good Thing. They are not. However,
not only is it possible to write specifications that make this sort of thing
easy and clear, it is fairly easy. Seven years ago when I got started in the
IETF it wasn't, but we've learned a lot since then, and there is not a large
base of existing IETF specification to look at for guidance on how to do this.

> Two methods of achieving clean reuse have been proposed:

> 1) Have the Technical Standard for TLS and the Applicability Statement
>    for particular ciphersuites appear in separate RFCs, and

First of all, in practice Applicability Statements in the IETF are used
either to profile standards from other groups or else to profile a
bunch of IETF standards for a particular environment. What you are talking
about here really isn't an Applicability Statement in the sense that
the term is used in the IETF.

I realize that this isn't exactly spelled out in the standards process
documents, but when I've suggested the use of Applicability Statements
in various situations myself I've been told that they aren't the right
mechanism.

Second, the notion of profiling TLS for a particular set of ciphersuites is
essentially a tautology and hence effectively meaningless. What would it mean,
for example, for a ciphersuite to declare itself as being mandatory? Mandatory
in what context? TLS needs to be and will be profiles for a variety of
applications. (A given ciphersuite can have mandatory and optional components,
of course, but this is a very different issue.)

But yes, it is theoretically permissible for the the base TLS specification to
have no ciphersuites in it at all and to have all the ciphersuites in separate
documents, each of them saying nothing about whether or not it is a mandatory
or optional in any particular context. Or you could have a single document with
the base TLS specification, an initial set of ciphersuites, and language
explaining how new ciphersuites can be added by additional documents. (This is
effectively how MIME was done, for example.)

But all this does is push the problem up a layer, it does not solve it. TLS
becomes a set of building blocks and not a protocol per se, and it would then
be up to each application that wants to use TLS to specify what ciphersuites
are mandatory or optional. You can no longer talk about TLS compliance as an
entity in and of itself, since what that means depends on the application
context you're using TLS in, and you will probably be forced to say as much in
your specification.

Now, as to whether or not the IESG would buy into this, I really could not say.
The closest example I know of in prior IETF work is IPSEC, and IPSEC has
mandatory ciphersuites in it, and moreover was not allowed out until it had
these mandatory ciphersuites. MIME is another sort-of counterexample -- it
would have been theoretically possible to have MIME say nothing about what
contents must be supported by comformant implementations, but this was not
allowed either.

On the other hand, IPSEC is typically used in ways that applications have no
control over, so one can argue that mandatory ciphersuites make all sorts of
sense in this context. But TLS is typically something applications have
knowledge of and control over. And in the case of MIME we ended up including
what amounted to a profile for email use in the base document, leaving the door
open for other profiles to be done for other uses of MIME.

In any case, I certainly would have no problem personally with TLS being
advanced in this way. Heck, I was the one of the people that originally
proposed this solution -- Chris Newman was the one that posted the message, but
I was looking over his shoulder at the time. The real question is whether or
not this is acceptable to the IESG, and that isn't something I could comment
on.

> 2) Allow the TLS Applicability Statement be reused without overriding it
>    by designating the preferred ciphersuites as SHOULDs instead of MUSTs.

I don't see this course of action as viable. The clear implication of having
such language in a specification is that TLS is a complete protocol
specification in and of itself and hence that coformance to TLS per se is
meaningfull. And, as has been pointd out over and over again, this simply
does not wash in light of the IETF's interoperability requirements.

Now, you may not like these requirements. You may not think they should apply
to TLS, and you can spend (and have spent) lots of time saying so on this list.
And speaking as someone who has chafed more than once over exactly the same set
of rules, I am very sympathetic because I've been here myself more than once.
For example, I'm probably going to have to prune a bunch of stuff out of the
MIME specifcation before it makes it to Standard, and doing so will hurt like
hell and I'll probably gripe and complain and moan about it a lot. But I'll do
it, because I know that these rules are there for a reason and I cannot expect
an exception to be made for me personally.

Now, if this group wants to pursue this course of action it certainly can. It
can resubmit the document as-is with an explanation of why the group thinks the
IESG's decision was incorrect. However, my take on the matter is that the IESG
has already told you this is a nonstarter, that you've had two members of the
IESG back up this assessment on this list, and thus that any attempt to pursue
this course of action is likely to again be rejected by the IESG. And yes, you
can appeal such judgements, but my guess is that the IAB will not be willing to
reverse the IESG on this point.

> Most of the TLS working group is in favor of option 2 (although I would
> like to hear the opinions of those who haven't chimed in yet - Dan Simon,
> Tatu, ekr, eay (who probably isn't reading email while on vacation :-),
> Paul Hoffman, etc.).

Group consensus in the IETF is necessary but not sufficient. I've seen a group
reach consensus on something that proved to be impossible to get through the
rest of the process dozens of times in the past. And the only cases I can think
of where the group won over opposition from "higher up" was when the opposition
came from the chair and group managed to get the IESG on its side to overrule
the chair.

> The folks with Innosoft addresses and the IESG don't like option 2.

It is not a question of what we like or don't like. We have have a
standardization process here that has been shown to work spectacularly well,
and more to the point, we have years of substantive experience that tells us
that we ignore the rules of the process at our peril. This is why I know, much
as I hate to admit it (and will deny if asked later ;-), that when I have to
sacrifice some of my favorite parts of MIME to get full Standard I'm really
being forced to do the Right Thing.

> Assuming that reaching agreement between the IESG and the WG on option 2
> will be a protracted process, perhaps leading to stalemate, what do folks
> think about option 1?  Although I strongly disagree with having MUST
> requirements at all, for the reasons previously discussed, I could live
> with them if they were explicitly separated from the TLS Technical Standard.

The real question is whether or not the IESG will buy into pushing the required
profiling of TLS up into the application protocols which use TLS. I suggest you
ask before proceeding down this path, and be prepared to answer intelligently
if the IESG comes back with a proposal for a "default set" of required
ciphersuites that an application using TLS can either build on top of or not
as it chooses. (This is more of the form the conformance requirements in
MIME take.)

One final point. I get the distinct feeling that you feel that option 1 is a
huge compromise on your part while the IESG would effectivly not be
compromising at all. With all due respect, I think you need to reassess this.
What is really happening here is that the IESG is forcing you to produce
specifications that stand a reasonable chance of making it through the entire
process. Reconvening groups to fix broken specifications is always
unpleasant... If you think this is bad, wait till you try to move from proposed
to draft. The small compromise you're making now is likely to pay huge
dividends in terms of the future changes you will be able to avoid having to
make.

And as far as the IESG is concerned, it it actually does agree to this
compromise it will be a HUGE step away from prior IETF practices -- the history
of security proposals in the IETF has consistently been that detailed and
extensive profiling was a requirement of entry onto the standards track. IPSEC
had to, PEM had to, etc. In fact about the only security protocol I know of
that has received IESG approval without lots of language of this sort was one I
coauthored: MOSS. We got away with this because we argued that this sort of
profiling belonged somewhere else. Sound familiar?

And MOSS is widely seen as total failure, and the reason I hear given most
often for its failure is that it had too many options too choose from and not
enough guidance as to what options should be implemented. In other words, while
I feel that such a compromise is in the best interests of everyone, it is a
very, very risky step for the IESG to agree to in light of past experience.

Anyway,. that's enough arguing against my own brief -- any more and I may
convince myself that option 1 isn't all that good an idea ;-)

				Ned