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

It's not entirely clear what you are asking for here, but have you
looked at the key derivation in TLS 1.3?

On 16 October 2015 at 01:27, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
>
> 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
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>