Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-12 Thread Peter Gutmann
Tony Arcieri writes: >I think these concerns can largely be addressed by ECDHE with e.g. X25519: Sure, and they could be addressed even better with LoRaWAN security, which is even more efficient, however given that the current common denominator for the user base appears to be TLS 1.0, the fact

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-08 Thread Töma Gavrichenkov
On Wed, Dec 5, 2018 at 10:47 PM R duToit wrote: > 2. The DoS (prevention) engineers should also weigh in on this. Would > servers not start reusing TLS 1.3 keyshare values when under DoS attack? DDoS (mitigation) engineer here, I'll reiterate the idea I've raised before in quic-wg. The operati

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-08 Thread Tony Arcieri
On Thu, Dec 6, 2018 at 11:14 PM Peter Gutmann wrote: > [0] "In principal" because there's a fair bit of SCADA gear that does this > because it doesn't have the CPU power to generate new DHE values, as I > found out when I turned on non-DHE checking some years ago. > I think these concern

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-07 Thread Peter Gutmann
Daniel Kahn Gillmor writes: >> [0] "In principal" because there's a fair bit of SCADA gear that does this >> because it doesn't have the CPU power to generate new DHE values, as I >> found out when I turned on non-DHE checking some years ago. > >Is this SCADA gear running TLS 1.3? is it

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-07 Thread Daniel Kahn Gillmor
On Fri 2018-12-07 07:14:17 +, Peter Gutmann wrote: > I appreciate that people feel strongly about this, and I support the idea of > non-ephemeral DHE detection in principal [0] (along with many, many other > measures to strengthen TLS), but this draft reads a lot like the IETF blowing > raspber

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-07 Thread Nico Williams
On Fri, Dec 07, 2018 at 07:14:17AM +, Peter Gutmann wrote: > It depends on what those resources are, at one end you've got proper DHE with > a full modexp required, at the other end if you can fake it with something as > lightweight as a mod-add or similar it's essentially free while defeating

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-06 Thread Peter Gutmann
Nico Williams writes: >If it's different then that's costing the server the resources to generate >it, which is precisely what its operator didn't want when they enabled eDH >key reuse. It depends on what those resources are, at one end you've got proper DHE with a full modexp required, at the o

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-06 Thread Nico Williams
On Fri, Dec 07, 2018 at 06:31:21AM +, Peter Gutmann wrote: > Aren't you going to get into an adversarial machine learning problem where > your recogniser has to be smarter than the other side's DH-reuse code? In > other words if the server just reuses the same DHE public value again and > agai

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-06 Thread Peter Gutmann
Daniel Kahn Gillmor writes: >the way i was going to write it that guidance was pretty dumb (i was thinking >of just a hashtable combined with a fixed-size ring buffer to be constant- >space and roughly constant-time, and hadn't even considered bloom filters), >so i welcome suggested text. Aren't

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-06 Thread Nico Williams
On Fri, Dec 07, 2018 at 03:37:25AM +0300, Daniel Kahn Gillmor wrote: > On Wed 2018-12-05 18:59:07 +, Stephen Farrell wrote: > > it's feasible and not easily defeated. > > TLS endpoints can share their data (key material, cleartext, etc) with > whoever they choose -- that's just how the univers

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-06 Thread Daniel Kahn Gillmor
On Wed 2018-12-05 18:59:07 +, Stephen Farrell wrote: > it's feasible and not easily defeated. TLS endpoints can share their data (key material, cleartext, etc) with whoever they choose -- that's just how the universe is implemented. They can even do it out of band, on a channel that the peer

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-05 Thread R duToit
1. Perhaps the kind folks at Qualsys ssllabs.com have some recent stats for us, given that they track DH reuse under "Protocol Details" when you run their  https://www.ssllabs.com/ssltest/analyze.html tool. 2. The DoS (prevention) engineers should also weigh in on this.  Would servers not start r

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-05 Thread Nico Williams
On Wed, Dec 05, 2018 at 06:59:07PM +, Stephen Farrell wrote: > My main concern is that a server playing a > draft-green-like game could just choose DH > values more cleverly and avoid detection. We can forbid static server DH keys, and should attempt to preclude them by encouraging clients to

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-05 Thread Viktor Dukhovni
> On Dec 5, 2018, at 2:19 PM, R duToit wrote: > > Quote: "As we will discuss later, we empirically find that at least 7.2% of > HTTPS domains in the Alexa Top Million reuse DHE values and 15.5% reuse ECDHE > values." That survey is now dated. Library defaults matter, and it used to be the ca

Re: [TLS] draft-dkg-tls-reject-static-dh

2018-12-05 Thread R duToit
See https://dl.acm.org/citation.cfm?id=2987480 Quote:  "As we will discuss later, we empirically find that at least 7.2% of HTTPS domains in the Alexa Top Million reuse DHE values and 15.5% reuse ECDHE values." On Wed, 05 Dec 2018 13:59:07 -0500 Stephen Farrell wrote Hiya, Thanks for