I had thought that the OCSP privacy concerns were among the reasons for the
general decline in OCSP queries issued by browsers.  In addition, part of
the rationale for development and encouragement of deployment of OCSP
stapling.

On Wed, Dec 4, 2019 at 6:12 PM Peter Bowen <pzbo...@gmail.com> wrote:

> Why not use OCSP?
>
> On Wed, Dec 4, 2019 at 3:52 PM Matthew Hardeman via dev-security-policy <
> dev-security-policy@lists.mozilla.org> 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 <
>> dev-security-policy@lists.mozilla.org> 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 <
>> > dev-security-policy@lists.mozilla.org> 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 <
>> > dev-security-policy-boun...@lists.mozilla.org
>> > > >
>> > > On
>> > > > Behalf Of Wayne Thayer via dev-security-policy
>> > > > Sent: Monday, December 2, 2019 3:29 PM
>> > > > To: Ben Laurie <b...@google.com>
>> > > > Cc: mozilla-dev-security-policy
>> > > <mozilla-dev-security-pol...@lists.mozilla.org>;
>> > > > Peter Gutmann <pgut...@cs.auckland.ac.nz>
>> > > > 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 <b...@google.com> wrote:
>> > > >
>> > > > >
>> > > > >
>> > > > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann
>> > > > > <pgut...@cs.auckland.ac.nz>
>> > > > > wrote:
>> > > > >
>> > > > >> Ben Laurie via dev-security-policy
>> > > > >> <dev-security-policy@lists.mozilla.org>
>> > > > >> 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
>> > > > dev-security-policy@lists.mozilla.org
>> > > > https://lists.mozilla.org/listinfo/dev-security-policy
>> > >
>> > > _______________________________________________
>> > > dev-security-policy mailing list
>> > > dev-security-policy@lists.mozilla.org
>> > > https://lists.mozilla.org/listinfo/dev-security-policy
>> > >
>> > _______________________________________________
>> > dev-security-policy mailing list
>> > dev-security-policy@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-security-policy
>> >
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to