[cabf_validation] 2024-07-11 Final Meeting Minutes

Thu Aug 8 16:02:03 UTC 2024

These are the Final Minutes of the Teleconference described in the subject
of this message, prepared by Doug Beattie (GlobalSign) and approved on the
August 8th meeting.

## Validation Subcommittee Minutes | Thursday, 2024-07-11

### Attendance

Aaron Poulsen (Amazon), Ben Wilson (Mozilla), Bruce Morton (Entrust), Clint
Wilson (Apple), Corey Bonnell (DigiCert), Doug Beattie (GlobalSign), Dustin
Hollenback (Microsoft), Enrico Entschew (D-TRUST), Gurleen Grewal (Google),
Joseph Ramm (OATI), Kiran Tummala (Microsoft), Mahua Chaudhuri (Microsoft),
Michael Slaughter (Amazon), Michelle Coon (OATI), Miguel Sanchez (Google),
Nate Smith (GoDaddy), Rebecca Kelly (SSL.com), Rollin Yu (TrustAsia), Scott
Rea (eMudhra), Thomas Zermeno (SSL.com), Tobias Josefowitz (Opera Software
AS), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management
Authority)

### Note Well

The statement was read concerning the meeting recording, antitrust policy,
code of conduct, and intellectual property rights agreement. 

### Approval of minutes

The minutes for the following meetings were approved:

- May 2nd Validation Working Group

- F2F May 30 F2F meeting minutes

- June 27th Validation Working Group

Side note: Slaughter is looking for endorsers for the CA assisted ballot, so
please reach out to him it you're interested.

### Discussion on email sent to the list on June 20th about Domain
Validation method 3.2.2.4.7

Doug provided an overview of the email:

- https://lists.cabforum.org/pipermail/validation/2024-June/001989.html 

The primary topic was where "in" the CNAME record would a random value be
located?  It's clear where it would be located in a DNS TXT and CAA record.

Slaughter said his interpretation is that the CNAME record would contain the
random value in the RDATA field (i.e., the domain-name).  Corey and Clint
agreed.  During the meeting examples like _12345.example.com were provided
as valid use where "12345" is the random value.

Wayne pointed out that the definition of Authorization Domain Name (ADN)
helps with the interpretation here as it defines how CNAMEs are to be used.
It says "The CA may use the FQDN returned from a DNS CNAME lookup as the
FQDN for the purposes of domain validation)".

The current 3.2.2.4.7 definition treats DNS TXT, CAA and CNAME records all
the same  but it might be better to split this out into three different more
clearly specified statements.  Ben opened an issue for this during the call
where we can discuss this topic further and decide if additional
clarification is needed:  https://github.com/cabforum/servercert/issues/533

Scott suggested providing some examples to help improve understanding of
topics like this.  Corey and others said that providing an partial
illustrative list might imply that those are the only ways and it's also
hard to create an exhaustive list.  We need to be mindful of that if we
proceed with including some examples.

Summary: Between section 3.2.2.4.7 and the definition of ADN, it's now clear
that the random value can be in a CNAME record (as being part of the
domain-name of the sub-domain record itself), or the CA can follow the CNAME
record and use that FQDN for the purposes of domain validation per the
definition of ADN.

### Discussion on improvements to CRLDP and CPS qualifier URI schemes in
section 7

Enrico discussed the improvement to the HTTP references via a short
presentation for some updates to the language for these topics.

He suggested that, for AIA (id-ad-ocsp and id-ad-caIssuers), every
accessMethod SHALL be the uniformResourceIdentifier scheme HTTP and other
schemes SHALL NOT be present

PolicyQualifier for id-qt-cps: will use http or https only.

Scott asked if the first entry in the CDP should be http and have we made
LDAP defunct?   After a short discussion, it was pointed out that LDAP has
been removed from all URIs in the BRs.  Wendy and Corey agreed that the
referenced to "the first GeneralName containing the HTTL URL..." was
probably there to assure this comes before any LDAP URIs, so this can
probably also be removed.

Wendy pointed out that we might want to make references to RFC 3986, section
3.1, in one place vs., every time we reference http to make future updates
easier and to avoid conflicting references.  Clint provided some further
clarification regarding that reference to which Enrico will also incorporate
into the follow-up discussions.

Summary: Enrico will put the proposed language in github and circulate with
the changes in a ballot type redline vs. a github issue for additional
review

###Security analysis of the use of DNS resolvers for method 7 validation

Security properties of using in-house or hosted DNS resolvers.

This was to follow up on last call where we discussed:

- Operating DNS resolvers should be done in-house

- Others say that it's difficult to operation an in-house resolver securely
and that outsourcing this you could leverage this additional knowledge.

Tobias said that any DNS resolver used for domain validation has to be a
first party resolver, or one that is specifically operated and configured
for such purposes. He's seen examples where getting forged responses into
DNS have caused security issues, or false responses to the DNS resolvers.

As long as this a specifically configured and secured resolver, it's not
absolutely necessary that it be hosted by the CA, but it needs to be
specifically configured for this purpose.

Slaughter asked what does "specific for this purpose mean"

Tobais said that for domain validation specially, DNS is so flawed that we
need an extra layer for domain validation. The way we bring this to domain
validation is to look at the flaws in DNS and mitigate them the best we can.
There are some easy steps that every CA can do.  The first one is to make
sure that the resolvers used for domain validation are only queried by the
CA for the exclusive use of domain validation and no other uses.

Slaughter: Agree, DNS is not great and this is the reality we live in.  We
need to do this to minimize the risk and maximized the correctness for
domain validation.  Taking a blanket statement that all DTPs are equivalent
is not true.  

Tobias: I'm 100% convinced that there are no available DNS providers that
would provide this level of security. Nothing else needs this level of
service.

Slaughter disagrees: CAs are responsible for performing domain validation
and it's the CAs responsibility to use secured components for this purpose
and it's not necessary for them to use in-house.  It's not easy to run and
lock down DNS.

Tobias: The key point is that we need to control who provides input to the
resolver in order to reduce the risk of exposing details to enable an
attacker, or that results in improperly cashed results.

Slaughter: yes, those are valid attacks and the CA needs to reduce the risk,
one way is to not use the resolver for any other purpose.  There are other
ways to do this so the blanket statement of not using 3rd party resolvers
may not hold.

Tobias: I don't think there is a DTP that offers what CAs need, so in that
way it's an academic discussion.  On top of that, if we do included this as
DTP we will need to figure out how to audit DTPs for this. 

Corey: What we'd like to do base decisions on security analysis and even
though there may not be any.

The auditing of the use of a 3rd party DNS was deemed compliant in the past,
but this does not cover the operation of the DNS provider itself (just that
the CA is using it).

It would be valuable if we could agree on the security outcome of this and
then drive the requirements.

Clint: CAs need to consistently represent that the validation was
authoritative and secure. He finds it difficult to understand how a 3rd
party could run DNS to the level needed, but perhaps the CA is also
intimately involved in the resolver settings and use.

Slaughter does not fundamentally believe that it is more secure to have a
120 implementations of DNS resolvers than a few well known ones operated by
DNS experts.

Clint agrees that CAs must have a DNS resolver dedicated to these DNS
queries.

Clint: can we see some concrete examples?

Slaughter: Let's not deviate too far from our DTP topic into this DNS
subject.  It's the CAs responsibility and the CA needs to understand and
address the risks, and using your own resolver and prohibition the use of a
DTP for this is more of an implementation decision (either can work).  The
BRs should not blanket prohibit 3rd party resolvers, but rather clearly
specify the risks that need to be mitigated and be audit on that.

Corey: We'll continue this discussion next week.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20240808/c445c586/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/20240808/c445c586/attachment-0001.p7s>