<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:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:等线;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@宋体";
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Georgia;
panose-1:2 4 5 2 5 4 5 2 3 3;}
@font-face
{font-family:"\@等线";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
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;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.5pt;
font-family:等线;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
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-family:"Calibri",sans-serif">For CAA record, no any DNS service providers in China that support CAA record (at least I don’t find one), and I checked GoDaddy that also don’t support.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">Best Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">Richard<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><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> Monday, February 27, 2017 8:43 AM<br>
<b>To:</b> CA/Browser Forum Public Discussion List <public@cabforum.org><br>
<b>Cc:</b> Ryan Sleevi <sleevi@google.com><br>
<b>Subject:</b> Re: [cabfpub] Ballot 187 - Make CAA Checking Mandatory<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 Sun, Feb 26, 2017 at 4:29 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal">Posting on behalf of <a href="mailto:mpalmer@hezmatt.org" target="_blank">mpalmer@hezmatt.org</a> . Note, please do not take this as an endorsement of the comments.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Feb 24, 2017 at 3:08 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<p class="MsoNormal">My own is I'd be willing to deal with the increased risk (that comes from using "Example CA"'s DNS services, which would allow them to potentially issue a certificate in contravention of my CAA record), so long as it could be clear as a
domain holder that I'm accepting that risk. If I didn't want it, I'd just choose to operate my DNS from someone who is not a CA (assuming I could determine that).<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'd like to ask for consideration of what I'd call the "Cloudflare problem" --<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">providers who mandate the use of their DNS service in order to use other,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">marginally-related services[1]. Were there an organisation which had a<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">"must delegate to us" policy which also operated a CA, they would, by this<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">suggestion that "DNS operator == full authoritah", have authority to issue<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">certificates for the domain.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While migrating away from (or deciding not to use) services which require<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">DNS delegation is, indeed, entirely possible, the bundling of other services<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">changes the migration calculus quite considerably. Losing a number of other<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">useful, valuable services in order to maintain control over certificate<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">issuance is a lot harder to swallow than "just" migrating DNS.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My main concern, in the general case, is that a rule such as that proposed<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">would encourage more CA-affiliated services to put in place a "delegate<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">only" policy in order to allow an end-run around CAA checking. I don't<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">think that serves the interests of any stakeholder in the WebPKI, other than<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">CAs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- Matt<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] For those who aren't aware, in order to use Cloudflare's DDoS protection<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> and other security services, you *must* delegate your domain to their<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> DNS servers (with one or two exceptions that aren't relevant to 99%+ of<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> all potential users of their service). No delegation -> no service. <o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While I think it's useful to consider, I don't believe anything can or should be done regarding this scenario and CAA.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The issue Matt is highlighting here is one that I believe has an inconsistent, and incomplete, threat model.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To put it differently, imagine we removed the 'operator' provision:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- Site Operator wants to use Cloudflare's services<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- Site Operator delegates DNS to Cloudflare<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- Site Operator places a CAA record saying <a href="http://megaca.example.com">
megaca.example.com</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The 'intent' here is that the Site Operator does not want Cloudflare to issue a certificate (or any other CA other than MegaCA). And while that's a useful intent to signal, and helpful, as a security mechanism, it's unrealistic to believe
CAA can or should address this. This is because Cloudflare could, in the pursuit of issuing such a certificate, easily require in its terms of service that it reserves the right to change the CAA record as necessary to provision its services. Or, for that
matter, any DNS record, as part of providing its services to the subscriber. As it's the DNS operator, it has the full technical capability to do so.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This is a business relationship problem, rather than a technical problem. To address that business relationship, the Site Operator must either contractually prevent Cloudflare from doing so, or choose not to use Cloudflare should such an
item be added to the Terms of Service.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Now, let's imagine this scenario in the world being proposed - that is, with the exception for the DNS Operator - the only change in threat model is that Cloudflare no longer needs to actively change the CAA record. While I can understand
that's one less 'hoop' to jump through, I assert it's an irrelevant hoop, because under the no-operator-exception and the operator-exception world, Cloudflare still possess the technical and business capability to issue certificates as appropriate.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">And while we've used Cloudflare and MegaCA as the examples here, this applies to any relationship with any DNS Operator, and is an intrinsic part of the DNS security model regarding delegation. I think Matt's approach is regarding DNS as
property, held by the "domain owner" and limited rights given to the DNS Operator. Unfortunately, I do not believe that model is historically or technically accurate, and the act of delegating DNS operation to any third party - whether Cloudflare, MegaCA,
or other - is effectively accepting the holistic security risks that go with it, by ensuring they're mitigated with the appropriate contracts and business relationships.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I can understand and appreciate Matt's concerns with the tradeoffs being that those who want to control certificate issuance tightly means they cannot delegate DNS to third parties. But unfortunately, I think that's life, and I don't believe
it'd be a positive outcome for the CA/Browser Forum to try to restrict those business relationships, given that they fundamentally are technically indistinguishable.<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>