1519560 - Add CAA DNS record for product domains

Status: RESOLVED FIXED

(Cloud Services :: Operations: Miscellaneous, task)

Description

[Julien Vehent]

We currently have a CAA record for services.mozilla.com that restricts certificate issuance to digicert. We should extend this record to the following domains:

• accounts.firefox.com (ideally firefox.com)
• addons.mozilla.org
• taskcluster.net
• telemetry.mozilla.org
• cdn.mozilla.net

Comment 1

[Julien Vehent]

Attachment: list of product certs not issued by digicert

Attached is the list of certificates for those domains (and all of mozilla.com) that have not been issued by digicerts.

Comment 2

[Julien Vehent]

All certificates hosted on the domains and subdomains from comment 0 currently use Digicert certificates. We are good to go to enable CAA there.

Comment 3

[Julien Vehent]

Alright, let's move forward. We need to set a CAA record with the value 0 issue "digicert.com" to the roots of these (sub)domains. This is similar to the CAA record set for services.mozilla.com, which is hosted in cloudservices-aws-prod route53. This is a non destructive change. Only CAs will check that record before issuing certs, and we can always remove the record if it blocks legitimate certificate issuance.

Spreading the needinfos for folks to implement the change:

• accounts.firefox.com: jbuck
• addons.mozilla.org: wezhou
• taskcluster.net: bstack
• telemetry.mozilla.org: jason
• cdn.mozilla.net: oremj

Comment 4

[Jon Buckley [:jbuck]]

Done for accounts.firefox.com. Thanks for getting the right domains together!

Comment 5

[Julien Vehent]

jbuck suggested also setting an iodef records so we can get reports of abuse. The DNS record to use then is:

0 iodef "mailto:[e-mail]"
0 issue "digicert.com"

Comment 6

[Brian Stack [:bstack]]

Created bug 1522005 to track the taskcluster side of things.

Comment 7

[:wezhou]

Likewise, filed bug 1522011 for addons.mozilla.org.

Thanks.

Comment 8

[Jeremy Orem [:oremj]]

Filed Bug 1522146

Comment 9

[Jason Thomas [:jason]]

Filed bug 1522148

Comment 10

[Corey Shields [:cshields]]

Hey ulfr, this won't work for CNAME records (addons.mozilla.org and telemetry.mozilla.org from your list)

per RFC, there can be no other records alongside a CNAME, and as such CAA follows the CNAME to query the destination. See https://letsencrypt.org/docs/caa/

So, we may want to discuss another way of handling these records if you want to add CAA to them.

Comment 11

[Rob Tucker [:rtucker]]

It might make sense to create a wildcard entries for mozilla.org and mozilla.com in the root of the domains and go from there.

*.mozilla.org 0 issue "digicert.com"
*.mozilla.org 0 iodef "mailto:[e-mail]"

*.mozilla.com 0 issue "digicert.com"
*.mozilla.com 0 iodef "mailto:[e-mail]"

Comment 12

[Julien Vehent]

This is unfortunately not possible as we use more than just digicert on mozilla.org and mozilla.com (lots of let's encrypt, some aws, etc.).

:cshields - I thought AMO and TMO were SOAed to route53, is that not the case?

Comment 13

[Rob Tucker [:rtucker]]

The following DNS requests are conclusive that TMO and AMO are simply CNAMEs

$ dig addons.mozilla.org @1.1.1.1

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> addons.mozilla.org @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2205
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;addons.mozilla.org. IN A

;; ANSWER SECTION:
addons.mozilla.org. 32 IN CNAME olympia.prod.mozaws.net.
olympia.prod.mozaws.net. 32 IN A 52.33.100.88
olympia.prod.mozaws.net. 32 IN A 52.33.146.255
olympia.prod.mozaws.net. 32 IN A 52.37.132.247
olympia.prod.mozaws.net. 32 IN A 54.187.89.91
olympia.prod.mozaws.net. 32 IN A 35.160.194.64
olympia.prod.mozaws.net. 32 IN A 35.166.51.240

;; Query time: 32 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Jan 24 07:58:13 STD 2019
;; MSG SIZE rcvd: 180

$ dig telemetry.mozilla.org @1.1.1.1

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> telemetry.mozilla.org @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12296
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;telemetry.mozilla.org. IN A

;; ANSWER SECTION:
telemetry.mozilla.org. 60 IN CNAME d65ojvdli7jd8.cloudfront.net.
d65ojvdli7jd8.cloudfront.net. 60 IN A 99.84.168.99
d65ojvdli7jd8.cloudfront.net. 60 IN A 99.84.168.12
d65ojvdli7jd8.cloudfront.net. 60 IN A 99.84.168.17
d65ojvdli7jd8.cloudfront.net. 60 IN A 99.84.168.90

;; Query time: 83 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Jan 24 07

Comment 14

[Julien Vehent]

Ok. so for AMO we could put the CAA under prod.mozaws.net since that's were the CNAME goes.

For TMO, however, the CNAME goes to cloudfront.net which we obviously don't control.

Comment 15

[Jeremy Orem [:oremj]]

I think cloudfront supports alias records, so you could CNAME to foo.prod.mozaws.net and make an A (Alias) record to Cloudfront (I think). We'd lose support for this if we ever moved to a CDN like Akamai.

Comment 16

[Corey Shields [:cshields]]

ulfr, what are your thoughts on adding CAA to mozilla.org/com for digicert, LE, and ACM?

Comment 17

[Gene Wood [:gene]]

:cshields,
At the very least we should add CAA records which replicate the current LetsEncrypt blacklist (see Bug 1300195) so we can have LetsEncrypt disable the blacklist on their side. I'd say once that is done we can look at changing the LetsEncrypt restrictions (which would no be captured in CAA records) or in establishing further restrictions if we wanted.

Comment 18

[Gene Wood [:gene]]

I've written up a summary page that gives the background to all of this : Certificate Authority Authorization CAA including Let's Encrypt

Comment 19

[Gene Wood [:gene]]

Greg do you have thoughts on this?

what are your thoughts on adding CAA to mozilla.org/com for digicert, LE, and ACM?

Comment 20

[Greg G]

(In reply to Gene Wood [:gene] from comment #19)

Greg do you have thoughts on this?

what are your thoughts on adding CAA to mozilla.org/com for digicert, LE, and ACM?

+1 on CAA to restrict CAs to a trusted subset of CA to prevent mis- or malicious issuance.
+1 on having digicert, LE, and ACM be the trusted CAs.

I believe we avoided LE in the past, because they didn't support wildcard certs at the time or the restrictions on who could issue certs for Mozilla domains that we wanted. I don't have access bug 1300195, but we should make sure the restrictions mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1519560#c17 are in place before including LE.

+ajvb who might have more context too

Comment 21

[Rob Tucker [:rtucker]]

We have also been issuing certs from Comodo/Sectigo and they would need added.
I am fairly certain there are some Google GCP issue certificates as well.

For mozilla.com/mozilla.com I would expect the changes to be as follows:

CAA 0 issue "sectigo.com"
CAA 0 issue "comodoca.com"
CAA 0 issuewild "sectigo.com"
CAA 0 issuewild "comodoca.com"
CAA 0 issue "digicert.com"
CAA 0 issuewild "digicert.com"
CAA 0 issue "letsencrypt.org"
CAA 0 issuewild "letsencrypt.org"
CAA 0 issue "amazon.com"
CAA 0 issuewild "amazon.com"
CAA 0 issue "amazontrust.com"
CAA 0 issuewild "amazontrust.com"
CAA 0 issue "awstrust.com"
CAA 0 issuewild "awstrust.com"
CAA 0 issue "amazonaws.com"
CAA 0 issuewild "amazonaws.com"
CAA 0 issue "pki.goog"
CAA 0 issuewild "pki.goog"
mozilla.com 0 iodef "mailto:[e-mail]"

Comment 22

[Matt Nordhoff (aka Peng on IRC & forums)]

FWIW, you can get the same results with fewer records -- you only need one domain for each CA (as long as you trust the CA not to stop recognizing the domain), and if "issue" and "issuewild" are identical, you don't need to specify "issuewild". It can be as short as:

0 issue "sectigo.com"
0 issue "digicert.com"
0 issue "letsencrypt.org"
0 issue "amazon.com"
0 issue "pki.goog"
0 iodef "mailto:[e-mail]"

Comment 23

[Gene Wood [:gene]]

but we should make sure the restrictions mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1519560#c17 are in place before including LE.

The blacklist for LE has already been removed. If there are restrictions you'd like to see in place, they should be rendered into CAA records. I'm unsure who can move this forward if it's someone from Cloud Services to define what CAA records to create or if it's rtucker to create those records.

Comment 24

[Rob Tucker [:rtucker]]

I can create the records when given the formal "Yes"

Comment 25

[Gene Wood [:gene]]

Excellent,

So I think this is either to :oremj or :gguthe or :ajvb then. I'll neglect to needinfo anyone for the moment in hopes that one of those folks does give you, Rob, a "yes, move forward"

Comment 26

[Greg G]

I'll run this by the rest of secops at our team meeting on Wednesday.

Comment 27

[Greg G]

Secops is +1

:hwine suggested double checking with :cshields prior to roll out, but I see Corey is already CC'd and :bobm noted that Fx already pins certs

Comment 28

[Corey Shields [:cshields]]

+1

Comment 29

[Rob Tucker [:rtucker]]

I've created/updated all of the caa records for mozilla.com/mozilla.org .

Comment 30

[Gene Wood [:gene]]

It looks like accounts.firefox.com, taskcluster.net and cdn.mozilla.net have records and addons.mozilla.org and telemetry.mozilla.org derive their record from mozilla.org

$ for domain in accounts.firefox.com addons.mozilla.org taskcluster.net telemetry.mozilla.org cdn.mozilla.net; do echo $domain; dig $domain CAA +short; done

accounts.firefox.com
0 issue "digicert.com"
0 iodef "mailto:[e-mail]"
addons.mozilla.org
olympia.prod.mozaws.net.
taskcluster.net
128 issue "sectigo.com"
128 issue "digicert.com"
128 issue "comodoca.com"
128 issue "awstrust.com"
128 issue "amazontrust.com"
128 issue "amazonaws.com"
128 issue "amazon.com"
128 iodef "mailto:[e-mail]"
telemetry.mozilla.org
d65ojvdli7jd8.cloudfront.net.
cdn.mozilla.net
0 issue "letsencrypt.org"
0 iodef "mailto:[e-mail]"
0 issue "amazontrust.com"
0 issue "digicert.com"

$ dig mozilla.org CAA +short

0 iodef "mailto:[e-mail]"
0 issue "sectigo.com"
0 issue "awstrust.com"
0 issue "digicert.com"
0 issue "amazontrust.com"
0 issuewild ";"
0 issue "amazon.com"
0 issue "comodoca.com"
0 issue "letsencrypt.org"
0 issue "pki.goog"
0 issue "amazonaws.com"