Re: [pkix] Updated elliptic curve drafts

Simon Josefsson <simon@josefsson.org> Fri, 16 October 2015 08:06 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F306E1B304F for <pkix@ietfa.amsl.com>; Fri, 16 Oct 2015 01:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.951
X-Spam-Level:
X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSgiCkPNmrI9 for <pkix@ietfa.amsl.com>; Fri, 16 Oct 2015 01:06:12 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31621B3039 for <pkix@ietf.org>; Fri, 16 Oct 2015 01:06:11 -0700 (PDT)
Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9G85nlD030398 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 16 Oct 2015 10:05:50 +0200
Date: Fri, 16 Oct 2015 10:05:47 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Message-ID: <20151016100547.0e375a55@latte.josefsson.org>
In-Reply-To: <CAMm+LwhDmnKFGWrcXP2N5W15uiazj+SiYNQvqviXz+6Fp442xQ@mail.gmail.com>
References: <87fv1fal6s.fsf@latte.josefsson.org> <CAMm+LwhDmnKFGWrcXP2N5W15uiazj+SiYNQvqviXz+6Fp442xQ@mail.gmail.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/CHKPI.2Ikhx7BM5cDNpXTQB"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/Dmioef986UqiNuPbIMgmZ7Ra1Qw>
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix] Updated elliptic curve drafts
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 08:06:14 -0000

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

How is that concern relevant for a new PKIX signature/publickey
algorithm?  I would assume this is relevant for TLS, OpenPGP, CMS, or
other higher level protocols, but I don't follow how anything could be
done at the PKIX level to help here.  Can you elaborate please?

/Simon

> 
> 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:
> https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/
> 
> 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
> <simon@josefsson.org> 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:
> >
> > https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04
> >
> > The following document adds new namedCurve OIDs, thus going
> > indirectly through the existing ECDSA 3279 route:
> >
> > https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01
> >
> > 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
> > pkix@ietf.org
> > https://www.ietf.org/mailman/listinfo/pkix
> >