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

(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, internet-drafts@ietf.org wrote:
> 
> 
> 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/
> 
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir