<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;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;}
@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 style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt'>Yes, if you read between the lines of my email, you’ll see that I acknowledge that the design goals have changed in the last six years … it’s why I think a reanalysis might actually be prudent. We’ve learned a lot.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>Part of the reason the BRs are currently so domain-control centric is that many of the older “ownership” based methods have been removed. Some of them by me </span><span style='font-size:11.0pt;font-family:"Segoe UI Emoji",sans-serif'>😊</span><span style='font-size:11.0pt'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>But if we want to specify new design goals instead of the old ones, I think we should do so explicitly and not implicitly, otherwise everybody will be secretly thinking slightly different things, and we’ll have endless arguments about whether methods need to be removed because they offended George’s sensibilities but not John or Paul’s, and who knows what Ringo thinks about all this silliness.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'> I think you can sort of already see that playing out in this thread.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>-Tim<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><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'> Aaron Gable <aaron@letsencrypt.org> <br><b>Sent:</b> Tuesday, September 24, 2024 2:57 PM<br><b>To:</b> Ryan Dickson <ryandickson@google.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br><b>Cc:</b> Tim Hollebeek <tim.hollebeek@digicert.com><br><b>Subject:</b> Re: [Servercert-wg] Transitive Trust and DCV (was Re: Ballot SC-080 V1)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal>Tim,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The historic thought to which you refer -- that proof of ownership is stronger than proof of control -- has been clearly shown to be incorrect. Nearly all of the proof of ownership methods require communication with a Domain Contact, and all of the methods of discovering and communicating with a Domain Contact (namely WHOIS, DNS SOA, and direct contact via unspecified means with the Domain Name Registrar) are at least as vulnerable to MITM/hijacking/takeover as any proof of control method. At best, they only show "instantaneous ownership". The <a href="https://docs.google.com/document/d/1aJiOzYVTpoAPVWDucnp20cTO2PR_cRsHncvkhlrcR10/edit">Validation Summit Findings</a> from 2018 don't make an argument otherwise.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>To the contrary, I am making the opposite claim: that these "proof of ownership" methods are currently weaker than their sibling "proof of control" methods, precisely because of how under-specified the method for finding the Domain Contact is.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>- Using DNS SOA is largely equivalent to the similar methods which use DNS TXT or CAA records to convey a contact address, so that's good.<o:p></o:p></p></div><div><p class=MsoNormal>- Using WHOIS has just been shown to be suspect for data quality reasons, but it is also an unencrypted and unauthenticated protocol which comes with its own risks.<o:p></o:p></p></div><div><p class=MsoNormal>- Direct contact with the Registrar has the potential to be reasonably secure or wildly insecure depending on how it is implemented.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>And of course, because all of these are just methods of <i>looking up</i> the Domain Contact, they are not subject to MPIC, and so are now notably more vulnerable to BGP hijacks than other DCV methods (including the DNS TXT and CAA methods that DNS SOA would otherwise be comparable to).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Finally, all of these methods have a second point of vulnerability that simply doesn't exist for the proof-of-control methods: the random token must be kept secret. There is no analysis where two methods that are nearly equivalent, but one requires a secret to be kept and the other doesn't, have the same security properties.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Now, I'm not actually advocating for all of the Domain Contact-based methods to be removed. I think that would be a somewhat extreme position, and one in which I have no personal stake as the CA that I represent doesn't use those methods. But I think we do need to carefully consider the ways in which Domain Contact information is acquired, and cease thinking of these methods as somehow stronger than their peers just because they purport to validate something more permanent than "instantaneous control".<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Aaron<o:p></o:p></p></div></div></div></div></div></body></html>