Re: [TLS] draft-dkg-tls-reject-static-dh
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 that better things exist doesn't help much until all of the existing hardware is replaced. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 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: xima...@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 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.
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 > raspberries at ETSI. 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? > [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 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 signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 DHE- > reuse detection. Fair. > 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. 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 -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 > 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. 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. > 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. No argument there. There's nothing wrong with server-side key escrow if that's what the server operator wants. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 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.
Sure.
> > 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.
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.
> 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
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.
> 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.
Depends on whether the client can retry, or whether you can do something
other than fail (see above).
> > 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.
+1
> > 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.
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
--
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 wrote > 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 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 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). > 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.) 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. > 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;-) OK, but clients would have to share...: > 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. 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 -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
> 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 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
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 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 TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] draft-dkg-tls-reject-static-dh
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.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
