Feature #15637

Deploy DNS CAA

Added by cypherpunks 2018-06-05 01:18:41 . Updated 2019-11-04 19:47:57 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
2018-06-05
Due date:
% Done:

0%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Because the plan in Feature #9026 to deploy HPKP may have been hindered by Chrome’s desire to remove HPKP support, it may be a good idea to instead (or additionally) deploy CAA. It has weaker guarantees than HPKP and in particular assumes the CA to be trustworthy, but is a significant improvement over the default state. Its support has recently been mandated and now all DNS servers and CAs support it. Deployment requires nothing more than creating a new DNS record.

https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum


Subtasks


History

#1 Updated by mercedes508 2018-06-05 09:04:12

  • Assignee set to bertagaz
  • Type of work changed from Sysadmin to Discuss

#2 Updated by intrigeri 2018-06-05 10:05:31

  • Assignee changed from bertagaz to cypherpunks
  • QA Check set to Info Needed
  • Type of work changed from Discuss to Research
  • Affected tool set to Verification Extension

The initial motivation behind doing HPKP & friends was to secure a tiny bit more downloads of the Tails ISO from web browsers, so I have to ask: do browsers currently use and enforce CAA?

Anyway, this looks super cheap to implement so I say let’s just do it if we can, i.e. if boum.org’s DNS server runs recent enough software (e.g. wrt. BIND, according to https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization it was added in the version that’s in Stretch but not in Jessie).

#3 Updated by cypherpunks 2018-06-06 01:20:58

intrigeri wrote:
> The initial motivation behind doing HPKP & friends was to secure a tiny bit more downloads of the Tails ISO from web browsers, so I have to ask: do browsers currently use and enforce CAA?

Not only do they not, they are required not to, according to RFC 6844:

>A set of CAA records describes only current grants of authority to issue certificates for the corresponding DNS domain. Since a certificate is typically valid for at least a year, it is possible that a certificate that is not conformant with the CAA records currently published was conformant with the CAA records published at the time that the certificate was issued. Relying Applications MUST NOT use CAA records as part of certificate validation.

It is not the job of the browser to check this. What you are thinking of is probably DANE, which allows clients to verify a site’s authenticity via DNS records, but it is not widely deployed. CAA is designed to prevent mis-issuance. For example a bug in the ACME protocol that allows anyone to get any domain signed by Lets Encrypt would be foiled. If an attacker is able to obtain the root signing certificate of any CA, then even with CAA, we’re boned. The only thing that can protect against that is HPKP. Makes you wonder just how seriously people take key ceremonies, huh?

#4 Updated by intrigeri 2018-06-06 06:47:18

  • Assignee changed from cypherpunks to groente
  • Type of work changed from Research to Sysadmin

> intrigeri wrote:
>> The initial motivation behind doing HPKP & friends was to secure a tiny bit more
>> downloads of the Tails ISO from web browsers, so I have to ask: do browsers
>> currently use and enforce CAA?

> Not only do they not, they are required not to, according to RFC 6844: […]

OK, good point, makes sense! Thank you.

So assigning to the sysadmin on duty to inquire with boum.org if we can have that.

#5 Updated by intrigeri 2018-06-06 06:48:24

  • Status changed from New to Confirmed

#6 Updated by intrigeri 2018-06-06 06:48:33

  • blocks Feature #13242: Core work: Sysadmin (Maintain our already existing services) added

#7 Updated by groente 2018-07-09 11:05:42

  • Assignee changed from groente to cypherpunks
  • QA Check deleted (Info Needed)

sadly, CAA records are not within the current realm of possibilities.

#8 Updated by intrigeri 2018-07-10 08:58:15

  • Status changed from Confirmed to Rejected
  • Assignee deleted (cypherpunks)

For now I don’t see benefits in keeping this ticket open. Anyone who cares much about this, please come back to it in a year or so, maybe there’ll be some updates and we can have a CAA record :)

#9 Updated by intrigeri 2019-04-12 07:18:35

  • Subject changed from Deploy CAA to Deploy DNS CAA
  • Status changed from Rejected to Confirmed

According to https://sslmate.com/caa/support, the DNS server we now use supports CAA records.

#10 Updated by intrigeri 2019-06-19 08:31:41

  • blocked by deleted (Feature #13242: Core work: Sysadmin (Maintain our already existing services))

#11 Updated by sajolida 2019-11-04 19:47:57

  • Affected tool deleted (Verification Extension)