Data on ICA list changes over time and TBD3

[csosto-pk]

It would be interesting to collect data on how ICA lists changes over time. We could focus one WebPKI since there is more data for that usecase.

We could study the changes over time in the Firefox list https://ccadb-public.secure.force.com/mozilla/MozillaIntermediateCertsCSVReport , https://github.com/FiloSottile/intermediates, or ICA in CT logs over time.

That would help us identify realistic values for TBD3.

Also, the text about TBD3 should clarify that the recommended time for WebPKI should TBD3, but other usecases may be different. A static Private PKI that rarely changes could make TBD3 months. etc.

[csosto-pk]

From Ilari

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.

[csosto-pk]

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.

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.

[csosto-pk]

David Benjamin brought up in IETF-113 that this would not work for WebPKI, maybe for other usecases. Reason being that browsers are usually not up to date and thus they will not have the latest ICA list and thus they will usually fall out of the TBD3-time and suppression will not kick in.

We could consider making TBD3 longer in order to prevent that, but then you increase the risk of a failure.

As explained in https://github.com/csosto-pk/tls-suppress-intermediates/issues/2#issuecomment-1076383064 , we probably cannot require the ICA to be TBD3 fresh. We probably have to try to eliminate failures as much as we can, but we will have to have a fallback mechanism.

• [ ] If we end up not using TBD3, then we do not need to investigate how often the ICA list changes, but we should find the diff of the ICA lists and the number of leaf certs that tie to the diffs. That should give us a feeling for how many failures would be introduced between ICA list updates @bwesterb what do you think ?

[csosto-pk]

As explained in https://github.com/csosto-pk/tls-suppress-intermediates/issues/2#issuecomment-1076383064 , we probably cannot require the ICA to be TBD3 fresh. We probably have to try to eliminate failures as much as we can, but we will have to have a fallback mechanism.

I don't see this concern: don't browsers update a lot of state already out-of-band of the normal software updates? For instance: crlite for revocations?

Yes, we could make that argument for CRLite or browser revocation blacklist whatever and Mozilla’s ICA Pre-load list. And it is a good argument.

But I guess the difference is that in these cases when the “list” is not up-to-date (I think it probably is the case for most browsers), you are not making things worse. I mean, you might miss a revoked cert but that will not cause an extra failure (you add a security concern, but not a failure. Don’t ask me which is worse). Or you might not be able to build the chain because your ICA preload list is wrong, but that connection would have failed anyway.

In our case,

• If we don’t have the freshness requirement we will introduce failures caused by the feature. Shouldn’t we avoid making things worse?
• If we require the freshness, we practically will not use it for the majority of connections because most Web clients will not be TBD3 days up-to-date. If we want the draft to help WebPKI, we probably should avoid that, right?

[csosto-pk]

From Bas

Is it the case that a browser couldn't keep the list up-to-date within a day the majority of the time?

I tend to think yes, but I may be wrong. David Benjamin seemed to suggest so.

From Martin in https://github.com/csosto-pk/tls-suppress-intermediates/issues/2#issuecomment-1076486500

If clients only need to have an update within the last week, some/many might be able to use the feature.

• [ ] I think we ought to dig deeper there. I will fire off another email yo ask David Benjamin what data he has on how stale these lists are.
• [ ] If we end up not using TBD3, then we do not need to investigate how often the ICA list changes, but we should find the diff of the ICA lists and the number of leaf certs that tie to the diffs. That should give us a feeling for how many failures would be introduced between ICA list updates @bwesterb what do you think ?

[csosto-pk]

David B. commented regarding the RBD3 freshness requirement

It's needlessly flaky for clients that don't manage to update their list. Clients that don't get updates either can't participate in this mechanism or have to drop out immediately.

It also gets complicated with user-added roots. A client may have intermediates for publicly-trusted roots preloaded, but probably doesn't have them for user-added roots. Now, you could say, oh, we assume the server knows whether it's using one the client believes is preloaded. But that makes our already rather flaky trust anchor agility story even more flaky. Publicly-accessible servers, after all, have to support more than one client.

The pre-IETF version of QUIC had a version of this mechanism, but it was much more robust. It gave names to preloaded intermediate sets. While more work to specify, I think that's a better and more robust direction to go here.

[csosto-pk]

So the idea is that you rely on the client to shut off the optimization after a period of time when stale?

Yes, but that could lead to inadvertent failures. Ryan Sleevi was pointing out that these are problematic, so we were also thinking that if there was a third party like CCADB to host these ICA lists then the server could also make a decision to send its ICAs regardless if it knows they don’t exist in the list. That should prevent even more failures.

It's needlessly flaky for clients that don't manage to update their list. Clients that don't get updates either can't participate in this mechanism or have to drop out immediately.

Right. It is a tradeoff for picking the freshness requirement TBD3-time the prevents failures but also gets to prevent sending ICAs as much as possible. We plan to study the WebPKI ICA list change frequency for the ICA list to get more concrete data before thinking about the best TBD3.

A client may have intermediates for publicly-trusted roots preloaded, but probably doesn't have them for user-added roots.

True, isn’t that usecase kind of rare though? If we manage to have a common CCADB ICA list (for WebPKI) then the server could use that to make the decision itself, but I get your point.

It gave names to preloaded intermediate sets. While more work to specify, I think that's a better and more robust direction to go here.

Agreed. We probably will investigate that with CCADB. Probably we should keep it simple if possible without defining list versions, but at the same time we want as much use as possible. If CCADB is receptive to it, I think we can come up with something.

[csosto-pk]

I think the action items left here

• [ ] Look into what TBD3-time seems like the best option. If we end up not using TBD3, then we do not need to investigate how often the ICA list changes, but we should find the diff of the ICA lists and the number of leaf certs that tie to the diffs. That should give us a feeling for how many failures would be introduced between ICA list updates @bwesterb what do you think ?
• [ ] Consider customer loaded Root use case. That looks like a rare one to me.