Subject: [pkix] Updated elliptic curve drafts

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Oct 2015 22:25:31 +0200

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Oct 2015 12:19:52 -0400

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:
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 <[email-masked]> wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 16 Oct 2015 10:05:47 +0200

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

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

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 16 Oct 2015 09:07:11 -0400

Simon,

Your response matches what I was about to say in response to PHB.
How a public key carried in a cert is employed for key agreement is
the job of a WG that defines how to use the key. It is not a topic
for discussion in PKIX.

Steve