[cabf_validation] Draft Minutes from 2020-07-02

[Clint Wilson]

# Validation Subcommittee Meeting - July 2, 2020

## Attendees: 
Tim Hollebeek, Wayne Thayer, Aneta Wojtczak, Corey Bonnell, Daniela Hood, Dean Coclin, Shelley Brewer, Clint Wilson, Encrico Entschew, Janet Hines, Li-Chun Chen, Rich Smith, Robin Alden, Trev Ponds-White, Ben Wilson, Stephen Davidson

## Agenda:
Continuing work on certificate profiles
Remove validation method #10 and replace with RFC 8737 TLS ALPN
Validation data reuse periods
Prioritization of future work

## Certificate profiles
Tim - There hasn’t been a lot of progress on the profiles this week
Tim - With the smaller than usual attendance today, perhaps it’s not likely that we’ll make progress on-call when there hasn’t been much off the call.

## Method #10 & RFC 8737
Wayne - With regards to replacing validation method #10, we say that once an FQDN is validated, then the validation can be reused for any FQDN that includes all the same labels. We do allow wildcard validaiton for method 6. Should the TLS ALPN method be allowed to be used for wildcard validation and for other subdomains of the validated FQDN.
Tim - I think we discussed this in Bilbao. If you prove control over a domain, then you prove control over subdomains since DNS is heirarchical. I think yes this method should work for wildcard/subdomain validation.
Wayne - I think the only exception is the IP Address method.
Tim - And that makes sense since we’re not validating a domain name.
Wayne - That’s why I’m bringing it up, since this method uses a TLS connection and an application layer connection. I’m wondering if we want to be more restrictive going forward. So if no one has thoughts, I think I’ll put forward a ballot with wildcard/subdomain valdiation forbidden and let discussion draw out if there’s a good reason for it.
Tim - That’s fine. I lean the other way, but you make a good point for sure. I wonder if we should align on consistency in forbidding wildcard/subdomains more completely.
Wayne - That’s a larger problem to solve overall, I think. With the vulnerable LE has implemented this method, since it’s permitted under the current method #10, and they don’t allow it to be used for wildcards, I assume for the same reasons that it’s not validating DNS.
Tim - Yeah I think you’re right, we can take it up in the discussion period.
Clint - I’d support sticking with your approach Wayne of starting with a reduced scope and revisiting that topic during discussion period.
Wayne - I’ll get a ballot out soon.
Robin - Could I ask where is the prohibition for method #10?
Wayne - I don’t believe it’s in the BRs. I believe Mozilla and Google have made statements that in its previous state it shouldn’t be used due to vulns found in late 2018. That prohibition was specific to the prior method without ALPN, and the new RFC method is technically permitted under method 10 which is how Let’s Encrypt is able to use it.
Tim - Any other topics?

## Validation data reuse
Trev - Validation reuse? It was on the Mozilla questionnaire back in May, but I haven’t seen any discussion. Any proposals? I’ve seen 30, 90, 365 days floated. Does Mozilla have a position on this, or in the Forum?
Ben - We may propose something eventually, but not on a specific timeframe. We’re taking it step-by-step, but don’t have anything planned at this point.
Trev - What are people’s thoughts generally? Does anyone have an opinion to share on what validation reuse should be? I think it makes sense for some of the methods to be much shorter, especially the newer ones.
Wayne - It depends on if it’s domain or organizational validation. The BRs don’t differentiate, but we probably need to introduce that in order to solve this. I think there’s consensus that domain validation reuse can be much shorter. Domains should be short and organizations could be longer.
Tim/Trev - That makes sense.
Wayne - I also think we should consider looking at WHOIS and the expiration there. If a domain is registered for 5 years, do you need to validate it every 30 days? I think arguably the risk is lower.
Tim - Direct contact with the registrar or something more secure; I think it makes a lot of sense to discuss further.
Clint - I agree with that line of discussion and looking at ways to improve experience for subscribers while maintaining/improving security for certificate consumers.
Trev - Would we want to incorporate popularity of the website? If a domain’s been owned a long time and it’s popular? Maybe not.
Dean - That’d be tough to define, we’d need to put some very strict boundaries and benchmarks on that. I think there’s a lot of different benchmarks you could look at, and maybe come up with some ideas. I think Wayne sent me a list that Cisco published?
Wayne - Yeah there are a few lists, Alexa and Cisco, Umbrella. I’m skeptical of popularity being the right approach, but we can certainly talk about it. I think it just takes someone to own it. I think it’s a very valid point to bring up. I do think the CA/BF needs to come out with a clear policy because if the Forum doesn’t then we leave it to root programs to decide what to do.
Tim - w.r.t popularity arguing both sides of the issue. Microsoft has probably owned microsoft.com <http://microsoft.com/> for a long time and let’s posit that it meets the definition of popular. Since Microsoft has owned microsoft.com <http://microsoft.com/> for so long and probably won’t ever stop owning microsoft.com; does that make it lower risk? Or since it’s so popular should it require more frequent checking?
Clint - Thinking out loud, maybe something where we check WHOIS/ownership data more frequently, but don’t require the full validation as frequently?
Trev - I think for DV certificates, if we’re talking about incorporating other information about length of time it’s been owned, it seems like we’re skirting close to “hey can we do a quasi-EV/OV validation for DV”. Based on for OV, maybe you’ve looked at other information that gives a reasonable sense that the business probably wants its domain for longer.
Tim - ID cards and other things that require validation often have different requirements for initial validation vs continuing validation. We’ve rejected that traditionally; issuance is the same as reissuance. But the idea that the company’s owned the domain for a long time skirts close to the issue of if you’ve revalidated many times, is a more light-weight validation acceptable?
Robin - If 1st of Jan on one year, we issue a cert, and then 1st of Jan next year they ask for another, and I check the site and see the same cert we issued last year, does that tell me anything about whether the site has changed hands or not
Tim - You’d still need to do the WHOIS checks and such to make this work. You could imagine if the request came from the same applicant, that could be one of the factors you could use.
Clint - Operational overhead should likely be part of the equation. Domain validation can be, should be pretty low overhead to repeating a domain validation, whereas organization validation has a bit more. That context likely plays a role in where we land.
Tim - I think that’s true. For the vast majority domain validation is very easy, but there’s a long tail for which it’s very hard.
Wayne - There’s a threat model where the CA account is hijacked and maybe the fact that domain validation is hard is actually a feature.
Tim - It certainly would allow you to do more rigorous domain validation, without having undue negative effects.
Robin - There’s only so short you can go, probably, before...
Trev - If that’s the threat to mitigate against, then you want to drive reuse down for all of them including OV, EV. If you can reuse OV for a year or two and someone hacks your account, then you could issue those for even longer than DV if it was harder.
Robin - Why is OV better protected?
Trev - No, if the CA is hacked and it can issue certs for what information it has or can easily obtain, then what’s at risk is any validation information that’s currently valid or processes that are easy. So if we’re saying for OV you can reuse those artifacts for longer, then those are a higher risk if that’s the threat that you’re looking at.
Wayne - That’s true if we were to allow domain validation to be reused for a longer period of time within EV/OV certs. That’s kind of my point, as we develop these proposals we need to look at these from an adversarial perspective. Maybe it’s logical to allow domain validation to be reused for longer with EV/OV, but then you’ve introduced a new threat that the data can be misused for a longer period of time so maybe it’s a bad idea.
Trev - Threat scale - definitely a threat if a CA account is hacked, but maybe a lower threat than some other threats, though the damage is catastrophic. It’s more severe if a CA is hacked, but less probable.
Robin - For a certain size of organization, there’s a common usage mode; they centralize certificate management. It’s someone’s job to order certs and deliver and install, etc. That becomes a painful process if they’re using OV/EV certs and they’re required to repeatedly provide the same information for OV/EV certs to the CA. Yes people can lose/share their credentials, and that’s something we need to protect against. We should prevent perfect being the enemy of the good.
Trev - I think that’s where some of the ideas of using the applicant’s data/context can help. You can make it easier for enterprises, but that could have the knock-on effect of different government entities getting their information confused/mixed up. If we do make it too hard for enterprises, we could decrease the security overall. Anything that becomes a “checkbox exercise” becomes a pointless exercise. People that only do 1-2 every few years, they look at with more scrutiny, compared to someone doing many every day.
Tev - So is the first step to figure out the distinction between DV and OV
Wayne - I think we need to define the difference between domain validation reuse periods and organization validation information reuse periods.
Tim - Should we focus on one and leave the other for later?
Wayne - I don’t know. I think it would be great if someone could put together a straw dog proposal so we can discuss.
Tim/Robin - Don’t have the time to put together a proposal at the moment, but would be happy to review and discuss.

## Prioritization of future work
Wayne - It’s potentially something I could work on after the ALPN ballot, but that’s going to be a little while. I’ll add it to the Trello board.
Tim - Maybe we should review the Trello board a couple weeks from now, on the next agenda. We can discuss next priorities for the Validation subcommittee then. If you have items, please be prepared to bring them up then.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200708/eb85446e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3621 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200708/eb85446e/attachment-0001.p7s>