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

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 10 Jun 2003 19:52:45 -0700

Greetings again. The tables in draft-ietf-ipsec-ikev2-algorithms have 
MUST, SHOULD, MUST-, SHOULD+, SHOULD- (which I have proposed 
removing), and MAY. The MAY designation is silly, since an 
implementation MAY do whatever it pleases for non-mandatory 
algorithms.

The reason I bring this up was the proposal that DES should be 
demoted to SHOULD NOT. That is somewhat harsh given that there are 
places where DES is appropriate (low value transactions in 
implementations that already have DES in them). Listing DES as "MAY" 
gives the wrong impression. The document should be re-cast to list 
all the registered algorithms, but to remove "MAY" from those that do 
not have a stronger designation.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Koning <[email-masked]>
Date: Wed, 11 Jun 2003 09:53:53 -0400

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

 Yoav> So RC4, Blowfish and IDEA are "MAY", but DES is "SHOULD NOT"?
 Yoav> I think those should be at least as discouraged as DES.

Why?  DES is known to be weak (inadequate key size), while the others
are (unless I missed something recent) not substantially weaker than
exhaustive search of their key.

Then again, RC4 shouldn't be in there at all since there is no spec
for the use of RC4 in IPsec.  Blowfish and IDEA are questionable for
the same reason, although there the generic CBC spec arguably can be
used. 

      paul

---

From: "Yoav Nir" <[email-masked]>
Date: Wed, 11 Jun 2003 16:44:27 +0200

So RC4, Blowfish and IDEA are "MAY", but DES is "SHOULD NOT"?  I think those
should be at least as discouraged as DES.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Paul Koning
Sent: Wednesday, June 11, 2003 3:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms

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

 Paul> Greetings again. The tables in
 Paul> draft-ietf-ipsec-ikev2-algorithms have MUST, SHOULD, MUST-,
 Paul> SHOULD+, SHOULD- (which I have proposed removing), and MAY. The
 Paul> MAY designation is silly, since an implementation MAY do
 Paul> whatever it pleases for non-mandatory algorithms.

 Paul> The reason I bring this up was the proposal that DES should be
 Paul> demoted to SHOULD NOT. That is somewhat harsh given that there
 Paul> are places where DES is appropriate (low value transactions in
 Paul> implementations that already have DES in them). Listing DES as
 Paul> "MAY" gives the wrong impression.

So what is wrong with "SHOULD NOT"?

Two points.  First, "SHOULD NOT" permits the implementation to do the
thing being discouraged, but it explicitly warns that one must first
consider whether it's wise to do so.  I think that is exactly the
correct message for DES.

Second, what implementation already has DES that doesn't also have
3DES?  I'm hard pressed to think of any.  In a software
implementation, 3DES is of course quite slow, but if so, the sensible
answer is AES, which is faster than either.  In a hardware
implementation, you're stuck with what's in the chip, but if so, you
have 3DES.

     paul

---

From: Paul Koning <[email-masked]>
Date: Wed, 11 Jun 2003 09:18:46 -0400

paul

---

From: "Yoav Nir" <[email-masked]>
Date: Wed, 11 Jun 2003 17:26:34 +0200

DES may be too weak for some applications, but it is a widely used standard.
It is up to the user to decide whether DES is strong enough for their
application or not.  We wish the standards to ensure interoperability, and
that means AES, 3DES and DES because these are widely implemented.

Blowfish and IDEA are relatively rare, and have not received the scrutiny
that DES and AES have.  That's why they should be discouraged.  Not because
they are weak, but because we don't know for sure how weak they are.

I agree though, that the argument for DES is no longer as strong as it was a
few years ago, when you had to support DES (and a DES-only license) to
export an encryption product out of the US.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Paul Koning
Sent: Wednesday, June 11, 2003 3:54 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms

      paul

---

From: Henry Spencer <[email-masked]>
Date: Wed, 11 Jun 2003 11:14:12 -0400 (EDT)

> DES may be too weak for some applications, but it is a widely used standard.

As is sending passwords in clear with no encryption at all.  Just because
it is widely used doesn't mean it is good enough for us to recommend it
for use in IPsec.

"Neglect of duty does not cease, by repetition, to be neglect of duty."
							-- Napoleon

> application or not.

Correct, and it is up to us to indicate wise choices for the bulk of
applications.  "SHOULD NOT" is precisely the right wording here -- it
specifies something that is typically unwise but may be necessary in
unusual circumstances. 

IPsec has long suffered from an unwillingness to make decisions and give
specific recommendations, even when the technical issues were clear-cut. 
It is time to be a bit more decisive.

> We wish the standards to ensure interoperability...

And security.  Which DES no longer delivers very well.

The FreeS/WAN project dropped single-DES support over four years ago, at
management insistence.  This caused surprisingly few interoperability
problems.  (There were one or two.)  I think it is now quite safe to say
that DES-only environments involve either obsolete software or specialized
requirements -- a perfect case for SHOULD NOT.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 11 Jun 2003 11:54:33 -0400

> requirements -- a perfect case for SHOULD NOT.

It appears that the US government agrees with your management on this
point.

section 12 of FIPS 46-3 (issued in 1999) says, in part:

   Single DES (i.e., DES) will be permitted for legacy systems only. New
   procurements to support legacy systems should, where feasible, use
   Triple DES products running in the single DES configuration.

Since there is no installed base of IKEv2 to interoperate with, this
FIPS would appear to prohibit use of single-DES with IKEv2 for
government use.

One more vote for SHOULD NOT.

						- Bill

---

From: Paul Koning <[email-masked]>
Date: Wed, 11 Jun 2003 11:57:51 -0400

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

 Yoav> DES may be too weak for some applications, but it is a widely
 Yoav> used standard.  It is up to the user to decide whether DES is
 Yoav> strong enough for their application or not.  We wish the
 Yoav> standards to ensure interoperability, and that means AES, 3DES
 Yoav> and DES because these are widely implemented.

There are lots of RFCs that say SHOULD NOT or MUST NOT for security
weaknesses.  Just because you can argue "the customer should decide
whether xyz is strong enough" doesn't justify a MAY there -- and I
don't think it does here, either.

 Yoav> Blowfish and IDEA are relatively rare, and have not received
 Yoav> the scrutiny that DES and AES have.  That's why they should be
 Yoav> discouraged.  Not because they are weak, but because we don't
 Yoav> know for sure how weak they are.

Ok, then the simple answer is to remove them entirely from the spec,
because they aren't really specified explicitly anyway for IPsec and
probably not implemented anywhere anyway.

	 paul

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 11 Jun 2003 09:17:47 -0700

>exhaustive search of their key.

Any algorithm with a variable key size could be considerably weaker 
than DES. Unless you are going to start listing key sizes and giving 
each size a rating, saying SHOULD NOT for DES but MAY for some other 
algorithm that can use 40-bit keys is silly.

--Paul Hoffman, Director
--VPN Consortium

---

From: Henry Spencer <[email-masked]>
Date: Wed, 11 Jun 2003 13:08:09 -0400 (EDT)

On Wed, 11 Jun 2003, Paul Koning wrote:
>  Yoav> Blowfish and IDEA are relatively rare... [and poorly studied]
> 

Almost nowhere -- there was a user-contributed FreeS/WAN patch that did
IDEA, Blowfish, and CAST, and some folks used it.  We never adopted it as
part of the official distribution, though, and I don't think that's
changed since I left the project. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: [email-masked] (David Wagner)
Date: 11 Jun 2003 16:48:13 GMT

>algorithm that can use 40-bit keys is silly.

I don't recall a MAY requirement for any 40-bit cipher.  We debated
40-bit ciphers a long time ago (remember export controls?), and we came
to consensus many years ago that 40-bit ciphers have no place in IPSec.
Are you saying there is a MAY requirement for a 40-bit cipher?  If so,
that should be fixed, but I don't believe it.

In short, I don't see how your argument is relevant to whether DES is
a SHOULD NOT, a MAY, or something else.

By the way, what matters is not whether a cipher could support 40-bit
keys, but whether, /as standardized in IPSec/, it uses 40-bit keys.
There's nothing wrong with the former; but the latter is to be avoided.

---

From: Henry Spencer <[email-masked]>
Date: Wed, 11 Jun 2003 13:05:10 -0400 (EDT)

On Wed, 11 Jun 2003, Bill Sommerfeld wrote:
> > management insistence...
> point...

In fact, at the time *I* disagreed with my then-management, and did my
best to talk them out of it -- I thought that dropping support was
premature and was going to cause us serious grief.  To my considerable
surprise, I was wrong. 

                                                          Henry Spencer
                                                       [email-masked]

---

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

>should be at least as discouraged as DES.

That seems about right.  DES has a 56-bit key, and hence is a poor choice
for deployment in new systems.  Blowfish and IDEA are believed to be much
stronger.

RC4, on the hand, shouldn't be there.  Are you sure that RC4 is a "MAY"
in the IPSec RFCs?  If so, that should be fixed.

---

From: Henry Spencer <[email-masked]>
Date: Wed, 11 Jun 2003 13:46:50 -0400 (EDT)

On Wed, 11 Jun 2003, Paul Hoffman / VPNC wrote:
> At 11:54 AM -0400 6/11/03, Bill Sommerfeld wrote:
> So you think it is better to give a lower recommendation for an 
> algorithm with a known (weak) key strength than to algorithms that 
> could be much weaker, including zero encryption.

Where, exactly, did either Bill or I say that?  Please be precise.
This is a gross misrepresentation of my views, and probably Bill's
as well.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 11 Jun 2003 10:43:10 -0700

So you think it is better to give a lower recommendation for an 
algorithm with a known (weak) key strength than to algorithms that 
could be much weaker, including zero encryption. That sure sends a 
clear message to implementers...

--Paul Hoffman, Director
--VPN Consortium

---

From: Henry Spencer <[email-masked]>
Date: Wed, 11 Jun 2003 13:44:27 -0400 (EDT)

> that should be fixed, but I don't believe it.

RFC 2451 Blowfish allows keys as short as 40 bits, as does RFC 2451 CAST. 
RFC 2451 IDEA does not. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 11 Jun 2003 10:57:15 -0700

>that should be fixed, but I don't believe it.

draft-ietf-ipsec-ikev2-algorithms-02.txt, the document under 
discussion, has MAY level for many encryption algorithms that have 
key sizes down to 40. It's pretty clear in the draft, regardless of 
what you believe.

>There's nothing wrong with the former; but the latter is to be avoided.

Anyone who wanted to write a replacement for RFC 2451 has had almost 
five years to do so; so far, no one has.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 11 Jun 2003 11:56:25 -0700

>Where, exactly, did either Bill or I say that?  Please be precise.

I only saw messages about making DES be SHOULD NOT, not any messages 
about making all the other variable-length ciphers SHOULD NOT. If you 
sent such a message and I missed it, I apologize.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked] (David Wagner)
Date: 11 Jun 2003 18:34:04 GMT

>RFC 2451 Blowfish allows keys as short as 40 bits, as does RFC 2451 CAST. 

That's different.  IPSec does not have a MAY requirement for 40-bit
ciphers.  It has a MAY requirement for ciphers like Blowfish which can be
used with 40-bit keys, but the default key size for Blowfish is 128 bits,
which is adequate.  With DES, not only is the default key inadequate
(56 bits), that's the *only* supported key size; as a result, DES is
clearly inadequate for deployment in most new systems.

It's not what size keys the cipher supports that matters; it's what size
keys are standardized for use in IPSEc.

Maybe we should add a line to RFC2451 saying that users SHOULD NOT
use key sizes shorter than the default.  There's no good reason to use
shorter keys.  This addition would make everything consistent with a
SHOULD NOT policy for DES.  Will this make everyone happy?

(Amusingly, RFC2451 suggests that implementors SHOULD check for weak keys.
Personally, I consider *every* 40-bit key a weak key.)

---

From: [email-masked] (David Wagner)
Date: 11 Jun 2003 18:44:34 GMT

>key sizes down to 40. It's pretty clear in the draft, regardless of 

Ok, I didn't realize that.  I'm not convinced this respects the consensus
established by the working group years ago, but arguing about this might
take us into a rathole from which we never recover, so let's not go there.

Instead, let me just note that the situation with
draft-ietf-ipsec-ikev2-algorithms-02.txt is very different from the
situation with DES.  DES can't go higher than 56 bits.  The algorithms
in draft-ietf-ipsec-ikev2-algorithms-02.txt go up to 128 bits and higher,
and indeed, their default is 128 bits.

So, I still think DES should be a SHOULD NOT.

And, if consistency matters, there's a simple fix.  Let's change
draft-ietf-ipsec-ikev2-algorithms-02.txt to make clear that short keys
SHOULD NOT be used, just like DES SHOULD NOT be used.  I'm fine with that.

I do think the DES issue is more important in practice than the
draft-ietf-ipsec-ikev2-algorithms-02.txt issue.  Not many implementations
will use, say, Blowfish, and for those that do, it's pretty unlikely
they will go out of their way to use a smaller-than-default key size.
(If they do, maybe they deserve what they get.)  But it is quite likely
that many implementations will use DES with its 56 bit keys.

As a result, I feel it is more important to fix the DES issue than to
worry about Blowfish minimum key sizes.  If we don't do anything, the
DES failure mode could become widespread, while the Blowfish failure
mode is likely to be very rare.

As a result, if there is some reason we can't fix the
draft-ietf-ipsec-ikev2-algorithms-02.txt minimum key size issue, we
shouldn't let that stop us from fixing the DES issue.  Getting security
right is more important than consistency.  But if we can fix the
ikev2-algorithms draft, I have no objection to upping the Blowfish
minimum key sizes, if that is preferable.  It's not a bad idea.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 11 Jun 2003 12:30:44 -0700

>keys are standardized for use in IPSEc.

Exactly right.

>SHOULD NOT policy for DES.  Will this make everyone happy?

It would certainly make me happier. That way, we would not be having 
different recommendations for IKEv1 than what we have for IKEv2. 
Actually, a complete revision to RFC 2451 would be nice, including 
removing algorithms for which there are not stable references.

--Paul Hoffman, Director
--VPN Consortium

---

From: Henry Spencer <[email-masked]>
Date: Wed, 11 Jun 2003 15:33:36 -0400 (EDT)

> sent such a message and I missed it, I apologize.

You're still jumping to conclusions -- the fact that you have not heard
from me about the variable-length ciphers tells you nothing about my
position on them, so you cannot legitimately infer that I consider dealing
with them unimportant.  (And your "zero encryption" remark remains odd,
because none of the RFC 2451 variable-length ciphers goes down to zero.)

My position on them actually lines up closely with David Wagner's most
recent message:  they *are* lower priority -- not because they are better,
but because they are little-used and do have at least the option of longer
keys -- but it would nevertheless be good to deal with them too.  Dealing
properly with DES, however, is *important*.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 11 Jun 2003 17:35:50 -0400

> because none of the RFC 2451 variable-length ciphers goes down to

And the null cipher for ESP is qualitatively different; it's an
alternative to AH for applications where privacy is clearly not
required.

> properly with DES, however, is *important*.

And, for the record, "What Henry Said".

						- Bill

---

From: Tobias Poppe <[email-masked]>
Date: Wed, 11 Jun 2003 23:35:41 +0200

Hi,

Single-DES should be treated like NULL cipher. It has been broken.
People will start laughting at you if this goes into the RFC any different
than SHOULD NOT.

> 						- Bill

-tp
p.s. I actually know people who are already 'amused' that this topic
requires such an extensive discussion.
p.s.s.: History taught us that the 'we let it up to the user to decide'-attitude
does not work in the real world.

---

From: "Yoav Nir" <[email-masked]>
Date: Thu, 12 Jun 2003 12:04:05 +0200

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."

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Paul Hoffman / VPNC
Sent: Wednesday, June 11, 2003 9:31 PM
To: David Wagner; [email-masked]
Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms

Exactly right.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Koning <[email-masked]>
Date: Thu, 12 Jun 2003 10:22:01 -0400

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

 Yoav> Me too.  With a statement that keys weaker than a certain level
 Yoav> (say, 128 bits although 96 is probably enough) SHOULD NOT be
 Yoav> used, I can live with DES being demoted to a SHOULD NOT.

96 is probably enough but it's not a common keysize, so 128 makes
sense. 

 Yoav> Still, I think that DES fits better with the definition of MAY:
 Yoav> "One vendor may choose to include the item because a particular
 Yoav> marketplace requires it or because the vendor feels that it
 Yoav> enhances the product while another vendor may omit the same
 Yoav> item."

But "MAY" is neutral, it expresses no value judgement about the
choice.  "SHOULD NOT" also allows the vendor to choose but clearly
recommends that you don't implement it.  That's the messsage I'd like
to see for short-key ciphers.

   paul

---

From: Geoff Keating <[email-masked]>
Date: 11 Jun 2003 14:44:57 -0700

> algorithm that can use 40-bit keys is silly.

It might be a good idea to have a SHOULD NOT for too-short key lengths
(maybe under 'Security Considerations'), independent of algorithm.
The IKE RFC, for instance, says

> For this reason, a prf function whose output is less than 128 bits
> (e.g., 3DES-CBC) MUST never be used with this protocol.

Proposed wording is:

Implementors and administrators should carefully consider what
algorithms and key sizes are appropriate for each situation; as a
minimum, an implementation SHOULD NOT use an algorithm with a key size
of 64 bits or less in its default configuration.

-- 
- Geoffrey Keating <[email-masked]>

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 12 Jun 2003 09:32:15 -0700

>96 is probably enough but it's not a common keysize, so 128 makes

But only if you want to eliminate TripleDES, whose key size is 112 
bits. No one counts the parity bits as meaningful.

Yes, I'm being picky about this. As we have seen from IKEv1, sloppy 
wording which "everybody" understands at the time the RFC is issued 
becomes confusing and leads to lack of interoperability within a few 
short years.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Koning <[email-masked]>
Date: Thu, 12 Jun 2003 13:23:51 -0400

>> 96 is probably enough but it's not a common keysize, so 128 makes

 Paul> But only if you want to eliminate TripleDES, whose key size is
 Paul> 112 bits. No one counts the parity bits as meaningful.

Indeed, one doesn't count the parity bits.  So the 3DES key length is
168 bits, because IPsec uses 3-key 3DES.

 Paul> Yes, I'm being picky about this. As we have seen from IKEv1,
 Paul> sloppy wording which "everybody" understands at the time the
 Paul> RFC is issued becomes confusing and leads to lack of
 Paul> interoperability within a few short years.

Agreed.
	paul

---

From: Eric Rescorla <[email-masked]>
Date: 12 Jun 2003 11:15:15 -0700

> bits. No one counts the parity bits as meaningful.
As I understand RFC 2451, the 3DES we uses is 3-key 3DES in
EDE mode, so the effective key size should be 168 bits.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Scott Fluhrer <[email-masked]>
Date: Thu, 12 Jun 2003 12:03:38 -0700 (PDT)

> EDE mode, so the effective key size should be 168 bits.

For a cryptographical standpoint, there may be 168 distinct key bits that
affect the ciphertext, but it is well known that you can break 3DES with
far less work than O(2**168) effort.  There is a meet-in-the-middle attack
that (with a lot of memory) brings the effort down to around O(2**112),
which is what I assume Paul was refering to.  In addition, if you have
vast quantities of known plaintext encrypted with the same key, Stephan
Lucks' attack becomes interesting, which reduces the effort a bit more
(I don't have a solid estimate at hand).

Neither of these attacks are practical given current current limitations,
but one should remember that they do exist.

-- 
scott

---

From: Eric Rescorla <[email-masked]>
Date: 12 Jun 2003 12:26:28 -0700

Scott Fluhrer <[email-masked]> writes:

> which is what I assume Paul was refering to.
Uh, "lot" means O(2**56), no?

>>  In addition, if you have

Sure, but under practical conditions the effective key size of
3DES-EDE3 168 bits and it's conventional to refer to it this way.
In the same way, it's conventional to refer to DES as having a strength
of 56 bits despite the fact that if you somehow laid your hands on 2^47
chosen plaintexts the complexity of DES would be a measly O(2^47).

-Ekr

---

From: Scott Fluhrer <[email-masked]>
Date: Thu, 12 Jun 2003 12:42:26 -0700 (PDT)

> Uh, "lot" means O(2**56), no?

Well, yes, but the attack scales to lesser amounts of memory.  If you
had only O(2**40) memory, then the attack works in O(2**128) time --
still far less than 2**168.

> 3DES-EDE3 168 bits
Actually, as I pointed out above, even if you restrict the amount of
memory an attacker has available to a reaonable amount, the strength of
3DES is still less than 168 bits.

> and it's conventional to refer to it this way.

Conventional, perhaps, to people who aren't too concerned with precision
(although, in my experience, the estimate of 112 bits is rather more
common).

On the IPSec mailing list, we're supposed to be (one of the) IETF expert
groups on security -- I would hope that some greater amount of precision
is appropriate.

> chosen plaintexts the complexity of DES would be a measly O(2^47).
Actually, if you're refering to linear cryptanalysis, the common result is
that it takes 2^47 known plaintexts.

-- 
scott

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Jun 2003 15:03:54 -0700

Just so we're clear.

> And if you have O(2^336) blocks of memory then you could do in
> O(1) steps.
And of course, if you paid the modest O(2^336) precomputation cost.

> No, I'm referring to differential. See the HAC, pag 259.
> Not that it really matters.
Of course, it matters in some cosmic sense, but for the current purposes,
its merely "impractically large".

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: 12 Jun 2003 14:59:23 -0700

> 3DES is still less than 168 bits.
Only if you behave as if memory is costless.

> groups on security -- I would hope that some greater amount of precision
I don't consider ignoring the cost of memory particularly precise.

-Ekr