<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Bruce.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Public [mailto:public-bounces@cabforum.org]
<b>On Behalf Of </b>Ryan Sleevi via Public<br>
<b>Sent:</b> Tuesday, January 24, 2017 4:48 PM<br>
<b>To:</b> Doug Beattie <doug.beattie@globalsign.com><br>
<b>Cc:</b> Ryan Sleevi <sleevi@google.com>; CA/Browser Forum Public Discussion List <public@cabforum.org><br>
<b>Subject:</b> Re: [cabfpub] Draft CAA motion (4)<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Jan 24, 2017 at 1:30 PM, Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://tools.ietf.org/html/rfc2308">https://tools.ietf.org/html/rfc2308</a> 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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>