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

[Amir Omidi]

> I also agree with deprecating this method but we could do it in a planned
and controlled fashion. Not all validations with this method are flawed, as
it is currently presented.

I don't think this framing is correct. WHOIS is both unstructured and
unauthenticated data.

I would also say that `.mobi` isn't necessarily a "vanity TLD" - and beyond
that, a vanity TLD is still part of this ecosystem. WebPKI should try its
best to not discriminate between TLDs.

A compromise for removing these methods can be allowing re-use of existing
authorizations done with these deprecated methods with a cut off date of
Sept 10th 2024 (around the time the watchtowr report was released), while
removing them for use for new authorizations. This would effectively buy
folks about a year time to migrate.


On Mon, Sep 16, 2024 at 1:19 PM Dimitris Zacharopoulos (HARICA) via
Servercert-wg <servercert-wg at cabforum.org> wrote:

> Is there feedback about the number of TLDs and possible certificate
> volumes that might be affected by this attack?
>
> The majority of validations performed by CAs using WHOIS is done in gTLDs
> which have decent rules for monitoring and supervising their operators. The
> biggest issue is with ccTLDs, which in majority work ok. Unfortunately,
> most of them do not disclose email contact information, making them
> unusable for Domain Validation.
>
> Why are we causing such a large disturbance as if the Global Internet is
> unsafe by this attack when the impact is 1 or 2 vanity TLDs for which
> mitigations exist (like, use a better library or use the latest updated
> list from IANA)?
>
> I also agree with deprecating this method but we could do it in a planned
> and controlled fashion. Not all validations with this method are flawed, as
> it is currently presented.
>
> Also, the deprecation date of November 1, 2024 is too soon. Even if we
> consider the 7+7=14 days to pass a ballot, there are 30 days of the IPR
> review process making this extremely close to the Nov 1, 2024 deadline. It
> is also difficult for all CAs to update their RA systems to stop re-using
> existing validation evidence in such a short timeframe.
>
> Do the authors feel this ballot is super urgent and need such an
> aggressive timeline? Is there any additional information for the potential
> impact of this attack compared to the other "healthy" cc/gTLDs? Would you
> consider an effective date closer to February or March 2025?
>
>
> Thank you,
> Dimitris.
>
>
> On 16/9/2024 7:16 μ.μ., Ryan Dickson via Servercert-wg wrote:
>
> Purpose of Ballot SC-080 V1:
>
>
>
> This Ballot proposes updates to the Baseline Requirements for the
> Issuance and Management of Publicly-Trusted TLS Server Certificates
> (i.e., TLS BRs) related to sunsetting the use of WHOIS when identifying
> Domain Contacts.
>
>
> Background:
>
>
> In light of recent events where research from WatchTowr Labs demonstrated
> how threat actors could exploit WHOIS to obtain fraudulently issued TLS
> certificates [1] and follow-on discussions in MDSP [2][3], we drafted an
> introductory proposal [4] to sunset the use of WHOIS for identifying Domain
> Contacts.
>
>
> The proposal sets a prohibition against relying on WHOIS to identify
> Domain Contacts beginning 11/1/2024. At the same time, it also prohibits
> use of DCV reuse where WHOIS was used as the source of truth for a Domain
> Contact.
>
>
>
> Proposal Revision History:
>
>    - Pre-Ballot Version #1 [4]
>
>
>
> Previous Versions of this Ballot:
>
>    - N/A
>
>
> References:
>
> [1]
> https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/
>
> [2]
> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U
>
> [3]
> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA
>
> [4] https://github.com/cabforum/servercert/pull/548
>
> [5]
> https://docs.google.com/spreadsheets/d/1IXL8Yk12gPQs8GXiosXCPLPgATJilaiVy-f9SbsMA28/edit?gid=268412787#gid=268412787
>
>
>
> The following motion has been proposed by Ryan Dickson and Chris Clements
> of Google (Chrome Root Program) and endorsed by Arvid Vermote (GlobalSign)
> and Pedro Fuentes (OISTE).
>
>
> — Motion Begins —
>
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted TLS Server Certificates” (“Baseline
> Requirements”), based on Version 2.0.7.
>
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
>
> https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..356799f0dcfe11deb0a375a11233403236ab72c9
>
>
>
> — Motion Ends —
>
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
>
> Discussion (7 days)
>
> - Start: 2024-09-16 16:00:00 UTC
>
> - End no earlier than: 2024-09-23 16:00:00 UTC
>
>
>
> Vote for approval (7 days)
>
> - Start: TBD
>
> - End: TBD
>
>
> _______________________________________________
> Servercert-wg mailing listServercert-wg at cabforum.orghttps://lists.cabforum.org/mailman/listinfo/servercert-wg
>
>
> _______________________________________________
> 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/20240916/24ac0348/attachment-0001.html>