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