ietf-smime
[Top] [All Lists]

Re: Restarting the 40-bit debate

1997-05-10 19:36:31
Meta-discussion alert.

I disagree.  If the standard claims to provide a certain degree of
privacy and authentication, but doesn't mandate that implementations
use cryptographic algorithms and key lengths sufficient to ensure
that degree of privacy or authentication, the standard has failed
to make good on its claims.

<sigh> Keith, for the nth time. Please stick to the spec. Please quote the
spec. That's why we wrote it and are asking for comments.

Paul, I think this goes much too far. Frankly, my assessment is that Keith is
entirely justified in posting what he has. And more to the point, if his
discussion is out of order, so is discussion of the documents you want to have.

This is supposed to be an IETF WG or WG-to-be. Fine. This means the group first
has to get a list set up. A BOF is also useful at this point. Both of these
have already happened.

The next step is to come up with a charter. The beginnings of one were posted
to the list back in January. As far as I know it hasn't been approved -- I see
no signs of much discussion or approval of it on the list by the WG members,
and I see no signs of the charter or approval of it on the IETF home page. (In
fact I cannot find any trace of the S/MIME WG at all there. I don't even know
what IETF this group is being chartered in; I assume it's Security. I also
don't know who the chair of the group is -- the charter doesn't say and I
assume it's not Paul since he's editor of various documents. Having the WG
chair also be the editor has been shown over and over again to be a truly
terrible idea.) This really needs to be attended to before anything else is
done. There is little point in having WG discussion when the WG itself doesn't
exist and has no clearly defined purpose.

Now, the charter that was posted to the list is interesting. (It is also
nowhere near adequate, but that's another matter. Nor is it the same as the
draft charter on the Web page. In accordance with IETF rules, however, I take
the last draft posted to the list as the more definitive one. It certainly is
longer and more complete.) It basically says that the group has two jobs, one
to specify the message format and the other to come up with a "minimum security
profile" for S/MIME, with the latter being the "main task" of the WG. There is
no indication that these two tasks are to done in any particular order than the
deliverable dates, which put the profile second. In fact in practice it is
obvious that the two cannot be separated, as the message format must be
flexible enough to accomodate whatever minimum security profile is developed.
As such, I see considerable justification for discussing the profile first.

Now, I believe what Keith, myself, and others are discussing is what this
minimum security profile needs to be. (It certainly is what I've been trying to
discuss.) And if you believe this group's charter as posted is valid, then this
discussion is totally within the scope of this group. This is true even though
we don't reference your message specification document in everything we say or
discuss. I realize that you want to discuss the messaging specification first,
that you are frustrated that people are ignoring the document you worked so
hard to produce,  but I find nothing in the charter to support your position on
this, and as such I see no reason to be bound by your personal preferences in
this regard.

BTW, if you don't believe the charter will be approved with the stated tasks,
then yes, I agree this discussion is out of order, but then so is discussion of
the documents.

Let me also offer you a bit of advice based on my own past experience that I
think is roughly comparable. When Nathaniel and I first wrote the specification
for what eventually became MIME, our work was basically ignored by the WG for
well over a year. This was incredibly frustrating for us, but in hindsight the
WG chair had a point: Our specification was basically the second thing that
needed to be considered (even though it actually appeared first in the
charter), and the basic problem was that there wasn't enough time in a given
meeting to cover what needed to be done first. Eventually the situation got so
bad that the first matter (SMTP extensions) was split off to a second WG with a
different chair. (Where it bogged down for another year.) In retrospect
a better charter would have fixed this and saved tons of time -- another point
you should consider.

What both Nathaniel and I found to be true was that jumping up and down and
trying to get people to shift focus onto what concerned us didn't work. In fact
all it did was waste time on procedural points that could have been used on
technical matters. I would estimate that our poor handling of this situation
(mostly mine, actually) cost MIME at least four months. And I firmly believe
you're doing yourself no favors by emulating our past behavior in this new
context.

Where in the spec does it "claim to provide a certain degree of privacy and
authentication" that it does not meet?

Actually, the message specification should be silent on this point. The
security profile cannot be silent, and that is what we're effectively
discussing. And more to the point, there are also some tacit requirements
imposed by the IETF standards process itself. (More of them than before now
that the IAB security workshop is complete.) I believe it is this set of
(admittedly somwaht nebuluos) requirements that Keith is referring to. I know
it is what I have been referring to in my postings.

Please cite a specific sentence or
paragraph. We'll fix it, I promise. What we *do* promise in the spec is
that if you use the minimum algorithm (FOO/40), you are using weak
cryptography. We say that many, many times. Thus, we are living up to our
claims. If you disagree, please state exactly where we have made a claim
higher than we support.

(Obviously, this request goes out to everyone. We do *not* want a spec that
overstates its security.)

Even with a longer key, I'd have to question whether the FOO
algorithm has received sufficient public review to make it the
only "MUST support" algorithm in the standard.

There is no FOO algorthim. The spec says there are multiple candidates for
what it will be replaced with. Clearly, I thought.

I for one haven't read the updated specifications. I see no reason to until the
discussion of what is going to be specified in the first place is finished and
a consensus emerges. Only then will I know what to look for in the documents.

If you want to try and track this consensus and keep the documents updated
that's all well and good, but to be honest I think you're making unnecessary
work for yourself at this stage in the game.

                                Ned