Check CAA Test Suite: https://caatestsuite.com/

It might be good to give this priority and implement this feature. I noticed that SSL Labs has been checking domains on the use of CAA for a little while now. I've also received a question about this in the mailbox from internet.nl. It seems that CAA is getting more attention.

NCSC now also recommends CAA: https://www.ncsc.nl/actueel/factsheets/factsheet-veilig-beheer-van-digitale-certificaten.html

In order to make the certificate issuing process more secure and to reduce the risk of fraudulent requests, Dienst Publiek en Communicatie (DPC) has started applying CAA policies on their self-managed DNS zones on a larger scale.

For example: https://toolbox.googleapps.com/apps/dig/?lang=nl#CAA/rijksoverheid.nl

https://tools.ietf.org/html/rfc8657 is a nice extension to CAA for restricting the validation methods and account that are permitted to issue certificates from the CA. It's supported by Let's Encrypt in staging already and they're going to be rolling it out to production at some point, hopefully in the near future. It should become available for every ACME-based CA over time.

ACME makes an ECDSA authenticated account for performing all of the issuance. You can use accounturi to pin the account and combined with DNSSEC that provides authenticated certificate issuance even with an authentication method like http-01.

This is the CAA configuration for grapheneos.org as an example:

grapheneos.org.	3600	IN	CAA	0 issue "letsencrypt.org; validationmethods=http-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/97211939"
grapheneos.org.	3600	IN	CAA	0 issue "letsencrypt.org; validationmethods=http-01; accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/16895147"
grapheneos.org.	3600	IN	CAA	0 iodef "mailto:caa@grapheneos.org"

So, for the Let's Encrypt staging server where this is already deployed, it will refuse to accept certificate issuance from any client not authenticating with the account key for the pinned account. Once they deploy it to production, it will start providing the same thing there too. It works with multiple records like this so using staging for dry run certificate issuance still works and doesn't reduce security.

So, not really available yet, but once it does get deployed by ACME-based CAs it will be possible to have a secure chain of trust from DNS. Not as good as clients enforcing TLSA but definitely a lot better than the status quo where an attacker can get a malicious certificate if they can MITM traffic between the server and CA servers.

So, once that's actually in production for ACME-based CAs and others, it could be made into a gentle recommendation as an extension beyond the baseline CAA. Once it becomes more widely available beyond Let's Encrypt, it could become a stronger recommendation. Every CA should really implement it.

"Every CA should really implement it."

Absolutely - and unfortunately that's also the weak point in CAA. Still, let's get this into 1.5...

I was under the impression that NCSC would reconsider suggesting CAA.

I was under the impression that NCSC would reconsider suggesting CAA.

Not that I know. The Dutch Standaardisatie Forum has added CAA in 2020 to the list of recommended standards in 2020. (Note that there is also a list with mandatory standards that includes for example HTTPS and DNSSEC.)

Still, let's get this into 1.5...

Ok. Latest RFC on CAA can be found here: https://tools.ietf.org/html/rfc8659

Let's make it a subtest with a recommended requirement level (i.e. so no scoring impact and orange warning /!\ in case of a fail) under the "certificate" section in the website test.

I am not fully sure how we should deal with CAA in the mail test. Because in the mail test we do not require the certificate to be published by a publicly trusted certificate authority. Furthermore we require DANE. Therfore I would suggest the CAA subtest to have an optional requirement level (i.e. no scoring impact and blue (i) in case of a fail) in the mail test (similar to"Trust chain of certificate").

https://tools.ietf.org/html/rfc8657 is a nice extension to CAA for restricting the validation methods and account that are
permitted to issue certificates from the CA.

Interesting! We might add this to the CAA subtest when the extension gets some more traction and is supported more broadly.

The only reason to add it to the mail test would be if you add optional MTA-STS support. CAA could be consider a subset of an MTA-STS test. MTA-STS isn't useful for receiving mail securely from servers enforcing DANE but it's useful to provide basic CA-based authenticated encryption from providers like Gmail not implementing DANE. In practice, a lot of people use Gmail, etc. so there's a lot of practical value in implementing it until they get their head out of the sand about DNSSEC and DANE.

My personal opinion for CAA is meh :). It doesn't offer any actual protection.

Therfore I would suggest the CAA subtest to have an optional requirement level (i.e. no scoring impact and blue (i) in case of a fail) in the mail test (similar to"Trust chain of certificate").

I would say no. Having something that is not green on the test will make people to add that to their servers. And IIRC MTA-STS is a no for internet.nl.

Even when using DANE TLSA, someone may use it with a CA intermediate or root certificate key rather than their leaf key. So, in that case, CAA could actually be useful for the mail test even with DANE TLSA as the only approach to authentication since accounturi and validationmethods provide a way to make the domain validation secure.

Personally, I deploy both DANE TLSA and MTA-STS because I want Gmail to be able to send mail that's at least secured by CA-based authentication rather than nothing.

Let's add the subtest for CAA to the "Certificate" section under "Secure connection (HTTPS)" of the website test. (Thus for now we will not add the CAA subtest to the mail test. We can decide later on that.) CAA will be a recommended (optional) subtest; failure will give a warning and there is no score impact. This is in line with NCSC-NL recommending CAA and the NL Standardisation Forum having CAA on the list with recommended (but not mandatory ) standards.

The subtest will check (1) if there's CAA record and (2) if the record data is valid. The found record data will be shown in the tech details section.

CAA is defined in RFC8659: RFC https://datatracker.ietf.org/doc/html/rfc8659
There might also be some additional useful info in the Baseline Requirements document of the CAB Forum that requires CAA checks by CA's: https://cabforum.org/baseline-requirements-documents/

Apparently XE already has done some work on thiss: https://github.com/internetstandards/Internet.nl/tree/ximon-feature-caa

RFC6844 was obsoleted by https://www.rfc-editor.org/rfc/rfc8659

@baknu already noticed RFC8659 in his comment on Mar 25, 2021, but to clarify I changed the top comment to link to RFC8659 and RFC8657.

The diff between RFC8659 and RFC6844:

7. Differences from RFC 6844

This document obsoletes [RFC6844]. The most important change is to the "Certification Authority Processing" section (now called "Relevant Resource Record Set" (Section 3), as noted below). [RFC6844] specified an algorithm that performed DNS tree-climbing not only on the FQDN being processed but also on all CNAMEs and DNAMEs encountered along the way. This made the processing algorithm very inefficient when used on FQDNs that utilize many CNAMEs and would have made it difficult for hosting providers to set CAA policies on their own FQDNs without setting potentially unwanted CAA policies on their customers' FQDNs. This document specifies a simplified processing algorithm that only performs tree-climbing on the FQDN being processed, and it leaves the processing of CNAMEs and DNAMEs up to the CA's recursive resolver.

This document also includes a "Deployment Considerations" section (Section 6) detailing experience gained with practical deployment of CAA enforcement among CAs in the WebPKI.

This document clarifies the ABNF grammar for the issue and issuewild tags and resolves some inconsistencies with the document text. In particular, it specifies that parameters are separated with semicolons. It also allows hyphens in Property Tags.

This document also clarifies the processing of a CAA RRset that is not empty but that does not contain any issue or issuewild tags.

This document removes the section titled "The CAA RR Type," merging it with "Mechanism" (Section 4) because the definitions were mainly duplicates. It moves the "Use of DNS Security" section into Security Considerations (Section 5). It renames "Certification Authority Processing" to "Relevant Resource Record Set" (Section 3) and emphasizes the use of that term to more clearly define which domains are affected by a given RRset.

Let's Encrypt has supported CAA account and method binding since December 2022. I forgot to mention that here at the time. We use this for all the GrapheneOS domains.

https://community.letsencrypt.org/t/enabling-acme-caa-account-and-method-binding/189588