Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt
"Theodore Y. Ts'o" <tytso@MIT.EDU> Wed, 09 September 1998 22:41 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA20628 for ipsec-outgoing; Wed, 9 Sep 1998 18:41:30 -0400 (EDT)
Date: Wed, 09 Sep 1998 18:58:32 -0400
Message-Id: <199809092258.SAA24165@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: William Allen Simpson <wsimpson@greendragon.com>
Cc: ietf@ietf.org, ipsec@tis.com
Reply-To: ipsec@tis.com
In-Reply-To: William Allen Simpson's message of Wed, 9 Sep 98 19:11:01 GMT, <7538.wsimpson@greendragon.com>
Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
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
- I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt Internet-Drafts
- Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt Rodney Thayer
- Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt Theodore Y. Ts'o
- Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt Robert Moskowitz
- Re: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt William Allen Simpson
- RE: I-D ACTION:draft-ietf-ipsec-ciph-cbc-03.txt Roy Pereira