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