<div dir="ltr"><div>Hi all,<br><br>Thanks for your feedback thus far! Understanding other perspectives from the community has been very helpful.<br><br>Trying to focus my response on the themes I understand from the last 24hrs of discussion in hopes of helping us move forward in a common direction.</div><div><span><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(0,0,0);background-color:transparent;font-weight:700;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif">On the implementation timeline:</font></span></p><ul><li><span id="m_-1424866073359714315m_-347336746046255284m_-6796603869944568816gmail-docs-internal-guid-5d69d76a-7fff-a1f2-c841-a2c71c443964">We welcome and expect(ed) continued discussion.</span></li><li>IMO, the specific date is ultimately less important than the Forum taking clear steps to act in response to a well substantiated security risk. The proposal for an accelerated timeline was intended to reliably reduce further potential abuse like that described possible by the WatchTowr report.  </li></ul><div><br></div><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(0,0,0);background-color:transparent;font-weight:700;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif">On the impact of the proposed sunset: </font></span></p><ul><li><span id="m_-1424866073359714315m_-347336746046255284m_-6796603869944568816gmail-docs-internal-guid-5d69d76a-7fff-a1f2-c841-a2c71c443964">As far as I understand, there’s no public disclosure related to “in-use” DCV methods other than the CCADB report shared in my last message. Even then, the data is specific to the method, not the actual approach used in that method (e.g., an instance of “3.2.2.4.4" does not guarantee reliance on RFC 3912). The level of specificity included in CP/CPSs often does not go to this level of detail, nor do these documents affirm a method is actively in-use, as opposed to being eligible for use.</span></li><li>So far, there’s been little discussion [1] on the reliance of WHOIS. One [2] interpretation of this is that CAs aren’t heavily relying on WHOIS, suggesting little impact to deprecation. We were hoping this discussion period would help better establish that context, as it cannot otherwise be measured externally. It has not yet done so.</li></ul><div><br></div><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="color:rgb(0,0,0);background-color:transparent;font-weight:700;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><font face="arial, sans-serif">On the approach:</font></span></p><ul><li><span id="m_-1424866073359714315m_-347336746046255284m_-6796603869944568816gmail-docs-internal-guid-5d69d76a-7fff-a1f2-c841-a2c71c443964">I interpret feedback from Francisco [3] to suggest that the immediate focus should be sunsetting information retrieved via RFC 3912 lookups.</span></li><li>I also interpret the WatchTowr report to indicate information retrieved from HTTPS Websites could be impacted. It’s not clear to me how CAs relying on HTTPS Websites hosting WHOIS tools can discern “flawed” lookups when using these tools from “good” ones. I interpret Andrew’s response [4] to agree with this position.</li><li>The approach Andrew laid out here [5] seems reasonable - and appears generally consistent with how I interpret part of Dimitris' proposal [6]. Additional feedback would be appreciated.</li><li>Longer term, I believe we should question the value of DCV methods that are either predominantly “manual", face challenges at scale, or are incompatible with renewal expectations described by the TLS BRs (e.g., is DCV via postal mail a reliable response to a 24 hour revocation event, and if not, is it responsible for us to continue allowing it?). This opinion is based on the perceived importance of agility and resilience of the Web PKI ecosystem.</li></ul><div><br></div><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font face="arial, sans-serif"><span style="color:rgb(0,0,0);background-color:transparent;font-weight:700;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">Questions: </span><span style="color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">Can those willing to share an opinion help me better understand…</span></font></p><ul><li><span id="m_-1424866073359714315m_-347336746046255284m_-6796603869944568816gmail-docs-internal-guid-5d69d76a-7fff-a1f2-c841-a2c71c443964">What criteria this community should use to establish an acceptable timeline for sunsetting or improving a DCV method that’s been demonstrated as either 1) capable of being abused or 2) offers unreliable security properties?</span></li><li>A description of active reliance on RFC 3912 lookups and/or lookups relying on HTTPS Websites hosting WHOIS tools?</li><li>How do we feel about the approach described in [5]?</li></ul><div><br></div>Thanks again,<br>Ryan<br><br>[1] <a href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/3Gy6LcHsAQAJ" target="_blank">https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/3Gy6LcHsAQAJ</a><br>[2] <a href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/FRXLDjXwAQAJ" target="_blank">https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/FRXLDjXwAQAJ</a><br>[3] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004834.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004834.html</a> <br>[4] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004840.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004840.html</a> <br>[5] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html</a> <br>[6] <a href="https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004835.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004835.html</a></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2024 at 11:22 AM Maria Merkel <<a href="mailto:maria@maria.cc" target="_blank">maria@maria.cc</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">It is worth adding that ICANN not only requires Whois availability in their agreements with gTLDs, but actually monitors it, so it is unlikely that these could have a non-functioning entry for very long: <a href="https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf" target="_blank">https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf</a><div><br></div><div>In most of these takeover situations, I would assume the Whois server was first offline for an extended period of time.</div><div><br></div><div>I also think the timeline for disallowing Whois is too short, and maybe disallowing it for ccTLDs only first may be an acceptable compromise.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2024 at 5:13 PM Andrew Ayer via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Ryan,<br>
<br>
We've seen evidence of two distinct security issues:<br>
<br>
1. CAs relying on an out-of-date database of WHOIS servers (original<br>
WatchTowr analysis).<br>
<br>
2. ccTLDs not maintaining an accurate record of their WHOIS server in<br>
the IANA Root Zone database (Hanno's analysis at [1]).<br>
<br>
We have not seen any evidence of issues with the WHOIS servers for<br>
gTLDs in IANA's database.  Indeed, all 17 examples of outdated WHOIS<br>
servers are for ccTLDs despite there being 4 times as many gTLDs as<br>
ccTLDs.<br>
<br>
I don't think it's reasonable to generalize to gTLDs based on ccTLDs,<br>
as ccTLDs aren't bound by any registry agreements and have historically<br>
been operated less competently than gTLDs.  For example:<br>
<br>
Outages of .io NS servers:<br>
<a href="https://hackernoon.com/stop-using-io-domain-names-for-production-traffic-b6aa17eeac20" rel="noreferrer" target="_blank">https://hackernoon.com/stop-using-io-domain-names-for-production-traffic-b6aa17eeac20</a><br>
<br>
Hijacking NS servers for .io:<br>
<a href="https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/" rel="noreferrer" target="_blank">https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/</a><br>
<br>
Hijacking NS servers for .cd:<br>
<a href="https://labs.detectify.com/writeups/how-i-hijacked-the-top-level-domain-of-a-sovereign-state/" rel="noreferrer" target="_blank">https://labs.detectify.com/writeups/how-i-hijacked-the-top-level-domain-of-a-sovereign-state/</a><br>
<br>
Registry compromise of .tg:<br>
<a href="https://groups.google.com/g/mozilla.dev.security.policy/c/4kj8Jeem0EU/m/GvqsgIzSAAAJ" rel="noreferrer" target="_blank">https://groups.google.com/g/mozilla.dev.security.policy/c/4kj8Jeem0EU/m/GvqsgIzSAAAJ</a><br>
<br>
The last three issues were security-critical and impacted DNS-based<br>
domain validation. It seems only the last issue was noticed by the<br>
WebPKI community, and the response was scoped only to .tg.<br>
<br>
A more targeted ballot would:<br>
<br>
1. Require CAs to perform WHOIS lookups by sending a query to IANA's<br>
WHOIS server and following the referral to the TLD's WHOIS server.<br>
Require CAs to perform RDAP lookups by using IANA's bootstrap file.<br>
Ban the use of HTTPS websites.  I believe this would give WHOIS/RDAP<br>
validation comparable security properties to DNS-based validation<br>
for gTLDs.  Note that the gTLD registry agreement places the same<br>
requirements on updating WHOIS/RDAP server information as it does on<br>
updating DNS server information.[2]<br>
<br>
2. Ban WHOIS/RDAP for ccTLDs.<br>
<br>
Regrettably, parsing emails sent to a Domain Contact is often the<br>
easiest way to implement automated validation for a large number of<br>
domains, since it allows delegation to a single central point, using<br>
configuration that is often already in place (WHOIS record contact<br>
information). Delegating DNS records using CNAME (e.g. with [3]) is<br>
better, but not as easy because it requires the subscriber to operate<br>
public-facing infrastructure.  So I think that banning WHOIS,<br>
particularly on this timeline, would lead to a net reduction in<br>
automation, and I don't believe this is justified by the available<br>
evidence when a more targeted fix is available.<br>
<br>
Regards,<br>
Andrew<br>
<br>
[1] <a href="https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240913151529.2289f19d%40computer" rel="noreferrer" target="_blank">https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240913151529.2289f19d%40computer</a><br>
<br>
[2] <a href="https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-21-01-2024-en.html" rel="noreferrer" target="_blank">https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-21-01-2024-en.html</a> "IANA Rootzone Database"<br>
<br>
[3] <a href="https://github.com/joohoi/acme-dns/" rel="noreferrer" target="_blank">https://github.com/joohoi/acme-dns/</a><br>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div>
</blockquote></div>