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

Mon Sep 23 19:50:41 UTC 2024

I guess that if the aim is parity with DNS-based validation (which I agree
it should be), one question is "what is the equivalent of MPIC for WHOIS,
and is it feasible to do?"

Mike

On Mon, Sep 23, 2024 at 3:48 PM Ryan Dickson via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> [Responding to the most recent message in the discussion, apologies if
> this causes unexpected threading.]
>
> Hi all,
>
> Given the discussion thus far, I’d like to propose the following for the
> group’s consideration in an effort to help guide a second round of
> discussion (TBD, but expected to begin no earlier than September 30).
>
>
> *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 [1] 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
>    [2] 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 [3] 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 [4] and are considered in this update.
>
> *Approach: *
>
>    - Add the following requirements in Sections 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”), and 3.2.2.4.15 (“Phone Contact with Domain Contact”).
>
> “
> *Effective January 15, 2025, when issuing Subscriber Certificates…*
>
>    - *The CA MUST NOT rely on Domain Contact information obtained using
>    an HTTPS website, regardless of whether previously obtained information is
>    within the allowed reuse period.*
>    - *The CA MUST NOT rely on Domain Contact information obtained using
>    the WHOIS protocol (RFC 3912) or the Registry Data Access Protocol (RFC
>    7482) if the requested Domain Name contains a ccTLD, regardless of whether
>    previously obtained information is within the allowed reuse period.*
>    - *When obtaining Domain Contact information using the WHOIS protocol,
>    the CA MUST query IANA's WHOIS server and follow referrals to the
>    appropriate gTLD WHOIS server.*
>    - *When obtaining Domain Contact information using the Registry Data
>    Access Protocol, the CA MUST utilize IANA's bootstrap file to identify and
>    query the correct RDAP server for the domain.*
>    - *The CA SHOULD NOT rely on cached 1) WHOIS server information or 2)
>    RDAP bootstrap data from IANA to ensure that it relies upon up-to-date and
>    accurate information.*”
>
>
>
> *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 update (above), there is limited public evidence of
>    significant reliance on these methods, including in response to [2] and [5].
>    - Instead, discussion has identified at least one CA Owner has already
>    sunset reliance on WHOIS [6], and another that has changed its approach [7]
>    for relying on WHOIS since disclosure of [1].
>    - 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., [8] and [9]),
>    while also benefiting from recently improved security practices [10]. 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 [11].
>    - Beyond the above, previous discussions within the CA/Browser Forum
>    have raised concerns about the perceived value (e.g., [12]) and security
>    (e.g., [13]) of the DCV methods relying on WHOIS, further supporting the
>    rationale for their gradual sunset.
>
> *Approach:*
>
>    - Add the following requirements to Sections 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”).
>
> “*Effective September 15, 2025, the CA MUST NOT rely on this method.*”
>
>
> The effective dates considered in this update are intended to 1) address
> the immediate concerns identified by [1], 2) offer near-term and
> longer-term transition periods for subscribers and CA Owners relying on
> existing implementations of these methods, and 3) align with existing
> effective dates in the TLS BRs (e.g., [10]).
>
> The above proposed updates compared to the initial effort described in
> [14] are highlighted at [15]. A comparison of these proposed updates
> against the in-force BRs is available at [16]
>
> Comments are welcome either on-list or with suggested edits via GitHub
> (preferred) at [17].
>
> Thanks,
> Ryan
>
> [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/m/hKJOz3XzAAAJ
> [3]
> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mAl9XjieSkA/m/oDNWxtPwAQAJ
> [4]
> https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004839.html
> [5]
> https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004844.html
> [6]
> https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/
> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1917896
> [8]
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change
> [9]
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322419-agreed-upon-change-to-website---acme
> [10]
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3229-multi-perspective-issuance-corroboration
> [11]
> https://cabforum.org/working-groups/server/baseline-requirements/requirements/#491-circumstances-for-revocation
> [12]
> https://archive.cabforum.org/pipermail/servercert-wg/2018-August/000113.html
> [13] https://lists.cabforum.org/pipermail/validation/2024-July/001995.html
> [14]
> https://archive.cabforum.org/pipermail/servercert-wg/2024-September/004825.html
> [15]
> https://github.com/ryancdickson/staging/compare/356799f0dcfe11deb0a375a11233403236ab72c9..7a2ea7b33611bebf006a99a9a82729f183143eac
> [16]
> https://github.com/ryancdickson/staging/compare/ba28d04894d69c8fac62850b9d0de5061658c7c5..7a2ea7b33611bebf006a99a9a82729f183143eac
> [17] https://github.com/ryancdickson/staging/pull/9
>
>
> On Wed, Sep 18, 2024 at 3:11 PM Amir Omidi via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> I do not know much about the state of subdomain auth deployment in the CA
>> ecosystem unfortunately.
>>
>> On Wed, Sep 18, 2024 at 2:09 PM Andrew Ayer <agwa at andrewayer.name> wrote:
>>
>>> Hi Amir,
>>>
>>> On Wed, 18 Sep 2024 15:48:38 +0000
>>> Amir Omidi via Servercert-wg <servercert-wg at cabforum.org> wrote:
>>>
>>> > There are two CAs (Let's Encrypt and Google Trust Services) with
>>> > DNS-ACCOUNT-01 (
>>> >
>>> https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/)
>>> > mostly ready to go. This draft is designed to solve the CNAME
>>> > delegation problem.
>>>
>>> It doesn't obviate the need to run an acme-dns server (or similar) but
>>> DNS-ACCOUNT-01 would indeed be a great help.  Note that RFC9444
>>> (subdomain auth) support is also needed as otherwise the subscriber
>>> has to add delegations for every hostname instead of just one per zone.
>>> Do you know what the state of CA adoption is there?
>>>
>>> In any case, I'll give this I-D a more thorough look and provide
>>> feedback in the ACME WG.
>>>
>>> Regards,
>>> Andrew
>>>
>> _______________________________________________
>> 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/20240923/857dc519/attachment.html>