One of the main things that CAs do as part of their business is precisely helping the customer configure their server to use the product. This is only one of dozens of misconfiguration issues that arise.
DNSSEC is complex enough in itself. One of the side effects of DNSSEC is that it will make any and all misconfigurations in your existing DNS apparent. It is the DNS equivalent of a ‘lights out’ data center. This is one of the reasons why positioning DANE to compete with the WebPKI was an own goal. The parties that might have assisted in the deployment of DNSSEC and helped customers work through the deployment were intentionally locked out. So where the CABForum documents say ‘must not issue’, what this actually means in practice is ‘must not issue until the CA has helped the customer get their act in gear’. From: Ryan Sleevi [mailto:sle...@google.com] Sent: Friday, August 18, 2017 10:02 AM To: Gervase Markham <g...@mozilla.org>; CA/Browser Forum Public Discussion List <public@cabforum.org> Cc: phill...@comodo.com; Kirk Hall <kirk.h...@entrustdatacard.com> Subject: Re: [cabfpub] Two CAA questions On Fri, Aug 18, 2017 at 7:25 AM, Gervase Markham via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote: Is anyone able to explain why this scenario is at all common? Why would the authoritative nameservers for a domain refuse to answer queries, if the owner of the domain wanted the domain to work at all? Isn't that two questions? That is, can someone explain this scenario, and how common is it? :) I think https://github.com/dns-violations/dns-violations is a useful collection of various ways that vendors have improperly implemented DNS and could result in affecting (a limited number of sites, customers of a particular DNS host / CDN). I'm not aware of any publicly available data showing prevalence or that it is common, especially in the context of CA issuance, and so I would think it would be a wonderful contribution to the Internet community if CAs are seeing such issues, that they could publish information about it. I know Let's Encrypt has investigated some issues, such as https://community.letsencrypt.org/t/caa-servfails-from-namebrightdns-com/38748 and https://community.letsencrypt.org/t/public-suffix-list-caa-issue-s/39802 , but these are indicative of gross server misconfigurations, and so failing to issue a certificate is a correct response for a misconfiguration that is indistinguishable from an attack. As CAs often remark about OCSP, the most secure solution is to fail closed when a service fails. Given that CAs have direct lines with the customers affected by such service failures - and thus, the means to remedy the issue - this does not seem at all an onerous request. As you said, and as Phillip mentioned, this is working as intended and designed, and important for security, so if there is more data that can be shared to help understand these concerns, that'd be useful, but otherwise it doesn't seem necessary to change anything.
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
