[cabfpub] Continuing the discussion on CAA

[Doug Beattie]

Jeremy,

I agree - For the Managed service model where CAs pre-vet domains we’d like to check CAA at the domain level and re-use that for all subdomains.  Maybe we can tie CAA into the domain validation process and allow the application of CAA and domain validation to the same Authorization Domain value which would enable high speed/volume issuance under a common domain (or a common subdomain).   Requiring the CA to check every FQDN for CAA compliance at the time of issuance will hinder performance and could result in denial of service vectors not previously available (DNS DDoS attacks).

Doug

-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley via Public
Sent: Monday, October 24, 2016 12:26 PM
To: Gervase Markham; public at cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

Thanks Gerv. Very useful.

I think there are just three concerns with CAA I'd like to address before hard-fail is required:
1)  CAA is currently an issuance check rather than a validation check. As mentioned during the face-to-face, this is a hurdle in fast issuance of certificates. We liked Ryan's proposal of simply doing a refresh every X days as a solution. By moving it to a validation check, CAs can have fast issuance times without CAA holding up the process after the initial validation is complete.
2) If a customer has a single base domain and needs to issue 6 million certs an hour for the various sub domains, then there isn't a way for the CA to simply accept the base domain's CAA record.
3) The validation process is actually opposite of what is required by CAA. 
The order required for CAA descends in scope rather than ascends (ie, check third level, then second level). Validation under 169 takes the opposite approach. The base domain is often used for validation without regard to anything specified in sub domains. Seems like we should pivot CAA to match the actual validation process and have the CAA scope match the domain authorization scope. Without doing this you run into an inconsistency where the customer could obtain *.example.com but not secure.example.com. This doesn't make sense as we like to encourage customers to use non-wildcard names when possible.

Problems #2 and #3 are easily solved together. Permitting verification of a sub domain to override the higher level domains solves performance issues, still restricts the scope of what CAs can issue, and permits high speed/volume issuance off a base domain.

Thoughts?
Jeremy

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Monday, October 24, 2016 9:43 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com>; public at cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On 24/10/16 16:40, Jeremy Rowley via Public wrote:
> Has there been an issuance to a third party that CAA would have prevented?
> Since there's no way to ensure compliance with a hard-fail CAA 
> requirement, will CAA do anything useful? We don't mind CAA as a 
> validation check, but I'm curious if anyone knows of an issued cert 
> that would have been rejected if CAA were fully implemented.

https://github.com/letsencrypt/boulder/issues/1231 :-)

Gerv