Minimum issuance volume for established CAs?

[Watson Ladd]

Dear DSP participants,

Recently at the IETF a novel compression scheme for certificates was put forward. This compression scheme depends on a dictionary based on all CA certificates and intermediates. The presence of many small CAs expands this dictionary, and the benefit of small CAs is small.

Small CAs have other costs: they are unlikely to have the resources to comply with more intrusive security measures or staff that can execute the tasks required when these measures fail. Meanwhile they have the same capacity to damage the security of the webPKI as much more well resourced ones. At the same time todays small CA is tomorrow's giant and refuge should we need to distrust a big CA.

I'd like to propose that any CA that has existed for five or more years whose annual issuance volume is under 2,000 EE certs be distrusted. To avoid injuring subscribers this distrust is "mild": all existing issued certs are fine, and the entity can handle all but the BR validation for specified intermediate of a bigger CA. This prevents the user community of the CA from being left high and dry. I haven't counted how many would be affected. For clarity I think this should only be for TLS server auth mainly because that's the highest risk kind of CA.

I realize this is an inevitably controversial proposal, (I called it a can of worms at the mic)  but the guidelines already ask for a balancing task between the value to users and the risk posed by a CA. I don't think we should be afraid to put some numbers on.

Sincerely,

Watson Ladd

[Watson Ladd]

On Sat, Jul 29, 2023 at 8:35 PM Phillip Hallam-Baker
<ph...@hallambaker.com> wrote:
>
> Which compression scheme is this?

Abridge certificate compression from
https://datatracker.ietf.org/meeting/117/session/tls
>
> Why is this compression scheme likely to take off when there was no interest in pursuing my proposal or that of Rob Straddling ten years ago?
>
> I am not sure why the number of CAs would lead to issues either. Please explain.

Each CA has a root that has to be identified and an intermediate that
also needs identification. This increases the amount of data the
clients have to ship with.

Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim

[passerby184]

wouldn't they just print certificates to fill the quota? not like they actually cost them to sign things

2023년 7월 30일 일요일 오후 12시 47분 47초 UTC+9에 Watson Ladd님이 작성:

[Maria Merkel]

We could require self-reporting split between customer and CA-owned EE certificates (potentially with audits) here, but I'm not a huge fan of the idea of a set threshold. There might be smaller CAs that can justify value either way.

Maybe we could instead make this a requirement to have a root certificate in the trust store but instead allow fully outsourced intermediary certificates to be operated by these entities? They could still be revoked via OneCRL etc if they need to be removed and would have the same requirements as other CAs, but would take up less space in a compression table because fewer certificates would be needed. Of course, this would not mitigate the other security issues.

Perhaps a combination of stricter justification of value and my proposal might make sense?

Maria Merkel

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/6f09f6f3-16d8-44c6-ad34-470a234407acn%40mozilla.org.

[Phillip Hallam-Baker]

I can't see this is necessary and as a matter of policy, restricting competition for the sake of saving a few bytes on the wire... The industry has enough anti-Trust issues without people creating new ones.

Anyone who proposes an OPTIMIZATION has to be 100% compatible with the legacy.

The solution in this case is pretty clear: Only use compression for the CAs you expect it to provide a benefit for. Process the rest as normal.

[Xiaohui Lam]

Are you suggesting that WebPKI encourages large monopolies?

[Alex Cohn]

Doesn't Firefox already ship with the full content of all root certificates, and also preemptively download all known valid intermediates? Taken as a whole, these only amount to ~2000 certificates; that's not exactly a large amount of data. How much efficiency can actually be gained here?

https://blog.mozilla.org/security/2020/11/13/preloading-intermediate-ca-certificates-into-firefox/ 

Alex

[ke ju]

I don’t know where the limit proposed comes from, but it seems highly arbitrary to me and seems designed to stifle competition. Additionally, what if there are special purpose CAs who issue certs for only a select subgroup of users? They won’t be able to function in such a scheme. I am against this idea for the little benefit noted in compression. 

[Matt Palmer]

On Sun, Jul 30, 2023 at 03:12:01PM -0700, Xiaohui Lam wrote:
> 在2023年7月31日星期一 UTC+8 01:26:15<Phillip Hallam-Baker> 写道：
>
> > I can't see this is necessary and as a matter of policy, restricting
> > competition for the sake of saving a few bytes on the wire... The industry
> > has enough anti-Trust issues without people creating new ones.
>
> Are you suggesting that WebPKI encourages large monopolies?

Insofar as any barrier to competition is likely to result in more
concentration of market share than would otherwise occur, I think the answer
is absolutely "yes".

That being said, monopolisation is only one dimension to be considered
amongst others, and "not completely ruining the system security" is almost
certainly stricly more important than "prevent a monopoly" for the WebPKI,
since it is possible (although extremely undesirable) to *have* a WebPKI
with a monopoly player, while it's basically impossible to have a (usable)
WebPKI if it is fundamentally insecure and untrustworthy.

- Matt

[Peter Gutmann]

Xiaohui Lam <inao...@gmail.com> writes:

>Are you suggesting that WebPKI encourages large monopolies?

Absolutely, but it actually does more than that, the high barriers to entry
and high cost to remain have three effects:

1. Only large monopoly CAs tend to prosper (government- and corporate-backed
vanity CAs with independent funding are another matter, but then they only
issue vanity certs so barely count).

2. Everyone becomes a reseller for a CA (with minimal controls and checks and
balances) rather than a full CA (with audits and checks and balances).

3. Because of this there's an impenetrable mass of cross-certifications of
sub-CAs that make it more or less impossible to determine whether you've ever
managed to knock out a rogue player.

In effect the Web PKI selects for the worst possible type of PKI.

Peter.

[Phillip Hallam-Baker]

Which compression scheme is this?

Why is this compression scheme likely to take off when there was no interest in pursuing my proposal or that of Rob Straddling ten years ago?

I am not sure why the number of CAs would lead to issues either. Please explain.

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a93695d0-d3a0-45a8-af55-7cbe0a81fd8dn%40mozilla.org.

[Dan Collins]

Greetings,

I have read the slides at https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-abridged-certificate-compression-00

This proposal consists of two "passes".

Pass 1 replaces the full root and intermediate certificates with a short identifier (three bytes, in the slide deck). The three byte identifier is currently sufficient to uniquely support 16 million root and intermediate certificates, and if that isn't enough, an extra byte is cheap. (It's also extensible if you, for example, "reserve" identifiers with bit zero equal to b'1', allowing you to transition to a variable length encoding down the line if it somehow becomes necessary, without any ambiguity.) It seems unlikely that there are enough CAs to exhaust this anytime soon? If there are enough CAs, then make it 6 bytes instead, you'll be good for a long while.

Pass 2 creates a "compression dictionary" of common fields within a certificate, such as CRL URLs and other URLs and strings which are common to many certificates, but peculiar to a given CA. If this dictionary wishes to fully support the best possible compression for all publicly trusted certificates, then that dictionary would have to include the URLs and other peculiar strings which appear in any of those CA's certificates, making the dictionary longer and the "compressed" IDs longer due to the larger dictionary. This, I think, is the main reason why having fewer CAs would benefit the compression.

However, I would offer a few counterpoints.

First, these dictionaries are encoding information that is already specific to each CA. As hinted at in slide 16, multiple smaller dictionaries (i.e. one for each CA, or multiple options for clients to choose from) would improve compression quality. MDSP or CCADB (or whoever is standardizing these dictionaries) could choose to offer the service to specific CAs based on their market share, or could produce a few options - for example, they could produce one with only the CAs which support at least 1% of TLS connections, and call it dictionary 0x01, another with all CAs which support at least 0.1%, call it 0x02, and other which includes all publicly trusted CAs, and call it 0x04. Clients could use one byte to tell the server which dictionaries are available, and the server could use the best dictionary for their chosen CA, using one byte in the response to tell the client which dictionary it chose. Clients could choose which dictionaries to ship based on the application.

Second, this is all being discussed in the light of post quantum certificates being significantly larger than current certificates. Slide 10 shows, based on certificates today, how the "green" section can be compressed with pass 2, whereas the "red" section would be difficult or impossible to compress. However, in a post quantum certificate, I believe the red area would be significantly larger than the green area. Accordingly, the "value" of the better compression should be evaluated based on the post-quantum certificates that we will all be using hopefully quite soon, and I think the compression ratios will not be as impressive in that case due to a much larger fraction of the certificate being cryptographic data (rather than plain text).

In short, I urge caution for two reasons:

* The compression ratio may not be worth the drastic action of distrusting small CAs, when calculated using certificates with post-quantum signatures and public keys.

* If the compression ratio is worth implementing pass 2 of the proposal, it would still be less disruptive and controversial to keep the small CAs, but either decline to give them the compression benefit of this proposal, or, create multiple compression dictionaries and allow client software to choose which to ship with.

There are some other arguments in support of reducing the number of trusted small CAs, but I think they are unrelated to the topic of this thread (being the proposed compression):

* Larger post-quantum certificates will increase the size of browser/OS root certificate stores

* As Watson says, the more CAs we have, the greater the overall risk of misbehavior, and smaller CAs are less equipped to implement best practices and respond to incidents

However, I think these are separate discussions, which require their own data.

Regards,

Dan Collins

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMm%2BLwhf1wt8Dy7fh6zcLRrNzu_VrCai88_zVEpFOgyfFjSEyw%40mail.gmail.com.

[Phillip Hallam-Baker]

Excluding CAs with fewer than X certs issued would make it impossible to ever start a new CA.

Hence the anti-Trust concern.

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ca173ea8-f2c7-45c5-bc41-d107048cb4bcn%40mozilla.org.

[Rob Stradling]

> Why is this compression scheme likely to take off when there was no interest in pursuing my proposal or that of Rob Straddling ten years ago?

Hi Phill.  Our 2014 I-D [1] tackled CRL compression, whereas the new proposal [2] that Watson referred to tackles WebPKI Certificate compression.

FWIW, whilst there was interest here in pursuing our proposal [3], Mozilla ultimately achieved the same result by implementing CRLite [4] instead.

[1] https://datatracker.ietf.org/doc/draft-hallambaker-compressedcrlset/

[2] https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1111613

[4] https://blog.mozilla.org/security/2020/01/09/crlite-part-2-end-to-end-design/

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Phillip Hallam-Baker <ph...@hallambaker.com>
Sent: 30 July 2023 04:35
To: Watson Ladd <watso...@gmail.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Minimum issuance volume for established CAs?

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMm%2BLwg2fj6pP-zmktoVPyifaWQ0mQTz3ZoMW4Ld358ScRWYKA%40mail.gmail.com.