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

From: Ben Campbell <[email-masked]>
Date: Mon, 1 Mar 2021 16:07:18 -0600

Hi,

Here’s some comments/thoughts/questions on version 01:

General:

This is labeled as standards track, but there’s language like “explores how the PASSporT mechanism could be used” that sounds pretty informational. Is ii really intended as standards track? I guess it needs to be for the PASSporT type definition—but do you expect the other text to evolve to be less speculative? (I may have asked this on 00, but I’ve slept since then :-) ) 

§3.1:

Have you thought about e2e encryption of MSRP similar to that for RTP in SIPBRANDY? And I guess you could just use straight-up SIPBRANDY for text/rtp? (For MSRP I’m wondering if you could use mkey claims for both a TLS SA and and e2e SA at the same time?)

When you talk about needing connected identity for RCS-style applications, are you thinking in terms of group chats? For two-party sessions, would this be any different than for normal STIR?  It seems like even just calling-party authentication could be extremely valuable for things like the RCS MaaP business messaging stuff.

§3.2:

Algorithm agility seems like a good idea unless we have a good reason not to have it :-)

I am on the fence on the msgi vs mky discussion in progress on the separate thread. On first blushl, it seems reasonable to use mky claims plus S/MIME for MIME bodies—but I can see msgi being useful for the OOB scenario you mention in §3.2.1.

As o

§3.2.1:
Any thoughts on whether one could create something like an identity header in SMPP?  IIUC, it’s used for a lot of commercial SMS submission services. (I am not an SMPP expert.)

Last TBD item: That exact thought occurred to me recently. This is a lot like the using OOB vs moving TDM networks to SIP argument for legacy voice, but I suspect the trade-offs would be different. It would be very interesting to hear whether carriers would invest in OOB for legacy SMS vs moving to OOT (or RCS, iMessage, etc.).   I think a lot of this will depend on how much new code will be needed on the SMS endpoints.

Thanks!

Ben.

> On Feb 22, 2021, at 5:36 PM, [email-masked] 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-peterson-stir-messaging-01.txt
> 	Pages           : 10
> 	Date            : 2021-02-22
> 
> 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 instant text
>   and multimedia messaging use cases, both for messages carried or
>   negotiated by SIP, and for non-SIP messaging.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-peterson-stir-messaging/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-peterson-stir-messaging-01
> https://datatracker.ietf.org/doc/html/draft-peterson-stir-messaging-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-peterson-stir-messaging-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 10 Mar 2021 23:11:46 +0000

Hi Ben,

A few notes below.
 
    General:

<JFP>I do expect this all to firm up - as usual, this is an individual submission draft proposing a direction for the WG, and if the group thinks this is a direction worth exploring, obviously we'll flesh it out. Probably it would be intended for PS, for the reasons you suggest.
    
    §3.1:

<JFP> Yes, definitely. I assumed there would be the most potential interest in securing MSRPoTLS. There is some ambiguity about how e2e the TLS would practically be - the principles of RFC8862 are really focused on UA-to-UA security associations, and it might be this is a one-off from that. The trick is really that whatever AS generates the PASSporT that signs "mky" gets the benefit of the assurance. If the AS is not built into the UA generating the initial INVITE, then of course the assurance isn't going to be as strong as RFC8862 can get, but it may still provide a practical benefit.

<JFP>I hope at least two-party sessions would work as normal STIR does. Group chats is definitely another thread of this we'd need to explore. I don't know if we'd want to specify something specific to the implementation of RCS in the IETF, but at least we should try not to close the door on things like that.
    
    §3.2:

    
<JFP>Yeah, exactly which model applies to which use case is still a bit up in the air. If we stage everything as MIME level security, as has been proposed, would make things a lot easier. We'll all have to chat more about that if we decide to flesh this thing out.
    
    §3.2.1:

<JFP>As you hint below, the whole question of how much we can either modify or replace legacy SMS is a huge part of the question of whether this mechanism could really be applicable to it. Broadly, conveyance within non-SIP protocols is more interesting than literal OOB. But I wouldn't entirely discount literal OOB either... especially if it's not the intermediate infrastructure that is doing the OOB, but instead the endpoints themselves. Like, say, if I had an app that knew when I received an SMS to check a certain CPS, and if it finds a corresponding "msgi" PASSporT there, to give a checkmark - something that really uses the receipt of an SMS as the trigger, rather than a rendezvous protocol that pushes the PASSporT to my app. There may be non-insane cases like that.

<JFP>Thanks for the read!

Jon Peterson
Neustar, Inc.
    
    Thanks!
    
    Ben.