Re: [TLS] Short Ephermal Diffie-Hellman keys

Bodo Moeller <bmoeller@acm.org> Sun, 03 June 2007 16:52 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 1HutJe-0002oz-4Y; Sun, 03 Jun 2007 12:52:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HutJc-0002j3-1K for tls@lists.ietf.org; Sun, 03 Jun 2007 12:52:28 -0400
Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HutJX-0007gM-GU for tls@lists.ietf.org; Sun, 03 Jun 2007 12:52:28 -0400
Received: from [80.142.163.135] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1HutJU0nZO-0000zs; Sun, 03 Jun 2007 18:52:21 +0200
Received: by tau.invalid (Postfix, from userid 1000) id 41E2E1AF29; Sun, 3 Jun 2007 18:52:18 +0200 (CEST)
Date: Sun, 03 Jun 2007 18:52:18 +0200
From: Bodo Moeller <bmoeller@acm.org>
To: Eric Rescorla <ekr@networkresonance.com>
Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys
Message-ID: <20070603165217.GA9266@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> <20070515224351.GA27872@tau.invalid> <20070603150710.8E87B33C4B@delta.rtfm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20070603150710.8E87B33C4B@delta.rtfm.com>
User-Agent: Mutt/1.5.9i
X-Provags-ID: V01U2FsdGVkX1/GDkcMzjMxPwxHsfk1nJOqHXtJC2Sb3cNxigb +tnUVvaxIXquQI3TJ2jXO+r6iMv/z82cn/ZqkMhA+UJ+UI/Gdh hlrg2wPoObwkO23upxKwA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
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 Sun, Jun 03, 2007 at 08:07:10AM -0700, Eric Rescorla wrote:
> At Wed, 16 May 2007 00:43:51 +0200,
> Bodo Moeller wrote:

>> 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.

> So, I'm no DH expert, but my understanding is that there are three
> common cases:
> 
> 1. Randomly generated p with no special structure
> 2. Sophie-Germain primes where q is about p/2.
> 3. DSA-style groups where q<<p.
> 
> Only in the last case does carrying around q offer much benefit.

This is almost true.  (The first case should be avoided: if you want
to avoid the cost of finding a Sophie-Germain prime, use a DSA-style
group instead.  There are other cases of special structure besides #2
and #3 that are safe to use, though, and where you might not be using
a prime order subgroup.)

In the strong-prime case (#2: q is a Sophie-Germain prime, p = 2q + 1
is a strong prime), you'd have to be shown q (or do a very expensive
test) to positively know that p is indeed a strong prime.  Once you
know this, you can save time by using short DH exponents in this case
just as in the DSA-style case.  So knowing q is useful for the client
in the strong-prime case too.


> Is this common enough that it's worth changing the spec?

It could very well become common.  With the protocol as it is now,
there isn't that much gained by using a DSA-style group because this
only helps the server, not the client.  And those client
implementations that don't care about spending five times or so
more time than necessary on the DH exchange could simply ignore the
extra information.


>                                                          It was
> my understanding that we mostly encouraged people to use S-G primes
> in any case.

There is no reason to recommend strong primes over other primes for
ephemeral DH.  They can be quite useful when using a *fixed* DH key
(because if you use a DSA-style group, you'd need a subgroup
membership test, which essentially means you'd lose the performance
advantage of using a fixed DH key -- and then the total cost of the DH
exchange with a DSA-style group might even be higher than with a
strong prime and short exponents).  But there is no need to use a
fixed DH key for an ephemeral DH key exchange: usually, this should be
avoided.

We don't have to encourage people to use strong primes for the
ephemeral DH key exchange.  Rather, we should encourage them to use
properly ephemeral DH -- i.e., not to reuse DH keys for more than a
single handshake.  If they do that, then they can gain a lot by using
DSA-style groups.

Bodo


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