Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Sat, Feb 19, 2022 at 04:28:52PM -0500, Ryan Sleevi wrote: > On Sat, Feb 19, 2022 at 6:15 AM Ilari Liusvaara > wrote: > > > > - Connection re-establishment affects the security and privacy > > > assumptions and should be captured. I am not sure the concern is > > > worse than the regular fingerprinting text already in the draft, > > > but point taken. We can improve the text and I created an issue > > > for it. > > https://github.com/csosto-pk/tls-suppress-intermediates/issues/12 > > > > Regarding security and privacy, the most severe impact of any attack > > I can come up with is determining if some arbitrary ICA is on the > > ICA list or not (for passive attacks, that is restricted to the issuing > > ICA used by the server). Practical impact of attacker being able to do > > that depends on how many endpoints share that same ICA list. > > > > Rough outline of the attack (active variant): Fabricate a certificate > > purporting to be from some ICA, send it to client and observe if the > > client retries (ICA not on the list) or just fails (ICA is on the list). > > > I'm hopeful that some may be interested to perform a more thorough > analysis. We saw enough complexity with respect to previous TLS versions > and the fallback logic being possible to induce downgrade attacks that I > think we should be very wary about introducing a class of anticipated > handshake failures that require connection re-establishment, especially > across independent TLS sessions. I realize that sounds a little like FUD, > but rather: every time we've tried to do this, it's blown up spectacularly, > so we need to make sure we're not setting up another bomb. I have hard time seeing how one could construct downgrade attack out of this, as it just requests extra data from server on fallback. For most other retry stuff, downgrade attack risk is obvious as less secure modes are introduced / more secure modes are removed. > I also think the active attack analysis is a bit lacking, especially since > the attacker has the ability to mint arbitrary ICAs on demand, without > running afoul of any existing client policies. For example, for the Web > PKI, by virtue of nameConstraints without pathLen in the basicConstraints, > the site can mint arbitrary ICAs and arbitrary EE certificates. Combined > with the discovery mechanism discussed, this is effectively the same as > other forms of stateful tracking (ala HSTS tracking), and thus likely to be > subjected to the same mitigations that would largely render the benefits > here ineffective, at best. Having pathLen >= 1 would do as well, right? And such ICAs can already be abused for tracking if the browser does transvalidity. Suppress ICAs flag would make it worse, by allowing other sites to read such tracking supercookies. Defense is not doing transvalidity nor cached AIA chasing (since those caches represent state that could be attacked). This closes the attack for both with and without suppress ICAs. Another defense to make reading ICA list harder would be to always trigger fallback if certificate validation fails and ICAs were suppressed. Neither defense would render suppress ICAs ineffective, since in vast majority of cases one can use quasi-static ICA list to buld verifiable certificate chain and then use that with no fallback. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-aviram-tls-deprecate-obsolete-kex-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Deprecating Obsolete Key Exchange Methods in TLS Authors : Carrick Bartle Nimrod Aviram Filename: draft-aviram-tls-deprecate-obsolete-kex-01.txt Pages : 20 Date: 2022-02-25 Abstract: This document makes several prescriptions regarding the following key exchange methods in TLS, most of which have been superseded by better options: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-aviram-tls-deprecate-obsolete-kex-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-aviram-tls-deprecate-obsolete-kex-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
On Fri, Feb 25, 2022 at 11:17 AM Ilari Liusvaara wrote: > I have hard time seeing how one could construct downgrade attack out of > this, as it just requests extra data from server on fallback. For most > other retry stuff, downgrade attack risk is obvious as less secure modes > are introduced / more secure modes are removed. I think I’m raising a question about whether or not implementations will actually do this, and arguably, to explicitly specify this if this is the expectation. In theory, yes, if the only thing changing in a fallback is an optional flag, it “shouldn’t” have concerns. In practice, however, these sorts of fallbacks (e.g. various server bug workarounds) introduce compositions that cause new and unexpected interactions. This is why the ecosystem has tried very hard to avoid fallbacks (c.f. TLS 1.3) and ensuring that both parties are able to commit to the negotiation. We saw this with the renegotiation issues getting confused state from the initial handshake. Having pathLen >= 1 would do as well, right? Sure, “without pathLen constraints” And such ICAs can already be abused for tracking if the browser does > transvalidity. Suppress ICAs flag would make it worse, by allowing other > sites to read such tracking supercookies. Transvalidity was never something widely supported outside of a specific product/library (Mozilla NSS). But yes, this is the point: this feature gives a much stronger signal. Defense is not doing transvalidity nor cached AIA chasing (since those > caches represent state that could be attacked). This closes the attack > for both with and without suppress ICAs. I fail to see how it closes it without suppress ICAs, particularly because the current draft very explicitly suggests caching as a possibility. And yes, implementations that wish to mitigate cross-context tracking are working to isolate those caches, and this was my point: doesn’t this isolation defeat the benefits of the caching / the likelihood of intermediate omission succeeding, and functionally mean that there needs to be a reliable, semi-real-time distribution mechanism for intermediates to achieve the benefits? I’m trying to look at this from a systems perspective, and tease out explicitly: what is this solution assuming exists in order to achieve the desired effect, and with those assumptions, are there simpler/less-risky/alternative technical solutions? Not to bikeshed, but because the design assumptions here are unstated and have practical and meaningful ecosystem effect, and so we at least owe that much. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] tls - Requested session has been scheduled for IETF 113
Dear Sean Turner, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:00 requested) Wednesday, 23 March 2022, Morning Session I 1000-1200 Room Name: Grand Park Hall 3 size: 250 - iCalendar: https://datatracker.ietf.org/meeting/113/sessions/tls.ics Request Information: - Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): Number of Attendees: 120 Conflicts to Avoid: People who must be present: Benjamin Kaduk Christopher A. Wood Eric Rescorla Joseph A. Salowey Nick Sullivan Rich Salz Sean Turner Yoav Nir Resources Requested: Special Requests: - ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
> I only have some isolated random datapoints on number of disclosed WebPKI > ICAs since 2021-02-08 (a bit over year ago), but during that time, that > number has grown from 1669 to 1820. Thx Ilari. Understood. We are looking into how we could quantify how the complete ICA list changes over time in order to evaluate TBD3. Probably it would be in the days to weeks timeline than years, but that remains to be seen. Of course that would not cover usecases other than WebPKI, but probably that is the more dynamic one. -Original Message- From: TLS On Behalf Of Ilari Liusvaara Sent: Saturday, February 19, 2022 6:15 AM To: tls@ietf.org Subject: RE: [EXTERNAL] [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Sat, Feb 19, 2022 at 03:59:23AM +, Kampanakis, Panos wrote: > - If we can assume an OOB mechanism to load the ICAs then we can > simplify things. Practically we can assume there is no failure. > Agreed, but I am not sure that we should not include any non-normative > language for the inadvertent corner case though. > There should be a fallback, one that we are assuming will never > happen, but an implementer should account for it. It seems to me that the dominant failure modes are: - Using old ICA list that is missing some newly minted ICA. - Using custom TA that is missing ICA data. > - Connection re-establishment affects the security and privacy > assumptions and should be captured. I am not sure the concern is worse > than the regular fingerprinting text already in the draft, but point > taken. We can improve the text and I created an issue for it. > https://github.com/csosto-pk/tls-suppress-intermediates/issues/12 Regarding security and privacy, the most severe impact of any attack I can come up with is determining if some arbitrary ICA is on the ICA list or not (for passive attacks, that is restricted to the issuing ICA used by the server). Practical impact of attacker being able to do that depends on how many endpoints share that same ICA list. Rough outline of the attack (active variant): Fabricate a certificate purporting to be from some ICA, send it to client and observe if the client retries (ICA not on the list) or just fails (ICA is on the list). > I would be interested to track how that ICA list has been changing > over time. Let’s see if we can get data on that for FFs preload list, > Filippo’s or others. I only have some isolated random datapoints on number of disclosed WebPKI ICAs since 2021-02-08 (a bit over year ago), but during that time, that number has grown from 1669 to 1820. -Ilari ___ 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
