The issue with a CAA hard-fail for all circumstances is that it could impact current obligations for certificate issuance and management and it is anti-competitive. What I don’t understand is why there are objections to a proposed solution without trying to provide an alternative. We should attempt achieve consensus on a new obligation which will impact the issuance of all future certificates.
I support CAA hard-fail for certificates requests where the request is not confirmed using a Reliable Method of Communication. Proposing the use of defined roles such as the Enterprise RA and the Certificate Approver is a soft-fail alternative. This allows existing Subscriber obligations to be fulfilled. It also allows an Applicant to change their request from DV to OV or EV where the identity of individual certificate approver will be established. Bruce. From: Public [mailto:[email protected]] On Behalf Of Ryan Sleevi via Public Sent: Tuesday, January 24, 2017 4:48 PM To: Doug Beattie <[email protected]> Cc: Ryan Sleevi <[email protected]>; CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [cabfpub] Draft CAA motion (4) On Tue, Jan 24, 2017 at 1:30 PM, Doug Beattie <[email protected]<mailto:[email protected]>> wrote: There is a tradeoff between security and usability and I don’t believe any of the points below significantly reduce the security from Gerv’s proposal. 1) Over-riding via Enterprise RA or Certificate Signer: I’ll let some of my colleagues chime in here. CAA will be checked when adding the domain to enterprise accounts and that there is a person in a BR defined role representing the company that has signed up for the service to issue certificates. One concern is that people managing DNS records with limited knowledge about all of the business units agreements with CAs can cause a denial of service. This is especially an issue for “smaller” CAs that could be locked out of issuance by the larger CAs promoting the addition of their CAA records with the DNS managers. Given the lack of CAA records in use today, it’s a concern that has not been realized yet. Perhaps we could put a sunset date on this as of 1-year after mandatory CAA checking and by then we should have addressed concerns like this via CAs reporting to the CABF on issues like this. As the thread shows, both Gerv and I have repeatedly objected to this addition. It's unclear if the members of the CA Security Council are simply introducing this in order to attempt to kill CAA, or if it was simply not realized how strong the opposition is to this clause. The Forum has so far delayed mandating CAA because of these FUD concerns, and requests from CAs to gather more experience. Unfortunately, the same CAs that have requested more time have failed to do so or provide data, so it's very hard to continue to be sympathetic to this concern. Considering how many members of the CA Security Council continue to misissue certificates through such scenarios, I do not think such a change can or should be supported, and CAs have yet to shed additional detail the last time it was requested. 2) 12 hours vs 1 hour: Several people already pointed out reasons for needing more than an hour, namely for the manual issuance process Entrust uses, so a working day seems to align with their needs. As long as we publish the rules for caching then the domain owners can understand the maximum time it takes for their changes to be applied to new certificate issuance. I don’t view this 11 hour increase in cache time as a significant security weakness. Domain owners should plan ahead and update CAA records, a half day should be more than sufficient for this. 3) 24 hour cache time when no CAA records found: Proposed by Symantec, and there were no objections on the list, so I added it. Nor was there support for it. This is an exceedingly poor idea outside of security or DNS best practice, but I understand that CAs may not be familiar with how DNS works. https://tools.ietf.org/html/rfc2308 covers more broadly the handling of negative caching of DNS records, which is why Google has been strongly supportive of leaving this as a behaviour of the DNS specification, rather than introducing a CA/Browser Forum behaviour above/beyond what DNS already does. In particular, Sections 3 and 5 contain the recommendations for how to handle it, but briefly, in the presence of an NXDOMAIN record, the caching lifetime is treated as the minimum of the TTL of the SOA record and of the SOA record's lifetime. I suspect that the CA Security Council was approaching this from a business side, but I highlight this to demonstrate that the tech side already addresses this, so it does not need an explicit callout or special policy in the ballot. For example, the proposal put forward on this thread would allow caching of an NXDOMAIN even after a domain registration expired or was moved to a new provider (making it less secure, by providing a way for a CA to ignore a CAA record), whereas simply attempting to resolve, using a standards-compliant resolver, would properly handle this by only caching up to the lifetime of the domain registration (at most).
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
