Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

From: Dave Crocker <[email-masked]>
Date: Thu, 01 Aug 2013 09:06:51 +0200

On 8/1/2013 8:59 AM, Stephen Kent wrote:
> Dave,
>
> I refer you to the BGPSEC threat doc
> (draft-ietf-sidr-bgpsec-threats-05), which is now
> in the hands of the RTG ADs, as an example of what I have in mind. It
> addresses a
> fairly complex, global system, so I would not expect an analogous doc
> for STIR
> to be any longer.

ack. tnx for the reference. looks quite helpful.

this does suggest that it would be helpful for the secdir to produce 
some sort of template to guide us plebes in our efforts to pretend we 
can be competent in these exercises.

it might also increase the consistency of what different secdir and sec 
AD folk require from these exercises...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Richard Barnes <[email-masked]>
Date: Thu, 1 Aug 2013 09:26:34 +0200

On Thu, Aug 1, 2013 at 7:22 AM, Dave Crocker <[email-masked]> wrote:

> On 8/1/2013 12:25 AM, Richard Barnes wrote:
>
>> (In any event, I would encourage WG participants to keep in mind that
>> there will likely substantial overlap between the two solutions.
>> They both require a credential infrastructure and some sort of
>> authenticated object that attests to the validity of a call.  They
>> might only really differ in how the authenticated object is delivered
>> from originator to verifier.  So we might find that some of the first
>> things that are delivered are common to both solutions.)
>>
>
>
>
> Richard,
>
> The above text is, of course, an entirely reasonable line of thinking. It
> might even be correct, and for some approaches most certainly is.
>
> For others it isn't at all correct.
>
> The project management problem with what you've put forward is that any
> meaningful version of "keeping out-of-band in mind" while working on
> in-band effectively requires working on in-band and out-of-band
> simultaneously.
>
> That's fundamentally different from working with complete focus on in-band
> and only afterwards moving towards out-of-band.
>
> At every turn in considering choices for in-band, the implication of your
> statement is that people will be raising concerns for application to
> out-of-band.  That essentially requires working out the details of
> out-of-band simultaneously with in-band.
>
> This is quite contrary to what is usually meant in a charter about working
> on one thing and /then/ on another.
>
> A charter is supposed to help reconcile these sorts of potential sources
> of focus-confusion, rather than make them fuzzier.

That's why I didn't propose putting it in the charter :)  Obviously, we
will try to clarify this in the charter.

--Richard

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 Aug 2013 09:56:57 +0200

> will try to clarify this in the charter.

Color me even more confused than usual (and that's going some.)

Advice from the cognizant AD about what technical issues to "consider" 
when working is usually treated as definitive direction, absent an 
overriding appeal (which isn't ever requested, nevermind sustained.)

Perhaps you could respond to the substance of the concern I raised in my 
previous note?

d/

---

From: <[email-masked]>
Date: Thu, 1 Aug 2013 08:00:52 +0000

Richard,

Re you second point, you may want to have a look at the report that the European NRA working group (ECC) on numbering produced on "Increasing Trust in Calling Line Identification and Originating Identification" a few years ago but is still relevant. You'll find it at http://www.erodocdb.dk/docs/doc98/official/pdf/ECCRep133.pdf.  

As several interventions noted on Tuesday, including one from a European NRA, it isn't specific to +1. But I think those jurisdictions address the issue in the wider context of CLI trust, which broadly speaking falls into 3 categories in Europe and probably elsewhere 
a) The national robotcalling/vishing/swatting of the current charter 
b) What Henning referred to as "cross-border" and "out of scope" in his presentation (also referred to "numbering misuse" elsewhere)  
c) Questionable commercial CLI practices by the legitimate number assignee such as using premium rate numbers to generate return calls, for which a certified CLI won't help. 

Some countries have developed BCPs to tackle those recently. 

Slightly off-topic for a charter discussion, but I hope this helps. (unless you wanted to add something to this end in the preamble) 

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Wednesday, July 31, 2013 6:38 PM
To: 'Stephen Kent'; 'IETF STIR Mail List'
Subject: Re: [stir] Moving from BOF to Charter

I agree though as Lucy Lynch pointed out in calling out attention to the
privacy problem there may be an interesting dimension to this. When does the
right to privacy trump the right to be anonymous?  We are confronted with a
situation where a genuine perceived need for anonymous communications
identity for some has become a shield for criminal behavior.  

The other issue maybe ISOC can help us with this problem is we still don't
have an idea of the scope of the problem beyond North America.  Other
jurisdictions handle this differently and this is a perfect opportunity to
encourage national regulators to engage with the IETF/ISOC in investigating
these problems.

I would argue that what we are seeing in North America is the "Canary in the
Coal Mine".  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Wednesday, July 31, 2013 11:27 AM
To: [email-masked]
Subject: Re: [stir] Moving from BOF to Charter

Russ,

As I mentioned at the mic, I'd like to see both a threat model and a privacy
analysis as deliverables early in this process.

I also think we need to have a discussion about the size of the population
of calling parties who will have credentials, and the size of the verifiers
in the system. This seemed to be the source of some disagreement during the
BoF, and some proposals that might work well for small values of either (or
both) of these parameters might not work well for very large values of these
parameters.

The texts says:

As its first work item, the working group will specify a SIP header-based
authorization mechanism to verify the originator of a SIP session is
authorized to use the claimed source telephone number,

Should the "authorization" be "authentication" above. I agree with the use
of "authorized" in the latter part of the sentence.

later, the text says:

After completing the in-band mechanism, the working group will consider
session establishment where there are one or more non-SIP hops, most likely
using an out-of-band authorization mechanism.

Did you mean authorization or authentication here?

Steve
_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Gordon Lennox <[email-masked]>
Date: Thu, 1 Aug 2013 10:10:26 +0200

> identity for some has become a shield for criminal behavior.

The Council of Europe is an international organisation promoting co-operation between all countries of Europe in the areas of legal standards, human rights, democratic development, the rule of law and cultural co-operation. It is an entirely separate body from the European Union (EU). Nearly all European countries are in the CoE including Russia. But the US and Canada are also involved. Certain CoE conventions have been opened to signature by non-members. Canada, Japan, South Africa and the United States all signed the CoE Cybercrime Convention, for example.

About ten years ago the CoE Committee of Ministers adopted a Declaration on freedom of communication on the Internet.

That included:

"Principle 7: Anonymity

In order to ensure protection against online surveillance and to enhance the free expression of information and ideas, member states should respect the will of users of the Internet not to disclose their identity. This does not prevent member states from taking measures and co-operating in order to trace those responsible for criminal acts, in accordance with national law, the Convention for the Protection of Human Rights and Fundamental Freedoms and other international agreements in the fields of justice and the police."

I am sure there is more from the CoE on this.

Gordon

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 1 Aug 2013 04:29:17 -0400

Many thanks to you and Gordon for the interesting pointers.

Though our focus is unquestionably technical, it certainly helps to
understand the problem in context.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, August 01, 2013 4:01 AM
To: Richard Shockey; 'Stephen Kent'; 'IETF STIR Mail List'
Subject: RE: [stir] Moving from BOF to Charter

Richard,

Re you second point, you may want to have a look at the report that the
European NRA working group (ECC) on numbering produced on "Increasing Trust
in Calling Line Identification and Originating Identification" a few years
ago but is still relevant. You'll find it at
http://www.erodocdb.dk/docs/doc98/official/pdf/ECCRep133.pdf.  

As several interventions noted on Tuesday, including one from a European
NRA, it isn't specific to +1. But I think those jurisdictions address the
issue in the wider context of CLI trust, which broadly speaking falls into 3
categories in Europe and probably elsewhere
a) The national robotcalling/vishing/swatting of the current charter
b) What Henning referred to as "cross-border" and "out of scope" in his
presentation (also referred to "numbering misuse" elsewhere)
c) Questionable commercial CLI practices by the legitimate number assignee
such as using premium rate numbers to generate return calls, for which a
certified CLI won't help. 

Slightly off-topic for a charter discussion, but I hope this helps. (unless
you wanted to add something to this end in the preamble) 

Regards,

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
Richard Shockey

-----Original Message-----

Russ,

The texts says:

later, the text says:

Steve

____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 1 Aug 2013 11:06:19 +0200

> overriding appeal (which isn't ever requested, nevermind sustained.)

That's an overstatement.  To quote the Tao:
"Many people look at the ADs as somewhat godlike creatures ... However,
most ADs are nearly indistinguishable from mere mortals and rarely speak
from mountaintops."

More to the point, I didn't mean it that way.  That's why, for example, I
said "I would encourage..." and not "Thou shalt..."  I consider the charter
to be the real commitment.

> previous note?

I take this to mean your concern that my "keep in mind" suggestion would
encourage people to work on things in parallel rather than sequence.

The intent is actually the opposite, to help people get interested in
out-of-band more engaged in in-band.  If the in-band solution requires
parts (A,B,C) and out-of-band requires (A,B,D), then people interested in
out-of-band should be interested in A and B, and not just checked out of
the WG until in-band is done.

--Richard

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 Aug 2013 11:18:25 +0200

On 8/1/2013 11:06 AM, Richard Barnes wrote:
> On Thu, Aug 1, 2013 at 9:56 AM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
>     Advice from the cognizant AD about what technical issues to
>     "consider" when working is usually treated as definitive direction,
>     absent an overriding appeal (which isn't ever requested, nevermind
>     sustained.)

Philosphy first, then wg pragmatics...

> most ADs are nearly indistinguishable from mere mortals and rarely speak

The Tao is (correctly in my view) trying to counter some natural 
tendencies to assign that godlike status to ADs.  There was less 
reticence to beat the crap out of an AD (in strictly polite and virtual 
ways, of course) back when I was an AD, 20 years ago... but the IETF has 
become more like the real world, since then.

> More to the point, I didn't mean it that way.  That's why, for example,
> I said "I would encourage..." and not "Thou shalt..."  I consider the
> charter to be the real commitment.

Vint Cerf has an anecdote about a Colonel newly raised to General, who 
arrives at his first assignment, a military base.  The car stops in 
front of HQ and as he gets out, he looks nearby and mutters "oh, a fire 
hydrant."  At the end of the day, when he exits HQ to the car, he 
discovers that the hydrant has been removed.  From generals, any 
utterance carries import.  While many of us are less intimidated by 
those in lofty IETF positions that we perhaps should be, many others are 
more intimidated.

To the point: An AD asserting what amounts to engineering guidance at
the start of an effort -- especially when it pertains to an existing 
point of controversy amongst competent proponents on both sides -- 
strikes me as problematic to wg process, which is why I raised a 
concern.  I'm not in the least concerned about your or anyone else's 
motives; everyone wants good stuff to happen.  My concern is with the 
mere potential of constraining legitimate debate.

>     Perhaps you could respond to the substance of the concern I raised
>     in my previous note?
>
> out-of-band more engaged in in-band.

Oh.  Well, that's certainly a helpful goal, of course.  But yes, I read 
your note quite differently, and from assorted separate conversations, I 
fear others also might have.

> If the in-band solution requires
> parts (A,B,C) and out-of-band requires (A,B,D), then people interested
> in out-of-band should be interested in A and B, and not just checked out
> of the WG until in-band is done.

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Aug 2013 05:29:36 -0400

I think the concern, and I have it too, is that when one mixes oil and water in a working group there are likely to be (1) differing views of what's acceptable/not in terms of threats, deployment models and protocols, and operation/management of it, and (2) cases of contention for the same resources, such as vying for time in WG meetings.

My interpretation of the charter is that if such things happen, then in-band wins; once in-band is submitted to IESG, out-of-band gets all the time.  For now we can talk about both in mailing list, and of course people can continue to work on out-of-band, discuss it in WG meetings if there's time, etc.  And when we work on our documents we have to keep out-of-band in mind... although if we do find there're some big differences or more documentation work required due to out-of-band, then my assumption is we'd separate the out-of-band into separate docs to work on later.

-hadriel

On Aug 1, 2013, at 5:06 AM, Richard Barnes <[email-masked]> wrote:

> Advice from the cognizant AD about what technical issues to "consider" when working is usually treated as definitive direction, absent an overriding appeal (which isn't ever requested, nevermind sustained.)
> 
> "Many people look at the ADs as somewhat godlike creatures ... However, most ADs are nearly indistinguishable from mere mortals and rarely speak from mountaintops." 
> 
> More to the point, I didn't mean it that way.  That's why, for example, I said "I would encourage..." and not "Thou shalt..."  I consider the charter to be the real commitment.
> 
>  
> 
> Perhaps you could respond to the substance of the concern I raised in my previous note?
> 
> I take this to mean your concern that my "keep in mind" suggestion would encourage people to work on things in parallel rather than sequence.
> 
> The intent is actually the opposite, to help people get interested in out-of-band more engaged in in-band.  If the in-band solution requires parts (A,B,C) and out-of-band requires (A,B,D), then people interested in out-of-band should be interested in A and B, and not just checked out of the WG until in-band is done.
> 
> --Richard
> 
>  
> 
> 
> d/
> 
> 
> -- 
> Dave Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 1 Aug 2013 09:42:26 +0000

I think what's important are the points we discussed in the BoF: that
having both of these mechanisms under development in the same venue lets
us reuse critical components of the architecture, avoid duplication of
effort, and scope what falls under the purview of one approach or the
other. That means that we pursue in-band mindful of the fact that
out-of-band is coming, and yes, when defining reusable components, we
ideally find designs for them that will accommodate both in-band and
out-of-band.

Jon Peterson
Neustar, inc.

On 8/1/13 11:29 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>
>I think the concern, and I have it too, is that when one mixes oil and
>water in a working group there are likely to be (1) differing views of
>what's acceptable/not in terms of threats, deployment models and
>protocols, and operation/management of it, and (2) cases of contention
>for the same resources, such as vying for time in WG meetings.
>
>My interpretation of the charter is that if such things happen, then
>in-band wins; once in-band is submitted to IESG, out-of-band gets all the
>time.  For now we can talk about both in mailing list, and of course
>people can continue to work on out-of-band, discuss it in WG meetings if
>there's time, etc.  And when we work on our documents we have to keep
>out-of-band in mind... although if we do find there're some big
>differences or more documentation work required due to out-of-band, then
>my assumption is we'd separate the out-of-band into separate docs to work
>on later.
>
>-hadriel
>
>
>> I take this to mean your concern that my "keep in mind" suggestion
>>would encourage people to work on things in parallel rather than
>>sequence.
>>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 1 Aug 2013 09:49:19 +0000

I believe the FCC wants something will be deployed versus just placed on the IETF RFC shelf, never to see a deployment light of day....

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Thursday, August 01, 2013 5:42 AM
To: Hadriel Kaplan; Richard Barnes
Cc: IETF STIR Mail List; Russ Housley; Dave Crocker
Subject: Re: [stir] Including out-of-band in the Charter

Jon Peterson
Neustar, inc.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 1 Aug 2013 14:12:38 +0200

On Thu, Aug 1, 2013 at 11:29 AM, Hadriel Kaplan
<[email-masked]>wrote:

> what's acceptable/not in terms of threats, deployment models and protocols,
> and operation/management of it, and (2) cases of contention for the same
> resources, such as vying for time in WG meetings.
>
> time.  For now we can talk about both in mailing list, and of course people
> can continue to work on out-of-band, discuss it in WG meetings if there's
> time, etc.  And when we work on our documents we have to keep out-of-band
> in mind... although if we do find there're some big differences or more
> documentation work required due to out-of-band, then my assumption is we'd
> separate the out-of-band into separate docs to work on later.
>

Thanks, Hadriel.  That matches my thinking.

--Richard

---

From: Michael Hammer <[email-masked]>
Date: Thu, 1 Aug 2013 13:51:12 +0000

Richard S., one clarification.

By privacy below, I assume you mean the American concept of "the right to be
left alone", meaning not bothered by anonymous strangers calling you.

I wonder if the CoE covers that.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gordon Lennox
Sent: Thursday, August 01, 2013 4:10 AM
To: Richard Shockey; IETF STIR Mail List
Subject: Re: [stir] Moving from BOF to Charter

On 31 Jul, 2013, at 18:38, Richard Shockey <[email-masked]> wrote:

> I agree though as Lucy Lynch pointed out in calling out attention to 
> the privacy problem there may be an interesting dimension to this. 
> When does the right to privacy trump the right to be anonymous?  We 
> are confronted with a situation where a genuine perceived need for 
> anonymous communications identity for some has become a shield for
criminal behavior.

The Council of Europe is an international organisation promoting
co-operation between all countries of Europe in the areas of legal
standards, human rights, democratic development, the rule of law and
cultural co-operation. It is an entirely separate body from the European
Union (EU). Nearly all European countries are in the CoE including Russia.
But the US and Canada are also involved. Certain CoE conventions have been
opened to signature by non-members. Canada, Japan, South Africa and the
United States all signed the CoE Cybercrime Convention, for example.

About ten years ago the CoE Committee of Ministers adopted a Declaration on
freedom of communication on the Internet.

That included:

"Principle 7: Anonymity

In order to ensure protection against online surveillance and to enhance the
free expression of information and ideas, member states should respect the
will of users of the Internet not to disclose their identity. This does not
prevent member states from taking measures and co-operating in order to
trace those responsible for criminal acts, in accordance with national law,
the Convention for the Protection of Human Rights and Fundamental Freedoms
and other international agreements in the fields of justice and the police."

Gordon

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 1 Aug 2013 10:42:11 -0400

My question exactly ...  especially volations of the Do Not Call Lists.

Especially by the political class but alas that is not always possible.

Canada has a more enlightened view of this.

http://news.nationalpost.com/2013/07/26/ndp-mp-paul-dewar-slapped-with-7000-
fine-over-campaign-robocalls/

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Thursday, August 01, 2013 9:51 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [stir] Moving from BOF to Charter

Mike

-----Original Message-----

criminal behavior.

That included:

"Principle 7: Anonymity

Gordon

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 2 Aug 2013 06:09:26 +0200

On Jul 31, 2013, at 10:28 PM, Brian Rosen <[email-masked]> wrote:

> With respect to privacy, I think there are two principles we ought to explicitly agree to
> 1) Anonymous calls, as already defined in SIP standards will still work, which means they will not have a valid identiy
> 2) the mechanisms we design will not reveal any more information than a call without the mechanism would.

+1

I don't think either of these are fully reflected in the charter at present, but they should be. In particular, "This working group is not chartered to mandate the presence of
identity in SIP requests" makes it sound like it could be re-chartered in the future to do so. The second principle above is also stronger than "to the extent feasible [the WG] will find privacy-friendly solutions that leak minimal information about calls to third parties."

Alissa

> 
> The former is just some explici text that says the mechanism must not be applied to calls to with the anonymous From uri.  The latter may constrain the mechanisms some, but that is a good thing.
> 
> Brian
> 
> On Wednesday, July 31, 2013, Michael Hammer wrote:
> All,
> 
> For security, an assessment of the degree to which a called party can
> reasonably rely on the caller ID validation is in order.
> But, it should probably contain the warning to users to still not provide
> any sensitive information when they are not the calling party, to be safe.
> 
> While privacy is important, I believe that it could be secondary, because,
> if this is designed as an optional feature (user chooses what to assert and
> whether to sign or not)
> such considerations are in the realm of the supplementary features like CLIP
> and CLIR.
> The default may be to show and sign for the 99% with an opt-in to suppress
> for the corner cases that need it.
> Privacy could also be modeled as an over-ride feature that allows a party or
> carrier to substitute an anonymous signature.
> 
> Bottom line, privacy is a derivative of the caller ID function.
> 
> Clearly there needs to be balance between the calling and called parties.
> Called parties are going to have to learn to automatically or manually block
> calls.
> 
> Mike
> 
> 
> Sent: Wednesday, July 31, 2013 12:38 PM

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 3 Aug 2013 09:25:07 +0000

Clearly, we need to reflect strong privacy goals in the charter. I'm slightly concerned about the second statement as there could be conceivable cases where the certificate or public key reveals information about the caller's *carrier*, particularly if that carrier chooses to re-use public keys across customers, as appears likely (and generally beyond the control of the caller).

A narrow interpretation could essentially rule out any mechanism that we have discussed, so maybe something like "reveal any more personal information about the caller than a call" would address the concern without making the problem impossible to solve.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Alissa Cooper [[email-masked]]
Sent: Friday, August 02, 2013 12:09 AM
To: Brian Rosen
Cc: [email-masked]; Michael Hammer; [email-masked]; [email-masked]
Subject: Re: [stir] Moving from BOF to Charter

+1

Alissa

---

From: Russ Housley <[email-masked]>
Date: Mon, 5 Aug 2013 15:44:10 -0400

Steve and Lucy:

I have been thinking about your call for privacy document.

The privacy document is fairly straight forward if you only consider the use of a STIR credential in the in-band and an out-of-band mechanisms.  However, it gets much more complicated if one considers other potential uses (and abuses) of this credential in other protocol environments.  Do you have any thoughts on this?  Do you have proposed charter text?

Russ

On Jul 31, 2013, at 10:25 AM, Russ Housley wrote:

> With the BOF behind us, I think there is one, and only one topic that this mail list should be discussing.  That is the charter text that is ready for the IESG.
> 
> The pre-BOF charter text is here: http://www.ietf.org/charter/charter-ietf-stir-00-00.txt
> 
> I will hold the pen on changes to the charter text.  Some people suggested changes during the BOF:
> 
> Preamble
>   - Remove "deployable" or change it to "rapidly deployable"
>   - Add "within call set up time"
>   - Add a discussion of a threat model
>   - Be clear that the "calling party" is identified by their telephone number
> 
> Postamble
>   - Can something be said about alignment of incentives?
> 
> Privacy
>   - We need to do more than punt.
> 
> Please propose exact text for any of these topics.  I prefer one proposed change per message in a hope to more easily judge consensus.  To this end, I will start a thread on the inclusion of an out-of-band mechanism.
> 
> Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 5 Aug 2013 15:44:39 -0400

Steve:

I have been thinking about your call for a threat document and a privacy document.

The threat document is quite different if it cover an in-band mechanism or both an in-band and an out-of-band mechanism.  Do you have any thoughts on this?  Do you have proposed charter text?

Russ

On Aug 1, 2013, at 2:59 AM, Stephen Kent wrote:

> Dave,
> 
> I refer you to the BGPSEC threat doc (draft-ietf-sidr-bgpsec-threats-05), which is now
> in the hands of the RTG ADs, as an example of what I have in mind. It addresses a
> fairly complex, global system, so I would not expect an analogous doc for STIR
> to be any longer.
> 
> Steve

---

From: Russ Housley <[email-masked]>
Date: Mon, 5 Aug 2013 15:59:45 -0400

Steve Kent raised a question on the list about the population size.  I think we need to consider this question in the long-term.  That is after both the in-band and out-of-band mechanisms have been developed and deployed.

Steve said:  

> in the system. This seemed to be the source of some disagreement during the BoF,
> and some proposals that might work well for small values of either (or both)
> of these parameters might not work well for very large values of these parameters.

So, I'd like to hear what people think, and what impact this has on the charter text.

Russ

---

From: Dave Crocker <[email-masked]>
Date: Mon, 05 Aug 2013 22:29:47 +0200

> So, I'd like to hear what people think, and what impact this has on the charter text.

Throughout list discussion, there has been a split view that sounded to 
me like a difference between "permitted" and "likely".

Permitted has been cited as any calling handset, any calling enterprise 
and any calling provider, as well as any called provider, enterprise, or 
handset.  As populations counts go, that's probably best described as 
"everyone".

Likely has typically been described as calling and called providers, 
with perhaps some intermediaries, like SBCs.  That's a somewhat smaller 
population.

d/

---

From: Brian Rosen <[email-masked]>
Date: Mon, 5 Aug 2013 18:02:55 -0400

I would say, initial use of in band is service providers and perhaps large
enterprise.  Initial use of out of band is end devices.  In band expands to
smaller enterprises and eventually devices.  Out of band may have some
initial SP on-behalf-of use.

Brian

On Monday, August 5, 2013, Dave Crocker wrote:

>> Steve Kent raised a question on the list about the population size.  I
>> think we need to consider this question in the long-term.  That is after
>> both the in-band and out-of-band mechanisms have been developed and
>> deployed.
>>
>> Steve said:
>>
> Throughout list discussion, there has been a split view that sounded to me
> like a difference between "permitted" and "likely".
>
> Likely has typically been described as calling and called providers, with
> perhaps some intermediaries, like SBCs.  That's a somewhat smaller
> population.
>
> d/
>
>
> --
> Dave Crocker
> ______________________________**_________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/stir<https://www.ietf.org/mailman/listinfo/stir>
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Aug 2013 00:29:45 +0200

On 8/6/2013 12:02 AM, Brian Rosen wrote:
> I would say, initial use of in band is service providers and perhaps
> large enterprise.  Initial use of out of band is end devices.  In band
> expands to smaller enterprises and eventually devices.  Out of band may
> have some initial SP on-behalf-of use.

A phrase like "initial use" invites the distinction between architecture 
and operation.  That's why I made the 'permitted' vs. 'likely' 
distinction, so this issue is explicit.

Is the architecture to be restricted only to providers?  That seems to 
go against what has been said repeatedly on the list.  If not 
restricted, then the "permitted' population appears to be essentially 
everybody.

If there is a view that a restricted "initial" use has architectural 
import, while somehow permitting later expansion to the larger use case, 
what would that mean, specifically?

And I thought that out of band was to be deferred for now.

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 5 Aug 2013 19:26:24 -0400

> So, I'd like to hear what people think, and what impact this has on the charter text.

Why would this have impact on the charter text?

Brian gave some numbers before on the list:
> There are several billion telephone numbers.  I think most experts believe there are more assigned numbers than people.  
> There are 300-odd country codes
> There are a few tens of thousands of service providers.  If enterprises get some form of credential, there are potentially high tens of millions

The likely target sizes, imo, if we think this will be world-wide:
There are ~250 numbering authorities (cert CAs or PKI roots or whatever)
Signers are only service providers and big Enterprises = ~50,000 max signing organizations
Verifiers are only service providers and big Enterprises = ~50,000 max verifier organizations

If you're asking about number of signing/verifying physical *systems*, it's way more than 50k.

If the doctor's office scenario occurs and is done by the phone itself, there still aren't very many of those in practice, so it likely doesn't matter much.

It's possible that LTE mobile phones might do signing someday, in certain roaming cases.  It's possible they might do verifying as well.  If so, that would balloon things fast.  I don't think that's likely to happen though.

It's possible that one or more countries might impose requirements that Enterprises, or even LTE mobile phones, do both the signing and verifying - or at least that they be allowed to.  I can imagine a few countries in Europe doing that, for example.  If that happens, that would balloon things to many millions, of course.

The hard part with these things is we don't actually know the answer.  It's not hard to imagine new features one could enable were such a PKI available, and if that happens, all bets are off.  Some PSTN features people thought would be super-popular fizzled out (e.g., ISDN video), while other things that people thought would be minor became mega-hits instead (e.g., SMS and number porting).

-hadriel

---

From: Eric Burger <[email-masked]>
Date: Mon, 5 Aug 2013 16:36:55 -0400

What are the use cases and drivers?

My understanding is there are two flaws with the current SIP identity infrastructure. The first is the vast majority of 'calls' use E.164 (telephone number) addressing. Thus we address them with sip:+12345567890;user=phone or tel:+1234567890 URI's. The current SIP identity infrastructure does not handle anything but user@host identities. Therefore, there is nothing we can do today to assert the identity of a phone number in SIP.

The second flaw in the identity infrastructure we have today is asserted, authenticated identity does not survive passing through middle boxes and B2BUA's. This comes from a mix of today's scheme being MITM resistant by design and perhaps a bit overzealous in what is being protected. The problem is real networks out there have a lot of B2BUA's in them.

Complicating matters, we have the extremely complex, real world user rules that my device can forward calls from an authenticated sender and that call is supposed to have the authenticated origin of the authenticated sender (e.g., I am traveling and forward my desk phone to my mobile phone). The problem here is it is trivial for a bad actor to induce a good guy to call them so the bad actor can originate a call with the authenticated good guy as the caller identity.

Henning at the BOF gave a number of scenarios where the device needs to lie about its identity. For example, a doctor on the golf course or at home wants her outgoing caller identity to be that of her office, not her home or personal phone. Legitimate enterprises regularly contract with legitimate call centers to make outbound calls on the enterprise's behalf. In this case, the enterprise want's their own caller identity to pop up to their customer. They do not want to let the customer know they have outsourced their call center to Panama.

We then have the issue of deployment. Assuming we could get beyond the impossible real-world scenarios that say "prevent a MITM attack, yet design in a MITM attack" and "provide strong identity of the origination, yet allow the origin to lie about its identity," we have some other problems. If that were not enough!

So, what do we have before us? We have one camp arguing for a 'practical' solution that can address the robocalling problem. Since the robocalling problem is primarily a PSTN problem, they are arguing for a solution that is amenable to PSTN deployment. The PSTN handled this problem pre-VoIP by noting which ISDN PRI circuit lied about the Caller ID field. Since most networks were for somewhat trusted, one could trace back to the bad actor. It was usually an enterprise doing something not quite nice.

My understanding is today carriers doing IP interconnect do not bother to look at the Caller ID field. From an inter exchange carrier's (IXC's) perspective, there is no reason to. They are being paid by the carrier that delivers the call to them. The IXC does not route based on Caller ID, it routes based on dialed number. Note this is the identical situation that a backbone provider has delivering spam. The backbone provider has no reason to filter the mail, as they are being paid to deliver it. Likewise, where the mail comes from does not factor into the routing of the mail. Too bad for the poor individual or enterprise that gets a massive bill for premium service numbers or the carrier that gets hit with massive termination fees.

So, to address today's PSTN problem, we want to be able to allow a carrier to determine whom a call is really coming from. Then, once on the PSTN, the carrier can use all of the legacy PSTN heuristics to deal with Caller ID spoofing. That leads us to an in band solution, as the gateway that bridges to the VoIP world would be able to authenticate the caller's identity claim. This is relatively fast to deploy, as outbound enterprises would want to do uptake of the technology so they do not get blocked. The solution would be totally compatible with the existing Caller ID infrastructure, as carrier network equipment can hack the display number and name to their heart's content.

Of course, any legacy Caller ID solution could be trivially hacked by Caller ID spoofing, as the bad guy can just stuff the Caller ID fields with something that looks legitimate. In this case, the carrier can override the Caller ID markings if they do not pass authentication. This also means that when grandma calls her kids, her kids will see a toxic waste warning on their Caller ID screens. I do not think grandma will appreciate that, but since I am not a regulator, that is not my problem. Grandma is never going to upgrade her ATA. The good news is she will die in a few decades from never talking with her grand kids, and the problem of grandma not upgrading will just quietly pass away.

Did I mention that IXC's have no incentive, or reason for that matter, to look at the Caller ID fields? Just an observation.

So, if in band identity authentication is hard, why not do the easy thing and do out of band identity authentication? Let us again suspend belief and assume we can solve the very hard (impossible?) problems of simultaneously supporting no MITM attacks and must have MITM attacks as well as simultaneously imposting not being able to lie about identity at the same time that one must be able to lie about identity.

It is easy to upgrade a few billion cell phones to support an out of band scheme. Cell phones get cycled every two years or so, and governments and manufacturers will be very eager to mandate strong identity in the phone. There are lots of countries that require an identity card, passport, or even just a credit card to buy a phone or SIM card. Having the IETF endorse the practice of being able to cryptographically tie an endpoint to a physical identity would be nirvana for them. The problem here is grandma again. [Well, there is a small problem of privacy, but I recall someone in the BOF saying something akin to "screw privacy."] Most enterprises are running PBX equipment that is a decade or so old with corresponding software loads. Unless they are an outbound call center, they have no incentive to upgrade. Likewise, grandma still only has an analog Caller ID box, maybe connected to an ATA, but more likely connected to a DMS-10 with a VoIP gateway hanging off the trunk side. She is never going to have an endpoint that will do authentication of inbound caller identity. That means for there to be any penetration, carriers are going to have to install or upgrade their equipment to take their legacy Caller ID origination or Caller ID delivery to be out of band aware. Another way of putting it is they need to take out of band identity authentication and turn it into in band identity authentication for it to be useful. Sounds like an argument for in band…

One last comment. I had a micro exchange with Hadriel about the IETF punting on a PSTN-centric and totalitarian, police state-centric solution and give it to a body that is used to that sort of engineering, namely the ITU-T. The IETF can then focus on Internet-based, opt-in, privacy preserving solutions. The counter argument was that instead of SPIT, SWATing, and robocolls, look at how bad email spam mitigation is. The assertion is an Internet-based approach would be much worse for the user than a PSTN, government-driven approach.

I just looked at my SpamSieve statistics. I get 99.5% accuracy. I see 0.1% false positives (grandma going into spam jail) and 0.4% false negatives (+234 still making it into my inbox). For email, that is misrouting 5 messages per month. For voice, that would be something like four or five mishandled calls PER YEAR.

Sounds a lot better than the 2-3 spit calls I get per week.

---

From: Eric Burger <[email-masked]>
Date: Mon, 5 Aug 2013 16:36:40 -0400

I agree we are not looking at a national security private network analysis. However, we are talking about the potential end of any privacy or anonymity for ANY Internet application, more especially Internet multimedia application. That needs to have a level of analysis that goes beyond either "hopelessly broken" or "don't worry about it."

On Jul 31, 2013, at 12:30 PM, Dave Crocker <[email-masked]> wrote:

> On 7/31/2013 5:27 PM, Stephen Kent wrote:
>> As I mentioned at the mic, I'd like to see both a threat model and a
>> privacy analysis as deliverables early in this process.
> 
> +1
> 
> The only caveat I'll raise is based on a 'scoping' problem that happened for the threats exercise when the DKIM wg was being formed.  What we were initially asked for was a rather basic consideration of threats, to formulate some summary, pragmatic statements.
> 
> Within a few days, a few IETF security folk -- I don't recall Herr Kent's position on this -- attempted to turn this into a detailed exercise at a level of detail I was told would have been appropriate to a military security system.  Calling that onerous would entirely miss how unrealistic it would have been to attempt.

> 
> I thought the original request quite appropriate, since it would get everyone on the same page about some essential motivations and goals for the effort.  The result was a 25-page RFC.[1]  I've never been clear whether it was more work than reasonable, too little, or just right.
> 
> So I suggest some care in formulating these requirements, to keep it useful, quick and short.
> 
> 
>> I also think we need to have a discussion about the size of the
>> population of calling parties who will have credentials, and the size
>> of the verifiers in the system.
> 
> +1
> 
> 
> d/
> 
> 
> [1]  http://www.ietf.org/rfc/rfc4686.txt
> 
> 
> -- 
> Dave Crocker

---

From: Eric Burger <[email-masked]>
Date: Mon, 5 Aug 2013 16:37:27 -0400

If the IAB wants to look into it or if the IAB would like to ask ISOC to look into it, I am sure the IAB will look into it or ask ISOC to look into it.

In the shameless self promotion department, I know a professor of government who is a real lawyer (i.e., NOT me) who can do the work, for a small fee.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 6 Aug 2013 00:28:33 +0000

I vote for a gazillion.

We could just say it needs to operate at Internet scale and move on.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Monday, August 05, 2013 7:26 PM
To: Russ Housley
Cc: IETF STIR Mail List
Subject: Re: [stir] Population Size

>> of the verifiers in the system. This seemed to be the source of some 
>> disagreement during the BoF, and some proposals that might work well 
>> for small values of either (or both) of these parameters might not work
well for very large values of these parameters.

Brian gave some numbers before on the list:
> There are several billion telephone numbers.  I think most experts believe
there are more assigned numbers than people.  
> There are a few tens of thousands of service providers.  If 
> enterprises get some form of credential, there are potentially high 
> tens of millions

The likely target sizes, imo, if we think this will be world-wide:
There are ~250 numbering authorities (cert CAs or PKI roots or whatever)
Signers are only service providers and big Enterprises = ~50,000 max signing
organizations Verifiers are only service providers and big Enterprises =
~50,000 max verifier organizations

If you're asking about number of signing/verifying physical *systems*, it's
way more than 50k.

If the doctor's office scenario occurs and is done by the phone itself,
there still aren't very many of those in practice, so it likely doesn't
matter much.

It's possible that LTE mobile phones might do signing someday, in certain
roaming cases.  It's possible they might do verifying as well.  If so, that
would balloon things fast.  I don't think that's likely to happen though.

It's possible that one or more countries might impose requirements that
Enterprises, or even LTE mobile phones, do both the signing and verifying -
or at least that they be allowed to.  I can imagine a few countries in
Europe doing that, for example.  If that happens, that would balloon things
to many millions, of course.

The hard part with these things is we don't actually know the answer.  It's
not hard to imagine new features one could enable were such a PKI available,
and if that happens, all bets are off.  Some PSTN features people thought
would be super-popular fizzled out (e.g., ISDN video), while other things
that people thought would be minor became mega-hits instead (e.g., SMS and
number porting).

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 06:50:32 -0400

On Aug 5, 2013, at 4:36 PM, Eric Burger <[email-masked]> wrote:

> I agree we are not looking at a national security private network analysis. However, we are talking about the potential end of any privacy or anonymity for ANY Internet application, more especially Internet multimedia application.

How so?  Obviously we could theoretically create some mechanism that took all call information from/to everyone and posted it to wikileaks or 
whatever, but I don't think we're that stupid. (nor do I think it would get published by the IETF, nor would anyone use it if we did)

No one is proposing, for example, that anonymous calls no longer remain anonymous.  Nor that one can't make anonymous calls.

Your statement seems a bit alarmist.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 09:47:17 -0400

[You sent a long email, so responding will be a long email...]

General comment:
Many of the points you raise, and your arguments for/against, have been raised before and answered - and answered sufficiently such that there appears to be continuing interest in solving it per the current charter, here in the IETF.  Given the number of emails on this mailing list, it's not a surprise that we get the same questions again and again, because it's not reasonable to expect people to read all the emails from day 1.  I think we're going to need to write up a FAQ somewhere - either in a draft or on a wiki somewhere, so we can point people to it and say "RTFM".

Regarding motivations of carriers:
Many of us wouldn't be wasting our time with STIR if we didn't think carriers had motivation for deploying it, including IXCs.  In the most pessimistic view, the motivation might purely be due to government mandates.  Governments do in fact issue and enforce requirements on telephone-service carriers, including IXCs, as you well know.  I happen to take a more optimistic view, and think the carriers have other motivations, but it's not necessary to believe that.

Regarding what STIR is about:
You seem to be under the belief that STIR is about preventing "spam", by which I think you mean telemarketing calls.  It's not.  STIR by itself is not sufficient to stop telemarketing calls, nor is that our chartered goal.  Not only do IXCs have an incentive to allow telemarketing calls, as you point out, and arguably carriers are legally required to accept such calls, but also decisions about such are regulated at a national level differently per country, and ultimately require whitelists/blacklists anyway.  The goal of STIR is, in the long run, to prevent "lying" about the source number, as you put it.

Regarding support for legitimate "lying":
You said that the doctor phone and call-center scenarios required us to support lying.  They don't really, and I think we explained why they don't in the BOF.  They do require third-party authorization, in a fashion, and I agree that will make the solution more challenging to deploy.  The good news is these cases aren't as common as one would think - they're common, for sure, but in the grand scheme of things it's actually a very small population that does this today, compared to the number of users.  It may grow a lot in the future, but that's why we need an automated mechanism for accomplishing it, and we've discussed specifying such a mechanism.

Regarding whether to do this in the IETF or ITU:
Of course we could do this stuff elsewhere.  In fact, there was some off-line discussion about whether to go to 3GPP or ETSI/ATIS instead of IETF, due to the impedance mismatch of in-band vs. out-of-band in the WG.  I still feel the IETF is the best place to do this work, for many reasons, but obviously if we fail to make progress quickly then the motivation to go elsewhere increases.  If your goal is to have that happen, I'd ask why, because it's not like we force you to participate in STIR.  You may think we're wasting our time, but we're not forcing you to waste *your* time.  For example I've never objected to working groups such as VIPR or P2PSIP being created - I felt they were a complete waste of time, but not *my* time, only the time of the people involved in it... and of course I could be wrong about it being a waste of time.  If people want to go work on something they think will be useful, that's their decision.  That's why I argued in-band and out-of-band should be split apart into separate working groups, because some folks in each camp thinks doing the other is a waste of their time.

Regarding needing to support and prevent MITM:
In the general malicious MITM sense, I believe there's consensus that MITM attacks are not a threat we need to protect against.  We do, though, need to constrain the scope of assertions such that an organization can only lie about its own numbers (ie, can only claim a call from/through its domain is from a number it can use).  And obviously an IXC can simply remove STIR info if it wishes to - but if that happens then governments will eventually get involved.  I agree there is a challenge with call-forwarding scenarios, as I've said many times in both drafts and emails, but I think there are some ideas of how to handle it.

Regarding the apparent success of email spam filters:
I'm sure we all have different experiences, but since you raised your own... I have 3 email accounts: 2 corporate (Acme+Oracle), one personal (Yahoo).  I spend every morning deleting ~30 spam emails on average from my inboxes, and throughout the day I delete another ~30 on average.  This is not counting emails I just don't care about, nor counting the emails that get filtered by spam filters.  I have no idea what that is on a percentage basis (I get a lot of emails), but I don't think percentages mean anything.  The senders of spam don't limit their volume to a percentage of all emails their targets get.  In other words, if you get 5 spam emails a day, you will get 5 spam emails a day regardless of how many non-spam emails you get.  Also, I don't use SpamSieve (perhaps I should!), but I believe it uses Bayesian analysis of email *content* to detect spam - and *content* is something we don't have with call request signaling.  Real-time communication makes it a lot harder to detect spam, for obvious reasons.

-hadriel

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 06 Aug 2013 10:41:16 -0400

It might be worth considering how Art. 5  requirements
of the EU Data Retention Directive will be met.
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:105:0054:0063:EN:PDF
See also
http://ec.europa.eu/dgs/home-affairs/what-we-do/policies/police-cooperation/data-retention/index_en.htm

Most jurisdictions have equivalent requirements.

-t

---

From: Dan York <[email-masked]>
Date: Tue, 6 Aug 2013 14:42:18 +0000

So I feel compelled to reply to this point...

On 8/6/13 9:47 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>You said that the doctor phone and call-center scenarios required us to
>support lying.  They don't really, and I think we explained why they
>don't in the BOF.  They do require third-party authorization, in a
>fashion, and I agree that will make the solution more challenging to
>deploy.  The good news is these cases aren't as common as one would think
>- they're common, for sure, but in the grand scheme of things it's
>actually a very small population that does this today, compared to the
>number of users.  It may grow a lot in the future, but that's why we need
>an automated mechanism for accomplishing it, and we've discussed
>specifying such a mechanism.

I am not so sure that this is a "very small population that does this
today" and I also want to emphasize that this is far more than just
doctors and call-centers. Prior to joining the Internet Society almost two
years ago, I spent four years working for Voxeo, a company that provides
an application platform that among its many uses can enable a wide range
of outbound calling applications.  Companies would build applications on
platforms such as Voxeo's (and other competitor's) and then sell them out
to customers.  Among the applications I remember hearing about (on Voxeo's
platform and other platforms) were:

- MANY school systems using outbound notification systems for
weather-related issues ("no school due to snow"), upcoming events/games,
emergency issues (ex. school shootings), etc. I remember hearing of at
least one case where there were *daily* calls going home to parents
indicating whether Johnny was in school and what Johnny's homework was.

- Communities using outbound notification systems to alert people to
emergencies in the region, including weather and crime events.

- Pharmacies using automated calls to alert people that prescriptions were
ready.

- Banks using automated calls as part of a security system to call back a
number. 

- Debt collection calls.

- Companies using outbound apps to do pre-screening as part of an
interview process (and sometimes quite a lengthy process).

- Customer service surveys

- Problem resolution updates (ex. a call saying a service has been
restored)

- Invitations to events with the ability to RSVP within the call

- Confirmation calls from various services (ex. doctors, dentists, auto
services) asking me to confirm whether I am going to be at my designated
appointment

- Online games that have used outbound calls as part of the experience
(One that I played that was related to a movie was kind of spooky in how
it called you to ask you questions... and then used your (recorded)
answers against you later in the game!)

And I could keep on going and going...  I think I heard of a ski area
making daily calls out with ski conditions!    Some of these that I listed
might be thought of as a "call center" app, but others are people trying
new and different ways of playing with outbound telephony.   And I can say
that with my previous employer there were some very large customers with
VERY large outbound calling volumes.

The point is that these are increasingly common types of calls to receive.
 We probably receive 1-2 of these calls each week here at my house, either
to confirm appointments or to be notified of prescriptions. I also
routinely get calls from airlines when traveling.  Once school starts up
I'll be getting occasional automated calls related to our kids' classes
and events.

Yes, you could say these are "robocalls"... but they are robocalls that
**I want to receive**.  I have either signed up for the service or allowed
them to call me.

Now, many of these calls may be implemented by the calling entity from
within their own phone network and therefore can have their origin easily
identified as being from that company.    But many other calls may be
implemented by any of these providers of "cloud" application platforms...
and there are now MANY such "communications applications platforms" who
will perform this outbound calling on your behalf.

In some of those cases, maybe the entity who wants the calls done doesn't
care about what Caller ID is on the call. But in many of the cases the
entity will want the Caller ID to be *their* ID, either to help the called
party believe the call is legit or because the caller may want to hide the
fact that they are using some other service to deliver the actual outbound
call.

So beyond simply doctors' seeking to display their office number when
calling from other lines - and all the "traditional" call-center outbound
calling, there are a very wide range of applications out there that are
now being deployed to provide more efficient customer service or to enable
new experiences.

We *do* need to account for these type of use cases in creating a system
of secure origin authentication for IP communications.  And yes, I know
we've discussed this... but I cringe every time I see someone dismissing
this use case as less common or only done by a small number of people.

Dan

---

From: Michael Hammer <[email-masked]>
Date: Tue, 6 Aug 2013 14:48:29 +0000

Yes, but that doesn't mean you have to lie about the true originator of the
call separate from what to display on caller ID or what to provide as a
call-back number.
Many of the problems arise from conflating multiple purposes into the same
field.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
York
Sent: Tuesday, August 06, 2013 10:42 AM
To: Hadriel Kaplan; Eric Burger
Cc: IETF STIR Mail List
Subject: [stir] Legitimate uses of third party Caller ID authorization /
spoofing for outbound calling - Re: What are we trying to do, and where do
we want to end up?

On 8/6/13 9:47 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>number of users.  It may grow a lot in the future, but that's why we 
>need an automated mechanism for accomplishing it, and we've discussed 

I am not so sure that this is a "very small population that does this today"
and I also want to emphasize that this is far more than just doctors and
call-centers. Prior to joining the Internet Society almost two years ago, I
spent four years working for Voxeo, a company that provides an application
platform that among its many uses can enable a wide range of outbound
calling applications.  Companies would build applications on platforms such
as Voxeo's (and other competitor's) and then sell them out to customers.
Among the applications I remember hearing about (on Voxeo's platform and
other platforms) were:

- MANY school systems using outbound notification systems for
weather-related issues ("no school due to snow"), upcoming events/games,
emergency issues (ex. school shootings), etc. I remember hearing of at least
one case where there were *daily* calls going home to parents indicating
whether Johnny was in school and what Johnny's homework was.

- Debt collection calls.

- Companies using outbound apps to do pre-screening as part of an interview
process (and sometimes quite a lengthy process).

- Online games that have used outbound calls as part of the experience (One
that I played that was related to a movie was kind of spooky in how it
called you to ask you questions... and then used your (recorded) answers
against you later in the game!)

The point is that these are increasingly common types of calls to receive.
 We probably receive 1-2 of these calls each week here at my house, either
to confirm appointments or to be notified of prescriptions. I also routinely
get calls from airlines when traveling.  Once school starts up I'll be
getting occasional automated calls related to our kids' classes and events.

Yes, you could say these are "robocalls"... but they are robocalls that **I
want to receive**.  I have either signed up for the service or allowed them
to call me.

Now, many of these calls may be implemented by the calling entity from
within their own phone network and therefore can have their origin easily
identified as being from that company.    But many other calls may be
implemented by any of these providers of "cloud" application platforms...
and there are now MANY such "communications applications platforms" who will
perform this outbound calling on your behalf.

So beyond simply doctors' seeking to display their office number when
calling from other lines - and all the "traditional" call-center outbound
calling, there are a very wide range of applications out there that are now
being deployed to provide more efficient customer service or to enable new
experiences.

We *do* need to account for these type of use cases in creating a system of
secure origin authentication for IP communications.  And yes, I know we've
discussed this... but I cringe every time I see someone dismissing this use
case as less common or only done by a small number of people.

Dan

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Aug 2013 17:07:12 +0200

+1

On 8/1/13 2:12 PM, Richard Barnes wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     I think the concern, and I have it too, is that when one mixes oil
>     and water in a working group there are likely to be (1) differing
>     views of what's acceptable/not in terms of threats, deployment
>     models and protocols, and operation/management of it, and (2) cases
>     of contention for the same resources, such as vying for time in WG
>     meetings.
>
>     in-band wins; once in-band is submitted to IESG, out-of-band gets
>     all the time.  For now we can talk about both in mailing list, and
>     of course people can continue to work on out-of-band, discuss it in
>     WG meetings if there's time, etc.  And when we work on our documents
>     we have to keep out-of-band in mind... although if we do find
>     there're some big differences or more documentation work required
>     due to out-of-band, then my assumption is we'd separate the
>     out-of-band into separate docs to work on later.
>
>
>      > "Many people look at the ADs as somewhat godlike creatures ...
>     However, most ADs are nearly indistinguishable from mere mortals and
>     rarely speak from mountaintops."
>      >
>      > More to the point, I didn't mean it that way.  That's why, for
>     example, I said "I would encourage..." and not "Thou shalt..."  I
>     consider the charter to be the real commitment.
>      >
>      >
>      >
>      > I take this to mean your concern that my "keep in mind"
>     suggestion would encourage people to work on things in parallel
>     rather than sequence.
>      >
>      > The intent is actually the opposite, to help people get
>     interested in out-of-band more engaged in in-band.  If the in-band
>     solution requires parts (A,B,C) and out-of-band requires (A,B,D),
>     then people interested in out-of-band should be interested in A and
>     B, and not just checked out of the WG until in-band is done.
>      >
>      > --Richard
>      >
>      >
>      >
>      >
>      > d/
>      >
>      >
>      > --
>      > Dave Crocker
>      > bbiw.net <http://bbiw.net>
>      >
>      > [email-masked] <mailto:[email-masked]>

---

From: Dan York <[email-masked]>
Date: Tue, 6 Aug 2013 15:21:01 +0000

Mike,

>call separate from what to display on caller ID or what to provide as a

Sure... but the reality is that if we have a field providing origin
identification it will probably be used for both.

>Many of the problems arise from conflating multiple purposes into the same

Perhaps we need to be more clear on who is the consumer of the field(s) we
are creating:

- Are we trying to help consumers know who is calling them?
- Are we trying to help carriers / service providers be able to track and
potentially block calls?
- Are we trying to do both?

Dan

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Aug 2013 08:23:02 -0700

Russ,

No doubt it's my naivete about the technical side of security work, but 
it isn't obvious to me why your assertion is correct.  Please explain 
the nature of the differences that you see.

By way of example, imagine an out-of-band mechanism that merely takes 
the in-band signature and stashes it somewhere, much like a cookie 
mechanism.  The storage environment can see the retrieval attributes in 
the clear -- the same as any other transit handling node -- I suppose, 
but the rest of the information won't be accessible to it.

Nevermind that, even before we have the charter saying that out-of-band 
is to be deferred, we have yet-another introduction of it into initial 
technical discussions.

d/

---

From: Michael Hammer <[email-masked]>
Date: Tue, 6 Aug 2013 15:26:22 +0000

All of them.

-----Original Message-----
From: Dan York [mailto:[email-masked]] 
Sent: Tuesday, August 06, 2013 11:21 AM
To: Michael Hammer; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Legitimate uses of third party Caller ID authorization /

Mike,

On 8/6/13 10:48 AM, "Michael Hammer" <[email-masked]> wrote:

>Yes, but that doesn't mean you have to lie about the true originator of 
>the call separate from what to display on caller ID or what to provide 
>as a call-back number.

>Many of the problems arise from conflating multiple purposes into the 
>same field.

Dan

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 6 Aug 2013 11:58:06 -0400

[RS> ]  IMHO all of them as Hammer points out.  We need both the hammer and
the chain saw.   We need to ultimately track the origin. The SIP/PSTN
gateway case is going to be more challenging but that is a totally
orthogonal issue.  I'm sorry to harp on this but legitimate use of anonymity
cannot be used to shield criminal fraud.   That is of course another problem
but they are interrelated.  I'm not tracking INSIPID but I'm disturbed that
some folks are talking about modifying its intended use case. 

Dan

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 12:28:40 -0400

Somehow I knew someone would object to that. :) 

I recognize there are a CRAP-LOAD of perfectly legitimate, good-and-wholesome automated outbound dialers.  But the only ones that matter in the "we need to let people lie about their number" context, are the ones who need to legitimately represent a number other than one they were assigned through the normal number assignment process.  If a bank generates automated outbound calls, and does so from a system they control, there's no problem.  The challenge is to allow them to authorize such calls from a system they don't directly control - such as an outsourcing company - whether that be a call-center or cloud-based service or whatever.

There are a LOT of those folks too.  And obviously we MUST support such use-cases - no one's ever claimed we wouldn't need to handle it, and handle it in such a way that those outsourcing companies could generate STIR-validated calls for those source identities.  We've even talked about how that could work, with authorization in either an IP-based automated protocol manner, or even with faxed documents or carrier pigeons.

The reason I said it "will make the solution more challenging to deploy", is because today those folks don't even have to send faxes or carrier pigeons; so it requires those folks to do something new, no matter how much or little effort it may be.

So my point was: the good news is it's not like the number of folks who have to do something new is 7 Billion.  Compared to the number of users in the system world-wide, it's a small population that has to do something new.  My guess is it's in the same ballpark of 50k... or 100k, or 200k, or it may well be in the 1 million for all I know... but still compared to 7 Billion it's a small population.

But in a separate email I also tried to explain that coming up with these numbers is a bit dangerous.  When new things are enabled, they sometimes take on a life of their own, and expand at surprising rates.  For example, most people didn't think number portability would be as popular is it turned out to be.  They didn't realize that the lack of number portability before-hand was creating a self-fulfilling statistic of few people changing carriers; once number portability was possible, people started switching carriers in droves.  Likewise it's possible that deploying source identity validation on a large scale in carriers, might enable uses of E.164 numbers as identities in ways we haven't foreseen, resulting in a very different usage pattern. (I can think of several ways that could happen)

Having said that, obviously we also have to be careful not to over-engineer and produce a solution which doesn't address the existing problem in a way the existing stake-holders can use it in the world we live in today.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 12:54:07 -0400

On Aug 6, 2013, at 11:58 AM, "Richard Shockey" <[email-masked]> wrote:

> I'm sorry to harp on this but legitimate use of anonymity
> but they are interrelated.  

I'm hoping we'll be ok on that topic.  I don't really equate STIR with tracking the bad guys down - I mean even STIR doesn't tell you where they came in from, and truly bad guys would just not sign their stuff using STIR anyway.  You can generate all the anonymous calls you want, but even today we can eventually track them down.  It's a major PITA because it requires going carrier-by-carrier comparing numerous CDR records and system logs, but it is doable and is actually performed.  

We've talked about providing something to help track stuff back (the header list of SPIDs idea), but it's kinda orthogonal to the current STIR deliverables.  ISTM we can add it as a milestone later if we want to.  That one would have some odd privacy implications, and need careful consideration, but I think it's possible to do.

> I'm not tracking INSIPID but I'm disturbed that

We have a very hard time doing things in RAI for purely operational-improvement purposes.  We want new features we can sell, instead. (and I include myself in that general problem too)

It's ok though - even with a different Session-ID value per domain, but consistent within portions of the domain, will make back-tracking easier.  End-to-end Session-ID was never going to avoid having to look at CDR records to back-track, anyway... just reduce how many CDRs you have to look at.  It didn't, for example, tell you what carriers the request came in from/through.

-hadriel

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Aug 2013 13:12:49 -0400

Dave:

> No doubt it's my naivete about the technical side of security work, but it isn't obvious to me why your assertion is correct.  Please explain the nature of the differences that you see.
> 
> By way of example, imagine an out-of-band mechanism that merely takes the in-band signature and stashes it somewhere, much like a cookie mechanism.  The storage environment can see the retrieval attributes in the clear -- the same as any other transit handling node -- I suppose, but the rest of the information won't be accessible to it.
> 
> Nevermind that, even before we have the charter saying that out-of-band is to be deferred, we have yet-another introduction of it into initial technical discussions.

The threat environment for in-band is simpler; it contains fewer entities to consider in the analysis.

The threat environment for out-of-band is more complex; it contains all of the entities in the in-band case as well as SBCs and PSTN entities.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Aug 2013 13:17:01 -0400

I have gathered the comments that I have seen so far regarding the privacy paragraph of the charter, and I have updated that paragraph:

   Authentication and authorization of identity is closely linked to
   privacy, and these security features frequently come at the cost of
   privacy.  Anonymous calls are already defined in SIP standards, and this
   working group will not eliminate this capability.  Of course, anonymous
   call will not have a valid identity.  This working group, to the extent
   feasible, will specify privacy-friendly mechanisms do not reveal any more
   information to third parties than a call that does not make use of these
   mechanisms.

I hope this is better than the "punt" that was in the version discussed at the BOF.

Does it capture enough?  Does it go to far?

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Aug 2013 18:22:36 +0100

Wordsmithing suggestions below.

>    working group will not eliminate this capability.  Of course, anonymous

s/anonymous/an anonymous.

>    call will not have a valid identity.  This working group, to the extent

s/valid/verifiable/ (anon is "valid" but you just can't check it really)

>    feasible, will specify privacy-friendly mechanisms do not reveal any more

s/do/that do/

>    information to third parties than a call that does not make use of these

"extent feasible" is a bit of a punt still though, since we know that
the signature and the TN are likely to allow a verifier to infer more
about the caller's service provider(s) than just the TN.

But I'd be ok with it,
S.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 6 Aug 2013 17:39:06 +0000

We need to keep focus on support of whitelist capability.
Doing black listing has always been a goose chase.

SWATing should never be allowed from an anonymous caller.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Tuesday, August 06, 2013 12:54 PM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [stir] Legitimate uses of third party Caller ID authorization /
spoofing for outbound calling - Re: What are we trying to do, and where do
we want to end up?

> but they are interrelated.  

I'm hoping we'll be ok on that topic.  I don't really equate STIR with
tracking the bad guys down - I mean even STIR doesn't tell you where they
came in from, and truly bad guys would just not sign their stuff using STIR
anyway.  You can generate all the anonymous calls you want, but even today
we can eventually track them down.  It's a major PITA because it requires
going carrier-by-carrier comparing numerous CDR records and system logs, but
it is doable and is actually performed.  

We've talked about providing something to help track stuff back (the header
list of SPIDs idea), but it's kinda orthogonal to the current STIR
deliverables.  ISTM we can add it as a milestone later if we want to.  That
one would have some odd privacy implications, and need careful
consideration, but I think it's possible to do.

> I'm not tracking INSIPID but I'm disturbed that some folks are talking 
> about modifying its intended use case.

We have a very hard time doing things in RAI for purely
operational-improvement purposes.  We want new features we can sell,
instead. (and I include myself in that general problem too)

It's ok though - even with a different Session-ID value per domain, but
consistent within portions of the domain, will make back-tracking easier.
End-to-end Session-ID was never going to avoid having to look at CDR records
to back-track, anyway... just reduce how many CDRs you have to look at.  It
didn't, for example, tell you what carriers the request came in
from/through.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 13:41:57 -0400

> about the caller's service provider(s) than just the TN.

I agree that *would* be a problem, and I think (hope?) we're all aware we have to be careful about that, but I get confused about what it has to do with charter text?  Or let me put it another way - enumerating all applicable privacy considerations in text in a charter won't help.  We need a section for this in the requirements or solutions doc, or a separate doc for it.  Agree?

-hadriel

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Aug 2013 18:49:16 +0100

On 08/06/2013 06:41 PM, Hadriel Kaplan wrote:
>> "extent feasible" is a bit of a punt still though, since we know
>> that the signature and the TN are likely to allow a verifier to
>> infer more about the caller's service provider(s) than just the
>> TN.
> 
> I agree that *would* be a problem, and I think (hope?) we're all
> aware we have to be careful about that, but I get confused about what
> it has to do with charter text?  Or let me put it another way -
> enumerating all applicable privacy considerations in text in a
> charter won't help.  We need a section for this in the requirements
> or solutions doc, or a separate doc for it.  Agree?

I agree that enumerating privacy issues in the charter would be
a bad plan.

Nonetheless, the current text seems to mean "...to the extent
feasible (but we know its not really feasible) will specify
privacy friendly..." except we've left out the parenthetical.

S.

> 
> -hadriel
> 
> _______________________________________________ stir mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/stir
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 6 Aug 2013 13:52:23 -0400

Instead of "this group will not eliminate this capability", I suggest "no
changes to such standards will be proposed".  This eliminates a double
negative and reinforces that we are not changing the mechanisms at all.

Brian

On Tuesday, August 6, 2013, Stephen Farrell wrote:

> > I have gathered the comments that I have seen so far regarding the
> privacy paragraph of the charter, and I have updated that paragraph:
> >
> >> The privacy document is fairly straight forward if you only consider
> the use of a STIR credential in the in-band and an out-of-band mechanisms.
>  However, it gets much more complicated if one considers other potential
> uses (and abuses) of this credential in other protocol environments.  Do
> you have any thoughts on this?  Do you have proposed charter text?
> >>
> >> Russ
> >
> > [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 6 Aug 2013 14:02:26 -0400

We handle anonymous callers now in some countries because in those
countries, calls from unintitalized mobiles are allowed to emergency
services.  The statistics of such capabilities are very poor (one good call
in thousands or tens of thousands of calls handled).  However, they are
still allowed.  The general rule for emergency calls is all calls are
accepted, always.  The source and validity of identity is used to inform
the response.  It would be unlikely for a full SWAT team to be deployed in
such cases, but some response would undoubtedly be dispatched.

Brian

On Tuesday, August 6, 2013, Michael Hammer wrote:

> From: [email-masked] <javascript:;> [mailto:[email-masked]<javascript:;>]
> On Behalf Of
> Hadriel Kaplan
> Cc: [email-masked] <javascript:;>
> On Aug 6, 2013, at 11:58 AM, "Richard Shockey" <[email-masked]<javascript:;>>
> wrote:
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 15:16:48 -0400

Ummm... well... I didn't want to raise this before because I didn't think it would affect the charter and anyway this idea is debatable, but I was going to suggest we might need to update RFC 5379, so that a priv-value of 'user' removes any new header we end up defining here.  The STIR document would say to not generate one anyway, so we might just be ok with that and leave 5379 alone.

[As an aside, like RFC 3323 for SIP, SS7 supports network-based privacy service, where the source identity is passed in the message but screened out by network equipment from being displayed to the called user. (SS7 has bit flags for this indication in Calling Party Number param)  So at least for the IKES mechanism, which can be used in SS7, we'd want to have it not generate a STIR header if the bit-flag is set.  I was going to put that in the next rev of IKES.]

-hadriel

On Aug 6, 2013, at 1:52 PM, Brian Rosen <[email-masked]> wrote:

> Instead of "this group will not eliminate this capability", I suggest "no changes to such standards will be proposed".  This eliminates a double negative and reinforces that we are not changing the mechanisms at all.
> 
> Brian
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Aug 2013 15:22:47 -0400

How about:

Anonymous calls are already defined in SIP standards, and this
working group will not propose changes to these standards.

Russ

---

From: Brian Rosen <[email-masked]>
Date: Tue, 6 Aug 2013 15:28:40 -0400

WFM

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Aug 2013 13:18:26 -0700

On 8/6/2013 10:12 AM, Russ Housley wrote:
>>> The threat document is quite different if it cover an in-band
>>> mechanism or both an in-band and an out-of-band mechanism.  Do
>> No doubt it's my naivete about the technical side of security work,
>> but it isn't obvious to me why your assertion is correct.  Please
>> explain the nature of the differences that you see.
...
> The threat environment for out-of-band is more complex; it contains
> all of the entities in the in-band case as well as SBCs and PSTN
> entities.

Ah. OK.  Thanks.

Yet another good reason to defer working on out-of-band until after
in-band is complete.

d/

---

From: Stephen Kent <[email-masked]>
Date: Tue, 06 Aug 2013 16:35:49 -0400

Russ,

I have not worked on proposed charter text, but now that you ask, I'll 
work on that.

Steve
------

---

From: Stephen Kent <[email-masked]>
Date: Tue, 06 Aug 2013 16:47:09 -0400

Eric,

I don't think the privacy implications need to be that bad. After all I 
think we
have assumed that callers will still be able to block caller ID info when
making a VoIP call, in the same way that *67 works for called initiated 
on the PSTN.
Also, unlisted PSTN numbers, by default, block their caller ID info.

Those seem like a reasonable starting point for VoIP caller ID blocking 
requirements,
in the STIR context.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Aug 2013 22:52:48 +0200

IMO there is a *big* difference between carrying identity info and 
removing it just before passing to the callee, and never having identity 
info in call at all.

	Thanks,
	Paul

On 8/6/13 10:47 PM, Stephen Kent wrote:
>> I agree we are not looking at a national security private network
>> analysis. However, we are talking about the potential end of any
>> privacy or anonymity for ANY Internet application, more especially
>> Internet multimedia application. That needs to have a level of
>> analysis that goes beyond either "hopelessly broken" or "don't worry
>> about it."
>>
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 06 Aug 2013 17:03:27 -0400

Russ,

You provided what seems like reasonable charter text. I have made few edits.

*Authentication and authorization of identity is closely linked to 
privacy, and these security features sometimes come at the cost of 
privacy. Anonymous calls are already defined in SIP standards, and this 
working group will not eliminate this capability. A called party will 
receive an indication that the number of the caller has been blocked, in 
support of anonymity,**equivalent to what it provided in the PSTN today. 
This working group, to the extent feasible, will specify 
privacy-friendly mechanisms that do not reveal any more information to 
third parties than a call that does not make use of secure telephone 
identification mechanisms. *

Steve

---

From: Brian Rosen <[email-masked]>
Date: Tue, 6 Aug 2013 17:11:06 -0400

We can't say what a device does when an anonymous call comes or when
unauthenticated identity is received.  Anonymity in SIP can be stronger
than in the PSTN in that the identity is not sent rather than being
suppressed at the recipient.  We can have suppresssion, at least in some
systems as well, but the IETF standards based anonymous call doesn't send
any identity.   So, I think your suggested addition can't be used.

Brian

On Tuesday, August 6, 2013, Stephen Kent wrote:

> privacy, and these security features sometimes come at the cost of privacy.
> Anonymous calls are already defined in SIP standards, and this working
> group will not eliminate this capability. A called party will receive an
> indication that the number of the caller has been blocked, in support of
> anonymity,** equivalent to what it provided in the PSTN today. This
> working group, to the extent feasible, will specify privacy-friendly
> mechanisms that do not reveal any more information to third parties than a
> call that does not make use of secure telephone identification mechanisms.
> *
>
> Steve
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 6 Aug 2013 14:15:31 -0700

I'm not following this either. How would this be the end of privacy for
(for instance) Web, any more than it is now....

-Ekr

On Tue, Aug 6, 2013 at 1:47 PM, Stephen Kent <[email-masked]> wrote:

> making a VoIP call, in the same way that *67 works for called initiated on
> the PSTN.
>> analysis. However, we are talking about the potential end of any privacy or
>> anonymity for ANY Internet application, more especially Internet multimedia
>> application. That needs to have a level of analysis that goes beyond either
>> "hopelessly broken" or "don't worry about it."
>>
>>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 6 Aug 2013 17:17:10 -0400

+1 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ
Housley
Sent: Tuesday, August 06, 2013 3:23 PM
To: Brian Rosen
Cc: Lucy Lynch; IETF STIR Mail List; Steve Kent
Subject: Re: [stir] Moving from BOF to Charter

How about:

Russ

Brian

On 08/06/2013 06:17 PM, Russ Housley wrote:
> I have gathered the comments that I have seen so far regarding the privacy

s/do/that do/

But I'd be ok with it,
S.

>> The privacy document is fairly straight forward if you only consider the
use of a STIR credential in the in-band and an out-of-band mechanisms.
However, it gets much more complicated if one considers other potential uses
(and abuses) of this credential in other protocol environments.  Do you have
any thoughts on this?  Do you have proposed charter text?

---

From: Michael Hammer <[email-masked]>
Date: Tue, 6 Aug 2013 21:17:36 +0000

I would not get into saying what parameters would or would not be provided. 

Last sentence could mean no new information of any kind.   A mechanism with
no info is magic.  J

Could you characterize that as personally identifiable information or
similar?

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Tuesday, August 06, 2013 5:03 PM
To: Russ Housley
Cc: Lucy Lynch; IETF STIR Mail List
Subject: Re: [stir] Moving from BOF to Charter

Russ,

Authentication and authorization of identity is closely linked to privacy,
and these security features sometimes come at the cost of privacy. Anonymous
calls are already defined in SIP standards, and this working group will not
eliminate this capability. A called party will receive an indication that
the number of the caller has been blocked, in support of anonymity,
equivalent to what it provided in the PSTN today. This working group, to the
extent feasible, will specify privacy-friendly mechanisms that do not reveal
any more information to third parties than a call that does not make use of
secure telephone identification mechanisms. 

Steve

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Aug 2013 17:21:25 -0400

Merging suggestions from other, I come up with:

Authentication and authorization of identity is closely linked to
privacy, and these security features sometimes come at the cost of
privacy. Anonymous calls are already defined in SIP standards, and this
working group will not propose changes to these standards.  A called
party will receive an indication that the source telephone number has
been blocked to provide anonymity. This working group, to the extent
feasible, will specify privacy-friendly mechanisms that do not reveal
any more information to third parties than a call that does not make
use of secure telephone identification mechanisms. 

Does that work for you?

Russ

On Aug 6, 2013, at 5:03 PM, Stephen Kent wrote:

> Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not eliminate this capability. A called party will receive an indication that the number of the caller has been blocked, in support of anonymity, equivalent to what it provided in the PSTN today. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to third parties than a call that does not make use of secure telephone identification mechanisms.

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 6 Aug 2013 17:23:55 -0400

But there may be some national security systems that run on the "public" 
network and legitimately need to conceal the real "originating number" 
from BOTH the called party and the internal call records.

Janet

[email-masked] wrote on 08/05/2013 04:36:40 PM:

> From: Eric Burger <[email-masked]>

> analysis that goes beyond either "hopelessly broken" or "don't 
worryabout it."

---

From: Russ Housley <[email-masked]>
Date: Tue, 6 Aug 2013 17:27:12 -0400

Janet:

What change to the charter text is needed?

Russ

On Aug 6, 2013, at 5:23 PM, Janet P Gunn wrote:

> But there may be some national security systems that run on the "public" network and legitimately need to conceal the real "originating number" from BOTH the called party and the internal call records. 
> 
> Janet
> 
> 
> > analysis that goes beyond either "hopelessly broken" or "don't worryabout it."
> > 
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 06 Aug 2013 17:29:57 -0400

Brian,

I don't see the term "suppressed" anywhere in my revised text. When I 
used the
"blocked" and made an analogy to PSTN functionality I did not mean that the
implementation would be the same, e.g., suppression only to the called 
party.

Steve

> unauthenticated identity is received.  Anonymity in SIP can be 
> stronger than in the PSTN in that the identity is not sent rather than 
> being suppressed at the recipient.  We can have suppresssion, at least 
> in some systems as well, but the IETF standards based anonymous call 
> doesn't send any identity.   So, I think your suggested addition can't 
> be used.
>
> Brian
>
>     privacy. Anonymous calls are already defined in SIP standards, and
>     this working group will not eliminate this capability. A called
>     party will receive an indication that the number of the caller has
>     been blocked, in support of anonymity,**equivalent to what it
>     provided in the PSTN today. This working group, to the extent
>     feasible, will specify privacy-friendly mechanisms that do not
>     reveal any more information to third parties than a call that does
>     not make use of secure telephone identification mechanisms. *
>
>     Steve
>

---

From: Michael Hammer <[email-masked]>
Date: Tue, 6 Aug 2013 21:34:53 +0000

Janet,

Couldn't you use fake numbers that could still be signed and pass
validation?

I think you are saying that the numbers used would not trace back to a given
organization, or would trace to storefront.com

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Janet P Gunn
Sent: Tuesday, August 06, 2013 5:24 PM
To: Eric Burger
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

But there may be some national security systems that run on the "public"
network and legitimately need to conceal the real "originating number" from
BOTH the called party and the internal call records. 

Janet

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 17:49:49 -0400

On Aug 6, 2013, at 4:52 PM, Paul Kyzivat <[email-masked]> wrote:

> IMO there is a *big* difference between carrying identity info and removing it just before passing to the callee, and never having identity info in call at all.

You're right, there is.  But we're not affecting that - we're making it neither worse nor better.  SIP already supports both models.  Per our existing SIP Privacy-related RFCs, the originating UA is *always* able to generate an anonymous From; or it can use a network-based "anonymization service" if it prefers, again per our RFCs.  It can even do both.

Even in deployed SIP networks today, many providers do support letting the UA generate an anonymous From - it's caused headaches, and I'm not claiming it's supported by _all_ providers, but many do actually support it.  (I know this from personal experience dealing with its repercussions, in multiple provider deployments)

For the STIR RFCs we generate, I don't think anyone's suggesting the STIR mechanism would counteract/undo this support, nor that STIR would generate information about the source identity if the From were already anonymous.  It's technically possible that some people could screw it up, but I think such errors would be quickly discovered and fixed. (and at least in the litigious US, they'd probably also be sued if they didn't fix it)  It's technically possible that some people could purposefully generate STIR info for anonymous calls despite the RFCs, but they can already generate source identity info today too and ignore the existing SIP Privacy RFCs.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 6 Aug 2013 17:54:37 -0400

Russ,

any more information to third parties

[RS> ] or user agents

What the network has to see vs what the UA should see.  

 than a call that does not make use of secure telephone identification
mechanisms. 

[RS> ]  again let's not get wrapped around the axel here.  

Steve

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 6 Aug 2013 17:57:16 -0400

I'm curious why would the source be necessary to conceal in the CDR's.  

Janet

[email-masked] <mailto:[email-masked]>  wrote on 08/05/2013
04:36:40 PM:

> From: Eric Burger <[email-masked]
<mailto:[email-masked]> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 18:00:32 -0400

Can they conceal it from CDRs now?  If so, I don't think what we're doing will expose it to CDRs.  Can you describe how they're doing it, at even a high-level?  I understand if you can't, but just saying it would help.  I've heard of only one way that's done today, and that way won't be affected by STIR as far as I can tell.  Well... when I say "not affected", I mean it won't cause their real originating numbers to show up in CDRs, nor in wireshark captures, or system logs, etc.

If they can't conceal it from CDRs now, I don't see how it applies to us.  I mean it's not a problem we're tasked with fixing.

Can you elaborate on the concern, in any way publicly?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 18:02:41 -0400

Example: an FBI office or agent calls a safe house.

-hadriel

On Aug 6, 2013, at 5:57 PM, "Richard Shockey" <[email-masked]> wrote:

> I’m curious why would the source be necessary to conceal in the CDR’s.  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 6 Aug 2013 18:13:23 -0400

OK .. so the FBI or CIA doesn't want the NSA to know who they are calling? 

Sorry its cocktail hour on the US east coast.

I shudder thinking about the corner cases here need to be listed in detail.
.... <sigh> 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, August 06, 2013 6:03 PM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

worryabout it."

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Aug 2013 00:21:55 +0200

Hadriel,

I was just responding to Steven's comment, not to the charter.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 19:00:18 -0400

Actually, I always forget which call direction this needs to happen in - or maybe it needs to happen in both directions.  But this is just an example anyway, of one reason a government might want to hide the real calling party number from CDRs.  I'm not saying it's the primary use-case, or that it even happens in practice in the real world.  It's just an example people use in public forums such as this, as to why one needs to be able to hide such things.

The issue isn't about the NSA necessarily - the issue is employees at the carriers along the path.  CDRs are viewable by too many employees, in too many carriers along the call path.

Safe houses (places to hide informants/witnesses) are meant to stay safe and anonymous, obviously - in particular from large criminal organizations with plenty of money, people, and muscle power.  In the FBI's case, for example, they need to protect safe houses even from other government organizations they might be investigating/prosecuting.  They have to distrust each other, for good reason.  Since you're in DC, you know this better than me. :)

So if you're an FBI office/agent/SAC or whatever, and you need to talk to the safe house regularly, you don't want to leave a trace in CDRs of your calling party number... because then someone who knows who the office/SAC is for a case, and their phone number, can get a hold of CDRs and look for who that office/SAC is calling, and then figure out the number to the safe house.  Or vice versa, if the Safe House calls the SAC, the CDRs show calls to the SAC from a safe-house number. (again, I can't remember which call direction was the one used in the example I'd heard, or if it's both ways)  Once you have potential Safe-House phone numbers, it's not hard to track down location, since the whole premise here is you have the money/power to co-opt employees at carriers.

Again, I have no idea if this is what really drives the need - it's just an example I've been told in other public fora.

We do similar things for Lawful Intercept, for which the requirements and mechanisms are publicly known/documented for several countries - not all countries have the same rules or mechanisms, but they're generally similar.  No CDR entries are recorded/generated about who's under warrant, being wiretapped past/present/future, etc.  If you looked at a CDR for a wiretapped call, nothing would appear different from a regular call.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Wed, 7 Aug 2013 08:45:36 -0400

I did misunderstand the text you proposed, but I do think there is a
difference between "blocked" and "never sent".  Are you okay with Russ's
latest edits?  I am.

Brian

On Tuesday, August 6, 2013, Stephen Kent wrote:

>  Brian,
>
> I don't see the term "suppressed" anywhere in my revised text. When I used
> the

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 7 Aug 2013 09:50:36 -0400

I think fake numbers would work.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

From:   Michael Hammer <[email-masked]>
To:     Janet P Gunn/USA/CSC@CSC, "[email-masked]" 
<[email-masked]>
Cc:     "[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
Date:   08/06/2013 05:34 PM
Subject:        RE: [stir] Early Homework  (was Re:  Moving from BOF to 
Charter)

Janet,
 
Couldn’t you use fake numbers that could still be signed and pass 
validation?
 
I think you are saying that the numbers used would not trace back to a 
given organization, or would trace to storefront.com
 
Mike

Janet

worryabout it."

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Aug 2013 15:52:13 +0200

The problem with hiding identity from CDRs is billing.
Carriers seem to want to charge for communication services.
The information used for charging could be distinct from that used for 
proving caller identity to the called party, but there is likely to be 
quite good correlation between the two.

I don't know how one can guarantee privacy in an environment that 
charges for service without trusting the intermediaries to hide the 
charging identity.

Perhaps something could be worked out via an anonymous payment mechanism 
such as bitcoins.

This isn't really an issue for STIR. There may be a need for another 
initiative to enable anonymous calling to any phone number. But I expect 
that many governments, including the US, might oppose that.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 7 Aug 2013 10:09:07 -0400

Do we need any charter language changes?

In the STIR scheme, there are no "fake" numbers, but of course there are
way to get numbers allocated for such uses and obtain the credentials
associated with those numbers so they can be used to send calls.

Brian

On Wednesday, August 7, 2013, Janet P Gunn wrote:

> bind CSC to any order or other contract unless pursuant to explicit written
> agreement or government initiative expressly permitting the use of e-mail
> for such purpose.
>
>
>
> From:        Michael Hammer <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> >
> To:        Janet P Gunn/USA/CSC@CSC, "[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>"
> <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>
> Cc:        "[email-masked] <javascript:_e({}, 'cvml', [email-masked]');>" <
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>, "
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>" <
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>, "
> [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>" <[email-masked] <javascript:_e({},
> 'cvml', [email-masked]');>>
> ------------------------------
>
>
>
> Janet,
>
> *From:* [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [mailto:[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
> *On Behalf Of *Janet P Gunn*
> Sent:* Tuesday, August 06, 2013 5:24 PM*
> To:* Eric Burger*
> Cc:* [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>;
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>;
> [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>*
> Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to Charter)
>
> [email-masked]* <javascript:_e({}, 'cvml',
> [email-masked]');> wrote on 08/05/2013 04:36:40 PM:
>
> > From: Eric Burger <[email-masked]* <javascript:_e({},
> 'cvml', [email-masked]');>>
>
> >

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 7 Aug 2013 10:09:11 -0400

That is not the specific case I was thinking of, but it suffices as an 
example.

You do not want carrier employees (who have legitimate reasons to look at 
CDRs, but do not typically have security clearances) to know where 
particular phone calls are coming from.

"Fake numbers" should be sufficient.

I think the reference in the charter to "equivalent to what it (sic) 
provided in the PSTN today " covers it.

Janet

[email-masked] wrote on 08/06/2013 07:00:18 PM:

> From: Hadriel Kaplan <[email-masked]>
> To: Richard Shockey <[email-masked]>
> Cc: [email-masked]
> Date: 08/06/2013 07:00 PM
> Sent by: [email-masked]
> 
> 
> Actually, I always forget which call direction this needs to happen 
> in - or maybe it needs to happen in both directions.  But this is 
> just an example anyway, of one reason a government might want to 
> hide the real calling party number from CDRs.  I'm not saying it's 
> the primary use-case, or that it even happens in practice in the 
> real world.  It's just an example people use in public forums such 
> as this, as to why one needs to be able to hide such things.
> 
> The issue isn't about the NSA necessarily - the issue is employees 
> at the carriers along the path.  CDRs are viewable by too many 
> employees, in too many carriers along the call path.
> 
> Safe houses (places to hide informants/witnesses) are meant to stay 
> safe and anonymous, obviously - in particular from large criminal 
> organizations with plenty of money, people, and muscle power.  In 
> the FBI's case, for example, they need to protect safe houses even 
> from other government organizations they might be investigating/
> prosecuting.  They have to distrust each other, for good reason. 
> Since you're in DC, you know this better than me. :)
> 
> So if you're an FBI office/agent/SAC or whatever, and you need to 
> talk to the safe house regularly, you don't want to leave a trace in
> CDRs of your calling party number... because then someone who knows 
> who the office/SAC is for a case, and their phone number, can get a 
> hold of CDRs and look for who that office/SAC is calling, and then 
> figure out the number to the safe house.  Or vice versa, if the Safe
> House calls the SAC, the CDRs show calls to the SAC from a safe-
> house number. (again, I can't remember which call direction was the 
> one used in the example I'd heard, or if it's both ways)  Once you 
> have potential Safe-House phone numbers, it's not hard to track down
> location, since the whole premise here is you have the money/power 
> to co-opt employees at carriers.
> 
> Again, I have no idea if this is what really drives the need - it's 
> just an example I've been told in other public fora.
> 
> We do similar things for Lawful Intercept, for which the 
> requirements and mechanisms are publicly known/documented for 
> several countries - not all countries have the same rules or 
> mechanisms, but they're generally similar.  No CDR entries are 
> recorded/generated about who's under warrant, being wiretapped past/
> present/future, etc.  If you looked at a CDR for a wiretapped call, 
> nothing would appear different from a regular call.
> 
> -hadriel
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Aug 2013 10:38:00 -0400

It depends on how you mean that.  For the governmental type calls we were talking about, I believe it's handled a slightly different way anyway, and I don't think it's worth speculating about here.

But for general anonymous calls: there are calls made on the PSTN (and its SIP equivalent), right now, that really don't have source caller identity in CDRs.  CDRs are still generated for them, but there is no calling party info with the phone number of the calling phone.  Afaik, in TDM land it's the ANI number that is used for charging, not the CLID.  And that's a different field, often identifying a generic billing number for a company/organization rather than a specific line/phone, and it's not delivered/presented to end users when they receive the call.  In SIP land, providers use various headers to encode a billing identity, separately from a source calling identity.  Some use P-DCS-Billing-Info for example; some even seen some use P-Asserted-Identity for it (sadly).  Dan York has had a draft out for several years, defining a new header for it (draft-york-sipping-p-charge-info), and I've been told it gets used by some folks already.

Clearly it does require trusting the carriers to hide the billing information from the called user, but (1) you have to trust them for a heck of a lot more than that anyway, especially in terms of privacy issues, and (2) that has not appeared to be a problem in the real world.  As you noted, it's not an issue for STIR.

-hadriel

On Aug 7, 2013, at 9:52 AM, Paul Kyzivat <[email-masked]> wrote:

> The information used for charging could be distinct from that used for proving caller identity to the called party, but there is likely to be quite good correlation between the two.
> 
> I don't know how one can guarantee privacy in an environment that charges for service without trusting the intermediaries to hide the charging identity.
> 
> Perhaps something could be worked out via an anonymous payment mechanism such as bitcoins.
> 
> This isn't really an issue for STIR. There may be a need for another initiative to enable anonymous calling to any phone number. But I expect that many governments, including the US, might oppose that.
> 
> 	Thanks,
> 	Paul
>

---

From: Michael Hammer <[email-masked]>
Date: Wed, 7 Aug 2013 14:56:01 +0000

I suspect that carriers will capture the signaling data, whether the numbers
therein are valid or not.

But, I think it out of scope for us to determine what they do with that.
Leave that to ATIS, ETSI, and ITU-T.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Wednesday, August 07, 2013 9:52 AM
To: [email-masked]
Subject: Re: [stir] Privacy

The problem with hiding identity from CDRs is billing.
Carriers seem to want to charge for communication services.
The information used for charging could be distinct from that used for
proving caller identity to the called party, but there is likely to be quite
good correlation between the two.

I don't know how one can guarantee privacy in an environment that charges
for service without trusting the intermediaries to hide the charging
identity.

	Thanks,
	Paul

On 8/7/13 1:00 AM, Hadriel Kaplan wrote:
>
> Actually, I always forget which call direction this needs to happen in -
or maybe it needs to happen in both directions.  But this is just an example
anyway, of one reason a government might want to hide the real calling party
number from CDRs.  I'm not saying it's the primary use-case, or that it even
happens in practice in the real world.  It's just an example people use in
public forums such as this, as to why one needs to be able to hide such
things.
>
> The issue isn't about the NSA necessarily - the issue is employees at the
carriers along the path.  CDRs are viewable by too many employees, in too
many carriers along the call path.
> organizations with plenty of money, people, and muscle power.  In the 
> FBI's case, for example, they need to protect safe houses even from 
> other government organizations they might be 
> investigating/prosecuting.  They have to distrust each other, for good 
> reason.  Since you're in DC, you know this better than me. :)
>
> So if you're an FBI office/agent/SAC or whatever, and you need to talk to
the safe house regularly, you don't want to leave a trace in CDRs of your
calling party number... because then someone who knows who the office/SAC is
for a case, and their phone number, can get a hold of CDRs and look for who
that office/SAC is calling, and then figure out the number to the safe
house.  Or vice versa, if the Safe House calls the SAC, the CDRs show calls
to the SAC from a safe-house number. (again, I can't remember which call
direction was the one used in the example I'd heard, or if it's both ways)
Once you have potential Safe-House phone numbers, it's not hard to track
down location, since the whole premise here is you have the money/power to
co-opt employees at carriers.
>
> Again, I have no idea if this is what really drives the need - it's just
an example I've been told in other public fora.
>
> We do similar things for Lawful Intercept, for which the requirements and
mechanisms are publicly known/documented for several countries - not all
countries have the same rules or mechanisms, but they're generally similar.
No CDR entries are recorded/generated about who's under warrant, being
wiretapped past/present/future, etc.  If you looked at a CDR for a
wiretapped call, nothing would appear different from a regular call.

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 7 Aug 2013 11:13:06 -0400

Janet,

Ideally the number sent would allow us to identify the billable party even if it doesn't identify the location from which the call was sent or the individual that sent it.  Is that consistent with your "fake number" idea?

tim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: Wednesday, August 07, 2013 7:09 AM
To: Hadriel Kaplan
Cc: [email-masked]; [email-masked]; Richard Shockey
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

That is not the specific case I was thinking of, but it suffices as an example.

You do not want carrier employees (who have legitimate reasons to look at CDRs, but do not typically have security clearances) to know where particular phone calls are coming from.

I think the reference in the charter to "equivalent to what it (sic) provided in the PSTN today " covers it.

Janet

[email-masked]<mailto:[email-masked]> wrote on 08/06/2013 07:00:18 PM:

> From: Hadriel Kaplan <[email-masked]<mailto:[email-masked]>>
> To: Richard Shockey <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> Sent by: [email-masked]<mailto:[email-masked]>
>
>
> On Aug 6, 2013, at 6:13 PM, Richard Shockey <[email-masked]<mailto:[email-masked]>> wrote:
>
> >
> > Cc: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 7 Aug 2013 11:27:50 -0400

"equivalent to what it (sic) provided in the PSTN today " 

"Dwight, Timothy M (Tim)" <[email-masked]> wrote on 08/07/2013 
11:13:06 AM:

> From: "Dwight, Timothy M (Tim)" <[email-masked]>
> To: Janet P Gunn/USA/CSC@CSC, Hadriel Kaplan <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <stir-
> [email-masked]>, Richard Shockey <[email-masked]>
> Date: 08/07/2013 11:14 AM
Charter)
> 
> Janet,
> 
> Ideally the number sent would allow us to identify the billable 
> party even if it doesn’t identify the location from which the call 
> was sent or the individual that sent it.  Is that consistent with 
> your “fake number” idea?
> 
> tim
> 
> You do not want carrier employees (who have legitimate reasons to 
> look at CDRs, but do not typically have security clearances) to know
> where particular phone calls are coming from. 
> 
> > > I shudder thinking about the corner cases here need to be listedin 
detail.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 07 Aug 2013 16:57:27 -0400

Brian,

> difference between "blocked" and "never sent".  Are you okay with 
> Russ's latest edits?  I am.
>
> Brian
there is ambiguity, since blocked very near the sender is more or less 
the same as never sent,
but no need to discuss this further.

At BBN we have PRI interfaces to the PSTN from our internal VoIP system, 
so there are
a variety of interface options.

Syeve

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 7 Aug 2013 17:28:47 -0400

What ...no SIP Trunking??  Hummmm   :-) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Wednesday, August 07, 2013 4:57 PM
To: Brian Rosen
Cc: Lucy Lynch; IETF STIR Mail List; Russ Housley
Subject: Re: [stir] Moving from BOF to Charter

Brian,

> Russ's latest edits?  I am.
there is ambiguity, since blocked very near the sender is more or less the
same as never sent, but no need to discuss this further.

At BBN we have PRI interfaces to the PSTN from our internal VoIP system, so
there are a variety of interface options.

Syeve

---

From: Lucy Lynch <[email-masked]>
Date: Thu, 8 Aug 2013 12:21:08 -0700 (PDT)

> use of secure telephone identification mechanisms.

I have some continuing concerns but will stand back for now and see
how this develops.

- Lucy

---

From: Brian Rosen <[email-masked]>
Date: Thu, 8 Aug 2013 16:49:44 -0400

Thanks.

Is that it?  Is everyone okay with the charter language now?  Russ will
post a new complete version just to make sure, but can we send this to the
IESG and ask for the work group?

Brian

On Thursday, August 8, 2013, Lucy Lynch wrote:

>>> anonymity, equivalent to what it provided in the PSTN today. This working
>>> group, to the extent feasible, will specify privacy-friendly mechanisms
>>> that do not reveal any more information to third parties than a call that
>>> does not make use of secure telephone identification mechanisms.
>>>
>>
>>

---

From: Eric Burger <[email-masked]>
Date: Thu, 8 Aug 2013 19:53:59 -0400

Which is storefront.com, which means the charter can be silent.

On Aug 7, 2013, at 11:27 AM, Janet P Gunn <[email-masked]> wrote:

> "Dwight, Timothy M (Tim)" <[email-masked]> wrote on 08/07/2013 11:13:06 AM:
> 
> > Subject: RE: [stir] Early Homework  (was Re:  Moving from BOF to Charter) 
> > 
> > Janet, 
> >   
> > > > I shudder thinking about the corner cases here need to be listedin detail.
> > > > .... <sigh> 
> > > > 
> > > https://www.ietf.org/mailman/listinfo/stir _______________________________________________
> stir mailing list
> [email-masked]

---

From: Eric Burger <[email-masked]>
Date: Thu, 8 Aug 2013 19:54:03 -0400

*67 only blocks the delivery of the caller ID to the called party. The network gets it, even often up to the called party's PBX. This relies on the good graces of the PBX implementor to honor the privacy bit.

On Aug 6, 2013, at 4:47 PM, Stephen Kent <[email-masked]> wrote:

> Eric,
> 
> I don't think the privacy implications need to be that bad. After all I think we
> making a VoIP call, in the same way that *67 works for called initiated on the PSTN.
> Those seem like a reasonable starting point for VoIP caller ID blocking requirements,
> in the STIR context.
>

---

From: Eric Burger <[email-masked]>
Date: Thu, 8 Aug 2013 19:54:07 -0400

> The threat environment for out-of-band is more complex; it contains all of the entities in the in-band case as well as SBCs and PSTN entities.

I thought the justification for out-of-band is it avoided the SBC's, the carriers, and so on. No?

---

From: Eric Burger <[email-masked]>
Date: Thu, 8 Aug 2013 19:54:10 -0400

> No one is proposing, for example, that anonymous calls no longer remain anonymous.  Nor that one can't make anonymous calls.

Actually, we are. We are talking about "official" calling. Otherwise, we would have p2psip and there would not be regulators in the middle. It would not be hard to imaging regulators banning anonymous calling, as the bad guys all use anonymous calling and grandpa still answers the call and hands over his life savings to the nice lady on the phone.

After that, what stops the regulators from congratulating the IETF on doing such a good job on phone calls to extend it to email? And then to IM? And then to TOR?

> Your statement seems a bit alarmist.

Ringing off the walls!

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 22:01:25 -0400

> *67 only blocks the delivery of the caller ID to the called party. The network gets it, even often up to the called party's PBX. This relies on the good graces of the PBX implementor to honor the p…

Yup, *67 blocks delivery.  I believe that it's rare for it to be sent to the called party's PBX, but I could be wrong on that.  Regardless, we're not making that any worse or better.  If it works today, it will work tomorrow.  If it doesn't work today, we're not magically fixing it.

True perfect source anonymity has never been a property of the PSTN: at the very least, your local carrier knows who you are when you generate a call.  You can use cutouts, public phones, or buy a disposable phone at the airport - and we're not preventing those things from being possible - but in the general Grandma-at-home case, her local provider knows who she is, even if she anonymizes her From in her SIP UA phone today.  But that is not a problem we're tasked with solving, nor has it appeared to even be a problem to begin with.

Even for the Internet: at the very least, your local ISP knows your IP Address, and knows you sent IP packets, and often knows where you sent them to.  You can use anonymous-proxies, public WiFi's, or whatever; but in the general broadband subscriber case, your ISP knows. 

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Aug 2013 23:23:51 -0400

On Aug 8, 2013, at 7:54 PM, Eric Burger <[email-masked]> wrote:

> Actually, we are. We are talking about "official" calling. Otherwise, we would have p2psip and there would not be regulators in the middle.

You lost me.  I have no idea what p2psip has to do with anything.  If you think p2psip failed because it allows anonymous calls, you are waaay off.    You must mean something else, but I'm not getting it.(?)

> It would not be hard to imaging regulators banning anonymous calling, as the bad guys all use anonymous calling and grandpa still answers the call and hands over his life savings to the nice lady on the phone.

It's theoretically possible that such a thing could happen.  I think it's unlikely for regulators to do it, but people today are already ignoring anonymous calls so it might be more of a result that no one ever answers them, rather than regulatory mandate that carriers block them.  So what?  Are we supposed to make people accept anonymous communication requests if they don't want to?  Should we be encouraging spoofing in order to give attackers an incentive to not anonymize their calls?  Should we be just constantly randomizing source numbers for all calls in the future, in order to protect the rights of those who don't want their source number known?  Should we just make all future calls be anonymous?  What's your proposed solution to such a dilemma?

In some ways, getting to a stage of deployment where all bad guys use anonymous numbers is a *good thing*.  The fact is most users are already conditioned to distrust anonymous calls, meaning the bad guys will have a lower success rate, which means the fraud folks have an easier time tracking the bad guys down.  Ultimately, you *should* distrust anonymous calls - you really do need to be more cautious, less trusting, etc.  No?

> After that, what stops the regulators from congratulating the IETF on doing such a good job on phone calls to extend it to email? And then to IM? And then to TOR?

Ah yes, the old slippery-slope argument.  I can play that game too. :)

Using that logic: if we decide to not work on STIR because we're worried that providing a mechanism for source identity verification means governments will decide to prevent anonymous sources... then we should shut down a whole bunch of stuff in the IETF, deprecate a crap-load of RFCs, and retire to the beach.  You could start with shutting down SCIM, REPUTE, SAVI, KITTEN, DANE, OAUTH, and probably a few others (you can never be too careful!).  And of course immediately deprecate DKIM, rfc4474, Mutual-TLS, any digest auth mechanism in any protocol, etc.  I mean if we provide a means of authenticating users, then governments might not allow anonymous users, so we need to remove the mechanisms from our specs.  Right?

At the end of the day we're the IETF, not ICANN or a government body.  They debate politics and policy.  We solve technical problems.  How are we supposed to get anything accomplished, if we have to worry about governments abusing their power and potentially taking advantage of success of our mechanisms?

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Aug 2013 21:00:46 -0700

On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger <[email-masked]>wrote:

> application.
> > How so?  Obviously we could theoretically create some mechanism that
> took all call information from/to everyone and posted it to wikileaks or
> > whatever, but I don't think we're that stupid. (nor do I think it would
> get published by the IETF, nor would anyone use it if we did)
> >
> > No one is proposing, for example, that anonymous calls no longer remain
> anonymous.  Nor that one can't make anonymous calls.
>
> Actually, we are. We are talking about "official" calling. Otherwise, we
> would have p2psip and there would not be regulators in the middle. It would
> not be hard to imaging regulators banning anonymous calling, as the bad
> guys all use anonymous calling and grandpa still answers the call and hands
> over his life savings to the nice lady on the phone.
>

I'm not following this argument at all. The regulators could presumably
require this now. How does STIR change the situation?

-Ekr

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 9 Aug 2013 09:15:15 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Rescorla
Sent: Friday, August 09, 2013 12:01 AM
To: Eric Burger
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger <[email-masked]
<mailto:[email-masked]> > wrote:

On Aug 6, 2013, at 6:50 AM, Hadriel Kaplan <[email-masked]
<mailto:[email-masked]> > wrote:
> On Aug 5, 2013, at 4:36 PM, Eric Burger <[email-masked]

[RS> ]  Well I think Deep Packet Inspection tools took care of that issue
years ago. 

> How so?  Obviously we could theoretically create some mechanism that took
all call information from/to everyone and posted it to wikileaks or

Actually, we are. We are talking about "official" calling. Otherwise, we
would have p2psip and there would not be regulators in the middle. It would
not be hard to imaging regulators banning anonymous calling, as the bad guys
all use anonymous calling and grandpa still answers the call and hands over
his life savings to the nice lady on the phone.

[RS> ]  A.  You are correct. Regulators could require this now, since they
have plenary authority of how their portions of the E.164 plan are used and
in the case of Germany Caller ID spoofing is not allowed under any
circumstances.  B. STIR would not change anything.  The difference here is
what is displayed vs what the network would be able to track and validate.
The STIR exercise is about restoring some level of trust in interconnected
realtime communications applications that use E.164 naming. 

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Fri, 9 Aug 2013 10:00:41 -0400

Below is the current charter text.  Is it ready for the IESG?

Russ

> Thanks.
> 
> Is that it?  Is everyone okay with the charter language now?  Russ will post a new complete version just to make sure, but can we send this to the IESG and ask for the work group?
> 
> Brian

= = = = = = = = 

Name: Secure Telephone Identity Revisited (stir)
Area: RAI

Chairs: TBD
Area Advisor: Richard Barnes

Mailing list: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/stir

The STIR working group will specify mechanisms for the validation of
source telephone number for an incoming call.  Since it
has become fairly easy to present an incorrect source telephone number, a
growing set of problems have emerged over the last decade.  As with
email, the claimed source identity of a SIP request is not verified,
permitting unauthorized use of the source identity as part of deceptive
and coercive activities, such as robocalling (bulk unsolicited commercial
communications), vishing (voicemail hacking, and impersonating banks) and
swatting (impersonating callers to emergency services to stimulate
unwarranted large scale law enforcement deployments).  In addition, use
of an incorrect source telephone number facilitates wire fraud or lead to
a return call at premium rates.  This working group will define
mechanisms that verify the authorization of the calling party to use a
particular telephone number.

SIP is one of the main VoIP technologies used by parties that want to
present an incorrect origin, in this context an origin telephone number.
Several previous efforts have tried to secure the origins of SIP
communications, including RFC 3325, RFC 4474, and the VIPR working group.
To date, however, true validation of the source of SIP calls has not seen
any appreciable deployment.  Several factors contributed to this lack of
success, including: failure of the problem to be seen as critical at the
time; lack of any technical means of producing a proof of authority over
telephone numbers; misalignment of the mechanisms proposed by RFC 4474
with the complex deployment environment that has emerged for SIP; lack of
end-to-end SIP session establishment; and inherent operational problems
with a transitive trust model.  To make deployment of this solution more
likely, consideration must be given to latency, real-time performance,
computational overhead, and administrative overhead for the legitimate
call source and all verifiers.

As its priority mechanism work item, the working group will specify a SIP
header-based mechanism to verify the originator of a SIP session is
authorized to use the claimed source telephone number, where the session
is established with SIP end to end.  This is called an in-band mechanism.
The mechanism will use a canonical telephone number representation
specified by the working group, including any mappings that might be
needed between the SIP header fields and the canonical telephone number
representation.  The working group will consider choices for protecting
identity information and credentials used, but will likely be based on a
digital signature mechanism that covers a set of information in the SIP
header fields, and verification will employ a credential that contains
the public key and is associated with the one or more telephone numbers.
In order to be authoritative, credentials used with this mechanism will
be derived from existing telephone number assignment and delegation
models.  That is, when a telephone number or range of telephone numbers
is delegated to an entity, relevant credentials will be generated (or
modified) to reflect such delegation.  The mechanism must allow a
telephone number holder to further delegate and revoke use of a telephone
number without compromising the global delegation scheme.

In addition to its priority mechanism work item, the working group will
consider session establishment where there are one or more non-SIP hops,
most likely using an out-of-band mechanism.  However, the in-band and the
out-of-band mechanisms should share as much in common as possible,
especially the credentials.  The in-band mechanism must be sent to the
IESG for approval and publication prior to the out-of-band mechanism.

Expansion of the authorization mechanism to identities using the
user@domain form deferred since the main focus of the working group is to
develop a solution for telephone numbers.

The working group will coordinate with the Security Area on credential
management.

The working group will coordinate with other working groups in the RAI
Area regarding signaling through existing deployments.

Authentication and authorization of identity is closely linked to
privacy, and these security features sometimes come at the cost of
privacy.  Anonymous calls are already defined in SIP standards, and this
working group will not propose changes to these standards.  A called
party will receive an indication that the source telephone number is
unavailable in order to provide anonymity.  This working group, to the
extent feasible, will specify privacy-friendly mechanisms that do not
reveal any more information to user agents or third parties than a call
that does not make use of secure telephone identification mechanisms.

Input to working group discussions shall include:

  - Private Extensions to the Session Initiation Protocol (SIP)
    for Asserted Identity within Trusted Networks
    [RFC 3325]

  - Enhancements for Authenticated Identity Management in the
    Session Initiation Protocol (SIP)
    [RFC 4474]

  - Secure Call Origin Identification
    [draft-cooper-iab-secure-origin-00]

  - Secure Origin Identification: Problem Statement, Requirements,
    and Roadmap
    [draft-peterson-secure-origin-ps-00]

  - Authenticated Identity Management in the Session Initiation
    Protocol (SIP)
    [draft-jennings-dispatch-rfc4474bis-00]

The working group will deliver the following:

  - A problem statement detailing the deployment environment and
    situation that motivate work on secure telephone identity

  - A threat model for the secure telephone identity mechanisms

  - A privacy analysis of the secure telephone identity mechanisms

  - A mechanism document describing the SIP end-to-end with telephone
    number-based identities 

  - A document describing the credentials required to support
    telephone number identity authentication

  - A fallback mechanism to allow out-of-band identity establishment
    during call setup

Milestones

Sep 2013   Submit problem statement for Informational
Nov 2013   Submit threat model for Informational
Nov 2013   Submit in-band mechanism for Proposed Standard
Feb 2014   Submit credential specification for Proposed Standard
Apr 2014   Submit Privacy analysis for Informational
Jun 2014   Submit out-of-band mechanism for Proposed Standard

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 9 Aug 2013 07:29:21 -0700

This looks basically good to me. Some wordsmithing below.

-Ekr

On Fri, Aug 9, 2013 at 7:00 AM, Russ Housley <[email-masked]> wrote:

> communications), vishing (voicemail hacking, and impersonating banks)

this may need an e.g.,

and
> of an incorrect source telephone number facilitates wire fraud or lead to

maybe "or can lead to"

> particular telephone number.

Do the mechanisms verify or "allow verification of..."

> consider session establishment where there are one or more non-SIP hops,
most likely using an out-of-band mechanism.

I feel like some words are missing here. Perhaps
"providing authorization for session establishment...."
"most likely requiring an out-of-band authorization mechanism"

 However, the in-band and the
> unavailable in order to provide anonymity.

Perhaps:
"In order to support anonymity, the output of the WG will provide a mode
in which the called party receives an indication..."

 This working group, to the

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Aug 2013 10:42:29 -0400

SHIP IT.

-hadriel
p.s. I too just sent some grammatical nits to Russ directly, but don't care if they don't get done - just a Type A personality issue.

---

From: Eric Burger <[email-masked]>
Date: Thu, 8 Aug 2013 19:54:38 -0400

And if it does not need to operate at Internet scale, why are we working on it?

---

From: Eric Burger <[email-masked]>
Date: Thu, 8 Aug 2013 19:54:20 -0400

What should go in the charter?

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 9 Aug 2013 11:44:55 -0400

+1 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Friday, August 09, 2013 10:42 AM
To: Russ Housley
Cc: IETF STIR Mail List
Subject: Re: [stir] Moving from BOF to Charter

SHIP IT.

-hadriel
p.s. I too just sent some grammatical nits to Russ directly, but don't care
if they don't get done - just a Type A personality issue.

> source telephone number for an incoming call.  Since it has become 
> fairly easy to present an incorrect source telephone number, a growing 
> set of problems have emerged over the last decade.  As with email, the 
> claimed source identity of a SIP request is not verified, permitting 
> unauthorized use of the source identity as part of deceptive and 
> coercive activities, such as robocalling (bulk unsolicited commercial 
> unwarranted large scale law enforcement deployments).  In addition, 
> use of an incorrect source telephone number facilitates wire fraud or 
> lead to
> 
> maybe "or can lead to"
>  
> To date, however, true validation of the source of SIP calls has not 
> seen any appreciable deployment.  Several factors contributed to this 
> lack of success, including: failure of the problem to be seen as 
> critical at the time; lack of any technical means of producing a proof 
> of authority over telephone numbers; misalignment of the mechanisms 
> proposed by RFC 4474 with the complex deployment environment that has 
> emerged for SIP; lack of end-to-end SIP session establishment; and 
> inherent operational problems with a transitive trust model.  To make 
> deployment of this solution more likely, consideration must be given 
> to latency, real-time performance, computational overhead, and 
> administrative overhead for the legitimate call source and all verifiers.
> 
> As its priority mechanism work item, the working group will specify a 
> SIP header-based mechanism to verify the originator of a SIP session 
> is authorized to use the claimed source telephone number, where the 
> session is established with SIP end to end.  This is called an in-band
mechanism.
> needed between the SIP header fields and the canonical telephone 
> number representation.  The working group will consider choices for 
> protecting identity information and credentials used, but will likely 
> be based on a digital signature mechanism that covers a set of 
> information in the SIP header fields, and verification will employ a 
> credential that contains the public key and is associated with the one or
more telephone numbers.
> In order to be authoritative, credentials used with this mechanism 
> will be derived from existing telephone number assignment and 
> delegation models.  That is, when a telephone number or range of 
> telephone numbers is delegated to an entity, relevant credentials will 
> be generated (or
> telephone number holder to further delegate and revoke use of a 
> telephone number without compromising the global delegation scheme.
> 
> In addition to its priority mechanism work item, the working group 
> will consider session establishment where there are one or more 
> non-SIP hops, most likely using an out-of-band mechanism.
> 
> I feel like some words are missing here. Perhaps "providing 
> authorization for session establishment...."
> user@domain form deferred since the main focus of the working group is 
> to develop a solution for telephone numbers.
> 
> this working group will not propose changes to these standards.  A 
> called party will receive an indication that the source telephone 
> number is unavailable in order to provide anonymity.
> 
> Perhaps:
> "In order to support anonymity, the output of the WG will provide a 
> mode in which the called party receives an indication..."
> 
> 
> reveal any more information to user agents or third parties than a

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 9 Aug 2013 11:47:21 -0400

Nothing ..  Its fine the way it is ...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Burger
Sent: Thursday, August 08, 2013 7:54 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] Legitimate uses of third party Caller ID authorization /
spoofing for outbound calling - Re: What are we trying to do, and where do
we want to end up?

On Aug 6, 2013, at 11:26 AM, Michael Hammer <[email-masked]>
wrote:

> Subject: Re: [stir] Legitimate uses of third party Caller ID 
> authorization / spoofing for outbound calling - Re: What are we trying 
> to do, and where do we want to end up?
> 
> Mike,
> 
> 
>> Yes, but that doesn't mean you have to lie about the true originator 
>> of the call separate from what to display on caller ID or what to 
>> provide as a call-back number.
> 
> Perhaps we need to be more clear on who is the consumer of the 
> field(s) we are creating:
> 
> - Are we trying to help carriers / service providers be able to track 
> and potentially block calls?

---

From: Russ Housley <[email-masked]>
Date: Fri, 9 Aug 2013 11:58:17 -0400

I have updated the text based on the comments from EKR and Hadriel.  Is it ready for the IESG?

I am not going to bet on the Nov 2013 milestones.  It is too easy yo delay the chartering ...

Russ

= = = = = = = = 

Chairs: TBD

The STIR working group will specify mechanisms for the validation of
the source telephone number for an incoming call.  Since it
has become fairly easy to present an incorrect source telephone number, a
growing set of problems have emerged over the last decade.  As with
email, the claimed source identity of a SIP request is not verified,
permitting unauthorized use of the source identity as part of deceptive
and coercive activities, such as robocalling (bulk unsolicited commercial
communications), vishing (voicemail hacking, and impersonating banks) and
swatting (impersonating callers to emergency services to stimulate
unwarranted large scale law enforcement deployments).  In addition, use
of an incorrect source telephone number facilitates wire fraud or can
lead to a return call at premium rates.  This working group will define
mechanisms that allow verification of the authorization of the calling
party to use a particular telephone number.

header-based mechanism for verification of the originator of a SIP session is
the public key that is associated with the one or more telephone numbers.

In addition to its priority mechanism work item, the working group will
consider a mechanism for verification of the originator during session
establishment in an environment with one or more non-SIP hops, most
likely requiring an out-of-band authorization mechanism.  However, the
in-band and the out-of-band mechanisms should share as much in common as
possible, especially the credentials.  The in-band mechanism must be sent
to the IESG for approval and publication prior to the out-of-band
mechanism.

Expansion of the authorization mechanism to identities using the
user@domain form are deferred since the main focus of the working group
is to develop a solution for telephone numbers.

Authentication and authorization of identity is closely linked to
privacy, and these security features sometimes come at the cost of
privacy.  Anonymous calls are already defined in SIP standards, and this
working group will not propose changes to these standards.  In order to
support anonymity, the working group will provide a solution in which the
called party receives an indication that the source telephone number is
unavailable.  This working group, to the extent feasible, will specify
privacy-friendly mechanisms that do not reveal any more information to
user agents or third parties than a call that does not make use of secure
telephone identification mechanisms.

 - A problem statement detailing the deployment environment and
   situations that motivate work on secure telephone identity

 - A document describing the SIP in-band mechanism for telephone
   number-based identities during call setup

 - A document describing the out-of-band mechanism for telephone
   number-based identities during call setup

Milestones

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 9 Aug 2013 09:19:36 -0700

This is fine with me

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Aug 2013 12:59:05 -0400

Same here.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Aug 2013 19:08:51 +0200

> I thought the justification for out-of-band is it avoided the SBC's, the carriers, and so on. No?

While an over the top call would avoid much of the tracking, it only 
works if the callee will accept an over the top call. And today that is 
very rare.

But maybe some key callees that have a need to accept anonymous calls 
(e.g., the police) could actively decide to do so. But that doesn't work 
unless most callers can originate such calls. And if callees that accept 
them are rare, then the mechanism isn't likely to be widely deployed.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Aug 2013 13:38:32 -0400

On Aug 9, 2013, at 1:08 PM, Paul Kyzivat <[email-masked]> wrote:

> While an over the top call would avoid much of the tracking, it only works if the callee will accept an over the top call. And today that is very rare.

The currently proposed straw-man for how the out-of-band would work is the call signaling would continue to go its current way and continue to do its current thing; but the originator of the call (or some entity on its behalf) would publish the source number verification info to an out-of-band registry, and then the receiver of the call would go retrieve it from there to verify the caller's source identity.  (I'm simplifying, but that's the general concept)

So in that way Eric's right - its main advantage is it can bypass the service providers.

Of course once such a thing is deployed it could be used for the call signaling itself, and that's even stated in the straw-man draft for it.

-hadriel

---

From: Eric Burger <[email-masked]>
Date: Fri, 9 Aug 2013 18:18:20 -0400

It is one thing for the regulators to say "be bad." It is another thing for the regulators to say "do bad things because the IETF says it is good."

On Aug 9, 2013, at 12:00 AM, Eric Rescorla <[email-masked]> wrote:

> 
> 
> 
> On Thu, Aug 8, 2013 at 4:54 PM, Eric Burger <[email-masked]> wrote:

---

From: Eric Burger <[email-masked]>
Date: Fri, 9 Aug 2013 18:37:45 -0400

I still think it is insane to say we will deliver the threat model and the solution in parallel, but Hadriel and I have a $2 vs $20M side bet going on :-)  10,000,000:1 odds is pretty good.

I also think it is silly to have a year of work (really three) on in band and have out of band be in the charter. Just say no and do that later or as individual work. If the individual work matures faster than in-band, they get their own group and I can have another side bet (like XCON and MEDIACTRL) that I can make book on. [Although admittedly, the XCON versus MEDIACTRL was the *ONLY* bet I have lost so far.]

Let's stop pontificating and get to work. Your AD's can beat you about the head about insane dates. The work is what is important.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 9 Aug 2013 17:02:14 -0700

I think you're massively overrating the importance of the existence of
an RFC on this topic. However, I agree we should emphasize the
importance of an anonymous option.

-Ekr

On Fri, Aug 9, 2013 at 3:18 PM, Eric Burger <[email-masked]>wrote:

> It is one thing for the regulators to say "be bad." It is another thing
> for the regulators to say "do bad things because the IETF says it is good."
>
> > > whatever, but I don't think we're that stupid. (nor do I think it
> would get published by the IETF, nor would anyone use it if we did)
> > >
> > > No one is proposing, for example, that anonymous calls no longer
> remain anonymous.  Nor that one can't make anonymous calls.
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Aug 2013 20:36:51 -0400

> It is one thing for the regulators to say "be bad." It is another thing for the regulators to say "do bad things because the IETF says it is good."

Wow, that is an impressive spin. :)

Last time I checked, the regulators didn't exactly consult the IETF on policy decisions.  We don't pay nearly enough lobbyists.  I mean I'm sure there're quite a few MUST and MUST NOT statements the IETF would like to send their way on various topics, but methinks it would fall on deaf ears.

Regardless, how do you propose we solve this dilemma?  Add a "MUST NOT block anonymous requests" type statement in the RFCs?  I'm cool with doing that, fwiw.  I think it would be ignored though, if regulators decided to block them anyway.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 12 Aug 2013 12:38:42 -0400

How do you define anonymous calling? 

What the network has to see to route the call or what is displayed on the
User Agent?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Rescorla
Sent: Friday, August 09, 2013 8:02 PM
To: Eric Burger
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-Ekr

On Fri, Aug 9, 2013 at 3:18 PM, Eric Burger <[email-masked]
<mailto:[email-masked]> > wrote:

It is one thing for the regulators to say "be bad." It is another thing for
the regulators to say "do bad things because the IETF says it is good."

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Aug 2013 09:54:04 -0700

What the ordinary callee sees. I.e., the properties I take the current
system to
have.

-Ekr

On Mon, Aug 12, 2013 at 9:38 AM, Richard Shockey <[email-masked]> wrote:

> How do you define anonymous calling? ****
>
> ** **
>
> User Agent?****
> ** **
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Eric Rescorla
> *Sent:* Friday, August 09, 2013 8:02 PM
>
> *To:* Eric Burger
> *Cc:* [email-masked]
> *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to Charter)*
> ***
>
> ** **
>
> I think you're massively overrating the importance of the existence of****
>
> an RFC on this topic. However, I agree we should emphasize the****
>
> importance of an anonymous option.****
>
> ** **
>
> -Ekr****
>
> ** **
>
> ** **
>
> On Fri, Aug 9, 2013 at 3:18 PM, Eric Burger <[email-masked]>
> wrote:****
>
> ****
> >****
> https://www.ietf.org/mailman/listinfo/stir****
>
> ** **
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Aug 2013 14:53:26 -0400

With regards to a threat document, I've been writing up one for STIR and have been shamelessly copying from the BGP Path Security one cited in the email below.

I notice that the BGP one covers attacks against each and every actor in the system, including routers themselves; and many forms of attack.  Were all the threats/attacks in the draft ones the SIDR WG was concerned about, or they were all listed just to be comprehensive?  In other words, should a STIR threat doc cover every possible threat we can come up with, or only the ones we think are relevant to STIR?

For example, the BGP one included various MITM attacks, which we don't seem as concerned with for STIR - should the doc cover all of those in detail as well, or just say "this is not considered relevant for STIR"?

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Mon, 12 Aug 2013 19:04:11 +0000

May be best to briefly describe what the threat is, what are mitigating
factors, and why STIR chose not to focus on that.
At least then readers know it was conscious decision and not an omission.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Monday, August 12, 2013 2:53 PM
To: Stephen Kent
Cc: [email-masked] Mail List; Dave Crocker
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

With regards to a threat document, I've been writing up one for STIR and
have been shamelessly copying from the BGP Path Security one cited in the
email below.

I notice that the BGP one covers attacks against each and every actor in the
system, including routers themselves; and many forms of attack.  Were all
the threats/attacks in the draft ones the SIDR WG was concerned about, or
they were all listed just to be comprehensive?  In other words, should a
STIR threat doc cover every possible threat we can come up with, or only the
ones we think are relevant to STIR?

For example, the BGP one included various MITM attacks, which we don't seem
as concerned with for STIR - should the doc cover all of those in detail as
well, or just say "this is not considered relevant for STIR"?

-hadriel

On Aug 1, 2013, at 2:59 AM, Stephen Kent <[email-masked]> wrote:

> (draft-ietf-sidr-bgpsec-threats-05), which is now in the hands of the 
> RTG ADs, as an example of what I have in mind. It addresses a fairly 
> complex, global system, so I would not expect an analogous doc for STIR to
be any longer.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 12 Aug 2013 20:20:17 +0000

There is a relatively lengthy section on threats already in the
secure-origin-ps-01 document (5.7) which lays out at least the
fundamentals (actors, scenarios, etc), without going into the attack
surface created by the solutions. Going in to the last meeting, my
understanding was we wanted this text to be in the problem statement
document; now that it's a separate deliverable in the proposed charter,
that text probably doesn't belong in the problem statement document
anymore.

Jon Peterson
Neustar, Inc.

On 8/12/13 11:53 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>I notice that the BGP one covers attacks against each and every actor in
>the system, including routers themselves; and many forms of attack.  Were
>all the threats/attacks in the draft ones the SIDR WG was concerned
>about, or they were all listed just to be comprehensive?  In other words,
>should a STIR threat doc cover every possible threat we can come up with,
>or only the ones we think are relevant to STIR?
>
>For example, the BGP one included various MITM attacks, which we don't
>seem as concerned with for STIR - should the doc cover all of those in
>detail as well, or just say "this is not considered relevant for STIR"?
>
>-hadriel
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Aug 2013 21:17:05 +0000

Apologies if I missed this discussion among the 300+ STIR messages, but I think it would help if we distinguished two kinds of anonymous calls:

* truly anonymous, i.e., none of the carriers knows the identity of the caller

* callerID suppressed calls, i.e., the carriers do.

Most anonymous calls today fall into the second category, i.e., if you are stupid enough to call in a threat using *67 callerID suppression from your home phone, you will likely have the doorbell ring pretty quickly. Payphones and cash-paid prepay phones offer an approximation of the first kind of anonymity.

Even the first kind aren't really fully anonymous - with a subpoena and assuming a domestic or friendly-foreign caller, you can find out who made the call (or at least which payphone), by tracing the call through its path based only on time and destination numbers. Happens all the time (and that's how domestic boiler room operators are caught, among other ways).

Thus, I think it would help the discussion to be very precise what kind of anonymity is being preserved or threatened. In many cases, such as 1-800 tip lines, this is really more like a promise not to trace the call, not a technical, TOR-like, feature, or anonymity towards the callee.

CallerID suppression does not appear to be impacted by signing; stating this as a goal, however, is useful. You could argue that if callees knew that nuisance and other illegal callers could be identified if they crossed the threshold into illegality, they'd be more likely to be accepted.

Henning

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Thursday, August 08, 2013 11:24 PM
To: Eric Burger
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Aug 2013 21:22:47 +0000

Looks good to me. It is not clear, however, whether " A called party will receive an indication that the source telephone number is unavailable in order to provide anonymity. " refers to a description of the status quo or a charter goal. This sounds like the existing SIP mechanism to me.

Henning

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Friday, August 09, 2013 10:01 AM
To: Brian Rosen
Cc: [email-masked]; IETF STIR Mail List; Stephen Kent
Subject: Re: [stir] Moving from BOF to Charter

Russ

= = = = = = = = 

Chairs: TBD

The STIR working group will specify mechanisms for the validation of source telephone number for an incoming call.  Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade.  As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments).  In addition, use of an incorrect source telephone number facilitates wire fraud or lead to a return call at premium rates.  This working group will define mechanisms that verify the authorization of the calling party to use a particular telephone number.

SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number.
Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working group.
To date, however, true validation of the source of SIP calls has not seen any appreciable deployment.  Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authority over telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model.  To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers.

As its priority mechanism work item, the working group will specify a SIP header-based mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end.  This is called an in-band mechanism.
The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.  The working group will consider choices for protecting identity information and credentials used, but will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key and is associated with the one or more telephone numbers.
In order to be authoritative, credentials used with this mechanism will be derived from existing telephone number assignment and delegation models.  That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or
modified) to reflect such delegation.  The mechanism must allow a telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme.

In addition to its priority mechanism work item, the working group will consider session establishment where there are one or more non-SIP hops, most likely using an out-of-band mechanism.  However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials.  The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism.

Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

The working group will coordinate with the Security Area on credential management.

The working group will coordinate with other working groups in the RAI Area regarding signaling through existing deployments.

Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy.  Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards.  A called party will receive an indication that the source telephone number is unavailable in order to provide anonymity.  This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to user agents or third parties than a call that does not make use of secure telephone identification mechanisms.

Milestones

---

From: Brian Rosen <[email-masked]>
Date: Mon, 12 Aug 2013 17:57:20 -0400

It's supposed to be either of the two existing mechanisms (actual sending
of anonymous From and suppresssion of callerid at the termination network).
 In either case, you get an indication in the signaling of what occurred.

Brian

On Monday, August 12, 2013, Henning Schulzrinne wrote:

> Looks good to me. It is not clear, however, whether " A called party will
> receive an indication that the source telephone number is unavailable in
> order to provide anonymity. " refers to a description of the status quo or
> a charter goal. This sounds like the existing SIP mechanism to me.
>
> Henning
>
> On Behalf Of Russ Housley
> Cc: [email-masked] <javascript:;>; IETF STIR Mail List; Stephen Kent
> source telephone number for an incoming call.  Since it has become fairly
> easy to present an incorrect source telephone number, a growing set of
> problems have emerged over the last decade.  As with email, the claimed
> source identity of a SIP request is not verified, permitting unauthorized
> use of the source identity as part of deceptive and coercive activities,
> such as robocalling (bulk unsolicited commercial communications), vishing
> (voicemail hacking, and impersonating banks) and swatting (impersonating
> callers to emergency services to stimulate unwarranted large scale law
> enforcement deployments).  In addition, use of an incorrect source
> telephone number facilitates wire fraud or lead to a return call at premium
> rates.  This working group will define mechanisms that verify the
> authorization of the calling party to use a particular telephone number.
>
> telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with
> the complex deployment environment that has emerged for SIP; lack of
> computational overhead, and administrative overhead for the legitimate call
> source and all verifiers.
>
> authorized to use the claimed source telephone number, where the session is
> established with SIP end to end.  This is called an in-band mechanism.
> specified by the working group, including any mappings that might be needed
> between the SIP header fields and the canonical telephone number
> header fields, and verification will employ a credential that contains the
> public key and is associated with the one or more telephone numbers.
> In order to be authoritative, credentials used with this mechanism will be
> derived from existing telephone number assignment and delegation models.
>  That is, when a telephone number or range of telephone numbers is
> delegated to an entity, relevant credentials will be generated (or
> especially the credentials.  The in-band mechanism must be sent to the IESG
> for approval and publication prior to the out-of-band mechanism.
>
> Authentication and authori_______________________________________________
> stir mailing list

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Aug 2013 22:11:55 +0000

Thanks. My suggestion would be to make it clear that we're not looking to do any new work here (e.g., new privacy or CLID suppression headers), maybe simply by grammatically tying the sentence to the previous one.

From: Brian Rosen [mailto:[email-masked]]
Sent: Monday, August 12, 2013 5:57 PM
To: Henning Schulzrinne
Cc: Russ Housley; [email-masked]; IETF STIR Mail List; Stephen Kent
Subject: Re: [stir] Moving from BOF to Charter

It's supposed to be either of the two existing mechanisms (actual sending of anonymous From and suppresssion of callerid at the termination network).  In either case, you get an indication in the signaling of what occurred.

Brian

Henning

-----Original Message-----
From: [email-masked]<javascript:;> [mailto:[email-masked]<javascript:;>] On Behalf Of Russ Housley
Sent: Friday, August 09, 2013 10:01 AM
To: Brian Rosen
Cc: [email-masked]<javascript:;>; IETF STIR Mail List; Stephen Kent
Subject: Re: [stir] Moving from BOF to Charter

Russ

= = = = = = = =

Chairs: TBD

Mailing list: [email-masked]<mailto:[email-masked]>
To Subscribe: https://www.ietf.org/mailman/listinfo/stir

Authentication and authori_______________________________________________
stir mailing list
[email-masked]<javascript:;>
https://www.ietf.org/mailman/listinfo/stir

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Aug 2013 12:53:00 -0400

Eric,

OK, then we ought to do better than *67 :-).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Aug 2013 13:01:53 -0400

Hadriel,

The threat doc was prepared rather late in the process, after the RPKI 
work was done
(published as RFCs), but before the BGPSEC work was completed. So, we 
had the advantage
(burden?) of reviewing the RPKI threats, since BGPSEC relies on the RPKI.

For the STIR context, I'd suggest staring with the threat 
characterization (adversary
classes, capabilities, and motivations). Then discuss components of the 
systems and
how they might be attacked, based on the threat exposition.

Since this is a doc being prepared early in the process, I would expect 
less detail,
especially in the attack discussion.

As for MITM, one reason that I have suggested generating a doc of this 
sort is to
clarify where MITM attacks are viewed as out of scope. Is it in all 
points in the
system, or only some?

Steve

---

From: Michael Hammer <[email-masked]>
Date: Tue, 13 Aug 2013 17:07:54 +0000

Could we try to avoid sliding down the slippery slope of designing a bunch
of supplementary services?
If we have to do it, let's focus on one:  assert number, sign it, validate
it.  Put out RFC.

We already have an assert anonymous feature.  This just needs to define how
you sign that.
Anything more starts getting into vendor's implementations.

Granted we have to have some of the others in back of mind.  
But as someone who one had to test 400+ features on a major vendor's switch,

this could easily diverge into a feature beauty contest.

Whether you use this one new feature or not, or block it in some way is next
release.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Tuesday, August 13, 2013 12:53 PM
To: Eric Burger
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Eric,

Steve
On 8/8/13 7:54 PM, Eric Burger wrote:
> *67 only blocks the delivery of the caller ID to the called party. The
network gets it, even often up to the called party's PBX. This relies on the
good graces of the PBX implementor to honor the privacy bit.
_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Aug 2013 10:19:38 -0700

> We already have an assert anonymous feature.  This just needs to define how

Is that really needed?  Offhand, it sounds like it wouldn't be useful...

The point behind 'anonymous' is to refrain from asserting a meaningful 
identity.  In the absence of such an assertion, it doesn't mean anything 
to 'validate' the Caller-ID.

In other words, your nice, simple suggestion for focus looks exactly 
right, with the note that not all caller-ids will be (or need to be) 
signed, and notably not 'anonymous'.

d/

---

From: Michael Hammer <[email-masked]>
Date: Tue, 13 Aug 2013 17:46:57 +0000

Only wanted to consider the possibility mentioned before of known by
carrier, but anonymous otherwise.

Mike

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Tuesday, August 13, 2013 1:20 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

On 8/13/2013 10:07 AM, Michael Hammer wrote:
> Could we try to avoid sliding down the slippery slope of designing a 
> bunch of supplementary services?
> If we have to do it, let's focus on one:  assert number, sign it, 
> validate it.  Put out RFC.
>
> We already have an assert anonymous feature.  This just needs to 
> define how you sign that.

The point behind 'anonymous' is to refrain from asserting a meaningful
identity.  In the absence of such an assertion, it doesn't mean anything to
'validate' the Caller-ID.

In other words, your nice, simple suggestion for focus looks exactly right,
with the note that not all caller-ids will be (or need to be) signed, and
notably not 'anonymous'.

d/

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 13 Aug 2013 18:05:06 +0000

Looks good. Ship it.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Aug 2013 11:11:52 -0700

> carrier, but anonymous otherwise.

That's a very specialized semantic.

It's not entirely clear what benefit it would produce, and it's not 
obvious how the semantic would be encoded.

d/

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 13 Aug 2013 14:14:44 -0400

Well that's fine for now but in the future you have to consider how to
display enhanced user, anonymous, unknown, validation data on the User
Agents.

CNAM only gives you 15 ASCII characters and I'm going to assume someone
might like something better in the future. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Hammer
Sent: Tuesday, August 13, 2013 1:08 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike

-----Original Message-----

Eric,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Aug 2013 14:32:11 -0400

Russ,

> use of secure telephone identification mechanisms.
I like the first few sentences. Given the additional info provided by
Eric re who along the call path see what caller ID info, we probably
should say that we plan to explore options re privacy in that arena.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Aug 2013 14:36:31 -0400

Russ,

I'm comfortable with the current charter text.

Steve

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 Aug 2013 15:08:39 -0400

Thanks, everyone.  I've sent the charter to the IESG for approval.
--Richard

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 13 Aug 2013 21:32:34 -0400

I'm sorry to be a skunk here but no one as bothered to answer my question or
elaborate a theory of how CUA's display rich text reputation data? 

What is the successor to CNAM? 

What can the network deliver to the consumer that they may or may not be
able to make a judgment on. 

I call the pizza place it returns a HTTP <foo> on specials before the call
is delivered.. And validates the data etc.   

UPS/FEDEX the inbound SMS delivers rich text delivery data in real time.  

What the network can process is almost irrelevant if the CUA can't display
it.  

Its orthogonal to the STIR problem statement but you can't ignore the
implications.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Shockey
Sent: Tuesday, August 13, 2013 2:15 PM
To: 'Michael Hammer'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-----Original Message-----

Mike

-----Original Message-----

Eric,

Steve

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 04:20:16 +0200

> What is the successor to CNAM?

That's an interesting question.

If there were a cert per phone number, then the CNAM data could be in 
the cert, eliminating another retrieval. But it seems that isn't being 
viewed as an attractive way to go.

Otherwise, it remains yet another DB that needs to be queried.
At least that query could be in parallel with verifying the signature on 
the number.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Aug 2013 07:01:35 -0400

I don't follow you - as you say it's orthogonal to STIR.  STIR validates the source identity E.614 number, and if that number is legit then it can be used for a lookup to retrieve CNAM info; or both database lookups can be done simultaneously and the CNAM info can be used if the validation is successful.  That's assuming you perform a database lookup for CNAM info for such information.

Of course SIP always had the Call-Info header, but it's basically never used afaik.  Historically it was useless because it never made it through PSTN gateways or B2BUAs, and most SIP UAs don't pay attention to it.  And even if it got sent through you could never trust it.  Even if you knew the caller claiming to be +16035551234 was really from that E.164 number, you couldn't trust the caller was Fidelity or Citibank or PayPal or whatever just because it claimed it was, in a Call-Info header.  Using a separate database for that information is better because the caller couldn't just claim to be whatever it wanted to.  Not that the CNAM database contents are perfect either (my home number has a wrong CNAM entry, for example)... but it's like a reverse lookup in the white/yellow pages, and they're generally ok.

If you mean where should the CNAM-type info go in SIP, I believe the most common thing is to put it as the display-name portion of the From.  I'm not saying that's a good place to put it, but that's where I see it put most often, I think.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Aug 2013 07:45:38 -0400

On Aug 13, 2013, at 10:20 PM, Paul Kyzivat <[email-masked]> wrote:

> If there were a cert per phone number, then the CNAM data could be in the cert, eliminating another retrieval.

There was some discussion around that early on.  I think there was concern about making the signing CAs have to verify CNAM-type info in a cert signing request before signing it.  

If they don't perform verification that you really are the name for the phone-number, then you could claim any name you wanted; if they do perform verification, it's either through a manual process and very expensive (as web certs are today), or the CA uses a CNAM database to populate the info in the cert without letting you choose what to put in it.  

It happens to be that in the US the numbering admin contractor and the most popular CNAM database are the same company, but my guess is there are regulatory restrictions around how integrated they can be. (I don't know that to be the case, but it's just a guess that antitrust issues would make it so... but IANAL)

Regardless, it also hits pricing/charging issues.  Currently the CNAM database providers charge the terminating side for retrieval, and I don't think we want that type of model for STIR at all. (as an aside: it's always seemed crazy to me that the terminating side pays for CNAM, rather than the opposite - I know how it came about to be that way, but I think it's counter-productive today)

> But it seems that isn't being viewed as an attractive way to go.

I don't know what you mean by that comment?  Using certs for STIR is most definitely on the table.  There're pros/cons with any proposed solution thus far.  The CIDER concept has warts too.  Ultimately we're going to have to choose, but there's no "perfect" solution as far as I can tell.

> Otherwise, it remains yet another DB that needs to be queried.

Not necessarily.  Even with a CIDER approach one could put the CNAM info in the same database, and in such a way that a single query returns both STIR and CNAM info at the same time.  You could, for example, put it in a NAPTR like was done in draft-ietf-enum-cnam-08, or you could put it in another TXT RR, or whatever.  Of course if you do that then the CIDER database could not be made publicly accessible, or at least the CNAM info record could not be made publicly accessible.

But even if the national CIDER database doesn't have the CNAM info, the local database copies of it in the carriers could integrate the CNAM info into their local copies.  That way they get to have a single query/response model, even if the data comes from different sources.

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Wed, 14 Aug 2013 09:31:44 -0400

I think we probably should keep CNAM out of this for now anyway.

The advantage of the credential delegation process as we have defined it is
that it's authoritative.

The current CNAM databases cannot be called "authoritative" really.
 Classically, as you describe, there is a database operated by on on behalf
of the origination carrier and queried by the termination carrier (often
with a charge to query).  The content is what the carrier has recorde from
the original service order, but there isn't any attempt to validate those
names, and there are carriers who will let you put anything you like in
there.  How "authoritative" is that?  Then there are other databases, like
Neustar's, that don't have any relationship to the originination carrier -
the termination carrier dips an independently developed database of
name-number relationships.  These databases are developed using a wide
variety of sources and have evolved to be very accurate, but hardly
"authoritative".

And yes, Hadriel, there are regulatory restrictions, mostly about what the
NPAC (number portability database administrator) can do. The CNAM databases
have very few regulations to deal with.

Brian

On Wednesday, August 14, 2013, Hadriel Kaplan wrote:

>
> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat <[email-masked]<javascript:;>>
> wrote:
>
> the cert, eliminating another retrieval.
>
> There was some discussion around that early on.  I think there was concern
> about making the signing CAs have to verify CNAM-type info in a cert
> signing request before signing it.
>
> If they don't perform verification that you really are the name for the
> phone-number, then you could claim any name you wanted; if they do perform
> verification, it's either through a manual process and very expensive (as
> web certs are today), or the CA uses a CNAM database to populate the info
> in the cert without letting you choose what to put in it.
>
> It happens to be that in the US the numbering admin contractor and the
> most popular CNAM database are the same company, but my guess is there are
> regulatory restrictions around how integrated they can be. (I don't know
> that to be the case, but it's just a guess that antitrust issues would make
> it so... but IANAL)
>
> Regardless, it also hits pricing/charging issues.  Currently the CNAM
> database providers charge the terminating side for retrieval, and I don't
> think we want that type of model for STIR at all. (as an aside: it's always
> seemed crazy to me that the terminating side pays for CNAM, rather than the
> opposite - I know how it came about to be that way, but I think it's
> counter-productive today)
>
>
> I don't know what you mean by that comment?  Using certs for STIR is most
> definitely on the table.  There're pros/cons with any proposed solution
> thus far.  The CIDER concept has warts too.  Ultimately we're going to have
> to choose, but there's no "perfect" solution as far as I can tell.
>
>
> Not necessarily.  Even with a CIDER approach one could put the CNAM info
> in the same database, and in such a way that a single query returns both
> STIR and CNAM info at the same time.  You could, for example, put it in a
> NAPTR like was done in draft-ietf-enum-cnam-08, or you could put it in
> another TXT RR, or whatever.  Of course if you do that then the CIDER
> database could not be made publicly accessible, or at least the CNAM info
> record could not be made publicly accessible.
>
> But even if the national CIDER database doesn't have the CNAM info, the
> local database copies of it in the carriers could integrate the CNAM info
> into their local copies.  That way they get to have a single query/response
> model, even if the data comes from different sources.
>
> -hadriel
>

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Wed, 14 Aug 2013 14:36:56 +0000

I assume the concern in this thread is with the case where a number might be authenticated but the CNAM displayed would be misleading because of lax policies of the CNAM provider - e.g., the bad guy makes a call from what is indeed his legit number but has managed to get Bank of America into his CNAM entry.

I'm thinking that taking on CNAM in the ietf may be a bridge too far for stir. Leave what happens after the number is validated up to national authorities since arrangements may differ. And at least in the case above it should be possible to trace back to the perp.

More generally I think the object of stir ought to be just to provide the customer an indication of whether the calling number was validated on not - whether calls get blocked or unvalidated numbers are still displayed should be up to the customer and their service provider.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, August 14, 2013 9:32 AM
To: Hadriel Kaplan
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

The advantage of the credential delegation process as we have defined it is that it's authoritative.

The current CNAM databases cannot be called "authoritative" really.  Classically, as you describe, there is a database operated by on on behalf of the origination carrier and queried by the termination carrier (often with a charge to query).  The content is what the carrier has recorde from the original service order, but there isn't any attempt to validate those names, and there are carriers who will let you put anything you like in there.  How "authoritative" is that?  Then there are other databases, like Neustar's, that don't have any relationship to the originination carrier - the termination carrier dips an independently developed database of name-number relationships.  These databases are developed using a wide variety of sources and have evolved to be very accurate, but hardly "authoritative".

And yes, Hadriel, there are regulatory restrictions, mostly about what the NPAC (number portability database administrator) can do. The CNAM databases have very few regulations to deal with.

Brian

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 16:51:41 +0200

I'm now convinced that CNAM should be out of scope for now, to avoid a 
rat hole.

I can imagine that this might need to be revisited again in the future, 
probably as a different WG.

	Thanks,
	Paul

On 8/14/13 3:31 PM, Brian Rosen wrote:
>   Classically, as you describe, there is a database operated by on on
> behalf of the origination carrier and queried by the termination carrier
> (often with a charge to query).  The content is what the carrier has
> recorde from the original service order, but there isn't any attempt to
> validate those names, and there are carriers who will let you put
> anything you like in there.  How "authoritative" is that?  Then there
> are other databases, like Neustar's, that don't have any relationship to
> the originination carrier - the termination carrier dips an
> independently developed database of name-number relationships.  These
> databases are developed using a wide variety of sources and have evolved
> to be very accurate, but hardly "authoritative".
>
> And yes, Hadriel, there are regulatory restrictions, mostly about what
> the NPAC (number portability database administrator) can do. The CNAM
> databases have very few regulations to deal with.
>
> Brian
>
>      > If there were a cert per phone number, then the CNAM data could
>     be in the cert, eliminating another retrieval.
>
>     There was some discussion around that early on.  I think there was
>     concern about making the signing CAs have to verify CNAM-type info
>     in a cert signing request before signing it.
>
>     If they don't perform verification that you really are the name for
>     the phone-number, then you could claim any name you wanted; if they
>     do perform verification, it's either through a manual process and
>     very expensive (as web certs are today), or the CA uses a CNAM
>     database to populate the info in the cert without letting you choose
>     what to put in it.
>
>     It happens to be that in the US the numbering admin contractor and
>     the most popular CNAM database are the same company, but my guess is
>     there are regulatory restrictions around how integrated they can be.
>     (I don't know that to be the case, but it's just a guess that
>     antitrust issues would make it so... but IANAL)
>
>     Regardless, it also hits pricing/charging issues.  Currently the
>     CNAM database providers charge the terminating side for retrieval,
>     and I don't think we want that type of model for STIR at all. (as an
>     aside: it's always seemed crazy to me that the terminating side pays
>     for CNAM, rather than the opposite - I know how it came about to be
>     that way, but I think it's counter-productive today)
>
>
>     I don't know what you mean by that comment?  Using certs for STIR is
>     most definitely on the table.  There're pros/cons with any proposed
>     solution thus far.  The CIDER concept has warts too.  Ultimately
>     we're going to have to choose, but there's no "perfect" solution as
>     far as I can tell.
>
>
>     Not necessarily.  Even with a CIDER approach one could put the CNAM
>     info in the same database, and in such a way that a single query
>     returns both STIR and CNAM info at the same time.  You could, for
>     example, put it in a NAPTR like was done in draft-ietf-enum-cnam-08,
>     or you could put it in another TXT RR, or whatever.  Of course if
>     you do that then the CIDER database could not be made publicly
>     accessible, or at least the CNAM info record could not be made
>     publicly accessible.
>
>     But even if the national CIDER database doesn't have the CNAM info,
>     the local database copies of it in the carriers could integrate the
>     CNAM info into their local copies.  That way they get to have a
>     single query/response model, even if the data comes from different
>     sources.
>
>     -hadriel
>

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 14 Aug 2013 13:01:30 -0400

I agree. I'll shut up now. It is a "bridge too far". 

I was just trying to "think out loud" on how the UA's might deal with this
new class of data.  

CNAM itself is badly broken and nonfunctional in an all SIP world.

You can return to your regularly scheduled program. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Wednesday, August 14, 2013 10:52 AM
To: Brian Rosen
Cc: [email-masked]; Hadriel Kaplan
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

I'm now convinced that CNAM should be out of scope for now, to avoid a rat
hole.

	Thanks,
	Paul

On 8/14/13 3:31 PM, Brian Rosen wrote:
> behalf of the origination carrier and queried by the termination 
> carrier (often with a charge to query).  The content is what the 
> carrier has recorde from the original service order, but there isn't 
> any attempt to validate those names, and there are carriers who will 
> let you put anything you like in there.  How "authoritative" is that?  
> Then there are other databases, like Neustar's, that don't have any 
> relationship to the originination carrier - the termination carrier 
> dips an independently developed database of name-number relationships.  
> These databases are developed using a wide variety of sources and have 
> evolved to be very accurate, but hardly "authoritative".
>

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 14 Aug 2013 13:50:28 -0400

Would it be possible to provide an indication of whether the calling name was validated (in the same sense that the calling number was validated, but an independent indication)?

ISTM that should be a simple exercise, protocol-wise.  And it maintains the parallel treatment of name and number that we have today (e.g., there are today separate indications of privacy, for name and number).  But that's not my main concern; mostly I'm thinking of the evolution of the process by which calling name is provided.  Even if it's not possible to validate calling name as provided by CNAM, it might be possible to validate calling name as provided by other methods; e.g., by the calling network in the display-name header field in the FROM or (more likely in public networks) the P-A-ID header.

tim

From: [email-masked] [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L
Sent: Wednesday, August 14, 2013 9:37 AM
To: Brian Rosen; Hadriel Kaplan
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Penn Pfautz
AT&T Access Management
+1-732-420-4962
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, August 14, 2013 9:32 AM
To: Hadriel Kaplan
Cc: [email-masked]<mailto:[email-masked]>; Paul Kyzivat
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Brian

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Wed, 14 Aug 2013 14:38:12 -0400

I suppose it's possible, but what is the criteria for validation?

With TNs, we have credentials that accompany number delegation - we have a
clear path to assuring that the caller asserting the identity is indeed
entitled to claim control of that number (well, SPs mostly, not the caller,
at least initially).  There is no equivalent assurance for CNAM.

I don't want to get into a fight over which database is better, but the
alternate, doesn't depend on the origination carrier mechansism is
statisically actually a better "validation" of the content than what a
traditional carrier gets in his service order (because they usually don't
actually validate the content), and is infiniately better than the carriers
that allow the consumer to put anything they want in the database.  Without
a reasonable way to assure that the database is actually valid, what is the
value of carrying an assertion?

If we had such a mechanism, what prevents one of the carriers that let's
you put anything you want in the database from asserting that the content
of P-A-ID is valid, when the user is allowed to say whatever they want goes
in P-A-ID?

The best thing I can come up with would be to have some independent
validation service that used other data sources to validate the content,
and let them sign it.  Then we could carry that signature somewhere.

Right now, I think we should leave it out of scope.  If we can figure out a
way to do validation, then we can revisit the notion of carrying evidence
of validation in future work.

Does argue for making sure that whatever mechanism we arrive at should have
some obvious extension mechanism, perhaps along the lines of what Jon was
suggesting for media properties.  If you recall, he proposed to have a
digest of SDP where the digest was protected by the signature, but if the
SDP received didn't match the SDP sent, the termination side could know
that, but the basic identity mechanism could succeed anyway (that is, you
knew you had a valid identity and a modified SDP).

Brian

On Wednesday, August 14, 2013, Dwight, Timothy M (Tim) wrote:

> Would it be possible to provide an indication of whether the calling name
> was validated (in the same sense that the calling number was validated, but
> an independent indication)?****
>
> ** **
>
> ISTM that should be a simple exercise, protocol-wise.  And it maintains
> the parallel treatment of name and number that we have today (e.g., there
> are today separate indications of privacy, for name and number).  But
> that’s not my main concern; mostly I’m thinking of the evolution of the
> process by which calling name is provided.  Even if it’s not possible to
> validate calling name as provided by CNAM, it might be possible to validate
> calling name as provided by other methods; e.g., by the calling network in
> the display-name header field in the FROM or (more likely in public
> networks) the P-A-ID header.****
>
> ** **
>
> tim****
>
> ** **
>
> ** **
>
> *On Behalf Of *PFAUTZ, PENN L
> *Sent:* Wednesday, August 14, 2013 9:37 AM
> *To:* Brian Rosen; Hadriel Kaplan
> *Cc:* [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>; Paul
> Kyzivat
> I assume the concern in this thread is with the case where a number might
> be authenticated but the CNAM displayed would be misleading because of lax
> policies of the CNAM provider – e.g., the bad guy makes a call from what is
> indeed his legit number but has managed to get Bank of America into his
> CNAM entry.****
>
> ** **
>
> I’m thinking that taking on CNAM in the ietf may be a bridge too far for
> stir. Leave what happens after the number is validated up to national
> authorities since arrangements may differ. And at least in the case above
> it should be possible to trace back to the perp.****
>
> ** **
>
> More generally I think the object of stir ought to be just to provide the
> customer an indication of whether the calling number was validated on not –
> whether calls get blocked or unvalidated numbers are still displayed should
> be up to the customer and their service provider.****
>
> ** **
>
> Penn Pfautz****
>
> AT&T Access Management****
>
> +1-732-420-4962****
>
> Of *Brian Rosen
> *Sent:* Wednesday, August 14, 2013 9:32 AM
> *To:* Hadriel Kaplan
> *Cc:* [email-masked]; Paul Kyzivat
> I think we probably should keep CNAM out of this for now anyway.****
>
> ** **
>
> The advantage of the credential delegation process as we have defined it
> is that it's authoritative.****
>
> ** **
>
> "authoritative".****
> have very few regulations to deal with.****
>
> ** **
>
> Brian ****
>
>
> On Wednesday, August 14, 2013, Hadriel Kaplan wrote:****
>
>
> On Aug 13, 2013, at 10:20 PM, Paul Kyzivat <pk
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 21:03:44 +0200

On 8/14/13 8:38 PM, Brian Rosen wrote:
> With TNs, we have credentials that accompany number delegation - we have
> a clear path to assuring that the caller asserting the identity is
> indeed entitled to claim control of that number (well, SPs mostly, not
> the caller, at least initially).  There is no equivalent assurance for
> CNAM.
>
> traditional carrier gets in his service order (because they usually
> don't actually validate the content), and is infiniately better than the
> carriers that allow the consumer to put anything they want in the
> database.  Without a reasonable way to assure that the database is
> actually valid, what is the value of carrying an assertion?

While I recognize that letting the customer put in whatever they want is 
problematic, I have no idea whether the alternative of letting the CNAM 
provider include whatever they want is "better". (How would we measure 
that?)

(I've just been trying to deal with an "information aggregator" that is 
publishing wrong information about me and won't change it. So I'm not 
feeling good about that sort of thing.)

ISTM that is is yet another example of ancient, informal, manual 
systems, that once mostly "worked" based on the good will of the people 
involved, but that have now been automated into monstrosities that 
nobody understands. (Management of healthcare data is another example.)

Ultimately there will need to be a big effort to develop a formal 
framework for this. And it will probably require the creation of new laws.

Alternatively this could be left to the open market. (E.g., The callee 
could just Google the calling number.)

In any case STIR can't go down this rat hole.

	Thanks,
	Paul

> you put anything you want in the database from asserting that the
> content of P-A-ID is valid, when the user is allowed to say whatever
> they want goes in P-A-ID?
>
> Right now, I think we should leave it out of scope.  If we can figure
> out a way to do validation, then we can revisit the notion of carrying
> evidence of validation in future work.
>
> Does argue for making sure that whatever mechanism we arrive at should
> have some obvious extension mechanism, perhaps along the lines of what
> Jon was suggesting for media properties.  If you recall, he proposed to
> have a digest of SDP where the digest was protected by the signature,
> but if the SDP received didn't match the SDP sent, the termination side
> could know that, but the basic identity mechanism could succeed anyway
> (that is, you knew you had a valid identity and a modified SDP).
>
> Brian
>
>     Would it be possible to provide an indication of whether the calling
>     name was validated (in the same sense that the calling number was
>     validated, but an independent indication)?____
>
>     __ __
>
>     ISTM that should be a simple exercise, protocol-wise.  And it
>     maintains the parallel treatment of name and number that we have
>     today (e.g., there are today separate indications of privacy, for
>     name and number).  But that’s not my main concern; mostly I’m
>     thinking of the evolution of the process by which calling name is
>     provided.  Even if it’s not possible to validate calling name as
>     provided by CNAM, it might be possible to validate calling name as
>     provided by other methods; e.g., by the calling network in the
>     display-name header field in the FROM or (more likely in public
>     networks) the P-A-ID header.____
>
>     __ __
>
>     tim____
>
>     __ __
>
>     __ __
>
>     *From:[email-masked] <javascript:_e({}, 'cvml',
>     [email-masked]');> [mailto:[email-masked]
>     <javascript:_e({}, 'cvml', [email-masked]');>] *On Behalf Of
>     *PFAUTZ, PENN L
>     *Cc:* [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>;
>     Paul Kyzivat
>     *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to
>     Charter)____
>
>     __ __
>
>     I assume the concern in this thread is with the case where a number
>     might be authenticated but the CNAM displayed would be misleading
>     because of lax policies of the CNAM provider – e.g., the bad guy
>     makes a call from what is indeed his legit number but has managed to
>     get Bank of America into his CNAM entry.____
>
>     __ __
>
>     I’m thinking that taking on CNAM in the ietf may be a bridge too far
>     for stir. Leave what happens after the number is validated up to
>     national authorities since arrangements may differ. And at least in
>     the case above it should be possible to trace back to the perp.____
>
>     __ __
>
>     More generally I think the object of stir ought to be just to
>     provide the customer an indication of whether the calling number was
>     validated on not – whether calls get blocked or unvalidated numbers
>     are still displayed should be up to the customer and their service
>     provider.____
>
>     __ __
>
>     Penn Pfautz____
>
>     AT&T Access Management____
>
>     +1-732-420-4962____
>
>     *From:[email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Brian Rosen
>     *Subject:* Re: [stir] Early Homework (was Re: Moving from BOF to
>     Charter)____
>
>     __ __
>
>     I think we probably should keep CNAM out of this for now anyway.____
>
>     __ __
>
>     The advantage of the credential delegation process as we have
>     defined it is that it's authoritative.____
>
>     __ __
>
>       Classically, as you describe, there is a database operated by on
>     on behalf of the origination carrier and queried by the termination
>     let you put anything you like in there.  How "authoritative" is
>     that?  Then there are other databases, like Neustar's, that don't
>     have any relationship to the originination carrier - the termination
>     carrier dips an independently developed database of name-number
>     relationships.  These databases are developed using a wide variety
>     of sources and have evolved to be very accurate, but hardly
>     "authoritative".____
>
>     __ __
>
>     And yes, Hadriel, there are regulatory restrictions, mostly about
>     what the NPAC (number portability database administrator) can do.
>     The CNAM databases have very few regulations to deal with.____
>
>     __ __
>
>     Brian ____
>
>
>     On Wednesday, August 14, 2013, Hadriel Kaplan wrote:____
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Aug 2013 15:13:34 -0400

I don't think we can solve that problem.  A different problem, which may be what Tim was getting at, is how a SIP endpoint receiving a message knows whether its local SIP Service Provider believes the calling-name is accurate or not.

In other words, suppose your SSP did use a CNAM database that was reasonably accurate, and even used a STIR-validated number to get the info from the CNAM DB.  When you receive an INVITE, which message header field do you use for calling-name display, and how do you know it was populated by your SSP based on STIR-validated information?

Today, the answer is basically that you trust your SSP to get it right; and the field a lot of folks use is the display-name portion of the From, or the display-name portion of the PAI if it's there.

The same can be said for the source identity calling number, in terms of what today's behavior is.  And even when this STIR thing gets deployed, there's no indication in SIP that your SSP actually performed STIR validation.  The assumption is it did perform it, and if the validation failed it would change the From to be 'sip:[email-masked]' or 'sip:invalid@invalid' or whatever.[1]

-hadriel
[1] I'm not saying we shouldn't be more explicit in this behavior in our docs once we get a WG, but right now it's undefined.

On Aug 14, 2013, at 2:38 PM, Brian Rosen <[email-masked]> wrote:

> With TNs, we have credentials that accompany number delegation - we have a clear path to assuring that the caller asserting the identity is indeed entitled to claim control of that number (well, SPs mostly, not the caller, at least initially).  There is no equivalent assurance for CNAM.  
> 
> I don't want to get into a fight over which database is better, but the alternate, doesn't depend on the origination carrier mechansism is statisically actually a better "validation" of the content than what a traditional carrier gets in his service order (because they usually don't actually validate the content), and is infiniately better than the carriers that allow the consumer to put anything they want in the database.  Without a reasonable way to assure that the database is actually valid, what is the value of carrying an assertion?
> 
> If we had such a mechanism, what prevents one of the carriers that let's you put anything you want in the database from asserting that the content of P-A-ID is valid, when the user is allowed to say whatever they want goes in P-A-ID?
> 
> The best thing I can come up with would be to have some independent validation service that used other data sources to validate the content, and let them sign it.  Then we could carry that signature somewhere. 
> 
> Right now, I think we should leave it out of scope.  If we can figure out a way to do validation, then we can revisit the notion of carrying evidence of validation in future work.
> 
> Does argue for making sure that whatever mechanism we arrive at should have some obvious extension mechanism, perhaps along the lines of what Jon was suggesting for media properties.  If you recall, he proposed to have a digest of SDP where the digest was protected by the signature, but if the SDP received didn't match the SDP sent, the termination side could know that, but the basic identity mechanism could succeed anyway (that is, you knew you had a valid identity and a modified SDP).
> 
> Brian
> 
> ISTM that should be a simple exercise, protocol-wise.  And it maintains the parallel treatment of name and number that we have today (e.g., there are today separate indications of privacy, for name and number).  But that’s not my main concern; mostly I’m thinking of the evolution of the process by which calling name is provided.  Even if it’s not possible to validate calling name as provided by CNAM, it might be possible to validate calling name as provided by other methods; e.g., by the calling network in the display-name header field in the FROM or (more likely in public networks) the P-A-ID header.
> 
>  
> 
> tim
> 
>  
> 
>  
> 
> I assume the concern in this thread is with the case where a number might be authenticated but the CNAM displayed would be misleading because of lax policies of the CNAM provider – e.g., the bad guy makes a call from what is indeed his legit number but has managed to get Bank of America into his CNAM entry.
> 
>  
> 
> I’m thinking that taking on CNAM in the ietf may be a bridge too far for stir. Leave what happens after the number is validated up to national authorities since arrangements may differ. And at least in the case above it should be possible to trace back to the perp.
> 
>  
> 
> More generally I think the object of stir ought to be just to provide the customer an indication of whether the calling number was validated on not – whether calls get blocked or unvalidated numbers are still displayed should be up to the customer and their service provider.
> 
>  
> 
> Penn Pfautz
> 
> AT&T Access Management
> 
> +1-732-420-4962
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Aug 2013 19:19:06 +0000

Just piling on... There are at least three levels of information here, making it difficult to do that within the signaling framework:

* the name of the person calling (vs. the subscriber name)
* the name of the organization
* properties of the organization ("licensed plumber", "FDIC-insured bank", "located in Washington, DC", "registered charity")

This is more whois-like information than just the SIP display name. In the certificate space, we have two levels: (1) assertion of domain name control; (2) EV (extended validation) certs. It would be interesting to see how well the EV concept has worked out in practice.

I don't see how signing helps here at all, for the reasons mentioned. Nefarious actors can use services such as http://www.callerid4u.com/ to use a legitimate number with just about any name string. And for corporate accounts, the service provider has no way of knowing whether Tom Sawyer is really at a particular number in a range and whether that entity prefers to list the name of the person, just the organization, the location ("PizzaHut Leonia") or something else. Indeed, the same number can legitimately have multiple display names that change quickly over time (e.g., staff at the doctor's office).

Verifiable whois-like information could be very useful and service providers could see that as an opportunity, given that they do know a lot about their customers, such as their billing and service address and how long they have been in business. But it's a separate problem, probably more closely related to the number allocation problem.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, August 14, 2013 3:04 PM
To: Brian Rosen
Cc: [email-masked]; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

On 8/14/13 8:38 PM, Brian Rosen wrote:
> With TNs, we have credentials that accompany number delegation - we 
> have a clear path to assuring that the caller asserting the identity 
> is indeed entitled to claim control of that number (well, SPs mostly, 
> not the caller, at least initially).  There is no equivalent assurance 
> for CNAM.
>
> I don't want to get into a fight over which database is better, but 
> the alternate, doesn't depend on the origination carrier mechansism is 
> don't actually validate the content), and is infiniately better than 
> the carriers that allow the consumer to put anything they want in the 

While I recognize that letting the customer put in whatever they want is problematic, I have no idea whether the alternative of letting the CNAM provider include whatever they want is "better". (How would we measure
that?)

(I've just been trying to deal with an "information aggregator" that is publishing wrong information about me and won't change it. So I'm not feeling good about that sort of thing.)

ISTM that is is yet another example of ancient, informal, manual systems, that once mostly "worked" based on the good will of the people involved, but that have now been automated into monstrosities that nobody understands. (Management of healthcare data is another example.)

Ultimately there will need to be a big effort to develop a formal framework for this. And it will probably require the creation of new laws.

Alternatively this could be left to the open market. (E.g., The callee could just Google the calling number.)

	Thanks,
	Paul

> If we had such a mechanism, what prevents one of the carriers that 
> let's you put anything you want in the database from asserting that 
> the content of P-A-ID is valid, when the user is allowed to say 
> whatever they want goes in P-A-ID?
>
> validation service that used other data sources to validate the 
> content, and let them sign it.  Then we could carry that signature somewhere.
>
> Jon was suggesting for media properties.  If you recall, he proposed 
> to have a digest of SDP where the digest was protected by the 
> signature, but if the SDP received didn't match the SDP sent, the 
> termination side could know that, but the basic identity mechanism 
> could succeed anyway (that is, you knew you had a valid identity and a modified SDP).
>
> Brian
>
>     name and number).  But that's not my main concern; mostly I'm
>     provided.  Even if it's not possible to validate calling name as
>     because of lax policies of the CNAM provider - e.g., the bad guy
>     I'm thinking that taking on CNAM in the ietf may be a bridge too far
>     validated on not - whether calls get blocked or unvalidated numbers

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 21:57:28 +0200

> The same can be said for the source identity calling number, in terms of what today's behavior is.  And even when this STIR thing gets deployed, there's no indication in SIP that your SSP actually…

ISTM that the feature you are describing can be satisfied by P-A-ID, in 
contexts where that can be trusted.

In contexts where it *can't* be trusted, then we have no solution for 
caller name.

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 14 Aug 2013 17:26:10 -0400

Oh well its August... time for leisurely conversation. 

My concern is how the UA can display the validation data for Caller ID or
what the SSP maybe/might/theoretically thinks about it.  There is a rich
vein of inquiry here but STIR is not the place to do it. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Wednesday, August 14, 2013 3:19 PM
To: 'Paul Kyzivat'; Brian Rosen
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Just piling on... There are at least three levels of information here,
making it difficult to do that within the signaling framework:

* the name of the person calling (vs. the subscriber name)
* the name of the organization
* properties of the organization ("licensed plumber", "FDIC-insured bank",
"located in Washington, DC", "registered charity")

This is more whois-like information than just the SIP display name. In the
certificate space, we have two levels: (1) assertion of domain name control;
(2) EV (extended validation) certs. It would be interesting to see how well
the EV concept has worked out in practice.

I don't see how signing helps here at all, for the reasons mentioned.
Nefarious actors can use services such as http://www.callerid4u.com/ to use
a legitimate number with just about any name string. And for corporate
accounts, the service provider has no way of knowing whether Tom Sawyer is
really at a particular number in a range and whether that entity prefers to
list the name of the person, just the organization, the location ("PizzaHut
Leonia") or something else. Indeed, the same number can legitimately have
multiple display names that change quickly over time (e.g., staff at the
doctor's office).

Verifiable whois-like information could be very useful and service providers
could see that as an opportunity, given that they do know a lot about their
customers, such as their billing and service address and how long they have
been in business. But it's a separate problem, probably more closely related
to the number allocation problem.

-----Original Message-----

ISTM that is is yet another example of ancient, informal, manual systems,
that once mostly "worked" based on the good will of the people involved, but
that have now been automated into monstrosities that nobody understands.
(Management of healthcare data is another example.)

Ultimately there will need to be a big effort to develop a formal framework
for this. And it will probably require the creation of new laws.

Alternatively this could be left to the open market. (E.g., The callee could
just Google the calling number.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Aug 2013 00:14:37 +0200

> vein of inquiry here but STIR is not the place to do it.

The limitations of callerid display on traditional phone devices really 
constrains what can be done. But we are gradually evolving away from 
those constraints. It might really be better to leave this to the device 
to deal with. Less constrained devices could easily:
- just use the info from the local address book, if there is any
- do a fairly general google-like query for info about the number
   and some heuristic pruning to choose what to display
- pop it all up in a window.

	Thanks,
	Paul

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 15 Aug 2013 15:15:42 -0400

I'm not sure what the objection to validating calling name, is.  Is it...

a)      It's too hard

b)      It's not necessary

c)      It isn't easily achieved using the solution we've already selected

The first strikes me as odd since it's been suggested that the smartphone could do it itself.  Surely whatever an app on a smartphone can do, we can do.

The second seems to leave a significant community of users still at risk.  Scammers can continue to target consumers, e.g., using numbers they've obtained from the victim's area code and with which they've been allowed by some shady entity to associate the name of the victim's bank.  Maybe that wouldn't fool a law enforcement agency or a PSAP (because they have their own identity databases), but it'd fool my mother.  I doubt she's memorized the phone number of her bank, and if she sees the name of her bank in the caller ID display (and if the nice man seems convincing) I suspect she'll believe she's talking to the bank.  Is this scenario not in scope?

Or is the real objection, that we don't want to consider requirements that don't fit (or might complicate) the solution we've already locked in on?

Tim

From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, August 14, 2013 1:38 PM
To: Dwight, Timothy M (Tim)
Cc: PFAUTZ, PENN L; Hadriel Kaplan; [email-masked]; Paul Kyzivat
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Brian

tim

From: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');> [mailto:[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>] On Behalf Of PFAUTZ, PENN L
Sent: Wednesday, August 14, 2013 9:37 AM
To: Brian Rosen; Hadriel Kaplan
Cc: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>; Paul Kyzivat
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Penn Pfautz

AT&T Access Management

+1-732-420-4962

Brian

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 15 Aug 2013 15:25:19 -0400

I suppose I would be happy with a cryptographically secure way for the called party to know what entity provided the calling name he sees on his caller ID display, and whether that entity asserts its usage to be valid.  That would let the called party make an informed decision about whether to trust what he sees.

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Wednesday, August 14, 2013 2:14 PM
To: Brian Rosen
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 15 Aug 2013 15:39:18 -0400

With respect, I think statements like " I don't see how signing helps " put the cart before the horse.  Signing is an attribute of a possible solution, not a requirement.  

It is precisely the www.callerid4u.com scenario you note, that worries me.  ISTM that if we declare any sort of validation for calling name to be out of scope, we provide no solution to the victims of scams enabled by services that allow dishonest actors to associate the name of a bank with their phone number.

I recognize that names are not delegated in the same way that numbers are, and that there are all sorts of semantic nuances that make their validation difficult.  Still, CA's do it.  And it's been proposed on this list that a smartphone app could do it.  So I don't see why we're so quick to agree we can't do it.  Or at least, do something.  

I'm a pragmatist.  Maybe we can't do as good a job validating names as we can numbers.  I still think it's better to make things better than to do nothing.  For example ISTM it'd be positive progress to enable the called party to make a more informed decision about whether to trust the calling name, than he can today.

tim

p.s. I tend to agree with Rich, that we can't forever duck the issue of what gets presented to the called party.  Whether it's addressed directly or not, we're already making assumptions about what is and isn't reasonable.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, August 14, 2013 3:04 PM
To: Brian Rosen
Cc: [email-masked]; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

	Thanks,
	Paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Aug 2013 15:52:49 -0400

Dwight,

I think the concern is that it's hard to image an appropriate, authoritative
source of this type of caller ID info. We have a great, worked example of
how not to do this in the browser environment (the current web PKI), and
a work-in-progress on how to do it right for that environment (DANE). But
the DANE model doesn't work well for the sort of names one typically sees
displayed for Caller ID.

Steve

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 15 Aug 2013 21:06:37 +0000

I fully agree that trustworthy information about the caller (identity, preferably beyond what fits into 15 characters) is a worthy goal, but traditional caller ID may just be too limited for that purpose.

The problem is that I don't see a good way to do this by signing. There are three cases I can see:

* #1: Bad (spoofed) number, spoofed text --> STIR will flag that and presumably lead recipients to ignore or question both;

* #2: Good (signed) number, spoofed text: this should only occur if there's a MITM attack where somebody replaces (say) the personal name with a misleading one ("John Doe" becomes "Bank of America")

* #3: Dodgy or careless provider: the number is legitimately assigned and signed, but the provider allows the caller to insert any textual information they want, either on-a-call-by-call basis or when signing up for service initially. As noted by others, signing doesn't help here, but you can at least identify the perpetrator and there is private recourse, such as trademark violations, that are not available for number spoofing.

Given that we've largely declared MITM and call hijacking to be out of (initial) STIR scope and that this attack vector seems somewhat unlikely in practice, that leaves case #3.

I do see one potential hijack attack that we might want to and can prevent, namely the copy-paste attack, where somebody has access to legitimate inbound calls, signed, and then re-issues the call with a spoofed textual information, assuming they don't care about the originating number (which would be the case for phishing attacks). That requires very little effort for the SIP case, and might argue for cryptographically including the text in a signature, which simply asserts that the same entity that signed the number also saw the same text, whatever its legal validity might be. If end users are allowed to sign, this doesn't help much, since they can just use case #3.

For traditional CA-issue web certs (not the EV variety), you can pretty much put anything in the organization name and the location, and you'll get issued a cert that includes that information. The only proof is that the holder has operative control of the domain name that's in the cert.

This does not apply to the CNAM case, just the inband display name case; CNAM seems similar to the "dodgy/careless" case above.

Henning

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Thursday, August 15, 2013 3:39 PM
To: Henning Schulzrinne; 'Paul Kyzivat'; Brian Rosen
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, August 14, 2013 3:04 PM
To: Brian Rosen
Cc: [email-masked]; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 15 Aug 2013 17:25:29 -0400

With respect to caller ID, at least at present, the caller id that is
usually presented to the user comes from a database as a result of a query.
 The SIP signaling protocol provides ways to carry the information, but the
data the user sees is generally the result of a CNAM dip.  That dip is done
on the termination side.

Now, that is certainly more true of legacy wireline/wireless than VoIP
endpoints, but lots of VoIP endpoints do in fact display the result of the
CNAM dip one way or another.

We can try to change that - we can try to change to using the data carried
in the call, set by the origination side and used by the termination side.

As long as there is a charge by the origination network to get the CNAM
data levied on the termination network, obsoleting those databases may be
hard.  The databases that use independently validated name-number
associations exist to avoid paying that charge.  They also generally are
more accurate because the opportunities for fraud are significantly
reduced, but they are not as comprehensive (generally, the CNAM directories
have entries for each and every TN served by a carrier.

If we changed the way the data is delivered to the termination endpoint,
then we would have to consider how to assure that it's valid, and not
messed with (MITM).  The former is the difficulty we have.

So, are you thinking we could reasonably change the entire CNAM ecosystem?

If you think that is feasible, than we can talk about what mechanisms might
be appropriate.

Brian

On Thu, Aug 15, 2013 at 5:06 PM, Henning Schulzrinne <
[email-masked]> wrote:

> I fully agree that trustworthy information about the caller (identity,
> preferably beyond what fits into 15 characters) is a worthy goal, but
> traditional caller ID may just be too limited for that purpose.
>
> * #1: Bad (spoofed) number, spoofed text --> STIR will flag that and
> presumably lead recipients to ignore or question both;
>
> * #2: Good (signed) number, spoofed text: this should only occur if
> there's a MITM attack where somebody replaces (say) the personal name with
> a misleading one ("John Doe" becomes "Bank of America")
>
> * #3: Dodgy or careless provider: the number is legitimately assigned and
> signed, but the provider allows the caller to insert any textual
> information they want, either on-a-call-by-call basis or when signing up
> for service initially. As noted by others, signing doesn't help here, but
> you can at least identify the perpetrator and there is private recourse,
> such as trademark violations, that are not available for number spoofing.
>
> Given that we've largely declared MITM and call hijacking to be out of
> (initial) STIR scope and that this attack vector seems somewhat unlikely in
> practice, that leaves case #3.
>
> I do see one potential hijack attack that we might want to and can
> prevent, namely the copy-paste attack, where somebody has access to
> legitimate inbound calls, signed, and then re-issues the call with a
> spoofed textual information, assuming they don't care about the originating
> number (which would be the case for phishing attacks). That requires very
> little effort for the SIP case, and might argue for cryptographically
> including the text in a signature, which simply asserts that the same
> entity that signed the number also saw the same text, whatever its legal
> validity might be. If end users are allowed to sign, this doesn't help
> much, since they can just use case #3.
>
> For traditional CA-issue web certs (not the EV variety), you can pretty
> much put anything in the organization name and the location, and you'll get
> issued a cert that includes that information. The only proof is that the
> holder has operative control of the domain name that's in the cert.
>
> This does not apply to the CNAM case, just the inband display name case;
> CNAM seems similar to the "dodgy/careless" case above.
>
> Henning
>
> With respect, I think statements like " I don't see how signing helps "
> put the cart before the horse.  Signing is an attribute of a possible
> solution, not a requirement.
>
> It is precisely the www.callerid4u.com scenario you note, that worries
> me.  ISTM that if we declare any sort of validation for calling name to be
> out of scope, we provide no solution to the victims of scams enabled by
> services that allow dishonest actors to associate the name of a bank with
> their phone number.
>
> I recognize that names are not delegated in the same way that numbers are,
> and that there are all sorts of semantic nuances that make their validation
> difficult.  Still, CA's do it.  And it's been proposed on this list that a
> smartphone app could do it.  So I don't see why we're so quick to agree we
> can't do it.  Or at least, do something.
>
> I'm a pragmatist.  Maybe we can't do as good a job validating names as we
> can numbers.  I still think it's better to make things better than to do
> nothing.  For example ISTM it'd be positive progress to enable the called
> party to make a more informed decision about whether to trust the calling
> name, than he can today.
>
> tim
>
> p.s. I tend to agree with Rich, that we can't forever duck the issue of
> what gets presented to the called party.  Whether it's addressed directly
> or not, we're already making assumptions about what is and isn't reasonable.
>
>
> certificate space, we have two levels: (1) assertion of domain name
> control; (2) EV (extended validation) certs. It would be interesting to see
> how well the EV concept has worked out in practice.
>
> Nefarious actors can use services such as http://www.callerid4u.com/ to
> use a legitimate number with just about any name string. And for corporate
> Verifiable whois-like information could be very useful and service
> providers could see that as an opportunity, given that they do know a lot
> about their customers, such as their billing and service address and how
> long they have been in business. But it's a separate problem, probably more
> closely related to the number allocation problem.
>
> that once mostly "worked" based on the good will of the people involved,
> but that have now been automated into monstrosities that nobody
> understands. (Management of healthcare data is another example.)
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 15 Aug 2013 18:41:25 -0400

Brian,

Please see responses inline, below.

tim

From: Brian Rosen [mailto:[email-masked]]
Sent: Thursday, August 15, 2013 4:25 PM
To: Henning Schulzrinne
Cc: Dwight, Timothy M (Tim); Paul Kyzivat; [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

With respect to caller ID, at least at present, the caller id that is usually presented to the user comes from a database as a result of a query.  The SIP signaling protocol provides ways to carry the information, but the data the user sees is generally the result of a CNAM dip.  That dip is done on the termination side.

Now, that is certainly more true of legacy wireline/wireless than VoIP endpoints, but lots of VoIP endpoints do in fact display the result of the CNAM dip one way or another.
[tmd] Agreed, this is the norm for Wireline VoIP.  What you see on your mobile is usually the result of your phone looking up the calling party number in your contact list.  At least if there's a match, that's what you see.  If there's no match, calling name information (or city/state information, or calling party's company information) may be provided by your cell phone company.  That capability is relatively recent, and certainly not universal.  A big driver for this was demand from Enterprises, who wanted something like "Sears appliance repair service" displayed when their technician calls a customer from his mobile.

We can try to change that - we can try to change to using the data carried in the call, set by the origination side and used by the termination side.
[tmd] I think this is inevitable.  The existing system is inefficient - the calling network withholds information it could have included in the setup request, forcing the terminating network to request it (and charging them for having done so).  We already see evidence of a desire to change it, in VoIP interconnect discussions with other carriers.

As long as there is a charge by the origination network to get the CNAM data levied on the termination network, obsoleting those databases may be hard.  The databases that use independently validated name-number associations exist to avoid paying that charge.  They also generally are more accurate because the opportunities for fraud are significantly reduced, but they are not as comprehensive (generally, the CNAM directories have entries for each and every TN served by a carrier.
[tmd] The first sentence is certainly true.  The rest is arguable.  I am not aware of any data regarding the relative accuracy of CNAM databases, and while it's true that the terminating network may avoid paying the originating carrier if he instead queries some 3rd party, those 3rd party services aren't free.

If we changed the way the data is delivered to the termination endpoint, then we would have to consider how to assure that it's valid, and not messed with (MITM).  The former is the difficulty we have.
[tmd] Right.  I'm trying to discuss whether it is or should be a requirement, though.  This is all good discussion, but we shouldn't just shrug things off because they're hard.  I don't want this effort to be just the latest toothless non-solution to the problem our customers experience.

So, are you thinking we could reasonably change the entire CNAM ecosystem?
[tmd] It's being discussed.  It sometimes comes up in VoIP interconnect discussions, for example.

If you think that is feasible, than we can talk about what mechanisms might be appropriate.
[tmd] I continue to find this a backwards discussion.  Nobody seems to want to talk about whether it's necessary in order to have a solution that meets the customers' needs.  We only want to talk about whether it's hard, or whether the solution we've already got in mind would easily accommodate it.

But anyway, to answer your question, Yes, I think change is feasible.  Keep in mind that the "growth areas" of telecommunications are generally not strongly vested in the status quo.

Brian

On Thu, Aug 15, 2013 at 5:06 PM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:
I fully agree that trustworthy information about the caller (identity, preferably beyond what fits into 15 characters) is a worthy goal, but traditional caller ID may just be too limited for that purpose.

Henning

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 15, 2013 3:39 PM
To: Henning Schulzrinne; 'Paul Kyzivat'; Brian Rosen
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

It is precisely the www.callerid4u.com<http://www.callerid4u.com> scenario you note, that worries me.  ISTM that if we declare any sort of validation for calling name to be out of scope, we provide no solution to the victims of scams enabled by services that allow dishonest actors to associate the name of a bank with their phone number.

tim

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Paul Kyzivat
Sent: Wednesday, August 14, 2013 3:04 PM
To: Brian Rosen
Cc: [email-masked]<mailto:[email-masked]>; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

        Thanks,
        Paul

>     *From:[email-masked]<mailto:[email-masked]> <javascript:_e({}, 'cvml',
>     [email-masked]<mailto:[email-masked]>');> [mailto:[email-masked]<mailto:[email-masked]>
>     <javascript:_e({}, 'cvml', [email-masked]<mailto:[email-masked]>');>] *On Behalf Of
>     *PFAUTZ, PENN L
>     *Cc:* [email-masked]<mailto:[email-masked]> <javascript:_e({}, 'cvml', [email-masked]<mailto:[email-masked]>');>;
>     Paul Kyzivat
>     +1-732-420-4962<tel:%2B1-732-420-4962>____
>
>     *From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] *On
>     Behalf Of *Brian Rosen
>     *Cc:* [email-masked]<mailto:[email-masked]>; Paul Kyzivat

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 15 Aug 2013 19:03:03 -0400

Henning,

I agree with what you say but I'm not sure what to conclude from it.  You seem to be saying you agree that case #3 needs to be resolved, but it's hard.  So, is it eliminated as a requirement because it's hard?  Does a solution that fails to address this, meet the public's need or the FCC mandate?

tim

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Thursday, August 15, 2013 4:07 PM
To: Dwight, Timothy M (Tim); 'Paul Kyzivat'; Brian Rosen
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Henning

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Thursday, August 15, 2013 3:39 PM
To: Henning Schulzrinne; 'Paul Kyzivat'; Brian Rosen
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, August 14, 2013 3:04 PM
To: Brian Rosen
Cc: [email-masked]; Hadriel Kaplan; Dwight, Timothy M (Tim); PFAUTZ, PENN L
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

        Thanks,
        Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Aug 2013 22:15:39 -0400

I may be misunderstanding you, but I think we're kind of getting a solution to that... though maybe not in a way that people want.

For sake of argument, let's ignore the technology or any proposed solution for STIR, or even STIR in general.  Also ignore the existing CNAM business model and pretend we wanted to provide CNAM for the first time, from scratch.

We know we can't just trust callerid4u to claim any CNAM it wanted to.  So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, and everyone has to trust them.  This CA used various sources of information and verification to create a "certificate" that said "for this phone number X, the user's name is Jane Doe", or maybe "for the holder of the private key for this public key, the user's name is Jane Doe" (which is basically what web certificates say).

So then we look at how to put this into SIP, and instead of putting the whole certificate in the INVITE, we use an external database lookup mechanism.  That's basically STIR, for the phone number part.  And the existing CNAM databases are basically the "CA", where they provide a trusted lookup database of phone-number -> CNAM.  Since STIR validates the phone number, the CNAM database lookup should be valid... assuming you trust the CNAM database to be valid to begin with.  But if you *don't* trust it, it's not clear why you'd trust any other CA either.

So we already have (or will once we have STIR) a way to get a fairly valid CNAM, if you believe in a CA model for that.  What we don't have is a different pricing/business model for how the "CA" charges for retrieving the "certificate" data.  But I don't think it's the technology that causes this really, so it's not something we can fix here.  I mean even web CAs charge an impressive amount of money for web certificates, and the technology part of the job is trivial for them, afaik.  They charge what they believe the market will bear.

-hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 16 Aug 2013 01:09:20 -0400

The problem is the CNAM lookup isn't trustworthy.  "dodgy" carriers can and do run their own LIDBs.  As do all sorts of 3rd parties, who get information from God-only-knows where, about individuals with whom they have no business relationship (so, no incentive to "keep happy").

Providing a validated calling number would not protect my mom from a scammer who's got a number from such a "dodgy" carrier, and has been allowed by that carrier to associate with it the name of her bank.  AFAICT it only helps entities that operate their own identity database, e.g., LEAs and PSAPs.

tim

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Thursday, August 15, 2013 9:16 PM
To: Dwight, Timothy M (Tim)
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

On Aug 15, 2013, at 3:39 PM, "Dwight, Timothy M (Tim)" <[email-masked]> wrote:

> * properties of the organization ("licensed plumber", "FDIC-insured
> bank", "located in Washington, DC", "registered charity")
>
>> not the caller, at least initially).  There is no equivalent
>> assurance for CNAM.
>>
>> the alternate, doesn't depend on the origination carrier mechansism
>> is statisically actually a better "validation" of the content than
>> what a traditional carrier gets in his service order (because they
>> usually don't actually validate the content), and is infiniately
>> better than the carriers that allow the consumer to put anything they
>> want in the database.  Without a reasonable way to assure that the
>> database is actually valid, what is the value of carrying an assertion?
>
> While I recognize that letting the customer put in whatever they want
> is problematic, I have no idea whether the alternative of letting the
> CNAM provider include whatever they want is "better". (How would we
> measure
> that?)
>
> (I've just been trying to deal with an "information aggregator" that
> is publishing wrong information about me and won't change it. So I'm
> not feeling good about that sort of thing.)
>
> systems, that once mostly "worked" based on the good will of the
> people involved, but that have now been automated into monstrosities
> that nobody understands. (Management of healthcare data is another
> example.)
>
>> out a way to do validation, then we can revisit the notion of
>> carrying evidence of validation in future work.
>>
>> Does argue for making sure that whatever mechanism we arrive at
>> should have some obvious extension mechanism, perhaps along the lines
>> of what Jon was suggesting for media properties.  If you recall, he
>> proposed to have a digest of SDP where the digest was protected by
>> the signature, but if the SDP received didn't match the SDP sent, the

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Aug 2013 07:28:43 -0400

So what that says to me is you can't trust a CA - or at least not all the "CAs".  I've been told that some CNAM DB providers don't just blindly believe LIDB entries, but actually perform cross-reference checking with other data. (if they even populated the data from LIDB to begin with)

But that's one of the reasons it feels logical to me to keep it in a separate 3rd-party database, because you can't just trust what comes in on SIP/SS7 - you need a third party to perform some verification/cross-checking of the data, and in-advance as opposed to just when the call comes in.

(BTW, this is not the case for direct VoIP interconnection of call originator and terminator - for that you don't need STIR nor 3rd party CNAM databases)

-hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 16 Aug 2013 09:30:13 -0400

The ability to "cross-check" or otherwise validate the contents of a database, is not unique to "3rd parties".  It baffles me why involving a 3rd party would be expected to make things better.  AFAICS the service provider and the 3rd party are equally capable of being vigilent with respect to the content of their database; but the service provider is uniquely positioned by virtue of his ongoing business relationship with the calling party.  That relationship gives him greater access to information about the customer's identity, and more incentive to manage it properly, than a 3rd party would have.

That doesn't eliminate the potential for "dodgy" service providers.  Obviously.  But 3rd party database providers have the same potential to be "dodgy", and less incentive not to be.

I wish that last comment were true, but I don't think it is.  The problem is that "dodgy" entities typically interconnect to the PSTN via wholesale services provided by a "traditional" carrier.  To exchange traffic with them you go through their wholesale provider.  Even if A and B directly interconnect, and neither is the least bit "dodgy", there may be sitting behind one or both of them, carriers that are.  Even if A and B trust one another completely I think they would still want to be protected from one anothers' wholesale customers.  And besides, in business nobody ever trusts anybody completely :-).

tim

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, August 16, 2013 6:29 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)" <[email-masked]> wrote:

>>> is indeed entitled to claim control of that number (well, SPs
>>> mostly, not the caller, at least initially).  There is no equivalent
>>> assurance for CNAM.
>>>
>>> better than the carriers that allow the consumer to put anything
>>> they want in the database.  Without a reasonable way to assure that
>>> the database is actually valid, what is the value of carrying an assertion?
>>
>> Alternatively this could be left to the open market. (E.g., The
>> callee could just Google the calling number.)
>>
>>> Right now, I think we should leave it out of scope.  If we can
>>> figure out a way to do validation, then we can revisit the notion of
>>> should have some obvious extension mechanism, perhaps along the
>>> lines of what Jon was suggesting for media properties.  If you
>>> recall, he proposed to have a digest of SDP where the digest was
>>> protected by the signature, but if the SDP received didn't match the
>>> SDP sent, the termination side could know that, but the basic
>>> identity mechanism could succeed anyway (that is, you knew you had a valid identity and a modified SDP).
>>>
>>> Brian
>>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Aug 2013 09:41:06 -0400

> I wish that last comment were true, but I don't think it is.  The problem is that "dodgy" entities typically interconnect to the PSTN via wholesale services provided by a "traditional" carrier.  To…

Agreed, that last paragraph is basically the problem we have, even for telephone numbers let alone CNAM.  We've always known this would eventually happen, once the cost of making phone calls and connecting to the network-of-trust got cheap enough.  The reason a 3rd party helps is because there really is incentive for them to not lie: if they lie, the "good" carriers won't use them and they won't be as valuable.  Their whole business model depends on their data being accurate.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 16 Aug 2013 13:44:56 +0000

If that "3rd party" is really the 2nd party, i.e. the terminating phone,
then it might just be trustworthy.
The end user can learn what number to trust based on experience.

All this discussion is interesting, but it all depends on the input to the
CNAM lookup being accurate, no?
Ensuring that the number is valid is Step 1, what I thought the focus of
STIR is.  All the rest of this is derivative.

This sounds to me like a BOF discussion for a follow-on WG.
And one that we could send all those concerned with privacy to.  :)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dwight, Timothy M (Tim)
Sent: Friday, August 16, 2013 9:30 AM
To: Hadriel Kaplan
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

The ability to "cross-check" or otherwise validate the contents of a
database, is not unique to "3rd parties".  It baffles me why involving a 3rd
party would be expected to make things better.  AFAICS the service provider
and the 3rd party are equally capable of being vigilent with respect to the
content of their database; but the service provider is uniquely positioned
by virtue of his ongoing business relationship with the calling party.  That
relationship gives him greater access to information about the customer's
identity, and more incentive to manage it properly, than a 3rd party would
have.

That doesn't eliminate the potential for "dodgy" service providers.
Obviously.  But 3rd party database providers have the same potential to be
"dodgy", and less incentive not to be.

I wish that last comment were true, but I don't think it is.  The problem is
that "dodgy" entities typically interconnect to the PSTN via wholesale
services provided by a "traditional" carrier.  To exchange traffic with them
you go through their wholesale provider.  Even if A and B directly
interconnect, and neither is the least bit "dodgy", there may be sitting
behind one or both of them, carriers that are.  Even if A and B trust one
another completely I think they would still want to be protected from one
anothers' wholesale customers.  And besides, in business nobody ever trusts
anybody completely :-).

tim

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, August 16, 2013 6:29 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

So what that says to me is you can't trust a CA - or at least not all the
"CAs".  I've been told that some CNAM DB providers don't just blindly
believe LIDB entries, but actually perform cross-reference checking with
other data. (if they even populated the data from LIDB to begin with)

But that's one of the reasons it feels logical to me to keep it in a
separate 3rd-party database, because you can't just trust what comes in on
SIP/SS7 - you need a third party to perform some verification/cross-checking
of the data, and in-advance as opposed to just when the call comes in.

(BTW, this is not the case for direct VoIP interconnection of call
originator and terminator - for that you don't need STIR nor 3rd party CNAM
databases)

-hadriel

On Aug 16, 2013, at 1:09 AM, "Dwight, Timothy M (Tim)"
<[email-masked]> wrote:

> The problem is the CNAM lookup isn't trustworthy.  "dodgy" carriers can
and do run their own LIDBs.  As do all sorts of 3rd parties, who get
information from God-only-knows where, about individuals with whom they have
no business relationship (so, no incentive to "keep happy").
>
> Providing a validated calling number would not protect my mom from a
scammer who's got a number from such a "dodgy" carrier, and has been allowed
by that carrier to associate with it the name of her bank.  AFAICT it only
helps entities that operate their own identity database, e.g., LEAs and
PSAPs.
> I may be misunderstanding you, but I think we're kind of getting a
solution to that... though maybe not in a way that people want.
>
> For sake of argument, let's ignore the technology or any proposed solution
for STIR, or even STIR in general.  Also ignore the existing CNAM business
model and pretend we wanted to provide CNAM for the first time, from
scratch.
>
> We know we can't just trust callerid4u to claim any CNAM it wanted to.  So
let's say instead of trusting callerid4u, we designated some common CA to
verify and sign CNAM information for everyone, and everyone has to trust
them.  This CA used various sources of information and verification to
create a "certificate" that said "for this phone number X, the user's name
is Jane Doe", or maybe "for the holder of the private key for this public
key, the user's name is Jane Doe" (which is basically what web certificates
say).
>
> So then we look at how to put this into SIP, and instead of putting the
whole certificate in the INVITE, we use an external database lookup
mechanism.  That's basically STIR, for the phone number part.  And the
existing CNAM databases are basically the "CA", where they provide a trusted
lookup database of phone-number -> CNAM.  Since STIR validates the phone
number, the CNAM database lookup should be valid... assuming you trust the
CNAM database to be valid to begin with.  But if you *don't* trust it, it's
not clear why you'd trust any other CA either.
>
> So we already have (or will once we have STIR) a way to get a fairly valid
CNAM, if you believe in a CA model for that.  What we don't have is a
different pricing/business model for how the "CA" charges for retrieving the
"certificate" data.  But I don't think it's the technology that causes this
really, so it's not something we can fix here.  I mean even web CAs charge
an impressive amount of money for web certificates, and the technology part
of the job is trivial for them, afaik.  They charge what they believe the
market will bear.
>>
>> I recognize that names are not delegated in the same way that numbers
are, and that there are all sorts of semantic nuances that make their
validation difficult.  Still, CA's do it.  And it's been proposed on this
list that a smartphone app could do it.  So I don't see why we're so quick
to agree we can't do it.  Or at least, do something.
>> p.s. I tend to agree with Rich, that we can't forever duck the issue of
what gets presented to the called party.  Whether it's addressed directly or
not, we're already making assumptions about what is and isn't reasonable.
making it difficult to do that within the signaling framework:
>> This is more whois-like information than just the SIP display name. In
the certificate space, we have two levels: (1) assertion of domain name
control; (2) EV (extended validation) certs. It would be interesting to see
how well the EV concept has worked out in practice.

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 16 Aug 2013 10:13:09 -0400

Mike,

Please see comments inline, preceded by [tmd].

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 8:45 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

If that "3rd party" is really the 2nd party, i.e. the terminating phone, then it might just be trustworthy.
[tmd] I guess what you mean is that if the calling number is in your contact list you can trust the calling name displayed, because you probably created the contact list entry yourself.  Fair enough.  But I doubt that's a significant use case.  Attackers usually claim to be someone like your bank, whose number is probably *not* in your contact list.  And of course this whole scenario assumes your phone *has* a contact list, which it may but won't always.

The end user can learn what number to trust based on experience.
[tmd] Yes, that occurred to me too.  My idea was that even if we can't validate the calling name, in the same sense that we validate the calling number, we could at least inform the called party of who asserted it.  Assuming we had some secure way to do that, the called party could then decide whether he trusts assertions made by that entity.  It's far from perfect, but might be an improvement (if the called party's equipment can make that information make sense to the human holding the phone).

All this discussion is interesting, but it all depends on the input to the CNAM lookup being accurate, no?
[tmd] Not necessarily.  If the terminating carrier uses CNAM, then he benefits from the input being valid.  But CNAM isn't the only way to obtain calling party name.  Regardless, I'm not arguing that validating calling party number is useless.  It's IMHO necessary but not sufficient.  It protects law enforcement agencies and PSAPs (who have their own identity databases) but it doesn't adequately protect consumers (who don't, except for the contact list in their phone).

Ensuring that the number is valid is Step 1, what I thought the focus of STIR is.  All the rest of this is derivative.
[tmd] I guess that's what we're discussing.  My worry is that if we stop there, we'll be perceived as the latest failure to address the problems experienced by consumers.  We may put dent in SWATting but identity theft and bank scams won't be deterred.

This sounds to me like a BOF discussion for a follow-on WG.  And one that we could send all those concerned with privacy to.  :)

Mike

-----Original Message-----

tim

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, August 16, 2013 6:29 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 16 Aug 2013 14:37:42 +0000

I don't disagree with anything that has been said.
I just don't want to get the cart before the horse.

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Friday, August 16, 2013 10:13 AM
To: Michael Hammer; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike,

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 8:45 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

If that "3rd party" is really the 2nd party, i.e. the terminating phone,
then it might just be trustworthy.
[tmd] I guess what you mean is that if the calling number is in your contact
list you can trust the calling name displayed, because you probably created
the contact list entry yourself.  Fair enough.  But I doubt that's a
significant use case.  Attackers usually claim to be someone like your bank,
whose number is probably *not* in your contact list.  And of course this
whole scenario assumes your phone *has* a contact list, which it may but
won't always.

The end user can learn what number to trust based on experience.
[tmd] Yes, that occurred to me too.  My idea was that even if we can't
validate the calling name, in the same sense that we validate the calling
number, we could at least inform the called party of who asserted it.
Assuming we had some secure way to do that, the called party could then
decide whether he trusts assertions made by that entity.  It's far from
perfect, but might be an improvement (if the called party's equipment can
make that information make sense to the human holding the phone).

All this discussion is interesting, but it all depends on the input to the
CNAM lookup being accurate, no?
[tmd] Not necessarily.  If the terminating carrier uses CNAM, then he
benefits from the input being valid.  But CNAM isn't the only way to obtain
calling party name.  Regardless, I'm not arguing that validating calling
party number is useless.  It's IMHO necessary but not sufficient.  It
protects law enforcement agencies and PSAPs (who have their own identity
databases) but it doesn't adequately protect consumers (who don't, except
for the contact list in their phone).

Ensuring that the number is valid is Step 1, what I thought the focus of
STIR is.  All the rest of this is derivative.
[tmd] I guess that's what we're discussing.  My worry is that if we stop
there, we'll be perceived as the latest failure to address the problems
experienced by consumers.  We may put dent in SWATting but identity theft
and bank scams won't be deterred.

This sounds to me like a BOF discussion for a follow-on WG.  And one that we
could send all those concerned with privacy to.  :)

Mike

-----Original Message-----

tim

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, August 16, 2013 6:29 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 16 Aug 2013 11:00:05 -0400

Hadriel,

You said in part "The reason a 3rd party helps is because there really is incentive for them to not lie: if they lie, the "good" carriers won't use them and they won't be as valuable.  Their whole business model depends on their data being accurate."

I guess this illustrates why it's dangerous to generalize.  In my experience anyway, this is sometimes but not always true.  In any mature market there are going to be bottom feeders that compete solely on price.  In this particular market there also seem to be entities who "try to be bad", i.e., openly advertise the fact that they don't validate the information you provide.  Just as you should not generalize that all 3rd party database providers are saints, I should not generalize that they're all sinners.  No doubt the same applies to service providers.

I guess all businesses have an incentive to "keep their customer happy", but if you're a bottom feeder that normally just means keeping the price low and if your business model is to be the fraudster's friend it means enabling / facilitating his mischief.  Bottom line, that incentive doesn't necessarily lead to the dissemination of accurate information.  By either the service provider or a 3rd party.

tim 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, August 16, 2013 8:41 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 16 Aug 2013 11:00:54 -0400

Sure.  But equally, we should not omit the cart.  Unless we believe that (a) the horse by itself is sufficiently valuable, or (b) someone else will provide the cart.

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 9:38 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Friday, August 16, 2013 10:13 AM
To: Michael Hammer; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike,

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 8:45 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike

-----Original Message-----

tim

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, August 16, 2013 6:29 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 16 Aug 2013 15:14:34 +0000

We know there will be carts.
There can be many types of carts.
Many carts means many  bunny-trails and rat-holes to go down.

Just don't want to get caught up with the design of chrome bumpers and be
stuck with a badly designed engine.
I think it is valuable to get the horse (team) right first.

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Friday, August 16, 2013 11:01 AM
To: Michael Hammer; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Sure.  But equally, we should not omit the cart.  Unless we believe that (a)
the horse by itself is sufficiently valuable, or (b) someone else will
provide the cart.

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 9:38 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Friday, August 16, 2013 10:13 AM
To: Michael Hammer; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike,

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 8:45 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike

-----Original Message-----

tim

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, August 16, 2013 6:29 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 16 Aug 2013 11:44:34 -0400

Mike,

I understand.  It's a good discussion and in the end will be a judgment call.  On the one extreme we could attempt to boil the ocean and get nowhere.  On the other extreme we could solve too small a part of the problem to be relevant, and/or create a partial solution that isn't consistent with the requirements of a complete solution (or worse, by its existence, constrains the set of solutions we will consider for the complete solution).  By analogy we could design a horse incapable of pulling the cart we later realize needs to be pulled.  Maybe the cart turns out to be big and we designed a Shetland pony :-).  Given that we've spent all that effort designing our pony, the natural temptation will be to design a cart that such a pony can pull.

To me this is similar to the in-band vs. out-of-band debate.  In that case we decided (I think) that we would focus on the former (to avoid ocean-boiling) while "keeping the latter in mind" (to avoid the horse-that-can't-pull-the-cart scenario).  Which seems like a reasonable compromise.

Maybe that's what we'll decide to do with calling-name validation too.  Frankly I started this discussion thinking that that's as much as I'd get... I just asked for some "hooks" in the initial solution that would allow us (or someone) to extend it.  But I know that the difference between agreeing to such incorporate such extensibility hooks and boiling the ocean, is a slippery slope.  How do you know your extensibility hook will actually be useful?  By analogy, how do you know your yoke will be sufficient to pull the cart without designing the cart?

If this resolves to a similar "keep it in mind but don't explicitly work on it" compromise, and we are willing to be explicit with our "user community" (suppliers who have to build this stuff and carriers who have to deploy it) about what portion of the problem we've addressed, I think I can live with that.

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 10:15 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Friday, August 16, 2013 11:01 AM
To: Michael Hammer; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 9:38 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Friday, August 16, 2013 10:13 AM
To: Michael Hammer; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike,

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 8:45 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike

-----Original Message-----

tim

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, August 16, 2013 6:29 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 16 Aug 2013 15:58:47 +0000

Understand.  

I would like to request that we don't end up designing it so that the horse
can only be used with one cart type.
i.e. keep it loosely coupled.

I am not so worried that if we get this one basic function right, it won't
get incorporated in many higher-level features.

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Friday, August 16, 2013 11:45 AM
To: Michael Hammer; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike,

I understand.  It's a good discussion and in the end will be a judgment
call.  On the one extreme we could attempt to boil the ocean and get
nowhere.  On the other extreme we could solve too small a part of the
problem to be relevant, and/or create a partial solution that isn't
consistent with the requirements of a complete solution (or worse, by its
existence, constrains the set of solutions we will consider for the complete
solution).  By analogy we could design a horse incapable of pulling the cart
we later realize needs to be pulled.  Maybe the cart turns out to be big and
we designed a Shetland pony :-).  Given that we've spent all that effort
designing our pony, the natural temptation will be to design a cart that
such a pony can pull.

To me this is similar to the in-band vs. out-of-band debate.  In that case
we decided (I think) that we would focus on the former (to avoid
ocean-boiling) while "keeping the latter in mind" (to avoid the
horse-that-can't-pull-the-cart scenario).  Which seems like a reasonable
compromise.

Maybe that's what we'll decide to do with calling-name validation too.
Frankly I started this discussion thinking that that's as much as I'd get...
I just asked for some "hooks" in the initial solution that would allow us
(or someone) to extend it.  But I know that the difference between agreeing
to such incorporate such extensibility hooks and boiling the ocean, is a
slippery slope.  How do you know your extensibility hook will actually be
useful?  By analogy, how do you know your yoke will be sufficient to pull
the cart without designing the cart?

If this resolves to a similar "keep it in mind but don't explicitly work on
it" compromise, and we are willing to be explicit with our "user community"
(suppliers who have to build this stuff and carriers who have to deploy it)
about what portion of the problem we've addressed, I think I can live with
that.

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 10:15 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Friday, August 16, 2013 11:01 AM
To: Michael Hammer; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 9:38 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Friday, August 16, 2013 10:13 AM
To: Michael Hammer; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike,

tim

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 16, 2013 8:45 AM
To: Dwight, Timothy M (Tim); [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Early Homework (was Re: Moving from BOF to Charter)

Mike

-----Original Message-----

tim

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, August 16, 2013 6:29 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Aug 2013 11:27:56 -0400

Hadriel,

> We know we can't just trust callerid4u to claim any CNAM it wanted to.  So let's say instead of trusting callerid4u, we designated some common CA to verify and sign CNAM information for everyone, a…
This aspect of your proposal already raises several concerns in my mind:

- Jane Doe is not a globally unique name, so a called party can't assume 
that
the caller is the Jane Doe that comes to mind

- I strongly doubt that there is a single CA that could (should) be 
trusted to
the identity of every caller in every country. if we have per-country
CAs we start getting close to the problems we have in the browser 
environment.

- As a rule, the best CAs are ones that are authoritative for the 
attributes for
which they vouch. For phone numbers a lot of folks seem confident that we
have the right players to perform this function. For common names, we do
not (until you add a lot of context, which is often not universally
meaningful), and if one tries to tie both attributes into one cert ...

My bottom line is that I don't believe in the web CA model; it has 
failed. DANE is
a much better approach, becuase it aligns name space management and 
public key binding.

Steve

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Aug 2013 12:02:18 -0400

Of course, but that's why I later said "if you believe in a CA model for that".  If you don't believe in a CA model for such data, there's nothing we can do to improve upon it, since there is no authority model we could really create for human names.

-hadriel

On Aug 19, 2013, at 11:27 AM, Stephen Kent <[email-masked]> wrote:

> - Jane Doe is not a globally unique name, so a called party can't assume that
> - I strongly doubt that there is a single CA that could (should) be trusted to
> CAs we start getting close to the problems we have in the browser environment.
> 
> - As a rule, the best CAs are ones that are authoritative for the attributes for
> My bottom line is that I don't believe in the web CA model; it has failed. DANE is
> a much better approach, becuase it aligns name space management and public key binding.
> 
> 
> Steve

---

From: Brian Rosen <[email-masked]>
Date: Mon, 19 Aug 2013 12:11:42 -0400

I'd like to examine your assertion "I don't believe in the web CA model; it
has failed. DANE is
a much better approach, becuase it aligns name space management and public
key binding." with respect to stir.

It seems inevitable that within a country, one entity will have the data.
 If that isn't the case, then we're going to have long chains of
delegations that each would need to be validated.  If there is one per
country, then there is only one signature per number.  That is independent
of how credentials are stored.

Even if there were a small number of entities per country, that wouldn't
change much.

The point is that mistakes will be made and the DANE model, applied here,
when most records are under control of one or  a small number of entities,
will be subject to the same issues that allowed the web CA model to fail.
 What is attractive in DANE is that the DNS delegation is diffuse, so
compromise of one entity limits problems.  We won't have that situation.

I do think that the consequences of a mistake will be much more modest.

Brian

On Mon, Aug 19, 2013 at 11:27 AM, Stephen Kent <[email-masked]> wrote:

> Hadriel,
>
>
>  ...
>>
>>
>> We know we can't just trust callerid4u to claim any CNAM it wanted to.
>>  So let's say instead of trusting callerid4u, we designated some common CA
>> to verify and sign CNAM information for everyone, and everyone has to trust

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Aug 2013 16:17:36 +0000

Human names are hard (and often misleading anyway - even with no ill intent, "Jim Smith" is likely to be inaccurate for many calls placed from the Smith household). Names of incorporated entities are much easier - they are registered in almost all cases, even if not trade-marked, and there are clear rules for dealing with collisions and right-to-use. As long as non-business entities are prevented from using a corporate name, the potential for misleading abuse is greatly reduced.

That way, a legitimate entity can register "Cardholder Services" and prevent its use by others. Rachel is unlikely to file a suit to complain.

The idea would be to create a database of names that are "protected", i.e., cannot be used without signature. (This would also help for numbers, by the way.)

Henning 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Monday, August 19, 2013 12:02 PM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Mon, 19 Aug 2013 16:21:43 +0000

Depends on which end of the telescope you are looking through.

I could argue that having the authority aspect diffused leads to the very
problem that we are trying to solve.

So, you end up with a system that very precisely asserts the wrong
information.

The longer the chain of delegation the higher probability of error.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Monday, August 19, 2013 12:12 PM
To: Stephen Kent
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

It seems inevitable that within a country, one entity will have the data.
If that isn't the case, then we're going to have long chains of delegations
that each would need to be validated.  If there is one per country, then
there is only one signature per number.  That is independent of how
credentials are stored.

Brian

Hadriel,

...

- I strongly doubt that there is a single CA that could (should) be trusted
to
the identity of every caller in every country. if we have per-country
CAs we start getting close to the problems we have in the browser
environment.

- As a rule, the best CAs are ones that are authoritative for the attributes
for

My bottom line is that I don't believe in the web CA model; it has failed.
DANE is
a much better approach, becuase it aligns name space management and public
key binding.

Steve

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Aug 2013 12:46:28 -0400

He was talking about with regards to calling name.  The web CA model has issues because fundamentally the "trusted" CAs are not authoritative for the names they assert - it's purely based on blind trust in the CA to be correct.  Worse even, there's no scope constraining what names they could assert.

With DANE, the "CA" is by definition authoritative for the name it asserts, because DNS is the singular authority for domain names.  And even if you're an evil DNS operator the scope of your authority is constrained to the domain names you're DNS-authoritative for, so you can't create false name entries of others.

For STIR calling numbers, we'll have the same constrained authority and scope - whether it be as certificates or CIDER or whatever.

For calling names, that's a much harder problem.  The only true authority for human names is national governments, and the authority for business names is also national governments. (or state governments, as is the case in the US)  But no one's truly authoritative for a phone-number-to-name mapping.  The closest thing to such an authority is the carriers themselves, but we've already conceded that some carriers are either sloppy or complicit for source identity.  For phone numbers we can prevent such sloppiness/malevolence because we can know whether the sender is actually authoritative for the phone number.  But for the calling name of the phone number...?

-hadriel

On Aug 19, 2013, at 12:11 PM, Brian Rosen <[email-masked]> wrote:

> I'd like to examine your assertion "I don't believe in the web CA model; it has failed. DANE is
> a much better approach, becuase it aligns name space management and public key binding." with respect to stir.
> 
> It seems inevitable that within a country, one entity will have the data.  If that isn't the case, then we're going to have long chains of delegations that each would need to be validated.  If there is one per country, then there is only one signature per number.  That is independent of how credentials are stored.
> 
> Even if there were a small number of entities per country, that wouldn't change much.
> 
> The point is that mistakes will be made and the DANE model, applied here, when most records are under control of one or  a small number of entities, will be subject to the same issues that allowed the web CA model to fail.  What is attractive in DANE is that the DNS delegation is diffuse, so compromise of one entity limits problems.  We won't have that situation.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Aug 2013 17:12:47 +0000

As you note, there are third parties with accurate databases for incorporated businesses, both government and private. If the corporate entity wants to, they can use the same public-private key pair to sign that information and tie it to that phone number, assuming that the trusted third party generally won't let just anyone do this. There is some impersonation risk while most such records aren't connected to the STIR record, but I suspect the high-profile targets would most likely get their records signed and thus prevent shopping for the CA with the weakest security. The incentive to impersonate the local barber shop is probably low.

An entity could simply list the outbound numbers in the third-party record and provide a low level of assurance much better than today, as long as the third party checks for duplicates.

Henning

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Monday, August 19, 2013 12:46 PM
To: Brian Rosen
Cc: [email-masked]; Stephen Kent
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Aug 2013 17:25:08 +0000

I see no reason not to have either the service provider or a third party provide this information. In some cases, important information (e.g., the holding of licenses or business permits) is only readily available via third parties. I don't think the local phone company wants to validate whether the lawyer is admitted to the bar, the doctor, charity or driveway sealer are state-licensed and the bank is FDIC-insured, but all of these are at least as important as the plain name to reduce fraud. Such additional indications make look-alike impersonation much less likely, i.e., where the perp uses "Bank for America" or typos to fool the quick glance.

However, generally, trusted entities tend to be somewhat larger and few. It is unlikely that a diligent rural ILEC or CLEC will ever accrue enough recognition to be on the "known diligent" list. You then either end up with a browser-like mechanism of endowing certain gatekeepers with a seal of approval, or you can at least separate the two functions, where needed. The small rural ILEC may decide that it's better to let the Chamber of Commerce or the state corporation board do this. Verizon and kin, on the other hand, may well want to acquire a reputation of validating their customer identities.

Thus, my suggestion to allow for both originating service provider and third-party models.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dwight, Timothy M (Tim)
Sent: Friday, August 16, 2013 9:30 AM
To: Hadriel Kaplan
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

tim

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, August 16, 2013 6:29 AM
To: Dwight, Timothy M (Tim)
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

-hadriel

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Aug 2013 13:52:23 -0400

Brian,

> public key binding." with respect to stir.
sure.
> It seems inevitable that within a country, one entity will have the 
> data.  If that isn't the case, then we're going to have long chains of 
> country, then there is only one signature per number.  That is 
> independent of how credentials are stored.
If we're talking about phone numbers, I agree and don't see a problem. 
if we're talking
about names, I do. Also, I didn't discuss multiple signatures for any 
credential.
> Even if there were a small number of entities per country, that 
again, for phone numbers I don't see a problem.
> The point is that mistakes will be made and the DANE model, applied 
> here, when most records are under control of one or  a small number of 
> entities, will be subject to the same issues that allowed the web CA 
> model to fail.  What is attractive in DANE is that the DNS delegation 
> is diffuse, so compromise of one entity limits problems.  We won't 
> have that situation.
I would phrase your last comment very differently. The DANE model is 
attractive because it limits what any
entity can assert (and have recognized as legitimate) based on that 
entity's location in the DNS hierarchy. It also
has the property I mentioned, i.e., the relationship between the vouched 
for data and the management entity
is the obvious one. Also, I am not suggesting use of DANE here, per se; 
I am using it as an example.

There are a few  examples I employ when discussing this sort of issue. 
For example, passports and employee ID cards.
Most folks agree that each country is authoritative as the issuer of 
passports for its citizens, identifying individuals based
on a name, passport #, and nationality. (There are a very few 
exceptions, but not enough to merit further discussion.)
Similarly, most folks seem to agree that a company is authoritative as 
the issuer of ID cards for employees, identifying
them by name and employee ID number. Whenever we stray from simple 
models of issuing credentials based on authoritative
databases, bad things happen.

Steve

---

From: Brian Rosen <[email-masked]>
Date: Mon, 19 Aug 2013 13:55:44 -0400

There are accurate databases for human names in most developed countries.
 Further, the databases you refer to would not have the information needed
to associate a business name with all of the numbers that the business
might use.  There are databases that have much of the information, but
would likely need some enhancement to have ALL of the possible numbers.

The issue I think we need to deal with has two aspects:
1. The entity asserting the name can't really claim authority because there
is no delegation chain for "John Smith"  or "World Wide Widgets".  There
are third parties that can assert some level of assurance that the name
goes with the number.

2. The assurance you get is not binary.  There is a score.

So, I think the way this would work is that a third party asserts a
likelihood score that the name asserted in the signaling is valid.  This
would work the best if the originating service provider asserted the score.
 The reason why is that the score is better the more information is known.
 If the originating SP provides the assurance service information like
service address, or other identifying information, the confidence is
better, and the score can be higher.  If there are only a few assurance
services, their credentials could be known by the terminating end, and some
form of the score signed by the service could be attached to the call and
verified at the termination.  The terminating end could use an assurance
service of its own choosing, but it would likely have only the name and
number as input, and thus have a limited score range to work with.

I do think that if there was a notion of a category (bank, insurance
company, doctor) included in the data, possibly with its own score, that
would help.

I think this is outside the charter.  We can either decide to work on this
later here in stir, or start a parallel effort.

Brian

On Mon, Aug 19, 2013 at 1:25 PM, Henning Schulzrinne <
[email-masked]> wrote:

> I see no reason not to have either the service provider or a third party
> provide this information. In some cases, important information (e.g., the
> holding of licenses or business permits) is only readily available via
> third parties. I don't think the local phone company wants to validate
> whether the lawyer is admitted to the bar, the doctor, charity or driveway
> sealer are state-licensed and the bank is FDIC-insured, but all of these
> are at least as important as the plain name to reduce fraud. Such
> additional indications make look-alike impersonation much less likely,
> i.e., where the perp uses "Bank for America" or typos to fool the quick
> glance.
>
> However, generally, trusted entities tend to be somewhat larger and few.
> It is unlikely that a diligent rural ILEC or CLEC will ever accrue enough
> recognition to be on the "known diligent" list. You then either end up with
> a browser-like mechanism of endowing certain gatekeepers with a seal of
> approval, or you can at least separate the two functions, where needed. The
> small rural ILEC may decide that it's better to let the Chamber of Commerce
> or the state corporation board do this. Verizon and kin, on the other hand,
> may well want to acquire a reputation of validating their customer
> identities.
>
> database, is not unique to "3rd parties".  It baffles me why involving a
> 3rd party would be expected to make things better.  AFAICS the service
> provider and the 3rd party are equally capable of being vigilent with
> respect to the content of their database; but the service provider is
> uniquely positioned by virtue of his ongoing business relationship with the
> calling party.  That relationship gives him greater access to information
> about the customer's identity, and more incentive to manage it properly,
> than a 3rd party would have.
>
> I wish that last comment were true, but I don't think it is.  The problem
> is that "dodgy" entities typically interconnect to the PSTN via wholesale
> services provided by a "traditional" carrier.  To exchange traffic with
> them you go through their wholesale provider.  Even if A and B directly
> SIP/SS7 - you need a third party to perform some
> verification/cross-checking of the data, and in-advance as opposed to just
> when the call comes in.
>
> information from God-only-knows where, about individuals with whom they
> have no business relationship (so, no incentive to "keep happy").
> >
> scammer who's got a number from such a "dodgy" carrier, and has been
> allowed by that carrier to associate with it the name of her bank.  AFAICT
> it only helps entities that operate their own identity database, e.g., LEAs
> and PSAPs.
> >
> > tim
> >
> >
> > For sake of argument, let's ignore the technology or any proposed
> solution for STIR, or even STIR in general.  Also ignore the existing CNAM
> business model and pretend we wanted to provide CNAM for the first time,
> from scratch.
> >
> existing CNAM databases are basically the "CA", where they provide a
> trusted lookup database of phone-number -> CNAM.  Since STIR validates the
> phone number, the CNAM database lookup should be valid... assuming you
> trust the CNAM database to be valid to begin with.  But if you *don't*
> trust it, it's not clear why you'd trust any other CA either.
> >
> > So we already have (or will once we have STIR) a way to get a fairly
> valid CNAM, if you believe in a CA model for that.  What we don't have is a
> different pricing/business model for how the "CA" charges for retrieving
> the "certificate" data.  But I don't think it's the technology that causes
> this really, so it's not something we can fix here.  I mean even web CAs
> charge an impressive amount of money for web certificates, and the
> technology part of the job is trivial for them, afaik.  They charge what
> they believe the market will bear.
> >
> > -hadriel
> >
> >
> >> I'm a pragmatist.  Maybe we can't do as good a job validating names as
> we can numbers.  I still think it's better to make things better than to do

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Aug 2013 18:05:39 +0000

As you say, there are currently no databases that associate numbers with corporate records, but such association doesn't seem all that hard, assuming that the owners of those databases see a business opportunity. They are, like Steve says, authoritative for the business name. They also have known contact points at those corporations, so impersonation is a lot harder.

The model would be that the existing business record (e.g., credit reporting or state agencies) allow their registered entities to add numbers to the record. They wouldn't need to add all their numbers - the numbers used for outbound calls to customers would be sufficient, not every desk phone of backoffice staff with no customer contact. For large entities such as most banks, they could also simply provide a public key in the record, indicating that every number signed with the corresponding private key is theirs.

The receiving entity queries the database with the name, number or public key.

Yes, it's largely a separate effort, but we do want to most likely tie the crypto credentials, so discussing how they might work together seems helpful.

From: Brian Rosen [mailto:[email-masked]]
Sent: Monday, August 19, 2013 1:56 PM
To: Henning Schulzrinne
Cc: Dwight, Timothy M (Tim); Hadriel Kaplan; [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

There are accurate databases for human names in most developed countries.  Further, the databases you refer to would not have the information needed to associate a business name with all of the numbers that the business might use.  There are databases that have much of the information, but would likely need some enhancement to have ALL of the possible numbers.

The issue I think we need to deal with has two aspects:
1. The entity asserting the name can't really claim authority because there is no delegation chain for "John Smith"  or "World Wide Widgets".  There are third parties that can assert some level of assurance that the name goes with the number.

So, I think the way this would work is that a third party asserts a likelihood score that the name asserted in the signaling is valid.  This would work the best if the originating service provider asserted the score.  The reason why is that the score is better the more information is known.  If the originating SP provides the assurance service information like service address, or other identifying information, the confidence is better, and the score can be higher.  If there are only a few assurance services, their credentials could be known by the terminating end, and some form of the score signed by the service could be attached to the call and verified at the termination.  The terminating end could use an assurance service of its own choosing, but it would likely have only the name and number as input, and thus have a limited score range to work with.

I do think that if there was a notion of a category (bank, insurance company, doctor) included in the data, possibly with its own score, that would help.

I think this is outside the charter.  We can either decide to work on this later here in stir, or start a parallel effort.

Brian

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Aug 2013 14:24:36 -0400

Brian,
> There are accurate databases for human names in most developed countries.
If you Google my name you will find (at least this used to be the case) 
that the better known "Stephen Kent" is a professional didgeridoo 
player. So, knowing that a caller is "Stephen Kent" (or "Brian Rosen") 
is not sufficient in many contexts.

My perspective is that there are no identifiers for individuals that are 
both globally unique and meaningful for all communication contexts. Even 
for organizations this
is an issue, e.g., a business name or trademark is NOT protected as 
unique, even in a country. It is context specific, and arguing about the 
context makes attorneys wealthy!

We do agree on one point: this topic ought to be out of scope for now.

Steve

---

From: Brian Rosen <[email-masked]>
Date: Mon, 19 Aug 2013 14:53:29 -0400

There isn't a database that will supply a unique identifier for all
contexts.  OTOH, if you are a US resident, we could get a pretty good score
comparing your name to your phone number, and if we had an address, we
probably can get a pretty high score.  That would provide a pretty
meaningful assurance on the name attached to a phone call if we could
manage to get the mechanics worked out.  These databases exist in most
developed countries.

This is much better than we have today, because in most cases there is no
attempt to validate the name when a service provider gets a new customer.

If we could use these databases to score the name associated with the
number, especially if the originating service provider obtained and
supplied other information to the validation service (at the initiation of
service, and possibly periodically after), then the validation service
could provide a pretty decent score at the termination end.

On Mon, Aug 19, 2013 at 2:24 PM, Stephen Kent <[email-masked]> wrote:

> that the better known "Stephen Kent" is a professional didgeridoo player.
> So, knowing that a caller is "Stephen Kent" (or "Brian Rosen") is not
> sufficient in many contexts.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Aug 2013 18:57:11 +0000

I don't see uniqueness as being a major issue. The likelihood that the impostor will be able to register "Citibank" as a barber shop is rather low, and I'm not too worried about confusion between "Acme plumbing" and "Acme roofing", particular if the information provided contains the registered business location of the caller. Yes, I may get a call from Apple Records instead of the guy from the Genius Bar, but probably again not the most efficient way to swindle callees. In other words, fraud due to confusion between two legitimately registered names that have the same letters is possible, but has much lower probability and is likely to raise the bar significantly. Most swindlers aren't going to hire lawyers to have trademark scoping fights.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, August 19, 2013 2:25 PM
To: Brian Rosen
Cc: Henning Schulzrinne; [email-masked] List; Hadriel Kaplan; Dwight, Timothy M (Tim)
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Brian,
> There are accurate databases for human names in most developed countries.
If you Google my name you will find (at least this used to be the case) that the better known "Stephen Kent" is a professional didgeridoo player. So, knowing that a caller is "Stephen Kent" (or "Brian Rosen") is not sufficient in many contexts.

My perspective is that there are no identifiers for individuals that are both globally unique and meaningful for all communication contexts. Even for organizations this is an issue, e.g., a business name or trademark is NOT protected as unique, even in a country. It is context specific, and arguing about the context makes attorneys wealthy!

Steve

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 19 Aug 2013 14:59:53 -0400

> From: Stephen Kent <[email-masked]>

> is not sufficient in many contexts.

I have it worse.

If you google my name "Janet Gunn" you come up with a lot of semi-nude 
pictures of a grade B actress.

For some reason my employer does not like me to mention this fact. 

Janet

---

From: Brian Rosen <[email-masked]>
Date: Mon, 19 Aug 2013 15:00:49 -0400

Yeah, I think there is a lot of merit in your category idea.  It needs a
taxonomy, but we probably can choose some existing one.  For common use, we
want one with relatively fewer categories, not trying, for example to
differentiate between a life assurance agent and a property insurance agent.

Brian

On Mon, Aug 19, 2013 at 2:57 PM, Henning Schulzrinne <
[email-masked]> wrote:

> I don't see uniqueness as being a major issue. The likelihood that the
> impostor will be able to register "Citibank" as a barber shop is rather
> low, and I'm not too worried about confusion between "Acme plumbing" and
> "Acme roofing", particular if the information provided contains the
> registered business location of the caller. Yes, I may get a call from
> Apple Records instead of the guy from the Genius Bar, but probably again
> not the most efficient way to swindle callees. In other words, fraud due to
> confusion between two legitimately registered names that have the same
> letters is possible, but has much lower probability and is likely to raise
> the bar significantly. Most swindlers aren't going to hire lawyers to have
> trademark scoping fights.
>
> for organizations this is an issue, e.g., a business name or trademark is
> NOT protected as unique, even in a country. It is context specific, and
> arguing about the context makes attorneys wealthy!
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 20 Aug 2013 08:40:11 +0200

Excuse me, but I get a PKI and enum feeling when reading this. Trying to get the TRUE caller ID name from 3rd party sources will delay this process forever. There are tons of issues to handle here, not forgetting privacy.

Do we really need the honest-to-god true legal names or do we need to trace who assured the name? 

If someone fakes a name we need to be able to stop that from happening again, we need a non-repudiation scheme so we can find who did it. 

I see a lot of cases where a company wants to modify caller ID names for the same number and not use the legal name. "Edvina Support" calling, "Edvina Order dept, Elena" etc etc. I see very few cases where I need a full legal and digital identity in the caller ID name - and if that's needed, let's point to S/MIME (ducks).

In addition, we also have a system in Sweden where the same legal identity can have multiple company names registred... 

/O

19 aug 2013 kl. 20:05 skrev Henning Schulzrinne <[email-masked]>:

> As you say, there are currently no databases that associate numbers with corporate records, but such association doesn’t seem all that hard, assuming that the owners of those databases see a business opportunity. They are, like Steve says, authoritative for the business name. They also have known contact points at those corporations, so impersonation is a lot harder.
>  
> The model would be that the existing business record (e.g., credit reporting or state agencies) allow their registered entities to add numbers to the record. They wouldn’t need to add all their numbers – the numbers used for outbound calls to customers would be sufficient, not every desk phone of backoffice staff with no customer contact. For large entities such as most banks, they could also simply provide a public key in the record, indicating that every number signed with the corresponding private key is theirs.
>  
> Yes, it’s largely a separate effort, but we do want to most likely tie the crypto credentials, so discussing how they might work together seems helpful.
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 20 Aug 2013 08:42:24 +0200

> If you Google my name you will find (at least this used to be the case) that the better known "Stephen Kent" is a professional didgeridoo player. So, knowing that a caller is "Stephen Kent" (or "Br…
And since we have UTF-8 in the caller ID name we can propably have different names that looks the same on the display.
> 
> My perspective is that there are no identifiers for individuals that are both globally unique and meaningful for all communication contexts. Even for organizations this
> is an issue, e.g., a business name or trademark is NOT protected as unique, even in a country. It is context specific, and arguing about the context makes attorneys wealthy!
> 
+1

/O

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Aug 2013 11:23:51 -0400

I would expect swindlers to find providers in locales where checks are 
not so stringent,
to facilitate fraud, with some minimal level of plausible deniability. 
We have seen this
happen in the web site cert arena for some time.

Also, Acme Plumber in one city vs. Acme Plumbing in some other city is a 
legitimate
distinction, but one that probably would be irrelevant if a called party 
is led to believe that a textual caller ID is reliable, as some suggest.

Steve

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Aug 2013 11:47:16 -0400

I suspect that private providers of calling name might satisfy the need. 
E.g., something similar to Google lookup of the phone number. I can 
imagine some phone apps coming along for this. Exactly what information 
is provided, and where it comes from will vary. But then people will 
know what to expect, and not, based on reviews of the app.

This won't solve the problem for companies that want the name to say 
something special. But signing the From can serve that purpose. And an 
app can display the caller's assertion along with whatever else it can 
find that doesn't depend on trusting the caller.

Of course this won't work for legacy phones, but that is a problem that 
will go away with time. Maybe the existing CNAM DBs will continue to 
serve those in the meantime.

	Thanks,
	Paul

On 8/20/13 2:40 AM, Olle E. Johansson wrote:
> Excuse me, but I get a PKI and enum feeling when reading this. Trying to
> get the TRUE caller ID name from 3rd party sources will delay this
> process forever. There are tons of issues to handle here, not forgetting
> privacy.
>
> If someone fakes a name we need to be able to stop that from happening
> again, we need a non-repudiation scheme so we can find who did it.
>
> I see a lot of cases where a company wants to modify caller ID names for
> the same number and not use the legal name. "Edvina Support" calling,
> "Edvina Order dept, Elena" etc etc. I see very few cases where I need a
> full legal and digital identity in the caller ID name - and if that's
> needed, let's point to S/MIME (ducks).
>
> In addition, we also have a system in Sweden where the same legal
> identity can have multiple company names registred...
>
> /O
>
>
>
> 19 aug 2013 kl. 20:05 skrev Henning Schulzrinne
> <[email-masked] <mailto:[email-masked]>>:
>
>> As you say, there are currently no databases that associate numbers
>> with corporate records, but such association doesn’t seem all that
>> hard, assuming that the owners of those databases see a business
>> opportunity. They are, like Steve says, authoritative for the business
>> name. They also have known contact points at those corporations, so
>> impersonation is a lot harder.
>> The model would be that the existing business record (e.g., credit
>> reporting or state agencies) allow their registered entities to add
>> numbers to the record. They wouldn’t need to add all their numbers –
>> the numbers used for outbound calls to customers would be sufficient,
>> not every desk phone of backoffice staff with no customer contact. For
>> large entities such as most banks, they could also simply provide a
>> public key in the record, indicating that every number signed with the
>> corresponding private key is theirs.
>> Yes, it’s largely a separate effort, but we do want to most likely tie
>> the crypto credentials, so discussing how they might work together
>> seems helpful.
>> *From:*Brian Rosen [mailto:[email-masked] <http://brianrosen.net>]
>> *Sent:*Monday, August 19, 2013 1:56 PM
>> *To:*Henning Schulzrinne
>> *Cc:*Dwight, Timothy M (Tim); Hadriel Kaplan;[email-masked]
>> <mailto:[email-masked]>List
>> *Subject:*Re: [stir] Early Homework (was Re: Moving from BOF to Charter)
>> There are accurate databases for human names in most developed
>> countries.  Further, the databases you refer to would not have the
>> information needed to associate a business name with all of the
>> numbers that the business might use.  There are databases that have
>> much of the information, but would likely need some enhancement to
>> have ALL of the possible numbers.
>> 1. The entity asserting the name can't really claim authority because
>> there is no delegation chain for "John Smith"  or "World Wide
>> Widgets".  There are third parties that can assert some level of
>> assurance that the name goes with the number.
>> likelihood score that the name asserted in the signaling is valid.
>>  This would work the best if the originating service provider asserted
>> the score.  The reason why is that the score is better the more
>> information is known.  If the originating SP provides the assurance
>> service information like service address, or other identifying
>> information, the confidence is better, and the score can be higher.
>>  If there are only a few assurance services, their credentials could
>> be known by the terminating end, and some form of the score signed by
>> the service could be attached to the call and verified at the
>> termination.  The terminating end could use an assurance service of
>> its own choosing, but it would likely have only the name and number as
>> input, and thus have a limited score range to work with.
>> company, doctor) included in the data, possibly with its own score,
>> that would help.
>> I think this is outside the charter.  We can either decide to work on
>> this later here in stir, or start a parallel effort.
>> Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 20 Aug 2013 16:09:43 +0000

I just don't see name confusion among legitimate entities as a problem for consumers. This is only a problem if ACME Plumbing Chicago somehow pretends to be my local NJ ACME Plumbing (with a different owner). Not very likely. The problem we're trying to solve is that some random entity can pretend to be ACME Plumbing without a corresponding corporate registration.

To repeat myself: once you can provide additional information (location, line of business), the confusion problem drops significantly, as legitimate entities generally have incentives to differentiate themselves within their locality and line of business, even if trademark law doesn't force the issue.

Yes, there's a trust problem with the database, but we discussed that already - some recipients will decide not to trust the Nigerian Business Certification agency.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, August 20, 2013 11:24 AM
To: Henning Schulzrinne
Cc: Brian Rosen; [email-masked] List; Hadriel Kaplan; Dwight, Timothy M (Tim)
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

I would expect swindlers to find providers in locales where checks are not so stringent, to facilitate fraud, with some minimal level of plausible deniability. 
We have seen this
happen in the web site cert arena for some time.

Also, Acme Plumber in one city vs. Acme Plumbing in some other city is a legitimate distinction, but one that probably would be irrelevant if a called party is led to believe that a textual caller ID is reliable, as some suggest.

Steve

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Aug 2013 12:10:22 -0400

If you do all of the processing at the termination end, it's okay, but it
could be better.  This is how the Neustar CNAM service works.  We have a
database, the termination carrier can query it with the phone number and
get a name.  It's not dependent on the originating SP.

It would be better if this validation was done at the origination side,
because the originating carrier has more information about the customer
that can be used to improve the score.  It also would deal with the desire
to have some control on the actual presentation, and has a faster start up
(when you do it at the termination side, adding a new record takes more
time, because the sources for the data have significant lag).  The downside
is that the service the originating carrier uses to validate might not be
as stringent as the called party wishes to have.  It's always possible to
do both, or to decide to use a validation service on the terminating side
if the service used on the originating side isn't good enough for the
called party.

Doing validation on the originating side is a hybrid of the two schemes
used today.  You apply validation to the claimed name at the originating SP
and get a score.  You carry that through the network.  I think that would
work quite a bit better than an unvalidated name carried through the
network and all validation on the terminating side.

Brian

On Tue, Aug 20, 2013 at 11:47 AM, Paul Kyzivat <[email-masked]>wrote:

> E.g., something similar to Google lookup of the phone number. I can imagine
> some phone apps coming along for this. Exactly what information is
> provided, and where it comes from will vary. But then people will know what
> to expect, and not, based on reviews of the app.
>
> something special. But signing the From can serve that purpose. And an app
> can display the caller's assertion along with whatever else it can find
> that doesn't depend on trusting the caller.
>
> will go away with time. Maybe the existing CNAM DBs will continue to serve
> those in the meantime.
>
>         Thanks,
>         Paul
>
>
>> <[email-masked] <mailto:Henning.Schulzrinne@**fcc.gov<[email-masked]>
>> >>:
>>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Aug 2013 13:38:53 -0400

Henning,

I think the problem will be more subtle than just the Nigerian example, 
based on some experience in the PKI arena, but ...

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Aug 2013 13:44:42 -0400

Brian,

> contexts.  OTOH, if you are a US resident, we could get a pretty good 
> score comparing your name to your phone number, and if we had an 
> address, we probably can get a pretty high score.  That would provide 
> a pretty meaningful assurance on the name attached to a phone call if 
> we could manage to get the mechanics worked out.  These databases 
> exist in most developed countries.
Score? I hope we're not planning to send the score to the callee, as 
that will probably
confuse them. If the score is for internal use by a service provider, 
then there is the
risk that different providers will have different thresholds, which 
leads to a different sort of confusion.
> This is much better than we have today, because in most cases there is 
> no attempt to validate the name when a service provider gets a new 
> customer.
>
> supplied other information to the validation service (at the 
> initiation of service, and possibly periodically after), then the 
> validation service could provide a pretty decent score at the 
> termination end.
Are we talking about the VoIP version of "Name that Tune":
     "it's got great lyrics and a good beat, so I give it a 7"

Steve

---

From: Michael Hammer <[email-masked]>
Date: Tue, 20 Aug 2013 17:50:10 +0000

LOL, different type of score I think.

I think he is aiming for something that is 1-9's or less.
(And yes, I know this is a different sort of reliability to measure.)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Stephen Kent
Sent: Tuesday, August 20, 2013 1:45 PM
To: Brian Rosen
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Brian,

> exist in most developed countries.
Score? I hope we're not planning to send the score to the callee, as that will 
probably confuse them. If the score is for internal use by a service provider, 
then there is the risk that different providers will have different 
thresholds, which leads to a different sort of confusion.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Aug 2013 19:54:22 +0200

On 20 Aug 2013, at 19:38, Stephen Kent <[email-masked]> wrote:

> Henning,
> 
> I think the problem will be more subtle than just the Nigerian example, based on some experience in the PKI arena, but ...

Without having really caught up with thread, I'm pretty sure I agree with Steve - adding another dimension of naming to STIR seems like a bad plan fraught with complexity,

S

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Aug 2013 14:01:24 -0400

The score could be used by a smart device to display something appropriate.
 A service provider could establish thresholds for dumb devices.

Lots of existing systems use scores for similar problems.  The data is not
definitive, so instead of go/no go, you get a score.  There are lots of
fields in these databases.  The more input you provide, the more accurate
the result.

The mechanics of the databases and scoring, and even using scores, is well
established data science.  The only new stuff here is the mechanics of
carrying it.

Brian

On Tue, Aug 20, 2013 at 1:44 PM, Stephen Kent <[email-masked]> wrote:

> Score? I hope we're not planning to send the score to the callee, as that
> will probably
> confuse them. If the score is for internal use by a service provider, then
> there is the
> risk that different providers will have different thresholds, which leads
> to a different sort of confusion.
>

---

From: Michael Hammer <[email-masked]>
Date: Tue, 20 Aug 2013 18:20:50 +0000

Great for nerds.  

But, I think if you tell the average person, 

that the call is 60% assured of coming from First National Bank, 

what does that mean?

It means the telephone network is broken, 

since it doesn't know what it is doing.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Tuesday, August 20, 2013 2:01 PM
To: Stephen Kent
Cc: [email-masked] List
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

Brian

Brian,

There isn't a database that will supply a unique identifier for all
contexts.  OTOH, if you are a US resident, we could get a pretty good score
comparing your name to your phone number, and if we had an address, we
probably can get a pretty high score.  That would provide a pretty
meaningful assurance on the name attached to a phone call if we could manage
to get the mechanics worked out.  These databases exist in most developed
countries.

Score? I hope we're not planning to send the score to the callee, as that
will probably
confuse them. If the score is for internal use by a service provider, then
there is the
risk that different providers will have different thresholds, which leads to
a different sort of confusion.

If we could use these databases to score the name associated with the
number, especially if the originating service provider obtained and supplied
other information to the validation service (at the initiation of service,
and possibly periodically after), then the validation service could provide
a pretty decent score at the termination end.

Steve

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Aug 2013 14:36:17 -0400

I think that I could come up with a reasonable way to display "this
information is likely good, but could be inaccurate" in a way that most
people can deal with it.  It's always possible to threshold it at the
device.

We have scores on the existing service - it's just that the threshold is
determined before the data gets to the device.

Brian

On Tue, Aug 20, 2013 at 2:20 PM, Michael Hammer <
[email-masked]> wrote:

> Great for nerds.  ****
>
> ** **
>
> But, I think if you tell the average person, ****
>
> that the call is 60% assured of coming from First National Bank, ****
>
> what does that mean?****
>
> ** **
>
> It means the telephone network is broken, ****
>
> since it doesn’t know what it is doing.****
>
> ** **
>
> Mike****
>
> ** **
>
> ** **
>
> *Sent:* Tuesday, August 20, 2013 2:01 PM
> *To:* Stephen Kent
>
> *Cc:* [email-masked] List
> The score could be used by a smart device to display something
> appropriate.  A service provider could establish thresholds for dumb
> devices.****
>
> ** **
>
> the result.  ****
> carrying it.****
> Brian****
> On Tue, Aug 20, 2013 at 1:44 PM, Stephen Kent <[email-masked]> wrote:****
>
> Brian,****
>
> ** **
>
> developed countries.****
> to a different sort of confusion.****
>
> ** **
>
> could provide a pretty decent score at the termination end.****
>
> Steve****

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 20 Aug 2013 14:45:51 -0400

[RS> ]  We know .. Virtually all credit scoring systems and risk based
authentication models do this.  The financial services industry pioneered
the technique. 

[RS> ] but  the mechanics of carrying it are the "bridge too far" for STIR. 

Brian

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Aug 2013 15:16:19 -0400

Brian,

Research performed at CMU a few years ago found that the vast majority of
folks in their test cohort were unable to figure out what the lock icon 
in a browser
meant, or even to notice its presence/absence reliably.

So, tell me again how one displays a confidence rating for caller ID to 
this same
set of folks in a way that is useful.

The fact that the financial services industry uses scoring to deal with 
risks (internally)
is, IMHO, irrelevant to this discussion.

Steve

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 20 Aug 2013 21:31:04 +0200

Hi Steve,

I think that there are various aspects to this story.

First, there is a user interface aspect that is quite important. 
Clearly, we have noticed that already with various other security 
protocols (and privacy mechanisms as well). While the IETF does not 
standardize user interfaces it would obviously be great if we could work 
with those who do this type of work.

Second, there is the challenge that a lot of our technology is pretty 
complex and the chances that end users understand them is rather 
unlikely (since even we have problems understanding the bigger picture 
ourselves).

But what is the conclusion? Should we stop working on security 
mechanisms because others don't understand them? Should we turn of 
security (like TLS) because people get confused by different colours 
various vendors use (in their attempt to differentiate themselves from 
their competitors)?

I don't think that is the solution either.

Ideally, we would like to provide a secure version only and, in some 
groups these issues actually got raised (if you think about the HTTP 2.0 
discussions) and, as you are also aware, there are various companies who 
love insecure versions of protocols (so that they can build enterprise 
DPI boxes, aeh. content security devices). In this particular case it is 
even worse since we have to work around a broken legacy system and 
equally insecure VoIP deployments. There is the big transition problem.

Of course, all this does not sound like the ingredients for an easy 
protocol design.

So, what should we do?

Ciao
Hannes

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Aug 2013 16:23:52 -0400

I'm not sure how you mean your questions - what're you applying them to?  To calling name, or to calling number?

ISTM using a "score" based model to determine authenticity/validity is reasonable and useful in some specific applications when a machine can make a determination of good/bad based on score thresholds, and the input weights to the score and their thresholds can be tweaked by administrators or vendors based on experience and prior results.  But I don't know if such a thing would make any sense whatsoever for calling name, and regardless of it does or not: to expect end users to grok scores is a bad joke.

Fundamentally most average PSTN users expect the calling number, and the calling name, to be legitimate.  We know they're not.  STIR is chartered (or will be soon) to address the calling number.  We're pretty sure we know ways to fix that from a protocol and technology perspective, in practical ways (whether the market adopts is a different question).

I don't think anyone has any practical idea for how to truly "fix" calling name anytime soon.  The most reasonable thing to do, I think, is to do nothing substantively different for calling name right now.  There's a 3rd-party CNAM DB model, there's a LIDB model, and there's a PAI display-name model.  None of them are perfect, and they each have better/worse properties.

The good news is the STIR calling number validation should help the calling name issue, by at least helping the fraud investigators know which originating carrier the call came from.  It might also enable the blacklisting/whitelisting mechanisms to actually work, which itself might help weed out bad calling name generators.

-hadriel

On Aug 20, 2013, at 3:31 PM, Hannes Tschofenig <[email-masked]> wrote:

> First, there is a user interface aspect that is quite important. Clearly, we have noticed that already with various other security protocols (and privacy mechanisms as well). While the IETF does not standardize user interfaces it would obviously be great if we could work with those who do this type of work.
> 
> Second, there is the challenge that a lot of our technology is pretty complex and the chances that end users understand them is rather unlikely (since even we have problems understanding the bigger picture ourselves).
> 
> But what is the conclusion? Should we stop working on security mechanisms because others don't understand them? Should we turn of security (like TLS) because people get confused by different colours various vendors use (in their attempt to differentiate themselves from their competitors)?
> 
> Ideally, we would like to provide a secure version only and, in some groups these issues actually got raised (if you think about the HTTP 2.0 discussions) and, as you are also aware, there are various companies who love insecure versions of protocols (so that they can build enterprise DPI boxes, aeh. content security devices). In this particular case it is even worse since we have to work around a broken legacy system and equally insecure VoIP deployments. There is the big transition problem.
> 
> Of course, all this does not sound like the ingredients for an easy protocol design.
> 
> So, what should we do?
> 
> Ciao
> Hannes
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Aug 2013 16:23:58 -0400

Hannes,
> standardize user interfaces it would obviously be great if we could 
> work with those who do this type of work.
sounds like an IRTF task, for now.
> unlikely (since even we have problems understanding the bigger picture 
agreed!
> various vendors use (in their attempt to differentiate themselves from 
One conclusion is that this may not be ready for engineering.

It certainly seems to be out of scope for this WG at this time.
> groups these issues actually got raised (if you think about the HTTP 
> 2.0 discussions) and, as you are also aware, there are various 
> companies who love insecure versions of protocols (so that they can 
> build enterprise DPI boxes, aeh. content security devices). In this 
> particular case it is even worse since we have to work around a broken 
> legacy system and equally insecure VoIP deployments. There is the big 
> transition problem.
see comments above.
> Of course, all this does not sound like the ingredients for an easy 
1. agree that we're going to pursue only calling # security measures until
this WG re-charters.

2. consider an IAB workshop or an IRTF group to deal with the issue of how
to represent individual or org ID info to users (not just VoIP) users in 
a way
that does more god than harm.

Steve

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Aug 2013 16:45:09 -0400

I don't think the IETF has the expertise, even in IRTF, to do user
interface design.  We don't need to do any.  If we carry a score, the
device UI designers and the service providers can deal with it.  We are
simply acknowledging that there is no certainty, and we're offering to
provide the level of certainty we have.  Since there are plenty of examples
of devices and services that use these kinds of scores, we don't need to
know how they work, or what any UI will do with them.  We don't even need
to offer advise on what to do.

Brian

On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent <[email-masked]> wrote:

>> First, there is a user interface aspect that is quite important. Clearly,
>> we have noticed that already with various other security protocols (and
>> privacy mechanisms as well). While the IETF does not standardize user
>> interfaces it would obviously be great if we could work with those who do
>> this type of work.
>>
>> complex and the chances that end users understand them is rather unlikely
>> (since even we have problems understanding the bigger picture ourselves).
>>
> agreed!
>
>  But what is the conclusion? Should we stop working on security mechanisms
>> because others don't understand them? Should we turn of security (like TLS)
>> because people get confused by different colours various vendors use (in
>> their attempt to differentiate themselves from their competitors)?
>>
>> love insecure versions of protocols (so that they can build enterprise DPI
>> boxes, aeh. content security devices). In this particular case it is even
>> worse since we have to work around a broken legacy system and equally
>> insecure VoIP deployments. There is the big transition problem.
>>
> see comments above.
>
> to represent individual or org ID info to users (not just VoIP) users in a
> way

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Aug 2013 17:37:50 -0400

On 8/20/13 4:45 PM, Brian Rosen wrote:
> device UI designers and the service providers can deal with it.

IMO a "score" (in the sense of a single number) is probably also not the 
most appropriate input to presentation solutions. I expect that we will 
likely have an assortment of data that can be used to assess the 
validity of the name. Better to just provide all that to the UI and let 
it do its thing, rather than boiling it down into a number (and 
discarding useful information in the process.)

For instance, if the name in the request is signed, then the identity of 
the signer may be useful. And stuff that gets looked up at the receiving 
end can have arbitrary properties.

> We are
> provide the level of certainty we have.  Since there are plenty of
> examples of devices and services that use these kinds of scores, we
> don't need to know how they work, or what any UI will do with them.  We
> don't even need to offer advise on what to do.

For now I think less is more. In that respect I agree with you.

	Thanks,
	Paul

> Brian
>
>
> On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hannes,
>
>         Hi Steve,
>
>         Clearly, we have noticed that already with various other
>         security protocols (and privacy mechanisms as well). While the
>         IETF does not standardize user interfaces it would obviously be
>         great if we could work with those who do this type of work.
>
>         Second, there is the challenge that a lot of our technology is
>         pretty complex and the chances that end users understand them is
>         rather unlikely (since even we have problems understanding the
>         bigger picture ourselves).
>
>     agreed!
>
>         mechanisms because others don't understand them? Should we turn
>         of security (like TLS) because people get confused by different
>         colours various vendors use (in their attempt to differentiate
>         themselves from their competitors)?
>
>         Ideally, we would like to provide a secure version only and, in
>         some groups these issues actually got raised (if you think about
>         the HTTP 2.0 discussions) and, as you are also aware, there are
>         various companies who love insecure versions of protocols (so
>         that they can build enterprise DPI boxes, aeh. content security
>         devices). In this particular case it is even worse since we have
>         to work around a broken legacy system and equally insecure VoIP
>         deployments. There is the big transition problem.
>
>     see comments above.
>
>     to represent individual or org ID info to users (not just VoIP)
>     users in a way
>     _________________________________________________
>     stir mailing list
>     https://www.ietf.org/mailman/__listinfo/stir
>     <https://www.ietf.org/mailman/listinfo/stir>
>
>
>
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Aug 2013 17:42:47 -0400

No objection to carrying more, but probably we have to standardize what
more is, and that may blow up the problem.  I can look into that aspect as
it applies to other domains where the same database is used.

I do think we have to include the identity of the validation service, but I
think that would in inherent in the mechanism one way or another.  Can't
have the caller or the originating SP mucking with the score, can we?

Brian

On Tue, Aug 20, 2013 at 5:37 PM, Paul Kyzivat <[email-masked]> wrote:

> likely have an assortment of data that can be used to assess the validity
> of the name. Better to just provide all that to the UI and let it do its
> thing, rather than boiling it down into a number (and discarding useful
> information in the process.)
>
>>     ______________________________**___________________
>>
>>     stir mailing list
>>     https://www.ietf.org/mailman/_**_listinfo/stir<https://www.ietf.org/mailman/__listinfo/stir>
>>     <https://www.ietf.org/mailman/**listinfo/stir<https://www.ietf.org/mailman/listinfo/stir>
>> >
>>
>>
>>
>>
>>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Tue, 20 Aug 2013 18:12:24 -0400

I think the originating SP may in many cases *be* the validator.  But I agree with Paul that it should be visible to the called party which entity is making the assertion.  Some care will obviously have to be taken to ensure this isn't spoofed, since claiming to be a trustworthy validator is an obvious attack vector.

tim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Tuesday, August 20, 2013 4:43 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

No objection to carrying more, but probably we have to standardize what more is, and that may blow up the problem.  I can look into that aspect as it applies to other domains where the same database is used.

I do think we have to include the identity of the validation service, but I think that would in inherent in the mechanism one way or another.  Can't have the caller or the originating SP mucking with the score, can we?

Brian

On Tue, Aug 20, 2013 at 5:37 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

IMO a "score" (in the sense of a single number) is probably also not the most appropriate input to presentation solutions. I expect that we will likely have an assortment of data that can be used to assess the validity of the name. Better to just provide all that to the UI and let it do its thing, rather than boiling it down into a number (and discarding useful information in the process.)

For instance, if the name in the request is signed, then the identity of the signer may be useful. And stuff that gets looked up at the receiving end can have arbitrary properties.

We are

        Thanks,
        Paul

Brian

On Tue, Aug 20, 2013 at 4:23 PM, Stephen Kent <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Hannes,

        Hi Steve,

    agreed!

    see comments above.

        Of course, all this does not sound like the ingredients for an
        easy protocol design.

        So, what should we do?

    1. agree that we're going to pursue only calling # security measures
    until
    this WG re-charters.

    2. consider an IAB workshop or an IRTF group to deal with the issue
    of how
    to represent individual or org ID info to users (not just VoIP)
    users in a way
    that does more god than harm.

    Steve

    stir mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    https://www.ietf.org/mailman/__listinfo/stir
    <https://www.ietf.org/mailman/listinfo/stir>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Aug 2013 18:17:54 -0400

ISTM that either:
- it is inserted and signed by the caller,
- it is determined up by somebody acting for the caller,
   based on authenticated identity of the caller,
   inserted and signed,
- it is looked up by somebody in the call path,
   based on the authenticated calling number, inserted and signed,
- or it is looked up at the receiving end by the authenticated
   calling number.
- somebody in the call path asserts the identity, without
   signing it. The recipient depends on transitive trust to
   guarantee the validity.

 From the receivers perspective, either it gets an asserted calling name 
that it simply trusts, or else it gets a signed calling name, or else it 
looks up a name itself based on the calling number.

In the asserted case (current IMS) if there is to be any variation in 
trustworthyness, then there will need to be some new mechanism to convey 
just that part.

If it looks up the name itself, then what information is available about 
trustworthyness comes from its trust in the lookup service plus whatever 
is returned as part of the lookup. IMO we don't need to specify that.

If it gets a signed calling name in the signaling, then it has 
information about the signer (probably a cert) to go on. Couldn't we 
just assume that the cert conveys (implicitly or explicitly) the level 
of confidence in the name?

	Thanks,
	Paul

On 8/20/13 5:42 PM, Brian Rosen wrote:
> more is, and that may blow up the problem.  I can look into that aspect
> as it applies to other domains where the same database is used.
>
> I do think we have to include the identity of the validation service,
> but I think that would in inherent in the mechanism one way or another.
>   Can't have the caller or the originating SP mucking with the score,
> can we?
>
> Brian
>
>
>     IMO a "score" (in the sense of a single number) is probably also not
>     the most appropriate input to presentation solutions. I expect that
>     we will likely have an assortment of data that can be used to assess
>     the validity of the name. Better to just provide all that to the UI
>     and let it do its thing, rather than boiling it down into a number
>     (and discarding useful information in the process.)
>
>     For instance, if the name in the request is signed, then the
>     identity of the signer may be useful. And stuff that gets looked up
>     at the receiving end can have arbitrary properties.
>
>
>         We are
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              Hannes,
>
>                  Hi Steve,
>
>              ___________________________________________________
>
>              stir mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/stir
>         <https://www.ietf.org/mailman/__listinfo/stir>
>              <https://www.ietf.org/mailman/__listinfo/stir
>         <https://www.ietf.org/mailman/listinfo/stir>>
>
>
>
>
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Aug 2013 20:15:33 -0400

Inline

> - it is inserted and signed by the caller,
Yes, possible, and workable

>   based on authenticated identity of the caller,
Yes, originating SP could do it.  Could also be an enterprise if you want
to separate the calling device from a proxy in the enterprise.  Not likely
any other SP until we get to the terminating domain

>   based on the authenticated calling number, inserted and signed,
Not likely, except as above

> - or it is looked up at the receiving end by the authenticated
Yes, but not as good as inserted in the orginating side.  It could be the
device or a service invoked by the device, or the terminating SP

>   signing it. The recipient depends on transitive trust to
I doubt this is useful

> looks up a name itself based on the calling number.
Yeah, the first is the situation for display name today.  The last is the
existing alternate CNAM dips that some terminating SPs use today.

> trustworthyness, then there will need to be some new mechanism to convey
Yes, that would be new work

> trustworthyness comes from its trust in the lookup service plus whatever is
> returned as part of the lookup. IMO we don't need to specify that.
>
Yeah, that exists today, no standardization needed.

>
> If it gets a signed calling name in the signaling, then it has information
> about the signer (probably a cert) to go on. Couldn't we just assume that
> the cert conveys (implicitly or explicitly) the level of confidence in the
> name?
>
No.  The score is based on a whole bunch of variables and varies from
record to record.  So it can't be in the cert.

>> On Tue, Aug 20, 2013 at 5:37 PM, Paul Kyzivat <[email-masked]
>> <mailto:[email-masked]>**> wrote:
>>
>>              ______________________________**_____________________
>>
>>              stir mailing list
>>         https://www.ietf.org/mailman/_**___listinfo/stir<https://www.ietf.org/mailman/____listinfo/stir>
>>         <https://www.ietf.org/mailman/**__listinfo/stir<https://www.ietf.org/mailman/__listinfo/stir>
>> >
>>              <https://www.ietf.org/mailman/**__listinfo/stir<https://www.ietf.org/mailman/__listinfo/stir>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 20 Aug 2013 20:46:25 -0400

Well we are there right now.

http://datatracker.ietf.org/wg/repute/charter/

Though not necessarily applicable to the STIR problem statement we know we
are dealing with this issue in multiple areas. 

A numeric value to a level of reputation trust could be easily grasped by
consumers.  

They certainly know what their credit rating score is when going for a car
loan. 

The issue is some form of data object presented to the SIP UA that presents
it to the consumer. We are not going there. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Tuesday, August 20, 2013 5:38 PM
To: [email-masked]
Subject: Re: [stir] Early Homework (was Re: Moving from BOF to Charter)

IMO a "score" (in the sense of a single number) is probably also not the
most appropriate input to presentation solutions. I expect that we will
likely have an assortment of data that can be used to assess the validity of
the name. Better to just provide all that to the UI and let it do its thing,
rather than boiling it down into a number (and discarding useful information
in the process.)

For instance, if the name in the request is signed, then the identity of the
signer may be useful. And stuff that gets looked up at the receiving end can
have arbitrary properties.

> don't need to know how they work, or what any UI will do with them.  
> We don't even need to offer advise on what to do.

	Thanks,
	Paul

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Aug 2013 15:26:52 -0400

Brian,

As of now, the charter expressly refers to caller identity that we're 
working
to secure as the caller's phone number (with some broad interpretation 
of that phrase). If you want a caller name to be in scope, you should 
ask for a change to the charter text.

Steve

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 22 Aug 2013 14:53:37 +0000

> What is the successor to CNAM? 

The thing that has already replaced CNAM for me is my personal address book on my phone and/or linkedin. When I get a call on my phone, the caller ID is looked up in the address book and the name that I assigned in my address book gets display. I like that. Some newer stuff will use my social networks to grab me the relevant context for that phone number. 

So to be clear, I view the CNAM thing, which is about human readable names that are not unique, should be kept very separate from the unique identifiers (phone numbers in this context). The problem of how the CA can verify the human readable name seems not only hard to solve, but also undesirable to bother solving. Other attributes, like "this organization is a US registered bank" might be easier to deal with.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 22 Aug 2013 14:46:34 -0400

<hat type="none"/>

More generally, if a called party can authenticate a TN, then they can use
that as a trusted key to look up associated information (names, attributes)
from other services.  In Cullen's example, that service is a local one (the
phone address book), but in principle you could also have network-based
services.  So focusing on the TN authentication problem first seems
entirely sensible.

--Richard

On Thu, Aug 22, 2013 at 10:53 AM, Cullen Jennings (fluffy) <[email-masked]

> The thing that has already replaced CNAM for me is my personal address
> book on my phone and/or linkedin. When I get a call on my phone, the caller
> ID is looked up in the address book and the name that I assigned in my
> address book gets display. I like that. Some newer stuff will use my social
> networks to grab me the relevant context for that phone number.
>
> So to be clear, I view the CNAM thing, which is about human readable names
> that are not unique, should be kept very separate from the unique
> identifiers (phone numbers in this context). The problem of how the CA can
> verify the human readable name seems not only hard to solve, but also
> undesirable to bother solving. Other attributes, like "this organization is
> a US registered bank" might be easier to deal with.
>
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Aug 2013 11:49:22 -0700

On 8/22/2013 11:46 AM, Richard Barnes wrote:
> if a called party can authenticate a TN, then they can use that as a
> trusted key to look up associated information (names, attributes) from
> other services.

This is one of the better and more concise descriptions of the value 
proposition for this type of mechanism that I've seen (after more than 
10 years working on the same type of mechanism for email...)

d/