> 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 <[email protected]> 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 > [email protected]https://lists.cabforum.org/mailman/listinfo/servercert-wg > > > _______________________________________________ > Servercert-wg mailing list > [email protected] > https://lists.cabforum.org/mailman/listinfo/servercert-wg >
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
