[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, 9 Sep 98 19:11:01 GMT
From: "William Allen Simpson" <wsimpson@greendragon.com>
I was horrified to see this posting today, and this message is a formal
protest against this document being advanced:
> Title : The ESP CBC-Mode Cipher Algorithms
> Author(s) : R. Pereira, R. Adams
Gentlefolk, it cannot "reflect comments", as this document has not been
through any "last call". Even the WG chose not to advance it during the
internal last call. It was deliberately _omitted_ from the IESG IPSec
last call.
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.
When I was notified of this last week, I consulted with Jeff Schiller
and Bob Moskowitz, and we agreed that the most efficient way to deal
with this oversight, while staying within the bounds of our standards
process, was for me to send out a note explaining this situation to the
IPSEC working group. There, we gave notice of our intention to advance
this document to IETF Last Call the following week, and if folks had any
issues with this, to please comment on the IPSEC list ASAP. (Note that
an internal WG last call is not required by our processes before IETF
last call, but we did want to give the working group time to make any
last-minute comments.)
As it turns out, the Roy Pereira, the document editor, had some changes
batched up that clarified the document, and that so this was the -03
version of the document was sent to the Secretariat this week, and whose
announcement apparently caused you great horror.
Today, I formally asked Jeff Schiller to put this document out for the
two-week IETF Last Call, which should get sent out tomorrow.
-----------------------------------------------
As to your specific issues with the documents, let me address them one
by one. Any further discussion on these points would probably be more
appropriate on the IPSEC working group list, so I have set the Reply-to:
field on this message to ipsec@tis.com. (Any folks who are not on the
IPSEC mailing list and who are interested are very much welcome to send
mail to ipsec-request@tis.com to get added to the IPSEC mailing list.)
(1) If there is a need for a "normative" CBC mode description, this is
already available as draft-simpson-cbc-01.txt, which has long been
awaiting publication as Informational (no last call is needed).
This document is a matched set with the DOI document, and contains
details of the default key sizes, weak key checks, etc. needed for the
various algorithms specified in the DOI. (The DOI document contains a
listing of which algorithms are mandatory and which are optional; this
document contains the details of how those algorithms are to be used
with ESP.)
(2) Including multiple ciphers in the document makes it difficult or
impossible to advance. We have often had this problem with "kitchen
sink" options documents in other WGs.
(3) Several of the ciphers are proprietary, and are not likely to be
universally implemented, again making it impossible to advance.
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.
It is true that if we do not have more than the two required independent
interoperable implementations for some of the various algorithms, we
will need to drop those algorithms before we advance this document to
Draft Standard. It is a relatively common occurance the IETF to drop
optional-to-implement portions of a standard, if there aren't the
requisite number of interoperable implementations of that part of the
standard. Indeed, one could call that valuable implementation
experience --- if we find out that part of the standard is not being
implemented, that we can take it out when we advance the document.
(4) The document does not meet the WG doc-roadmap requirements, which
have been through last call.
The Document Roadmap does in fact reference the draft-ietf-cipb-cbc
document; again, it was originally the intent the IPSEC wg to advance
this document. The fact that it was not advanced with the other IPSEC
documents was purely an administrative oversight on my part, and I
apologize for that.
(5) Some of the ciphers are "standardized" for 40 bits. The formal
position of the IETF, after considerable debate, and acclaimation at
an open IESG plenary, has been that this is unacceptable!
In fact, if you read draft-ietf-ipsec-cipg-cbc-03.txt, you will find
that the document specifies a default key size of 128 bits for all
ciphers except for 3DES, which as a key size of 192 bits.
(6) This document is derivative from my own text without sufficient
attribution. Figures and quotations are plagiarized, from
draft-simpson-cbc-01.txt and draft-simpson-des3v2-03.txt (or earlier
versions thereof).
To quote from the Acknowledgements section:
>This document is a merger of most of the ESP cipher algorithm
>documents. This merger was done to facilitate greater
>understanding of the commonality of all of the ESP algorithms and
>to further the development of these algorithm within ESP.
>
>....
>
>Thanks to all of the editors of the previous ESP 3DES documents; W.
>Simpson, N. Doraswamy, P. Metzger, and P. Karn.
I'm not sure what you mean by "quotations", since there aren't any
quotations in draft-ietf-ciph-cbc-03.txt. Perhaps you mean
bibliographic citations, such as where we cite [FIPS-46] and
[Tuchman79]?
As far as figures are concerned, there is a single figure depicting the
DES-EDE3-CBC algorithm on page 8 which appears to have originated from
your 3DES document. If the above text in the Acknowledgements section
thanking the editors of the previous ESP 3DES documents is not
sufficient, please advise me as to what text you would prefer to see in
the Acknowledgements section.
- Ted
Follow-Ups: