IETF STIR WG 116 Meeting Minutes Wednesday, 29 March 2023 - 15:30 JST SCRIBE: Simon Castle # Summary {#summary} draft-ietf-stir-identity-header-errors-handling has been approved by the IESG. The only changes during IESG review were editorial. draft-ietf-stir-passport-rcd is nearing the finish line. There have been a number of clarifications during IESG review. Participants in the room also agreed to limit "icn" to use HTTPS URLs. These involve some changes to normative language. Russ sent an email asking for objections to the changes to be sent to the list by April 7. The WG recommends Errata 6519 be set to "Hold for Document Update" and the notes from IETF115 be added to the erratum. draft-stir-messaging has had a number of changes due to the AD review. There are pending changes to clarify the reasoning for the Proposed Standard status and to reference the COSE registry for integrity mechanism hash algorithms. (People noted that draft-ietf-stir-passport-RCD may need to reference the same registry for RCDi.) draft-ietf-stir-rfc4916-update has had a number of changes since the last version and will go to WGLC shortly after the meeting. draft-ietf-stir-servprovider-oob seems to have resolved most comments. We need to progress it soon, since related work has already happened in ATIS. \[Note: The minutes do not explicitly mention WGLC, but it sounds like time.\] draft-ietf-stir-certificates-ocsp is making good progress, but needs polish before WGLC. Discussion will continue on the list. # Detailed Notes {#detailed-notes} STIR Working Group at IETF 116 1) Administrivia * Agenda Bashing * Minute Taker * Jabber Scribe * Bluesheets 2) Identity Header Error Handling * Chris Wendt * draft-ietf-stir-identity-header-errors-handling-08 * In the RFC Editor queue Chris Wendt: Only changes from 7 to 8 were editorial comments. No slides. Hopefully all set; we're done. 3) PASSporT Extension for Rich Call Data * Chris Wendt and Jon Peterson * draft-ietf-stir-passport-rcd-24 * Have all IESG Evaluation issues been resolved? Chris Wendt: Hopefully crossing finish line. Resolving last comments, including Roman Danyliw's very comprehensive helpful comments. Ben brought up some comments around HTTPS and/or CID. Chris Wendt: In addressing comments: some normative language change. Only one that upgraded normative requirements was the "nam" key section; was clarifying that the display name should be followed as part of RFC3261. Feedback wanted esepicailly for this one. Chris Wendt: Other sections on "icn" HTTPS URL refs, JWT Claim Constraints "rcd" adding a MAY, JWT Constraints for "crn" downgraded from MUST to MAY, "rcdi" added NOT RECOMMENDED but didn't change the intent. Level of Assurance removed a MUST and clarified a RECOMMEND about third-party assurances. Chris Wendt: A section about "rcd" and "rcdi" claims as additional claims to other PASSporTs contained a note that was remoevd. Ben Campbell: That last note being removed didn't change anything right? Chris Wendt: No, no change Jon Peterson: Because we're doing that right? Chris Wendt: Correct. The procedure doesn't change, people just didn't like the language. Chris Wendt: Added paragraphs to Security Considerations (RCD URI linked resources, URL/URI guidance) following Roman's feedback. Happy with where we've got to. Ben Campbell: Roman asked why we had a support for URL rather than HTTPS. We orignally added because we thought e.g. logos might want to be imbedded in the SIP request. But we'd probably be fine with HTTPS only. If we need others later we can update. If anyone does want CID etc say soon! (Further comments from Chris Wendt and Jon Peterson broadly agreeing) Chris Wendt: Updates to SIP Core list which are referenced, but that's pended until after the RCD changes were done. Ben Campbell: There are a few normative language changes. Propose leaving for a few days to allow for review and feedback. Silence is consent. Odds are we'll get through any call directions before the ISG is ready to prgoress anyway. 4) Errata 6519 * STIR WG Co-chairs * https://www.rfc-editor.org/errata\_search.php?eid=6519 * Propose resolution to the ART Area Directors Robert Sparks: Errata filed against an RFC about whether the value to the "ppt" parameter is quoted or not. From meeting recordings and minutes there's a fairly concise description on what to do, but no follow-up. Robert Sparks: Proposal - capture the notes from that meeting as notes for the errata, put forward with "Hold for Document Update". I don't think that getting a correction published in the RC base in a more timely fshion is necessary. It's a minor point of interoperability but as far as we're aware not causing a problem in deployments. Any comments? \[No response\]. That's what I'm going to do. 5) STIR for Messaging * Chris Wendt and Jon Peterson * draft-ietf-stir-messaging-05 * Have all IESG Evaluation issues been resolved? Jon Peterson: This one got out of the WG, into the IESG. This is a draft for leveraging STIR work into text messaging. More spam in the messaging network - in part caused because our work in making call spam harder! Jon Peterson: There's a problem in messaging: E2E encryption. Jon Peterson: it's a waste to come up with a new approach for messaging, so just reuse STIR technology. Jon Peterson: Lots of fixes in -07 after review. Two outstanding fixes for -08: resuing COSE registry for an algorithmic agility fix, and add a note to the introduction clarifying that there is (a small amount of) normative language, but also plenty of informative guidance. Ben Campbell: Does the rcdi need to reference the same COSE registry? Jon Peterson: We could, and the msgi description was taken directly from it. From standards perspective we probably should. Chris would be writing that - he can just copy what I write for msgi. \[Chris agrees\] Jon Peterson: We could add some language around MIME/MME - don't know if it'll change anyone's world but can do it. Jonathan Rosenberg: There are other use cases around this and you can only do that if there's something in the document to start that. Jon Peterson: There have been preliminary discussions around that, and someday there will be a draft around that. Chris Wendt: Want to clarify on the COSE registry - you should have some text that it says only the hash algorithms. Jon Peterson: No we're just using their tokens. We can allude to their algorithms and rely on their expertise. Other than that, I think we're pretty close and should be able to go forwards. 6) Connected Identity for STIR * Jon Peterson and Chris Wendt * draft-ietf-stir-rfc4916-update-02 * Is this ready for WG Last Call? Jon Peterson: Connected Identity began as a solution to how you do STIR in the backwards direction. Problem is it struggles with any redirection (among other points). Jon Peterson: So why am I interested in this? Various considerations looking to leverage STIR. For example, avoiding forged BYEs (Route higacking, call stretching). So we extended the charter to cover this. Jon Peterson: Decided last meeting to remove "from-change" and start a new approach, through introduction of an "rsp" PASSporT, signed with authority for the 'dest' rather than the 'orig'. It'll work really well in a sunny-day case with no div (good for things like banking, healthcare). Can also secure media keys (for messaging cases like MSRP). Jon Peterson: So I've punted all the "from-change" work. Someone else could pick this up if they wanted. Jon Peterson: So new document is not so much of an update to RFC 4916. It could be said to obsolete that one but it's nice to leave in case someone does want to fix the "from-change" in the future. I'd like to make some comments and propose it's ready to advance to Last Call. Eric Rescorla: Seems better than nothing. Curious what the expectation is around how the call behaves in the absense or incorrectness of this - always a problem in incremental deployment of this. Jon Peterson: We don't specify outright but there could be a critically flag a user could add which means a call requires this. Eric Rescorla: Have you given any thought to being able to condition a caller's expectations in a more useful way? Jon Peterson: There's some sci-fi language in here that could provide operational systems or enum like systems to support this. Eric Rescorla: Is there some way you can decorate the URL? Jon Peterson: SIP has required supported options tags; we could put an option tag in for that says something like "it's required that this option exists for this call to go forward". Eric Rescorla: Seems like a good start. Chris Wendt: That's a good point but I think we can punt it to just be a SIP application that handles the response, and maybe specify something in the future. Jon Peterson: There's a lot of stuff in there that says "these provisional responses aren't reliable". It's kind of best erffort. The only thing that can mitigate that or create the proper experiecnce is that there is a criticality button you can press that says "for this kind of call it's really important and if it doesn't I don't want the call to be set up." But that's entirely UX. That's my assess; I'm open to better ideas. Jon Peterson: I think what's there is baked enough, I'd like some eyes on it and maybe advance the document? Ben Campbell: What still needs to be done about this? You said you needed to decruft this, was that before or after last call? Jon Peterson: It's just de-crufting, it can be after. Ben Campbell: So question for the floor is - does anyone think this is not ready for WG Last Call? \[No comments from the floor\] \[Chairs agree to issue a Working Group Last Call for this document ASAP (And will do a better job about it than last time!)\] 7) Out-of-Band STIR for Service Providers * Jon Peterson * draft-ietf-stir-servprovider-oob-04 * Is this ready for WG Last Call? Jon Peterson: What do you do if not everything is SIP? The CPS was designed as a fallback. We've defined an alternative use case in this draft where an entity who knows the called/calling parties hosts the CPS. Aiming for a description. Jon Peterson: Few useful comments from Simon Castle asking about how the CPS can be identified. Didn't want to be presecriptive about the process for advertising but there's questions about how you map from TN to SPC unless something already exists so the draft now disclaimers that issue. Jon Peterson: Also added a disambiguation for SPCs vs TNs based on the TNEntry value. Russ, does that seem sufficient? Russ Housley: Seems OK Jon Peterson: Also what if you want to support non-TN based STIR e.g. URIs. Decided to leave that for someone else to address. Simon Castle: All comments addressed. Jon Peterson: So we're all good to go? Ben Campbell: ATIS has done a document that's based on the concepts in here. They don't directly reference it and there's been some controversy there around issues with potential substitution attacks and privacy issues. I don't think they apply to this draft, just to the ATIS version, but want to raise to the floor. Jon Peterson: I agree with you. Ben Campbell: They make some architectural assumptions that change the security consideration some; I'm not taking a side on whether it's a but... Jon Peterson: Certianly if you take the concept of the CPS and decouple it from the Service Providers that way and everyone who operates a CPS is required to flood and share every PASSporT they see with every other CPS - I don't believe that's salient to this. Jon Peterson: Time to ship? \[No responses\] 8) OCSP Usage for Secure Telephone Identity Certificates * Jon Peterson and Sean Turner * draft-ietf-stir-certificates-ocsp-03 * Is this ready for WG Last Call? Jon Peterson: Freshness for STIR Certs - everyone wants to know that a cert in STIR is fresh due to the TnAuthList extension (and specifically TNs and TnRanges). How do you know if a TN is still in the scope of authority of a certificate? Jon Peterson: Looked at OCSP and short lived certs. Jack Rickard put together a summary of the various options (existing by-ref; OCSP with or without stapling; short-lived with or without stapling). Jon Peterson: Existing by-ref works but involves very large downloads that are hard to be cached - can we do better? Jon Peterson: OCSP is used commonly already (my company already uses it). This allows a single TN to be requested minimizing data revelation.But this still reveals info about who's calling where. Jon Peterson: Alternative is short-lived certificates for a single TN which can be relied on, but these might not be usefully cacheable and mechanisms need to include more options. Jon Peterson: Jack's summary including a new option: stapling the short-lived certs, putting the certificate in the x5c value. So those are the options on the menu. Eric Rescorla: At the highest level, seems like there are two possibilities - either contain all the information you need in something with a short life-span or lack it and someone has to go query it. My way to reason about this is that the long lived certificate has the entire range of TNs and over time starts to accumulate gaps. Jon Peterson: Except the by-ref option. But that has the revelation problem. Eric Rescorla: Right. Is the conventional practice now with OCSP that you advertise a range that contains numbers you never owned and then when people live check they say actually I don't? Jon Peterson: That practice hasn't been implemented that I'm aware of. We put regular OCSP without this extension; the way this extension would work is we added the extension to the OCSP query so that when the query comes back you get a binary pass/fail. Eric Rescorla: If you do regular OCSP, why doesn't that have the same revelation problem as by-ref? Jon Peterson: If you poll the whole number space, yes, of course. We don't bake the numbers into the cert at all - the AIA replaces the TnAuthList that would have been baked into the cert. The only thing you care about as a verification service is validation of a single number, we want to reveal as little infomation as possible that provides that, that's our design goal. Eric Rescorla: I guess that's what you and I were talking about before the sessions; there's cryptography that does this this but it's expensive. So the question is if there's a less expensive version. Maybe we can chat offline to get a sense of the size of the space. Because I can imagine some ideas that will work a lot better if the certificates can only cover relatively small ranges. If there are only 1000 valid numbers asking the question "is this number allowed" is an easier question than when there's all possible numbers. Jon Peterson: It'd be hard to put an upper bound on the number of numbers that could be in the range that the cert has responsibility for. That's the challenge. Eric Rescorla: One possible design you might imagine: certificates cover blocks of 100. Then it might be possible to get answer to "do you cover this number" efficiently. But there's no way around the polling problem, fundamentally. Jon Peterson: Unless stapling can suffice, where you ship the leaf cert in a parameter in the PASSporT itself. Eric Rescorla: If you're willing to poll the CA every time you want to do that. Jon Peterson: We could push the entire chain, ultimately. It's just the PASSporT will be huge then. That's the trade-off. Chris Wendt: Number ranges don't make sense in this discussion any more. Should all be single TNs using OCSP or short-lived. Jon Peterson: That is the part that does our data minimization responsibility best, if we do that. Unless Ecker comes up with a crypto thing. We can talk about that offline. We're less concerned about paying costs on the relying party side than about the dip in the latency. Jonathan Rosenberg: Back in the Viper days we had a similar problem of revealing information to the cloud based on what calls were being received, the solution there was that you'd query for multiple numbers rather than just the one you'd received. Jon Peterson: We're less concerned about the revelation of the relaying party to the CA than the amount that the relaying parties learn about the assets of the enterprise that owns all the numbers. But yes, we could use bogus queries, that's something we do with the CPS. Jonathan Rosenberg: The OCSP problem is that it's open; not everyone in the world needs to be able to access it, just given providers. Jon Peterson: I can imagine a scenario - thinking internationally - where you have a set of trusted entities in one nation state but then should blind parties who aren't party to this, should they still be able to be relying parties on this - I don't know. Jonathan Rosenberg: In practice isn't that true? Jon Peterson: In practice in North America there's a list of trusted CAs and effectively there's a list of Verification Services that have some ties to the PAs in the SHAKEN model that is a closed network, but I've noticed you can't always predict where a call is going to land based on the calling party number. It'd be great if wherever it lands, even if it's not part of your trust network, that could still show up - but maybe that's a property we should discard, that's a valid comment. Eric Rescola: Just so I understand the threat model a little more - we want to avoid impersonation of a number when it's ported from one provider to another? Jon: More just need to be able to handle numbers being ported and other kinds of acquisition, and moving from one place to another, and we can rely on CAs as a source of truth. Eric: So how long is the reaction time? Jon Peterson: About 24 hours is reasonable for number porting. Chris Wendt: It also has benefits if there's a bad actor you want to revoke. Jon Peterson: Some have argued that we should cut down to only support one thing. I think this is premature. Short-lived and AIA already work out-the-box. OCSP is already in use so getting that extension to work, we sort of get that for free. I'm reluctant to rule much of this out for now. We might end up in a pluraist environment. People might want to do short-lived certs for their own reasons and be compatible with the fact that of course OCSP is going to get used. Jon Peterson: What we proposed in the OCSP stapling draft (not yet adopted) was a new stapling feature to the PASSporT. This was considered for other places like in the SIP layer, but kept to PASSporT since this is very important for Out-Of-Band and messaging use-cases. It could be extended to short-lived certs, sending the leaf cert or even the whole chain in the PASSporT. This will massively increase the size of the PASSporTs. We get comments about MTU etc on the mailing list. But that's what Jack was proposing. Jon Peterson: We need more discussion. Any thoughts? Anyone got implementations of STIR that will barf with this? ???: It's the SIP that will barf with this. There's a lot of UDPs still out there. Ben Campbell: I've seen major carriers talk about they have IP interconnects they still can't do SHAKEN over because they're UDP. But we already can't do any of this over UDP! Jon Peterson: SHAKEN should have adopted compact form some time ago. Ben Campbell: Then you're just shoving information over back into the SIP header. Jon Peterson: No, compact form just dispense with everyhing but the SAG. Ben Campbell: If we've already pushed this into using TCP, then what difference is a little more? Jon Peterson: Yeah, for this you'd need a SIP header that would carry the entire leaf cert, x5c with it. Chris Wendt: We've been debating this so long. I like either form of stapling, because it removes the number of round trips - it'd be good to pick one of the forms, but OK to keep both. Jon Peterson: My proposal - I'd like to keep three elements: keep the OCSP baseline that's close to done (some SDOs are using it, so let's get it published so it's something people can rely on); adopt and advance the currently expired shortlived draft (hoping to twist Jack's arm into helping on this) but probably downplaying the ACME dimension since people are getting short-lived certificates from their service providers over a different interface; and take the existing stapiling draft for OCSP and generalize it to a 'freshness' element to PASSporTs that can apply to OCSP or short-lived. Jon Peterson: Nothing's actually being dropped, but from a workflow perspective let's advance OCSP and short-lived. Both are applicable, we're not in a position to pick a winner, and they're not obviously competing. Eric Rescorla: This seems in the finest traditions of the IETF. Jon Peterson: We provide tools to be used in different profiles and different environments; we should just make the tools available. Eric Rescorla: I'm not clear why you'd use OCSP to do stapling. It's not clear why we have to do both, they're kind of isomorphic. Jon Peterson: It's because they're isomorphic that it's hard to decide. Eric Rescorla: Typically you'd imagine short-lived is a better approach because they're smaller. Jon Peterson: Those x5c chains could be quite large in delegation, these could be five or six chains. My intuition is there's no free lunch, we end up doing the same work. Jonathan Rosenberg: Is one of these mandatory to implement? Jon Peterson: My intention is that these are independent specifications and that compliant implementations will specify which ones they're compliant with. There'll be no guide which one is mandatory. Maybe in the future one will be the winner. Jonathan Rosenberg: Is there an interoperability problem? Or are you saying ATIS will pick one so in practice there won't be an interoperability problem? These might have to be stripped at national boundaries. Chris Wendt: I think we should pick one. I'm not concerned about long certificate chains; I think we should go with short-lived with 'stapling'. I'd be OK with both forms of stapling but would prefer just the short-lived one; it's the simplest. Jon Peterson: I agree from a security perspective it's the strongest. It provides the data minimization we want. As an assurance it feels stronger to me than OCSP, but operationalizing that system where on a per-call basis you're synthesizing a certificate for a single TN and providing its chain and getting it into a certificate in time, and the validation then runs which is complex, with multiple paths that could be built - there's no free lunch. Every way I look at this, I get worried about complexity in the architecture. Chris Wendt: These are all pre-call things. You could gather that information pre-call. Jon Peterson: You could gather all the information for every number you could possibly sign for, but then the question becomes how short-lived are those? How often do you have to do that process? Generate 500,000 certs every 5 minutes? Don't underestimate the complexity this could be. Chris Wendt: But you're gathering all those things asynchronously. You're not doing that all at the call. Jon Peterson: I'd probably do it at the call if I was building this. If I was doing it for 100 numbers I might do it on the API call to my AS, but if I have to do it for a large enterprise for tens of millions and I have to keep a keyring... Not saying it's impossible. Eric Rescorla: As you say, either you have the certificates in advance or do you get them on the fly? Can we make it so you don't have 500,000 signatures? Probably. Can we make it so you don't have to store some stuff? Probably not. You have to store some data. Jon Peterson: I'm worried about 500 million more than 500 thousand. Jon Peterson: I don't have an answer to this other than "let's advance three docs at roughly this scope." and see if we can do better. Ben Campbell: As chair, what are the concrete Working Group actions to do? Jon Peterson: I'll do a bit of polishing of the OCSP before going for WG Last Call. Call for adoption on Short-Lived immediately as lots of people seem to want that. General stapling only occured to me this morning so let me do at least one rev of that before we talk about adoption. \[Further agreement that more discussion needed on the list\] 9) Any Other Business (if time permits) No other business.