<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
Thanks for steering the discussion, Ryan, and for offering summaries
and recaps that help it move forward.<br>
<br>
<div class="moz-cite-prefix">On 17/9/2024 7:04 μ.μ., Ryan Dickson
via Servercert-wg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0100019200ba88ef-9c4dee1f-54d8-40a9-a734-2c92f6b533c7-000000@email.amazonses.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
</blockquote>
<span><font face="arial, sans-serif">[...]</font></span>
<blockquote type="cite"
cite="mid:0100019200ba88ef-9c4dee1f-54d8-40a9-a734-2c92f6b533c7-000000@email.amazonses.com">
<div dir="ltr">
<div><span>
<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>
</span></div>
</div>
</blockquote>
<br>
I will only comment on the approach described in [5] to ban
WHOIS/RDAP for ccTLDs in general (of course I agree with the first
suggestion in [5]). <br>
<br>
I would consider it unfair to ban all ccTLDs when some of those
operators do a great job at operating and maintaining these critical
services, even better than some gTLD operators. Granted that there
is no global oversight of their operations, however there are
multiple jurisdictions that take these services very seriously,
enough to apply strict supervision like the one applied to power
plants, public transportation, telecommunication providers and
nuclear factories!<br>
<br>
An alternative suggestion would be to create a block list of ccTLDs
for which there is undisputed evidence that certain
Registrars/Operators are not performing their duties in a reliable
way. But even in that case, why would the Forum want to be in a
position to deprive Domain Owners of Domain Names under "unreliable"
Registrars, the right to obtain a publicly-trusted certificate to
secure communications? The Forum has even established methods to
securely offer certificates to onion Domain Names that are outside
the DNS.<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
<br>
<blockquote type="cite"
cite="mid:0100019200ba88ef-9c4dee1f-54d8-40a9-a734-2c92f6b533c7-000000@email.amazonses.com">
<div dir="ltr">
<div><span>
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/joohoi/acme-dns/</a><br>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org"
moz-do-not-send="true" class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a><br>
<a
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote>
</div>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
Servercert-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
</blockquote>
<br>
</body>
</html>