[cabfpub] Continuing the discussion on CAA

[Eric Mill]

*(Just noting for my first email from this address - when I email from
eric.mill at gsa.gov <eric.mill at gsa.gov>, I'm participating as an Interested
Party in my capacity as a GSA employee.)*

I wasn't present at Bilbao and so I don't know the full context from there,
but my perspective is that for CAA to be at all relevant to enterprise
security decisions, it has to be strictly enforceable to the greatest
technical extent possible.

In the context of this thread, that is to Not Issue At All if the CA sees a
CAA record that does not permit the CA to issue for the domain, with the
only solution being that the domain owner updates the CAA record to include
the CA.

Given that DNS is unreliable, allowing it to "fail open" seems permissible,
mitigated by CAs being required to keep clear audit logs like the kind Ryan
described in (4). DNS unreliability is already a fact of life in validating
domain ownership, so this seems inevitable, and hopefully CAs that perform
DNS-based domain validation already keep audit logs to that level of detail
anyway. Mechanisms to mitigate DNS unreliability (such as performing DNS
validation from multiple vantage points) are already useful for domain
validation.

The enterprises I tend to work with are federal agencies, who often wish to
employ only a subset of CAs in their enterprise environment, with the
intent of limiting their exposure to CA failure in the broader web PKI. The
general approach they take is to have human policies restricting what CAs
their employees are allowed to use. This alone adds no security value and
doesn't reduce any exposure to CA failure whatsoever, but as far as I have
seen it is consistently employed alone, making it security theater.

CAA could be a straightforward way for enterprises to set an actual
security policy that can be technically enforced, without the same level of
risk or technical sophistication required by HPKP. However, each of the
proposed ways of loosening CAA enforcement ("High Risk" treatment, EV
treatment, contacting a human from whois, and maybe just issuing anyway)
moves CAA out of the realm of technical enforcement and into the realm of
CA discretion. In my opinion, this would put CAA at major risk of being
security theater.

In general, relying on technical enforcement is always much preferable to
CA discretion, but it's particularly necessary for CAA. A major part of the
rationale for CAA (and HPKP) is to allow domain owners to avoid exposure to
failures in weaker CAs in the web PKI. A CAA enforcement policy that relied
on CA discretion would mean that CAA is effectively as strong as the
weakest CAs, undermining one of CAA's main benefits.

On Fri, Sep 9, 2016 at 9:41 AM, Gervase Markham <gerv at mozilla.org> wrote:

>
> I suggest this because I think it might be a good way to meet Google's
> needs for absolute bans, without making CAA, like HPKP, a technology
> that only large sites will deploy because of the near-"bricking" potential.
>

While I get what you are saying, there are some very significant
differences in potential severity between hard-bricking a site through HPKP
vs hard-denying issuance through CAA. Two major ones:

* Any failures occur at issuance-time, not request-time. While an issuance
failure might lead to request failures when replacing expired or
imminently-expiring certificates, many (most?) issuance failures will give
service operators time to respond before request failures, including
adjusting DNS records as necessary.

* HPKP policies are cached in clients for a potentially significant number
of days, making some kinds of hard-failures impossible (by design) to fix
in a rapid timeframe. CAA policies can be changed centrally, server-side,
and issuance attempts repeated immediately afterwards, ensuring that a
rapid fix is always theoretically possible and often quite practical.

So even though a hard-fail CAA might intimidate some classes of domain
owners from using it, I don't think CAA and HPKP are similar enough to
suggest that current deployment of HPKP could be used to project the impact
of a hard-fail CAA.

And even if it does intimidate some class of domain owners, it seems better
to provide direct security guarantees for the domain owners who choose to
use it, than for a looser policy to put a low ceiling on the security it
could possibly provide any domain owner.



> I agree with Ryan that, even if the process is loose, we need proper
> audit trails to make sure the CA does the checks and follows the
> exception process properly.
>

Just for clarity's sake, I read Ryan's proposed requirement around audit
trails to be part of a "strict" process, not a looser one -- and that the
unreliability of DNS and the necessity of failing open makes a specific
audit trail especially necessary even for a strict policy.

Eric Mill

Senior Advisor on Technology
Technology Transformation Service <http://www.gsa.gov/tts>
U.S. General Services Administration
eric.mill at gsa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160911/986f0620/attachment-0003.html>