Hi Rich, I think static DH, or reusing ephemerals, has always been a weak point of TLS implementations: e.g. if you don’t validate the peer’s public value, you may leak your (reusable) private value. In principle, if implemented correctly, static DH can be ok if you don’t care about forward secrecy, but TLS 1.2 also did this weird thing of truncating the result of DH to strip leading zeroes, which leads to this attack. Retiring static DH and forbidding ephemeral key reuse in TLS 1.2 seems like the safest way forward.
Note that TLS 1.3 does not truncate the result of DH, and neither does draft-green-tls-static-dh-in-tls13, and both (should) ask for peer keys to be validated, so these issues should not apply to TLS 1.3 implementations (unless they are buggy.) -Karthik > On 9 Sep 2020, at 17:04, Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> wrote: > > https://raccoon-attack.com/ > > Do we need a short RFC saying “do not use static DH” ? > > I am probably not the only one thinking fondly of > draft-green-tls-static-dh-in-tls13 now. > > _______________________________________________ > 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
