This is trivially detectable, and doesn't need to be addressed via any CA/B Forum work.
This particular threat model is already part of other browser certificate uses (e.g. HTTP Signed Exchanges) and already something (some) browsers monitor. As Peter Bowen mentions, OCSP and CRLs are just as equal there. On Wed, Dec 4, 2019 at 6:52 PM Matthew Hardeman <[email protected]> wrote: > Not that anyone is presently doing or would do such a thing, but... > > Imagine a CA that wanted to offer up a user/browser tracking service to > their subscriber customer. > > Is there any rule that prevents an issuing CA from having a "custom" > (hiding an identifier for the end-entity certificate) AIA URL? Such that > when the browser AIA chases, it's disclosing the fact of the AIA chase as > well as a user's IP address (and possibly some browser details) to the CA? > One could easily do it with wildcard DNS and a per-end-entity cert host > label for the AIA distribution point. > > > On Wed, Dec 4, 2019 at 4:13 PM Ryan Sleevi via dev-security-policy < > [email protected]> wrote: > >> Yes, I am one of the ones who actively disputes the notion that AIA >> considered harmful. >> >> I'm (plesantly) surprised that any CA would be opposed to AIA (i.e. >> supportive of "considered harmful", since it's inherently what gives them >> the flexibility to make their many design mistakes in their PKI and still >> have certificates work. The only way "considered harmful" would work is if >> we actively remove the flexibility afforded CAs in this realm, which I'm >> highly supportive of, but which definitely encourages more distinctive >> PKIs >> (i.e. more explicitly reducing the use of Web PKI in non-Web cases) >> >> Of course, AIA is also valuable in helping browsers push the web forward, >> so I can see why "considered harmful" is useful, especially in that it >> helps further the notion that root certificates are a thing of value (and >> whose value should increase with age). AIA is one of the key tools to >> helping prevent that, which we know is key to ensuring a more flexible, >> and >> agile, ecosystem. >> >> The flaw, of course, in a "considered harmful", is the notion that there's >> One Chain or One Right Chain. That's not the world we have, nor have we >> ever. The notion that there's One Right Chain for a TLS server to send >> presumes there's One Right Set of CA Trust Anchors. And while that's >> definitely a world we could pursue, I think we know from the past history >> of CA incidents, there's incredible benefit to users to being able to >> respond to CA security incidents differently, to remove trust in >> deprecated/insecure things differently, and to set policies differently. >> And so we can't expect servers to know the Right Chain because there isn't >> One Right Chain, and AIA (or intermediate preloading with rapid updates) >> can help address that. >> >> On Wed, Dec 4, 2019 at 5:02 PM Tim Hollebeek via dev-security-policy < >> [email protected]> wrote: >> >> > Someone really should write up "AIA chasing considered harmful". It was >> > disputed at the TLS session at IETF 105, which shows that the reasoning >> > behind it is not as widely understood as it needs to be, even among TLS >> > experts. >> > >> > I'm very appreciative of Firefox's efforts in this area. Leveraging the >> > knowledge of all the publicly disclosed ICAs to improve chain-building >> is >> > an >> > idea whose time has come. >> > >> > -Tim >> > >> > > -----Original Message----- >> > > From: dev-security-policy < >> [email protected] >> > > >> > On >> > > Behalf Of Wayne Thayer via dev-security-policy >> > > Sent: Monday, December 2, 2019 3:29 PM >> > > To: Ben Laurie <[email protected]> >> > > Cc: mozilla-dev-security-policy >> > <[email protected]>; >> > > Peter Gutmann <[email protected]> >> > > Subject: Re: [FORGED] Re: How Certificates are Verified by Firefox >> > > >> > > Why not "AIA chasing considered harmful"? The current state of >> affairs is >> > that >> > > most browsers [other than Firefox] will go and fetch the intermediate >> if >> > it's not >> > > cached. This manifests itself as sites not working in Firefox, and >> users >> > switching >> > > to other browsers. >> > > >> > > You may be further dismayed to learn that Firefox will soon implement >> > > intermediate preloading [1] as a privacy-preserving alternative to AIA >> > chasing. >> > > >> > > - Wayne >> > > >> > > [1] >> > > >> > >> https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading >> > > #Intermediate_CA_Preloading >> > > >> > > On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie <[email protected]> wrote: >> > > >> > > > >> > > > >> > > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann >> > > > <[email protected]> >> > > > wrote: >> > > > >> > > >> Ben Laurie via dev-security-policy >> > > >> <[email protected]> >> > > >> writes: >> > > >> >> > > >> >In short: caching considered harmful. >> > > >> >> > > >> Or "cacheing considered necessary to make things work"? >> > > > >> > > > >> > > > If you happen to visit a bazillion sites a day. >> > > > >> > > > >> > > >> In particular: >> > > >> >> > > >> >caching them and filling in missing ones means that failure to >> > > >> >present correct cert chains is common behaviour. >> > > >> >> > > >> Which came first? Was cacheing a response to broken chains or >> broken >> > > >> chains a response to cacheing? >> > > >> >> > > >> Just trying to sort out cause and effect. >> > > >> >> > > > >> > > > Pretty sure if broken chains caused browsers to not show pages, then >> > > > there wouldn't be broken chains. >> > > > >> > > > -- >> > > > I am hiring! Formal methods, UX, SWE ... verified s/w and h/w. >> > > > #VerifyAllTheThings. >> > > > >> > > > https://g.co/u58vjr https://g.co/adjusu *(Google internal)* >> > > > >> > > _______________________________________________ >> > > dev-security-policy mailing list >> > > [email protected] >> > > https://lists.mozilla.org/listinfo/dev-security-policy >> > >> > _______________________________________________ >> > dev-security-policy mailing list >> > [email protected] >> > https://lists.mozilla.org/listinfo/dev-security-policy >> > >> _______________________________________________ >> dev-security-policy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-security-policy >> > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
