Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

Yaron Sheffer <> Tue, 24 September 2013 06:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7998C21F9C52 for <>; Mon, 23 Sep 2013 23:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.465
X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uF0oziLFBbEz for <>; Mon, 23 Sep 2013 23:30:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c00::22d]) by (Postfix) with ESMTP id 9B69F21F9C47 for <>; Mon, 23 Sep 2013 23:30:32 -0700 (PDT)
Received: by with SMTP id c50so2224772eek.18 for <>; Mon, 23 Sep 2013 23:30:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QjTIfMiAxVzGfcExiB5pziZeDcd8iwELKT2fB7LRzrM=; b=qre056ch8ad/mXacOgKxmtZVN7BbN6effGlux2AbRd2ov4WIYORT+lbBC+w+DjmF2E 5s+vKJv+5T+bm13YoOXtePGAfW27KxN7Vkxm13rcYGN1G/cS6itvS2mj1zY2+5rRFtqW +thiNDv9PPJInqNeSCZW93sSeywG+N+Kpk+YUmyFb2YyHF0OOMVBOHLKtvlDxNywVP3P SlCzGCaFdL5AwCIPGxsoXvxfWqulTuWHMc7jbBX6dg5MFkDQ/FalHVM1EG2wkJ3dr7y4 69Sn3HoKqXqCTGno7QgFwJfLzZDFasM4yr9PIvnHs74WlUgixPRH4+p6uiUg1RuJK1K0 uJNA==
X-Received: by with SMTP id m44mr202152eey.78.1380004231754; Mon, 23 Sep 2013 23:30:31 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id n48sm49718858eeg.17.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 23:30:31 -0700 (PDT)
Message-ID: <>
Date: Tue, 24 Sep 2013 09:30:30 +0300
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Peter Gutmann <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-Mailman-Version: 2.1.12
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: Tue, 24 Sep 2013 06:30:33 -0000

Just to clarify my sloppy terminology: I was asking about ECDH with 
named curves (which today means P-256 in practice, but in the future 
will allow non-NIST curves, e.g. Brainpool). Of course the "parameters" 
(DH public key) are generated periodically or even on each connection.


On 09/24/2013 07:45 AM, Peter Gutmann wrote:
> Yaron Sheffer <> writes:
>> - Does any of this brittleness still apply when talking about ECDH (as
>> opposed to ECDSA), with fixed parameters?
> Probably not, in terms of brittleness.  But then if you're using fixed ECDH
> parameters (rather than, say, regenerating them once an hour and discarding
> the old ones) you've got potentially NSA-influenced values like P256 that the
> NSA has been awfully keen to get everyone to use, and that even without NSA
> skullduggery make a nice single target for attack.  So that's an entirely
> different problem.
> If you do want to generate your own ECDH parameters (i.e. curves), that's
> another huge mess to deal with.  For DH you just use Lim-Lee and you're done
> (although the fact that TLS doesn't communicate the 'q' value is something I'd
> really like to see corrected), while for ECC you need to get an awful lot of
> special-case checks and conditions just right.
> Then, once you've done that, you get to find out how many implementations
> support the arbitrary_explicit_prime_curves format, which I suspect is pretty
> close to zero.
> Peter.
> _______________________________________________
> TLS mailing list