Re: [TLS] Static DH timing attack

2020-09-15 Thread Lanlan Pan
Dan Brown 于2020年9月10日周四 下午11:18写道： > *From:* TLS *On Behalf Of *Salz, Rich > > Do we need a short RFC saying “do not use static DH” ? > > > > Don’t TLS 0-RTT and ESNI/ECH via HPKE use a type of (semi)static ECDH? If > so, then an RFC to ban static (EC)DH in TLS would need to be very clear >

Re: [TLS] Static DH timing attack

2020-09-12 Thread Filippo Valsorda
2020-09-12 05:48 GMT+02:00 Peter Gutmann : > Filippo Valsorda writes: > > >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. > > > >

Re: [TLS] Static DH timing attack

2020-09-11 Thread Peter Gutmann
Russ Housley writes: >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. ... thus

Re: [TLS] Static DH timing attack

2020-09-11 Thread Peter Gutmann
Filippo Valsorda writes: >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

Re: [TLS] Static DH timing attack

2020-09-11 Thread Filippo Valsorda
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,

Re: [TLS] Static DH timing attack

2020-09-11 Thread Russ Housley
Peter: > Achim Kraus 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

Re: [TLS] Static DH timing attack

2020-09-11 Thread Salz, Rich
> Which, given that it's such a footgun would IMHO be a good thing, but others will probably disagree :-). Got it, thanks. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Static DH timing attack

2020-09-10 Thread Peter Gutmann
Salz, Rich writes: >Do you mean this because people will confuse DH with ECDHE ? See my reply to Achim, it's not that but because banning static-ephemeral (EC)DH will also affect all the cases where it's being applied as it if were RSA. Which, given that it's such a footgun would IMHO be a

Re: [TLS] Static DH timing attack

2020-09-10 Thread Peter Gutmann
Achim Kraus 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

Re: [TLS] Static DH timing attack

2020-09-10 Thread Salz, Rich
Much as I hesitate to disagree with Peter: > Reason the second: Telling people not to use static-ephemeral DH will mean > telling them not to use 25519 key exchange, which will make their heads > asplode. Do you mean this because people will confuse DH with ECDHE ?

Re: [TLS] Static DH timing attack

2020-09-10 Thread Hugo Krawczyk
Dan, What you suggest, namely, DH for both static and ephemeral keys is what OPTLS was about and this approach is now specified in https://tools.ietf.org/html/draft-ietf-tls-semistatic-dh-01. I was never too happy with the name semi-static for such protocol, and people may think that if static

Re: [TLS] Static DH timing attack

2020-09-10 Thread Dan Brown
From: TLS On Behalf Of Salz, Rich > Do we need a short RFC saying “do not use static DH” ? Don’t TLS 0-RTT and ESNI/ECH via HPKE use a type of (semi)static ECDH? If so, then an RFC to ban static (EC)DH in TLS would need to be very clear about not referring to these use cases of static ECDH.

Re: [TLS] Static DH timing attack

2020-09-10 Thread Achim Kraus
Am 10.09.20 um 11:23 schrieb Peter Gutmann: Reason the second: Telling people not to use static-ephemeral DH will mean telling them not to use 25519 key exchange, which will make their heads asplode. Peter. So, risking damaged heads: Does using x25519 for ECDHE is significant less secure

Re: [TLS] Static DH timing attack

2020-09-10 Thread Peter Gutmann
Salz, Rich writes: >Do we need a short RFC saying “do not use static DH” ? There are two things arguing against it: Reason the first: Static-ephemeral DH was a dumb idea when it was proposed in X9.42 more than twenty years ago and hasn't gotten any better since then. If people haven't learned

Re: [TLS] Static DH timing attack

2020-09-09 Thread Karthik Bhargavan
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

Re: [TLS] Static DH timing attack

2020-09-09 Thread Dmitry Belyavsky
I also want to remind about so called "Enterprise TLS" — if I remember correctly, they introduced this bug to their modified TLS 1.3 specification... ср, 9 сент. 2020 г., 18:04 Salz, Rich : > https://raccoon-attack.com/ > > > > Do we need a short RFC saying “do not use static DH” ? > > > > I am

[TLS] Static DH timing attack

2020-09-09 Thread Salz, Rich
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