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

Re: Derived versus Explicit IV

> From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
>                  ....  RFC-1829 implementations are allowed to pick
> random IV's --- it doesn't specify how the IV's are picked at all.  If
> they do so, they won't be complaint with the latest ESP, because that
> field is where the sequence number goes, which must be a sequentially
> incrementing field starting at zero.
>
That latter analysis is not correct.

For manual keys, the sequence number starts at a random number.  There
is no anti-replay requirement, but the random start provides a small
degree of protection through unpredicatability.

For automated keys, the sequence number starts at one (not zero).

Historically, RFC-1829 was based on swIPe, which had a sequence number.

The extra 64-bit explicit IV was mandated by the current WG chair.  It
ruined word alignment for IPv6.  It was not requested by any person in
the WG.

The authors were not happy about this, but agreed to add the option to
get the publication out the door.  You can draw your own conclusions as
to the motivation of that WG chair.

The stated rationale was that it was needed for backward compatibility
with existing hardware manufacturers.  A straw poll on the list found no
such existing implementations.  A survey of actual vendors at SWAN and
ANX workshops have found no such vendors.  QED.

Thus, in the olden days, we "bent over backwards" to assist backwards
compatibility.  Doing that has lead to persons claiming that because
we had an explicit IV as an option, the new drafts need an explicit IV
as well.  Give them an inch, they take a yard.

Yet, the proposed explicit IV is _not_ backward compatible with deployed
RFC-1829, as noted by several on this list.  So, those advocating an
explicit IV are contradicting themselves.  Suddenly, we need no backward
compatibility.

I do not find the argument of those arguing against backward
compatibility compelling.


> We made changes to the ESP protocol --- by adding a sequence number
> field, and adding an authenticator --- to improve ESP's security.  The
> old ESP was flawed; we fixed it.  Sometimes such fixes imply
> incompatible changes.  Life's rough sometimes.
>
As noted many times before, all we did was move around existing fields
in their documents.  The sequence number was there in swIPe, and it was
there in RFC-1829 and RFC-1851, and it has been moved (as a common field)
back into the main ESP base.  There was no "fix".

The only change is removing an unneeded explicit IV.  Removing
unnecessary options is a common practice when proceeding from Proposed
to Draft Standard.

As noted many times before, we already can provide authentication via
AH.  The Bellovin splicing attack was duly referenced in RFC-1829, which
noted the need for authentication/integrity in _certain_ scenarios.

The authenticator does not improve security over AH.  The only reason
for adding the authenticator field is to save 8 bytes of AH header.

Adding an explicit IV wastes those 8 bytes.

I conclude that there are no vendors needing this capability for any
technical reason.

I perceive that those persons asking for this capability are vendors
that have no deployed product, and can only conclude that they are
trying to use the WG consensus process to "level the playing field" and
give their new products an equal opportunity against other vendors.

I reject the claims of such vendors.

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
Follow-Ups: