Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

[Slaughter, Michael]

Closing the discussion period and opening up the voting period.

 

Ballot SC-082 is proposed by Michael Slaughter (Amazon Trust Services) and endorsed by Martijn Katerbarg (Sectigo) and Wayne Thayer (Fastly).

 

— Purpose of Ballot SC-082 —

 

The purpose of this ballot is to clarify the practice of CA Assisted DNS Validation and add constraints under Method 7 (3.2.4.4.7 DNS Change). Modification of other domain validation methods and the introduction of new domain validation methods are not in scope of this ballot but may be addressed in a future ballot.

 

Background:

 

CA Assisted DNS Validation is the practice where Certification Authorities (CAs) instruct Applicants to create Canonical Name (CNAME) records specifically for the purpose of assisting the Applicant with Domain Control Verification (DCV) of their domain.

At F2F 59 (July 23’), the Validation Subcommittee of the Server Certificate WG presented the following conclusions on the practice of CA Assisted DNS Validation:

• More clarity is needed around the practice
• Applicants generally delegate the performance of many aspects of operating a website.
• If done correctly, allowing Applicants to delegate the placement of the Random Value/ Request Token boosts agility and automation.
• There are reasonable interpretations of the BRs that such delegation is already allowed today.

A tiger team was formed to threat model CA Assisted DNS Validation and propose modifications to the BRs to add clarity and constraints around the practice under section 3.2.2.4.7. The results of the threat model exercise [1] were presented and discussed at F2F 60 [2] and F2F 61 [3].

 

Overview of Changes:

• New definition: Canonical Authorization Domain Name
• Add Canonical Authorization Domain Names into section 3.2.2.4.7 (DNS Change)
• Addition of constraints around the usage of Canonical Authorization Names by CAs
  • Enforce CNAMEs are unique to an Applicant and not shared with multiple Applicants
  • Expire DNS lookup results after 8 hours
  • Restrict the type of DNS records located in zones used for this purpose.

 

References:

[1] Validation SC Threat Modeling Doc: https://docs.google.com/document/d/1G2GYb0eg0rqE23f844J8qs7RYGU1jFVDsU5Pf7UYg3g/edit

[2] F2F-60 Presentation: https://docs.google.com/presentation/d/1M80h1N7MpBuqvZS0FdtJ_zj-AsaFxu7BNBSUJ6Ia5jU/edit?usp=sharing

[3] F2F-61 Presentation: https://docs.google.com/presentation/d/1rKW7I5jOYh37jQFtd1S-fKIs0j-dCAyUUU-fq_C8UKw/edit?usp=sharing

[4] https://github.com/cabforum/servercert/pull/501

 

The following motion has been proposed by Michael Slaughter (Amazon Trust Services) and endorsed by Martijn Katerbarg (Sectigo) and Wayne Thayer (Fastly)

 

GitHub pull request for this ballot: https://github.com/cabforum/servercert/pull/501

 

— Motion Begins —

 

MODIFY the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based on Version 2.0.9 as specified in the following redline:

https://github.com/cabforum/servercert/compare/911e47e2657de64a7455ba16319b96ffdb5816cd..76f6e1b7a39f44f6e7b5a1bc0c4a0df744457d84

 

— Motion Ends —

 

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (7 days)

 

- Start: 2024-11-12 17:30:00 UTC

- End no earlier than: 2024-11-19 17:30:00 UTC

 

Vote for approval (7 days)

 

- Start: 2024-11-20 18:30:00 UTC

- End:  2024-11-27 18:30:00 UTC

 

 

 

[Clint Wilson]

Hello,

I apologize for the tardiness of this email, in relation to the discussion period for SC-082. I have a few points of feedback that I’d like to understand better from the perspective of the ballot author and endorsers.

Canonical Authorization Domain Name

This ballot introduces a new definition for a Canonical Authorization Domain Name (CADN), however it’s not clear how this is a new concept — or whether it’s intended to be. An Authorization Domain Name (ADN) includes in its scope the RDATA values of CNAME records located at the ADN and 3.2.2.4.7 includes in its scope an ADN prefixed with an underscore character.

FQDN = example.com

3.2.2.4.7 -> _domainlabel.example.com

ADN -> _domainlabel.example.com. IN CNAME otherdomain.com

otherdomain.com is then both the/an Authorization Domain Name and the Canonical Authorization Domain Name, based on the definitions. Am I correct in understanding that the purpose of defining the CADN is to specify exactly this form of ADN, in order to differentiate it from any other possible formulation of an ADN? Is this term intended to convey any other intrinsic property, separate from a “basic” ADN?

Adding to Method 7

A major concern I have with this proposal is its addition of this approach to domain validation to the existing 3.2.2.4.7 method. Separating out the operation of CADNs by CAs is necessary to ensure the use of this validation method is appropriately scoped and implemented, now and if further refinement is required in the future. As noted in 3.2.2.4, "CAs SHALL maintain a record of which domain validation method, including relevant BR version number, they used to validate every domain.” If this method is not separated out, it may not be reliably ascertained after the fact whether a domain was validated using 3.2.2.4.7 as it exists today or through reliance on the CA’s operation of a CADN. 

Given the new factors and participants added to the domain validation process in this ballot, I don’t believe it should be treated as an extension of 3.2.2.4.7 and instead should be added as a new validation method in 3.2.2.4.21 — perhaps with some additional constraints to ensure a higher degree of confidence that the use of this method does not enable abuse of the Web PKI.

It should not be overshadowed the level to which this changes the TLS security model. By delegating an Authorization Domain Name to the CA, the CA arguably (as written today) becomes an Applicant Representative which introduces an explicitly approved channel through which a CA could request and issue certificates to themselves (or another party). Note that the threat model’s assumption of account separation mechanisms being effective is irrelevant in this regard as this ballot does not limit issuance to individual accounts. It’s not clear whether this interaction was intended or considered, so perhaps I’m missing something which prevents this scenario from playing out.

As a side note, as with many ballots, it seems like a future effective date would be worthwhile to ensure that there is adequate time for systems changes, rather than incentivizing, to any extent, an unnecessarily quick implementation timeline.

Certification

My final overarching concern with this validation method is its instantiation of a relationship which further distances the certification process described by the TLS Baseline Requirements from resulting in a certificate which directly binds a public key to a domain name where that binding is explicitly and individually granted by the holder/owner of both the public key and the domain name.

This is, perhaps, somewhat of a philosophical concern, but from the perspective of a relying party, the ideal outcome of a TBR-compliant certificate is a 1:1 relationship between the validation of data (domain control <> public key) by an RA and the certification of that data by a CA. In this idealized scenario, each public key would be individually validated as an authorized public key for a given FQDN — this would provide the highest degree of assurance to relying parties. The reuse of any validation inherently distances reality from this ideal. Quoting from https://cseweb.ucsd.edu/~goguen/courses/275f00/geer.html: "a trust management paradigm says that a digital signature is only as valid as the key (in which it was signed) was at the moment of signature”.

This method introduces an abundance of convenience, and I don’t want to downplay that. However, I think along with that comes a tradeoff in which relying parties find themselves relying upon a relationship between a CA and Subscriber, represented through the one-time creation of a DNS record which does not naturally expire or require interaction to maintain. Instead of a certificate representing the authorization of a key, it represents the authorization of a business relationship. The risks associated with that shift are strongly — but not solely — tied to (shorter) certificate lifetimes and validation data reuse periods. To an extent, the adoption of this ballot would further emphasize the need for SC-081, possibly even increasing its urgency.

To be clear, I’m not requesting a change to this ballot to directly address this, rather I wanted to highlight this aspect of the ballot in case it’s something others don't agree with, see differently, or weren’t aware of as a perspective. I do think this shift is worth consideration when determining whether this method is suitable for addition to the TBRs as-is.

Thanks!

-Clint

-- 
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/591A7733-9F52-4049-9B88-9B9274F3C78E%40amazon.com.