Re: [FORGED] Re: How Certificates are Verified by Firefox

[Jakob Bohm via dev-security-policy]

On 2019-12-09 11:44, Ben Laurie wrote:

On Wed, 4 Dec 2019 at 22:13, Ryan Sleevi  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.



It would be a whole lot more efficient and private if the servers did the
chasing.



It would also greatly help if:

1. More clients (especially non-browser client such as libraries used by
  IoT devices) supported treating the received "chain" more like a pool
  of potential intermediaries and accepted any acceptable combination of
  received certs and locally trusted roots.  This would allow servers to
  send an appropriate collection of intermediaries for different client
  needs.  Clients that detect different levels of trust (such as the
  Qualsys checkers and EV clients) also need to choose the best of the
  offered set, as the alternative certs are obviously for use by other
  clients.  In particular, clients should not panic and block on the
  presence of any "bad" certificates in the pool, if a valid chain can
  be assembled without that certificate.
   This is already in the CMS/PKCS#7 spec and apparently also in the TLS
  1.3 spec, but remains seemingly optional when TLS 1.2 or older is
  negotiated.
   I recently became aware of at least one IoT-focused TLS library that
  doesn't support the "pool" interpretation due to lack of a memory-
  efficient chain building algorithm.

2. Certain CAs made it a lot easier to get the recommended-to-send list
  of certificates ("chain") for server operators to configure.  Some
  CAs make server operators manually chase down links to each cert in
  the list, and some don't send out pre-emptive notification of changes
  to paying subscribers.

3. Certain TLS libraries didn't refuse to provide server software
  vendors with working stapling code, especially the code to collect
  and cache OCSP responses.

P.S. One commonly wilified server brand actually does use AIA to build
  the server chain.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Ben Laurie via dev-security-policy]

On Wed, 4 Dec 2019 at 22:13, Ryan Sleevi  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.
>

It would be a whole lot more efficient and private if the servers did the
chasing.


>
> 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 
>> > Cc: mozilla-dev-security-policy
>> ;
>> > Peter Gutmann 
>> > 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  wrote:
>> >
>> > >
>> > >
>> > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann
>> > > 
>> > > wrote:
>> > >
>> > >> Ben Laurie via dev-security-policy
>> > >> 
>> > >> 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 cachei

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Ben Laurie via dev-security-policy]

On Mon, 2 Dec 2019 at 20:28, Wayne Thayer  wrote:

> 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.
>

AIA does not prevent single verifications from working, unlike caching.


>
> You may be further dismayed to learn that Firefox will soon implement
> intermediate preloading [1] as a privacy-preserving alternative to AIA
> chasing.
>

If that involves loading and using intermediates that are not actually
available via AIA, then yes.


> - Wayne
>
> [1]
> https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading#Intermediate_CA_Preloading
>
> On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie  wrote:
>
>>
>>
>> On Thu, 28 Nov 2019 at 20:22, Peter Gutmann 
>> 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)*
>>
>

-- 
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

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Ryan Sleevi via dev-security-policy]

On Sun, Dec 8, 2019 at 7:14 PM Eric Mill  wrote:

> On Thu, Dec 5, 2019 at 12:34 PM Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> From looking at better security, the 'ideal' path is that modern clients
>> are only trusting modern (new) roots, which never issued old crappy certs.
>> That is, the path "D -> A -> B -> C" is forbidden, while the path "A -> D
>> -> E -> F" is required.
>
>
> It took me a little bit to parse this, but I think I see what you mean -
> that A->D->E->F eliminates any client from having to rely on the old
> non-modern intermediate B, while allowing new clients to only trust D and
> legacy clients to only trust A. Am I summing that up right?
>

It allows clients to remove support for A and B, which may have issued
problematic certificates - and only trust D, which is a 'clean' root to the
latest standards.

This similarly allows for the evolution of root/intermediate certificate
profiles. e.g. if A was issued in 2000, D in 2010, and G in 2020, you can
be sure G reflects the best 'modern' practice.


>
>
>> Further, if you want to excise past crappy certs, a
>> modern browser would require a new root from a CA every few years, such
>> that today's "A -> D -> E -> F" becomes tomorrow's "A -> D -> G -> H -> I"
>> - where "G -> H -> I" is the path that conforms to all the modern security
>> (G will have only issued certs that are modern), while D and A are legacy
>> paths for old clients. In order to keep old clients working, a
>> precondition
>> to browsers doing the modern security thing, you need for *old* clients to
>> be able to get to D/A. And you don't want to send (in the TLS handshake)
>> "I, H, G, D" to cover all your permutations - that is terrible for
>> performance *and* security (e.g. QUIC amplification attacks).
>>
>
> For those of us who don't follow all of the attacks out there, how do
> longer chains promote QUIC amplification attacks? Is it a DoS vector
> similar to NTP amplification? Since obviously minimum chain length can
> vary, is there a threshold of cert length where the QUIC amplification risk
> goes from acceptable to unacceptable?
>

The TL;DR: is that it's standard to UDP protocols, with UDP security
protocols adding a factor to that. So yes, it's similar to UDP, or DNSEC.
https://www.cloudflare.com/learning/ddos/what-is-a-quic-flood/ is helpful.
Drafts like
https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/
exist to attempt to help with this, but there are limits to the compression
that are in part impacted by the certificate profile.


> It sounds like the reason intermediate preloading is an incomplete
> solution is primarily due to name constrained sub-CAs. How big of a
> presence are name-constrained subCAs, in terms of validation volume among
> browser clients which rely on the Web PKI?
>

I wouldn't prioritize it like this into a bucket like "primarily", no. I
think it's necessary to consider the entire ecosystem. As I mentioned, this
concern is primarily with suggesting /disabling/ AIA for players that
already enable it. It's a net-positive for Mozilla to go from nothing to
preloading, but a net-negative for those who do AIA fetching to go to
disabled.

Preloading is functionally moving from a robust and distributed system into
a centralized system. We know centralization can help privacy, by only
making the interaction with a single provider, and hopefully aligned with
users' interests. Mozilla pursuing DNS-over-HTTPS with Cloudflare (for now,
the only DoH provider) is perhaps an example of making that trade-off. But
we wouldn't say preloading is unconditionally good, especially when it
removes a lot of agility from the ecosystem.

>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Eric Mill via dev-security-policy]

On Thu, Dec 5, 2019 at 12:34 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> From looking at better security, the 'ideal' path is that modern clients
> are only trusting modern (new) roots, which never issued old crappy certs.
> That is, the path "D -> A -> B -> C" is forbidden, while the path "A -> D
> -> E -> F" is required.


It took me a little bit to parse this, but I think I see what you mean -
that A->D->E->F eliminates any client from having to rely on the old
non-modern intermediate B, while allowing new clients to only trust D and
legacy clients to only trust A. Am I summing that up right?


> Further, if you want to excise past crappy certs, a
> modern browser would require a new root from a CA every few years, such
> that today's "A -> D -> E -> F" becomes tomorrow's "A -> D -> G -> H -> I"
> - where "G -> H -> I" is the path that conforms to all the modern security
> (G will have only issued certs that are modern), while D and A are legacy
> paths for old clients. In order to keep old clients working, a precondition
> to browsers doing the modern security thing, you need for *old* clients to
> be able to get to D/A. And you don't want to send (in the TLS handshake)
> "I, H, G, D" to cover all your permutations - that is terrible for
> performance *and* security (e.g. QUIC amplification attacks).
>

For those of us who don't follow all of the attacks out there, how do
longer chains promote QUIC amplification attacks? Is it a DoS vector
similar to NTP amplification? Since obviously minimum chain length can
vary, is there a threshold of cert length where the QUIC amplification risk
goes from acceptable to unacceptable?


So what you want is "I, H" in the TLS handshake, modern clients to know G,
> and 'legacy' clients to know how to get "G" and "D" as needed. AIA is the
> best way to do that, and the most interoperable way, without requiring
> out-of-band predistribution (to *legacy* clients) about G and D.
>
> I don't disagree on the privacy concerns with AIA, but I think folks are
> overlooking the tradeoffs, complexity, or the fact that today we afford CAs
> much greater flexibility than is perhaps desirable in the structure of
> their PKIs. Intermediate preloading *is* valuable, but it does have
> limitations, and those limitations have consequences to the agility of the
> ecosystem. That's not a problem if a client is going like Firefox, from
> nothing to preloading, but it's much more complex and nuanced if a client
> is going from AIA to preloading, because that's a step to less agility.
>

It sounds like the reason intermediate preloading is an incomplete solution
is primarily due to name constrained sub-CAs. How big of a presence are
name-constrained subCAs, in terms of validation volume among browser
clients which rely on the Web PKI?


> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


-- 
Eric Mill
617-314-0966 | konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Ryan Sleevi via dev-security-policy]

On Thu, Dec 5, 2019 at 10:42 AM Nick Lamb  wrote:

> On Wed, 4 Dec 2019 17:12:50 -0500
> Ryan Sleevi via dev-security-policy
>  wrote:
>
> > Yes, I am one of the ones who actively disputes the notion that AIA
> > considered harmful.
>
> As not infrequently happens I can't agree with Ryan here. AIA chasing in
> browsers is a non-trivial privacy leak AND doesn't match how the
> specification says things work.
>

Wait, what? Is this a reference to TLS? Certainly not 5280.


> What I'd like to see, as with OCSP stapling, is for web /servers/ to
> do the fix-up not browsers. If an operator doesn't take the initiative
> to provide the server with a complete chain, it should do its own AIA
> chasing to discern the chain and then provide that chain in the TLS
> Certificate message. This obeys the specification AND makes the server
> software easier to administrate AND has few or no privacy implications


The problem, again, is that the notion of "the chain" and "a complete
chain" is a flawed assumption. This is the flaw in Ben's argument, and it's
the flaw due to the flexibility browsers afford CAs in how to design and
structure their PKI, *and* the flaw that not all browsers (or all versions
of a given browser) support the same CA.

This is trivial to work out on paper to see why the notion of "the chain"
is flawed, and because it's flawed, the server cannot do the right thing.
Further, even if we were assume to ascribe to servers the responsibility,
it would mean that clients (like browsers) could not make pro-user changes
unless/until servers updated.

Assuming you have a CA A, which signs intermediate B, which signs leaf C
A -> B -> C

Naively, or without thinking through the implications, people want servers
to send "C, B" in the TLS handshake, and let the client know it has A.

However, what happens when the CA A creates a new root, with stronger
cryptography, called D? They typically do one of the following:
D -> A -> B -> C (New root signs old root, to keep old certs working)
A -> D -> E -> F (Old root signs new root, which creates a new issuance,
where F is the leaf, E is the new stronger intermediate. Think SHA-2
migrations here, where A/B/C is SHA-1 and D/E/F is SHA-2)
A -> B -> C / D -> B' -> C (a new version of B, called B', is created,
signed by D)
[or some combination of the above]

The moment you've done this, there's no longer 'the' chain. The server that
was previously sending "C, B" is now buggy to the browser that only trusts
D, because it doesn't know about A (and thus, can't go "C, B, A" to find
D). The server that was sending "F, E" is buggy to clients that trust A,
even though it's perfectly configured to clients that trust D, because
clients that only trust A don't know how to go "F, E, D" to get to A. The
server that has to decide between B and B' is just... doomed.

Now, intermediate preloading helps here, but only to a degree.
Name-constrained sub-CAs aren't required to be disclosed by Mozilla, for
example, nor the subordinates they issue, and so intermediate preloading
won't cover those cases, and the problem still exists all the same. Maybe
the answer is "don't do name-constrained CAs" or "require their
disclosure", and that's not unreasonable, but a significant amount of
policy work (since the primary reason for name-constraining is to reduce
the responsibility and management overhead)

>From an ecosystem health perspective, we know not every client supports
root auto-updates. Even Mozilla clients don't, but this is especially
pronounced on non-Windows platforms (... including Apple). The existence of
AIA helps keeps all of this "working" - working with modern and working
with legacy. Intermediate preloading helps, but only by making the software
vendor eat the cost of the flexibility afforded to the CA, which... is
unfortunate.

>From looking at better security, the 'ideal' path is that modern clients
are only trusting modern (new) roots, which never issued old crappy certs.
That is, the path "D -> A -> B -> C" is forbidden, while the path "A -> D
-> E -> F" is required. Further, if you want to excise past crappy certs, a
modern browser would require a new root from a CA every few years, such
that today's "A -> D -> E -> F" becomes tomorrow's "A -> D -> G -> H -> I"
- where "G -> H -> I" is the path that conforms to all the modern security
(G will have only issued certs that are modern), while D and A are legacy
paths for old clients. In order to keep old clients working, a precondition
to browsers doing the modern security thing, you need for *old* clients to
be able to get to D/A. And you don't want to send (in the TLS handshake)
"I, H, G, D" to cover all your permutations - that is terrible for
performance *and* security (e.g. QUIC amplification attacks).

So what you want is "I, H" in the TLS handshake, modern clients to know G,
and 'legacy' clients to know how to get "G" and "D" as needed. AIA is the
best way to do that, and the most interoperable way, without requiring

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Nick Lamb via dev-security-policy]

On Wed, 4 Dec 2019 17:12:50 -0500
Ryan Sleevi via dev-security-policy
 wrote:

> Yes, I am one of the ones who actively disputes the notion that AIA
> considered harmful.

As not infrequently happens I can't agree with Ryan here. AIA chasing in
browsers is a non-trivial privacy leak AND doesn't match how the
specification says things work.

What I'd like to see, as with OCSP stapling, is for web /servers/ to
do the fix-up not browsers. If an operator doesn't take the initiative
to provide the server with a complete chain, it should do its own AIA
chasing to discern the chain and then provide that chain in the TLS
Certificate message. This obeys the specification AND makes the server
software easier to administrate AND has few or no privacy implications

No new standards development work is needed. Anybody can do this today,
but so far as I can tell nobody does.

I know Mozilla does outreach to server operators, but does it also do
any outreach to server software developers? Is the situation that
they've got their fingers in their ears about this, or that we aren't
yelling at the right people?

Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Ryan Sleevi via dev-security-policy]

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  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 
>> > > Cc: mozilla-dev-security-policy
>> > ;
>> > > Peter Gutmann 
>> > > 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 Fire

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Matthew Hardeman via dev-security-policy]

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 
> > > Cc: mozilla-dev-security-policy
> > ;
> > > Peter Gutmann 
> > > 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  wrote:
> > >
> > > >
> > > >
> > > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann
> > > > 
> > > > wrote:
> > > >
> > > >> Ben Laurie via dev-security-policy
> > > >> 
> > > >> write

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Ryan Sleevi via dev-security-policy]

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  >
> On
> > Behalf Of Wayne Thayer via dev-security-policy
> > Sent: Monday, December 2, 2019 3:29 PM
> > To: Ben Laurie 
> > Cc: mozilla-dev-security-policy
> ;
> > Peter Gutmann 
> > 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  wrote:
> >
> > >
> > >
> > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann
> > > 
> > > wrote:
> > >
> > >> Ben Laurie via dev-security-policy
> > >> 
> > >> 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

RE: [FORGED] Re: How Certificates are Verified by Firefox

[Tim Hollebeek via dev-security-policy]

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 
On
> Behalf Of Wayne Thayer via dev-security-policy
> Sent: Monday, December 2, 2019 3:29 PM
> To: Ben Laurie 
> Cc: mozilla-dev-security-policy
;
> Peter Gutmann 
> 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  wrote:
> 
> >
> >
> > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann
> > 
> > wrote:
> >
> >> Ben Laurie via dev-security-policy
> >> 
> >> 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



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Wayne Thayer via dev-security-policy]

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  wrote:

>
>
> On Thu, 28 Nov 2019 at 20:22, Peter Gutmann 
> wrote:
>
>> Ben Laurie via dev-security-policy 
>> 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

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Ben Laurie via dev-security-policy]

On Thu, 28 Nov 2019 at 20:22, Peter Gutmann 
wrote:

> Ben Laurie via dev-security-policy 
> 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

Re: [FORGED] Re: How Certificates are Verified by Firefox

[Peter Gutmann via dev-security-policy]

Ben Laurie via dev-security-policy  
writes:

>In short: caching considered harmful.

Or "cacheing considered necessary to make things work"?  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.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy