Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason)

[Henning Schulzrinne <[e-mail]>]

Hi Chris,

tl;dr: My suggestions are: (1) leave call purpose out
of draft-ietf-stir-passport-rcd; (2) drop call-purpose
from draft-ietf-sipcore-call-info-rcd; (3) consider a new JWT claim
"subject" [or whatever] that encapsulates the signed call purpose in the
future.

More details inline below.

On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <[e-mail]>
wrote:

> Hi Henning,
>
> I understand what you are saying.  I do however think there is reasons to
> protect call-reason/Subject of call.  I think these situations are mostly
> in the context of delegation to perhaps a call center, where you have
> authorized them to represent your company in particular ways, including not
> only your identity, but for different context of calls that you have
> authorized them to represent you.  We all know there is some call centers
> that use call identities with good reputation for customers that may
> exploit that reputation for other customers.  I would look at this as
> similar situation.
>

I think we generally agree - your example of a call center is probably, in
my view, the most likely case where some indication of call purpose will be
used, probably with explicit arrangement with the carrier. This may well
turn out to be similar to the current model for SMS, where (in the US and
some other countries) you'll have to register your "campaign" with the
carrier or designated third party. This may even take the notion of a
template ("This call is about your recent order from {date}") that can be
auto-enforced. It's clear that carriers seem quite concerned about their
individual customers messaging, in volume, to their subscribers, given the
abuse.


>
> There is also potential for future of Subject/call-reason to be more than
> just a text string.
>

I suspect that's best handled separately, once we have a clearer use case.
I don't think we can just stick this into call-reason without all kinds of
backwards-compatibility issues.


>
> I’m struggling a bit on your point that we should sign some data but not
> other data because it is less likely to be manipulated.  Is that the bar we
> should be striving for here? Seems to conflict with my understanding of
> some of the goals.
>

Maybe this indicates that we should be clearer on the goals. My take on the
value of STIR "classic" (for TNs) is that the main purpose of signing is to
make it clear who is responsible for the information provided - thus, the
whole discussion of A/B/C attestation. Indeed, the experience seems to
indicate that C-level attestation is actually a signal for a robocall,
i.e,. C-level calls are *more* likely to be robocalls than unsigned calls.
A/B/C obviously have the same cryptographic strength and all prevent
modification by third parties.

I don't think that carrier manipulation of the caller information (except
in various normalization ways) has ever been a major problem - it's
originator (OSP or end user) spoofing. This is rather different than the
typical threat model where the originator worries about evil Mallory
changing their data, e.g., by redirecting a money transfer to them.

But for call-purpose, this is less relevant - this is clearly (mostly)
useful if inserted by the originating caller, and unlike for A-level
attestation, the carrier can't really validate that the message is
truthful. How would it know that "You have won a cruise!" in the
call-purpose/Subject was correct or a scam? Indeed, as mentioned, if I were
a carrier, I'd never want to attest to that purpose, as somebody could
reasonably claim that the carrier should have known that the recipients
hadn't won anything.

This is the main reason that I think this should be a separate claim - if
anybody should sign/attest this, it's the enterprise call center and only
that call center.


> Why not have the framework that we can do that.  You are free to protect
> or not protect data depending on your own policy.
>

Nothing wrong as such. My argument is that RCD and call-purpose/Subject are
very different, so they shouldn't be in the *same* framework. If we need
Subject/call-purpose, they should be in separate claims, for the
operational reasons mentioned.


>
> I guess i want to be sure whether you are reacting to us not using Subject
> vs call-info as a common container for “rich call data” related info or
> that we have both call-info and ‘rcd’ as a container for Rich Call Data
> more generally?  I think there is many reasons why we landed there, we can
> re-hash that in the context of call-info vs subject.  I would be less
> excited about re-hashing it for passport/rcd.
>

For the reasons above, I think this is a bad idea for both cases, in
my view. It's worse for Call-Info, because of the duplication of existing
functionality.

To use an analogy: The RCD is mostly like a business card. We don't
typically write our contracts and messages on business cards - we might
staple our business card to a note.

My constructive suggestion is to create a separate claim if needed. (My
understanding is that rcd-14 does not contain the call purpose, so this is
the current state.)


>
> I do believe both of these frameworks need to be extensible, i don’t think
> we are finished.  We can define more passport extensions, but at the same
> time, do we want to redefine “rcd” and “rcdi” for new passport extensions?
>

No, we should create, in my view, a separate document that focuses on
signing the call purpose, expressed either as Subject (as the compact form)
or an explicit JWT claim, such as "subject".


> -Chris
>
>
>