[cabfpub] CAA look up failures and retry logic

[Doug Beattie]

From: Jacob Hoffman-Andrews [mailto:jsha at letsencrypt.org]
Sent: Wednesday, October 4, 2017 4:17 PM
To: Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: geoffk at apple.com
Subject: Re: [cabfpub] CAA look up failures and retry logic

You make a good point. To reiterate the language from the BRs:

> 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.

Specifically, this talks about a single record lookup failure, but allows treating that as permission to issue. I think the behavior we'd really like here is to treat a record lookup failure as equivalent to a successful, empty response if those conditions are met. That way, for instance if a CAA lookup for "nonexistent.example.com<http://nonexistent.example.com>" returns NXDOMAIN, the CA is still required to attempt looking up a CAA record for "example.com<http://example.com>".

So I agree that your "most likely" option is the ideal, and is what CAs should be implementing to be conservative, but the BRs do not currently say that. I would support a ballot to amend it.
CAs might be motivated to run into fewer failures and to issue more certificates, so being conservative might not be what’s happening.  I know we’re blocking many more requests than some other CAs (mutual customers have informed us), which is driving this line of questioning for clarity.

-          What constitutes a failure?

-          How are failures retried and processed?

-          What’s an acceptable timeout period?
None of this is called out in the BRs or RFC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171004/e8aed31f/attachment-0003.html>