Root Causes 371: MPIC Rules Go to CABF Ballot

Episode Transcript

Lightly edited for flow and brevity.

• 

  Tim Callan

  So there's an interesting development. So we've talked in the past, about what at the time we referred to as MPDV, or multi-perspective domain validation. We've covered that in a few episodes in the past and there's a significant development in this whole effort and we want to catch you up on that today.

• 

  Jason Soroko

  Root Causes podcast 327, what is Multi-Perspective Domain Validation? And yes, there are a few things to catch up on here.

• 

  Tim Callan

  Excellent. So first of all, we needed to find a new term. So at the time, we were referring to it as Multi-Perspective Domain Validation. Moving forward, we're going to refer to this instead as Multi-Perspective Issuance Corroboration. So an MPIC. And the reason for that is because it's bigger than domain control validation. There's more need here than just DCV and referring to it as MPDV, although that's where the dialogue started, would not really do justice to the entire scope of what is needed by the web PKI.

• 

  Jason Soroko

  And I actually do like the term. Issuance is in the term because it's what it really what it comes down to. And corroboration is a really good term because it says what it is. It basically means that you have to corroborate various inputs of information in actually checking and there's a lot of information now that has been written. I did a lot of reading this morning, Tim. There's a lot more here than I thought there was going to be and I like that new term. I think MPIC or whatever you want to call it.

• 

  Tim Callan

  I’m calling it MPIC.

• 

  Jason Soroko

  MPIC as an acronym. Let's just call it that. I think it's a good term.

• 

  Tim Callan

  Although I mostly calling it MPDV. So I have to teach myself to use the same word, the same way that I haven't yet taught myself to say the right word for CRYSTALS-Kyber, right? I'm still saying, Kyber. I'm not saying ML-KEM yet because it's just not how my brain is trained. But MPIC - - So what MPIC is is MPIC is a response - we’ve talked about this in the past - to having potentially a BGP attack or Border Gateway Protocol attack where you teach - - you basically fool DNS into looking at the wrong place and it leaves the door open for things like DCV attacks where the CA is doing DCV it believes correctly, but it's looking at the wrong server. And so MPIC is supposed to or is intended to address all that. What's interesting in this case, or why we're talking about it now is there is a new ballot in the CA/Browser Forum that has gone into discussion period, and it is Ballot SC-067 if you want to look it up and see it for yourself, and Ballot SC-067, which has gone into the discussion period, has specifics of how MPIC is to be implemented in the CA and that's what's noteworthy about this. I was thinking maybe today, we could just call out a few of the specifics where they really matter.

• 

  Jason Soroko

  Yeah. Let's dive in. What's the juicy part here?

• 

  Tim Callan

  So there are a couple things I think that we discussed in that last episode that we now have answers on. And I think we even identified, look, these are some of the things where we're unclear and these have to be clear before people can move ahead. So one of them - - there’s probably three main ones.

  One of them is the definition of distance, right? Because the point here is that you need your different validations, you know, you're going to look at the destination, the online destination from different places, in order to defend yourself against a BCP attack and look for some kind of consensus among them, in order to be confident that this is the real domain that really you should be looking at.

  And so the first question was, how is that going to work? And the answer here, is that it has to do with it's literally measuring physical distance of the endpoint where the query, if you will, the check of the domain leaves the encrypted tunnel that it has coming from the CA. So they're looking for 500 kilometers physical distance. So literally, if I had one of them happening in Mountain View, California, and another one happening in Virginia, that would meet the physical distance requirement. That's the kind of thing they’re looking for. And that's to prevent multiple queries from being swept up under the same BGP attack.

• 

  Jason Soroko

  And that makes sense. I'm curious to know some of the details behind this as to whether or not there's any kind of weird exceptions to that. In other words, geographic boundaries might not always, you know, fit from a BGP perspective, proximity from a networking standpoint. There may be exceptions, but 500 kilometers sounds right. I would just love to hear more about the choice of that.

• 

  Tim Callan

  Right. It is an interesting choice, right? Where because you're not really looking for physical distance, you're looking for what I’ll call logical distance, but it may be that physical distance is the best proxy we have for logical distance and that it works very well almost all of the time. Right? And what you really probably want to do is you just want to put them on different continents. You’d send one from Europe and one from North America and if you do that, then you kind of got that distance automatically. You also got that logical distance. So there has to be something in there to make it work and make sense and that's the objective, measurable requirement that was settled on. So that's the first point.

  The second point is we talked about how many, right? Like, do you have to have two inquiries? Do you have to have three? How many do you have to have? What qualifies? And the answer to that is that it grows over time. So the rules here have us a starting with two, and then on a specific cadence, graduating to three and four, and eventually five.

• 

  Jason Soroko

  Right. By end of 2026, five, and each one of those five have to be separated by that 500 kilometers.

• 

  Tim Callan

  Correct. Which, you know, that means you need a decent amount of geographic spread, and CAs that aren't necessarily set up to do this, probably especially including local regional CAs are going to have to come up with a solution for this, which doesn't necessarily mean that they have to have boxes sitting in certain places. I'm sure they could do this with a service with a CDN or some kind of partner but they're going to have to get that in place so that they can accomplish this successfully.

  And then the last question we had is, well, when? And so that winds up being interwoven with the question of how many, and there's an actual phase, a rather detailed phase out, with one, two, three, four, five, six - six different steps, six stages, to the end of the process. What you said, in December 15, 2026 and I thought it might be worth just walking through all six of them, and what they are and when they're occurring.

• 

  Jason Soroko

  Yeah. Let's hear it, Tim. I read this one this morning. And it's, as you say, there's a lot of detail and it's going to be an important way to roll out. I'd be curious to see what actually happens, you know, some of the CAs might choose to leap ahead to some of this, depending on what the arrangements are. But very curious.

• 

  Tim Callan

  Okay. Yes. And by the way, as is the norm with these kind of rules, there's no penalty for going early. There's absolutely no penalty for going early. And there's no need to wait until the last possible day. And we as a policy at Sectigo don't. We always implement these things early because that way if there's a technical problem, you shake it out and fix it before you wind up being out of compliance. It's just a better way to go. So there's no penalty for going early and we probably will and a lot of CAs probably will, but these are the deadlines.

  So the first one the first magic date is September 15, 2024. And this isn't really - - this actually isn't a date because it's a should and I'll read the language here. The CA should implement multi-perspective issuance corroboration using at least two remote network perspectives. So they want two remote network perspectives. That's the 500 kilometers different distance thing. And it's a should by September 15, 2024, which means if a CA doesn't, there's actually no penalty. This is more like telling you, guys, you need to get going on this, you need to get into it, you need to start figuring this stuff out. Right?

• 

  Jason Soroko

  Yes.

• 

  Tim Callan

  Now the second one is March 15, 2025. So March 15, 2025, it goes from a should to a must. The CA must implement MPIC, using at least two domain perspectives. The CA may proceed with certificate issuance if the number of remote network perspectives that do not corroborate the determinations made by the primary network perspective is greater than allowed in the quorum requirements table. And basically, what the quorum requirements table turns out to be is it is that it can't be a majority that do not correspond.

  So in this case, you're actually allowed to get away with one of the two corresponding. That's what that table states. So starting March 15, 2025, you have to have at least two perspectives, and one of them has to match what you expect. So this is us still easing into it, and then rolling this out very gradually so that everybody can get it right because this is a big deal.

  Now, the third date is September 15, 2025. A year later from that original should. This is where the CA must implement MPIC using at least two remote network perspectives. The CA must not proceed with certificate issuance if the number of non-corroboration is greater than allowed in the quorum requirements table. So it's a may, right? The one before, the March 15, is they may proceed, so the CA must be doing it but they may proceed regardless of the results they're seeing. Starting September 15, 2025, one year later, they must be obeying the quorum requirements using at least two perspectives. And from here it rolls out relatively predictably.

  So the next one is effective March 15, 2026, they must implement it for at least three remote network perspectives and they must not proceed if the number of non-corroborating is greater than the quorum requirements.

  The one after that is June 15, 2026. And in June 15, 2026, the CA must implement MPIC for at least four remote network perspectives and other than that, the rules are the same, except the number has gone up to four.

  And then in December 15, 2026, the CA must implement MPIC for at least five remote network perspectives. And other than that the rules are the same. So basically, you see what we do is CAs are getting between now and March 15, 2025 to be using at least two perspectives and they're getting between now and September 15, 2025 to be using those two perspectives to make a determination. And then after that, what happens is there's a regular cadence of increasing the number of perspectives required leading up to December 15, 2026.

• 

  Jason Soroko

  Sounds good, Tim. There's a lot there isn’t there?

• 

  Tim Callan

  There is a lot there. Now, let me emphasize. This is in a discussion period. This ballot has not been voted on and it has not even been put forward as a ballot. It's in a discussion period. However - - or I guess it has been, but it hasn't been voted on. So it's in a discussion period. It hasn’t been voted on. Ballots do get pulled back sometimes in the discussion period if meaningful concerns are raised. To my preliminary look, this feels to me like this is a pretty solid ballot, but we'll see if anything comes up on it. Either way, I think it is not a question that some kind of MPIC requirement is coming and coming soon. And if there are specifics that get changed about this ballot, specifics of some of the esoteric of the words or the timing of the cadence or those things, those will get changed, and there will be a new ballot but I think we will look at a ballot, a ballot will pass, and we will be on a cadence that will eventually end in something akin to what I described to you today being a hard requirement for every public CA before they issue any TLS certificates.

• 

  Jason Soroko

  Right on, Tim. This is - - yeah, you know, do you have the link, maybe some search terms people can go and have a look at this?

• 

  Tim Callan

  Yeah. I'm looking at a GitHub repository. So it's in the CA/Browser Forum/Server cert GitHub repository. So that may be worth looking at but I don't know. I would say search for CA/Browser Forum valid SC- 067. That's probably your best bet to try to find information about this. That's the search probably to look for - SC-067. And like I said, we'll see what happens with this and we'll let you know what the results were, but this is a big deal. And it's, you know, it's coming.

• 

  Jason Soroko

  It's coming and that that period of should, at the end of this year, from September 15, 2024 to March 15, 2025, that interests me. Be interested to see who implements during this should period.

• 

  Tim Callan

  Yeah. And this should - - obviously again, the should itself, it's not a violation if you don't.

• 

  Jason Soroko

  That's right.

• 

  Tim Callan

  So that's the balloteer’s way of kind of putting CAs on notice to say, look, don't wait until the last minute. Because if you think about this, right, DV is a requirement - - or DCV. Without DCV, you don't have issuance, right? You can't do it. It's required for every single cert. And if you can't do DCV correctly, then you can't issue certs. So a CA who isn't getting two different - - who isn't successfully getting two different network perspectives by March 15, 2025, even if they're doing nothing with it, if they're not getting the two perspectives by March 15, 2025, then according to compliance rules, they must stop issuing all TLS certificates until it is solved. And they must revoke any cert that is issued after March 15, 2025 until such time as that's resolved. So that is a big, big, big, big deal. And that's why the should is there, I think. Is to say, hey, guys, don't let this one linger. Get on it, and get it done.

• 

  Jason Soroko

  We have been talking about MPDV and now MPIC for quite a while.

• 

  Tim Callan

  Yep.

• 

  Jason Soroko

  And so we knew it was coming. And so now it's written down when the hard dates are going to be. And I don't think any of the dates are surprising.

• 

  Tim Callan

  No, I think this is actually very akin to what we predicted. We predicted that it wasn't going to be a hard requirement this year. That it wasn’t going to be a hard requirement next year, that late this year, we would know what the specific schedule was. And in fact, we know what the specific schedule is, like, we’ll know early this year because it'll be this ballot or the one that comes after it and that'll be the schedule.

• 

  Jason Soroko

  Yeah, Tim. I'm gonna repeat it. For those of you who are curious about what the heck we are talking about with MPDV now called MPIC, please check out Root Causes podcast 327. We go into some pretty good detail about what the potential attack is that we are mitigating here as an industry. One of the big points that I think you and I made on that podcast, Tim, was that this does not have affect the end user, the consumer of publicly trusted certificates. This is all about the CA's having to do magic in their systems.

  And I gotta say, and I think you'll agree with me, this is important. I think BGP attacks, they've been proven by white hats and the writing is on the wall that I think as an industry we need to do this. It would just be horrible if we started to see mis-issuance due to BGP attacks. We have to do this.

• 

  Tim Callan

  We have to do this. It's definitely a real technical possibility. And, you know, this is just something that's got to be required.

• 

  Jason Soroko

  Yeah.

• 

  Tim Callan

  All right. So, there you go. Once again, probably updates will come later as all of this solidifies but that's where it stands right now.

• 

  Jason Soroko

  That's great, Tim. Thanks for the update.

• 

  Tim Callan

  Thank you, Jason. This has been Root Causes.