Subject: [stir] I-D Action: draft-ietf-stir-messaging-01.txt

From: [email-masked]
Date: Tue, 09 Nov 2021 13:23:16 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF.

        Title           : Messaging Use Cases and Extensions for STIR
        Authors         : Jon Peterson
                          Chris Wendt
	Filename        : draft-ietf-stir-messaging-01.txt
	Pages           : 10
	Date            : 2021-11-09

Abstract:
   Secure Telephone Identity Revisited (STIR) provides a means of
   attesting the identity of a telephone caller via a signed token in
   order to prevent impersonation of a calling party number, which is a
   key enabler for illegal robocalling.  Similar impersonation is
   sometimes leveraged by bad actors in the text messaging space.  This
   document considers the applicability of STIR's Persona Assertion
   Token (PASSporT) and certificate issuance framework to text and
   multimedia messaging use cases, both for instant messages carried or
   negotiated by SIP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stir-messaging/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-stir-messaging-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-messaging-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Nov 2021 22:50:16 -0600

(No hats)

Thanks for the update. A few high level thoughts. We’ve probably talked about some of these before, but I’ve slept since then.

Freshness:

I wonder if we need to think about (and maybe even say something) about passport freshness for messaging. The time frame for message delivery is different than for voice calls. They may end up on message stores for store-and-forward or message history applications. I suspect the freshness guidance in RFC 8224 won’t be right. OTOH, extending the freshness window for more than a few minutes could be a replay attack problem.  Maybe the passport should be verified prior to putting a “read" message into a history folder, but that may not make sense for store-and-forward of unread messages.

CPIM:

I see that it now mentions CPIM. My concern about CPIM based messages is that some systems use it to attach metadata to the message. As far as I know, the use of CPIM for security interworking between messaging protocols hasn’t really happened. But it is being used by some messaging systems (e.g. RCS) to attach metadata to messages for other purposes. I suspect there are cases where intermediaries add or consume CPIM header fields. This could be an issue for the MSGi mechanism if we assume the entire body is always protected. RFC 8591 section 9.1 talks about this in some more detail for S/MIME, but the same issues may apply here.

I’m not saying that we should necessarily change from msgi protecting the entire body—it’s just something we should think about and maybe get some feedback from implementors.

SMS:

I’ve been thinking if we could use OOB passports in some way to authenticate legacy SMS messages, especially if they are sent or delivered using SIP (e.g. the 3GPP’s SMS-over-IP spec. But IIUC, in that spec the SIP From, To, and R-URI do not necessarily represent the sender and the recipient. That information is buried in the body. Figuring out a solution for that is probably out-of-scope for STIR, but it would be nice if we don’t preclude others form solving this.  (I suspect the answer is that SMS-over-IP is a completely different protocol that only incidentally uses SIP at the edge, and someone would need to specify how to use passports with it.)

Thanks!

Ben.

> On Nov 9, 2021, at 3:23 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir