On Fri, Nov 17, 2017 at 12:49:33PM -0800, Jacob Hoffman-Andrews wrote:
> 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.
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.
> 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?
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
> extended-error draft will help enormously with that, but I'm looking for
> 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
> 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.
This is complicated.
> 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.
That language looks misguided to me.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
