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

Re: ESP revisions straw poll

	 In message <3.0.32.19970521113228.00890250@127.0.0.1>, "Steven M. Bell
	ovin" wri
	 tes:
	 >
	 >Both, actually.  Encryptionless ESP is the way AH should have been de
	signed.
	 >(I objected to the current scheme at least as far back as Stockholm.)
	  But
	 >yes, I'm tired of arguing.  I'll settle for something that's ugly, le
	ss
	 >efficient, and unclean if it's here *now*...
	 
	 Several people have mentioned that what the AH computation
	 covers could be negotiated (wether it's the current scheme or
	 just hte payload) by the key management layer. I don't think
	 there would be many objections to that.

Well, count at least one...  We should try very hard not to add extra
complexity.  My objection to the current AH specification is that it is
complex to implement.  Adding a negotiated variant would just add to
the complexity.  Besides, each variant would need to be analyzed for
safety.

Hmm -- we could make the scope of the authentication programmable.

	AH-scope: {
		bytes=1-5 byte-order=network bits=2-4 bit-order=intel base=ip
		bytes=7-8 byte-order=ibm bits=* base=udp
		bytes=* base=ip-options filter=java::ip_optionfilt(type,len)
	}

Never mind, I'm feeling grouchy this morning...  Let me be a bit more
blunt than usual.

	*) I don't like complexity.  Apart from the esthetics -- and
	those are important -- complex structures are buggy.
	Cryptographic protocols are *hard* to get right; the more of
	them we have, the less assurance we have that any of them
	individually are correct.  More to the point, we have no
	assurance that arbitrary combinations are correct.  We've
	already seen that the order of AH and ESP can be important (for
	example, against short-block guessing attacks).

	*) I don't like complex code.  It's likely to be buggy.

	*) I don't like unnecessary multiplication of mechanism.  This
	is especially true when there's no clear guidance -- especially
	guidance amenable to programmed decisions -- about when to use
	which variant.  In this particular case, someone has suggested
	negotiating what AH covers.  What is the basis for making the
	decision?

	*) I don't like mutating protocols.  The problem with AH is
	that some fields are sometimes modified in transit.  This is
	not under control of the end systems.  In fact, it's rarely
	knowable to the users of the end systems, since they don't
	control what happens in the network cloud.  The solution, such
	as it is, was to decree that certain fields have to be zeroed
	before the MAC computation.  Leaving out the layering violation
	(see the point about code complexity above), in the 21 months
	since RFC 1826 the network cloud has changed its behavior.
	Section 3.2.3.1.1 of the Kent/Atkinson AH draft notes (with
	appropriate snideness) that the TOS field should now be zeroed,
	too, since some router vendors have chosen to violate RFC 791
	and diddle those bits.  And it's going to get worse -- see
	Section 3.2.3.1.2 for examples of what I mean.

	*) I don't like layering violations.  AH requires that the IP
	header be calculated first, then AH called to fill in data that
	follows the IP header.

	*) I don't like meaningless cryptography.  Almost two years
	ago, I posted a field-by-field analysis.  I showed that the IP
	header fields are either irrelevant for security purposes,
	changed en route (and hence not protectable), or are or should
	be bound to the security association, and hence need not be
	authenticated on a per-packet basis.

That's all well and good.  It's also irrelevant -- others disagreed
with me, for good and sufficient reason, and their arguments (and
needs) carried the day.  I've kept quiet about the issue since then,
because I have another dislike:

	*) I don't like working groups that drag on forever,
	fine-tuning a protocol to the point of irrelevancy.  Folks,
	we're under a deadline.  There are real products out there that
	implement some version of IPSEC.  There are things like PPTP
	that also include authentication and encryption.  We need to
	finish *now*.

The only reason we're discussing this again is because we realized that
encryption almost always requires authentication.  This may not be
sufficient reason to reopen the question, especially given the
immediately preceeding point.  But yes, in an ideal world I'd opt
for a clean AH, aka encryptionless ESP.

		--Steve Bellovin