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

Alex Elsayed <> Tue, 24 September 2013 13:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A25811E8120 for <>; Tue, 24 Sep 2013 06:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f2Y2DAJEWReI for <>; Tue, 24 Sep 2013 06:37:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A419221F8EB5 for <>; Tue, 24 Sep 2013 06:37:45 -0700 (PDT)
Received: from list by with local (Exim 4.69) (envelope-from <>) id 1VOSo6-0003xv-Qc for; Tue, 24 Sep 2013 15:37:38 +0200
Received: from ([]) by with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <>; Tue, 24 Sep 2013 15:37:38 +0200
Received: from eternaleye by with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <>; Tue, 24 Sep 2013 15:37:38 +0200
From: Alex Elsayed <>
Date: Tue, 24 Sep 2013 06:37:25 -0700
Lines: 25
Message-ID: <l1s4if$od1$>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
User-Agent: KNode/4.11.1
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 13:37:51 -0000

Peter Gutmann wrote:

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

Bernstein and Lange have some interesting stuff regarding that in-progress; 
this presentation[1] points out that those very same special-case checks and 
conditions are made necessary by the types of curves chosen, and that by 
choosing complete, twist-secure Edwards curves those can largely be avoided.

However, neither of the NIST curves nor the Brainpool curves are Edwards 
curves at all due to not having an order 4 point.

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

Of course, this remains an issue.