Subject: digest-md5: strongly prefer explicit IV in every block

From: [email-masked] (Sam Hartman)
Date: Tue, 16 Mar 2004 18:52:28 -0500 (EST)

I'm looking at the AES CBC cipher in digest-md5.  AS we discussed in
Seoul, there are two approaches under consideration.

I strongly prefer the option that includes an explicit IV in every AES
packet to the option that introduces a new packet type and only
sometimes sends an explicit IV.

There are two claimed advantages to the second approach:

1) Performance.

As I understand it, the performance implication of including the IV is
the cost of generating a 128-bit random number along with the cost of
encrypting one block of AES data.

2)  Simplicity of implementation: implementations could re-use
    existing packet formats.

I don't understand this at all.  It seems like you need to implement
both packet types in all implementations, so the I don't see how it is
simpler.

The advantages of the first approach seem to be security against the
attack that we were trying to defend against.  If an attacker can ever
predict a situation when an explicit IV is not going to be used, then
the attacker can mount the attack.

I do not expect the second approach would pass AD review.

For now, I'd recommend against ignoring the performance concern.  If
there are implementers who are seriously concerned about performance,
then we should consider counter mode instead of the explicit IV
approach.  

--Sam

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Mar 2004 10:53:11 -0500

Sam:

I will not say that the second alternative will not pass AD 
review.  However, it will require justification.  The first alternative is 
the traditional way to do things, so no justification is needed.  There are 
many protocols that employ the first alternative, including IEEE 802.10b, 
IPsec, and S/MIME.  Notice this covers many different layers in the 
protocol stack.

If the working group selects the second alternative, the security 
considerations section MUST state why the first alternative is a poor fit, 
and it MUST state how the second alternative offers the same level of security.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Mar 2004 10:53:11 -0500

Sam:

Russ