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
