[cabf_validation] 2024-05-02 Final Meeting Minutes

[Corey Bonnell]

## Validation Subcommittee Minutes | Thursday, 2024-05-02

 

### Attendance

 

Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Abhishek Bhat (eMudhra), Adriano Santoni (Actalis S.p.A.), Andrea Holland (VikingCloud), Ben Wilson (Mozilla), Bruce Morton (Entrust), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Doug Beattie (GlobalSign), Enrico Entschew (D-TRUST), Gregory Tomko (GlobalSign), Gurleen Grewal (Google), Iñigo Barreira (Sectigo), Janet Hines (VikingCloud), Jay WIlson (Sectigo), Johnny Reading (GoDaddy), Keshava Nagaraju (eMudhra), Luis Cervantes (GoDaddy), 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), Naveen Kumar (eMudhra), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Rebecca Kelly ( <http://ssl.com/> SSL.com), Rollin Yu (TrustAsia), Roman Fischer (SwissSign), Scott Rea (eMudhra), Stephen Davidson (DigiCert), Thomas Zermeno ( <http://ssl.com/> SSL.com), Tim Hollebeek (DigiCert), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), 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 March 21st 2024 meeting of the Validation Subcommittee were approved.

The minutes for the April 4th 2024 meeting of the Validation Subcommittee were approved.

 

### Discussion - Identifying DTPs in the context of domain validation

 

#### Method 2

 

> Reviewed method 2’s use of email, fax, SMS, and postal mail

 

Aaron G: We’ve discussed previously the use of MailChimp-style email providers, this one adds the possibility of something like Twilio being used.

Tim H: It’s possible 3rd party Operating Systems are in use as well.

Aaron G: Maybe we care about the targeting of the random value, but not the transport mechanism. That may inform what’s considered a delegated third party (DTP). What you use to look up the Domain Contact has to be very carefully controlled and not use DTPs. The transmission from the Domain Contact doesn’t matter as long as the correct Domain Contact received the random value.

Tim H: We need a threat model and security analysis of which components materially affect the integrity of the validation process. Some hypotheticals are many levels removed from the actual security, critical properties of the system.

Aaron G: Right, if the CA has correctly determined the Domain Contact without using any 3rd party then an Email or SMS hijack is equivalent to a BGP hijack in Methods 18 and 19.

Tim H: The improvements we’re trying to make aren’t even related to what is or isn’t a DTP; that’s a bit of a red herring. It’s really about a security analysis of what components are security critical and weren’t included in previous analyses of the security properties of these methods. Ве should focus on what are the actual critical security properties of each of the parts of these validation methods and are there any things that are outside the control of the CA that could potentially compromise the integrity of the validation process.

Aaron G: Applying that to Method 2, we don’t care about the transmission of the random value from the Domain Contact to the CA, but getting the random value to the correct Domain Contact so you can prove they’ve received it is very hard. 

 

Tim H: This method also mixes together 3 completely unrelated things that have different security properties, which makes this method difficult to analyze. Is postal mail still used?

Corey B: There are probably a couple smaller European teams that do

Tim H: This method is interesting in that it’s verifying control over an email, fax, or SMS number that was found as contact information from a trustworthy source.

Roman F: An interesting property of using postal mail is you can do Registered Mail and have legal proof that it has been received. If you use a fax or SMS, you’re probably going to use a 3rd party provider. Maybe this should be taken apart.

Aaron G: It’s interesting that any node along the transmission path to the Domain Contact can pretend to be the Domain Contact and reflect it back.

Tim H: It’s usually better to get the value back via some sort of authenticated portal, and I think that’s how it’s done for most these days.

Aaron G: If that were required, it would bring this closer to other methods.

Tobias J: Why is that? I can sign up for an account with the CA and enter the random value in, but if I’m getting that random value from a stolen email then the authenticated portal doesn’t change anything.

Aaron G: Agreed, but if we’re accepting that control of an email, fax, SMS, or mail address is equivalent to control of a domain, then it brings it to the equivalent level of Methods 18 and 19 where an attacker could apply for the certificate and do a BGP hijack as opposed to a postal mail hijack.

Tobias J: If you can just reply to the email or take something from the email and enter it into a website, I don’t see where the difference is. It seems to make a difference for some and I’m not understanding why.

Aaron G: That’s a fair point. It makes it more symmetric with other methods, but I think you’re right that it doesn’t meaningfully improve the security.

 

Trev P: Are we listing DTPs that can be used with this method? I assume it’s okay to use commercial and government postal services?

Tobias J: Is that a DTP? The government approved postal or phone service is the authoritative way of delivering to a postal address or phone. I’m synthesizing that understanding from this method’s use of postal mail. A postal mail address works in that sense that it defines the recipient that can be reached via the postal mail service — it’s an intrinsic part of this transaction.

Tim H: So you’d you also agree that commercial email providers are the standard way of sending emails and therefore using a 3rd party commercial email provider is completely appropriate for sending emails.

Tobias J: No, because the email address as the recipient is defined in the DNS. You hand over your message to that record, not to a commercial service that then does the lookup itself.

Tim H: There’s no requirement that you hand your mail over to the post office, you could have some 16 year old intern running the mail over to the post office. Email addresses are just an identifier to identify someone on the internet, the same way an address or phone number is.

Tobias J: If you have 16 year old interns handling the mail, you’re responsible for that. You’ve screened them, you’re aware of the contexts surrounding what they’re doing, how it’s structured, etc. 

Tim H: As a CA, I’m responsible for email communication as well. I’m not going to delegate that to some untrusted person. In the same way we take very seriously who handles outbound postal mail. The idea that there’s a distinction between using a standard commercial service for email is not okay but somehow for postal mail, because the post office is a government entity, it’s totally okay.

Tobias J: It’s not because the post office is a government entity, it’s because the service is intrinsic to how postal mail is and can be delivered to you.

Trev P: Going back to when you have someone taking your mail to the mailbox, and you have some kind of oversight. To me that’s the same thing you do with a company that you use for a service. The best you can do is get the assurances that you can, and with a company you get more assurances by reviewing 3rd party audits. It just seems a little mystical to make the distinction between FedEx, UPS, the Post Office; and Twilio.

 

Clint W: I’m hearing that this method may include use of services that are sort of intrinsically DTPs, for some aspects of the method, and it’s maybe not a suitable validation method.

Tim H: You can say the same thing about DNS services and therefore they’re all not suitable validation methods.

Clint W: I’m not sure; I don’t think I would agree with that because a CA *can* access authoritative DNS records directly, they *can* send email directly to an MX record of a mailbox; they can’t send postal mail directly to a postal mail address - unless they really want to.

Trev P: The point that you’re raising is why I think we’ve run ahead of ourselves and redefined the intent of what a DTP was supposed to mean. If you look at the historical discussion, the intent was when you delegated away all of the decision-making, not random pieces of technology that your CA has probably assessed along the way that you use to help. So the entire discussion we’ve had about this method and so much of it intrinsically relies on 3rd party services is a good example of how I don’t think the intent of forbidding DTPs was to be “you can’t use any piece of technology”.

Tim H: That’s why I brought up the Operating System examples. Historically, this was when RAs were doing all of the validation (but not actually doing any validation) and then those validation results were relied upon by major CAs at the time. That behavior is what this was intended to prevent. The rat hole that it’s gone down where you’re worried about whether the electricity providers or Operating Systems are DTPs needs a nice clear definition of what exactly a DTP is and what the criteria are, including "is there actually a good security model for the validation method?” and “is this DTP actually critically involved in the security of the method?”

 

Clint W: Are we back to the framework that Aaron G. proposed near the beginning of the call, saying we’re mostly worried about the generation of random values and the delivery of the random value to the correct contact, and after that it doesn’t matter as much? The receipt of that random value, wherever it comes from, is delivered to the Domain Contact. If the Domain Contact sends it to somebody else or shares it or whatever, that’s their prerogative. If the CA receives it in association with the Request it was generated for, it’s valid. Is that model the right thing to be talking about instead?

Tim H: Absolutely. Another thing is that there are really 2 types of random values. There are bearer tokens and secrets. In method 2 it’s a secret random value, so all we’re worried about is whether it can be transmitted securely to the intended recipient, which is the person identified by the identifier (email address, phone number, or physical address) that was specified. That’s the scope of the security requirements method 2.

Martijn K: I would add that method 7 is the opposite way. We wouldn’t care who we send it to so long as the person that wants the certificate can create the DNS record.

 

Aaron G: I think I end up with there being a lot of things that could be considered a DTP involved in the transmission of the random value, e.g. Twilio, MailChimp, USPS, etc. and I think we’re choosing to mostly not care about those. The important thing is to care about how the CA looks up the Domain Contact.

Tim H: CAs are on the hook for this, so if you choose a bad provider you’re not immune to repercussions for your customers. If the provider doesn’t keep the emails secret, for example, you might end up needing to revoke all your certs.

Corey B: The essential element is the CA take responsibility for the validation process. If there is some 3rd party component that’s compromised in any way the CA has to rectify that. The other methods we’ve discussed (18-20 and 7) all use a “freshness” random value and method 2 uses a “secret” random value, so the transport of this random value is much more critical than the other ones. Should we eventually enumerate the 3rd party components that can be used for this and then do a security analysis on these, and then do a ballot?

 

Tobias J: What are the reasons we can’t discontinue this? Is it in use?

Tim H: Absolutely, it’s pretty common.

Clint W: Are fax, SMS, and postal mail in use?

Tobias J: I could disagree more with what’s been said, but I don’t want to go through that because I’m very concerned with many aspects of this method, especially if we say it’s fine to use DTPs all the way or anything like that? I don’t want to have that discussion unless it’s necessary, so I would like to know what aspects of this method are actually relevant?

Clint W: My thought was, if nobody’s using certain aspects of method 2, then we can avoid doing a security analysis and spending time them. If there’s some consensus that we can eliminate aspects of method 2, that would help us avoid spending time on parts of this.

Trev P: I agree we can discuss this method in the future, but that’s not really Corey’s question.

Corey: I think it’s best to separate the discussions of this method in relation to DTPs vs the merits of retaining different mechanisms in this method.

Martijn K: The more I think about it, the more I realize how very insecure the postal method is. I think we should scrap it as soon as we can, but maybe people have other opinions.

Mads H: I agree that the way to find the proper Domain Contact is an important part of this validation method. We also have several methods that use email as the transport mechanism, so that is worth looking into. I also agree that, as presented now, security is not very good independent of whether a CA using using a DTP or not. I think we heard earlier the discussion about if the Domain Contact presents the random value or request token in a portal, it should be an authenticated portal where it’s possible to see that it’s an actual representative of the Applicant; that could be one direction to move this.

 

Corey B: In the spirit of moving things forward, do we want to table this discussion and in the near future we’ll go through each communication mechanism and identify potential 3rd party components that can be used, perform a security analysis on those, and look at language improvements for this method Does that sounds like a good path forward?

Mahua C: Is there a way to separate fax, SMS, postal mail from email with this method and discussion?

Corey B: I think that would be valuable to pare down the available communication mechanisms, but I’m worried that it would push back the overall discussion we’re trying to accomplish.

Clint W: I agree, but I think from this discussion I see that forking this might make sense. Maybe tabling the analysis of this method for the time being and continuing with other methods. There are a couple things that have come out of this discussion that seem worth continuing to follow up on. 1) The random value. I think we have a GitHub issue for this, but splitting it into the “secret” vs “not-secret” random values to make it clearer and when we get to the security analysis, we’ll need that concept defined anyway. 2) Looking at this method and whether we can deprecate it or replace it with a method that’s only email or replace it with separate methods for email, SMS, fax, and postal mail — something that would allow for future changes that remove some of the components of this method that are unused and aren’t necessary to remain in the BRs. That’s how I’m seeing it; I know that doesn’t directly address the next steps for the DTP assessment, but I’m not sure that’s as valuable for this method given what’s been discussed and identified today.

Trev P: It’s still not clear to me what part of the internet for sending email constitutes a DTP. I think the ballot we did before was overzealous and not in line with the intent of DTPs.

Clint W: We’re going to continue with other methods that use email, so we’re still going to be talking about email and DTPs, which I totally agree is something we need to spend more time on, I just don’t think we need to spend more time on fax and postal mail.

Aaron G: I generally agree, but it’s not clear to me that tabling discussion will be super helpful given that all of the methods we have left are either email or phone contacts and different ways to obtain those contacts. So email and phone are going to be topics for the rest of the DTP discussions.

Clint W: Yeah I’m specifically just saying fax and postal mail should be tabled.

 

Trev P: I feel like tabling them is just avoiding the issue that we’ve retconned a definition of DTP that didn’t exist. We were just like “oh well now we think it means this”, but as we dig into it we’re realizing it can’t mean what we decided it meant a few months ago when it was put in, because when you examine these DTPs in the validation methods, they fall apart.

Tim H: I don’t know what delegated third party means in the context of the Baseline Requirements. I can say there’s a bunch of stuff discussed on MDSP or its successor list and there are incidents, but the only thing I can really conclude is nobody in the industry, even the experts, has a precise definition or understanding of what DTP is. And for something that’s part of our critical compliance requirements, that situation can't persist. We can argue about which methods are not good, but until we come up with objective criteria about what a DTP is we’re just going to go in circles for years.

Corey B: So maybe next meeting we spend the first 20 minutes circling back on the definition of DTP and then work on the F2F agenda.

 

Meeting adjourned.

 

### Action Items & Next Steps

 

1. Consider breaking apart Method 2 and/or deprecating some of its supported mechanisms for performing domain validation

2. Revisit the idea of separating the current concept of “random value” into 2 which incorporate the expectation that the random value be kept secret (or not)

3. Continue reviewing validation methods in the context of third parties and DTPs

 

 

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