<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 14, 2016 at 1:49 PM, Gervase Markham via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 14/10/16 18:32, Bruce Morton via Public wrote:<br>
> I think that the CA can limit risk by checking CAA records where there<br>
> has been no verified Enterprise RA or a Certificate Approver<br>
> established. In this condition, I think that the CAA record check should<br>
> be a hard fail.<br>
<br>
</span>How would you code that, in practice? What would the UX look like for<br>
the validation specialist?<br>
<br>
Any version of this where CAA is not a hard-coded non-overrideable hard<br>
fail deprives CAs of the misissuance protection they could get when it<br>
is. Imagine if, even if an attacker got control of your entire infra he<br>
still couldn't issue for <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a>, <a href="http://yahoo.com" rel="noreferrer" target="_blank">yahoo.com</a> or other high profile<br>
sites because of CAA. </blockquote><div><br></div><div>You could also say that any CA where domain control checks are not "hard-coded non-overrideable hard fail" miss out on misissuance protection, or really about any other technical checks on misissuance. </div><div><br></div><div>I don't think providing resistance to full compromise of a CA is what CAA addresses. CAA is self-enforced, so it can address the threat of misissuance caused by weaknesses in other *parts* of the CA's infrastructure (like issuance protocols). SCT enforcement/auditing and HPKP can provide some protection against *full* CA compromise, because they are ultimately enforced by devices outside the CA's infrastructure.</div><div><br></div><div>In my experience, Bruce's description of organizations where the DNS team isn't in effective coordination with the people requesting certs is unfortunately common. How much weight that should have regarding CAA policy is worth debating, but a debate on CAA should be oriented around a clear threat model. It seems to me that CAA is valuable if it provides meaningful technical controls that restrict issuance from the vast majority of CAs with whom an organization will have no business relationship.</div><div><br></div><div>-- Eric</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">That would make the consequences of the compromise<br>
significantly less bad for the internet, and therefore less bad for the<br>
CA. Protection against malicious misissuance (as opposed to an employee<br>
violating policy, say) is not the only benefit of CAA, but I think it's<br>
a useful one.<br>
<br>
Making mistakes with an organization's DNS can lead to all sorts of<br>
types of outage or disruption. Why is the disruption caused by a<br>
mistaken CAA record (which seems a fairly unlikely scenario to me, but<br>
let's run with it) so much worse that it needs specially protecting against?<br>
<br>
If an organization allows random employees to make unreviewed changes to<br>
its DNS, surely it has bigger problems than not being able to get certs?<br>
<br>
Gerv<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Eric Mill</div><div>Senior Advisor on Technology</div><div>Technology Transformation Service, GSA</div><div><span style="font-size:12.8px"><a href="mailto:eric.mill@gsa.gov" target="_blank">eric.mill@gsa.gov</a>, </span>+1-617-314-0966</div></div></div>
</div></div>