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 < [email protected]> 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 <[email protected]> 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 < > [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” > > 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 <[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 > > _______________________________________________ > Servercert-wg mailing list > [email protected] > https://lists.cabforum.org/mailman/listinfo/servercert-wg > _______________________________________________ > Servercert-wg mailing list > [email protected] > https://lists.cabforum.org/mailman/listinfo/servercert-wg >
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
