Re: [pkix] Updated elliptic curve drafts

Phillip Hallam-Baker <> Thu, 15 October 2015 16:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 387F91ACD47 for <>; Thu, 15 Oct 2015 09:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id la-x72Yjav_6 for <>; Thu, 15 Oct 2015 09:19:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20A051ACD13 for <>; Thu, 15 Oct 2015 09:19:55 -0700 (PDT)
Received: by lfaz124 with SMTP id z124so34885661lfa.1 for <>; Thu, 15 Oct 2015 09:19:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bz7NCe+7oBOJBBCNlGzNc+6HQaBe9oxwkaKjTZ5NsgA=; b=qgtB0fNi6jCqb5G2q4lGHtfnvSNBTlwe4HkvRo2UIDjTxPRq2b6tVh2Ej9JWlay2XR JGQ+zesuXsSP85M8HqNYAGSGOLjwXyfPYJZIQhPc+bzvESl/TlIELqp+B6kN9aH3d55O d9LU0RMwN1g3i3ZBfDFP4Lcr9Ju/CoVtEtkCd7KdouKTEabl3X1W2WEqBj4Ff+pnERl0 cYfElNx/3mhjet7Vq8CfYV34QxfN/hDpz3UNDiv9WceYecW7tfCtYZweEPgcjA6iwAKO Vuh0AHxFmT7GRwwiWhnvmxi/mHgxk7nwo5qJT37ZhidDVLVrHcLG8vkslWCEtb/kpNL5 w2sg==
MIME-Version: 1.0
X-Received: by with SMTP id q81mr3409584lfe.124.1444925993190; Thu, 15 Oct 2015 09:19:53 -0700 (PDT)
Received: by with HTTP; Thu, 15 Oct 2015 09:19:52 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 15 Oct 2015 12:19:52 -0400
X-Google-Sender-Auth: W13GcZJpkYSDBVfpsfj5OUBcm-M
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Simon Josefsson <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
Subject: Re: [pkix] Updated elliptic curve drafts
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Oct 2015 16:19:57 -0000

I strongly oppose any new crypto that does not include a fix for the
ephemeral keygen.

The reason logjam is possible is that the key negotiation is essentially

1) Negotiate a shared secret S1 using the strong, long term server key.
2) Use the shared secret to authenticate ephemeral key parameters Ec, Es
3) Derive the session keys S2 from the ephemeral key parameters only
and throw away the output from the strong long term keys.

It is not just 512 bit keys that are vulnerable. 1024 bit DH keys are also weak:

If we are changing the crypto suites we can and should fix this
instead of S2 being a function of Ec, Es alone, add in the original S1
as a salt.  e.g. S2 = SHA512 (S1 + f(Ec, Es))

This ensures that no matter how broken the ephemeral crypto is, the
key exchange is always at least as secure as either the long term or
the ephemeral key.

Logjam isn't the only way that the system can be compromised.

Oh and damn right I think BULLRUN might have had a part in keeping the
spec broken.

There is a right way to design an ephemeral key exchange and it is to
'Do no harm'. Logjam shows that our current key negotiation mechanism
has a hole that makes it possible for the ephemeral to do harm.

The move to the CFRG curves will mean a backwards incompatible change
to the deployed infrastructure so this is a perfect time to fix
ephemeral key establishment.

I am going to keep raising this until the issue is fixed.

On Mon, Oct 12, 2015 at 4:25 PM, Simon Josefsson <> wrote:
> Hi,
> I've updated my drafts on Curve25519/Curve448 support in PKIX to refer
> to the CFRG-Curves and CFRG-EdDSA drafts.
> The following document adds new EdDSA key/signature OIDs directly:
> The following document adds new namedCurve OIDs, thus going indirectly
> through the existing ECDSA 3279 route:
> These two drafts take different approaches to including the new curves
> into PKIX, and currently both lack applicability statements.  There is
> potential for overlap and conflict right now.  It recently came up that
> for PKCS#11 a namedCurve approach would be useful, but for normal PKIX
> Certificates, it may be that the first direct approach is preferrable.
> The former lack the possibility of encoding keys for DH.  I believe each
> approach can be useful on its own, but we need to include text adressing
> use-cases that can be resolved by both documents to avoid conflicts.
> /Simon
> _______________________________________________
> pkix mailing list