[cabf_validation] Final minutes of the 2024-08-08 validation-sc meeting

[Corey Bonnell]

Here are the final minutes of the 2024-08-08 meeting of the validation-sc as
taken by Aaron Gable and approved on yesterday's meeting.

 

# Validation Subcommittee, Thursday 2024-08-08

 

## Administrivia
- Minutes taken by Aaron Gable
- Note Well read by Corey Bonnell
- Roll Call
- Minutes from 2024-07-11 approved

## Attendees
Aaron Gable (Let's Encrypt), Andrea Holland (VikingCloud), Aneta
Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Clint Wilson (Apple),
Corey Bonnell (DigiCert), Doug Beattie (GlobalSign), Iñigo Barreira
(Sectigo), Jaime Hablutzel (OISTE Foundation), Janet Hines (VikingCloud),
Johnny Reading (GoDaddy), Joseph Ramm (OATI), Li-Chun Chen (Chunghwa
Telecom), Mads Henriksveen (Buypass AS), Mahua Chaudhuri (Microsoft),
Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon
(OATI), Miguel Sanchez (Google), Nargis Mannan (VikingCloud), Nate Smith
(GoDaddy), Paul van Brouwershaven (Entrust), Pekka Lahtiharju (Telia
Company), Rebecca Kelly (SSL.com), Scott Rea (eMudhra), Sissel Hoel (Buypass
AS), Sven Rajala (Keyfactor), Tobias Josefowitz (Opera Software AS), Trevoli
Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI
Management Authority)

## Status of Ballot SC-070 (Aaron Gable)
- Mads Henriksveen asked for clarification on the status of the ballot
- Discussed at ServerCert last week
- GoDaddy has withdrawn their exclusion notice in private communication to
the IPR Committee
- Ben Wilson has asked them to state that withdrawal on a public list
- Some concerns were raised that the ballot should be reconsidered, since
we've had more discussions about DTPs since then
- Aaron currently intends to reintroduce Ballot SC-070 as-is, because he
believes it is still valuable and walks the right line
- But further discussion in both ServerCert WG and Validation SC is
warranted

## Update on Subject Attributes (Martijn Katerbarg)
- Continuation of discussion from Face-to-Face
- Currently OV organizationName can contain only the Subject's name or their
DBA, not both
- But EV and S/MIME can contain both, in a specific order
- Martijn [has a
proposal](https://github.com/cabforum/servercert/compare/main...XolphinMarti
jn:servercert:orgNameAlignment) to better align OV with the other profiles
- It still wouldn't be quite identical to the EVGs, which require both
Assumed Name and DBA to be given
- Seeking endorsers
- Corey Bonnell pointed out that it might be good to introduce similar
language for personal identity, since some jurisdictions allow DBA names for
individuals

## Continuation of DNS discussion (Corey Bonnell)
- Note that discussion has been ongoing [on the mailing
list](https://lists.cabforum.org/pipermail/validation/2024-July/001994.html)
- Question: What are the specific threats being mitigated by this work?
- Question: If SC-070 passes again, is there additional work to be done?
- Tobias: DTPs are already banned for domain validation, so use of external
resolvers is already forbidden. So why are we still having this
conversation?
- Aaron: SC-070 was designed as a clarification, not new requirements
- Miguel Sanchez: Merely running one's own DNS resolver doesn't resolve all
potential risks; we need a more thorough threat analysis
- Trevoli Ponds-White: From this historical context, it's clear that DNS
resolvers were not part of the original intended definition of "Delegated
Third Party". SC-070 would be adding requirements, not just clarifying.
- Trevoli: In the context of MPIC, it's surprising that we're not requiring
the use of mulitple DNS resolvers. It feels like requiring running your own
is a step in the wrong direction.
- Clint Wilson: Delegation of the full validation process was what prompted
the discussion, but the result was that all parts (including DNS
resolution!) must be performed by the CA.
- Aaron: The reason for CAs to run their own DNS is so that it's under their
control, not to mitigate specific attacks
- Michael Slaughter: We do still need to do threat modeling, though
- Tobias: MPIC mitigates BGP-level attacks, but not against all DNS-level
attacks
- Miguel: Running your own DNS resolver can be non-trivial, and having CAs
all run their own may introduce additional risks
- Tobias: Running a CA is already non-trivial, it's okay to require this
- Trevoli: So we should expect all CAs to have DNS experts on staff?
- Tobias: At least consulting with DNS experts is a reasonable expectation,
yes. It's the single most important part of domain validation.
- Miguel: Not convinced that the value proposition of every CA running their
own DNS resolvers (perhaps not in the most secure way) vs using several
well-run public resolvers
- Tobias: But there are no public resolvers which satisfy all the current
requirements
- Aaron: For example, Google DNS is willing to ignore DNSSEC failures in
certain circumstances
- Corey: We need to have a shared understanding of what we're trying to
mitigate. Next call we will use the [STRIDE
model](https://en.wikipedia.org/wiki/STRIDE_model) to do threat modeling.
- Aaron: The STRIDE model does not include one specific threat we need to
include: "The CA doesn't understand their DNS resolver's behavior and it
doesn't do what they think it does"
- Trevoli: A couple years ago some Amazon engineers gave a presentation to
NETSEC on how to do good threat modeling on ambiguous problem spaces
- Corey: Motivation -- execution of the DCV process is the most critical
concern. The problem is that the requirements are not very clear. We need to
develop a shared
- Aaron: STRIDE modeling will do a good job of developing requirements to
place on DNS resolvers to mitigate specific threats. But having CAs run
their own DNS resolvers within their own audit scope is a necessary step 0
regardless of the outcome of the STRIDE modeling.
- Clint: Seconded, and Ballot SC-070 should move forward in parallel to the
modeling.
- Corey: If you have alternatives to STRIDE, please propose them before the
next meeting.

Meeting adjourned

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20240823/9717e5ed/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5231 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20240823/9717e5ed/attachment-0001.p7s>