speaking of keys

[Stephen Kent <kent@bbn.com>]

Since we've been discussing the details of key derivation, the amount 
of entropy we get from a 1204 bit DH exchange, and how that aligns 
nicely with the 160-bit hash output from SHA-1, I want to raise a 
related issue.

Consistent with our efforts to simplify IPsec in general, I suggest 
that we mandate support for just one DH group (of 1024-bit size) and 
require that products provide a management interface to allow 
users/administrators to specify other groups as needed.

Althouhg I am not a cryptographer, it seems that the 160-bits we get 
from a 1024-bit DH exchange is reasonable for use with 128-bit AES. 
I believe that NIST suggests that 1024-it DH should be good until at 
least 2015, although I forget what parameters they use in this 
analysis.

Yes, I know we generate at least 2 and more often 4 keys from each DH 
exchange (one each for encryption and integrity in each direction), 
so the 128-bit key size and 160-bit entropy measures are not so 
easily comparable.

I also worry that if we insist that all IPsec (IKE) implementations 
support 1536-bit DH, that too many folks will decide to select that 
option, under the "bigger is better" theme.  However, the added 
performance hit for 1536-bit DH is significant and might have the 
unintended effect of causing folks to decide that the IPsec 
performance hits is too big and thus choose not to employ IPsec at 
all.

If we mandate support for locally selected DH parameters, then we do 
permit more sophisticated user communities to select bigger groups, 
with different parameters, if they really need to. I have received 
feedback from some DoD clients that they want to use IPsec for 
protecting unclassified data, but feel the need to use groups 
selected by their crypto advisors (it's a union thing, I guess). it 
seem that many IKE implementations do not provide a facility for 
configuring other groups, and this poses problems for these folks. 
Hence my suggestion to adopt just one MUST group, at the 1024-bit 
size, but also mandate support for a management interface that allows 
user communities to support "custom" groups. We could impose some 
requirements on the max size groups that MUSt be supported via the 
management interface (to ensure interoperability), without specifying 
these other, bigger groups.

What do people think about this suggestion?

Steve