Hi Doug,
> The title, purpose and background of this ballot define the removal of WHOIS
and does not discuss any other changes, but we’re actually sunsetting other
aspects of domain validation while also leaving method 3.2.2.4.12 that can
continue to use WHOIS.
I feel “Objective 2", included in the “Background" section, makes the intent to sunset methods
clear (the objective's description is: "/Sunset Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail
to Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain Contact")/").
Would changing the title to something like “/Strengthen registration data lookups
and Sunset Methods 3.2.2.4.2 and 3.2.2.4.15/" help?
> I understand the desire to remove WHOIS based on the recent incident(s), but
if we’re going to focus on sunsetting WHOIS, we should 100% sunset it for all uses
and we should not include the removal of other methods within this ballot.
All methods relying on identifying Domain Contacts via registration data are
strengthened by this ballot, beginning January 15, 2025. This includes methods:
- 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact")
- 3.2.2.4.12 (“Validating Applicant as a Domain Contact")
- 3.2.2.4.15 (“Phone Contact with Domain Contact")
The ballot goes on to sunset the following methods, beginning July 15, 2025:
- 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail to Domain Contact")
- 3.2.2.4.15 (“Phone Contact with Domain Contact")
The only method relying on identifying a “Domain Contact" via registration data left by
the ballot is 3.2.2.4.12 (“Validating Applicant as a Domain Contact"). This was
originally excluded from the scope of sunsets given the expectation that in cases where the
organization operating the CA was also the Domain Name Registrar (or an Affiliate), there
would be (1) a lower likelihood of unreliable Domain Contact information given a direct
relationship with the subscriber/subscriber organization, and (2) a higher potential for
seamless certificate lifecycle management because of that relationship. Regardless of whether
this expectation is misguided, nothing stops a future ballot from contemplating the further
improvement or sunset of 3.2.2.4.12 (“Validating Applicant as a Domain Contact").
If there’s a case to make for including 3.2.2.4.12 in the sunsets covered in
the proposal, it’s also welcome.
> The VWG can be tasked to review methods we think are weak and discuss
removing them, for example, imo, all the methods that rely on phone calls (Domain
and IP address both), which to me are weaker than automated methods like using
they SOA record.
I agree that it’s important for this community to routinely re-evaluate the DCV
methods permitted by the TLS BRs and consider them against a set of desirable
security and operational properties that best enable subscriber organizations to
make securely managing their TLS implementations “boring" (effortless, routine,
reliable, and without excitement - even when facing the unexpected).
Periodically over the past three years (when I joined this community), I’ve
participated in discussions where members have expressed a desire for improved
DCV methods, which has included suggestions to remove perceived weak methods
(with those that are phone or email-based cited as examples). While very few of
these discussions have led to direct action, this ballot presents a proactive
opportunity to address some of those concerns, along with mitigating concerns
related to registration data lookups identified by recent events.
I do not believe a holistic evaluation of the DCV-methods permitted by the TLS
BRs needs to be a blocking function on this ballot, and that both activities
can take place independently of one another.
Thanks,
Ryan
On Mon, Oct 7, 2024 at 7:35 AM Doug Beattie <[email protected]
<mailto:[email protected]>> wrote:
Hi Ryan,____
__ __
The title, purpose and background of this ballot define the removal of
WHOIS and does not discuss any other changes, but we’re actually sunsetting
other aspects of domain validation while also leaving method 3.2.2.4.12 that
can continue to use WHOIS. Part of this is the unfortunately extremely broad
definition of “Domain Contact” and “Domain Name Registrant” and the wide scope
of 3.2.2.4.2, which I agree we need to clarify and fix. I understand the
desire to remove WHOIS based on the recent incident(s), but if we’re going to
focus on sunsetting WHOIS, we should 100% sunset if for all uses and we should
not include the removal of other methods within this ballot. The VWG can be
tasked to review methods we think are weak and discuss removing them, for
example, imo, all the methods that rely on phone calls (Domain and IP address
both), which to me are weaker than automated methods like using they SOA
record.____
__ __
Doug____
__ __
*From:*Ryan Dickson <[email protected] <mailto:[email protected]>>
*Sent:* Friday, October 4, 2024 2:55 PM
*To:* Doug Beattie <[email protected]
<mailto:[email protected]>>
*Cc:* CA/B Forum Server Certificate WG Public Discussion List
<[email protected] <mailto:[email protected]>>
*Subject:* Re: [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2:
"Sunset the use of WHOIS to identify Domain Contacts and relying DCV
Methods”____
__ __
Hi Doug,____
__ __
Your interpretation of the latest version of the ballot is correct. ____
__ __
As currently presented, Method 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail
to Domain Contact”) and Method 3.2.2.4.15 (“Phone Contact with Domain Contact”)
are sunset, in their entirety, effective July 15, 2025. ____
__ __
Specific to domain contact email addresses from SOA records, can you share
your perspective for adding this specific option given the existence of (1)
other email-based alternatives (e.g., 3.2.2.4.4, 3.2.2.4.13 and 3.2.2.4.14) and
(2) other far more heavily relied upon DCV methods that present an opportunity
for improved automation and scalability (and also benefit from MPIC)?____
__ __
For example, detailing responses below would be helpful for
understanding:____
* existing reliance on this specific approach in comparison to the other
DCV methods offered?____
* how this reliance has trended over time (e.g., last 1 / 3 / 5
years)?____
* how the sunset would affect subscribers?____
* a general description of the level of effort for affected subscribers
to transition to another method?____
* what barriers exist that prevent subscribers from transitioning to
other methods?____
__ __
I think it’s reasonable for the community to approach RNAME lookups with
the same degree of concern for accuracy and reliability as registration data
due to the potential for:____
* neglected configurations (e.g., in 2020, [1] indicated only 39.74% of a
set of “top” 1M domains contained “reachable” SOA contacts, and only
approximately 20% of the sampled .com and .net domains did).____
* potential CA reliance on third-party tools with unknown operational
characteristics for performing SOA lookups (the same concern as WHOIS lookups
using HTTPS websites).____
* a lack of oversight and enforcement for ensuring SOA record updates
(e.g, accuracy/correctness and timeliness).____
* use of automated DNS management solutions that can result in an
unintended and/or unknown delegation of authority to approve TLS certificates,
while also representing a single point of failure (or attack).____
__ __
Thanks,____
Ryan____
__ __
[1] https://mkorczynski.com/WTMC2020.pdf
<https://mkorczynski.com/WTMC2020.pdf>____
__ __
__ __
On Thu, Oct 3, 2024 at 9:57 AM Doug Beattie <[email protected]
<mailto:[email protected]>> wrote:____
Hey Ryan,____
____
The way I read the ballot is that using domain approver email addresses
from SOA records is being removed since that’s part of 3.2.2.4.2. Should we
add a new method specifically for that, or was the intent to remove that as a
valid location to obtain domain approver email addresses?____
Doug____
____
*From:*Servercert-wg <[email protected]
<mailto:[email protected]>> *On Behalf Of *Ryan Dickson via
Servercert-wg
*Sent:* Tuesday, October 1, 2024 12:59 PM
*To:* ServerCert CA/BF <[email protected]
<mailto:[email protected]>>
*Subject:* [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2:
"Sunset the use of WHOIS to identify Domain Contacts and relying DCV
Methods”____
____
*_Purpose of Ballot SC-080 V2:
_*This ballot proposes updates to the Baseline Requirements for the
Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs)
to address concerns regarding the use of WHOIS and HTTPS websites for
identifying Domain Contacts.
*_Background:
_*This ballot intends to accomplish two objectives, originally
described in [1].____
Objective 1: Enhance WHOIS/RDAP validation of gTLDs with comparable
security properties to DNS-based validation and sunset WHOIS/RDAP for ccTLDs.
_Justification:_____
* A recent disclosure [2] demonstrated how threat actors could
exploit deficiencies in the WHOIS protocol and WHOIS tools served via HTTPS
websites to obtain fraudulent TLS certificates.____
* Discussions within the Mozilla Dev Security Policy (MDSP) community
[3] further expressed corresponding risks related to WHOIS, while also noting
that ccTLDs may not maintain accurate or up-to-date WHOIS server records.
Several examples of inoperative WHOIS servers for ccTLDs were identified.____
* Discussion in [4] further called into question the reliability of
ccTLD WHOIS servers given, per IANA, there is no global policy requirement for
ccTLD managers to operate a WHOIS server, and if they do, what kind of
information is provided.____
* Solutions to strengthen existing WHOIS lookup methods were proposed
in [5] and are considered in this ballot.____
____
Objective 2: Sunset Methods 3.2.2.4.2 (“Email, Fax, SMS, or Postal Mail
to Domain Contact”) and 3.2.2.4.15 (“Phone Contact with Domain Contact”).
_Justification:_____
* While solutions to strengthen WHOIS-relying DCV methods are
considered in this ballot (see above), there is limited public evidence of
significant reliance on these methods, including in response to [3] and [6].____
* Instead, discussion has identified at least one CA Owner has
already sunset reliance on WHOIS [7], and another that has changed its approach
[8] for relying on WHOIS since disclosure of [2].____
* More modern and heavily relied-upon DCV methods offer advantages
over the existing WHOIS-based methods, including greater opportunity for
seamless certificate lifecycle management automation (e.g., [9] and [10]),
while also benefiting from recently improved security practices [11]. These
methods can also more effectively align subscriber capabilities with agility
and resilience expectations necessary to respond to the revocation timelines
described in the TLS BRs [12].____
* Beyond the above, previous discussions within the CA/Browser Forum
have raised concerns about the perceived value (e.g., [13]) and security (e.g.,
[14]) of the DCV methods relying on WHOIS, further supporting the rationale for
their gradual sunset.____
*_Benefits of adoption:_*____
* Enhanced Security: Eliminates reliance on outdated and vulnerable
DCV methods that cannot consistently provide the security required by the TLS
BRs, or benefit from recent DCV security enhancements (i.e., Multi-Perspective
Issuance Corroboration [11]). ____
* Increased Agility: Encourages site owners to transition to modern
DCV methods, creating opportunities for faster, more efficient, and less
error-prone certificate lifecycle management. ____
* Opportunity for Innovation: Promotes the development of new and/or
improved DCV methods, fostering innovation that may enhance the overall
security and agility of the ecosystem.____
*_Proposed Key Dates:_*____
The effective dates considered in this update are intended to 1)
address the immediate concerns identified by [2], and 2) offer near-term and
longer-term transition periods for subscribers and CA Owners relying on
existing implementations of these methods.____
* January 15, 2025: (1) Prohibit the use of RFC 3912 (WHOIS) and
HTTPS websites to identify Domain Contact information. (2) Prohibit the reuse
of DCV relying on information obtained using these technologies. (3) Prohibit
WHOIS-based DCV methods for Subscriber Certificates containing ccTLDs. (4) CAs
MUST NOT rely on cached WHOIS/RDAP data more than 48 hours old. ____
* July 15, 2025: (1) Sunset DCV Methods 3.2.2.4.2 ("Email, Fax, SMS, or Postal Mail
to Domain Contact") and 3.2.2.4.15 ("Phone Contact with Domain Contact"). (2) Prior
validations using these methods and validation data gathered therein MUST NOT be used to issue new
Subscriber Certificates.____
*_Proposal Revision History:_*____
* Pre-Ballot Version #1 [4]____
* Ballot Version #1 [7]____
* Version #2 Pre-Release [17] and discussion [18]____
* Version #2 (this version) [19]____
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..7f2b54cfa5b89f41458a88211566ce508c464804
<https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7f2b54cfa5b89f41458a88211566ce508c464804>
— Motion Ends —
This ballot proposes a Final Maintenance Guideline. The procedure for
approval of this ballot is as follows:
_Discussion (no less than 7 days)_____
* Start: 2024-10-01 17:00:00 UTC____
* End no earlier than: 2024-10-08 17:00:00 UTC____
_Vote for approval (7 days)_____
* Start: TBD____
* End: TBD____
____
Comments are welcome either on-list or with suggested edits via GitHub
(preferred) at [19].____
____
Thanks,____
Ryan____
____
____
*References:*____
[1]
https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html
<https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004900.html>
[2]
https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/
<https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/>
[3]
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ
<https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/FuOi_uhQB6U/m/hKJOz3XzAAAJ>
[4]
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ
<https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ>
[5]
https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html
<https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html>
[6]
https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html
<https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html>
[7]
https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/
<https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/>
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1917896
<https://bugzilla.mozilla.org/show_bug.cgi?id=1917896>
[9]
https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change
<https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change>
[10]
https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme
<https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme>
[11]
https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration
<https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration>
[12]
https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation
<https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation>
[13]
https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html
<https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html>
[14] https://lists.cabforum.org/pipermail/validation/2024-July/001995.html
<https://lists.cabforum.org/pipermail/validation/2024-July/001995.html>
[15]
https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html
<https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html>
[16]
https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac
<https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac>
[17]
https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac
<https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac>
[18] https://github.com/ryancdickson/staging/pull/9
<https://github.com/ryancdickson/staging/pull/9>
[19] https://github.com/cabforum/servercert/pull/551
<https://github.com/cabforum/servercert/pull/551>____
____
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
