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

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Dec 2018 18:59:07 +0000

Hiya,

Thanks for writing this, I would support it
being progressed if we conclude that it's
feasible and not easily defeated.

My main concern is that a server playing a
draft-green-like game could just choose DH
values more cleverly and avoid detection.
E.g. if the DH values are derived via some
function so that public shares never recur,
or only rarely. (And while such derived DH
values would in a sense represent the server
borking its own crypto, that's basically what
draft-green suggested anyway, so one might
expect a DH borking adversary in such cases
to not care so much about the client's
security.)

I guess that testing would also be an issue
so it'd be great if someone was to try do
that to check if this might break things.
(Which'd be useful in any case if it found
some servers accidentally re-using.)

Other than that, some more minor comments:

It'd be good to describe in detail a way in
which one might efficiently retain the client
state required, e.g. via a bloom filter maybe?
(Assuming an occasional false positive isn't
too alarming;-)

It might also be good to outline how a survey
or CT-like mechanism (say logging some value
as a witness for the DH public) could be used
to detect this kind of badness even if common
TLS clients didn't deploy.

I think in 3.2 you need to be a bit more
precise about which DH values you mean, e.g.
if doing ESNI then clients will see the same
DH value from ESNIKeys a number of times. (So
I suspect you couldn't implement this at a
very low level in the crypto engine.)

"MUST avoid accidental" is an interesting
phrase:-)

Section 4 could probably do with some text
about how not to do this, e.g. keeping a list
of {servername,[DH values]} would be bad if
a client's disk were compromised.

Cheers,
S.

---

From: R duToit <[email-masked]>
Date: Wed, 05 Dec 2018 14:19:57 -0500

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 <[email-masked]> wrote ---- Hiya, Thanks for writing this, I would support it being progressed if we conclude that it's feasible and not easily defeated. My main concern is that a server playing a draft-green-like game could just choose DH values more cleverly and avoid detection. E.g. if the DH values are derived via some function so that public shares never recur, or only rarely. (And while such derived DH values would in a sense represent the server borking its own crypto, that's basically what draft-green suggested anyway, so one might expect a DH borking adversary in such cases to not care so much about the client's security.) I guess that testing would also be an issue so it'd be great if someone was to try do that to check if this might break things. (Which'd be useful in any case if it found some servers accidentally re-using.) Other than that, some more minor comments: It'd be good to describe in detail a way in which one might efficiently retain the client state required, e.g. via a bloom filter maybe? (Assuming an occasional false positive isn't too alarming;-) It might also be good to outline how a survey or CT-like mechanism (say logging some value as a witness for the DH public) could be used to detect this kind of badness even if common TLS clients didn't deploy. I think in 3.2 you need to be a bit more precise about which DH values you mean, e.g. if doing ESNI then clients will see the same DH value from ESNIKeys a number of times. (So I suspect you couldn't implement this at a very low level in the crypto engine.) "MUST avoid accidental" is an interesting phrase:-) Section 4 could probably do with some text about how not to do this, e.g. keeping a list of {servername,[DH values]} would be bad if a client's disk were compromised. Cheers, S. _______________________________________________ TLS mailing list [email-masked] https://www.ietf.org/mailman/listinfo/tls

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Dec 2018 14:34:44 -0500

> On Dec 5, 2018, at 2:19 PM, R duToit <[email-masked]> 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 case in OpenSSL that it was all to easy to re-use (EC)DHE keys.

This is no longer the case, and if that survey were repeated today,
servers not running unpatched EOL code would not re-use (EC)DHE keys.
I rather expect the amount of re-use is much lower now, and will be
essentially zero in the next couple of years (as most of the remaining
outdated software is replaced).

Some Internet metrics can change in just a few years.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Dec 2018 13:35:06 -0600

> values more cleverly and avoid detection.

We can forbid static server DH keys, and should attempt to preclude them
by encouraging clients to do _some_ work to detect them.

We can preclude Dual_EC style escrow systems by not providing a way to
publish enough material on the wire for an eavesdropper with access to
the Dual_EC secrets to recover the keys.  Dual_EC style escrow systems
are not protocol-neutral.

We can forbid extension/ciphersuite registration for key escrow schemes.
We'd have to direct experts designated for Expert Review to look for
the possibility that an extension or ciphersuite could be used for
in-band key escrow.

But we can't preclude protocol-neutral (out-of-band) key escrow schemes.
These are not detectable (implementation fingerprinting can always be
defeated).

> to not care so much about the client's

Such a scheme requires some sort of counter to appear on the wire,
similar to Dual_EC.  With no nonces, this can't be done.  But with small
enough counters it will be difficult to preclude their appearance (or
the appearance of a truncated counter, which would require some brute
force on the part of the escrow agents, again like Dual_EC) as there
will always be freedom to express some small number of arbitrary bits
in-band.

> TLS clients didn't deploy.

Providing a way for clients to report what they see would have serious
privacy concerns that, IMO, outweigh the static server DH key concerns.

And none of this would help detect/preclude out-of-band escrow systems.
Client-side detection of static/reused server DH keys will simply push
server operators who must escrow to use undetectable out-of-band escrow,
thus wasting all work on client-side detection.

Nico
--

---

From: R duToit <[email-masked]>
Date: Wed, 05 Dec 2018 14:47:03 -0500

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 reusing TLS 1.3 keyshare values when under DoS attack? --Roelof ---- On Wed, 05 Dec 2018 14:34:44 -0500 Viktor Dukhovni <[email-masked]> wrote ---- > On Dec 5, 2018, at 2:19 PM, R duToit <[email-masked]> 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 case in OpenSSL that it was all to easy to re-use (EC)DHE keys. This is no longer the case, and if that survey were repeated today, servers not running unpatched EOL code would not re-use (EC)DHE keys. I rather expect the amount of re-use is much lower now, and will be essentially zero in the next couple of years (as most of the remaining outdated software is replaced). Some Internet metrics can change in just a few years. --     Viktor. _______________________________________________ TLS mailing list [email-masked] https://www.ietf.org/mailman/listinfo/tls

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 07 Dec 2018 03:37:25 +0300

On Wed 2018-12-05 18:59:07 +0000, 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 has no
knowledge of.

The question for TLS implementers is what to do about risks or leakage
that they *can* become aware of.

> It'd be good to describe in detail a way in which one might
> efficiently retain the client state required, e.g. via a bloom filter
> maybe?  (Assuming an occasional false positive isn't too alarming;-)

Yes, that would be great.  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.

Given that the size of the set of elements to include is effectively
infinite, standard Bloom filters seem likely to be trouble (way too fast
to converge onto false-positives).

Perhaps "stable bloom filters" would represent a better tradeoff:

  http://webdocs.cs.ualberta.ca/~drafiei/papers/DupDet06Sigmod.pdf

But hm, even a 0.1% false positive rate sounds pretty alarming too.  1
in a thousand connections failing?  yikes!  I think we'd want to err on
the false-negative side for this particular use case.

> It might also be good to outline how a survey or CT-like mechanism
> (say logging some value as a witness for the DH public) could be used
> to detect this kind of badness even if common TLS clients didn't
> deploy.

oof, CT itself is *really* heavyweight, and given our overall failure to
get any sort of monitoring that would detect abuse by the CT logs
themselves working (gossip hasn't had the necessary traction), i'm not
sure i have the stamina to go down that route for ephemeral DH values.

If someone wants to try to think that through (how do you ensure it's
not spammed?) i'd be happy to see it as a separate draft, but i don't
think it belongs in this one, which is intended as guidance for TLS
endpoint implementations.

> I think in 3.2 you need to be a bit more precise about which DH values
> you mean, e.g.  if doing ESNI then clients will see the same DH value
> from ESNIKeys a number of times. (So I suspect you couldn't implement
> this at a very low level in the crypto engine.)

Yes, that's absolutely right.  Proposals for text welcome!

> "MUST avoid accidental" is an interesting phrase:-)

good catch, i'll drop "accidental" :)

> Section 4 could probably do with some text about how not to do this,
> e.g. keeping a list of {servername,[DH values]} would be bad if a
> client's disk were compromised.

right, this would align with the bloom filter (or whatever)
implementation guidance you mention above.  I've been thinking about
this, and i'm not sure that we even need servername as part of the key.
is there any reason that a client should ephemeral DH reuse *across*
hosts?  If anything, ephemeral DH reuse across hosts *proves* that a DH
secret has been shared (wittingly or unwittingly), which is one of the
things we're trying to avoid, right?  Simpler implementations are
probably better, and it's certainly easier to not deal with the
servername.

        --dkg

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Dec 2018 00:22:47 -0600

> that they *can* become aware of.

Sure.

> and hadn't even considered bloom filters), so i welcome suggested text.

False negatives are OK here.  False positives... depends on whether the
application / library can reconnect and retry.  (I doubt we'd add a TLS
extension by which the client can ask to retry with a fresher server eDH
key...)

When false positives are not OK a Bloom filter check prior to doing a
slower check that has no false positives is a good optimization.  But
let's assume the client can reconnect and retry, no?  If not then just
write all the eDH keys seen to a circular log and on Bloom filter
positive just do a linear search on the log.

Another possibility is to not fail on false positive but to mark a
server as "needs watching like a hawk" and use a more appropriate data
structure (w/o false positives) to watch it for a while.  When you catch
a server cheating with that data structure, then fail hard.

>   http://webdocs.cs.ualberta.ca/~drafiei/papers/DupDet06Sigmod.pdf

Nifty.

Another option is Scalable Bloom Filters.  Basically, when a filter gets
full-ish, you close it to additions and add a new filter, thenceforth
checking all the closed filters and the one open filter.  Delete filters
older than some number of days, and you limit storage use.

Looks like both Scalable and Stable BFs would fit the bill in terms of
limiting storage use and false positive rate.

> the false-negative side for this particular use case.

Depends on whether the client can retry, or whether you can do something
other than fail (see above).

> sure i have the stamina to go down that route for ephemeral DH values.

+1

> probably better, and it's certainly easier to not deal with the

You're right, the server name isn't needed.  In principle eDH keys
should be large enough and all randomly generated.  The chances of reuse
anywhere, ever, should be very small.

This would help detect RNGs with shared seeds.  Remember the bad RNG in
OpenSSL in Debian, about a decade ago?  Yeah, let's not have that happen
again.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 7 Dec 2018 06:31:21 +0000

Daniel Kahn Gillmor <[email-masked]> 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 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
again you can detect it, but if they generate slightly different values from a
fixed seed or start point you're not going to be able to detect it unless you
know what they're doing.

Not to mention a NOBUS DHE public value if they really want to be crafty.  In
other words if someone wants to middlebox TLS, they're going to do it no
matter how much people may dislike it.

Peter.

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Dec 2018 00:47:45 -0600

> fixed seed or start point you're not going to be able to detect it unless you

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.

Indeed, the client cannot detect the use of a fixed seed and counter
shared with an escrow agent.

> matter how much people may dislike it.

No argument there.  There's nothing wrong with server-side key escrow if
that's what the server operator wants.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 7 Dec 2018 07:14:17 +0000

Nico Williams <[email-masked]> 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 other end if you can fake it with something as
lightweight as a mod-add or similar it's essentially free while defeating DHE-
reuse detection.

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
raspberries at ETSI.  

Some years ago a draft was rejected by, of all places, PKIX, for being
"workgroup posturing", and that's what this seems to be.  The IETF could make
its point by releasing a statement saying they don't support what ETSI is
doing, but getting into an arms race you know you can't win seems like, well,
workgroup posturing.

Peter.

[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.

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Dec 2018 10:48:08 -0600

> lightweight as a mod-add or similar it's essentially free while defeating DHE-

Fair.

> measures to strengthen TLS), but this draft reads a lot like the IETF blowing

That's my take as well.  However, the possibility of detecting stuck
RNGs like the Debian OpenSSL debacle of ten years ago is interesting.
Still, it's more complexity for clients.

Nico
--

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 08 Dec 2018 06:22:57 +0300

> measures to strengthen TLS), but this draft reads a lot like the IETF blowing

hm, it's true that i'm not happy with ETSI's decision-making process
here, but my goal with the draft is to provide a measure of defense for
TLS clients on the public Internet who might accidentally/unknowingly
come into contact with some errant eTLS server implementation that has
escaped the enterprise data center, and not realize it.  If you want to
suggest ways to reduce the raspberry-blowing-ness of it, i'm all ears.

My initial (unpublished) copy of the draft didn't contain the "Problems
with static DH" section at all, it was just a quick set of guidance on
how to mitigate the risks introduced by this potential ecosystem change.

I added the "Problems" section because i wanted to document the very
real concerns; it's not a raspberry-blowing doc for the sake of
rasberries.

> but getting into an arms race you know you can't win seems like, well,
> workgroup posturing.

Another way that someone who wants to leak secrets could leak them would
be to use a bad FFDHE group and small subgroup during key exchange
(indeed, this can happen by accident in some cases), or by enabling and
encouraging the use of export ciphersuites.  But we discourage people
from doing bad FFDHE at a protocol level in TLS 1.2 (where arbitrary
groups are allowed) by encouraging peers to reject handshakes that are
not in the right-sized subgroup.  If you can detect that the peer is
misbehaving, shouldn't you act on it?  Otherwise, what's the point of
detection?

>     found out when I turned on non-DHE checking some years ago.

Is this SCADA gear running TLS 1.3?  is it clients and servers both, or
just one or the other?  When was this scan done?  i'd love to see more
documentation about this practice.

        --dkg

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 8 Dec 2018 05:21:35 +0000

Daniel Kahn Gillmor <[email-masked]> writes:

>Is this SCADA gear running TLS 1.3?  is it clients and servers both, or just
>one or the other?  When was this scan done?  i'd love to see more

No, it'd be mostly 1.0, moving slowly to 1.2 at some stage (I spend a fair
chunk of yesterday debugging a handshake failure that turned out to be the
fact that the current, most-recent release of the code in a fairly significant
code base can't understand anything newer than TLS 1.0).  It wasn't a rigorous
scan, it just got enabled for a new release and then there were enough
complaints about it breaking things that it got removed again.

I don't really know if it's possible to do any kind of useful survey of the
SCADA environment because most of it is invisible to the public internet, you
just try various things on a small basis and if no-one complains, push it out
to more and more users and hope you don't get complaints.  Sometimes things
break, for example within the last month we had a customer who thought "USA"
was a valid ISO 3166 country code:

231  12:       SET {
233  10:         SEQUENCE {
235   3:           OBJECT IDENTIFIER countryName (2 5 4 6)
240   3:           PrintableString 'USA'
       :           }
       :         }

Since no-one seems to check whether the C= component in a DN is a valid
country or even looks like a valid C= component, it hadn't been noticed
before.  No idea what would have ended up in there if they were in Saint
Vincent and the Grenadines or the Federated States of Micronesia.

Anyway, I don't have any real data, just that it was common enough that we had
to remove the check again.  When I talk about SCADA stuff and it sounds rather
anecdotal that's because it usually is, you enable a new feature and if you
don't get complaints, leave it enabled, but that's as far as it goes in terms
of coverage.

Peter.

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 8 Dec 2018 08:05:57 -0800

>     found out when I turned on non-DHE checking some years ago.

I think these concerns can largely be addressed by ECDHE with e.g. X25519:

https://eprint.iacr.org/2015/343.pdf

This implementation does variable-base X25519 scalar multiplication in
13,900,397 cycles, or ~0.869s on a 16MHz AVR CPU commonly found on
Arduinos. I imagine fixed-base scalar multiplication can be further
optimized.

-- 
Tony Arcieri

---

From: Töma Gavrichenkov <[email-masked]>
Date: Sat, 8 Dec 2018 19:49:14 +0300

On Wed, Dec 5, 2018 at 10:47 PM R duToit <[email-masked]> 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 operation
of a server (or a client, because a client could be attacked too)
under a DDoS attack should be as close to a normal way of operation as
possible. Every single case where it's different should be seen as
opening a motivation for an attacker to hunt exactly for that
difference. E.g. if you add RTTs under an attack, then an attacker can
play with jitter, or make your server appear slower for clients than
their server (assuming the attack is ordered by your market
competition).

(This is by the way the reason why fast open wasn't a nice idea from
the DDoS mitigation perspective)

So no. TLS keyshare reuse is visible from the attacker's point of
view, so must not be done under a DDoS attack.

| Töma Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: [email-masked]
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 12 Dec 2018 08:30:44 +0000

>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 that better things exist doesn't
help much until all of the existing hardware is replaced.

Peter.