[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt
> Date: Wed, 09 Sep 1998 23:18:07 -0400
> From: Robert Moskowitz <rgm-ietf@HTT-CONSULT.COM>
> At 06:58 PM 9/9/98 -0400, Theodore Y. Ts'o wrote:
> >
> >It was omitted from the IPSEC last call due to an oversight; which was
> >only caught by the RFC Editor. As the other documents, in particular
> >the DOI document, contain normative references to this document, we need
> >to advance this document before the other IPSEC documents can be
> >advanced.
>
> Not to argue with my good co-chair, but the oversight was the normative
> references. Back in April when we were finally getting the docs out of
> last call (and yes, draft-ietf-ipsec-ciph-cbc-01.txt and 02.txt were part
> of that last call in the workgroup), our AD worked with me to see if we
> could 'stage' the drafts for the IESG. draft-ietf-ipsec-ciph-cbc-02.txt
> was then taken out of the list sent on to the IESG even though the doc
> editor asked thta it be included with the orginal set. For this reason
> there never was an IETF last call on it.
>
I am pleased to see that Bob has already corrected Ted's misconceptions,
and that we are now in agreement that there was never an IETF Last Call
on this document.
This means that we all agree that the original draft announcement was in
error. The changes were not a result of any last call, and a last call
would have to proceed before the document could be approved.
> Now that our alert RFC editor found the normative reference, we have
> rewoken the wg on this doc as Ted mentioned. With the publication of
> draft-ietf-ipsec-ciph-cbc-03.txt, there will now be a IETF last call and
> then on to the IESG so we can get the full set out.
>
An alert reviewer (me) already noted during the IETF last call that
ciph-cbc was referenced in more than one doc, and the issue was included
in my detailed message (to the IESG). I am sorry to see that the
references were not properly removed.
I cannot understand why, as this has been far longer than 2 weeks (April
was a long time ago). The entire suite of documents should have been
published, and well on their way to Draft stage. Given the large amount
of time, I can only conclude that the IESG reviewers were negligent.
Thank goodness there was more care by the RFC Editor staff.
In doc-roadmap, there is a reference to [CBC], which can simply be
removed without affecting the text in any way. There are also other
references to unpublished documents in the Acknowledgements section.
I explicitly requested to the IESG that the following changes be made:
Layering the documents was originally proposed by William Allen
Simpson, and the contents of this document corresponds to the
sections and requirements in RFC-1828, RFC-1829, RFC-1851 and
RFC-1852, and includes wording from later "shim" drafts for DES,
3DES, and DESX. Additional wording was suggested by Hugh
Daniel, Cheryl Madson, Roy Periera, ....
[all references to unpublished or work in progress documents
should be deleted].
In IKE DOI, there are several references to unpublished drafts,
including [ESPCBC] and [DESMAC]. They are not required for
interoperability, and thus are not part of the Proposed Standard. They
should simply be removed.
> This is the problem with wgs that take years to complete.
> draft-simpson-cbc-01.txt talks about CBC, as some people felt that the IETF
> needed a document defining how to do CBC. draft-ietf-ipsec-ciph-cbc-03.txt
> defines a set of CBCish crypto algorithms for use in IPsec as per the
> Roadmap doc. The name space overlap is regretable. And of course, not all
> of the CBC cryptos are in this unified doc. DES is not, and you, Bill, are
> working on a revised DESX per the note from Bellovin and Rivest.
>
Yes. And have a 3DES as well.
However, it was apparent at the time that the name space overlap was
deliberate, and there exist several sections of text that are nearly
identical to my own text. I fail to see how the million monkeys
accidently wrote the same words and diagrams.
> [At 06:58 PM 9/9/98 -0400, Theodore Y. Ts'o wrote:]
> >Indeed, originally we had separate documents for each of the cipher
> >algorithms. It was the decision of the IPSEC working group that having
> >five or six documents of which 90% of the text was boilerplate, and only
> >a minor portion of the text was specific to an encryption algorithm was
> >hard to manage, and that it would be clearer to consolidate the
> >algorithms into a single document.
>
Under our standards process, the WG was simply wrong. It is nigh
impossible to advance unless multiple interoperable implementations have
all implemented all of the options (in the same implementation). It is
very unlikely that some of these algorithms will ever be widely
implemented.
> For those that have not looked at this doc for a while, the algorithms
> included are: 3DES, RC5, CAST, IDEA, and BLOWFISH. From casual
> conversations, we very well might see all of these in a few
> implementations. I am aware of one small company for whom the IDEA
> royalties are not a problem and it sounds like they have licensed BSAFE.
> We shall see. Bill's point is a good one about option groupings, but the
> wg was just getting document overload.
>
And the correct solution was proposed. Take the main set to
publication, and then go back and work on the extensions in a new WG.
I seem to remember taking this approach in another area ... :-)
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32