Re: [TLS] Static DH timing attack

I feel like there should be nothing controversial in the context of TLS.
 * Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a MUST NOT, because they can't be implemented securely.
 * Reusing ephemeral shares for ECDHE and DHE ought to be a MUST NOT in all TLS versions, because it's unnecessary and has been a requirement for many attacks now.
 * Non-ephemeral ECDH ciphersuites (TLS_ECDH_*) ought to be a SHOULD NOT, because again ECDH share reuse enables a whole class of attacks.
 * FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DHE_*) ought to be a SHOULD NOT, because they are specified in a dangerous way that is not secure if shares are reused.
If any of the above are not already the case, it should be a quick and easy document.

2020-09-11 16:06 GMT+02:00 Russ Housley <housley@vigilsec.com>:
> Peter:
> 
> > Achim Kraus <achimkraus@gmx.net> writes:
> > 
> >> Does using x25519 for ECDHE is significant less secure than using it with
> >> e.g. secp384r1?
> > 
> > The NIST curves AFAIK are never used that way, it's only done with 25519
> > (there was something about it in an OpenPGP draft, but I think GPG went
> > straight to 25519 and only used ECDSA for signatures).
> > 
> > What I'm specifically referring to is DH run sideways, as someone put it
> > during the X9.42 discussion, i.e. used in static-ephemeral mode to try and
> > make it work like it's RSA.
> > 
> > In all the code audits I've done of 25519 used that way, I've never seen it
> > used correctly.  Usually there isn't just one mistake made but many of them.
> > It's such an obvious problem that that and misuse of RC4-equivalent modes/
> > algorithms like GCM and ChaCha20 are the first things I look for in crypto
> > code.
> 
> I am sure you know that ephemeral-static DH was original used for S/MIME.  The reasoning for ephemeral-static DH was not to make it work like RSA.  Rather, the idea was to provide authentication of the static DH key holder by certifying the static DH public key.  Then, the ephemeral DH key pair is generated using the parameters from the certificate.  One important aspect of this approach was to avoid picking a single group for all of the DH keys.
> 
> Russ
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 