> 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 <tls-boun...@ietf.org> 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 +0000, 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
