response to Last Call on: IP Authentication using Keyed MD5
Phil Rogaway <rogaway@cs.ust.hk> Thu, 29 June 1995 12:59 UTC
Received: from interlock.ans.net by nis.ans.net with SMTP id AA42815 (5.65c/IDA-1.4.4 for <archive-ipsec@nis.ans.net>); Thu, 29 Jun 1995 08:59:21 -0400
Message-Id: <199506291259.AA42815@nis.ans.net>
Received: by interlock.ans.net id (InterLock SMTP Gateway 3.0 for archive-ipsec@nis.ans.net); Thu, 29 Jun 1995 08:59:20 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Thu, 29 Jun 1995 08:59:20 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 29 Jun 1995 08:59:20 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 29 Jun 1995 08:59:20 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-0); Thu, 29 Jun 1995 08:59:20 -0400
Date: Thu, 29 Jun 1995 16:54:48 +0800
From: Phil Rogaway <rogaway@cs.ust.hk>
To: ipsec@ans.net
Subject: response to Last Call on: IP Authentication using Keyed MD5
Now that it may finally be on the table to do something about draft-ietf-ipsec-ah-md5-03.txt I would like to remind this community that not only should the MAC be defined independent of its intended use, so too should the encryption transform. I did this two months ago (Internet Draft draft-rogaway-cbc-encrypt-00.txt -- the suggested replacement to what is now draft-ietf-ipsec-esp-des-cbc-04.txt). I received 0 (zero) comments on this work, and the revised IPSEC document (draft-ietf-ipsec-esp-des-cbc-04.txt) was non-responsive. This despite the fact that not only is the transform in draft-ietf-ipsec-esp-des-cbc-04.txt intertwined with its use, but its description has at least two major technical errors. These were already pointed out in earlier notes: incorrectly asserting that the mechanism provides integrity, and incorrectly stating that a counter provides as an acceptable IV. Phil Rogaway
- response to Last Call on: IP Authentication using… Phil Rogaway
- Re: response to Last Call on: IP Authentication u… Phil Rogaway