[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MODP groups draft concern


This e-mail asks whether it is appropriate at this time to include the
suggested 8192-bit MODP group in the draft. If I correctly understood your
presentation at the San Diego IPsec meeting, not only do we not know whether
the proposed 8192-bit modulus is a Sophie-Germain prime, but we don't even
know if it is prime. If this is true, then we aren't at all certain of its
security properties, so don't know whether it meets its design goal of
providing the level of security suggested as necessary for AES-192.
Probabalistic assurances are something we have never agreed to before for
well-known IKE groups. In the past our standard has been the modulus for any
well-known group must be a verified Sophie-Germaine prime. This criteria has
served us well for every well-known group to date. Why abandon it now?

I can think of at least three plausible ways forward:

a. The IPsec community could dedicate resources to help verify that the
value is indeed a Sophie-Germain prime (assuming it is). In the eventuality
of a successful verification, it would be appropriate for the value to
remain in the draft. Many would see this as the most desirable outcome,
because we would possess a value anyone could use, safe in the knowledge
that it actually provides the level of security we hope it does.

b. If we can't certify it is a Sophie-Germain prime, or even a prime, we
should remove it from the draft altogether, because we don't know whether it
actually provides the expected level of security. The reasoning here would
be to defer prescribing a value this large until sufficient resources exist
to determine whether a proposed candidate meets the selection criteria.
Probabalistic assurances might be sufficient for private phase 2 groups, but
not for the well-known groups defined by the standard. We certainly expect
potential attackers to concentrate their resources on resolving the issue
for us, and if by dumb luck it turns out the value is not Sophie-Germain or
not even prime (probabilities are only probabilities, after all), consumers
of IPsec technology would not be harmed by a false sense of security. There
will always be lingering doubt and risk until the probability of being a
Sophie-Germain prime is shown to be exactly 1.

c. We could widen the rules, as the draft implicitly does now, to accept
values with only probabalistic assurances. My e-mail objects to this path,
because we have not yet discussed the issue and reached a consensus within
the community that this has acceptable risk. At the very least, we need to
make this kind of selection criteria explicit instead of implicit, and if we
allow probabilistic assurances, we need to document the probabilities we are
talking about. I find this the least desirable of the three possibilities
enumerated here, because we would have to qualify the 8K value as not
providing the same sense of security as the existing smaller prime values
already used by IKE; we think but aren't sure it really satisifies the
requirements for being a good Diffie-Hellman group modulus. And I don't know
have a clue as to how to get this message through the filter of the
marketeers to the ultimate consumers of IPsec, who need to understand the
probabilities and issues very clearly to make informed tradeoffs about when
it is prudent to use the 8K group (or rather alleged group, since we don't
know it's prime). The users of our technology are not just cryptographers
and security specialists, and it is an understatement to say I am sanguine
about the wisdom of forcing our customers to consider these kinds of

It is not obvious to me that the need for an 8K or larger group is
sufficiently urgent to abandon our long standing criteria. Let the
verification algorithm crank a few months or years or however long is
necessary to tell us whether the value has the right properties we need for
security. We can standardize a new 8K group whenever this completes with a
verified Sophie-Germain prime, or generates a Schnorr group, or whatever we
define as safe. Until then, let's not tell the world this value is OK to use
by including it in the draft, because we just don't know.

-- Jesse Walker