Re: draft-simpson-esp-des1-v2-00.txt to Draft Standard
Bob Monsour <rmonsour@earthlink.net> Sat, 24 May 1997 07:54 UTC
Received: from cnri by ietf.org id aa03593; 24 May 97 3:54 EDT
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa02713; 24 May 97 3:54 EDT
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA00061 for ipsec-outgoing; Sat, 24 May 1997 03:39:38 -0400 (EDT)
Message-Id: <3.0.32.19970524004450.00b0d490@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sat, 24 May 1997 00:44:54 -0700
To: William Allen Simpson <wsimpson@greendragon.com>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: draft-simpson-esp-des1-v2-00.txt to Draft Standard
Cc: Steven Bellovin <smb@research.att.com>, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bill, While the wg and doc editors have been struggling to get the document structure "cleaned up", I respectfully submit that the two drafts you recently submitted appear to subvert that effort. In what is being refered to as the "new" ESP draft (draft-ietf-ipsec-new-esp-00.txt), the 2nd paragraph of section 3.2.3.2, Encryption Algorithms, states: At the time of writing, one mandatory-to-implement encryption algorithm and mode has been defined for ESP. It is based on the Data Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode [NIST80]. Details of use of this mode are contained in [need a new I-D with DES-CBC and implicit IV generation, but no overlap with this document]. The operative phrase is "but no overlap with this document". While I understand that you believe that it's important for the algorithm/transform documents to repeat certain field definitions from the base ESP document, in this case I find it couter-productive and prone to inducing errors. Let's take an example from from your DES draft (draft-simpson-esp-des1-v2-00.txt) and compare it to the "new" ESP draft and RFC1829. It states: Padding zero or more octets. Prior to encryption, this field is filled with a series of integer values (beginning with zero), to align the Pad Length and Payload Type fields at the end of an eight octet boundary (counted from the beginning of the Payload Data). After decryption, it is examined for a valid series of integer values. This field is opaque. That is, the value is set prior to encryption, and is examined only after decryption. In the "new" ESP draft (section 2.5) padding is defined as follows: The Padding bytes SHOULD be initialized with random data and they are transmitted. The transmitter can add 0-255 bytes of padding. Padding beyond that required for encryption algorithm blocksize alignment may be used to conceal the actual length of the payload, in support of traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. The Padding field is optional, but all implementations MUST support generation and consumption of padding. Lastly, RFC1829 states: Padding The size of this field is variable. Prior to encryption, it is filled with unspecified implementation dependent (preferably random) values, to align the Pad Length and Payload Type fields at an eight octet boundary. After decryption, it MUST be ignored. I don't understand how someone can write code to support the padding requirements that conform to RFC1829 or the "new" ESP and find that it will interoperate with code that is written to follow your new draft. An RFC1829 programmer will send the "preferably random" values in for padding and the implementor of your new draft will reject the incoming packet for lack of a "valid series of integer values". While you don't say exactly what to do in this case, it certainly leaves room for various interpretations (read that as potential interoperability problems). Would it not have been simple to create a draft that really matched the goal of matching the intentions of the "new" ESP draft and the wg? That would have been a great service to the wg. At 03:27 AM 5/24/97 GMT, William Allen Simpson wrote: >I looked at those (CAST & RC5), and found them remarkably uninformative. >I cannot imagine a "protocol" description without packet formats. They >should put some packet formats in! I see these as algorithm/transform definitions, not protocols. They define how to take a set of data and transform it into another set of data. The context is, as stated simply and elegantly in the abstracts of the RC5 and CAST drafts (and these are the only words in the abstracts): This draft describes the CAST-128 block cipher algorithm as to be used with the IPSec Encapsulating Security Payload (ESP). This draft describes the RC5 block cipher algorithm as to be used with the IPSec Encapsulating Security Payload (ESP). (OK, so they share an author) >The only true change in "new" ESP is the >requirement of the sequence field in all transforms, and adding an >optional trailing Authenticator. That's all I've done here, update to >match the "new" ESP environment. Not so. The move to the "new" ESP environment involved a conscious document structure change, not just the protocol changes you mentioned. That structure change is intended to simplify the specifications by eliminating reduntant and potentially conflicting requirements (i.e., factoring out the common elements of the packet formats and leaving the transform docs to specify algorithmic details). >I don't like _under_ specifying stuff. Each transform should stand on >its own! B relating the transform drafts back to the base ESP draft (as you do and the RC5/CAST drafts do), then they DO stand on their own as separable transforms that support the packet formats as defined in ESP. They MUST be read AND used in conjunction with ESP and ONLY in conjunction with ESP. If you REALLY want them to stand on their own in the context of all the working groups, then I would go further to say that they should just describe the algorithms and not refer to any base packet formats. In that way they could be referenced by any base protocol spec such as TLS or ECP by way of IANA numbers. But in my relatively short IETF life, I wouldn't expect to see that happen at this stage and would be grateful to fulfill the intentions of the wg and the ESP draft (and for this purpose, we have the IPSec DOI). [To the doc editors and co-chairs, if no one is preparing drafts of DES and 3DES for use with the "new" ESP (similar in construct to the RC5 and CAST drafts), I volunteer to take on the task as long as I get some volunteers to review them prior to posting to double-check them.] Regards, Bob Monsour rmonsour@hifn.com
- draft-simpson-esp-des1-v2-00.txt to Draft Standard William Allen Simpson
- Re: draft-simpson-esp-des1-v2-00.txt to Draft Sta… Steven Bellovin
- Re: draft-simpson-esp-des1-v2-00.txt to Draft Sta… William Allen Simpson
- Re: draft-simpson-esp-des1-v2-00.txt to Draft Sta… Bob Monsour
- draft-simpson-esp-des3-x-01.txt Matt Thomas