Minutes IETF112: stir
minutes-112-stir-00

Meeting Minutes Secure Telephone Identity Revisited (stir) WG
Date and time 2021-11-12 16:00
Title Minutes IETF112: stir
State Active
Other versions markdown
Last updated 2021-11-18

minutes-112-stir-00

STIR Working Group at Virtual IETF 112

Chairs: Robert Sparks, Russ Housely, and Ben Campbell.

Session materials

The chairs would like to think Jean Mahoney, Mary Barnes, and Emmanuel Tricaud for taking detailed notes.

Summary

Charter Update

The STIR WG discussed a charter update to allow adoption of the connected identity document at IETF 111. Nothing happened since then. Our Area Director is okay with the propsued update. The chairs will ask him to progress the update and bring it back to the list in parallel for any last minute discussion.

Connected Identity

The room agreed that draft-peterson-stir-rfc4916-update-04 is a good start and should be adopted. The chairs will move forward as soon as the charter update is in place.

Identity Error Handling

The room agreed that we should adopt draft-wendt-stir-identity-header-errors-handling. The chairs will start a 3 week call for adoption (The call for adoption is in progress. It ends 3 Dec. 2021.) Robert Sparks will submit a companion draft to SIPCORE to allow multiple Reason header field values for the same protocol (STIR). (Since submitted as draft-sparks-sipcore-multiple-reasons)

RCD PASSporT Extension

The participants discussed allowing "cid:" URLs in the "jcl" key. There was support for doing so, but this needs more list discussion. Chris will take it to the list.

The prohibition on having both the "apn" and an alternate presentation number in a jCard should be removed. Chris added text requiring "apn" if it is intended to be displayed when there is a "tel" entry in a jCard.

There is new text in the security considerations about the need to vet RCD content. There are clarications to the use of JWTClaimConstraints for "rcd" and "rcdi", which allows scenarios where a claim is not required, but has constraints on its value if it is included.

There was disagreement about the interaction between PASSporT verification and integrity verification of content referenced by a URL. While people seemed to agree that it should be possible to verify an RCD PASSporT without verifying the "rcdi" claim, people disagreed on how to state thatin the document, including whether a PASSporT should be considered more valid when "rcdi" is verified. Chris, Jack, and Ben agreed to discuss offline to try to agree on text to propose back to the mailing list.

STIR for messaging

The update adds some text about CPIM. Applying integrity to the entire payload when CPIM is used might be an issue. Some messaging systems may have intermediaries that add or remove CPIM header fields. RFC 8591 has some discussion on this. We should try to get input from implementors.

Emergency services use MSRP, and gateway MMS to MSRP. They already verify calls, and want to apply similar verification to messaging.

We need to think about PASSporT freshness for messaging. Messaging applications may have different freshness windows due to things like store-and-forward and message history.

There was general agreement to punt on message conferencing for now.

Eric asked about future-proofing for MLS integration. Hopefully we get that mostly for free, since MLS uses X.509. Jon will discuss this offline with Richard and Eric.

Jon expects this will be ready for WGLC soon.

Detailed Notes from Jean

Administrivia

  • Agenda Bashing
  • Minute Taker
  • Jabber Scribe
  • Bluesheets

Ben - Charter update. Chairs had agreed at the last IETF mtg that we'd discuss it with AD. Murray is okay with text as presented. Propose circulate text on ML.

Jon - I have a slide in the connected ID presentation. We can go over it then. Happy to send text to list.

RjS - Suggest that Murray process text immediately; he can keep an eye on the ML.

Murray - I'm here. Sync up with me.

Connected Identity for STIR

Jon presenting.

Not a WG item yet. Needs a charter update.

No questions or comments from mic.

Mary - LGTM

Ben, Christ, Brian, Cullen, Norbert, ekr - +1

Murray - the diff text I saw looked like a great starting point.

Ben - anyone want to argue that we shouldn't adopt the work?

Jack Rickard - this is quite neat, but it's quite a lot. I'd like to be more confident that people will use it.

Ben, relaying for RjS in chat - we talked aobut this before, we agreed to do this. Let's get this done.

Identity Header Error Handling

RjS, in chat - I still owe the sipcore doc, I sent the text to the list already

Jon and Brian, in chat - adopt

Jack - the security implications stick out to me. You have to remove the Reason header so you don't leak info. If an auth service doesn't understand the spec, they won't do that.

Chris - there's potential danger. People are used to..., doesn't matter if there's multiple or not. I question how much risk there is here. I support the ability to strip it. It's up to the group.

Jack - I'll bring it up on the list, otherwise I really like this.

Brian, from chat - could we have an options thingy that wouldn't sent it unless it was going to be handled appropriately.

Brian, at mic - you wouldn't send it unless the other end could deal. I don't think there's much of a problem here. But we can determine if the downstream element can handle it.

Ben - not seeing opposition to adoption. We'll do a call for adoption on the ML.

Russ - we'll do we 3 weeks for the call given the time of year.

PASSporT Extension for Rich Call Data

Chris presenting.

Ben - the use case - something in another body part, ...

Jon - you can use a cid. Do we want these mime bodies inserted by intermediaries? But we shouldn't be worried about it. what's the integrity...advertisements in a jcard. I think it's doable.

Chris - will people do it?

Ted, from chat - The data URL scheme is self-referencing data

Ben - operators are still figuring out how do some things. Don't want to take it off the table.

Jon - ...you can embed it in the call-info header itself - ugly, and people will do that if we don't provide a better way. ... We're specifying HTTPS, others can specify other URI schemes in other specs.

Brian - we have been using call-info a lot in emergency calls... By value or by reference. People wrote code once and use it all over the place. By reference used more often. cid.

-- chat discussion --
Ted - Please, please don't do that.
Norbert - SHOULD instead of MUST?
Ben - @jon: wfm, Or what Brian just said
Jon - if the existing implementations use cid for emergency services, i'm cool with including it now
Ted - If you specify those two and then say anything requires an update to the spec, I think you're in the right place. sorry, anything else.
Ben, Norbert, ekr - +1 Ted
Jack - We have jcd for by value though right?
ekr - could we also say that whatever it is has to bind it securely? (perhaps it already does?)
jon - the issue is jcd is by-value in the passport, not reflected elsewhere in the SIP message... this may be a point of misalignment between the rcd draft and the sipcore callinfo draft
Brian - hmmmm, if the URI is in a call info and dereferencing it gets you the value you want, then I think the call info with CID gets you the value you want
Jon - yeah, i guess my point is that callinfo header isn't going to point to a PASSporT with a jcd in it - or at least we'd need a way to do that if we want this to interface with callinfo directly
-- /chat discussion --

chris - leaning toward using cid.

Jack - I definitely don't think this is the right wording (slide 9, 3rd bullet is not sensible to have). I sent to the ML why I didn't think this is right.

Chris ...

Jack - This doesn't support that.

Ben, in chat - It's perfectly feasible to make strong statements about integrity verification without making it part of passport verification

Jon, in chat - actively cause harm sounds a little too strong, it's only harm if nobody checks it later

Ted, in chat - @Jon so it causes harm in the face of negligence. I hear the argument as negligence is so likely that we can presume harm. Is that a fair restatement?
Jon, in chat - well chris's text makes it clear that the terminating entity that consumes it is responsible for full verification
Ben, in chat - It's becoming less speculative. The FCC is getting concerned about text spam

Ben - I agree with Jack, and I had made a proposal - 2 kinds of verification. The passport - sig and jwt claims constraint. Integrity of external content - only after passport verification and only if you care about it. Divide this into two steps. passport isn't dependent on the integrity being correct.

Jon - the last sentences here are trying to say that - it's talking about full verification. I hesitate to draw the line here. RCD is more actionable. Are the links safe and can be rendered? We don't want to be prescriptive. ...

Chris - I struggle with - if I'm signing a call, and my tel number is correct but my logo is trying to scam people - are we looking at the total picture there, or only saying the number passes?

Ben - we are falling into a semantic trap here, will confuse people. An evil passport that is signed is valid. If an operator that wants to make other choices based on the contents, they can. I propose that integrity verification is not part of passport verification.

Chris - my fear is that people won't take the integrity stuff seriously, and won't check it and it will be a security hole.

Ben - if they do that, they're using the logo wrong. Use case - up to terminating side to verify the rcd parts, seems valid, don't want to preclude.

Chris - I care about the text means both passport validation and integrity check.

Ben - I argue that it does not.

Chris - what about my use case?

Jack - if the end entity is ignoring the integrity, give up.

Chris - the end entity should consider verification if passport and integrity are verified. Middleboxes only verify numbers.

Jack - doing the integrity check is important, but you have to do it right. Middle boxes can cause harm doing integrity checks. The content at the URLs can only be checked by the endpoint, everything else should ignore it.

Chris - happy to clarify that. The verification service that retrieves the URL and verifies.

Ben as chair - we have another topic. Get together offline, put together some text, bring it back to the list.

STIR for Messaging

Jon presenting

Ben- the cpim discussion goes further. Intermediaries were adding timestamps in the cpm headers, could break integrity.
ekr - great that you are working on this. what about mls

Jon - hope we get mls for free. had sessions about this earlier, but if you thoughts on this.

ekr - need to future proof this a bit.

brian - useful to us in emergencies. we use msrp, has spam and swatting issues. We gateway mms to msrp. If it's sip all the way we're ok.

chris - gatewaying to msrp ... does that too.

richard - MLS has X509Credential, so STIR certs should notch in pretty directly. might need a little more glue to state the number you intend to claim, though that could probably be done at the app layer (cf. HTTP Server vs. SNI) (or rather HTTP Host vs. TLS cert)

Jon - are people cool with us punting on multiparty messaging?

ben, in chat - punting is cool

ekr -

brian - wouldn't be a problem for emergency services. but not stable for long time. Right now it's not a big deal.

jon - if the passport will validate on the other side of it, we're ok.

chris - we can do this sooner rather than later, but for this doc, keep it simple. Consider conferencing later.

Ben - we are out of time

Jon - I'll talk with Richard and ekr about basic principles.

Detailed notes from Mary

1) Administrivia

  • Agenda Bashing
  • Minute Taker (Mary Barnes, Emmanuel (sp?))

Charter Update (Ben):
- Chairs had agreed at last IETF to discuss charter update with connected identity. That didn't happen. Ben proposes to circulate on ML and then hand it over to Murray.
- Jon: has a slide on this for Connected Identity discussion.
- Robert: suggest Murray start processing proposed text immediately.
Conclusion: follow-up with Murray after the session

2) Connected Identity for STIR

Jon summmarized that this is revisiting RFC 4916. Goal is to close security vulnerability such as Route hijacking, short stopping. Takes STIR beyond RFC 7375, thus charter update required. Summarized work that still needs to be done (including notion of a directory to lookup participating entities).

Jon included new charter text - solving related identity problems.

Discussion:
- Mary (chat): Looks good to me - lots of +1s
- Murray: charter text looks like a good starting point.
- Jack: this is quite a big change. Will people really use it?
- Jon: yes, it is a big lift. Think this will be important to various specific scenarios (drive will need to come from those that really need it).
- Robert: We've talked about htis before and have already agreed to do it.

Conclusion: Next step - get charter approved.

3) Identity Header Error Handling

Chris summarized outcome from interim - define a new STIR reason code as opposed to reusing SIP reason codes.

Robert will add a draft to SIPCORE to allow multiple reason headers.

Discussion:
- Jon (chat): adopt!, +1
- Jack: security implications. You have to remove reason header as it propogates so you don't leak info. If an AS doesn't understand this spec, will it just forward everything up.
- Chris: not sure how much risk this is.
- Brian: could we have options that wouldn't send unless it would be handled properly? But, don't see there's much of a problem.
- Ben: Adopt? No disagreements.
- Chris: thinks it's the other way around - the AS has implemented stripping.
- Brian: Yes.

Conclusion: Three week call for adoption to be done on mailing list.

4) PASSporT Extension for Rich Call Data

Chris put together a checklist of items from the interim and reviewed the issues:

  • Issue 1: Ben's comment on 5.1.4 wrt "jcl" key. Should it be limited to HTTPS URLs.

Discussion:
- Ben: use case was when you had something in another body part.
- Jon: you can use a cid URL. Do we really want mime bodies inserted by intermediaries? Need to consider integrity protection properties.
- Chris: it's doable but do we think people will implement?
- Ben: operators and such that would use RCD are still figuring things out. Don't think we should take cid off table just yet.
- Chris: has had discussions on call-info versus claims
- Jon: point about data url, you could encode entire jcard as data info and put in call-info header. But, shouldn't do that. Thinks people will however if we don't do something like this proposal (HTTPS as primary mechanism). People can define separate extensions (beyond HTTPS) in different docs.
- Brian: use call-info for ES a lot. Uniformly allow cid and HTTPS. Think it's useful - by reference used more often than by value. It's done when people don't want to maintain a webserver (use by value).
- Jack: isn't that JCD (by value)?
- Chris: Yes.

Conclusion (issue 1): Seems cid is desirable but needs more discussion on list.

Issue 2: clarify that like "nam", "apn" represents intended default usage. Propose to remove text/requriement that "apn" can't appear in jcard.

-- No comments.

Issue 3: security considerations/vetting.

-- No comments.

Issue 4: "nam", "apn" and all RCD should be vetted.

-- No comments.

Issue 5: fix consistency of logic of rules with constraints (in "rcd" and "rcdi" usages).

Discussion:
- Jon (chat): the issue is jcd is by-value in the passport, not reflected elsewhere in the SIP message... this may be a point of misalignment between the rcd draft and the sipcore callinfo draft

Issue 6 - Verification of integrity for the data - added additional text for Verification rules.

Discussion:
- Jack: don't think the wording is right. Sent message to the list.
- Chris: may be resolved with policies in specific ecosystems.
- Jack: don't think this will support the application of policies
- Ben: there are really two separate kinds of verification. 1) PASSporT is correct - signature and JWT claims constraint 2) Verify integrity of external content. Would only do if 1) is verified and if you care about the integrity. Posted this on email. Proposed to divide into 2 steps.
- Jon: isn't the proposed text saying that? Hesitant to figuring out how to draw the line. RCD is more actionable when it comes to verification. Don't want to be prescriptive. Distinction perhaps along the lines of if it's "safe to render".
- Chris: crux of issue - if I'm signing a call and TN is correct but logo is bogus, are you looking at total picture of verified or is the case that TN is good, is that okay? Think you need to look at all info holistically.
- Ben: Semantic trap - partial versus full verification. Evil PASSporT that's properly signed is valid - up to policies as to whether it is really verified.
- Chris: fear that people won't take integrity seriously and an MB will give an attestation of A and people are going to pass bogus RCD without verifying.
- Ben: if they do that, then they're doing it wrong. Originating carrier uses RCD only for attribution purposes - entirely up to terminating side to verify RCD.
- Chris: want text to be more specific that verification means both - PASSport Validation and integrity check.
- Ben: disagrees.
- Jack: MBs can't protect against malicious actors.
- Chris: isn't that what the text says? Endpoint needs to verify everything but there are MB scenarios where you don't need to do full verification.
- Jack: integrity verification is important - needs to be done right. MBs can actively cause harm by doing integrity verification. Integrity is separate.
- Chris: happy to clarify that.
- Ben: Propose to have offline discussion and propose text to list.

Conclusion: further discussion required and text needs to be agreed on mailing list.

5) STIR for Messaging

Jon quickly summarized draft purpose - PKI to address SPAM messaging issues, noting that there's a lot of legacy messaging that isn't SIP. Two paths for STIR:
- SDP negotiated message stream security
- individual MESSAGE security - at MIME level

Summarized recent updates: privacy/security, messaging conferencing (MSRP) - would required Connected-identity, CPIM

Discussion:
- Ben: some of this (CPIM) is discussed in a previous draft.
- EKR: what's relationship to MLS?
- Jon: discussed earlier, but not a lot of takers. Don't think expertise is in this room.
- Richard (chat): MLS has X509Credential, so STIR certs should notch in pretty directly .... might need a little more glue to state the number you intend to claim, though that could probably be done at the app layer (HTTP host vs TLS cert)
- Brian: would be good for ES which uses MSRP. MSRP would work as long as the right thing would happen at the gateway.
- Chris: this happens in RCS.
- Jon: Do we need to solve multiparty messaging out of the gate for this to be useful?
- EKR: ...spoke too quickly to capture...
- Brian: not a problem for ES because multiparty MSRP isn't implemented now.

Conclusions: Jon to chat with Ekr and Richard offline. General support to punt multiparty for now. Doc should be about ready for WGLC.

Detailed notes from Emmanuel

Pre meeting chat track

Jean Mahoney : can hear you 16:58:11
Ben Campbell : chat is quiet--is this thing on? 17:01:19
Mary Barnes: Yes. Everyone is tired..... 17:01:32 I've been up since 1:30 am. Nomcom interview at 4am 17:01:51
Jon Peterson: heh 17:01:59 we can discuss charter with connected identity 17:02:16
Ben Campbell : Note taking tool: https://notes.ietf.org/notes-ietf-112-stir 17:07:54 (if anyone wants it) 17:08:05

Connected Identity for STIR

Introduction:

Jon Peterson and Chris Wendt
draft-peterson-stir-rfc4916-update-04
Discuss deferred from interim meeting due to time constraints

Discussion notes:

Jon Peterson : this is about an update to RFC4916. It is about how to make Identity work in the backwards direction. The purpose is to tell you who you actually reached. this is no new version. There are risks of privacy considerations. Having some kind of directory about one should expect communication from this identity. There is plenty to do. Is there any question?

Jon Peterson : we will proceed as said.
Murray Kucherawy : it looks like a great starting point.
Ben Campbell: Any reason we should not adopt this?
Jon Peterson : this will be STIR 2.0.
Jack Richard : it is quite a big change. I’d like to be more confident that people will make use of it. If emergency services, big banks, big corporations want it, they have a big leverage on carriers.
Ben Campbell : let’s move to the next agenda item.

Chat track

Mary Barnes : Looks good to me. 17:12:15
Ben Campbell : +1 17:12:25
Chris Wendt : +1 17:12:29
Brian Rosen : +1 17:12:30
Cullen Jennings : +1 17:12:34
Eric Rescorla : +1 17:12:56
Robert Sparks : the room has said do this already more than once - good to check that the mood hasn't changed, but yeah, lets go 17:14:07
Norbert Angell : as long as it's not "required", I can see some Operators saying no thanks? 17:14:41 +1 17:15:27
Jon Peterson : yeah the forcing function would be critical use cases from large enterprises who might be like "if you don't want to do it i'll find somebody who does" 17:17:17
Robert Sparks : I still owe that sipcore doc 17:17:58. I sent the text to the list already 17:18:10
Brian Rosen: yes, you so, said a sipcore chair 17:18:10
Mary Barnes : I like that. 17:18:23
Brian Rosen : "do" 17:18:26
Jon Peterson : adopt! 17:19:57
Brian Rosen : yes please, adopt 17:20:07 could we have an options thingy that wouldn't send it unless it was going to be handled appropriately? 17:21:57
Jack Rickard : I'm also pro adopting if that wasn't clear

Identity Header Error Handling

Introduction

Chris Wendt
draft-wendt-stir-identity-header-errors-handling-03
Updated based on discussion at interim meeting. Discuss open issues; get ready for WG call for adoption

Discussion notes

Chris Wendt: we’ll move from a SIP reason code to a STIR reason code. Let me know whether there is any thought on the changes I’ve made.

Jack Richard: the one thing that stick out is the security implication. If you have to remove the Reason header and you don’t, what is left of security ?
Chris Wendt: there is some danger in that. How much risk is there for this situation ? We are still in early days.
Jack Richard: that’s right.
Brian Rosen : you would not send it unless it was implemented.
Chris Wendt: if I interpret Jack’s comments correctly, there is a potential danger. I support the idea it could be stripped.
Brian Rosen : we could come up with a way to do that if necessary.
Ben Campbell: let’s do a call for adoption.
Russ Housley : let’s do it three weeks, considering the time of year.

PASSporT Extension for Rich Call Data

Introduction

Chris Wendt and Jon Peterson
draft-ietf-stir-passport-rcd-14
Update from discussion at interim meeting. Resolve open issues from WG Last Call

Discussion notes

Chris Wendt: there was a comment from Ben, saying that we should eliminate anything but https URLs.
Ben Campbell : if we did not put it; it would be inconvenient if people wanted to add it in later.
Chris Wendt: I see your point.
Jon Peterson : you could encode the entire jcard. That would be ugly.
Brian Rosen: with https or CID you get exactly the same data. I see people using much more often by reference than by value. It is when vendor
Jon Peterson : JCD is by value, JCL is by reference.
Chris Wendt: good point. I’ll put it on the list and generate a bit more discussion.
Chris Wendt: there are a couple things about NAM and APN, supporting textual clients.
Chris Wendt: rcd usage and rcdi usage : there is also the possibility to have no rcd claim. With rcdi, the rules are slightly different but the logic is the same. Do we want only permitted values?
Chris Wendt: On verification rules, I added the last paragraph.
Jack Richard: I definitely don’t think this is the right text to put in.
Ben Campbell : one is to verify that your passport is correct. The second is that your external thing is correct, but you would do it only if your passport is correct.
Jon Peterson : I am a little hesitant. RCD is more actionable than other things we have done before. Are these links safe enough to be rendered to users ?
Chris Wendt: the crux of the issue for me is that, if I am signing a call, if my telephone number is correct, but my logo is trying to scam people, ???
Ben Campbell : we are falling into a semantic trap that is going to confuse people. Integrity verification is not part of passport verification at all.
Chris Wendt: my fear is that people will not take this integrity stuff seriously. They will just pass this info on.
Ben Campbell: it is entirely to the terminating side to check this integrity thing.
Jack Richard: if the end entity is ignoring integrity, you might as well forget it.
Chris Wendt: there are middle box scenarios where you can ignore it.
Jack Richard : middle boxes can in some cases do some harm in checking integrity.
Chris Wendt: I am happy to clarify that.
Ben Campbell: we have only 8 minutes left. Let’s take it offline and do it by mail.
Ben Campbell: we should switch to messaging.

Chat track

Jon Peterson : cid url 17:27:37
Ben Campbell : yes, that :-) 17:28:11
Ted Hardie : The data URL scheme is self-referencing data:(the encoded data). I don't think I'd recommend that. 17:28:13
Ben Campbell: @Ted: sorry, I meant "cid" 17:28:26
Ted Hardie : Please, please don't do that. 17:30:52
Norbert Angell : SHOULD instead of MUST? 17:31:28
Ben Campbell : @jon: wfm17:31:42 Or what Brian just said 17:32:05
Jon Peterson: if the existing implementations use cid for emergency services, i'm cool with including it now 17:32:21
Ted Hardie: If you specify those two and then say anything requires an update to the spec, I think you're in the right place. 17:32:22 sorry, anything else. 17:32:30
Ben Campbell: +1 Ted 17:32:32
Eric Rescorla: +1 to what Ted says 17:32:33
Jack Rickard: We have jcd for by value though right? 17:32:34
Norbert Angell: +1 Ted 17:32:39
Eric Rescorla: could we also say that whatever it is has to bind it securely? 17:33:26
(perhaps it already does?) 17:33:32
Jon Peterson: the issue is jcd is by-value in the passport, not reflected elsewhere in the SIP message... this may be a point of misalignment between the rcd draft and the sipcore callinfo draft 17:36:09
Brian Rosen: hmmmm, if the URI is in a call info and rereferencing it gets you the value you want, then I think the call info with CID gets you the value you want 17:38:07
"dereferencing" 17:38:25
Ben Campbell: I think Alec said the bit attributed to me. (Or maybe I was parroting him) 17:39:20
Jon Peterson: yeah, i guess my point is that callinfo header isn't going to point to a PASSporT with a jcd in it - or at least we'd need a way to do that if we want this to interface with callinfo directly 17:39:57
Ben Campbell: It's perfectly feasible to make strong statements about integrity verification without making it part of passport verification 17:50:28
Jon Peterson: actively cause harm sounds a little too strong 17:50:48
it's only harm if nobody checks it later 17:50:59
Ted Hardie: @Jon so it causes harm in the face of negligence. I hear the argument as negligence is so likely that we can presume harm. Is that a fair restatement? 17:52:00
Jon Peterson: well chris's text makes it clear that the terminating entity that consumes it is responsible for full verification 17:54:15

STIR for Messaging

Introduction

Chris Wendt and Jon Peterson
draft-ietf-stir-messaging-01

Discussion notes

Jon Peterson: this is for real-time texting sessions plus individual messages. The messaging ecosystem is very diverse. Two paths: SDP negotiation and individual message security. We added a lot of security/privacy considerations, some text on message conferencing, on CPIM.
Ben Campbell : I don’t know if I have an answer to this question.
Brian Rosen : we use MSRP. It is treating like a call. We cannot have calls checked and messages not checked. If it’s SIP all the way, we are OK.
Brian Rosen: it would not be a problem for emergency calls. If we started to chat with MSRP, that would be an issue, but now punting this is fine.
Jon Peterson : we have STIR/Shaken PKI for SIP ; I don’t want to have something different for messaging.

Chat track

Ben Campbell It's becoming less speculative. The FCC is getting concerned about text spam 17:55:53
Yay, we can have the same discussion about message integrity verification as RCD integrity :-) 17:57:08 Will connected ID be a normative dependency? 17:57:53
Richard Barnes : MLS has X509Credential, so STIR certs should notch in pretty directly18:00:18 might need a little more glue to state the number you intend to claim, though that could probably be done at the app layer (cf. HTTP Server vs. SNI) 18:00:50
(or rather HTTP Host vs. TLS cert) 18:01:16
Ben Campbell: Punting is cool18:02:30 MLS for free is even more cool 18:02:46
Eric Rescorla: SGTM 18:04:52
Richard Barnes: 👋 18:04:58 sg, happy to do a follow up18:05:02
Jon Peterson: sg 18:05:51