[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AH versus ESP -- no longer unanimous
> From: Steven Bellovin <smb@research.att.com>
> > Ever since Bill posted his straw poll, I've been bothered by an
> > intuitive feeling that AH and encryptionless ESP were not equivalent
>
> So -- what shall we do? Shall we defer any solution until everyone agrees
> to do no more thinking about the problem? Perhaps only researchers who
> agree to take such an oath are allowed to work on it? I, at least, will
> admit my own mistakes when I recognize them.
>
It did not appear to me to be worded as the admission of a mistake. It
appeared to be waffling, after a claim that the topic had been completely
considered over a period of 2 years. Apology accepted.
> We have the following choices:
>
> a) Keep AH the way it's been; permit encryptionless ESP.
>
> b) Keep AH the way it's been; ban encryptionless ESP.
>
> c) Discard AH; use encryptionless ESP only.
>
> d) Redefine AH so that it has the semantics of encryptionless
> ESP. Use either a flag bit in the header or a separate protocol
> number to distinguish this case, to preserve the context-
> free knowledge that no encryption has been used.
>
> So -- in an ideal world, I'd pick (d), as indeed I did two years ago.
> But that choice was rejected by the group, and I'm content with that
> decision. There is no new data, and I see no reason to reopen the
> question -- that I "lost" is manifestly insufficient.
>
Agreed.
Also, as you may remember, I have previously noted that it is impossible
to prevent (a), even by a mandate, as a "null" encryption transform
could be publically or privately implemented.
> You now suggest (c). We lose certain abilities, and in particular we
> lose the same abilities that caused (d) to be rejected two years ago.
>
Actually, the poll was because (b) was rejected by the document editor,
despite the group decision in its favor at Memphis, and you posted a
long note that appeared to ask for (c).
The list posters unanimously chose (c), until the obvious result was
announced, and then another set of postings repudiated it.
In short, there is a fundamental disagreement between the implementors
and the researchers on this list preventing this group as a whole from
making final choices -- of virtually anything.
> The choice between (a) and (b) is, for the most part, whether or not
> we include explicit language on the subject in the ESP draft; as has
> been noted, it's easy to write a separate encryptionless shim document.
I think that any explicit language added (that would be the
architecture document covering AH and ESP, not the ESP document itself)
would probably extend the already long period of contention. We have
been arguing for over 2 months.
> I have a modest preference for the separate document approach, since
> otherwise an implementor has to choose between null ESP and AH for
> cleartext connections, without architectural guidance. That is, if
> we're going to provide two different -- but not equivalent -- ways to
> do the same thing, we need to specify when each should be used. But
> if people feel otherwise, I'm not going to waste the electrons (or
> whatever remaining life my wrist tendons have) disagreeing.
>
Please write the "null" encryption transform draft, including thorough
guidance on when to use it. Maybe a concrete specification will end the
arguing, and you can convince someone to implement it.
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