[Servercert-wg] Discussion Period Begins - Ballot SC-080 V2: "Sunset the use of WHOIS to identify Domain Contacts and relying DCV Methods”
Ryan Dickson
ryandickson at google.com
Tue Oct 8 19:15:32 UTC 2024
Hi Rob!
Welcome to the community, we’re glad to have you!
> Yoshihiko-sama's points below are very similar to a variety of use cases
we're researching and unless there's an exception as outlined it looks like
Ballot SC-080 could WEAKEN security in cases like this.
Can you offer more detail on:
- How specifically will the proposed changes weaken security?
- What precisely is the exception that should be considered?
- What are you referring to by the phrase “extended validation?"
- How do the proposed changes impact “extended validation?”
Thanks,
Ryan
On Tue, Oct 8, 2024 at 2:12 PM Rob B via Servercert-wg <
servercert-wg at cabforum.org> wrote:
> Hello everyone,
>
> Just joined the WG as an Interested party, been lurking so far to get my
> bearings and this is my first post - please be gentle if I'm out of turn or
> off base.
>
> Yoshihiko-sama's points below are very similar to a variety of use cases
> we're researching and unless there's an exception as outlined it looks like
> Ballot SC-080 could WEAKEN security in cases like this.
>
> Feel the intent of SC-080 is to close a loophole created by 3rd party data
> of unknown provenance, however if you have validated non-public contact
> information (and almost certainly existing contractual obligations) then
> those contacts SHOULD be considered reliable and suitable starting points
> for extended validation.
>
> Kind regards,
>
>
>
> Rob Brady
>
>
> -----Original Message-----
> From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of
> Yoshihiko Matsuo via Servercert-wg
> Sent: Tuesday, October 8, 2024 7:29 AM
> To: CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> Subject: Re: [Servercert-wg] Discussion Period Begins - Ballot SC-080 V2:
> "Sunset the use of WHOIS to identify Domain Contacts and relying DCV
> Methods”
>
> All,
>
> > 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").
>
> We are the CA, and at the same time we are also the gTLD Registrar and the
> ccTLD Registry.
> In this case, I understand that it is acceptable to use the Domain
> Contacts we hold as The gTLD Registrar for DCV.I would like to hear your
> opinions on whether the same can be said for the Domain Contacts we hold as
> the ccTLD Registry.
>
> Note: We require that ccTLD Domain Contacts be kept current as the contact
> information for the domain name registrant.
>
> With this question, I would like to clarify whether the BR allows the
> following cases.
>
> 1. The CA that is also the ccTLD Registry retrieves Domain Contacts from
> its own database and performs validation in accordance with 3.2.2.4.2.
>
> 2. The CA that is also the ccTLD Registry retrieves Domain Contacts from
> the WHOIS operated by the ccTLD Registry (which is also a CA) and performs
> validation in accordance with 3.2.2.4.2.
>
> Thanks,
> Yoshihiko Matsuo(JPRS)
>
>
> On 2024/10/08 4:49, Ryan Dickson via Servercert-wg wrote:
> > 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 <doug.beattie at globalsign.com
> <mailto:doug.beattie at globalsign.com>> 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 <ryandickson at google.com <mailto:
> ryandickson at google.com>>
> > *Sent:* Friday, October 4, 2024 2:55 PM
> > *To:* Doug Beattie <doug.beattie at globalsign.com <mailto:
> doug.beattie at globalsign.com>>
> > *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>>
> > *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 <
> doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com>>
> 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 <servercert-wg-bounces at cabforum.org
> <mailto:servercert-wg-bounces at cabforum.org>> *On Behalf Of *Ryan Dickson
> via Servercert-wg
> > *Sent:* Tuesday, October 1, 2024 12:59 PM
> > *To:* ServerCert CA/BF <servercert-wg at cabforum.org <mailto:
> servercert-wg at cabforum.org>>
> > *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
> > 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
> _______________________________________________
> 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/20241008/bc69256d/attachment-0001.html>
More information about the Servercert-wg
mailing list