Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms

From: [email-masked]
Date: Fri, 13 Jun 2003 19:30:45 -0400

> Me too.  With a statement that keys weaker than a certain 
> level (say, 128 bits although 96 is probably enough) SHOULD 
> NOT be used, I can live with DES being demoted to a SHOULD NOT.
> 
> Still, I think that DES fits better with the definition of 
> MAY: "One vendor may choose to include the item because a 
> particular marketplace requires it or because the vendor 
> feels that it enhances the product while another vendor may 
> omit the same item."

We need to write requirements that have a reasonable lifetime;
keep in mind how long the MUST for DES survived.  DES is already
embarrassingly weak, and will only get weaker.

In the algorithms draft, I'd like to see:
	- SHOULD NOT use DES
	- SHOULD NOT use keys shorter than 128 bits
The latter is about key length, not effective strength of the
cipher against best known attack.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Yoav Nir" <[email-masked]>
Date: Sun, 15 Jun 2003 09:19:19 +0200

Why not make the requirement about effective strength?  That way, if ever it
turns out that AES_128 can be broken in 2**90 steps, it automatically
becomes a SHOULD NOT.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Saturday, June 14, 2003 1:31 AM
To: [email-masked]
Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms

Thanks,
--David

---

From: Paul Koning <[email-masked]>
Date: Sun, 15 Jun 2003 19:59:34 -0400

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:

 Yoav> Why not make the requirement about effective strength?  That
 Yoav> way, if ever it turns out that AES_128 can be broken in 2**90
 Yoav> steps, it automatically becomes a SHOULD NOT.

That idea is somewhat appealing, but how would you define effective
strength?  There's memory, there's precomputation, and there's the
subsequent computation for the attack.  All three parts matter.  (If
you omit precomputation and memory, then all block ciphers have
strength 1...)

	 paul

---

From: [email-masked] (David Wagner)
Date: 16 Jun 2003 04:39:26 GMT

>turns out that AES_128 can be broken in 2**90 steps, it automatically

I don't recommend this.

I can just see the debates this might spawn.  Cryptographers
already can't agree whether the Courtois-Pieprzyk attack works or
not, and that might be a 2^80 attack on AES -- if it works
(which nobody knows).

I'd recommend to keep it simple.  KISS.  Isn't it easier to simply write
that implementors SHOULD NOT use key sizes shorter than the default
key size?

---

From: "Yoav Nir" <[email-masked]>
Date: Mon, 16 Jun 2003 08:33:00 +0200

It MAY be simple, but it is wrong, so it SHOULD NOT be used.  WEP offers
128-bit keys, but only 24-bit security (or 12, depending on your definition)

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David Wagner
Sent: Monday, June 16, 2003 6:39 AM
To: [email-masked]
Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms

I don't recommend this.

---

From: [email-masked] (David Wagner)
Date: 16 Jun 2003 05:44:32 GMT

>128-bit keys, but only 24-bit security (or 12, depending on your definition)

That's irrelevant: WEP isn't on the list of recommended algorithms.
If our recommended key sizes were inadequate, then complain about
that.  But I think that you'll find that the default key sizes in
draft-...-ikev2-algorithms are eminently reasonable.

I think you're making this more complicated than it should be.
Let me take this to absurd extremes: Imagine adding a sentence
to the standard saying "All IPSec implementations MUST be secure.
Insecure implementations are non-complying."  Such a sentence would
add little value, because it doesn't tell the implementor *how* to
achieve compliance.  The purpose of the standard is not to list a set
of requirements or desirable features; the purpose of the standard is
to promote interoperability and to specify a protocol that (we believe)
meets those requirements.

---

From: Paul Koning <[email-masked]>
Date: Mon, 16 Jun 2003 09:02:34 -0400

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:

 Yoav> It MAY be simple, but it is wrong, so it SHOULD NOT be used.
 Yoav> WEP offers 128-bit keys, but only 24-bit security (or 12,
 Yoav> depending on your definition)

Yes, but the troubles with WEP, as I recall, don't come from its
cipher, but rather from the stuff that was wrapped around it without
any regard to proper cryptographic design.

So are you proposing that the rule should be on the effective strength
of the whole system?  Yes, that's theoretically what you'd want, but
no, I don't see how that's feasible.

    paul

---

From: Henry Spencer <[email-masked]>
Date: Mon, 16 Jun 2003 10:56:38 -0400 (EDT)

> any regard to proper cryptographic design.

Correct.  The cipher is RC4, which is (last I heard) still thought to be
okay.  The problem is that WEP generates keys by a distinctly non-random
process which produces many closely-related keys, and nobody thought to
ask whether this was a weakness.  It is.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 16 Jun 2003 11:56:34 -0400

> okay.  

Okay, but not great.

RC4 is a stream cipher which comes with additional special handling
recommendations ("For best results, discard first N bytes of output
after keying").

> The problem is that WEP generates keys by a distinctly non-random

The WEP related-key attacks exploit the first-byte weaknesses of RC4.

					- Bill

---

From: Henry Spencer <[email-masked]>
Date: Mon, 16 Jun 2003 12:13:43 -0400 (EDT)

> recommendations ("For best results, discard first N bytes of output

My impression is that said recommendation applies only with non-random
keys.  When I dug into this (albeit briefly) a while back, I was unable to
find any source for that recommendation which didn't trace back to WEP's
disastrously non-random key-generation procedure. 

I would be curious to know whether this is still an issue *with* good
random-bits keys.  (With a reference, not just folklore; my suspicion is
that the WEP problem is being over-generalized in the folklore.)

                                                          Henry Spencer
                                                       [email-masked]

---

From: "Russ Housley" <[email-masked]>
Date: Mon, 16 Jun 2003 13:45:42 -0400

WEP causes a problem from RC4 because it "publishes" the first 24 bits
of the key.  The RC4 key schedule is not robust enough to deal with part
of its input being disclosed.  If RC4 is used in a system where none of
the keying material is disclosed, as is the case with TLS, then it holds
up just fine.

In ESP, the use of RC4 would require special handling to avoid WEP-like
issues.  I do not believe that anyone has written a specification for
RC4 and ESP.

Russ

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Bill Sommerfeld
> Sent: Monday, June 16, 2003 11:57 AM
> To: Henry Spencer
> Cc: IP Security List

---

From: "Lee Dilkie" <[email-masked]>
Date: Mon, 16 Jun 2003 14:36:03 -0400

I thought also that RC4 was not a restartable(seekable?) stream cipher and
thus cannot tolerate lost or out of order packets unless special steps were
taken (re-gen the key schedule for each packet?).

> [mailto:[email-masked]]On Behalf Of Russ Housley
> Sent: Monday, June 16, 2003 1:46 PM
> To: [email-masked]; 'Henry Spencer'
> Cc: 'IP Security List'
> > > process which produces many closely-related keys, and
> nobody thought
> to

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 Jun 2003 16:28:28 -0400

>taken (re-gen the key schedule for each packet?).

All stream ciphers use a key to produce a key stream.  WEP needs a 
different key stream for each packet, as would IPsec ESP if one tried to 
use RC4 in this context.  WEP achieved this by constructing a per-packet 
key.  An IV was simply concatenated with the rest of the key.  This is how 
the first three bytes of the packet key are "published."

Russ

---

From: "Yoav Nir" <[email-masked]>
Date: Tue, 17 Jun 2003 09:20:16 +0200

The problem with WEP is that although there's a secret part to the key (40
or 104 bits), that part never changes.  The IV is 24 bits which means that
there are only 2^24 possible streams.  Even assuming that the IVs are
uniformly random, you can expect collisions after a few thousand packets.

But we're not here to discuss WEP.  I only brought it up as an example of
how key-length does not equal security.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Henry Spencer
Sent: Monday, June 16, 2003 6:14 PM
To: IP Security List
Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms

                                                          Henry Spencer
                                                       [email-masked]