Email or username:

Password:

Forgot your password?
Jan Schaumann

Remember the X.509 PKI? You know, the one that gave us

- "Oh wait, certificate revocation is basically all broken"
- The One Where That Dutch CA Issued A Fraudulent *.google.com Cert

and my all-time favorite:

- Honest Ahmed's Used Cars and Certificates
bugzilla.mozilla.org/show_bug.

31 comments
Jan Schaumann

It's great, because it secures virtually all web traffic, and all you have to do is get a certificate from a certificate authority -- any one at all!

Don't be picky: there are literally hundreds in your trust bundle:

Jan Schaumann

But you probably would want to allow only a very small number of CAs to do that.

What can you do?

For a while, we tried dynamic HTTP Public Key Pinning (HPKP, via the Public-Key-Pins header).

But, TOFU issues aside, that was a big footgun, so we deprecated that swiftly.

Jan Schaumann

Except, we didn't: _static_ HPKP is still very much alive, even if your company long forgot they had submitted pins several years ago:

source.chromium.org/chromium/c

Jan Schaumann

Certificate Transparency (CT) was supposed to make up for (dynamic) HPKP being deprecated, but of course that shifts the defense mechanism from _prevention_ to _detection_.

Monitoring CT logs for thousands of domains is a bitch, so ~nobody does that.

Jan Schaumann

And DANE... well. For starters it requires DNSSEC, which is like asking for Linux on the Desktop, or generally available IPv6, so... yeah.

But sure, let's use the DNS, where we have "Certificate Authority Authorization" or CAA records, specified in RFC8659, and which CAs are required to honor via CA/B Forum Ballot 187 since 2017.

Jan Schaumann

CAA records let you specify which CAs you want to authorize to issue certificates for the given domain.

This is not perfect: CNAMEs get messy quickly, and you actually have to have your act together and know which domains are used where and how, e.g., with respect to third-parties you CNAME or delegate to.

Jan Schaumann

But alright, as so often, it is what it is. Still better than allowing Honest Ahmed and his uncles and cousins to issue certs for your domains.

Let's take a look at how widely used CAA records actually are.

Jan Schaumann

I looked up CAA records for ~214 million domain names in almost 1,200 TLDs as well as across the Tranco Top 1M Domains list.

In total, fewer than 3 million domains have CAA records; fewer than 50K of the Top 1M domains. That's barely 1.4% of all TLDs (4.8% of Top 1M domains) -- not that great, adoption wise.

Jan Schaumann

For the domains that _do_ have CAA records set, the most common number of records is small, e.g., four or five CAs authorized to 'issue' and 'issuewild':

But over 900 domains have more than 20 CAA records, and a few even more than 50!

Jan Schaumann

The 'flags' field should be exactly either 0 or 128: the "Issuer Critical Flag" is bit 0 of the flags field, and not the _value_ of this field.

Unsurprisingly, many people get that wrong (with values encountered ranging from 0 to 250, with no clear indication what people might think those values mean):

Jan Schaumann replied to Jan

RFC8659 defines three different properties: 'issue', 'issuewild', and 'iodef'. That's it.

(CA/B Forum Ballots SC13 and SC14 added 'contactemail' and 'contactphone', but those aren't part of the RFC, and I only encountered 741 and 23 uses of these respectively, so let's ignore them.)

Jan Schaumann replied to Jan

Ignoring misspelled records ("issiue", "issuewld", "iodev", ...), here are the CAA records by tag:

Jan Schaumann replied to Jan

And here's the frequency of combination of these records:

Jan Schaumann replied to Jan

The 'iodef' property can have one of three methods: mailto, http, and https.

Extra l33t points go to kyhwana.org for putting a log4j canary into their CAA record.

Jan Schaumann replied to Jan

The most frequently 'iodef' records are shown here.

Pretty pleased to see Yahoo's records dominate, since setting the right CAA policy and adding default CAA records for all of Yahoo's (many) parked domains was something I pushed for at my time there. Yay! \o/

Jan Schaumann replied to Jan

But let's see what CAs everybody is authorizing via their 'issue' and 'issuewild' records.

In total, I found almost 2,200 distinct 'issue' records (for domains in all TLDs, 456 distinct for the Top 1M domains) and 878 'issuewild' records (all TLDs, 227 Top 1M).

Here are the top 20 CAs:

Jan Schaumann replied to Jan

But... let's carefully read RFC8659 again.

The 'issue' tag grants

"authorization to issue certificates containing that FQDN to _the holder of the issuer-domain-name or a party acting under the explicit authority of the holder of the issuer-domain-name_."

Jan Schaumann replied to Jan

Who is the "holder of the issuer-domain-name" for, say, geotrust.com, rapidssl.com, or thawte.com?

That's right: DigiCert.

So by specifying 'geotrust.com' in your CAA record, you are implicitly also granting the various DigiCert subsidiaries authorization, which really isn't obvious at all.

Jan Schaumann replied to Jan

If we then add up the various related CA domains, our breakdown looks more like this:

Jan Schaumann replied to Jan

Or, if you prefer Pareto charts to better illustrate the cumulative concentration:

Jan Schaumann replied to Jan

Authorizing a given CA can still be too broad for your taste, which is why RFC8657 specifies the 'accounturi' and 'validationmethods' parameter extensions.

There's also a draft extension for Signed HTTP Exchanges ('cansignhttpexchanges') that appears to only be supported by DigiCert and pki.goog.

The usage of these parameters is quite limited:

Jan Schaumann replied to Jan

In conclusion, after analyzing around 214 million domain names for CAA records, the following are worth noting:

1) CAA records are still not widely used.

Across all TLDs, only 1.4% of domains use CAA records; out of the Top 1M Domains, only 4.8%.

Considering that CAA records have been around since 2010 and honoring them has been mandatory for CAs since 2017, this seems like a pretty poor adoption rate.

Jan Schaumann replied to Jan

2) Most people don't set 'iodef'.

Those domains that do use CAA records tend to use the 'issue' and 'issuewild' records, but only minuscule fraction (0.9% of all TLDs' domains; 3.2% of the Top 1M Domains) set 'iodef'.

Jan Schaumann replied to Jan

3) Extensions are not widely used.

The dominance of the 'cansignhttpexchanges' parameter here surprised me, but could be explained by being pushed without industry agreement by Google as part of their "Accelerated Mobile Pages" (AMP) framework?

Jan Schaumann replied to Jan

And finally, and most importantly:

4) A small number of CAs dominate.

Only 7 Certificate Authorities account for over 99% of all CAA 'issue'/'issuewild' records (10 CAs for 99% of the Top 1M Domains).

3 alone account for over 75%: Comodo, DigiCert, and Let's Encrypt.

Jan Schaumann replied to Jan

Even though this only covers the small percentage of domains that do set CAA records, I would not be surprised if the overall use of CAs across all domains followed a similar -- and similarly centralized -- distribution.

(In some markets, regional players will play a bigger role; once again the inability to get access to all ccTLD zones makes this difficult to assess.)

Jan Schaumann replied to Jan

So no, you probably could replace your giant trust bundle with fewer than... 20 or so root CA certs and not notice a difference, I'd guess.

But whether that's a good thing, whether it's wise for the entire internet to place all -- well, >99% -- of its certificates/eggs into fewer than 10 CAs/baskets seems more than questionable.

Jan Schaumann replied to Jan

And that's it for today - thanks for playing "Whose Cert Is It Anyway?" โœŒ๏ธ

This thread is available as a blog post here:

netmeister.org/blog/caa-divers

Jan Schaumann replied to Jan

P.S.: This was the third blog post in a series on the centralization of the internet.

Part 1, covering NS records, can be found here:
netmeister.org/blog/nsauth-div

Or, as a Twitter thread:
twitter.com/jschauma/status/15

Go Up