Subject: Suggested wording for weak key lengths in IKEv2

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 26 Jun 2003 11:15:00 -0700

Greetings again. Now that the WG last call is finished , it seems 
like having proposed wording might help resolve some of the open 
issues on Angelos' issue list. (You all are watching 
<https://roundup.machshav.com/ipsec/index>, yes?)

The issue that has the most issue numbers is the deprecating DES and 
weak keys issue in the ipsec-ikev2-algorithms document. To resolve 
it, I propose the following changes for section 4.1.3:

- ENCR_DES_IV64 and ENCR_DES be listed as "SHOULD NOT"

- A sentence be added to the end of that section as a free-standing 
paragraph that says: "Implementations that use algorithms with 
variable-length keys SHOULD NOT use keys that are weaker than the 
effective strength of ENCR_3DES."

If we do this, we can eliminate the definition of "SHOULD-", because 
it was only used for the two DES algorithms.

--Paul Hoffman, Director
--VPN Consortium

---

From: Henry Spencer <[email-masked]>
Date: Thu, 26 Jun 2003 14:48:36 -0400 (EDT)

> effective strength of ENCR_3DES."

This sounds good to me, except that I would be tempted to pin down the
latter more by adding "(112 bits)" at the end.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 26 Jun 2003 13:00:55 -0700

At 3:56 PM -0400 6/26/03, Paul Koning wrote:
>  Paul> - A sentence be added to the end of that section as a
>  Paul> free-standing paragraph that says: "Implementations that use
>  Paul> algorithms with variable-length keys SHOULD NOT use keys that
>  Paul> are weaker than the effective strength of ENCR_3DES."
>
>How about "... strength of ENCR_3DES (112 bits)."  Otherwise it might
>cause confusion, because some will think that this rules out 128-bit
>keys, which isn't the intent.

As noted on the list, not everyone agrees that the effective strength 
of TripleDES is 112 bits, given differing values for amount of RAM 
and so on. I think it is better to just leave it as "effective 
strength" and let folks decide what that means.

If anyone reads the sentence and think that it means that AES-128 
(which is listed as a SHOULD) is weaker than TripleDES, well, I don't 
think I would call them an implementer that we need to worry about...

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Koning <[email-masked]>
Date: Thu, 26 Jun 2003 15:56:44 -0400

>>>>> "Paul" == Paul Hoffman </ VPNC <[email-masked]>> writes:

 Paul> The issue that has the most issue numbers is the deprecating
 Paul> DES and weak keys issue in the ipsec-ikev2-algorithms
 Paul> document. To resolve it, I propose the following changes for
 Paul> section 4.1.3:

 Paul> - ENCR_DES_IV64 and ENCR_DES be listed as "SHOULD NOT"

Great.

      paul

---

From: Henry Spencer <[email-masked]>
Date: Thu, 26 Jun 2003 16:38:57 -0400 (EDT)

> strength" and let folks decide what that means.

NO NO NO NO NO!  That means we have a standard which means different
things to different people, and nobody can tell which interpretation is
right!  This is TOTALLY UNACCEPTABLE.

If the problem is that people don't agree on 3DES's "effective strength",
then get rid of those words, and say something people can understand and
agree on, like "minimum 100 bits".

                                                          Henry Spencer
                                                       [email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 26 Jun 2003 17:52:30 -0400

> agree on, like "minimum 100 bits".

Agreed.  

We know that the key size is an upper bound on effective strength.
And it's an objective measure which doesn't change as research
evolves.

To select an actual value quickly, maybe we should just pick N
cryptographers at random, have each suggest a recommended minimum
symmetric key bit length and just take the average. ;-)

					- Bill

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 26 Jun 2003 15:20:38 -0700

>right!  This is TOTALLY UNACCEPTABLE.

Ah, a return to calm discussion about simple topics. :-)

>agree on, like "minimum 100 bits".

I'm fine with this as well.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Koning <[email-masked]>
Date: Thu, 26 Jun 2003 18:31:22 -0400

>>>>> "Paul" == Paul Hoffman </ VPNC <[email-masked]>> writes:

 Paul> At 3:56 PM -0400 6/26/03, Paul Koning wrote: - A sentence be
 Paul> added to the end of that section as a free-standing paragraph
 Paul> that says: "Implementations that use algorithms with
 Paul> variable-length keys SHOULD NOT use keys that are weaker than
 Paul> the effective strength of ENCR_3DES."
 >> How about "... strength of ENCR_3DES (112 bits)."  Otherwise it
 >> might cause confusion, because some will think that this rules out
 >> 128-bit keys, which isn't the intent.

 Paul> As noted on the list, not everyone agrees that the effective
 Paul> strength of TripleDES is 112 bits, given differing values for
 Paul> amount of RAM and so on. I think it is better to just leave it
 Paul> as "effective strength" and let folks decide what that means.

 Paul> If anyone reads the sentence and think that it means that
 Paul> AES-128 (which is listed as a SHOULD) is weaker than TripleDES,
 Paul> well, I don't think I would call them an implementer that we
 Paul> need to worry about...

I'm sorry I have to disagree.  You seem to assume, or expect, that
implementers have significant knowledge of cryptography.  That isn't
always true, and I don't think it should be a requirement.

I mentioned earlier that I don't really like talking about "effective
strength" in the first place since it's so much subject to debate and
opinion.  Can we just talk about raw key lengths?  If so, then 128 is
a good limit.

     paul

---

From: Francis Dupont <[email-masked]>
Date: Fri, 27 Jun 2003 11:29:50 +0200

In your previous mail you wrote:

=> it seems the lack of protection for the peer addresses (recognized
as a "security flaw" at Yokohama's meeting) is still missing:
if we can postpone mobility/multi-homing/etc stuff, this is not the
case for this issue: some words somewhere are needed.

Thanks for the pointer.

[email-masked]

PS: there are at least two solutions:
 - make NAT detection mandatory and use the implicit protection
   this mechanism provides (Tero's solution).
 - promise an explicit protection for address of peers which are
   not behind a NAT in "important" exchanges (My solution).
As the issue interacts with NAT traversal (either the peer is behind
a NAT and its address cannot be protected, or it is not behind a NAT
and its address must be protected) we need the final version of
the draft to see if the issue is closed.