Re: [TLS] WGLC: draft-ietf-tls-negotiated-ff-dhe-05

Watson Ladd <> Wed, 28 January 2015 03:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E3A751A1B61 for <>; Tue, 27 Jan 2015 19:13:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bb9wds1R05f6 for <>; Tue, 27 Jan 2015 19:13:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 782E01A1B71 for <>; Tue, 27 Jan 2015 19:13:34 -0800 (PST)
Received: by with SMTP id q200so7919198ykb.9 for <>; Tue, 27 Jan 2015 19:13:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SO1vogXI5RKXo5GKB7jgvTK4pLqlu010rxODmtd4LlA=; b=SKzRFRb/KwMhDVqV+EykCVbRer/XIjgXlyWuEOxXfT7T0fNBSN08hNekqhdGYIn/Io BDWbyD74zCSz07AqhVC1R97xk/i1/dop0glRODybLjE5cvYJihUSmMo3vEYrcIJVzYYC oPG1titNNf+gVIyK679NhnyUiFnycLX9FeFNkqaGUpuv45PXkaJgKl6HRnENAJzRuk4k aLz0I3MNewRKZVVzt+5AVlvbImQ+55QHbvGMP20d0zpJdlPIFYO+Zwhsf9NUWcJ01Vx+ pHa0/i/gMIBr35naBItQfCxlfUXtPMeYz7QZmkVwxbYbmCRCI687HVM36VkHSQLjFI/t +kdw==
MIME-Version: 1.0
X-Received: by with SMTP id j9mr210430ykf.19.1422414813654; Tue, 27 Jan 2015 19:13:33 -0800 (PST)
Received: by with HTTP; Tue, 27 Jan 2015 19:13:33 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Tue, 27 Jan 2015 19:13:33 -0800
Message-ID: <>
From: Watson Ladd <>
To: Daniel Kahn Gillmor <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] WGLC: draft-ietf-tls-negotiated-ff-dhe-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Jan 2015 03:13:38 -0000


> Using a keyed PRF instead of e
> ------------------------------
> Two objections were made about the use of e --
> (a) because of its definition as the base of the natural log, e has some
>     sort of special internal structure that might make FFDH groups
>     derived from it more vulnerable to analysis.
> (b) that starting from e and counting up biases the randomized prime
>     selection by only fiddling certain bits in the prime while counting.
> I've spoken with several cryptographers about (a) who dismissed it as
> totally implausible.  I haven't gotten much feedback about (b).
> The proposed change is to select the "random" bits by using a keyed PRF,
> or KDF, with the seed or additional input incrementing until a safe
> prime is found.
> I confess this sounds better than using e to me, simply because the
> construction avoids any claims about (a) and (b).
> One approach would be to use [HKDF] with SHA-512, with the initial key
> material ("IKM") and info parameter both set to "TLS-ffdheNNNN" (where
> ffdheNNNN is the ASCII name of the group), and a salt that we increment
> until a safe prime is found at the right length.
>   [HKDF]

I don't see what the gains of this approach are over the existing one.
(b) is valid as far as it goes but I don't think it's a real concern.

> Avoiding the high-64 and low-64 bits set to 1
> ---------------------------------------------
> The high 64 bits and the low 64 bits of these primes are set to 1
> specifically to facilitate Montgomery and Barrett reduction.  This is
> similar to the choices made in the MODP FFDHE groups.
> The objection to this is that the special structure may make these
> groups more vulnerable to attacks that we don't know about, potentially
> making them equivalent to groups the size of the inner bits or
> something.
> I'd like to think that if any advances had been made against the DLOG
> problem for groups with this special form, they would be published
> already, since the first Oakley group is 768 bits, with the top and
> bottom 64 bits all set to 0xff, so this should be in-range and
> high-profile for anyone who wants to take a crack at it:
> But i'm not a cryptographer, i know of no such attack, and i have no
> idea how to judge the likelihood of something like this existing.
> I also don't know how widespread or desirable Barrett and Montgomery
> reductions are: if these reduction methods are unlikely to be actually
> used in the field, or offer only insignificant efficiency incentives for
> adoption, then we might not need to maintain them.

Montgomery reduction is a very common implementation choice for RSA
and DH implementations. Barrett may get used, but requires a big table
per prime. I doubt there are going to be attacks based on this
"special" property.

> Another argument here is that if efficiency is paramount, most people
> will choose ECDHE instead of FFDHE.  So if we're proposing FFDHE groups
> as a bulwark against some future failure of ECDHE, we might as well
> accept that performance efficiency isn't the highest priority.
> These last two points are what Andrei is referring to when he says
> "avoid special-form primes", fwiw.
> Thoughts, feedback?
>           --dkg
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin