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

RE: notes from developer's portion of IETF meeting

Thank you Hugo, Dan, and Hilarie for stating clearly why the group at the IETF chose
to make integrity mandatory.   Btw, Dan, I think you're correct in stating why we are still
having this discussion and where it came from in the first place..

At any rate, if MAC is optional for ESP, I think you'll be seeing a lot of implementations
that don't allow the negotiation of a MACless ESP, or force policy to include a MAC algorithm
with any ESP policy... %)  

As for optional encryption...  I still think, if you don't want encryption you should use AH.
I don't really buy the argument that processing the headers takes that more processing time.
Table 18.2 in Applied Cryptography, Second Edition, says that MD5 will do 174 Mbytes a second
on a 33MHz 486SX...  so that means that your average 1500 byte packet, assuming 1/3 is 
headers (being very conservative) would...  oh well, you can do the math... Looks like it doesn't
add a noticable overhead per packet to me... And probably over the course of the exchange will
get lost in the noise... 
	
So, can we agree?   

Optional integrity for ESP?  No.?  yes...?   I'd say no.
Optional confidentiality for ESP?   I'd also say no. 

How 'bout other people?

-Rob

----------
From: 	Hilarie Orman[SMTP:ho@earth.hpc.org]
Sent: 	Wednesday, April 23, 1997 10:00 AM
To: 	ipsec@tis.com
Subject: 	Re: notes from developer's portion of IETF meeting

Block ciphers like DES without integrity are intensely vulnerable to
active attacks, for any kind of machine, and in more ways than have
been described on this list.  Block splicing based on captured
ciphertext with known plaintext allows the attacker great latitude for
inserting bogus traffic with only minimal integrity violations.  The
last block attack shows how you can use this general technique even
without knowing all the plaintext, and traffic modification poses yet
another problem.  Weak integrity checks in the application are an
illusionary defense.

I'd thought the goal of the group was to protect the Internet
environment, i.e. an active attack environment.  Thus, it seems to me
that leaving integrity as an administrator option is contrary to the
charter of the group.

The conditions for safely dispensing with integrity are very narrow,
i.e. one of

	1. Physical impossibility of active attacks (NB analysis must be
	   end-to-end)
	2. Encryption method has strong internal integrity (not DES)
	3. Connection limited to use by applications with strong
	   internal integrity
	4. Attacker can never know or guess ciphertext/plaintext pairs
	   from observed traffic

I am hesitant to leave this analysis to the system administrator; item
1 might arguably be an administrator decision, being highly
environmental, but are these environments of concern to the Internet?

Depending on implementations, the ratio of MD5 speed to DES speed can
be between 3 to 1 and 10 to 1*, according to my notes, so integrity
should not be eliminated based on performance considerations.
However, the time to transmit 128 bytes on a slow connection is
considerable and especially annoying if the data is shorter than the
checksum, so that I can well understand the reluctance to include the
it.  Nonetheless, it seems very unlikely to me that a risk analysis
would show that elimination of integrity was a winning trade-off, even
at low speeds.

Hilarie

* ratios reported outside this range may depend on cache effects or
  byte reordering subtleties
Follow-Ups: