Re: response to Last Call on: IP Authentication using Keyed MD5
"Perry E. Metzger" <perry@imsi.com> Tue, 27 June 1995 02:07 UTC
Received: from interlock.ans.net by nis.ans.net with SMTP id AA05459 (5.65c/IDA-1.4.4 for <archive-ipsec@nis.ans.net>); Mon, 26 Jun 1995 22:07:34 -0400
Received: by interlock.ans.net id AA50995 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 26 Jun 1995 22:00:55 -0400
Message-Id: <199506270200.AA50995@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-4); Mon, 26 Jun 1995 22:00:55 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 26 Jun 1995 22:00:55 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 26 Jun 1995 22:00:55 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 26 Jun 1995 22:00:55 -0400
To: hugo@watson.ibm.com
Cc: ipsec@ans.net, iesg@cnri.reston.va.us, PAULV@BNR.CA
Subject: Re: response to Last Call on: IP Authentication using Keyed MD5
In-Reply-To: Your message of "Mon, 26 Jun 1995 20:22:51 EDT." <199506270121.AA40361@interlock.ans.net>
Reply-To: perry@imsi.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 26 Jun 1995 22:00:48 -0400
From: "Perry E. Metzger" <perry@imsi.com>
To be very clear here, I'm speaking (as usual) for Perry Metzger -- not for my co-authors, just for me. These are *my* views. Take them as such. hugo@watson.ibm.com writes: > The document: draft-ietf-ipsec-ah-md5-03.txt > presents what is supposed to become the "must to implement" message > authentication function for IPSP and IPv6. The authors of that document > have ignored past recommendations I made to this group regarding > the choice of this function. I'd say that "ignored" is too strong a statement. "Felt exhausted by the battles over the authentication transform and were too desultory about making changes to the document because we were utterly and completely burned out" is perhaps a much more accurate statement. We were sort of depending on people to come up with specific language to insert. There being none mentioned, things slouched towards last call. I'm happy to see the suggestions you made adopted in this round, *PROVIDED* that my co-authors don't object (big provisio) and that the incorporation of your suggestions does not substantially delay the adoption of the document (another big provisio). This has been a draft for some time, and has been in last call for some time -- you did have an opportunity to make objections a long time ago. This is not to say that I don't want the technically best solution adopted, but it is to say that I'm more willing to try to make the changes when the documents move the next notch up the standardization process than I am to let these documents, which should have been out literally years ago, get delayed any longer. The architecture we have adopted permits open addition of new security transforms and it will be a simple matter to make your transform a new one in the suite and to mandate its implementation instead of the the existing MD5 transform in the next round of standardization. The IETF process is very forgiving in this regard. I'd like to say that had your results on this topic in cryptography not been informally discussed in Danvers and had I not enormous (that is to say, overwhelming) respect for you, Hugo, I would be of a mind to work to have your objections tossed out right now because of how ill timed they are. You should have been pressing us with specific language to insert into the drafts two months ago. As it is because I am forced to admit that you know far more about the technical merits of one signed hash method over another than almost anyone else around I feel like we have to bend over backwards to try to accomodate your ideas -- but PLEASE DONT EVER DO THIS AGAIN! Next time, please bring this all up earlier, and be mindful of the fact that the earlier set of working group last calls were in place specifically to remind you to jog our memory about such things. Also remember that this is just the first move towards standardization and that there are plenty of more opportunities to make this sort of technical correction as we move forward. > Hugo (Krawczyk) Perry
- response to Last Call on: IP Authentication using… hugo
- Re: response to Last Call on: IP Authentication u… Perry E. Metzger
- Re: response to Last Call on: IP Authentication u… Hilarie Orman