Re: [TLS] Short Ephermal Diffie-Hellman keys

Bodo Moeller <bmoeller@acm.org> Tue, 15 May 2007 22:44 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho5kU-0003cX-As; Tue, 15 May 2007 18:44:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho5kS-0003cS-FT for tls@lists.ietf.org; Tue, 15 May 2007 18:44:04 -0400
Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho5kQ-0000Jt-2i for tls@lists.ietf.org; Tue, 15 May 2007 18:44:04 -0400
Received: from [80.142.184.190] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Ho5kG2B32-0002iE; Wed, 16 May 2007 00:43:55 +0200
Received: by tau.invalid (Postfix, from userid 1000) id 619921C298; Wed, 16 May 2007 00:43:51 +0200 (CEST)
Date: Wed, 16 May 2007 00:43:51 +0200
From: Bodo Moeller <bmoeller@acm.org>
To: Russ Housley <housley@vigilsec.com>
Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys
Message-ID: <20070515224351.GA27872@tau.invalid>
References: <op.tsa3n9ttqrq7tp@nimisha.oslo.opera.com> <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> <4649D2FD.2020309@drh-consultancy.demon.co.uk> <4649E35B.4030809@bolyard.com> <20070515202726.GA24732@tau.invalid> <0MKu60-1Ho53w3DRn-0003jg@mx.kundenserver.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0MKu60-1Ho53w3DRn-0003jg@mx.kundenserver.de>
User-Agent: Mutt/1.5.9i
X-Provags-ID: V01U2FsdGVkX19anh4vg0dLSoCKpBP5prqCXEa1luv4Qo6QmIP 9P6IEz3GjAveK65Kw+CArEHXUEDzjRAPkuYhHSqyyl1zoo4/Bf VqmDXyGqOasAKfD+HpS9A==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: tls@lists.ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

On Tue, May 15, 2007 at 05:54:27PM -0400, Russ Housley wrote:
> Bodo:

>>>> Speaking of which what do people think about including the sub prime
>>>> value (aka "q") as an optional value in DH parameters in a TLS 1.2
>>>> handshake?

>> Yes, this definitely should be done!

> RFC 2412 does not seem use "q" this way.  Does anyone every use 
> Oakley groups with TLS?  If so, then you probably need some more 
> general way to indicate the size of the subgroup.

For the Oakley well-known groups, the generator actually is a
generator of a prime-order subgroup, so specifying a 'q' value is no
problem.  (It doesn't help much in this case, though, since 'q' is
just one bit shorter than 'p'.)

In general, Oakley-style group specifications include a "group order
largest prime factor" field, which is pretty useless for
implementations.  It only helps to estimate the security that
can be obtained using such a group when doing Diffie-Hellman
*properly*, which is something for which you *don't* need this piece
of information (and for which you shouldn't rely too much on
Appendix D of RFC 2412).  What you do need for implementations is the
group order, and (if you want to use the short-exponent trick
suggested in RFC 2412 App. D) information on whether the group order
is prime (which is *not* part of Oakley-style group specifications).


I'd suggest stating in the TLS specification that 'q' can only be
included in the ServerKeyExchange message for the case of prime-order
subgroups.  These are what you'd usually use, except sometimes if the
DH subgroup is nearly as large as 'p', which is a case where knowing
'q' doesn't provide significant benefits anyhow.

Bodo


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls