Subject: [stir] Encoding considerations

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Oct 2015 15:00:19 +0000

We seem to have reached some agreement on four issues:

(1) All proposals support a variety of keying architectures (various PK mechanisms and granularities, maybe even private shared keys);

(2) The expressive power of JWT and 4474bis seems roughly similar (and any substantive differences can probably be narrowed fairly easily);

(3) Multiple signatures are helpful;

(4) Signatures will be added and validated by a variety of systems, from UAs to proxies to B2BUAs/SBCs, depending on the system architecture, and the signer may not be able to predict who will look at the signature downstream.

On "how to carry signatures", there seem to be three options:

(1) JWT as multipart-MIME;

(2) Headers (Identity, Identity-Info, Identity-Extension, etc.) in 4474bis

(3) JWT blobs as (base-64?) headers.

[Obviously, (3) hasn't actually been proposed; it's just the intersection of (1) and (2) that I made up.]

The encoding format seems to matter primarily in terms of architecture (who is supposed to inspect what parts of the SIP message), backwards-compatibility (does the call setup fail or does the information get stripped) and, somewhat less importantly, total message size and the ability to use UDP as a SIP transport in both the baseline case (simple telephone number signing) and more elaborate cases.

If I understand this correctly, the JWT model is a "copy" ("by value") model, i.e., all the data signed is copied into the JWT object, while the current 4474bis model is a reference model, i.e., it just references header, either implicitly or explicitly. I'd like to understand the implications of this difference. We talked a bit about information leakage for numbers, but I also wonder about the need of validators to establish the equivalence of data items, presumably through some kind of canonicalization step for headers and SDP.

I'm also unsure how the current 4474bis model supports multiple independent signatures.

Looking forward to the discussion.

Henning

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 16 Oct 2015 15:02:27 +0000

UAs as UEs, no

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: [email-masked]<mailto:[email-masked]>

On Oct 16, 2015, at 11:00 AM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

Henning

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Oct 2015 15:06:28 +0000

I'm afraid I don't quite understand your comment. Could you explain both the statement and maybe the reasoning behind it? Also, are you saying that the "no" implies "not of interest to AT&T" vs. "should be prohibited in the architecture"?

________________________________
From: DOLLY, MARTIN C <[email-masked]>
Sent: Friday, October 16, 2015 11:02 AM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [stir] Encoding considerations

UAs as UEs, no

Martin C Dolly

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 16 Oct 2015 15:14:48 +0000

Trust model where the UE is not trusted

Also, the verifying entity is one that is assigned a number

I assume the FCC will only assign numbers to entities they can punish

I do not see individuals fitting in that model

Regards from Serbia

Martin C Dolly

On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

________________________________
From: DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 16, 2015 11:02 AM
To: Henning Schulzrinne
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Encoding considerations

UAs as UEs, no

Martin C Dolly

---

From: Chris Wendt <[email-masked]>
Date: Fri, 16 Oct 2015 11:18:51 -0400

Maybe a more general way to say this is, you are a trusted UA if you have credentials to sign the INVITE, wherever the UA is in the network.

> On Oct 16, 2015, at 11:14 AM, DOLLY, MARTIN C <[email-masked]> wrote:
> 
> Email: [email-masked] <mailto:[email-masked]>
> 
> On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> From: DOLLY, MARTIN C <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>
>> Email: [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 16 Oct 2015 15:19:42 +0000

Fine with that😀

Martin C Dolly

On Oct 16, 2015, at 11:18 AM, Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:

On Oct 16, 2015, at 11:14 AM, DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>> wrote:

Regards from Serbia

Martin C Dolly

UAs as UEs, no

Martin C Dolly

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Oct 2015 15:20:26 +0000

Regardless of the number assignment issue (which we have hashed over elsewhere...), I thought I've been hearing the notion that signatures not directly tied to numbers would be valuable. In that model, it seems at least plausible that (say) United Airlines, Bank of America or the IRS would sign a call request, in their respective roles as airlines, financial institution or government agency, not as a carrier. This would probably be augmented by a traditional carrier or number-based signature.

________________________________
From: DOLLY, MARTIN C <[email-masked]>
Sent: Friday, October 16, 2015 11:14 AM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [stir] Encoding considerations

Regards from Serbia

---

From: Eric Burger <[email-masked]>
Date: Fri, 16 Oct 2015 11:27:29 -0400

Inline.

> On Oct 16, 2015, at 11:00 AM, Henning Schulzrinne <[email-masked]> wrote:
> 

I think you and I agree: this is one of the bigger points, but not going to be discussed today.

> (2) The expressive power of JWT and 4474bis seems roughly similar (and any substantive differences can probably be narrowed fairly easily);

True, although 4474bis needs to invent just what it is that JWT brings. That is why I lean towards JWT. Instead of inventing something that looks like and smells like JWT, might as well use JWT. Moreover, there are lots of open source libraries for JWT processing, as opposed to whole-cloth code that we would need to write for 4474bis. I could argue that the bespoke code for 4474bis will be a lot more efficient than JWT, as it will focus on the four or five fields and only those fields and not need to be able to handle arbitrary attributes. However, everyone seems to be talking about optionally bringing other attributes into 4474bis, which would make 4474ter and beyond look like spaghetti code. Ultimately, we will end up with something that looks like JWT. Given this, I would offer let us start with JWT and be done with it.

> (3) Multiple signatures are helpful;

There was talk of this. Can someone, anyone, please write down what the use case is and what it looks like and who would use it?

> (4) Signatures will be added and validated by a variety of systems, from UAs to proxies to B2BUAs/SBCs, depending on the system architecture, and the signer may not be able to predict who will look…

This ties in to #3. If there is a provision for multiple signers, then I think we get into an n^2 or so combination of authenticators and validators. If there is not a provision for multiple signers, then we do not need to worry. If you are some unnamed service provider that will not allow the UA to sign their own messages, great: you will be running the message through a B2BUA anyway. Do what you want. The other end will see the man-in-the-middle attack, as the message will not have the expected signature by the UA, but it will be able to whine to the service provider, if they care.

> (1) JWT as multipart-MIME;

You seem to be adamant that no one in the wild wants or does MIME. If that is the case, this is a non-starter option. I have not surveyed the market, so I will defer to you. Other voices?

> (2) Headers (Identity, Identity-Info, Identity-Extension, etc.) in 4474bis

I really like Identity or Identity-Info. Global, interoperable, not relying on service providers breaking their vows to strip P-*-mumble when messages cross IMS boundaries, etc.

> (3) JWT blobs as (base-64?) headers.

Why not? (See below on size)

> The encoding format seems to matter primarily in terms of architecture (who is supposed to inspect what parts of the SIP message), backwards-compatibility (does the call setup fail or does the info…

We are talking about spit remediation. If email is any guide, the signatures (e.g., SPF, DKIM, S/MIME), internal routing recording (X-Spam-mumble), and regular route recording (Received in email, Via in SIP), will push anything beyond UDP.

Anyone in the wild really not able to do TCP or SCTP?

> If I understand this correctly, the JWT model is a "copy" ("by value") model, i.e., all the data signed is copied into the JWT object, while the current 4474bis model is a reference model, i.e., it…

Good catch. I suppose that with the copy by value, there will be temptation to ignore the SIP signaling and use the JWT values. That is a temptation that needs avoidance.

> I'm also unsure how the current 4474bis model supports multiple independent signatures.

I’m not sure what anyone will do with multiple, independent signatures.

> Looking forward to the discussion.

Me, too!

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 16 Oct 2015 15:30:09 +0000

#3: Government priority services

Martin C Dolly

On Oct 16, 2015, at 11:27 AM, Eric Burger <[email-masked]<mailto:[email-masked]>> wrote:

Inline.

Me, too!

---

From: Eric Burger <[email-masked]>
Date: Fri, 16 Oct 2015 11:31:13 -0400

I’ll go further. I am convinced that for the foreseeable future, signatures tied to numbers are beyond unrealistic and useless.

The only thing worth tying to the signature is who is doing the signing. Having the signature tied to the number that is the number that is being signed adds near zero value. This is not a response to US 8,200,959. There could be use cases for having the signature tied to the number. However, I do not see it, and I see a ton of bad things happening if we do say the certificate signing the signaling includes the number being vouched for.

> On Oct 16, 2015, at 11:20 AM, Henning Schulzrinne <[email-masked]> wrote:
> 
> 
> [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: Fri, 16 Oct 2015 11:38:25 -0400

> I do not see individuals fitting in that model

There has been considerable discussion of a delegation model. So ATT may 
be assigned a number and then delegate it to an enterprise. Then IIUC 
both the enterprise and SP would be able to sign, using different 
credentials.

In the case of enterprises with PBXs, the enterprise is in a position to 
verify *which* of those numbers is being used for a specific call. The 
signature by the SP can probably only assure that the number being 
asserted is one that the enterprise, or PBX, is authorized to use.

And those checking can decide which signature they want to trust. The 
enterprise's other locations will probably trust their own signature.

	Thanks,
	Paul

> On Oct 16, 2015, at 11:06 AM, Henning Schulzrinne
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> I'm afraid I don't quite understand your comment. Could you explain
>> both the statement and maybe the reasoning behind it? Also, are you
>> saying that the "no" implies "not of interest to AT&T" vs. "should be
>> prohibited in the architecture"?
>>
>>
>> ------------------------------------------------------------------------
>> *From:* DOLLY, MARTIN C <[email-masked] <mailto:[email-masked]>>
>> *Sent:* Friday, October 16, 2015 11:02 AM
>> *To:* Henning Schulzrinne
>> *Cc:* [email-masked] <mailto:[email-masked]>
>> *Subject:* Re: [stir] Encoding considerations
>> UAs as UEs, no
>>
>> Martin C Dolly

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Oct 2015 15:39:28 +0000

Besides the priority services case, I do believe there's a good case to be made for a dual signature during the interim:

(Signature 1): "Hi, I'm the carrier and attest to having originated this call"

(Signature 2): "Hi, I'm the alerting entity placing calls on behalf of United Airlines and I got a proof-of-possession signature from a third party. I hope you like it."

This allows us to deal with the exception cases without inferring more trust to UAs than Martin is prepared to do, while allowing carriers to do "blanket" signatures, regardless of the number.

The "signed by Bank of America" case is another example, i.e., no number-based cert at all.

We have also talked about separate signatures for CNAM-like pieces of the call, likely added by somebody else (such as the terminating carrier or a third-party validator) downstream of the originating carrier.

I don't know how common this is going to be, but I'd rather have the option now than find out that we're stuck without it, particularly in the initial phase of experimentation, partial deployment and exception cases.

Henning

________________________________
From: stir <[email-masked]> on behalf of Eric Burger <[email-masked]>
Sent: Friday, October 16, 2015 11:27 AM
To: [email-masked]
Subject: Re: [stir] Encoding considerations

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Oct 2015 15:45:39 +0000

Could you explain the problem in more detail?

One simple model I envision is the "Skype model" (and maybe the AT&T OneNumber model, although I don't quite know yet how that works): You get a trusted third party to issue you a cert based on your simple fact of having been assigned a number, i.e., you can be reached at that number. (Skype allows you to put your cell number in outbound calls, but they call you first and you have to enter a PIN into the web form, conveyed by a phone call to that number, so that you can't easily claim somebody else's number.) It doesn't say anything beyond that - no legal authority, no formal number assignment, etc. This can handle the doctor's office problem, and at least some of the PBX issues.

Henning

________________________________
From: stir <[email-masked]> on behalf of Eric Burger <[email-masked]>
Sent: Friday, October 16, 2015 11:31 AM
To: [email-masked]
Subject: Re: [stir] Encoding considerations

I'll go further. I am convinced that for the foreseeable future, signatures tied to numbers are beyond unrealistic and useless.

---

From: Eric Burger <[email-masked]>
Date: Fri, 16 Oct 2015 11:50:01 -0400

In this scenario, it is really Microsoft or AT&T that is doing the attesting. Yes, there is a certificate that has a number in it, but that number could be +1 666-666-6666. All the verifier does is check that it passes.

My expectation is that someone like Martin will look to see if Microsoft or some real root is in the chain. I would really hope that no one accepts a message signed with a free Comodo cert to mean anything other than the message was signed.

> On Oct 16, 2015, at 11:45 AM, Henning Schulzrinne <[email-masked]> wrote:
> 
> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of Eric Burger <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>

---

From: Chris Wendt <[email-masked]>
Date: Fri, 16 Oct 2015 11:51:26 -0400

I think this could be used for special highly verified/authorized cases potentially.

Think, the school snow day call must get through no matter how shady the robo-call service they are using might seem to the terminating provider and the fact that the caller-id is being spoofed.

> On Oct 16, 2015, at 11:31 AM, Eric Burger <[email-masked]> wrote:
> 
>> On Oct 16, 2015, at 11:20 AM, Henning Schulzrinne <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Oct 2015 15:57:45 +0000

For the Comodo web cert (not the free one, but the $40/year one), they actually do validate the phone number that appears in the certificate. I just did this a few days ago when I upgraded a cert to SHA256 and they do exactly what I described for the Skype case.

Yes, it would be the signing entity (probably not Microsoft, but some CA)  that is doing the attesting. Whether anybody trusts that CA is a separate matter; indeed, having multiple signatures allows to deal with that case somewhat more gracefully since you can then set policies, maybe even with something DANE-like. ("I only accept calls claiming to be from the IRS if they are signed by the IRS since they claim to sign all such calls.")

Henning
________________________________
From: stir <[email-masked]> on behalf of Eric Burger <[email-masked]>
Sent: Friday, October 16, 2015 11:50 AM
To: [email-masked]
Subject: Re: [stir] Encoding considerations

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Oct 2015 16:05:25 +0000

Right - we also know that otherwise legitimate businesses sometimes end up hosting shady customers, directly or indirectly, and inadvertently. (See the NYT front page story about gambling outfits and the services they use, if you want a very recent example.)

I frankly don't see how large wholesale gateway providers can vet all their upstream customers and the numbers they are entitled to use. Many of the shady customers will appear, place their spoofed calls, collect their fraud toll, and then vanish in a matter of hours or days.

________________________________
From: stir <[email-masked]> on behalf of Chris Wendt <[email-masked]>
Sent: Friday, October 16, 2015 11:51 AM
To: Eric Burger
Cc: [email-masked]
Subject: Re: [stir] Encoding considerations

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 16 Oct 2015 16:12:27 +0000

I think it is important there is a very clear algorithm for what the device receiving multiple signatures does with them. 

I get the idea of one signature that says AT&T claims this is Cullen and another that says Cullen is allowed priority services but those are two pretty much unrelated assertions. 

What I don't want is "here's a boat load of information that may or may not help a human make a decisions about what to do with this call" - we need things that make for a clear algorithm where a machine can execute a policy. 

> On Oct 16, 2015, at 9:39 AM, Henning Schulzrinne <[email-masked]> wrote:
> 
>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 16 Oct 2015 16:13:43 +0000

Most of the abuse comes from pink enterprise, so where do we draw the line 

Martin C Dolly
Email: [email-masked]

> On Oct 16, 2015, at 11:38 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> There has been considerable discussion of a delegation model. So ATT may be assigned a number and then delegate it to an enterprise. Then IIUC both the enterprise and SP would be able to sign, using different credentials.
> 
> In the case of enterprises with PBXs, the enterprise is in a position to verify *which* of those numbers is being used for a specific call. The signature by the SP can probably only assure that the number being asserted is one that the enterprise, or PBX, is authorized to use.
> 
> And those checking can decide which signature they want to trust. The enterprise's other locations will probably trust their own signature.
> 
>    Thanks,
>    Paul
> 
>> Regards from Serbia
>> 
>> Martin C Dolly

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 16 Oct 2015 16:19:36 +0000

When we discussed this in the RFC4474 past, I recall we cast this in terms
of having different SIP headers to differentiate the semantics of
signatures. For example, we looked the notion of a "verification
assertion" that would provide middle-to-end security for cases where the
recipient endpoint trusted a specific party in the middle who effectively
brokered security associations. That I think would belong in a header with
different semantics as Identity. As long as these things are properly
differentiated so that verifiers know who did what, and don't confuse
people doing Henning's signature (1) with hose doing (2), then there are
workable ways to approach it.

Jon Peterson
Neustar, Inc.

On 10/16/15, 9:12 AM, "Cullen Jennings (fluffy)" <[email-masked]> wrote:

>
>I think it is important there is a very clear algorithm for what the
>device receiving multiple signatures does with them.
>
>I get the idea of one signature that says AT&T claims this is Cullen and
>another that says Cullen is allowed priority services but those are two
>pretty much unrelated assertions.
>
>What I don't want is "here's a boat load of information that may or may
>not help a human make a decisions about what to do with this call" - we
>need things that make for a clear algorithm where a machine can execute a
>policy. 
>
>
>> Besides the priority services case, I do believe there's a good case to
>>be made for a dual signature during the interim:
>> 
>> (Signature 2): "Hi, I'm the alerting entity placing calls on behalf of
>>United Airlines and I got a proof-of-possession signature from a third
>>party. I hope you like it."
>> 
>> This allows us to deal with the exception cases without inferring more
>>trust to UAs than Martin is prepared to do, while allowing carriers to
>>do "blanket" signatures, regardless of the number.
>> 
>> We have also talked about separate signatures for CNAM-like pieces of
>>the call, likely added by somebody else (such as the terminating carrier
>>or a third-party validator) downstream of the originating carrier.
>> 
>> I don't know how common this is going to be, but I'd rather have the
>>option now than find out that we're stuck without it, particularly in
>>the initial phase of experimentation, partial deployment and exception
>>cases.
>> 
>> Henning
>> 
>> There was talk of this. Can someone, anyone, please write down what the
>>use case is and what it looks like and who would use it?
>> 
>>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 16 Oct 2015 16:20:42 +0000

Carrier A signs this is X
GETS carrier signs this is a priority user 

Martin C Dolly

> On Oct 16, 2015, at 12:12 PM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2015 12:25:41 -0400

> Most of the abuse comes from pink enterprise, so where do we draw the line

A couple of answers come to mind:

- I only trust the enterprises I want to trust

- The delegation model is tied to the cert chain. So I can trust the 
signature if I trust the CA. (ACME Corp obtained the number from 
ATT.com, so ACME's signature uses a cert with ATT as the CA, and I trust 
ATT.)

	Thanks,
	Paul

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 16 Oct 2015 16:26:07 +0000

"I only accept calls claiming to be from the IRS if they are signed by the IRS since they claim to sign all such calls."

You're suggesting carriers will manage dozens/hundreds/thousands of policies such as your example in distributed SBCs and/or AS's and apply to ALL terminating phone calls?

Pierce Gorman
Core Network Planning
Sprint
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: October 16, 2015 10:58 AM
To: Eric Burger <[email-masked]>; [email-masked]
Subject: Re: [stir] Encoding considerations

Henning
________________________________
From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Eric Burger <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 16, 2015 11:50 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Encoding considerations

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Oct 2015 16:27:09 +0000

Indeed - as a carrier, there are really two cases:

(1) "This call is from one of my (direct/well-known indirect) customers and I know that they are entitled to use the number they stuck in the SIP header"

(2) "I carried this call, but I have no way to validate whether the number is theirs to use or not."

Since, as you say, a lot of bad stuff falls into the second category, along with legitimate calls, it would be nice to have an additional mechanism to allow the good guys to do more so that they don't get tarnished by association. And we know that entities come in various shades of pink, from victims where a bad apple slipped by to "I'm shocked, shocked that gambling is going on here".

________________________________________
From: stir <[email-masked]> on behalf of DOLLY, MARTIN C <[email-masked]>
Sent: Friday, October 16, 2015 12:13 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [stir] Encoding considerations

Martin C Dolly

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2015 12:28:01 -0400

> ATT.com, so ACME's signature uses a cert with ATT as the CA, and I trust

Or, better, ACME got the number from ATT and ATT got the number from 
FCC. ATT is CA for ACME, FCC is CA for ATT. I trust FCC.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Oct 2015 16:32:47 +0000

No - they can easily delegate this to third parties. There are lots of entities that manage [telephone] reputation as a business. We heard from some at the FCC workshop, and there are others, whether Dun & Bradstreet or various credit rating-style entities. I suspect there are one or two represented on this mailing list. These entities keep track of the reputation and behavior of millions of businesses and hundreds of millions of consumers. Also, for the high-profile fraud cases (such as the IRS), the number of spoof-worthy entities is pretty small. You have to be big or reasonably-well-known to be worth spoofing - nobody is going to spoof the hair salon on Main Street to extort money.

________________________________
From: stir <[email-masked]> on behalf of Gorman, Pierce A [CTO] <[email-masked]>
Sent: Friday, October 16, 2015 12:26 PM
To: Henning Schulzrinne; Eric Burger; [email-masked]
Subject: Re: [stir] Encoding considerations

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 16 Oct 2015 16:33:13 +0000

No

Martin C Dolly

> On Oct 16, 2015, at 12:25 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> - The delegation model is tied to the cert chain. So I can trust the signature if I trust the CA. (ACME Corp obtained the number from ATT.com, so ACME's signature uses a cert with ATT as the CA, and I trust ATT.)
> 
>    Thanks,
>    Paul
> 
>> Martin C Dolly

---

From: Chris Wendt <[email-masked]>
Date: Fri, 16 Oct 2015 12:37:00 -0400

I would just caution for the discussion this afternoon, let’s not focus on the certificate associations and usage and rather focus on the syntax.  They are and should be separate issues.

-Chris

> On Oct 16, 2015, at 12:32 PM, Henning Schulzrinne <[email-masked]> wrote:
> 
> You’re suggesting carriers will manage dozens/hundreds/thousands of policies such as your example in distributed SBCs and/or AS’s and apply to ALL terminating phone calls?
>  
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2015 12:37:13 -0400

On 10/16/15 12:26 PM, Gorman, Pierce A [CTO] wrote:
> "I only accept calls claiming to be from the IRS if they are signed by
> the IRS since they claim to sign all such calls."
>
> You’re suggesting carriers will manage dozens/hundreds/thousands of
> policies such as your example in distributed SBCs and/or AS’s and apply
> to ALL terminating phone calls?

Not necessary as long as the signatures can also be checked further 
downstream - the UAS, or perhaps a receiving PBX.

So I could configure my own policies into my phone. I might do this in 
response to annoying calls.

Of course when done this way the SP doesn't get to charge an extra fee 
for doing this "screening". :-)

	Thanks,
	Paul

> *Pierce Gorman*
>
> Core Network Planning
>
> Sprint
>
> *From:*Henning Schulzrinne [mailto:[email-masked]]
> *Sent:* October 16, 2015 10:58 AM
> *To:* Eric Burger <[email-masked]>; [email-masked]
> For the Comodo web cert (not the free one, but the $40/year one), they
> actually do validate the phone number that appears in the certificate. I
> just did this a few days ago when I upgraded a cert to SHA256 and they
> do exactly what I described for the Skype case.
>
> Yes, it would be the signing entity (probably not Microsoft, but some
> CA)  that is doing the attesting. Whether anybody trusts that CA is a
> separate matter; indeed, having multiple signatures allows to deal with
> that case somewhat more gracefully since you can then set policies,
> maybe even with something DANE-like. ("I only accept calls claiming to
> be from the IRS if they are signed by the IRS since they claim to sign
> all such calls.")
>
>
> Henning
>
> *From:*stir <[email-masked] <mailto:[email-masked]>> on
> behalf of Eric Burger <[email-masked]
> <mailto:[email-masked]>>
> *Sent:* Friday, October 16, 2015 11:50 AM
> *To:* [email-masked] <mailto:[email-masked]>
> In this scenario, it is really Microsoft or AT&T that is doing the
> attesting. Yes, there is a certificate that has a number in it, but that
> number could be +1 666-666-6666. All the verifier does is check that it
> passes.
>
> My expectation is that someone like Martin will look to see if Microsoft
> or some real root is in the chain. I would really hope that no one
> accepts a message signed with a free Comodo cert to mean anything other
> than the message was signed.
>
>
> This e-mail may contain Sprint proprietary information intended for the
> sole use of the recipient(s). Any use by others is prohibited. If you
> are not the intended recipient, please contact the sender and delete all
> copies of the message.
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2015 12:39:09 -0400

> No

I'm really tired of reading comments that are so cryptic that they can't 
be understood.

*What* are you saying No to?

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Oct 2015 16:41:30 +0000

One plausible use case for what Paul mentions is phishing prevention for government agencies, health care facilities and financial institutions, in addition to protecting vulnerable groups (retirement community).

________________________________________
From: stir <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: Friday, October 16, 2015 12:37 PM
To: [email-masked]
Subject: Re: [stir] Encoding considerations

        Thanks,
        Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 16 Oct 2015 16:43:14 +0000

Thanks for hauling us back - I think this started with the "what's the use case for multiple signatures", but I think we have beaten that topic into the ground.

________________________________
From: Chris Wendt <[email-masked]>
Sent: Friday, October 16, 2015 12:37 PM
To: Henning Schulzrinne
Cc: Gorman, Pierce A [CTO]; Eric Burger; [email-masked]
Subject: Re: [stir] Encoding considerations

I would just caution for the discussion this afternoon, let's not focus on the certificate associations and usage and rather focus on the syntax.  They are and should be separate issues.

-Chris

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 16 Oct 2015 16:48:29 +0000

No to your example
In a word NO

Martin C Dolly

> On Oct 16, 2015, at 12:39 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> I'm really tired of reading comments that are so cryptic that they can't be understood.
>

---

From: Alex Bobotek <[email-masked]>
Date: Fri, 16 Oct 2015 09:43:53 -0700

There are many operational reasons for signing with multiple keys.  One of them stems from signing having different meaning at different points in the call flow.  DKIM's signatures, for example, are often described as allowing a signing entity to take some responsibility for the signed message, perhaps that it transited the signer's network with the implication that it met their transit policy criteria.

Consider an INVITE or MESSAGE signed by the originating user and the originating service provider.  A policy engine may wish to consider reputation of each signature, as well as whether the originating service provider is the carrier of record for the originating identity.  As an end user, I might trust my friend's originating user signature more than a service providers.  As a recipient of a suspicious call, policy might more heavily weight the reputation of the first signing service provider than a potentially unknown calling party's identity.

In the case of defending a small town from a DDOS attack, it may be appropriate to allow only calls that appear to have NOT transited or originated in a certain network, or have been routed through another network.  There are many examples of this in DMARC/DKIM and email defense, where almost every conceivable aspect of headers, envelope and body are used as policy inputs.

Some models of delegated ownership and authority over an entity are also facilitated by multiple keys.

IMHO it is advisable to have the signing syntax

*         permit multiple signatures,

*         define a sufficient set of signable aspects (e.g., headers) and

*         permit the signer to declare which aspects they are signing.

Regards,

Alex

From: stir [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: Friday, October 16, 2015 8:30 AM
To: Eric Burger <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] Encoding considerations

Martin C Dolly

I'm not sure what anyone will do with multiple, independent signatures.

Me, too!

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 16 Oct 2015 17:04:13 +0000

The FCC should stay away from business models

Martin C Dolly

On Oct 16, 2015, at 12:33 PM, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>> wrote:

________________________________
From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 16, 2015 12:26 PM
To: Henning Schulzrinne; Eric Burger; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Encoding considerations

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2015 13:09:50 -0400

> The FCC should stay away from business models

Yes. That includes not blessing a particular established business model, 
but rather enabling other ones to develop.

	Thanks,
	Paul

> On Oct 16, 2015, at 12:33 PM, Henning Schulzrinne
>> No - they can easily delegate this to third parties. There are lots of
>> entities that manage [telephone] reputation as a business. We heard
>> from some at the FCC workshop, and there are others, whether Dun &
>> Bradstreet or various credit rating-style entities. I suspect there
>> are one or two represented on this mailing list. These entities keep
>> track of the reputation and behavior of millions of businesses and
>> hundreds of millions of consumers. Also, for the high-profile fraud
>> cases (such as the IRS), the number of spoof-worthy entities is pretty
>> small. You have to be big or reasonably-well-known to be worth
>> spoofing - nobody is going to spoof the hair salon on Main Street to
>> extort money.
>>
>>
>> *From:* stir <[email-masked] <mailto:[email-masked]>> on
>> behalf of Gorman, Pierce A [CTO] <[email-masked]
>> <mailto:[email-masked]>>
>> *Sent:* Friday, October 16, 2015 12:26 PM
>> *To:* Henning Schulzrinne; Eric Burger; [email-masked]
>> <mailto:[email-masked]>
>> policies such as your example in distributed SBCs and/or AS’s and
>> apply to ALL terminating phone calls?
>>
>>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 16 Oct 2015 17:16:55 +0000

Deploy ability is an issue though
Not theory Paul

Martin C Dolly

> On Oct 16, 2015, at 1:09 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Yes. That includes not blessing a particular established business model, but rather enabling other ones to develop.
> 
>    Thanks,
>    Paul
> 
>> Martin C Dolly

---

From: Richard Shockey <[email-masked]>
Date: Fri, 16 Oct 2015 20:06:22 -0400

The problem at least at this point is as follows.   Right now its the carriers that are on the hook for the abuses in the system.

However plausible that United Airlines is trusted, IMHO that is a oxymoron, I wouldn’t trust United Airlines with <fill in the blank> my vision of the construct is to build rings of defense starting with carrier to carrier transactions.

First a moat

Second  concertina wire.

Third  Browning 50 Caliber parapets. 

Each requires a level of trust.

There is going to be no progress if there is some command for one size fits all.

— 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

From:  stir <[email-masked]> on behalf of Henning Schulzrinne <[email-masked]>
Date:  Friday, October 16, 2015 at 11:20 AM
To:  "DOLLY, MARTIN C" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [stir] Encoding considerations

 

Regards from Serbia

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

---

From: Richard Shockey <[email-masked]>
Date: Fri, 16 Oct 2015 20:07:22 -0400

Among other use cases…

— 
Richard Shockey
Shockey Consulting LLC

From:  stir <[email-masked]> on behalf of "DOLLY, MARTIN C" <[email-masked]>
Date:  Friday, October 16, 2015 at 11:30 AM
To:  Eric Berger <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [stir] Encoding considerations

Martin C Dolly 

On Oct 16, 2015, at 11:27 AM, Eric Burger <[email-masked]> wrote:

Inline. 

Me, too!

---

From: Richard Shockey <[email-masked]>
Date: Fri, 16 Oct 2015 20:08:54 -0400

Paul do not go there. 

UNDER NO CIRCUMSTANCES UNDER ANY POSSIBLE CONSIDERATION are we going to discuss credential delegation here. 

— 
Richard Shockey
Shockey Consulting LLC

---

From: Richard Shockey <[email-masked]>
Date: Fri, 16 Oct 2015 20:11:51 -0400

RAT HOLE ALERT.

Eric don’t distract the discussion with credential distribution issues. 

Stick to knitting .. What goes on the wire and nothing else.

— 
Richard Shockey
Shockey Consulting LLC

From:  stir <[email-masked]> on behalf of Eric Berger <[email-masked]>
Date:  Friday, October 16, 2015 at 11:50 AM
To:  "[email-masked]" <[email-masked]>
Subject:  Re: [stir] Encoding considerations

Henning

---

From: Richard Shockey <[email-masked]>
Date: Fri, 16 Oct 2015 20:15:31 -0400

Correct they can’t but. They can claim what they trust and what they don’t and ultimately we can create some process by which the Consumer can decide what to accept an what they may not.

That is the reputation management part of this but it it not even orthogonal to the STIR/SHAKEN problem.  What is the minimal protocol set that goes on the wire. 

From:  stir <[email-masked]> on behalf of Henning Schulzrinne <[email-masked]>
Date:  Friday, October 16, 2015 at 12:05 PM
To:  Chris Wendt <[email-masked]>, Eric Berger <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [stir] Encoding considerations

---

From: Richard Shockey <[email-masked]>
Date: Fri, 16 Oct 2015 20:22:18 -0400

+1  My friend.

Not going to happen.  

From:  stir <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date:  Friday, October 16, 2015 at 12:26 PM
To:  Henning Schulzrinne <[email-masked]>, Eric Berger <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [stir] Encoding considerations

 

Pierce Gorman

Core Network Planning

Sprint

Henning

---

From: Richard Shockey <[email-masked]>
Date: Fri, 16 Oct 2015 20:26:48 -0400

What you are saying is do you trust the North American Number Plan delegation model.  Full disclosure I’m a NANC member. 

Second to you trust the authority by which the United States or Canada or Jamaica delegates numbers to Licensed Carriers.

Frankly I don’t care one way or the other.  The first order trust model IMHO is do I trust ATT [my mobile provider] to give me accurate information on who THEY trust.  I pay ATT by the way, quite happily and Verizon for my trustworthy FIOS landline.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 16 Oct 2015 20:27:34 -0400

Precisely .. We are not going there now or in the future IMHO.

From:  stir <[email-masked]> on behalf of Chris Wendt <[email-masked]>
Date:  Friday, October 16, 2015 at 12:37 PM
To:  Henning Schulzrinne <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [stir] Encoding considerations

-Chris

---

From: Richard Shockey <[email-masked]>
Date: Fri, 16 Oct 2015 20:37:20 -0400

+1 Precisely

---

From: Richard Shockey <[email-masked]>
Date: Fri, 16 Oct 2015 21:17:43 -0400

Paul .. I don’t know how to put this any other way but it might as well go on the record. I understand your concerns but elements of this are going far far into the weeds that will lead to a quagmire that will end up in tragedy that no one wants. 

I deeply respect you views and on behalf of the SIP Forum I put on the record you outstanding work in the VRS profile which was recently approved my our BoD.

First we know what the ultimate problem actually is that is well documented.

Second established Telephony Service Providers are on the hook for defining a solution. That is now self evident. We know its not just the FCC its the CRTC OFCOM etc.  The regulators are not looking at Ford, Caterpillar, Dyson ( the UK vacuum cleaner folks who I adore)  or any enterprise for solutions.  They point the finger at the Telephony Service Providers’s.  My view is that the trust model first and foremost has to establish the trust model between TSP’s then build the rings of defence. If the IETF cannot understand or accommodate the needs of TSP’s now then there is a very very large process problem that again will end up in tragedy for all concerned. 

Forget end to end for the time being.

Ok you and others may hate TSP’s but frankly get over it. We will not solve the very very real problem Consumers and Enterprises have nor can we accomodiate the perfectly ligmitate concerns of governmental entities to preserve protect and defend the realtime communications networks in times of national crisis until we can first address the KISS model TSP’s are proposing here.  

IMHO the IETF has no business telling NRA’s how to credentiaize anyone using E.164 numbers. USC 251 e 1 for a start. I can quote chapter and verse from UK and Canadian law if you wish.

I do not how to express this in more clear terms.  If the IETF chooses to impose its views on TSP business models in order to get RFC approval or try and define how the industry should be structured rules or how we deliver credentials on the wire then some of us will suggest that we take the ball bat glove etc an find a new sand box.  

My non negotiables are generally around the basic principals of what goes on the wire.  I absolutely demand that the functions of extensibility of the on wire protocols are preserved, I want to be able to sign the identity for a use case independently of the primary consideration, consistent reuse of existing headers, and the IANA considerations are really non restrictive. Like none.   Second Amendment.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 17 Oct 2015 11:53:01 -0400

> What you are saying is do you trust the North American Number Plan delegation model.  Full disclosure I’m a NANC member.

I trust ATT only as long as I think their interests align with mine.
There seem to be many times when that isn't the case.

I am much more inclined to trust their signature for a number they 
control than I am for one they don't control. So the question is whether 
I will be able to determine if they are authoritative for the number 
they are signing.

> Second to you trust the authority by which the United States or Canada or Jamaica delegates numbers to Licensed Carriers.

If the certs are tied to the specific numbers, or number ranges, then I 
would trust them to certify "This is one of our numbers and we delegated 
it to ATT".

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 17 Oct 2015 13:33:53 -0400

Richard,

I get it that the TSPs are on the hook and we need a solution that works 
for them. (That doesn't mean it can't also be used in other ways too. 
But I'll defer that.)

But focusing on how those TSPs will use it - what are you seeing as the 
model? Is it that the originating provider signs, and that signature 
travels to the callee? Or are you thinking of yet another transitive 
trust model, where each TSP decides if it trusts the incoming signature, 
and if so then replaces it with its own?

If the former, then does the terminating TSP decide about the trust and 
makes all the decisions? Or can the terminating device see and make its 
own decisions about trust in the signature?

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 17 Oct 2015 17:56:55 +0000

Paul

The intent is to pass it on to the UE and let the user decide

Martin C Dolly

> On Oct 17, 2015, at 1:34 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Richard,
> 
> I get it that the TSPs are on the hook and we need a solution that works for them. (That doesn't mean it can't also be used in other ways too. But I'll defer that.)
> 
> But focusing on how those TSPs will use it - what are you seeing as the model? Is it that the originating provider signs, and that signature travels to the callee? Or are you thinking of yet another transitive trust model, where each TSP decides if it trusts the incoming signature, and if so then replaces it with its own?
> 
> If the former, then does the terminating TSP decide about the trust and makes all the decisions? Or can the terminating device see and make its own decisions about trust in the signature?
> 
>    Thanks,
>    Paul
>

---

From: Richard Shockey <[email-masked]>
Date: Sat, 17 Oct 2015 14:40:54 -0400

Martin is correct. The former. The originating provider signs based on the fact that they issued the number to the customer and presumably has the billing relationship.  The terminating provider validates the call and presents to the UE the results.  I’m not worried about the UE actually doing the validation right now. In the future probably but I would prefer to start simple.  "Rings of Defense” KISS for now.

There are going to have to be some profiles about how transit providers treat the data etc but I don’t want to wade into the weeds about that right now. I’d prefer to see a classic SIP trapezoidal model emerge for the first round.

The preference is certainly to let the UE decide, however that does not preclude the terminating carrier from acting directly on behalf of the consumer, if that is the consumer preference. That BTW was the clear intent of the FCC robocall order.   I can run spam filters on my mail client or I can pay some one to act on my behalf . That’s a well understood model. 

Speaking of which .. Paul do you have any thoughts on where we could put Validation data so the UE could display it?  I can’t get a reasonable answer from folks about that.

---

From: Richard Shockey <[email-masked]>
Date: Sat, 17 Oct 2015 15:37:39 -0400

Disclaimer IMHO this is the way I see this if I had the magic wand. If there is a emerging consensus on what STIR/SHAKEN is trying to do its focus specifically on what goes on the wire and totally ignore any discussion of how the credentails are created delegated etc. That discussion is beyond wading in the weeds it would be rolling in the poison ivy. 

I believe there is NO POSSIBLE WAY there is any support for signing each and every TN. Its a non starter. In the NANP that is about 800 M. Yes its doable. There is ample precedent. Goodness there is some form of RPKI for all kinds of things out there from our credit cards to television set top boxes, but its not going to happen. The industry will not pay for it.  Just banish that idea from any concept of where we may be going for the time being. Oh and no one wants the mess we saw in WEB certs. Consequently you are looking at a highly defined delegation model.  It should not be surprising that there is a severe allergy among TSP’s for large numbering databases. 

The focus therefore is on signing a claim by the originating TSP that they trust this number ( they issued its to the consumer) and that they are responsible for the session. Its a much different view and a much more restricted view of what the chain of trust should be than where I think we started.   

IMHO, and again this is not a IETF issue, the credential delegation model would closely follow that for the numbers themselves and the delegation is to the TSP itself and not the numbers under their control.  If you are a Canadian carrier (there are about 700 in CA BTW 1600 or so in the US and that does include Vonage and some interesting names to follow ) and you have access to the Canadian NANP delegation you have a little chat with the CRTC (or whomever they designate) and pick you your private key by some trusted and secure methodology, distribute your public keys in one of the many well known models and start signing. If you muck things up there are some fine folks in Gatineau ( read Enforcement) who will have a chat with you. 

If folks want to do other things and want to build other kinds of credential infrastructures to support other stuff ..fine but that is for another time and place. Which is why I’m very very insistant that what ever SHAKEN/STIR looks like on the wire is fully extensible and that the IANA considerations are as least restrictive as possible. (!!!!!!!! NO RFC’s !!!!!!!) Yes some of us have some very specific use cases where different credentials might sign for different things associated with the Session.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 17 Oct 2015 16:20:47 -0400

> Martin is correct. The former. The originating provider signs based on the fact that they issued the number to the customer and presumably has the billing relationship.  The terminating provider va…

OK. So far so good.

Now, When my UAS gets this with the signature by foobar.com asserting 
that the number is valid, how do I know that foobar.com is responsible 
for the number? I never heard of foobar.com. It could be a valid 
provider somewhere. But it could also be entirely bogus.

Does this have *something* to do with the CA for the cert? Or does it 
rely on me having a whitelist of trusted signers of phone numbers?

Having specialized CA certs for this would help. Then I wouldn't need to 
know every phone provider. I could instead choose to trust any one that 
has a CA I trust for this purpose.

And it would be better yet if it was tied back to the formal delegation 
of phone numbers.

> There are going to have to be some profiles about how transit providers treat the data etc but I don’t want to wade into the weeds about that right now. I’d prefer to see a classic SIP trapezoidal…

If what you say is true, then transit providers should simply leave the 
cert untouched.

> The preference is certainly to let the UE decide, however that does not preclude the terminating carrier from acting directly on behalf of the consumer, if that is the consumer preference. That BTW…

IMO it is fine to allow opt-in network services, that validate according 
to some known policy and then block failing calls or otherwise treat 
them specially.

But I would certainly want to have the option of having them step out of 
the way and let my device handle it as I wish.

In this way it is a lot like spam filters.

> Speaking of which .. Paul do you have any thoughts on where we could put Validation data so the UE could display it?  I can’t get a reasonable answer from folks about that.

Here I think it would be good to "let a 1000 flowers bloom".
Phones come in so many different form factors now, and people use them 
in so many different ways, that I don't think there is one right answer.

Calls could be sorted into different trust levels, and that could be 
signaled via differing ring tones, or different colors when the call is 
displayed. Or with all sorts of different visual decorations on the 
screen. There are many more options on a smart phone than on a black phone.

I would like to be able to choose phone call filter apps for my phone, 
just like choose other apps.

That assumes that the UAS is doing the analysis of the cert itself. If 
some network service is doing it on my behalf, then if call is passed 
through to the phone it may be necessary to still convey nuances 
determined by the service. Given that I will know the service is in the 
path, this could be done with Alert-Info (using RFC7462), or callee-caps 
(RFC3840). Either way some new tags will likely need to be defined.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 17 Oct 2015 16:35:32 -0400

> I believe there is NO POSSIBLE WAY there is any support for signing each and every TN. Its a non starter. In the NANP that is about 800 M. Yes its doable. There is ample precedent. Goodness there i…

I get it that this is hard, and likely won't happen any time soon.
And once something that works passably well is in place it will be hard 
to change.

But at least it will be possible. Especially if the call can contain 
multiple signatures.

> The focus therefore is on signing a claim by the originating TSP that they trust this number ( they issued its to the consumer) and that they are responsible for the session. Its a much different v…

ISTM, at least for US providers, that will probably work reasonably well 
for individual numbers managed by the provider. (Not so much for Nigeria.)

I'm a little more concerned about calls originating from PBXs attached 
to those providers. Can we trust that the provider will really check 
that the number is one assigned to that PBX trunk? I have the impression 
that such checking is not universal today. For things to be ok I think 
the FCC will have to *insist* on this.

> IMHO, and again this is not a IETF issue, the credential delegation model would closely follow that for the numbers themselves and the delegation is to the TSP itself and not the numbers under thei…

If the CA chain is set up in such a way that I can simply keep a list of 
trusted CAs for this purpose (may be different than trusted CAs for web 
certs), then it seems tolerable. (Again, for the US. It is going to be 
hard to figure out what you can trust on international calls.)

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 17 Oct 2015 21:05:55 +0000

I hesitate to post about credentials in a thread called "encoding
considerations," but I would like to see if we can put the scope question
of the overall work here to rest and get back to the encoding details for
a little while.

The IETF is not going to prop up a credential system for STIR. It's not
going to tell you whose credentials you should trust or what needs to go
in them. If some particular SIP deployment would like to create a "Ring of
Defense" model for trust based on existing web certificates, then great,
that deployment can trust whatever certificates it would like, and that
will be compatible with the encoding over-the-wire we are defining here in
STIR. If it isn't, then we're doing it wrong.

Where the IETF does have a role in credentials is in specifying anything
new that credentials might need to do for our envisioned deployments. STIR
is chartered to produce work along those lines right now, and yes, it's
intended to address the sorts of use cases Paul is raising (which are
explicitly in STIR's threat model). But STIR producing that work item does
not obligate any deployment to use it, any more than any IETF RFC
obligates any deployment. When it comes to the signing, our job is to
design something that will work with credentials like Richard is
envisioning, and credentials like Paul is envisioning. I have heard still
other models for credentials under consideration, like one involving OCNs,
and then as Richard suggests there are further signer use cases that will
be orthogonal to any IETF work, I'm sure.

Different communities out there want to approach credentials in different
ways, but it's not clear to me there's any need for an IETF consensus to
try to "resolve" that, or even that it's a problem in terms of deployment.
I think it will turn out there need to be a few different approaches to
these credentials in the marketplace. Given that, our job here is to be
careful not to box our work in to a place where it serves only one of
those envisioned credentials and the full set our participants care about.
If we do that, we'll be getting the scope right, I think.

Jon Peterson
Neustar, Inc.

On 10/17/15, 1:35 PM, "Paul Kyzivat" <[email-masked]> wrote:

>> Disclaimer IMHO this is the way I see this if I had the magic wand. If
>>there is a emerging consensus on what STIR/SHAKEN is trying to do its
>>focus specifically on what goes on the wire and totally ignore any
>>discussion of how the credentails are created delegated etc. That
>>discussion is beyond wading in the weeds it would be rolling in the
>>poison ivy.
>>
>> I believe there is NO POSSIBLE WAY there is any support for signing
>>each and every TN. Its a non starter. In the NANP that is about 800 M.
>>Yes its doable. There is ample precedent. Goodness there is some form of
>>RPKI for all kinds of things out there from our credit cards to
>>television set top boxes, but its not going to happen. The industry will
>>not pay for it.  Just banish that idea from any concept of where we may
>>be going for the time being. Oh and no one wants the mess we saw in WEB
>>certs. Consequently you are looking at a highly defined delegation
>>model.  It should not be surprising that there is a severe allergy among
>>TSP¹s for large numbering databases.
>
>> The focus therefore is on signing a claim by the originating TSP that
>>they trust this number ( they issued its to the consumer) and that they
>>are responsible for the session. Its a much different view and a much
>>more restricted view of what the chain of trust should be than where I
>>think we started.
>
>> IMHO, and again this is not a IETF issue, the credential delegation
>>model would closely follow that for the numbers themselves and the
>>delegation is to the TSP itself and not the numbers under their control.
>> If you are a Canadian carrier (there are about 700 in CA BTW 1600 or so
>>in the US and that does include Vonage and some interesting names to
>>follow ) and you have access to the Canadian NANP delegation you have a
>>little chat with the CRTC (or whomever they designate) and pick you your
>>private key by some trusted and secure methodology, distribute your
>>public keys in one of the many well known models and start signing. If
>>you muck things up there are some fine folks in Gatineau ( read
>>Enforcement) who will have a chat with you.
>
>> If folks want to do other things and want to build other kinds of
>>credential infrastructures to support other stuff ..fine but that is for
>>another time and place. Which is why I¹m very very insistant that what
>>ever SHAKEN/STIR looks like on the wire is fully extensible and that the
>>IANA considerations are as least restrictive as possible. (!!!!!!!! NO
>>RFC¹s !!!!!!!) Yes some of us have some very specific use cases where
>>different credentials might sign for different things associated with
>>the Session.
>>
>>
>> On 10/17/15, 11:53 AM, "stir on behalf of Paul Kyzivat"
>><[email-masked] on behalf of [email-masked]> wrote:
>>
>>>> What you are saying is do you trust the North American Number Plan
>>>>delegation model.  Full disclosure I¹m a NANC member.
>>>
>>>> Second to you trust the authority by which the United States or
>>>>Canada or Jamaica delegates numbers to Licensed Carriers.
>>>
>>>> Frankly I don¹t care one way or the other.  The first order trust
>>>>model IMHO is do I trust ATT [my mobile provider] to give me accurate
>>>>information on who THEY trust.  I pay ATT by the way, quite happily
>>>>and Verizon for my trustworthy FIOS landline.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 10/16/15, 12:28 PM, "stir on behalf of Paul Kyzivat"
>>>><[email-masked] on behalf of [email-masked]> wrote:
>>>>
>>>>>>> Most of the abuse comes from pink enterprise, so where do we draw
>>>>>>>the
>>>>>>> line
>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 17 Oct 2015 18:27:59 -0400

Jon,

I agree with all you say.

We also have to ensure that deployment of one model won't preclude 
concurrent deployment of another.

I think that means allowing multiple signatures.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 17 Oct 2015 22:48:55 +0000

The next version will incorporate support for multiple signatures.

Jon Peterson
Neustar, Inc.

---

From: Richard Shockey <[email-masked]>
Date: Sat, 17 Oct 2015 21:41:21 -0400

Last but not least I’ll say the dreaded letters. TCP. If we weren’t there before we are certainly there now. 

I don’t see how we can avoid the inevitable recommendation.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Oct 2015 02:49:40 +0000

Just to make this more concrete: Are you describing the need, for example, to indicate how phone numbers, phone number ranges, carrier identities or OCNs are encoded in X.509 certificates? (I'm trying to be complete without implying that all of these are necessary or even IETF-relevant.) Recommendations on how to do stapling or OCSP and the other revocation-related issues we have discussed?

Henning

________________________________________
From: stir <[email-masked]> on behalf of Peterson, Jon <[email-masked]>
Sent: Saturday, October 17, 2015 5:05 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [stir] Encoding considerations

Jon Peterson
Neustar, Inc.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Oct 2015 03:18:46 +0000

Tangential, but curious: Any guess how many of the 1,600 or so US carriers actually delegate numbers to non-direct-customers to any significant degree? My sense is that the number of entities that serve the various SIP trunking providers (to the extent that they are not carriers themselves) and VoIP API providers (like Twilio) is very small. One starts with an L, the other a B, I believe. If these entities essentially operate as CAs for the numbers they assign to their customers, this seems to allow a carrier-driven mutual-trust models, without any centralized infrastructure, beyond maybe OCN-level certificates.

I'm just trying to explore various options along the complexity scale.

Henning

________________________________________
From: stir <[email-masked]> on behalf of Richard Shockey <[email-masked]>
Sent: Friday, October 16, 2015 8:26 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [stir] Encoding considerations

---

From: Richard Shockey <[email-masked]>
Date: Mon, 19 Oct 2015 09:51:25 -0400

I’d certainly guess no more than 10 or so. The vast majority of US ETC are rural ILEC’s.  Of the CLEC’s in the wholesale market 5 of those generating 90% or more of the traffic on delegated NANP numbers.  Its certainly significant and a major competitive force in certain markets..  Certain L+B and don’t forget X and B here in NOVA maybe G as well.  A COMPTEL question. :-)

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 19 Oct 2015 10:38:22 -0400

This may be true today (or may not, I don't know) but surely you're not thinking of baking such a limitation into the architecture.  So what's the point?

tim

---

From: Brian Rosen <[email-masked]>
Date: Mon, 19 Oct 2015 11:43:04 -0400

It's probably a handful, but more than 2 or 3.  I know of at least two more
beyond the two you are thinking of and I suspect there are a couple more
beyond that.

But you limited to "significant" and that is a problem, because there are
lots and lots of cases of smaller number resell where there are smaller
providers and someone is trying to build a national portfolio of numbers.
I also think you are assuming only one level of indirect, and  it can be 2
or 3, and probably is for the bad guys.

And then there are the odder cases ("authorized spoofing"), etc.

Brian

On Mon, Oct 19, 2015 at 9:51 AM, Richard Shockey <[email-masked]> wrote:

>
> I’d certainly guess no more than 10 or so. The vast majority of US ETC are
> rural ILEC’s.  Of the CLEC’s in the wholesale market 5 of those generating
> 90% or more of the traffic on delegated NANP numbers.  Its certainly
> significant and a major competitive force in certain markets..  Certain L+B
> and don’t forget X and B here in NOVA maybe G as well.  A COMPTEL question.
> :-)
>
>
>
> >Tangential, but curious: Any guess how many of the 1,600 or so US
> carriers actually delegate numbers to non-direct-customers to any
> significant degree? My sense is that the number of entities that serve the
> various SIP trunking providers (to the extent that they are not carriers
> themselves) and VoIP API providers (like Twilio) is very small. One starts
> with an L, the other a B, I believe. If these entities essentially operate
> as CAs for the numbers they assign to their customers, this seems to allow
> a carrier-driven mutual-trust models, without any centralized
> infrastructure, beyond maybe OCN-level certificates.
> >
> delegation model.  Full disclosure I’m a NANC member.
> >
> >Second to you trust the authority by which the United States or Canada or
> Jamaica delegates numbers to Licensed Carriers.
> >
> >Frankly I don’t care one way or the other.  The first order trust model
> IMHO is do I trust ATT [my mobile provider] to give me accurate information
> on who THEY trust.  I pay ATT by the way, quite happily and Verizon for my
> trustworthy FIOS landline.
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 19 Oct 2015 23:04:27 +0000

I meant primarily the former, yes, the means of indicating how various
bits of information useful to STIR verifiers might be associated with
X.509 certificates.

The issues around OCSP and stapling (which the room in Prague clearly
found overcomplicated) are in some respects generic to SIP: one could make
an argument that there should be a way to do OCSP stapling for SIP, say,
as a general optimization for overall TLS usage. I didn't mean to suggest
that STIR is chartered to do that work today, and perhaps that would
belong somewhere else if we were to pursue it.

We have however entertained a design where the means you associate the
"various bits of information" with X.509 certificates would be by
reference, from an interface specified in the cert itself. Once you start
going down that path, collapsing that into OCSP quickly becomes attractive
(and that in turn quickly leads you to stapling). That's how the mechanics
of OCSP ended up being the center of attention in that discussion.

But my point here was just to say that the approach to this in stir-certs
is not required for using RFC4474bis, and that the presence of these
certificate extensions should be optional: verifiers wouldn't need to use
them if they had other policies for trust, and auth services wouldn't be
compelled to acquire certificates supporting these proposed extensions. I
still do believe there are environments where those extensions would be
useful, and that it's worth pursuing this among other credential
strategies. 

Jon Peterson
Neustar, Inc.

On 10/18/15, 7:49 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>Just to make this more concrete: Are you describing the need, for
>example, to indicate how phone numbers, phone number ranges, carrier
>identities or OCNs are encoded in X.509 certificates? (I'm trying to be
>complete without implying that all of these are necessary or even
>IETF-relevant.) Recommendations on how to do stapling or OCSP and the
>other revocation-related issues we have discussed?
>
>Henning
>