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 <hous...@vigilsec.com>: > Peter: > > > Achim Kraus <achimkr...@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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
