[Servercert-wg] Discussion Period Begins - Ballot SC-080 V1: "Sunsetting use of WHOIS to identify Domain Contacts"

Tue Sep 17 16:03:42 UTC 2024

Hi all,

Thanks for your feedback thus far! Understanding other perspectives from
the community has been very helpful.

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.

On the implementation timeline:

   - We welcome and expect(ed) continued discussion.
   - 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.

On the impact of the proposed sunset:

   - 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.
   - 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.

On the approach:

   - I interpret feedback from Francisco [3] to suggest that the immediate
   focus should be sunsetting information retrieved via RFC 3912 lookups.
   - 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.
   - 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.
   - 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.

Questions: Can those willing to share an opinion help me better understand…

   - 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?
   - A description of active reliance on RFC 3912 lookups and/or lookups
   relying on HTTPS Websites hosting WHOIS tools?
   - How do we feel about the approach described in [5]?

Thanks again,
Ryan

[1]
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/3Gy6LcHsAQAJ
[2]
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/FRXLDjXwAQAJ
[3]
https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004834.html
[4]
https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004840.html
[5]
https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html
[6]
https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004835.html

On Tue, Sep 17, 2024 at 11:22 AM Maria Merkel <maria at maria.cc> wrote:

> 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:
> https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf
>
> In most of these takeover situations, I would assume the Whois server was
> first offline for an extended period of time.
>
> I also think the timeline for disallowing Whois is too short, and maybe
> disallowing it for ccTLDs only first may be an acceptable compromise.
>
> On Tue, Sep 17, 2024 at 5:13 PM Andrew Ayer via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> Hi Ryan,
>>
>> We've seen evidence of two distinct security issues:
>>
>> 1. CAs relying on an out-of-date database of WHOIS servers (original
>> WatchTowr analysis).
>>
>> 2. ccTLDs not maintaining an accurate record of their WHOIS server in
>> the IANA Root Zone database (Hanno's analysis at [1]).
>>
>> We have not seen any evidence of issues with the WHOIS servers for
>> gTLDs in IANA's database.  Indeed, all 17 examples of outdated WHOIS
>> servers are for ccTLDs despite there being 4 times as many gTLDs as
>> ccTLDs.
>>
>> I don't think it's reasonable to generalize to gTLDs based on ccTLDs,
>> as ccTLDs aren't bound by any registry agreements and have historically
>> been operated less competently than gTLDs.  For example:
>>
>> Outages of .io NS servers:
>>
>> https://hackernoon.com/stop-using-io-domain-names-for-production-traffic-b6aa17eeac20
>>
>> Hijacking NS servers for .io:
>>
>> https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/
>>
>> Hijacking NS servers for .cd:
>>
>> https://labs.detectify.com/writeups/how-i-hijacked-the-top-level-domain-of-a-sovereign-state/
>>
>> Registry compromise of .tg:
>>
>> https://groups.google.com/g/mozilla.dev.security.policy/c/4kj8Jeem0EU/m/GvqsgIzSAAAJ
>>
>> The last three issues were security-critical and impacted DNS-based
>> domain validation. It seems only the last issue was noticed by the
>> WebPKI community, and the response was scoped only to .tg.
>>
>> A more targeted ballot would:
>>
>> 1. Require CAs to perform WHOIS lookups by sending a query to IANA's
>> WHOIS server and following the referral to the TLD's WHOIS server.
>> Require CAs to perform RDAP lookups by using IANA's bootstrap file.
>> Ban the use of HTTPS websites.  I believe this would give WHOIS/RDAP
>> validation comparable security properties to DNS-based validation
>> for gTLDs.  Note that the gTLD registry agreement places the same
>> requirements on updating WHOIS/RDAP server information as it does on
>> updating DNS server information.[2]
>>
>> 2. Ban WHOIS/RDAP for ccTLDs.
>>
>> Regrettably, parsing emails sent to a Domain Contact is often the
>> easiest way to implement automated validation for a large number of
>> domains, since it allows delegation to a single central point, using
>> configuration that is often already in place (WHOIS record contact
>> information). Delegating DNS records using CNAME (e.g. with [3]) is
>> better, but not as easy because it requires the subscriber to operate
>> public-facing infrastructure.  So I think that banning WHOIS,
>> particularly on this timeline, would lead to a net reduction in
>> automation, and I don't believe this is justified by the available
>> evidence when a more targeted fix is available.
>>
>> Regards,
>> Andrew
>>
>> [1]
>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240913151529.2289f19d%40computer
>>
>> [2]
>> https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-21-01-2024-en.html
>> "IANA Rootzone Database"
>>
>> [3] https://github.com/joohoi/acme-dns/
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240917/9bd76f56/attachment-0001.html>