[cabfpub] Continuing the discussion on CAA

[Ryan Sleevi]

On Thu, Sep 8, 2016 at 2:40 PM, Rick Andrews <Rick_Andrews at symantec.com>
wrote:

> Additionally, I'd like to address this point: 'Ryan pointed out that, at
> present, nothing would prevent Neil from stating in his CP/CPS that his CA
> will issue certificates if he sees a CAA record for "symantec.com" '. If
> Neil adopted that policy, wouldn't it violate RFC 6844, which says "The
> issue property entry authorizes the holder of the domain name <Issuer
> Domain
> Name> or a party acting under the explicit authority of the holder of that
> domain name to issue certificates for the domain in which the property is
> published."?
>

Rick,

As you know, the IETF historically shies away from discussions of policy,
and instead focuses on the technological side. We can see that certainly
with PKIX (RFC 5280 & friends), and it was actually a frequently reiterated
point during the discussion of CAA through its standardization.

As such, we should imagine that CAA defines the structural representation,
but it's up to the CA/B Forum to specify the policy that applies here. You
can see that the document intentionally shies away from this discussion in
Sections 6.1 and 6.2, and that's arguably the right thing.

The extent of my comments was to make sure that, in developing a policy for
CAA (which I'm strongly supportive of, so appreciate you continuing the
discussion), we make it clear what is and is not acceptable. If we were to
accept that Neil doing so would violate RFC 6844, then we must also accept
that the only RFC 6844-compliant method of a CA running into the situation
you propose is to Not Issue At All. That is, not even Option 1 is
acceptable (since you included the parenthetical escape clause).

My "ideal" outcome for CAA within the CA/B Forum would be:
1) A requirement in the CPS to state that the CA respects CAA
2) A requirement that the CPS documents which domains the CA recognizes in
CAA records. As a consequence, if a CA wishes to recognize additional
domains in CAA records, this requires a CPS update.
3) A requirement that the CA honor the CAA record exactly as presented,
with no overriding allowed, short of changing the DNS record.
4) A requirement that the CA maintain audit records regarding their CAA
evaluation, such as:
  - The order and sequence of DNS records they attempted to resolve
  - The results of those DNS records and the source of the information.

Each of these I suspect is controversial in some way, and will no doubt
require more discussion, but to briefly justify this:

#1, without #2-4, is largely toothless. However, my goal is to ensure that
auditors have a consistent framework to evaluate a CA's compliance, and for
the public at large as well to evaluate. If a CA says it supports CAA, and
a misissuance event occurs that contravenes that, it's natural that both
auditors and the public should want to understand why and how, and setting
this up within the CPS makes it clear that the CA is committed to
explaining that.

#2 is about making it clear for Subscribers and Applicants the "Right Way"
to configure things. Each CA naturally is free to manage their customer
relations as they wish, but it can be hard to find consistent information
(such as where to report misissuance events), and the CPS is the one
universal aspect that all CAs must have and abide by, so it naturally makes
sense to ensure it's in a consistent and discoverable place.

#3 is clearly a sticking point. I think we're all pretty aware of CAs'
objections to this, but I do feel strongly that, without this, CAA is not
an effective security mitigation. As you know, Google holds a variety of
domains, and we routinely receive requests from other CAs attempting to
confirm that an applicant was duly authorized to make a request, and we
routinely have to contact CAs and request revocation for certificates that
were not authorized according to our company policy. Allowing escape
clauses, even at the EVGL level, significantly weaken our ability to
proactively prevent this, which we believe would reduce both ours and CAs'
administrative burdens.

#4 is less obvious. During Bilbao, we discussed how DNS resolution can be
unreliable for CAs; for example, network hiccups due to peering
interconnects can manifest as a DNS timeout, rather than a successful
(negative) response. We also know that CAA policies are only applicable at
time of issuance, and may change, so we can't examine post-facto the CAA
record of a domain and make a declarative judgement of misissuance.
However, unfortunate as it is, CAA is a "fail open" rather than "fail
closed" model - any misconfiguration on the CA's part (such as forgetting
to configure their DNS clients or firewalls correctly) can result in
issuance, even when a domain holder explicitly requests that the CA not
issue (via CAA). So we need to have some sort of way to audit this, so
that, in the event of claimed conflict, we can better ascertain what
happened, and why. This is a rough sketch of an attempt to do so, but the
point in particular being to ensure there's enough record to know if the CA
had a bug in their system, and to ensure enough information is preserved to
understand that bug.


We know CAA isn't the system we'd hope for - while it presents itself as a
whitelist mechanism (listing only authorized CAs) - because it's built atop
the unreliable DNS, it's effectively a blacklist mechanism (any failure is
interpreted as the status quo - any CA is authorized - rather than the
desired state - no CA is authorized). In an ideal world, I would wish for
CAA to be required, and present, in order for a CA to issue a certificate,
but I know that world is unlikely to ever come about, and so I'd at least
be willing to settle on #1 - #4 as an improvement to the status quo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160908/30f77851/attachment-0003.html>