[TLS] Fwd: [pkix] Updated elliptic curve drafts

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