[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: response to Last Call on: IP Authentication using Keyed MD5


Phil Rogaway writes:
> 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.

More properly, you should state that it is your opinion that the
transforms should be independant of use.

> 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,

Many of us are too tired to comment in detail on every idea that comes
forward. I'm still to tired, myself. Hugo has a legitimate point that
his method provides more security, so I'm reluctantly seeing if I can
lobby to do something about them. Your changes were gratuitous and
actually less efficient, so I didn't think of them as being a good idea.

> 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.

"Major technical errors?"

I was an author of that document.  There is already an explicit
reference in the document to the fact that under some circumstances
integrity can be breeched...

               The usual (ICMP, TCP, UDP) transport checksum can detect   |
   this attack, but on its own is not considered cyptographically         |
   strong.  In this situation, user or connection oriented integrity      |
   checking is needed [A-AH].                                             |

and the only other reference to the word "integrity" is in the
introductory sentence which generically describes goals of ESP and not
specific properties of the DES transform.

However, I'm sure in this or a later version of the document a single
sentence could easily be inserted to note that DES alone can't
guarantee integrity. This is hardly the mark of a "major technical
error" in the proposal. At worst it's something that we could say more
redundantly. I don't see that this would justify holding up the
documents, but I'll find out if we could insert a single line to that
effect.

As for counters, assuming that DES does in fact work as advertised,
flipping one bit in the IV should flip, on average, 50% of the output
bits. Do you have evidence that this is insufficient for purposes of
disguising identical initial blocks, which is all an IV does in life?

Perry