[cabfpub] Ballot 187 - Make CAA Checking Mandatory

Richard Wang richard at wosign.com
Mon Feb 27 01:47:16 UTC 2017

For CAA record, no any DNS service providers in China that support CAA record (at least I don’t find one), and I checked GoDaddy that also don’t support.

Best Regards,


From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Public
Sent: Monday, February 27, 2017 8:43 AM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Ryan Sleevi <sleevi at google.com>
Subject: Re: [cabfpub] Ballot 187 - Make CAA Checking Mandatory

On Sun, Feb 26, 2017 at 4:29 PM, Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>> wrote:

   Posting on behalf of mpalmer at hezmatt.org<mailto:mpalmer at hezmatt.org> . Note, please do not take this as an endorsement of the comments.

   On Fri, Feb 24, 2017 at 3:08 PM, Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>> wrote:

      My own is I'd be willing to deal with the increased risk (that comes from using "Example CA"'s DNS services, which would allow them to potentially issue a certificate in contravention of my CAA record), so long as it could be clear as a domain holder that I'm accepting that risk. If I didn't want it, I'd just choose to operate my DNS from someone who is not a CA (assuming I could determine that).

   I'd like to ask for consideration of what I'd call the "Cloudflare problem" --

   providers who mandate the use of their DNS service in order to use other,

   marginally-related services[1].  Were there an organisation which had a

   "must delegate to us" policy which also operated a CA, they would, by this

   suggestion that "DNS operator == full authoritah", have authority to issue

   certificates for the domain.

   While migrating away from (or deciding not to use) services which require

   DNS delegation is, indeed, entirely possible, the bundling of other services

   changes the migration calculus quite considerably.  Losing a number of other

   useful, valuable services in order to maintain control over certificate

   issuance is a lot harder to swallow than "just" migrating DNS.

   My main concern, in the general case, is that a rule such as that proposed

   would encourage more CA-affiliated services to put in place a "delegate

   only" policy in order to allow an end-run around CAA checking.  I don't

   think that serves the interests of any stakeholder in the WebPKI, other than


   - Matt

   [1] For those who aren't aware, in order to use Cloudflare's DDoS protection

       and other security services, you *must* delegate your domain to their

       DNS servers (with one or two exceptions that aren't relevant to 99%+ of

       all potential users of their service).  No delegation -> no service.

   While I think it's useful to consider, I don't believe anything can or should be done regarding this scenario and CAA.

   The issue Matt is highlighting here is one that I believe has an inconsistent, and incomplete, threat model.

   To put it differently, imagine we removed the 'operator' provision:

   - Site Operator wants to use Cloudflare's services

   - Site Operator delegates DNS to Cloudflare

   - Site Operator places a CAA record saying megaca.example.com<http://megaca.example.com>

   The 'intent' here is that the Site Operator does not want Cloudflare to issue a certificate (or any other CA other than MegaCA). And while that's a useful intent to signal, and helpful, as a security mechanism, it's unrealistic to believe CAA can or should address this. This is because Cloudflare could, in the pursuit of issuing such a certificate, easily require in its terms of service that it reserves the right to change the CAA record as necessary to provision its services. Or, for that matter, any DNS record, as part of providing its services to the subscriber. As it's the DNS operator, it has the full technical capability to do so.

   This is a business relationship problem, rather than a technical problem. To address that business relationship, the Site Operator must either contractually prevent Cloudflare from doing so, or choose not to use Cloudflare should such an item be added to the Terms of Service.

   Now, let's imagine this scenario in the world being proposed - that is, with the exception for the DNS Operator - the only change in threat model is that Cloudflare no longer needs to actively change the CAA record. While I can understand that's one less 'hoop' to jump through, I assert it's an irrelevant hoop, because under the no-operator-exception and the operator-exception world, Cloudflare still possess the technical and business capability to issue certificates as appropriate.

   And while we've used Cloudflare and MegaCA as the examples here, this applies to any relationship with any DNS Operator, and is an intrinsic part of the DNS security model regarding delegation. I think Matt's approach is regarding DNS as property, held by the "domain owner" and limited rights given to the DNS Operator. Unfortunately, I do not believe that model is historically or technically accurate, and the act of delegating DNS operation to any third party - whether Cloudflare, MegaCA, or other - is effectively accepting the holistic security risks that go with it, by ensuring they're mitigated with the appropriate contracts and business relationships.

   I can understand and appreciate Matt's concerns with the tradeoffs being that those who want to control certificate issuance tightly means they cannot delegate DNS to third parties. But unfortunately, I think that's life, and I don't believe it'd be a positive outcome for the CA/Browser Forum to try to restrict those business relationships, given that they fundamentally are technically indistinguishable.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170227/a44bd8a3/attachment-0003.html>

More information about the Public mailing list