Subject: [IPsec] guidelines for choice of D-H group

From: Scott C Moonen <[email-masked]>
Date: Mon, 29 Jun 2009 12:30:18 -0400

RFCs 4753 and 5114 provide vague recommendations for choice of 
Diffie-Hellman group relative to symmetric key sizes.  They don't 
specifically address how to look at a set of chosen SA encryption and 
authentication algorithms and arrive at a choice of suitable 
Diffie-Hellman group, nor do they address the use of PFS.  So:

1) For the IKE SA, the Diffie-Hellman operation generates two encryption 
and two authentication keys.  Should the Diffie-Hellman strength generally 
be equivalent to the longest key length, or to the sum of the key lengths? 
 If we sum up all four symmetric key lengths, most choices will exceed the 
strength provided by the currently available Diffie-Hellman groups.  But 
if we don't sum up the symmetric key lengths, then we are making 
Diffie-Hellman the weakest link in the chain (i.e., we aren't obtaining 
significant added value by generating different values for each of SK_ei, 
SK_er, SK_ai, SK_ar).  Which is the case?

1b) In any case, we don't have suitable Diffie-Hellman groups for use with 
HMAC-SHA2-384 and HMAC-SHA2-512.  Interestingly, the upcoming NIST and DoD 
standards push into the realm of 256-bit symmetric algorithms 
(HMAC-SHA2-256) with SHOULD+ or MUST, but for Diffie-Hellman only into the 
realm of 112 bits (NIST makes group 24 a MUST) or 128 bits (DoD makes 
group 19 a MUST).  Do the folks from DoD or NIST have any comments on this 
disparity?

2) If we are recommending parity between symmetric algorithms and DH group 
choice, is there any place that we are also recommending the use of 
perfect forward secrecy to guard against weaknesses there?  Not using 
perfect forward secrecy goes even further to make the Diffie-Hellman the 
weakest link in the chain.  And yet RFC 4308 does not require PFS, and 
NIST's own RFC 4869 doesn't even mention it.  Do the folks from NIST have 
any comments on why PFS is not mandated, let alone mentioned, in RFC 4869?

3) IKEv2 does not allow perfect forward secrecy for the first child SA. 
Similar to question 1 above, how does that play into the recommendation 
for DH group size to choose?  Admittedly, there probably isn't much lost 
if the IKE SA keys are compromised.  So should we look only at the child 
SA symmetric key sizes when considering what IKE SA DH group is 
appropriate?  Or should we sum up the IKE and child SA symmetric key 
lengths?

Thanks,

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

---

From: "Scott Fluhrer" <[email-masked]>
Date: Mon, 29 Jun 2009 13:01:03 -0400

_____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Scott C Moonen
Sent: Monday, June 29, 2009 12:30 PM
To: [email-masked]
Subject: [IPsec] guidelines for choice of D-H group

RFCs 4753 and 5114 provide vague recommendations for choice of
Diffie-Hellman group relative to symmetric key sizes.  They don't
specifically address how to look at a set of chosen SA encryption and
authentication algorithms and arrive at a choice of suitable Diffie-Hellman
group, nor do they address the use of PFS.  So: 

1) For the IKE SA, the Diffie-Hellman operation generates two encryption and
two authentication keys.  Should the Diffie-Hellman strength generally be
equivalent to the longest key length, or to the sum of the key lengths?  If
we sum up all four symmetric key lengths, most choices will exceed the
strength provided by the currently available Diffie-Hellman groups.  But if
we don't sum up the symmetric key lengths, then we are making Diffie-Hellman
the weakest link in the chain (i.e., we aren't obtaining significant added
value by generating different values for each of SK_ei, SK_er, SK_ai,
SK_ar).  Which is the case? 

It's pointless to make it much stronger than the longest key, as each
individual symmetric key can be attacked separately.
 
For example, suppose that SK_ei was an 128 bit AES key; the attacker could
recover that key by finding a packet encrypted with that key, and do a trial
decrypt based on successive keys, and stop when he finds a key that makes a
plausible plaintext.  The important point is that he can do this without
knowing what the other keys SK_er, SK_ai, SK_ar are, and so those other keys
don't add to the security in this specific attack.
 
More generally, suppose the attacker is able to recover SK_ei with effort A
(for example, if AES-128 is being used, and we're using brute force to
recover the key, then A=2**127 decrypt operations expected), and similarly
SK_er, SK_ai, SK_ar can be recovered with efforts B, C, D, then the time
taken to recover all four is A+B+C+D, which is no more than 4 times the
largest of the four (and this is assuming that the attacker is actually
interested in all four, which is generally not the case).

1b) In any case, we don't have suitable Diffie-Hellman groups for use with
HMAC-SHA2-384 and HMAC-SHA2-512.  Interestingly, the upcoming NIST and DoD
standards push into the realm of 256-bit symmetric algorithms
(HMAC-SHA2-256) with SHOULD+ or MUST, but for Diffie-Hellman only into the
realm of 112 bits (NIST makes group 24 a MUST) or 128 bits (DoD makes group
19 a MUST).  Do the folks from DoD or NIST have any comments on this
disparity? 

2) If we are recommending parity between symmetric algorithms and DH group
choice, is there any place that we are also recommending the use of perfect
forward secrecy to guard against weaknesses there?  Not using perfect
forward secrecy goes even further to make the Diffie-Hellman the weakest
link in the chain.  And yet RFC 4308 does not require PFS, and NIST's own
RFC 4869 doesn't even mention it.  Do the folks from NIST have any comments
on why PFS is not mandated, let alone mentioned, in RFC 4869? 

3) IKEv2 does not allow perfect forward secrecy for the first child SA.
Similar to question 1 above, how does that play into the recommendation for
DH group size to choose?  Admittedly, there probably isn't much lost if the
IKE SA keys are compromised.  So should we look only at the child SA
symmetric key sizes when considering what IKE SA DH group is appropriate?
Or should we sum up the IKE and child SA symmetric key lengths?  

Same answer to the last question: the IKE and the IPSec SA keys can be
attacked separately, and so making the DH stronger than the longest
individual key doesn't gain you anything from a security standpoint.
 
-- 
scott

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 29 Jun 2009 15:09:00 -0400

Scott, thank you.  How dense of me!  Doubling the work effort is 
equivalent to adding one bit to the effective strength, not doubling the 
number of bits.

From:
"Scott Fluhrer" <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS, <[email-masked]>
Date:
06/29/2009 01:01 PM
Subject:
RE: [IPsec] guidelines for choice of D-H group

 
For example, suppose that SK_ei was an 128 bit AES key; the attacker could 
recover that key by finding a packet encrypted with that key, and do a 
trial decrypt based on successive keys, and stop when he finds a key that 
makes a plausible plaintext.  The important point is that he can do this 
without knowing what the other keys SK_er, SK_ai, SK_ar are, and so those 
other keys don't add to the security in this specific attack.
 
More generally, suppose the attacker is able to recover SK_ei with effort 
A (for example, if AES-128 is being used, and we're using brute force to 
recover the key, then A=2**127 decrypt operations expected), and similarly 
SK_er, SK_ai, SK_ar can be recovered with efforts B, C, D, then the time 
taken to recover all four is A+B+C+D, which is no more than 4 times the 
largest of the four (and this is assuming that the attacker is actually 
interested in all four, which is generally not the case).

 
-- 
scott