[cabfpub] Ballot 187 - Make CAA Checking Mandatory
sleevi at google.com
Mon Feb 27 00:43:27 UTC 2017
On Sun, Feb 26, 2017 at 4:29 PM, Ryan Sleevi <sleevi at google.com> wrote:
> Posting on behalf of 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> 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. 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
> changes the migration calculus quite considerably. Losing a number of
> 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
> - Matt
>  For those who aren't aware, in order to use Cloudflare's DDoS
> 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
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
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...
More information about the Public