[cabfpub] Draft CAA motion (4)
sleevi at google.com
Tue Jan 24 21:47:53 UTC 2017
On Tue, Jan 24, 2017 at 1:30 PM, Doug Beattie <doug.beattie at globalsign.com>
> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public