[Servercert-wg] Discussion Period Begins - Ballot SC-067 V1: "Require domain validation and CAA checks to be performed from multiple Network Perspectives”

Fri Apr 5 13:58:15 UTC 2024

Hi Martijn,

Thank you for your review and comments, especially as suggested commits!

This is helpful feedback in clarifying the expectations of the Ballot, and
we’ve responded to them directly on GitHub [1]. We also staged [2] these
updates in and a separate branch [3] to avoid any confusion with the
in-progress discussion period. Feedback on these proposed updates are
welcome.

The new branch will serve as the basis for a subsequent round of Public
Discussion once this one closes.

Thanks again!

-Chris (on behalf of the Chrome Root Program)

[1] https://github.com/cabforum/servercert/pull/487/files

[2]
https://github.com/ChristopherRC/servercert/compare/SC-067-Version-1..ChristopherRC:servercert:SC-067-Version-2?expand=1

[3] https://github.com/ChristopherRC/servercert/tree/SC-067-Version-2

On Wed, Apr 3, 2024 at 4:01 AM Martijn Katerbarg <
martijn.katerbarg at sectigo.com> wrote:

> Hi Chris,
>
> Thank you for getting this ballot out. After having gone through the
> language more detailed, I have a few comments. I’ve added these to the
> Github PR, but will list them here additionally for visibility.
>
>
>
>    - Minor nit:
>    https://github.com/cabforum/servercert/pull/487#discussion_r1549074735
>       - I’m not native english, so I may be wrong on this one, but it
>       seems to me like this “from” should be a “by”.
>    - I can imagine CAs may want to differentiate their checks for CAA
>    lookups vs those for Domain Control, as such I would recommend this
>    “and/or”:
>    https://github.com/cabforum/servercert/pull/487#discussion_r1549076900
>    - Section 3.2.2.9 paragraph 2 currently reads, or can be read in such
>    a way that a single response from a Network Perspective needs to contain
>    both the necessary information to asses (a) *and* (b) in that
>    paragraph. I can imagine CAs wanting to use 2 different calls for that,
>    thus resulting in 2 different responses, both confirming different checks.
>    I’ve added a suggestion here, but I’m not fully happy with that language
>    either. If someone else has a better suggestion, please comment.
>    I thought about making the “and” at the end of (a) an “and/or”, but
>    that may then result in CAs believing they only need to confirm either
>    Domain Control or CAA alltogether, which is not desirable.
>    - Another minor one, but relevant:
>    https://github.com/cabforum/servercert/pull/487/files#r1549101349 It
>    seems like re-use should also allow for the domain itself to be able to
>    re-use data.
>
>
> Regards,
>
> Martijn
>
>
>
>
>
> *From: *Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of
> Chris Clements via Servercert-wg <servercert-wg at cabforum.org>
> *Date: *Wednesday, 20 March 2024 at 21:20
> *To: *Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>, CA/B Forum
> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *Subject: *Re: [Servercert-wg] Discussion Period Begins - Ballot SC-067
> V1: "Require domain validation and CAA checks to be performed from multiple
> Network Perspectives”
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Hi Dimitris,
>
>
>
> Your suggestion to extend the discussion period to at least 30 days sounds
> very reasonable and fair to us. I am providing an updated preamble below
> that extends the current discussion and makes no other changes.
>
>
>
>
>
> *Purpose of Ballot SC-067*:
>
>
>
> 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 “Multi-Perspective Issuance Corroboration”
> (“MPIC”).
>
>
>
> *Background*:
>
>
>
> - MPIC refers to performing domain validation and CAA checks from multiple
> Network Perspectives before certificate issuance, as described within the
> Ballot for the applicable validation methods in TLS BR Sections 3.2.2.4 and
> 3.2.2.5.
> - Not all methods described in TLS BR Sections 3.2.2.4 and 3.2.2.5 will
> require using MPIC.
> - This work was most recently motivated by research presented at
> Face-to-Face 58 [1] by Princeton University, but has been discussed for
> years prior as well.
> - The goal of this proposal is to make it more difficult for adversaries
> to successfully launch equally-specific prefix attacks against the domain
> validation processes described in the TLS BRs.
> - Additional background information can be found in an update shared at
> Face-to-Face 60 [2].
>
>
>
> *Benefits of Adoption*:
>
>
>
> - Recent publicly-documented attacks have used BGP hijacks to fool domain
> control validation and obtain malicious certificates, which led to the
> impersonation of HTTPS websites [3][4].
> - Routing security defenses (e.g., RPKI) can mitigate the risk of global
> BGP attacks, but localized, equally-specific BGP attacks still pose a
> significant threat to the Web PKI [5][6].
> - Corroborating domain control validation checks from multiple network
> perspectives (i.e., MPIC) spread across the Internet substantially reduces
> the threat posed by equally-specific BGP attacks, ensuring the integrity of
> domain validation and issuance decisions [5][7][8].
> - Existing deployments of MPIC at the scale of millions of certificates a
> day demonstrate the feasibility of this technique at Internet scale [7][9].
>
>
>
> *Intellectual Property (IP) Disclosure*:
>
>
>
> - While not a Server Certificate Working Group Member, researchers from
> Princeton University presented at Face-to-Face 58, provided academic
> expertise, and highlighted publicly-available peer-reviewed research to
> support Members in drafting this ballot.
> - The Princeton University researchers indicate that they have not filed
> for any patents relating to their MPIC work and do not plan to do so in the
> future.
> - Princeton University has indicated that it is unable to agree to the
> CA/Browser Forum IPR agreement because it could encumber inventions
> invented by researchers not involved in the development of MPIC or with the
> CA/B Forum.
> - Princeton University has instead provided the attached IPR statement.
> Pursuant to the IPR statement, Princeton University has granted a worldwide
> royalty free license to the intellectual property in MPIC developed by the
> researchers and has made representations regarding its lack of knowledge of
> any other Princeton intellectual property needed to implement MPIC.
> - For clarity, Princeton University’s IPR statement is NOT intended to
> replace the Forum’s IPR agreement or allow Princeton to participate in the
> Forum in any capacity.
> - Members seeking legal advice regarding this ballot should consult their
> own counsel.
>
>
>
> *Proposal Revision History*:
>
>
>
> - Pre-Ballot Release #1 (work team artifacts and broader Validation
> Subcommittee collaboration) [10]
> - Pre-Ballot Release #2 [11]
>
>
>
> *Previous versions of this Ballot*:
>
>
>
> - N/A, this is the first discussion period.
>
>
>
> *References*:
>
> [1]
> https://cabforum.org/wp-content/uploads/13-CAB-Forum-face-to-face-multiple-vantage-points.pdf
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fwp-content%2Fuploads%2F13-CAB-Forum-face-to-face-multiple-vantage-points.pdf&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230417253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=GoX5Lbu9SFpKRc1rISxdAuK7VJvYyDEagL1FwvMqnCA%3D&reserved=0>
>
> [2]
> https://drive.google.com/file/d/1LTwtAwHXcSaPVSsqKQztNJrV2ozHJ7ZL/view?usp=drive_link
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrive.google.com%2Ffile%2Fd%2F1LTwtAwHXcSaPVSsqKQztNJrV2ozHJ7ZL%2Fview%3Fusp%3Ddrive_link&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230427471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=67N%2Bzjb413rZd5EoEBJxanGoGrzAuXugTPMXbvcv%2BoI%3D&reserved=0>
>
>
> [3]
> https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2Fs2wblog%2Fpost-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230434584%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=56zKEthdTZLDQHEBjMJlm7M9EdnsQCXbEuokDw63lf8%3D&reserved=0>
>
>
> [4] https://www.coinbase.com/blog/celer-bridge-incident-analysis
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.coinbase.com%2Fblog%2Fceler-bridge-incident-analysis&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230440923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XE6439%2F24MaEeGbHQPU%2BgHd99%2Fa%2Bp86qUIY2u26ESR8%3D&reserved=0>
>
>
> [5]
> https://www.usenix.org/conference/usenixsecurity23/presentation/cimaszewski
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.usenix.org%2Fconference%2Fusenixsecurity23%2Fpresentation%2Fcimaszewski&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230447223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=JUM%2FaN6fWHHowr2W9KbqIhfg0P1Tm30Kx8klEIJ%2FV4k%3D&reserved=0>
>
>
> [6]
> https://www.blackhat.com/docs/us-15/materials/us-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking-wp.pdf
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.blackhat.com%2Fdocs%2Fus-15%2Fmaterials%2Fus-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking-wp.pdf&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230452773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2BKTqv6mLNjqvr9TJ3xSM8XD%2FICfoGiKqoZdaKT%2FVRtI%3D&reserved=0>
>
>
> [7]
> https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.usenix.org%2Fconference%2Fusenixsecurity21%2Fpresentation%2Fbirge-lee&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230458401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=uG%2F%2BZU4A2g5xK1tom4JLBKhFLzDgmnReTdig01rqW20%3D&reserved=0>
>
>
> [8]
> https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.usenix.org%2Fconference%2Fusenixsecurity18%2Fpresentation%2Fbirge-lee&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230463868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Sn%2BixjQn94EbiLbBVP7IiNIJJHOEzA%2BZUn2wPD57e9A%3D&reserved=0>
>
>
> [9]
> https://security.googleblog.com/2023/05/google-trust-services-acme-api_0503894189.html
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecurity.googleblog.com%2F2023%2F05%2Fgoogle-trust-services-acme-api_0503894189.html&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230469305%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=sp00Gv5b6A%2B8%2Fjp%2BqJ1KHyXx4QifJVKXmmkBc42Y2%2Bs%3D&reserved=0>
>
>
> [10] https://github.com/ryancdickson/staging/pull/6
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fryancdickson%2Fstaging%2Fpull%2F6&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230475067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zQgtc7MvlOlKiH6f2GzteKaZG5ZyBrYPCrhPsFHbqHI%3D&reserved=0>
>
>
> [11] https://github.com/ryancdickson/staging/pull/8
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fryancdickson%2Fstaging%2Fpull%2F8&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230480284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=qnupbwuMcOtQcw%2FhMx0PYmmejyjQonGr90Xvjaa1oE4%3D&reserved=0>
>
>
>
>
> The following motion has been proposed by Chris Clements and Ryan Dickson
> of Google (Chrome Root Program) and endorsed by Aaron Gable (ISRG / Let’s
> Encrypt) and Wayne Thayer (Fastly).
>
>
>
> *— 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.2.
>
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
>
> https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35..6d10abda8980c6eb941987d3fc26e753e62858c0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fcompare%2F41f01640748fa612386f8b1a3031cd1bff3d4f35..6d10abda8980c6eb941987d3fc26e753e62858c0&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230485479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ANXwEeN5k5oU5S5eBIcwALiRXdJMdX6p17aZklae48c%3D&reserved=0>
>
>
>
>
> *— Motion Ends —*
>
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
>
> *Discussion (at least 30 days)*
>
> - Start: 2024-03-18 15:30:00 UTC
>
> - End no earlier than: 2024-04-17 15:30:00 UTC
>
>
>
> *Vote for approval (7 days)*
>
> - Start: TBD
>
> - End: TBD
>
>
>
>
>
> On Tue, Mar 19, 2024 at 11:00 AM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg <servercert-wg at cabforum.org> wrote:
>
> Hi Chris,
>
> On 18/3/2024 5:32 μ.μ., Chris Clements via Servercert-wg wrote:
>
> *Intellectual Property (IP) Disclosure*:
>
>
>
> - While not a Server Certificate Working Group Member, researchers from
> Princeton University presented at Face-to-Face 58, provided academic
> expertise, and highlighted publicly-available peer-reviewed research to
> support Members in drafting this ballot.
>
> - The Princeton University researchers indicate that they have not filed
> for any patents relating to their MPIC work and do not plan to do so in the
> future.
>
> - Princeton University has indicated that it is unable to agree to the
> CA/Browser Forum IPR agreement because it could encumber inventions
> invented by researchers not involved in the development of MPIC or with the
> CA/B Forum.
>
> - Princeton University has instead provided the attached IPR statement.
> Pursuant to the IPR statement, Princeton University has granted a worldwide
> royalty free license to the intellectual property in MPIC developed by the
> researchers and has made representations regarding its lack of knowledge of
> any other Princeton intellectual property needed to implement MPIC.
>
> - For clarity, Princeton University’s IPR statement is NOT intended to
> replace the Forum’s IPR agreement or allow Princeton to participate in the
> Forum in any capacity.
>
> - Members seeking legal advice regarding this ballot should consult their
> own counsel.
>
>
> This is the first time the Forum and a Chartered Working Group goes
> through a ballot with essential contributions coming from a non-Member. At
> the last F2F meeting, we discussed about possibly allowing fewer days for
> the IPR review in certain cases, and many Members felt that this would
> create problems because legal departments need time to review these
> documents. My interpretation is that Organizations that participate in the
> Forum are very sensitive when it comes to IP issues.
>
> I would therefore suggest that the discussion period takes *at least 30
> days* (similar to the time it takes for the IPR review period to end for
> Maintenance Guidelines), so that Members have time to provide information
> to their legal departments regarding the commitment by Princeton from
> January 11, 2024, and see if there are any objections or concerns raised.
> All members will ultimately have to accept the proposed IPR solution
> offered by Princeton before the ballot enters its voting period. I hope
> this sounds reasonable and fair.
>
> At the same time, we can continue discussing the proposed language that
> updates the BRs.
>
> Other Members that are sensitive on this matter can also speak up about
> this suggested process so we can proceed with caution and minimize the IP
> risks.
>
>
> Thank you,
> Dimitris.
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230492660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jZ8MBQ4l0cHamgNbuRy3NjWc34gpTaKmVdABBIzfhX4%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240405/12fbb71e/attachment-0001.html>