Re: [TLS] DH group validation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] DH group validation
On Wed, Oct 17, 2007 at 09:48:58AM +0300, Pasi.Eronen at nokia.com wrote:
> Bodo Moeller wrote:
>> I don't see that verifying the DH group doesn't really add
Oops, unintended double negation. But apparently everyone got what
I meant: "I don't see that verifying the DH group really adds
significant value."
>> significant value: it does not counter any threats by actual
>> adversaries.
> Not all threats all caused by malicious adversaries. IMHO the
> purpose of doing some kind of DH group validation is to mitigate
> risk from a particular kind of implementation mistake. This
> particular implementation mistake has been seen in real world,
> so it does have some relevance (although there are, of course,
> other implementation mistakes that can't be found by this
> particular check).
Yes, this is my point (as stated earlier in the paragraph part of
which you quoted here).
> However, it seems that as long as we don't require any particular
> verifiable prime generation algorithm (such as X9.42), or use only
> "known" groups (like IKE does), the only validation we can easily
> do (without non-trivial computation) is checking the size of "p".
I am hoping that we can agree to (optionally?) include "q" into DH
parameters for the next version of the standard, allowing for more
meaningful quick "validation" on the one hand, and for efficiency
improvements on the other hand. (Efficiency improvements since if you
have a 2048-bit p with a 224-bit q, the client has much less work to
do if it knows it only has to choose an exponent in the range (2, q-1)
and not a 2048-bit exponent.) In this case, the client would look
at the size of q to see if it looks reasonably large, and presumably
also would check that q is at least one bit longer than q.
Bodo
_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.