<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><i>(Just noting for my first email from this address - when I email from <a href="mailto:eric.mill@gsa.gov" target="_blank">eric.mill@gsa.gov</a>, I'm participating as an Interested Party in my capacity as a GSA employee.)</i></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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. </div><div class="gmail_quote"><br></div><div class="gmail_quote">On Fri, Sep 9, 2016 at 9:41 AM, Gervase Markham <span dir="ltr"><<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I suggest this because I think it might be a good way to meet Google's<br>
needs for absolute bans, without making CAA, like HPKP, a technology<br>
that only large sites will deploy because of the near-"bricking" potential.<br></blockquote><div><br></div><div>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:</div><div><br></div><div>* 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.</div><div><br></div><div>* 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I agree with Ryan that, even if the process is loose, we need proper<br>
audit trails to make sure the CA does the checks and follows the<br>
exception process properly.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Eric Mill</div><div><br></div><div>Senior Advisor on Technology</div><div><a href="http://www.gsa.gov/tts" target="_blank">Technology Transformation Service</a></div><div>U.S. General Services Administration</div><div><a href="mailto:eric.mill@gsa.gov" target="_blank">eric.mill@gsa.gov</a><br></div></div></div></div>