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
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
Re: [TLS] ETSI releases standards for enterprise security and data centre management
I like the gist of what Tony is saying. Key escrow (it should be called "secret escrow", but I digress) itself is not really the problem in a datacenter - those guys struggle to solve the key distribution problem. If it was one-server-to-one-tool then we would not be having this discussion. eTLS looks like an attempt to simplify the key distribution implementation, but at the expense of the security attributes of the TLS session. Why don't we provide a "sandbox" mechanism that would allow business-solution folks to solve the key distribution problem without directly affecting the TLS session? What I have in mind is a TLS extension that would unlock a new TLS record ContentType called "foo" (for lack of a name). All "foo" records will be completely ignored by the TLS stack, including not affecting the TLS record sequence number or crypto state. That mechanism can then be used to send in-band messages that could be picked up by inline and passive tools along the way. Mechanisms that use "foo" records could potentially be designed outside the IETF, and the TLS-WG would have no responsibility for insecure implementations of multi-party secret sharing mechanisms (although it would be good to point those engineers in the right direction). --Roelof On Wed, 05 Dec 2018 10:51:26 -0500 Tony Arcieri wrote On Wed, Dec 5, 2018 at 12:09 AM Bret Jordan wrote: Now this WG is finally starting to talk about a solution to a real problem and need. We can either address the use case and need here in the IETF, or we can let the solutions be done else where. I would personally prefer we take this work item back and solve it here in the IETF. [...] On Dec 5, 2018, at 1:18 AM, Tony Arcieri wrote: [...] It seems like with an out-of-band escrow agent, the traffic secrets could be escrowed with no changes to TLS. Note that the solution I was proposing here requires no changes to TLS. I am sure that there are many in the IETF who would be happy with people exploring solutions which don't require changes to TLS. Here are some others: Endpoint agents (OSS - commercial options are also available): https://osquery...io/ https://www.bro.org/ (now Zeek) https://wazuh.com/ Encrypted traffic analytics: https://blogs.cisco.com/security/tls-version-1-3-change-is-here-and-encrypted-traffic-analytics-has-got-your-back -- Tony Arcieri ___ 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] I-D Action: draft-ietf-tls-grease-01.txt
GREASE values should not make their way into code. The whole point is to get code used to the fact that unknown values exist. The GREASE mechanism is useful, but it will definitely make its way into code and become ossified itself. Example: https://github.com/salesforce/ja3 --Roelof On Thu, 07 Jun 2018 17:05:47 -0400 David Benjamin david...@chromium.org wrote On Thu, Jun 7, 2018 at 5:00 PM Benjamin Kaduk bka...@akamai.com wrote: On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote: Hi all, Apologies for the probably record time delay in actually updating this thing. I like the graph... apparently -00 was expired for nearly twice as long as it was valid? Oops! Per the discussion from a really really long while ago, I've rebased the document atop TLS 1.3 and added values for the many more bits added in TLS 1.3. Since TLS 1.3 has server-offered extensions, this needed a bit of reorganization. For the one-bit PSK KE values, I borrowed the pattern from draft-bishop-httpbis-grease-00. Let me know if folks have any comments. Additionally, I'm curious what folks thoughts are on the following (not incorporated into the document): 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks to parse out the "ignore/" string. Instead, what do folks think about just using two byte strings. Perhaps the same two byte pattern we're currently doing? 2) This is somewhat of a "how much badly I abuse the registries" thing. :-) I have observed one TLS implementation which just transcribed the registry directly into their source code. This was done all the way down to mapping "Reserved for Private Use" to some dedicated symbol. They successfully ignored the private use value, but the actual unallocated values for each of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and treated as syntax errors! This was just a single implementation, but it suggests GREASE works better when it's not so obviously allocated in the registry. Of course, not recording the values at all is unreasonable as we must avoid allocating the values for real. What do folks think about leaving them out of the table but instead adding a note in the registry like: "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, 0x8A8A, 0x9A9A, 0x, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are used by [[this document]] for testing implementation correctness. They should be left permanently unassigned." An implementor infinitely bad at reading may well still special-case the and defeat all these measures, but that was always the case. Rather, the goal is to find inexpensive ways to lower the failure probability. It seems inexpensive to me, but I don't know how much trouble it would cause for IANA. Unfortunately, (my understanding is that) IANA is moving towards a proper database for codepoints, and prefer to actually have all values matched up with their corresponding metadata; I expect that they would not be happy to do something like this. But, of course, we should actually ask instead of guessing I suppose the question is what the database is meant to be used for. I can imagine wanting it to be properly queryable so you can transform it into code. GREASE values should not make their way into code. The whole point is to get code used to the fact that unknown values exist. I can also imagine wanting to make it easier to allocate values mechnically. Then, yeah, you want the GREASE values in there. But the allocations need occasional human input anyway (e.g. 26 and 40), so maybe it's fine not to have those in there in a completely structured way? David ___ 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] Warning alert before TLS 1.3 ServerHello
The server sending the alert at warning level while knowing that it is about to negotiate TLS 1.3 seems to be in violation of the statement that "All alerts listed in Section 6.2 MUST be sent with AlertLevel=fatal," - that is probably more of an implementation issue. The client's reaction to the warning alert is what is ambiguous. Some TLS 1.3 client implementations will ignore the alert, while others will choke. On Thu, 10 May 2018 02:05:18 -0400 Martin Thomson martin.thom...@gmail.com wrote On Thu, May 10, 2018 at 1:48 PM Viktor Dukhovni ietf-d...@dukhovni.org wrote: I may be misreading the code, but it sure looks like the alert is only sent if the application callback for the server name extension asks OpenSSL to do that. The application can just decline the extension and let the handshake continue with a default certificate... Is the surprise that the alert is sent, or that it is a warning, or something else? It's risking a failed connection. Though perhaps not that much more than providing the client with a certificate it might not like. ___ 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
