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

Re: calculating IVs

>It was the second compromise method.  It is a little stronger than the
>first compromise reached over 2 years ago, described in RFC-1829 and
>RFC-1851.  One of the problems with this group is no decision stands for
>more than a year.  And everything has to be explained all over again to
>each new person, such as yourself.

If all the "shim" ESP drafts hadd agreed on a signle common IV, I
wouldn't have asked.  But there was a difference and (as an implementor)
I wanted to know why (I'd rather have one common method for all the
ciphers, if possible).  

Would it not be best then to either include text on how generate an IV
in the ESP draft and allow the "shim" drafts to override it?  Or define
it in a separate draft RFC and let each "shim" reference it?  It does
seem unwise to duplicate this in each "shim" RFC.

>The "best" method would be to key DES-OFB over SPI+Sequence and use that
>for the IV.  Easy in software, but the hardware manufacturers griped
>that would cause 2 chip invocations, and slow down their implementations.
>However, since then it has appeared that the "best" method can be done
>with 1 invocation in CBC mode, and then replace the generated ciphertext
>in the packet with the original SPI+Sequence.  Simple.  Elegant.
>I would be willing to change.  Ask the vendors that implemented RFC-1851
>if they would be willing to change....

Since we seem to be doing our best to be incompatible with RFC 1851,
why do we care?  As much as I hate suggesting this, make it negotiable
(with the default being the same as the current behavior).  If it is
really more secure (or better), those that can do it will.
Matt Thomas                    Internet:   matt.thomas@altavista-software.com
Internet Locksmith             WWW URL:    <coming eventually>
AltaVista Internet Software    Disclaimer: This message reflects my own
Littleton, MA                              warped views, etc.