Subject: [DNSOP] Error handling in CAA

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 17 Nov 2017 12:49:33 -0800

In the SPASM group, we are refining CAA (RFC 6844) based on the changes
that were needed in order to get it passed at the CA/Browser Forum.
There's one sticky bit in particular I'd like input on. Here's the
current language in the BRs:

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.4.pdf

> CAs are permitted to treat a record lookup failure as permission to issue
> if:
> - the failure is outside the CA's infrastructure;
> - the lookup has been retried at least once; and
> - the domain's zone does not have a DNSSEC validation chain to the
> ICANN root.

It would be nice if we could provide more solid language for a future BR
update, or possibly for a CAA update.

The goal here is to work around the issue that a small but significant
number of domains return errors when asked for CAA ((I'd guesstimate
1%?). CAs would like to be able to assume there is no CAA record present
for those domains and issue anyhow.

However, if you're using a standard recursive resolver inside your own
infrastructure, and you get a SERVFAIL, how do you distinguish whether
that was a DNSSEC validation failure or another type? I realize the
extended-error draft will help enormously with that, but I'm looking for
a solution that can be deployed before that is done. One idea: Run two
recursive resolvers, one validating and one not. If you get an error
from both, it's a network error; if you get an error from the validating
one and success from the non-validating one, it's a DNSSEC error and you
should refuse issuance.

A second issue: How does one determine automatically whether a failure
is "outside a CA's infrastructure?" This was inserted as a bit of a
handwave to get the ballot passed, but it would be nice if we could
formalize this concept, or declare that it's unenforceable.

Thanks,
Jacob

---

From: Mark Andrews <[email-masked]>
Date: Sun, 19 Nov 2017 07:13:09 +1100

The only real way to determine if a lookup failure in internally or not is to
query the authoritative servers for the zone directly.

The simple fix is to charge $1000 extra if the CAA lookup fails due to the
authoritative servers for the zone failing to support lookups for the CAA
record or for the servers being incorrectly delegated.  This covers moving
the lookup off the automated path.

Make sure this fee is clearly stated up front.  RFC 1034 had clear instructions
for how to handle unknown records.  You refuse to load the zone if they present
and return SERVFAIL.  After that there is no special handling required. As they are
not present in the zone the server returns NOERROR or NXDOMAIN as appropriate.
Recursive servers treat them as opaque blobs.  Add to that RFC 3597 was published
in 2003 which provided a master file representation to allow unknown records to
be saved in a master file.  It also repeated the handling instructions from RFC 1034
in different words.

Failing to support CAA lookups include but is not limited to:
returning SERVFAIL (rcode 2)
returning FORMERR (rcode 1)
returning NOTIMP (rcode 4)
timing out on CAA lookups but not timing out on one of SOA, A or AAAA

Mark

> On 18 Nov 2017, at 7:49 am, Jacob Hoffman-Andrews <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 18 Nov 2017 21:10:00 +0000

On Fri, Nov 17, 2017 at 12:49:33PM -0800, Jacob Hoffman-Andrews wrote:

> > - the domain's zone does not have a DNSSEC validation chain to the ICANN root.

This language really should have been much more clear.  In particular,
the last item warrants clarification.  It is critical that the CA
determine the lack of a validation chain in a robust manner.  The
simplest approach:

    * Request the SOA record of the domain.  If this lookup fails,
      (ServFail, Timeout, ...) stop, the domain's DNSSEC status is
      unknown.

    * If the lookup returns NoError with AD=1 (a validated SOA
      record or a validated NoData), the domain is signed,
      do not tolerate CAA lookup failure.  Ditto for "NXDomain".
      (As I've repeated too many times, NoError, NoData and NXDomain
      are not lookup failures).

    * If the lookup returns NoError with AD=0 (an insecure SOA
      record or an insecure NODATA), the domain is not signed.
      Ditto for NXDomain.  Tolerate persistent CAA lookup
      failure.

> that was a DNSSEC validation failure or another type?

See above, the CA should not attempt to distinguish between different
faiure modes.

    * All failures for domains *not known* to be "insecure" should
      be fatal.

    * Persistent CAA lookup failure for *known* "insecure" domains
    (AD=0 with NoError, NoData or NXDomain) can be ultimately
    ignored as a software or configuration issue with the remote
    nameservers.

I include NXDomain, because I think (correct me if I'm  wrong) CAs
may issue certificates for (internal) names that don't appear on
the public internet, when the customer controls a public prefix.
 
> I realize the
> a solution that can be deployed before that is done.

It is best to not attempt to read the tea-leaves.  You can reliably
determine which domains are insecure.  Your validating resolver
will include the AD bit with the SOA lookup result.  If even SOA
lookups fail, the domain is busted, and needs to be fixed on the
customer's end.

> One idea: Run two

This is complicated.

> formalize this concept, or declare that it's unenforceable.

That language looks misguided to me.

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Mon, 20 Nov 2017 13:10:43 +0000

> On Fri, Nov 17, 2017 at 12:49:33PM -0800, Jacob Hoffman-Andrews wrote:

This is a topic of operational interest to me :-)

I previously posted about CAA checks and private domains at:
https://lists.dns-oarc.net/pipermail/dns-operations/2017-September/016752.html

Our CA has updated their implementation to issue certs if (I am told)
"a lookup error is returned (like a SERVFAIL from an internal DNS server)
AND the domain does not have a valid DNSSEC signature (or a parent domain
does not have valid DNSSEC)."

I hope that by "valid DNSSEC signature" they actually mean signed DS
RRset, but I have not tested their new behaviour.

We have worked around this problem by making a public empty view for our
private subdomain, so the fix comes a bit too late to help us. (And it
turns out there are other advantages to our workaround.)

The other entertaining CAA checking bug was due to checkers getting in
loops when CNAMEs closer to the root point at subdomains of themselves -
https://twitter.com/fanf/status/915936787171807237

>       (ServFail, Timeout, ...) stop, the domain's DNSSEC status is

No, you need to lookup the domain's DS records to determine its DNSSEC
status.

Apart from that I agree with Viktor's points.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fair Isle, Faeroes: Northeast veering east 4 or 5, occasionally 6 later.
Moderate or rough. Wintry showers, rain later. Good occasionally poor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Nov 2017 20:54:04 +0000

> No, you need to lookup the domain's DS records to determine its DNSSEC

Actually, I chose my recommendation of SOA lookup after some thought
and with care.  A domain may have no DS records, and yet be signed
because it is not a (delegated) zone apex domain.  Furthermore, an
SOA query elicts data from the domain itself, not the parent, and
thus ensures that any published DS records up the tree yield working
signatures for records in the zone containing the domain.

If the SOA lookup fails, then the domain is severely broken beyond
just "stoopid" blocking of CAA and other "novel" RRtypes, and so
there is no reason for the CA to be "forgiving" of such errors.
(Not that I have much sympathy for domains where CAA lookups fail
but other lookups do not, they really should feel some pain to fix
their DNS).

So I stand by the advice to issue "SOA" queries, they are far
simpler to implement correctly (without having to chase DS records
up the tree, cross check them against NS records, ...) and they
yield more useful information, namely whether:

    * A domain has working "insecure" DNS
    * A domain has working "secure" DNS
    * A domains is broken, and needs attention before CAA status
      can be determined or ignored.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Nov 2017 16:00:40 -0500

>       can be determined or ignored.

If the domain is broken, validation is going to fail as well. Which
may prove a useful cut.

---

From: Tony Finch <[email-masked]>
Date: Wed, 22 Nov 2017 12:09:51 +0000

> signatures for records in the zone containing the domain.

OK I thought you meant to query for the SOA of the zone containing the CAA
domain, and I meant to query for the closest enclosing negatively or
positively resolvable DS.

The CAA search has to walk the DNS tree anyway, so finding the closest
enclosing DS is a similar kind of process.

> If the SOA lookup fails, then the domain is severely broken

No, it might just be private.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Tyne, Dogger, Fisher, German Bight, Humber, Thames: South or southwest 6 to
gale 8, occasionally severe gale 9 except Tyne. Rough or very rough,
occasionally very high for a time in Biscay. Rain or showers. Good,
occasionally poor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Nov 2017 21:30:11 +0000

> No, it might just be private.

We are not using the same (mine is correct :-) definition of failure.
An NXDomain reply is not a lookup failure.  The security status of
the domain is available regardless of whether we get NoError with
some answers, NoError with no answers (aka NoData) or NXDomain.

A private sub-domain should return NXDomain on the public side of
the Internet, with that answer signed or not based on the security
status of the parent zone.  Having the query ServFail is where of
course you run into trouble.

My recommended algorithm for CAA probing is that any (really, as
in ServFail, ...) failed CAA probe be accompanied by an SOA probe
for the *same* domain.

If the SOA probe succeeds (including NXDomain), and is signed, then:

    * Signed NXDomain is sufficient to conclude that CAA does not
      exist either
    * Signed NODATA is sufficient to conclude that the zone is
      signed and CAA lookup failure must not be ignored.
    * Ditto for a signed SOA RRset.

If the SOA probe succeeds (including NXDomain), and is not signed,
then:

    * Unsigned NXDomain is sufficient to conclude (sans DNSSEC) 
      that CAA does not exist either.

    * Unsigned NODATA is sufficient to conclude that the zone
      is not signed and persistent CAA failure might eventually be
      ignored (sparing the domain owner the pain signal they need
      to take important corrective action, perhaps not a good idea).

    * Ditto for unsigned SOA RRset.

If the SOA lookup (really) fails, then the domain is broken.  Any
non-public sub-domains that want certificates, should not be broken
in this way.  Either appear in the public DNS, return NXDomain or
NODATA.  A wildcard CAA record might in fact be a good way to
present a non-public subtree to the outside world:

    internal.example.com. IN CAA ...
    *.internal.example.com. IN CAA ...

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Thu, 23 Nov 2017 13:25:57 +0000

Viktor Dukhovni <[email-masked]> wrote:

> the Internet,

Maaaaaybe. That (mostly) requires that DNS servers support views.

Obviously in practice, private zones and views are often used together,
but DNS purists have also argued that that you don't need views to have
private zones (and that is how private.cam.ac.uk was set up).

But purism has disadvantages: REFUSED queries to private domains from the
public Internet cause retries and traffic amplification so there are
non-CAA-related advantages to having a public NXDOMAIN view.

Even so, I know that at least one CA has received enough complaints from
customers with REFUSED private domains that they have already updated
their implementation to permit certificates in unresolvable zones that
lack DNSSEC. It worked before CAA and I don't think there's any particular
advantage to breaking it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Faeroes, Southeast Iceland: Northerly backing northwesterly gale 8 to storm
10. Very rough or high, occasionally very high in north. Squally wintry
showers. Moderate or poor.