Re: Comments on Mandatory Ciphers and a Proposal

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Ned and all,

  First let me say that I appritiated neds disertation here very
intresting a thought provoking.

  Now to his comments...

Ned Freed wrote:
> 
> > 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.

  Possibly so.  But does thai mean that they shouldn't be used and a
possible
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.)

  So you are saying that MANDITORY cipher suites are not the answer
here?
That is how I read you here.  I am not sure that I agree however that
a given ciphersuite cna have mandatory or optional paramaters as being a
diffrent issue.  I believe they are very much interrelated, therefore
cannot be seen as a seperate issue in context here.
> 
> 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.)

  I agree with this process as a vehicle.
> 
> 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.

  You say this does not solve the problem.  True.  But it does provide
for a mechnisim to do so.  Hence, there is at least a method to use
as an approach here.  Therefore leading to a solution.

  Di don't agree that TLS cannot be an entity in aand of itself
entirely.
It can.  It is a "Container type" protocol after all in essance.  The
application is secondary really as I see it.  It doesn't matter what 
particular application one may be using with TLS, if you have the
avaliblity of ciphersuites for those applications built withing TLS
for those applications to use.
> 
> 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.

  I don't see this argument at all.  Interoperability can be met much
better
with SHOULD USE ciphersuites rather than MUST USE ciphersuites.  This 
is where I believe there is a flaw in the logic.  If TLS needs MUSTS
USE ciphersuites to meet the criterian of interoperability, than it is a
very week design.  I don't believe this is the case however.  I believe
that
the folks on the working group have decided that that is the way in
which
they wish to design and build TLS rather than providing any flexibility
within the spec.  This is weak, if so.  And bad design.  
> 
> 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.

  oh boy!  Now we are talking politics here.  THERE ARE NO POLITICAL
SOLUTIONS TO TECHNICAL PROBLEMS!  One of my axioms.  I have never 
waviered from it, and I doubt I ever will.  Logic does not permit it.
> 
> > 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.

  Of course it is a question of what they like or don't like.  You as
much as said it just above.  Politics cannot solve this problem in 
technicaly sound or BEST way.
> 
> > 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.

  If this is so, than the process needs revision terribly.  I am
somewhat 
appaled at this thought.  But there it is.  No process should dictate
any technical standard.  No software should be predicated to any
political
process as to it's viability or design soundness.
> 
> 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

Respectful regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. 
Phone :913-294-2375 (v-office)
E-Mail jwkckid1@xxxxxxxxxxxxx