Subject: [stir] Anonymous Calling

From: Eric Burger <[email-masked]>
Date: Sun, 19 Jul 2015 20:39:01 -0400

The certificates draft points out that one cannot do a rooted signature over “anonymous.invalid”. That is the suggested domain for anonymous calls per RFC 3261. That is nice, and one could argue that 4474bis does not eliminate anonymous calling. However, 4474bis gets into the policy world by stating first of all the service provider should sign, stating something like “[email-masked]”. However, that already leaks what could be significantly revealing information (think of “fbi.gov”).

The draft is close. I would offer the draft is more explicit in Section 4.2 to state that it is recommended that UAS behavior is to not reject unsigned requests if the request has an obviously anonymous From header.

For interoperability, it would be good to update 3261 to mandate “[email-masked]” (I am not tied to the string, so long as it is one and only one string) to indicate a universally anonymous identity. This is as opposed to [email-masked], which would always work because it is just a user. Anyway, it leaves [email-masked] available, which might be a real user or group of users.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 20 Jul 2015 08:07:15 +0000

Actually, the certificates draft doesn't talk about anonymity at all. I assume you mean rfc4474bis. 

The text in Section 9 (2nd and 3rd paragraph) that seems to be confusing you here talks about both the recommendations in RFC3323 and RFC3261. If you are using an RFC3323 anonymization service, you will have a URI with a valid host portion (which could theoretically be signed). If you are using anonymous.invalid as a host, as RFC3261 used, then obviously no service can or should sign it. But rfc4474bis in no way endorses one approach or the other, or in some other way veers into this nebulous realm of "policy." It merely explains how the signature mechanism would interact with either of this choices. 

Rereading that text, I don't think there any need to make that clearer. 

Jon Peterson
Neustar, Inc,

Sent from my iPad

> On Jul 20, 2015, at 2:39 AM, Eric Burger <[email-masked]> wrote:
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 20 Jul 2015 08:13:36 +0000

There are cases where anonymous should be signed

Sent from my iPhone

> On Jul 20, 2015, at 4:07 AM, Peterson, Jon <[email-masked]> wrote:
> 
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Jul 2015 10:24:35 +0200

Who is signing, and what are they attesting?

stir is supposed to be about making sure that the identifier in the From is delegated to the entity placing the call.  It is not “this is a call from a trusted party"

That would preclude anyone signing a call from anonymous.invalid because there is no delegation to anonymous.invalid

Brian

> On Jul 20, 2015, at 10:13 AM, DOLLY, MARTIN C <[email-masked]> wrote:
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 20 Jul 2015 08:30:49 +0000

Agreed, those are RFC3323 cases, where there is a signable domain. 4474bis allows that.

Jon Peterson
Neustar, Inc.

Sent from my iPad

---

From: <[email-masked]>
Date: Mon, 20 Jul 2015 11:05:00 +0200

Hi,
I do not understand the difference.

If you know the entity placing the From. Isn't this not also a kind of trust relationship? 

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: stir [mailto:[email-masked]] Im Auftrag von Brian Rosen
Gesendet: Montag, 20. Juli 2015 10:25
An: DOLLY, MARTIN C
Cc: [email-masked]; Jon Peterson
Betreff: Re: [stir] Anonymous Calling

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Jul 2015 11:13:56 +0200

It might be, but it’s not the trust relationship stir discusses.

If there is a domain delegated to the sender, and it can sign, then it works.  Any privacy service could do this, for example.  3323 shows a few other cases.

But not from anonymous.invalid, no one has that delegated to them.

Brian

> On Jul 20, 2015, at 11:05 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Hi,

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 20 Jul 2015 09:20:26 +0000

Then may be STIR is broken

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, July 20, 2015 5:14 AM
To: [email-masked]
Cc: DOLLY, MARTIN C; [email-masked]; Jon Peterson
Subject: Re: [stir] Anonymous Calling

Brian

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 20 Jul 2015 10:02:51 +0000

In baseline SIP, you can either claim an identity, or a pseudonym, or you can be anonymous in one of a few ways. STIR doesn't change that, it just explains how it interacts with those modes in SIP. So at worst, STIR is only as confused as SIP about all this. 

Jon Peterson
Neustar, Inc.

Sent from my iPad

> On Jul 20, 2015, at 11:20 AM, DOLLY, MARTIN C <[email-masked]> wrote:
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 20 Jul 2015 06:31:03 -0400

I agree with Brian: there is no need for anyone to say, “This is *really* an anonymous call.” I do not think anyone will be upset if their Caller ID displays “I think this is Anonymous” instead of “This is Really Anonymous”. Unless of course it is Anonymous calling, in which case that is a CNAM issue, not a STIR issue. <g>

No one who wants to lie about their identity is going to ‘forge’ Anonymous. This is one of those times when public policy does the right thing. We say we value letting people make anonymous calls. That’s *67 in the U.S. There is no need for anyone to attest the ‘identity’ in this case.

Moreover, signing Anonymous leaks the service provider (geography) or enterprise (which makes extracting identity even easier).

> On Jul 20, 2015, at 4:24 AM, Brian Rosen <[email-masked]> wrote:
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 20 Jul 2015 11:04:48 +0000

At the risk of reiterating the overall purpose of a privacy service as defined in RFC3323, let's point out that there are fields other than the From header field that can leak information about a user's location or identity - Via headers, Contacts, even elements of the SDP. Changing your From header to anonymous.invalid won't help protect you from those forms of leakage. Consequently, users may want to rely on services to provide some protections. Those services may in turn provide valid pseudonymous domains in the From header field values they generate. Is there a ton of value in those services signing for those domains? Perhaps not in most cases. Perhaps [email-masked] would have a different significance to verifiers (depending entirely on local policy) if it were signed than not. rfc4474 is not passing judgment on these questions - it is just saying that you can sign, as a privacy service. It's not forcing anyone to do so, or recommending this as superior to some other option.

Jon Peterson
Neustar, Inc,

Sent from my iPad

> On Jul 20, 2015, at 12:38 PM, Eric Burger <[email-masked]> wrote:
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 20 Jul 2015 07:07:46 -0400

We are in agreement, and you have a good point here. Unless you have S/MIME encrypted your SDP (you do do that, don’t you? :-), an eavesdropper will notice your SDP happens to have an IP address in AT&T’s address range, which might be a hint you are on AT&T’s network.

Nothing in the draft prohibits signing [email-masked]

> On Jul 20, 2015, at 7:04 AM, Peterson, Jon <[email-masked]> wrote:
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 20 Jul 2015 11:31:44 +0000

Part of the problem may be that we're talking about two kinds of anonymity:

(1) anonymous only to the called party (which is largely the PSTN behavior today)

(2) anonymous to the destination and intermediate carriers

An important use case is #1, where people would be more likely to accept anonymous calls if they were known not to be on a blacklist of nuisance callers (and, conversely, that the caller's anonymity may be breached by court order if the call turns out to be harassing, threatening or otherwise illegal).

As far as I can tell, the STIR mechanism supports version #1, but maybe the description can be clarified since the commonly-understood caller ID context of "anonymous" is not anonymous.invalid, but closer to the first case.

Henning
________________________________________
From: stir <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Monday, July 20, 2015 5:05 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Anonymous Calling

Hi,

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: stir [mailto:[email-masked]] Im Auftrag von Brian Rosen
Gesendet: Montag, 20. Juli 2015 10:25
An: DOLLY, MARTIN C
Cc: [email-masked]; Jon Peterson
Betreff: Re: [stir] Anonymous Calling

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Jul 2015 13:39:25 +0200

Perhaps I’m confused.  Are you saying that the call is placed with the actual identity in From, marked as private, and then the terminating service provider substitutes the identity with something else?  With respect to stir, as long as the termination service provider does the check of the signature before it does that, sure.

But I didn’t think it worked that way (public calling using SIP signaling) today.

Brian

> On Jul 20, 2015, at 1:31 PM, Henning Schulzrinne <[email-masked]> wrote:
> 
> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>>> On Jul 20, 2015, at 4:07 AM, Peterson, Jon <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>>> On Jul 20, 2015, at 2:39 AM, Eric Burger <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> The certificates draft points out that one cannot do a rooted signature over “anonymous.invalid”. That is the suggested domain for anonymous calls per RFC 3261. That is nice, and one could argue that 4474bis does not eliminate anonymous calling. However, 4474bis gets into the policy world by stating first of all the service provider should sign, stating something like “[email-masked] <mailto:[email-masked]>”. However, that already leaks what could be significantly revealing information (think of “fbi.gov <http://fbi.gov/>”).
>>>> 
>>>> For interoperability, it would be good to update 3261 to mandate “[email-masked] <mailto:[email-masked]>” (I am not tied to the string, so long as it is one and only one string) to indicate a universally anonymous identity. This is as opposed to [email-masked] <mailto:[email-masked]>, which would always work because it is just a user. Anyway, it leaves [email-masked] <mailto:[email-masked]> available, which might be a real user or group of users.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jul 2015 07:47:37 -0400

On 7/20/15 7:39 AM, Brian Rosen wrote:
> Perhaps I’m confused.  Are you saying that the call is placed with the
> actual identity in From, marked as private, and then the terminating
> service provider substitutes the identity with something else?  With
> respect to stir, as long as the termination service provider does the
> check of the signature before it does that, sure.
>

I thought that for this the call is made with anonymous in From and the 
actual id in P-Preferred/P-Asserted-ID. In that case I think it is the 
P-Asserted-ID that will be signed. And then before reaching the callee 
the P-Asserted-ID is removed. Presumably the signature will also be 
removed at that time.

	Thanks,
	Paul

> Brian
>
>> On Jul 20, 2015, at 1:31 PM, Henning Schulzrinne
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> An important use case is #1, where people would be more likely to
>> accept anonymous calls if they were known not to be on a blacklist of
>> nuisance callers (and, conversely, that the caller's anonymity may be
>> breached by court order if the call turns out to be harassing,
>> threatening or otherwise illegal).
>>
>> As far as I can tell, the STIR mechanism supports version #1, but
>> maybe the description can be clarified since the commonly-understood
>> caller ID context of "anonymous" is not anonymous.invalid, but closer
>> to the first case.
>>
>> Henning
>> From: stir <[email-masked] <mailto:[email-masked]>> on
>> behalf [email-masked]
>> <mailto:[email-masked]><[email-masked]
>> <mailto:[email-masked]>>
>> To:[email-masked] <mailto:[email-masked]>;[email-masked]
>> <mailto:[email-masked]>
>> Cc:[email-masked] <mailto:[email-masked]>;[email-masked]
>> <mailto:[email-masked]>
>> Cc: [email-masked] <mailto:[email-masked]>; Jon Peterson
>> stir is supposed to be about making sure that the identifier in the
>> From is delegated to the entity placing the call.  It is not “this is
>> a call from a trusted party"
>>
>> That would preclude anyone signing a call from anonymous.invalid
>> because there is no delegation to anonymous.invalid
>>
>> Brian
>>
>>
>>
>>>
>>>> On Jul 20, 2015, at 4:07 AM, Peterson, Jon <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>
>>>> The text in Section 9 (2nd and 3rd paragraph) that seems to be
>>>> confusing you here talks about both the recommendations in RFC3323
>>>> and RFC3261. If you are using an RFC3323 anonymization service, you
>>>> will have a URI with a valid host portion (which could theoretically
>>>> be signed). If you are using anonymous.invalid as a host, as RFC3261
>>>> used, then obviously no service can or should sign it. But
>>>> rfc4474bis in no way endorses one approach or the other, or in some
>>>> other way veers into this nebulous realm of "policy." It merely
>>>> explains how the signature mechanism would interact with either of
>>>> this choices.
>>>>
>>>>> On Jul 20, 2015, at 2:39 AM, Eric Burger
>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>
>>>>> The certificates draft points out that one cannot do a rooted
>>>>> signature over “anonymous.invalid”. That is the suggested domain
>>>>> for anonymous calls per RFC 3261. That is nice, and one could argue
>>>>> that 4474bis does not eliminate anonymous calling. However, 4474bis
>>>>> gets into the policy world by stating first of all the service
>>>>> provider should sign, stating something like “[email-masked]
>>>>> <mailto:[email-masked]>”. However, that already leaks what
>>>>> could be significantly revealing information (think of “fbi.gov
>>>>> <http://fbi.gov/>”).
>>>>>
>>>>> The draft is close. I would offer the draft is more explicit in
>>>>> Section 4.2 to state that it is recommended that UAS behavior is to
>>>>> not reject unsigned requests if the request has an obviously
>>>>> anonymous From header.
>>>>>
>>>>> For interoperability, it would be good to update 3261 to mandate
>>>>> “[email-masked] <mailto:[email-masked]>”
>>>>> (I am not tied to the string, so long as it is one and only one
>>>>> string) to indicate a universally anonymous identity. This is as
>>>>> opposed [email-masked] <mailto:[email-masked]>,
>>>>> which would always work because it is just a user. Anyway, it
>>>>> [email-masked]
>>>>> <mailto:[email-masked]>available, which might be a real
>>>>> user or group of users.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 20 Jul 2015 11:59:39 +0000

Yes. I believe we need to support that mode as otherwise "anonymous" calling essentially becomes "do not accept this call unless you love talking to fraudsters". This is already, largely, true for traditional caller ID where this is standard consumer advice. Many of the commercial robocall blocking services, whether hardware or Android apps, have anonymous call blocking as the default setting.

Interestingly, the Nomorobo filtering service does a version of this. They rely on simultaneous ringing (aka forking) and fork to an 800#, which delivers the calling number to the filtering service even if the caller has pressed *67.

I don't know how widely

Privacy: header

is implemented in SIP space.

________________________________
From: Brian Rosen <[email-masked]>
Sent: Monday, July 20, 2015 7:39 AM
To: Henning Schulzrinne
Cc: [email-masked]; [email-masked]; [email-masked]; Jon Peterson
Subject: Re: [stir] Anonymous Calling

Brian

On Jul 20, 2015, at 1:31 PM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

Henning
________________________________________
From: stir <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 20, 2015 5:05 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Anonymous Calling

Hi,

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: stir [mailto:[email-masked]] Im Auftrag von Brian Rosen
Gesendet: Montag, 20. Juli 2015 10:25
An: DOLLY, MARTIN C
Cc: [email-masked]<mailto:[email-masked]>; Jon Peterson
Betreff: Re: [stir] Anonymous Calling

Brian

On Jul 20, 2015, at 4:07 AM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

Jon Peterson
Neustar, Inc,

Sent from my iPad

On Jul 20, 2015, at 2:39 AM, Eric Burger <[email-masked]<mailto:[email-masked]>> wrote:

The certificates draft points out that one cannot do a rooted signature over “anonymous.invalid”. That is the suggested domain for anonymous calls per RFC 3261. That is nice, and one could argue that 4474bis does not eliminate anonymous calling. However, 4474bis gets into the policy world by stating first of all the service provider should sign, stating something like “[email-masked]<mailto:[email-masked]>”. However, that already leaks what could be significantly revealing information (think of “fbi.gov<http://fbi.gov/>”).

For interoperability, it would be good to update 3261 to mandate “[email-masked]<mailto:[email-masked]>” (I am not tied to the string, so long as it is one and only one string) to indicate a universally anonymous identity. This is as opposed to [email-masked]<mailto:[email-masked]>, which would always work because it is just a user. Anyway, it leaves [email-masked]<mailto:[email-masked]> available, which might be a real user or group of users.
_______________________________________________