Re: [pkix] Updated elliptic curve drafts

[Simon Josefsson <[e-mail]>]

> 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
> <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pkix
> >