[Servercert-wg] Discussion Period Begins - Ballot SC-080 V1: "Sunsetting use of WHOIS to identify Domain Contacts"
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Tue Sep 17 07:04:28 UTC 2024
On 16/9/2024 10:25 μ.μ., Amir Omidi wrote:
> > 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.
In most cases, the data structure has similar patterns and CAs have
developed methods to structure this data. DNS is also unauthenticated
data but it's been working well so far.
>
> 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.
I stand corrected on the vanity part. You are correct. We should also
not discriminate but need to take measures proportional with the threat
and potential impact. If I understand correctly, this is about
insecure/bad implementation of WHOIS libraries that use stale entry
points to query certain TLDs, instead of refreshing the IANA sources or
using IANA and then following referrals. Please correct me if I'm
missing something.
>
> 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.
That makes sense but kills a method that is actively used securely for
the vast majority of queries to Domain Name Registrars. Instead we could
add controls for CAs to use WHOIS queries securely as an emergency
ballot, and gradually deprecate the WHOIS protocol, promoting the use of
RDAP in its place.
Dimitris.
>
>
> 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 list
>> Servercert-wg at cabforum.org
>> https://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/20240917/f5f4a317/attachment-0001.html>
More information about the Servercert-wg
mailing list