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

Re: draft-simpson-esp-des1-v2-00.txt to Draft Standard



> From: Steven Bellovin <smb@research.att.com>
> I'm afraid I disagree; this document is not ready for advancement.
> First, it's the wrong document.  Given the new structure (i.e., as
> described in draft-ietf-ipsec-new-esp-00.txt), there's far too much
> in your draft. The CAST-128 draft (draft-ietf-ipsec-esp-cast-128-cbc-00.txt)
> or RC5-CBC draft (draft-ietf-ipsec-esp-rc5-cbc-00.txt) are much better
> models for what's needed.

Thanks for reading the document.  Funny, Steve Kent sent a private
message saying almost the same thing.

I looked at those (CAST & RC5), and found them remarkably uninformative.
I cannot imagine a "protocol" description without packet formats.  They
should put some packet formats in!

I did move the weak key text from the security considerations up to the
key sub-section to match them, though.  Keeping related stuff like that
together was a good idea.


> (Bill, I realize you feel differently.  I
> don't like documents that overspecify stuff -- changes to the base
> document's headers would require changes to your document as well,
> quite unnecessarily.)
>
Changes to the base document headers would be a new protocol, and
require a new IP Protocol number!

Even "new" ESP is still just an SPI (the same as "old" ESP), with a
32-bit Sequence Number (which was one of the options in RFC-1829 and
long described in swIPe).  The only true change in "new" ESP is the
requirement of the sequence field in all transforms, and adding an
optional trailing Authenticator.  That's all I've done here, update to
match the "new" ESP environment.

Can anyone imagine ICMP documents with the packet formats only starting
after the Checksum field?  Nope.  The IETF tradition is to copy those
definitions for context.  True, it is boilerplate, but it certainly aids
the implementor by providing context.

Besides, the IV is calculated based on the SPI+Sequence fields.  Showing
them is pretty helpful to implementors.

   As an aside, I once tried putting the Photuris Cookies in only a
   single place, early in the _same_ document.  After all, they are just
   the same boilerplate repeated over and over.  Suddenly, the most
   frequently asked question was "where are the Cookies"?

   So, I still have that section describing the Cookies, but I also
   faithfully copy them into each packet format.  It was only a little
   extra work, but it saved a lot of explanation in the long run....

I don't like _under_ specifying stuff.  Each transform should stand on
its own!


> Second, given the new structure -- with authentication folded in with
> ESP -- I don't know of any implementations.  I suppose one could say
> that the DES-CBC part is ready, but it's a bit hard to assess without
> the framework.
>
The Authenticator is an optional field.  Its specification and testing
are outside the scope of DES-CBC.  We don't test frameworks, we test
protocols.  Again, each transform should stand on its own!

Besides, there are plenty of folks who have tested AH+ESP.  Seems to
work pretty well....

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