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

Re: eliminate AH -- unanimous

I'm going to break some of my rules here.

	 Ahh, and it's messages like these that remind me what a true joy it has
	 been to discuss things with the cryptologic community.  If you bring two
	 of them together, you get 4 opinions; 3 of them yield 9, etc.
	 
	 In this case, we cannot even get a consistent conclusion from the same
	 person in different weeks....

Bill, if you know any way to produce instant solutions to problems, I'd
love to know it.  I can't do that.  What I can do is to continue to work
on the problem.  In this case, as you noted, I said in so many words that
it took me a while to come up with it:
	 
	 > 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.

Two or three years ago, it was decided that we should have both AH and ESP.
In the aftermath of my recent notes, several people have pointed out to
me that my latest posting, showing a difference between AH and null ESP,
was in fact old news -- it was the original rationale.  Great -- that
means that the correct analysis was done, and that I had forgotten it,
and that others had either forgotten it or simply declined to post.  (Why
anyone would be shy about posting to this list is beyond me...)  It's
a sure sign that the working group has gone on too long when we no longer
remember why we did certain things.

Two years ago, I (among others) objected to the design of AH, for good
and sufficient reason.  Mind you, I wasn't objecting to the concept back
then, but rather, to the details of the MAC computation.  Now, Kent
has proposed an ESP variant that satisfies those objections of mine, but
doesn't preserve the context-free discard ability.  (I should note that
several people have also pointed out that the current AH spec protects
the IPSO information.  My religion dictates that security labels are
bound to the SPI -- see Pirke Machshavim Tovim 0x1234:2^56 for the
detailed exposition of this by Rebbitzen DES -- so I don't care about
that property.)

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.

As best I can tell, export controls are a red herring here, btw.

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.

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.

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

*I'm perfectly content with any of these choices.  I don't give a rat's
ass which is picked; all of them are (to my knowledge) secure, and
since I'm not implementing anything these days the ugliness of some of
the choices is purely esthetic.  They'll all work.  I want this spec
finished, and the group disbanded.*