A comment from the co-chair
Ran Atkinson <rja@cisco.com> Wed, 13 March 1996 20:09 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21551; 13 Mar 96 15:09 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21547; 13 Mar 96 15:09 EST
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa12514; 13 Mar 96 15:09 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa17617; 13 Mar 96 14:50 EST
Received: from relay.tis.com by neptune.TIS.COM id aa17593; 13 Mar 96 14:44 EST
Received: by relay.tis.com; id OAA23262; Wed, 13 Mar 1996 14:46:14 -0500
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma023254; Wed, 13 Mar 96 14:45:47 -0500
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA13082; Wed, 13 Mar 96 14:44:45 EST
Received: by relay.tis.com; id OAA23244; Wed, 13 Mar 1996 14:45:44 -0500
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1) id xma023240; Wed, 13 Mar 96 14:45:43 -0500
Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id LAA07737; Wed, 13 Mar 1996 11:46:48 -0800
Date: Wed, 13 Mar 1996 11:46:48 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199603131946.LAA07737@puli.cisco.com>
To: ipsec@tis.com
Subject: A comment from the co-chair
X-Orig-Sender: ipsec-request@neptune.tis.com
Precedence: bulk
All, The misrepresentations in the notes below are unproductive and unwarranted. The ongoing personal attacks on the chairs and other members of the WG from Bill Simpson are not acceptable behavior in this or any other IETF WG. In future, notes that contain personal attacks will be ignored in toto by the chairs. If Bill keeps up his current behavior, we suggest putting all incoming mail from Bill into /dev/null using a kill file or other similar mechanism. We suggest that others on the list ignore the entire contents of all notes containing personal attacks and simply don't respond to them or their author. It is entirely unproductive to focus on perceptions of history. Instead the discussions should focus on the technical issues before us so that forward progress can be made. Discussions about history, who said what when to whom and so on cannot be objectively confirmed and only cause confusion, contention and divisiveness. They are not productive. As to what Ran has said or what Ran believes, Bill's assertions are quite false. Ran is fairly confused as to how Bill came to his misperception of the facts. Ran's comments quoted below about the inappropriateness of Bill's draft to alter the AH specification clearly indicates that it is a problem of scoping. AH/ESP specification changes MUST NOT be attempted by any key management proposal. Rather, the key management proposals MUST conform to the AH/ESP specs. If the WG later decides to modify the AH/ESP specs at some time, then the key management specs can be correspondingly modified at that future time. The WG chairs understand from the LA IETF meeting that keyed integrity on the protected data of the ESP header is part of the mandatory ESP transform. Similarly, it is our understanding that implementation of support for replay protection as part of ESP is mandatory. Finally, understanding that WG consensus is that the RFC-1829 transform should be obsoleted on the standards track by a new ESP transform. The new transform will have a new transform identifier so as to avoid confusion with RFC-1829. The WG chairs have assigned the Document Editor position for that new ESP transform to Jim Hughes. The new transform will correct these deficiencies in RFC-1829. Once that new transform moves to Proposed Standard, RFC-1829 will move to HISTORIC status and leave the standards track. RFC-1825 through RFC-1828 are not yet able to be considered for advancement to Draft Standard under IETF rules because of the cross dependencies among each other and with the ESP transform. They can be considered for advancement once the new ESP transform has been at Proposed Standard for 6 months and has at least 2 interoperable implementations. As none of the current Key Management proposals currently meet WG requirements (though all could be modified to meet WG requirements), none can proceed to Last Call or onto the Standards Track at this time. It is the prerogative of Working Group Chairs to decide who may edit documents for their working group. Bill Simpson's behavior is incompatible with the requirements of Document Editor for documents to be considered by the IPSEC Working Group for the IETF Standards Track. Documents edited by Bill will not be considered by the Chairs for consideration in the IPSEC Working Group. This does not preclude others from listing Bill as co-author on documents in which he has made significant technical contributions. Randall Atkinson rja@inet.org Co-Chair, IP Security WG PS: Any complaints about this note should be directed at the Security AD, Jeff Schiller <jis@mit.edu>. [Quoted notes follow] ---------------------------------------------------------------------- From: wsimpson@greendragon.com (William Allen Simpson) To: ipsec@TIS.COM Subject: AH and ESP Orthogonality Message-ID: <5041.wsimpson@greendragon.com> Date: 11 Mar 96 22:07:45 GMT For the past several years, this WG (and others such as SIP, SIPP, and IPng, and other protocol designers such as SSL) strongly supported orthogonality between the Authentication and Encapsulation (both privacy and compression) facilities. Recently, the WG chairs (without any stimulating WG comments) have tried to move the WG toward a non-orthogonal all-in-one approach for ESP. Last week, Ran Atkinson stood at the microphone, and stated (without elaboration) that his previous support for an orthogonal approach was "a serious mistake". I ask, what was the mistake? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ---------------------------------------------------------------------- From: wsimpson@greendragon.com (William Allen Simpson) To: ipsec@TIS.COM Subject: Re: Alternative transform encapsulation scheme Message-ID: <5040.wsimpson@greendragon.com> Date: 11 Mar 96 21:42:41 GMT Lines: 43 > From: smb@research.att.com > Date: Sat, 09 Mar 96 14:48:32 EST > > There's a lot that needs to be rethought. I could quite easily be > persuaded that we shouldn't -- we've got to get this stuff > deployed ASAP. I'm with Bellovin on this. I don't think we need a non-orthogonal transform (even though I've written a draft). The deployed AH-MD5 + ESP-DES is adequate. > that we should simply decree that ESP > must be used only in conjunction with AH We already did, when the ESP transform doesn't provide integrity!!! In addition to the numerous references in RFC-1825, -1826, and -1827, RFC-1829 (ESP-DES) clearly states: The usual (ICMP, TCP, UDP) transport checksum can detect this attack, but on its own is not considered cryptographically strong. In this situation, user or connection oriented integrity checking is needed [RFC-1826]. And you promised to write up a more thorough analysis of your attack.... > One small change -- the addition of replay protection -- > does seem to be needed, though. > Why? Doesn't the underlying transport _already_ protect against replay? That is, TCP and ICMP already protect themselves against replay. So, you are recommending that the next version of -1826 provide a replay prevention mechanism? We've discussed this before, but Atkinson was opposed. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ---------------------------------------------------------------------- From: wsimpson@greendragon.com (William Allen Simpson) To: ipsec@TIS.COM Subject: Re: AH and ESP Orthogonality Message-ID: <5044.wsimpson@greendragon.com> Date: 12 Mar 96 00:26:58 GMT Lines: 33 > From: smb@research.att.com > We therefore have a situation where ESP must be used in conjunction with > AH, and no document saying so. Hmmm, perhaps I am mistaken, but as I have already quoted the "documents saying so" in a previous message, do I need to quote them again? Why do you think that the documents don't say so? Is there a suggestion you could make to improve the text? > Worse yet, we're paying the overhead > price for a new header twice. > True. That was the tradeoff for orthogonality. It was 8 bytes for AH. But, if we also require AH for message origin authentication, while ESP provides integrity, we haven't saved anything. As noted by Bob Baldwin last week, we have a bigger hit for processing costs, too. So, which do you prefer? 33% slower processing??? Look folks, we discussed this all last year. We knew about the cut and paste attack before we wrote the documents. We referenced the Bellovin presentation in the documents. The "mistake" that Atkinson made MUST be something else that we didn't already know about. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ---------------------------------------------------------------------- From: wsimpson@greendragon.com (William Allen Simpson) To: ipsec@TIS.COM Newsgroups: cisco.external.ietf.ipsec Subject: Re: AH and ESP Orthogonality Message-ID: <5048.wsimpson@greendragon.com> Date: 12 Mar 96 13:25:54 GMT Lines: 45 > From: "Perry E. Metzger" <perry@piermont.com> > William Allen Simpson writes: > > Look folks, we discussed this all last year. We knew about the cut and > > paste attack before we wrote the documents. > > Actually, we didn't during the initial drafts, Ah, Perry, but I beg to differ. We knew about general cut and paste against CBC _long_ before we wrote the drafts. It is a "feature" of CBC itself. Atkinson always had words in his drafts about the need for integrity. There was always a strong consensus for providing integrity. Bellovin merely described a specific scenario last April where cut and paste was a problem, and integrity was required. We added words to that effect to our documents. > and we were discussing > combined transforms as long ago as Toronto, though we didn't envision > making them mandatory at the time. > Yes, we were! And we _decided_ as a WG _not_ to use them, that orthogonality was better! > Anyway, lets just consider the situation on its current technical > merits, and not try to figure out who said what when... > My point is that we are rehashing old arguments, and undermining the good work and deployment that this WG generated. There has been no demonstrated need to eliminate orthogonality, and worse, it has been shown to be computationally problematic. What is the NEW attack, that we had not previously considered, that would require a removal of orthogonality? What was Atkinson's "serious mistake"? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ---------------------------------------------------------------------- From: wsimpson@greendragon.com (William Allen Simpson) To: ipsec@TIS.COM Newsgroups: cisco.external.ietf.ipsec Subject: Re: AH and ESP Orthogonality Message-ID: <5053.wsimpson@greendragon.com> Date: 12 Mar 96 18:15:56 GMT Lines: 67 > From: Stephen Kent <kent@bbn.com> > Having orthogonal transformations was not necessarily a bad idea, > but there are benefits to having a better division of responsibility > between AH and ESP. I agree. > For example, the current definition of AH is messy > because either AH covers the entirity of an IP datagram (minus mutuable IP > header fields) or it covers just upper layer protocols. The distinction is > a function of where AH appears relative to ESP. Several of us would prefer > a verison of AH that applied to the whole datagram (as described above), > period. > I understand. You raised this last year. But, other analysts prefered the AH "inside" ESP approach. So, there was no agreement. Instead, a flexible mechanism was defined, and the orthogonality allowed both approaches. Indeed, the chairs dictated to Jim Hughes in his DES+MD5 draft that the MD5 apply to the "inside" plaintext, rather than the "outside" ciphertext. There were objections raised from the WG, such as Karn. Outside allows detection of modification sooner, rather than after DES. As you may remember, I'm an "outy" myself. > It might be preferable if ESP defined > optional, variable length fields for carrying the necessary data to support > confidentiality and authentication and integrity. The specific fields used > for a given SA would be defined at SA establishment, nailing this down for > efficient per-packet processing. The result would be to make transform > definition documents more modular. > The result would be to make the transform documents much more difficult to understand and implement. The WG rejected the variable fields approach yet _again_ last week. Instead, we nail down the specific _transforms_ at SA establishment. Same result, easier to implement, easier to verify. > Several folks, including yours truly, have expressed a desire to > add an anti-replay feature into the IPSEC suite. This could be useful in > either AH or ESP, or both. I'm included in that "several folks". We discussed this last year, and again in January of this year. It's in our latest ESP revision, and in Photuris Extensions. But, as you may remember Atkinson's message: Date: Thu, 22 Feb 1996 12:29:13 -0800 Message-Id: <199602222029.MAA00276@puli.cisco.com> 5) Section 2.11 of draft-ietf-ipsec-photuris-ext-01.txt MUST be deleted. It is WAY outside the scope of Bill's draft to modify any standards track protocol and the attempt to do so is more than sufficient grounds to bar publication as ANY kind of RFC until that section is deleted. So, the chairs are rather vehemently against adding replay protection, even as a negotiated option. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 ----------------------------------------------------------------------
- A comment from the co-chair Ran Atkinson
- Re: A comment from the co-chair Robert Moskowitz