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

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