Subject: Re: [stir] Questions about stir-certificates

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 19 Oct 2017 16:17:03 +0000

So as Sean Turner and I have been dotting the last I's and crossing the
last T's in auth48 *cough* for stir-certs we did want to make sure we
didn't neglect the things Martin talks about below, including pretty
fundamental questions about how we structure the TNAuthList and what
properties that structure can support, like delegation. Before slipping in
any last minute changes that might be surprising, we wanted to run this by
the group.

>The first question is whether this delegation makes any sense for
>service provider codes.  A service provider that signs a subordinate
>(such as an enterprise that operates a PBX) is hardly going to allow
>that subordinate to use their service provider code.  In light of
>that, it seems like subjectAltName is entirely appropriate place to
>put a service provider code.

I think the use case for SPC delegation is probably not the enterprise
case. A service bureau case makes more sense. We've also entertained cases
where a large carrier, say, might have authority over multiple SPCs in one
cert, but might want to delegate to some part of its own network a
certificate for just one of those SPCs. I've also dimly envisioned, if
this all takes off, use cases for selectively delegating applications
associated with an SPC for a particular service, probably to a service
bureau: like, Company A is doing the SMS for SPC 6166.

>I really don't think that it's a great design choice to bundle service
>provider codes with telephone numbers as TNAuthList does currently.
>It seems arbitrary.  I'll concede that this might seem partly an
>aesthetic objection, but the two are entirely different things with
>different rules.  Given that the authority to sign for a telephone
>number is most often a consequence of being a particular service
>provider (and having a valid code) rather than a direct and
>independent authority.

That last point is rather what persuaded me at least that the two are
coupled. I might even say that for verification purposes an SPC is just
shorthand for a set telephone numbers that the SPC covers.

>It's also unclear to me whether a certificate that includes AIA for
>telephone numbers also effectively constrains subordinates to comply
>with that set.

I hope it does, yes. We can make sure the document does say that.

> The document doesn't say.  On the assumption that it
>does, what happens when the resource identified in the AIA changes?

This is supposed to be a feature, believe it or not. If the resource
behind the AIA changes, the scope of the certificate changes. Part of
resolving the chain of authority in this model would be dereferencing any
such AIA's, yes, and making sure it still holds.

>There's a possibility that changes in the referenced resource could
>invalidate subordinates.  Doesn't this put AIA on the critical path?

That last point is probably better for Sean to speak to than me.

>The draft is unclear on how uniqueness is managed for service provider
>codes, or even if uniqueness is a requirement.  Is this a property of
>the certification path in that a trust anchor will be connected to a
>particular country prefix (or set thereof), or is there something more
>concrete?

The SPC as specified is admittedly a blank check we're writing at this
point, but I think that's about where we are in deployment. The early
adopters of this are North American carriers, there are already bodies who
allocate codes for such carriers. I don't think the IETF is the right
place to do that or to try to figure out how those identifiers should be
internationally allocated or what should happen when signed messages pass
into places where other sorts of SPCs might be in use. What's there now is
good enough to let people kick the tires and get some experience; it will
give national and international bodies enough leeway to define what they
want for it, and we can point to that later.

>How does one add `count` to a number containing "*" or "#"?

Don't get wrong: I won't pretend that every possible corner case involving
"*" and "#" has been given adequate consideration. They are there in the
syntax to cover a very small number of paranoid forward-compatibility use
cases of the "To" header field, mostly ones that in turn will use the
proposed "divert" extension. (For example, I'm dialing *69. That goes to a
server that is going to retarget the call to the last party who called me.
How should that retargeting server sign the "divert"?) I don't think count
will be practically relevant to those cases, which will would have to use
specialized certs anyway. I know we don't have all that fully specified,
but kind of like SPC, we're trying to leave a bit of wiggle room in the
syntax not to close doors on possibilities.

>Does the addition of `count` treat the `start` as an integer?
>What does a `count` of 0 mean?

I believe a count of '0' is disallowed.

>How do I express that all numbers in the +1 prefix are covered?

If it were up to me, probably, I wouldn't want the NANPA to publish a cert
with authority for +1, but instead, for the valid set of 10,000 blocks
(done with "count") that cover the allocated +1NPANXX's. But to your
bigger question...

> (The NANP is perhaps a bad example, try finding solid
>information on the numbering plan for +257).  Did the working group
>consider a number prefix in addition to the range, to allow for saying
>"+1..." as a single rule?

I went back and forth a lot between count versus prefix a couple years
ago, and honestly neither is perfect. Count can least theoretically do
things prefix can't; but doing some that are ugly to do with count can be
done very elegantly with prefix. Maybe the best thing for us to do is at
least leave the door open in the syntax to specify another way to do
number ranges? I think for our current purposes count is probably okay,
but I wouldn't object to adding wiggle room so we could specify other
options in the future.

>Why does JWTClaimName use IA5String rather than UTF8String?  If you
>need constraints on valid characters, prose is a better choice.  RFC
>7519 permits any Unicode string by not constraining the format of the
>name.

We discussed this quite a bit with the IESG in terms of consistency across
the three drafts, and I think what we have in the post-auth48 versions
should be okay. We just want to make sure that the claim names and the
syntax of the JWTClaimNames are the same - practically speaking I don't
think we're going to see things in the claim names outside the IA5 range,
so I don't think it's a problem as such.

Jon Peterson
Neustar, Inc.

---

From: Chris Wendt <[email-masked]>
Date: Thu, 19 Oct 2017 13:57:43 -0400

From IPNNI Task Force point of view we have two general use cases we are looking at covering for now.

First is the pure SHAKEN mechanism which includes only a SPC to identify the service provider that is attesting to the telephone identity.

Second one we are looking at, but not completely defined yet is a SPC + TN or SPC + TNblock certificate which can be used for delegation or proof of possession use cases where the service provider that manages the telephone number both identifies themselves with SPC and the telephone identities in the certificate.

So i would like to make sure we keep the ability to have SPC and TN or TNblock as an array in TNAuthList.

> On Oct 19, 2017, at 12:17 PM, Peterson, Jon <[email-masked]> wrote:
> 
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: David Bryan <[email-masked]>
Date: Thu, 19 Oct 2017 16:57:29 -0500

Forgive me if I am off base here
and this use case is covered elsewhere (and if so, a kindly pointer
appreciated). I've been following this group since the early days but not
as actively as I used to follow such IETF matters, so I certainly may have
missed something...

With respect to Jon's comment on delegation:

There are definitely large real deployments I am currently aware of of
where large VoIP or regional providers (call this A) no longer "own" their
numbers - they are owned by a large termination provider (call this B), are
leased, and PSTN connectivity is still provided by that termination
provider (B), who presumably "owns" the number from a STIR perspective.

In this case, however, these prividers (A) are large enough to peer
directly with carriers for delivery. Some (many) calls from the VoIP
provider's users' (A) bypass the termination provider (B, who is
authoritative for the number) entirely if they are delivered, say directly
from a caller on A' s network to a caller on a third network C with which A
has such a direct peering relationship.

Given B is the authoritative owner of the number, despite A being the
actual provider the customer's device authenticates with etc., I was under
the impression the SPC delegation was how this would be handled. Provider A
would sign using the delgated SPC from B after verifying the identity of
the caller, and deliver that to C.

If there is no other way to do this, there are a large number if VoIP
providers who will have a big issue. Just a further case, I think to argue
we definitely need SPC delegation.

The only other way I see is the national authority knowing who leases from
whom and issuing certs accordingly, but that seems ugly to say the least.

Is the case I mentioned one SPC delegation is intended to solve or is there
another mechanism in mind?

>From IPNNI Task Force point of view we have two general use cases we are
looking at covering for now.

First is the pure SHAKEN mechanism which includes only a SPC to identify
the service provider that is attesting to the telephone identity.

Second one we are looking at, but not completely defined yet is a SPC + TN
or SPC + TNblock certificate which can be used for delegation or proof of
possession use cases where the service provider that manages the telephone
number both identifies themselves with SPC and the telephone identities in
the certificate.

So i would like to make sure we keep the ability to have SPC and TN or
TNblock as an array in TNAuthList.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 20 Oct 2017 11:28:05 +1100

Thanks for the response Jon,

It took me a little while to revive state for this, so I hope that I'm
at least consistent with before...

> bureau: like, Company A is doing the SMS for SPC 6166.

That makes me more confident that you have the right model, as least
with respect to subjectAltName.  I was concerned that a SPC was an
identity of the entity doing the signing, but it seems like it is
instead a proxy for a number range.  Cast in those terms, the model
you have is OK.  But it really isn't that clear from the document that
this is the model.  For a relative outsider, it might be useful to say
that this is an assumption in your model.

> I hope it does, yes. We can make sure the document does say that.

I trust that you will do that :)

> That last point is probably better for Sean to speak to than me.

I just checked and RFC 5280 mandates AIA as a non-critical extension.
I think that's a bit of a deal-breaker.

>From my (limited) experience with out-of-band information in the web
PKI, this isn't that great a solution.  Every time we use some
out-of-band mechanism, it turns out to be brittle.  When something is
brittle, the immediate reaction is to make it non-blocking.  That was
the case with CRLs and OCSP.  That's why we have OCSP stapling.

This might be a different story.  Maybe the sheer quantity of numbers
will lead to the right incentives and people will insist on retrieving
up-to-date information from these resources.  But nothing in the
mechanism will require it unless this document does.

If you need to use AIA, then you need to do something about it being
non-critical.  I think that a strategic "MUST" might be all you need.
"MUST support AIA, retrieve an updated AIA, and use the information
provided therein"

For that to work, you need an MTI retrieval mechanism and format.  I
assume that this is just a DER-encoded TNAuthList.  You probably want
to write that down.  And then someone will end up asking whether you
have a media type for it.

And then there is the privacy story with these sorts of things.  Big
lists of AIA are probably OK (K-anonymity with large K), but I can
imagine the CA being able to use this as a way to track calls.  Not
serious here because lists are generally long, but it was a problem
with CRLs and OCSP on the web, so it's worth a brief mention at least.

> want for it, and we can point to that later.

I think that you need more than that.  At least acknowledge that the
service provider code is defined within a certain scope and that
someone consuming the code needs to be aware of where the code is
coming from.

> syntax not to close doors on possibilities.

Please define something.  Either say that addition of numbers that
contain these digits is invalid, or that the count is added to any
numeric digits to the right of these digits.  If this turns out to be
a bad idea, then see my answer regarding prefixes.

>>Does the addition of `count` treat the `start` as an integer?

You missed this question.  I think that it's important.  It's the
little things that can trip up implementations.

"123" + 10 is probably "123", "124", "125", ..., "132", is that correct?
What about "123" + 1000?  It might pay to say that overflow into more
digits isn't permitted, especially if you consider the case of
"123*69" + 32.  Is this up to "154*69" or "123*100" or "124*00" or
something else?  It might be easier to say that it's invalid.

> I believe a count of '0' is disallowed.

Indeed it is.

> but I wouldn't object to adding wiggle room so we could specify other

I would make sure that there is an extension point.  My ASN.1 is
rusty, but I think that adding ... to TNEntry would be enough for
that.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 20 Oct 2017 16:15:27 +0000

Martin,

I want to offer my compliments for your comments attempting to help improve the standard and make STIR more robust.

You also observed, "PKI, this isn't that great a solution.  Every time we use some out-of-band mechanism, it turns out to be brittle.  When something is brittle, the immediate reaction is to make it non-blocking."

The protocol and policy challenges of STIR and PKI are contributing factors to why I believe STIR/SHAKEN by itself will probably always be non-blocking.

Even if we constrain our consideration to the Service Provider use case, there are many thousands of Service Providers and hundreds of government authorities and so SHAKEN/STIR may only ever be fragile and non-blocking in perpetuity.  If we consider non-network-centric end-user application and per-Telephone Number use cases, I think the already considerable policy, protocol, and operational challenges become even more significant.

Furthermore, STIR/SHAKEN is a mechanism for conveying relative trustworthiness of the calling telephone number, and AFAIK consumer preference studies of VoIP-originated SPAM have so far been anecdotal and unscientific.  It is not yet clear whether a positive indication of trust such as a green check mark will be preferred (or acceptable), as compared to a negative indication of trust such as a red circle with a diagonal red slash across it on a white background.

The majority of telephony consumers may prefer to only be alerted to suspicious call attempts.   SHAKEN's "Full" attestation provides the highest level of trust with regard to the originating telephone number not having been spoofed, but consumers may not want to be told, "here's another most likely benign call attempt".

"Partial" and "Gateway" attestations as indications of relative untrustworthiness of the calling number may be usable as filters for secret-sauce analytics and/or post-processing forensic investigation.  IMHO they are not suited for at-a-glance indications of unwanted calling attempts to subscribers.   And, I assume no user, enterprise, or originating or transit service provider will volunteer "Fraudulent" or " SPAM" attestations although they would be undeniably more usable for an at-a-glance decision about whether to accept a call.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]]
Sent: Thursday, October 19, 2017 7:28 PM
To: Peterson, Jon <[email-masked]>
Cc: [email-masked]; Sean Turner <[email-masked]>
Subject: Re: [stir] Questions about stir-certificates

It took me a little while to revive state for this, so I hope that I'm at least consistent with before...

On Fri, Oct 20, 2017 at 3:17 AM, Peterson, Jon <[email-masked]> wrote:
> case. A service bureau case makes more sense. We've also entertained
> cases where a large carrier, say, might have authority over multiple
> SPCs in one cert, but might want to delegate to some part of its own
> network a certificate for just one of those SPCs. I've also dimly
> envisioned, if this all takes off, use cases for selectively
> delegating applications associated with an SPC for a particular
> service, probably to a service

That makes me more confident that you have the right model, as least with respect to subjectAltName.  I was concerned that a SPC was an identity of the entity doing the signing, but it seems like it is instead a proxy for a number range.  Cast in those terms, the model you have is OK.  But it really isn't that clear from the document that this is the model.  For a relative outsider, it might be useful to say that this is an assumption in your model.

>> The document doesn't say.  On the assumption that it does, what
>>happens when the resource identified in the AIA changes?
>
> resolving the chain of authority in this model would be dereferencing
> any such AIA's, yes, and making sure it still holds.
>

>From my (limited) experience with out-of-band information in the web
PKI, this isn't that great a solution.  Every time we use some out-of-band mechanism, it turns out to be brittle.  When something is brittle, the immediate reaction is to make it non-blocking.  That was the case with CRLs and OCSP.  That's why we have OCSP stapling.

This might be a different story.  Maybe the sheer quantity of numbers will lead to the right incentives and people will insist on retrieving up-to-date information from these resources.  But nothing in the mechanism will require it unless this document does.

If you need to use AIA, then you need to do something about it being non-critical.  I think that a strategic "MUST" might be all you need.
"MUST support AIA, retrieve an updated AIA, and use the information provided therein"

For that to work, you need an MTI retrieval mechanism and format.  I assume that this is just a DER-encoded TNAuthList.  You probably want to write that down.  And then someone will end up asking whether you have a media type for it.

And then there is the privacy story with these sorts of things.  Big lists of AIA are probably OK (K-anonymity with large K), but I can imagine the CA being able to use this as a way to track calls.  Not serious here because lists are generally long, but it was a problem with CRLs and OCSP on the web, so it's worth a brief mention at least.

> adopters of this are North American carriers, there are already bodies
> who allocate codes for such carriers. I don't think the IETF is the
> right place to do that or to try to figure out how those identifiers
> should be internationally allocated or what should happen when signed
> messages pass into places where other sorts of SPCs might be in use.
> What's there now is good enough to let people kick the tires and get
> some experience; it will give national and international bodies enough
> leeway to define what they want for it, and we can point to that later.

I think that you need more than that.  At least acknowledge that the service provider code is defined within a certain scope and that someone consuming the code needs to be aware of where the code is coming from.

> Don't get wrong: I won't pretend that every possible corner case
> involving "*" and "#" has been given adequate consideration. They are
> there in the syntax to cover a very small number of paranoid
> forward-compatibility use cases of the "To" header field, mostly ones
> that in turn will use the proposed "divert" extension. (For example,
> I'm dialing *69. That goes to a server that is going to retarget the call to the last party who called me.
> How should that retargeting server sign the "divert"?) I don't think
> count will be practically relevant to those cases, which will would
> have to use specialized certs anyway. I know we don't have all that
> fully specified, but kind of like SPC, we're trying to leave a bit of
> wiggle room in the syntax not to close doors on possibilities.

Please define something.  Either say that addition of numbers that contain these digits is invalid, or that the count is added to any numeric digits to the right of these digits.  If this turns out to be a bad idea, then see my answer regarding prefixes.

>>Does the addition of `count` treat the `start` as an integer?

You missed this question.  I think that it's important.  It's the little things that can trip up implementations.

"123" + 10 is probably "123", "124", "125", ..., "132", is that correct?
What about "123" + 1000?  It might pay to say that overflow into more digits isn't permitted, especially if you consider the case of "123*69" + 32.  Is this up to "154*69" or "123*100" or "124*00" or something else?  It might be easier to say that it's invalid.

Indeed it is.

> If it were up to me, probably, I wouldn't want the NANPA to publish a
> cert with authority for +1, but instead, for the valid set of 10,000
> blocks (done with "count") that cover the allocated +1NPANXX's. But to
> your bigger question...
>
>> (The NANP is perhaps a bad example, try finding solid information on
>>the numbering plan for +257).  Did the working group consider a number
>>prefix in addition to the range, to allow for saying "+1..." as a
>>single rule?
>
> things prefix can't; but doing some that are ugly to do with count can
> be done very elegantly with prefix. Maybe the best thing for us to do
> is at least leave the door open in the syntax to specify another way
> to do number ranges? I think for our current purposes count is
> probably okay, but I wouldn't object to adding wiggle room so we could
> specify other options in the future.

I would make sure that there is an extension point.  My ASN.1 is rusty, but I think that adding ... to TNEntry would be enough for that.

________________________________

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: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 20 Oct 2017 16:25:48 +0000

David,

Chris Wendt proposed a Telephone Number Proof-of-Possession (TN PoP) architecture based on STIR/SHAKEN which I think can address your use case.  I also think your proposal of SPC delegation can work but would be as a commercial agreement and out-of-scope as regards protocol (but not policy?) work.  (It would also be my preference if I was operating a subordinate SP.)

From: David Bryan [mailto:[email-masked]]
Sent: Thursday, October 19, 2017 4:57 PM
To: Chris Wendt <[email-masked]>
Cc: Sean Turner <[email-masked]>; [email-masked]; Martin Thomson <[email-masked]>; Peterson, Jon <[email-masked]>
Subject: Re: [stir] Questions about stir-certificates

Forgive me if I am off base here
and this use case is covered elsewhere (and if so, a kindly pointer appreciated). I've been following this group since the early days but not as actively as I used to follow such IETF matters, so I certainly may have missed something...

There are definitely large real deployments I am currently aware of of where large VoIP or regional providers (call this A) no longer "own" their numbers - they are owned by a large termination provider (call this B), are leased, and PSTN connectivity is still provided by that termination provider (B), who presumably "owns" the number from a STIR perspective.

In this case, however, these prividers (A) are large enough to peer directly with carriers for delivery. Some (many) calls from the VoIP provider's users' (A) bypass the termination provider (B, who is authoritative for the number) entirely if they are delivered, say directly from a caller on A' s network to a caller on a third network C with which A has such a direct peering relationship.

Given B is the authoritative owner of the number, despite A being the actual provider the customer's device authenticates with etc., I was under the impression the SPC delegation was how this would be handled. Provider A would sign using the delgated SPC from B after verifying the identity of the caller, and deliver that to C.

If there is no other way to do this, there are a large number if VoIP providers who will have a big issue. Just a further case, I think to argue we definitely need SPC delegation.

The only other way I see is the national authority knowing who leases from whom and issuing certs accordingly, but that seems ugly to say the least.

Is the case I mentioned one SPC delegation is intended to solve or is there another mechanism in mind?

On Oct 19, 2017 12:57 PM, "Chris Wendt" <[email-masked]<mailto:[email-masked]>> wrote:
From IPNNI Task Force point of view we have two general use cases we are looking at covering for now.

> On Oct 19, 2017, at 12:17 PM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> [email-masked]<mailto:[email-masked]>

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

---

From: David Bryan <[email-masked]>
Date: Fri, 20 Oct 2017 12:33:01 -0500

Thanks, Pierce, and thanks for the tip on TN-PoP. Just googled it and found
at least a few ATIS slides floating around, and I'll go take a look.

My concern protocol vs. policy side was the (somewhat) side comment in
Jon's email, replying to Martin's original comment about the enterprise
case not being realistic. I wanted to advocate that support in the
structure/draft for delegation remains, for cases like I described where
you are talking about one carrier "owning" but leasing very large (many
thousands) of numbers to another carrier.

The trust relationship and mechanics are different from the enterprise case
I think Martin is thinking about, and I think we want SPC delegation there,
so just wanted to make sure it stays alive within the protocol. Agree the
details are mostly policy, just so long as protocol primitives are there to
allow it.

It may definitely be the case there is a (much) better way to handle the
sort of use case I describe than delegation. I'll look at TN-PoP, although
from a quick peek I'm talking about a scenario with hundreds of thousands
of users vs. PBX users, but may be a fit -- I need to go see what I can
find on Chris' work here (so far just a few slides -- but now I know where
to dig) and read up/offer to help!

On Fri, Oct 20, 2017 at 11:25 AM, Gorman, Pierce A [CTO] <
[email-masked]> wrote:

> David,
>
>
>
> Chris Wendt proposed a Telephone Number Proof-of-Possession (TN PoP)
> architecture based on STIR/SHAKEN which I think can address your use case.
> I also think your proposal of SPC delegation can work but would be as a
> commercial agreement and out-of-scope as regards protocol (but not policy?)
> work.  (It would also be my preference if I was operating a subordinate SP.)
>
>
>
>
>
> *From:* David Bryan [mailto:[email-masked]]
> *Sent:* Thursday, October 19, 2017 4:57 PM
> *To:* Chris Wendt <[email-masked]>
> *Cc:* Sean Turner <[email-masked]>; [email-masked]; Martin Thomson <
> [email-masked]>; Peterson, Jon <[email-masked]>
> *Subject:* Re: [stir] Questions about stir-certificates
>
>
>
> cases
> who
> involving
> count
> cert
> ------------------------------
>
> 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, 20 Oct 2017 13:45:30 -0400

> "Partial" and "Gateway" attestations as indications of relative untrustworthiness of the calling number may be usable as filters for secret-sauce analytics and/or post-processing forensic investiga…

Speaking strictly as a telephony consumer: I see value in *both* the 
positive and negative indicators. I am inclined to use the negative one 
when deciding whether to answer the call at all, and the positive one 
for whether to trust the call for sensitive matters, such as with 
government agencies and financial institutions.

This can be coupled with per-number policy at my own end (in my address 
book) by remembering which numbers have previously received full 
attestation. That can raise the bar on future calls from the same number.

	Thanks,
	Paul

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 20 Oct 2017 19:49:44 +0000

Government agencies and financial institutions would not be given "Full" attestation under ordinary circumstances and so their calls would not get the green check (although Chris' TN PoP could help change that).

Remembering the originating telephone number of government agencies and financial institutions may be difficult for some consumers (and probably not a source of many calls for the average Joe in any case).

Challenges with the veracity of calling name information remain even in the presence of STIR/SHAKEN.  It's an area of opportunity for further study and development.

Pierce

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, October 20, 2017 12:46 PM
To: [email-masked]
Subject: Re: [stir] Questions about stir-certificates

> "Partial" and "Gateway" attestations as indications of relative untrustworthiness of the calling number may be usable as filters for secret-sauce analytics and/or post-processing forensic investiga…

Speaking strictly as a telephony consumer: I see value in *both* the positive and negative indicators. I am inclined to use the negative one when deciding whether to answer the call at all, and the positive one for whether to trust the call for sensitive matters, such as with government agencies and financial institutions.

This can be coupled with per-number policy at my own end (in my address
book) by remembering which numbers have previously received full attestation. That can raise the bar on future calls from the same number.

	Thanks,
	Paul

>> I think the use case for SPC delegation is probably not the 
>> enterprise case. A service bureau case makes more sense. We've also 
>> entertained cases where a large carrier, say, might have authority 
>> over multiple SPCs in one cert, but might want to delegate to some 
>> part of its own network a certificate for just one of those SPCs. 
>> I've also dimly envisioned, if this all takes off, use cases for 
>> selectively delegating applications associated with an SPC for a 
>> particular service, probably to a service
>>> The draft is unclear on how uniqueness is managed for service 
>>> provider codes, or even if uniqueness is a requirement.  Is this a 
>>> property of the certification path in that a trust anchor will be 
>>> connected to a particular country prefix (or set thereof), or is 
>>> there something more concrete?
>>
>> The SPC as specified is admittedly a blank check we're writing at 
>> this point, but I think that's about where we are in deployment. The 
>> early adopters of this are North American carriers, there are already 
>> bodies who allocate codes for such carriers. I don't think the IETF 
>> is the right place to do that or to try to figure out how those 
>> identifiers should be internationally allocated or what should happen 
>> when signed messages pass into places where other sorts of SPCs might be in use.
>> some experience; it will give national and international bodies 
>> enough leeway to define what they want for it, and we can point to that later.
> 
>> blocks (done with "count") that cover the allocated +1NPANXX's. But 
>> to your bigger question...
>>
>>> the numbering plan for +257).  Did the working group consider a 
>>> number prefix in addition to the range, to allow for saying "+1..." 
>>> as a single rule?
>>
>> I went back and forth a lot between count versus prefix a couple 
>> years ago, and honestly neither is perfect. Count can least 
>> theoretically do things prefix can't; but doing some that are ugly to 
>> do with count can be done very elegantly with prefix. Maybe the best 
>> thing for us to do is at least leave the door open in the syntax to 
>> specify another way to do number ranges? I think for our current 
>> purposes count is probably okay, but I wouldn't object to adding 
>> wiggle room so we could specify other options in the future.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Oct 2017 16:18:58 -0400

> Government agencies and financial institutions would not be given "Full" attestation under ordinary circumstances and so their calls would not get the green check (although Chris' TN PoP could help…

That would be sad. Isn't that the goal of all this?

> Remembering the originating telephone number of government agencies and financial institutions may be difficult for some consumers (and probably not a source of many calls for the average Joe in an…

When I get a call from somebody I expect to hear from again I am 
inclined to put them in my address book directly from the call history. 
If the call history remembered the level of attestation of the call then 
it could retain that in the address book as well, and update it on 
future calls if the attestation for the same caller gets stronger. 
(Perhaps remember all the different levels that have been observed for 
the number.)

This doesn't require anything from the end user that he isn't already doing.

> Challenges with the veracity of calling name information remain even in the presence of STIR/SHAKEN.  It's an area of opportunity for further study and development.

I understand that the name is a whole different thing.

	Thanks,
	Paul

---

From: Richard Shockey <[email-masked]>
Date: Fri, 20 Oct 2017 17:49:31 -0400

> "Partial" and "Gateway" attestations as indications of relative untrustworthiness of the calling number may be usable as filters for secret-sauce analytics and/or post-processing forensic inves…

RS> You have to remember there are multiple use cases here.  Don’t make the mistake that the Call Validation Display data is strictly directed at the consumer.  There is a strong business case advanced call analytics for inbound call centers especially for financial services utilities here. 

RS> Agreed but that is ultimately a high policy issue the regulators are looking at now. 

https://ecfsapi.fcc.gov/file/1013653727266/Shockey%20Consulting%2017-97%20Call%20Authentication%20Trust%20Anchor%20exparte.pdf

    
    	Thanks,
    	Paul

---

From: Chris Wendt <[email-masked]>
Date: Mon, 23 Oct 2017 10:35:24 -0400

Hi Paul,

The key thing is that on the telephone network, there will be a transition period between 10% calls being signed to 50% of calls being signed to 90% of calls being signed and i think the indicators will need to evolve through those periods of time.  If you start with both positive and negative indicators based entirely on STIR that may imply something different in all of those transitional periods, so the simple start is to have mostly positive indicators if STIR is your only tool.  The indications will also likely be mixed with call spam analytics tools and their determinations, so I think in most of the industry discussions we want to work collaboratively between service providers and Call Analytics apps and consumers to see how things evolve for the best display framework.
The key thing is taking both the STIR signatures, analytics, and other tools together to build a robust way of determining both correct identity and intent of the calls being received.

-Chris

> On Oct 20, 2017, at 4:18 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> When I get a call from somebody I expect to hear from again I am inclined to put them in my address book directly from the call history. If the call history remembered the level of attestation of the call then it could retain that in the address book as well, and update it on future calls if the attestation for the same caller gets stronger. (Perhaps remember all the different levels that have been observed for the number.)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Oct 2017 12:04:38 -0400

Chris,

On 10/23/17 10:35 AM, Chris Wendt wrote:
> Hi Paul,
> 
> The key thing is that on the telephone network, there will be a transition period between 10% calls being signed to 50% of calls being signed to 90% of calls being signed

Yes.

> and i think the indicators will need to evolve through those periods of time.  

Do you mean the indicators that are displayed to the end user? Or do you 
mean the indicators that are conveyed in the signaling to the UAC?

Hopefully you are talking about the indicators that are being displayed.

> If you start with both positive and negative indicators based entirely on STIR that may imply something different in all of those transitional periods, so the simple start is to have mostly positive indicators if STIR is your only tool.  The indications will also likely be mixed with call spam analytics tools and their determinations, so I think in most of the industry discussions we want to work collaboratively between service providers and Call Analytics apps and consumers to see how things evolve for the best display framework.

IMO there can be many ways of doing these indications, and there is no 
real reason to be overyly restrictive about these. For the sake of 
consistency it may be worthwhile to come up with a dictionary of 
predefined iconography.

For suitably smart devices (e.g. mobile phones) I would hope that 
various apps and configuration options for those apps can provide the UI 
to users. Then app providers can compete on who does it better and users 
can choose. And these can evolve over time as the uptake on the signing 
increases. Maybe this is what you mean by Call Analytics apps.

It would be bad if all of this gets locked up in the FCC regulatory regime.

	Thanks,
	Paul

---

From: Richard Shockey <[email-masked]>
Date: Mon, 23 Oct 2017 12:28:26 -0400

RS> Paul I don’t think this is going to get locked up in a FCC/FTC OFCOM CRTC like regime but the regulators do have legitimate concerns on consistency. The regulators have actually been quite helpful here. They are willing to eventually help with consumer education if the framework for display options is simple, and I also believe there are excellent opportunities for service providers to add value.   Sometimes choice is bad and confusing the consumer with different forms of UX could cause its own problems.  Its still early.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 23 Oct 2017 18:37:18 +0000

Paul,

There's a letter from Janice Kopec at the Federal Trade Commission (filed as ATIS document "IPNNI-2017-00106R000.pdf") to Tom Goode, General Counsel for ATIS, where the FTC staff provided feedback and guidelines for developing SHAKEN/STIR Caller Validation Display that may provide helpful context around some of the remarks in the discussion.

A few of the FTC comments were:

* Design fallbacks (e.g., when technology fails or is not available for some users, how does the system react and what is communicated)

* Warnings need to be accurate , or else users will get habituated and ignore them

* What do full, partial, and gateway attestation translate to in plain language?

* What are carriers able to vouch for with those data points, and with what level of confidence?  Need consistent interpretation of levels of validation.

* How will carriers handle calls at each level of attestation, when calls fail attestation, and when attestation is absent?

*Clearly differentiate between information about the caller ID and information about the content of the call.  Just because a call is authenticated doesn't mean the content of the call can be trusted.

Remember that SHAKEN attestion doesn't provide anything with respect to call content and intent.  And, robocalling and spoofed caller ID are not illegal.  They're used by government agencies and charities too, not just bad actors.

Call processing systems have a large variety of information presented to them from protocols designed by committees and interpeted by commercial programmers operating under challenging timelines and with limited resources.  Creating a stable consistent experience several millions of times a day will not be a quick achievement.  IMHO, application of SHAKEN/STIR will be permissive in the early stages, and really needs to be married to outboard analytics which look at things like network calling patterns and permit/deny lists in order to be able to render more reliable judgements to the network (or a client application) with respect to relative trustworthy-ness of a call attempt.

---

From: Richard Shockey <[email-masked]>
Date: Mon, 23 Oct 2017 14:48:52 -0400

+1 .. I sat in those meetings with the FTC as did Martin Dolly and Chris Wendt. This is my point that the regulators do have ligitmate concerns but are willing to be helpful without being prescriptive.  As a additional note I also recently met with the FCC folks including brother Eric Burger and they had similar concerns.  

That said we will may see some further regulatory action in the 17-97 FCC docket within 90 days or so.  Right now the industry is digesting the implications of National Number Portability which is REALLY going to have a profound effect on US call routing. 

On 10/23/17, 2:37 PM, "stir on behalf of Gorman, Pierce A [CTO]" <[email-masked] on behalf of [email-masked]> wrote:

    Paul,

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Oct 2017 16:46:19 -0400

> +1 .. I sat in those meetings with the FTC as did Martin Dolly and Chris Wendt. This is my point that the regulators do have ligitmate concerns but are willing to be helpful without being prescript…

OK. That sounds promising. I look forward to seeing how it develops.

	Thanks,
	Paul

---

From: Sean Turner <[email-masked]>
Date: Mon, 30 Oct 2017 21:37:11 -0400

Some responses inline.  Note that there are some proposals for new text and a couple of questions.

spt

> On Oct 19, 2017, at 20:28, Martin Thomson <[email-masked]> wrote:
> 

Since s10.1 points to s9 where the constraints are I would assume that implementers would know to apply the constraints the same way.  But, if I put on my “where’s that explicit statement" hat on - it’s not there.  So, I get your point.  How about we add the following to the end of the 2nd paragraph in s10.1:

   As with the certificate extension defined in Section 9, a URI dereferenced
   from an end entity certificate will indicate the TNs which the caller has
   been authorized; a URI  dereferenced from a CA certificate will limit the
   the set of TNs for certification paths that include this certificate.

I think that this also addresses mixing the two ways to constrain the caller, i.e., the CA had an AIA and the EE had the certificate extension.  BUT, I’m not sure that we should really do that because it could get complicated.  Maybe whatever way the CA is constrained, i.e., with the TN Authorization List extension or the AIA, is the way the EE MUST be constrained?

Thoughts?

> provided therein”

When I read your comment and when I talked about Jon, I didn’t equate on the critical path with the extension being critical.  We’re certainly not suggesting that AIA be made critical.  I think the outline of certificate usage in s4 points to s10.1 for additional requirements, but I can see how it might not be that clear.  Maybe we add the following to the end of the 2nd paragraph in s10.1 after the new text above:

   Verifiers MUST support the AIA extension.

> have a media type for it.

I think the format is already there in s10.1:

   The document returned by dereferencing that
   URI will contain the complete TN Authorization List (see Section 9)
   for the certificate.

And ugh media types … sure how about this:

   Type name: application

   Subtype name: tnauthlist+der

   Required parameters: None.

   Optional parameters: None.

   Encoding considerations: Binary.

   Security considerations:  See Section 12 of this specification.

   Interoperability considerations:

      The TN Authorization List inside this media type MUST be DER-encoded
      TNAuthorizationList.

   Published specification: This specification.

   Applications that use this media type:

      Applications that support [draft-ietf-stir-certificates] certificates.

   Fragment identifier considerations: N/A

   Additional information:

      Magic number(s): None
      File extension(s): None
      Macintosh File Type Code(s): None

   Person & email address to contact for further information:

      Sean Turner <[email-masked]>

   Intended usage: COMMON

   Restrictions on usage: none

   Author: Sean Turner <[email-masked]>

   Change controller: The IESG <[email-masked]>

Notes:

1. I don’t have to be the POC.
2. +der is there in case in some later time you want to say use +json
3. when we’re happy with this I’ll get the ball rolling to get the review started

> with CRLs and OCSP on the web, so it's worth a brief mention at least.

I think this is addressed in s10.

> someone consuming the code needs to be aware of where the code is

I’m hoping that the example we provided for N.A. with OCNs and SPIDs is providing the scope without being exhaustive where the list might come from.

> something else?  It might be easier to say that it's invalid.

A couple of things:

1. The count text has not been updated since we added “*" and “#” and I’m thinking that count was only supposed to apply to the parts of the TN that are not related to the “*" and “#”.

2. To answer your question: yes it’s the number plus the next 9 and overflows should be prohibited.

How about the following for #2 in s9:

 2.  Telephone numbers can be listed in a range (in the
      TelephoneNumberRange format), which consists of a starting
       telephone number and then an integer count of numbers within the
       range, where the valid boundaries of ranges may vary according to
       national policies.  count has the following constraints: overflow into
       more digits isn’t permitted, e.g., “123” + 100 is not allowed; count
       only applies to the telephone number and not to digits associated
       with “*” or “#”.

In the above I am not sure the words a quite right.

> rusty, but I think that adding ... to TNEntry would be enough for

Extensibility is easy enough:

TNEntry ::= CHOICE {
      spc   [0] ServiceProviderCode,
      range [1] TelephoneNumberRange,
      one   [2] TelephoneNumber,
     ...
      }

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Oct 2017 14:51:23 +1100

> I think that this also addresses mixing the two ways to constrain the caller, i.e., the CA had an AIA and the EE had the certificate extension.  BUT, I’m not sure that we should really do that beca…

Having the two match might not make sense if you consider the
possibility for an operator to run their own subordinate CA.  I think
that it would be reasonable for that CA to be constrained to the set
of numbers that operator has, but if the EE cert has to match exactly
it would prevent the operator from creating more narrowly constrained
EE certs.

>    Verifiers MUST support the AIA extension.

I think that you are looking for MUST use.

>    URI will contain the complete TN Authorization List (see Section 9)

That's the format, mostly, though it probably needs to say that it's
the actual DER encoding of that structure so that it's crisp.  The
retrieval mechanism is needed too.  I assume that HTTPS will work,
with all the usual things regarding server authentication and so forth
(2818 and all that).  RFC 5280 talks about using LDAP and other things
that I don't think you want.

> 2. +der is there in case in some later time you want to say use +json

+anything is a rathole you don't want to dig for yourself.  If you
need a JSON variant, then I'm sure that it would be easy to define
application/tnauthlist+json, but a bare name will avoid all sorts of
headaches.  I just recently went through the trouble involved with RFC
8091 and have no wish to inflict that on others.

> I think this is addressed in s10.

Not really.  I assume that you refer to:

   Delivering the entire list of telephone numbers associated with a
   particular certificate will divulge to STIR verifiers information
   about telephone numbers other than the one associated with the
   particular call that the verifier is checking.

Which says that a verifier will learn that a particular EE or CA can
also speak for a particular set of telephone numbers.  The risk here
is that with a sufficiently small set of numbers in the AIA document,
the CA (or whoever hosts the AIA doc) learns that a particular
verifier is terminating a call from one of those numbers.  Caching
isn't an effective defense if you care about that.  (This is one
reason that stapling is a big deal, but OCSP responses are signed and
can therefore be stapled, whereas you are not offering any way to
avoid this lookup being necessary.)

You could avoid the problem by having the AIA be a reference to a
larger certificate (that is, one that contains the complete TNAuthList
and no AIA), which would allow you to attach a signature to the AIA.
Then it becomes possible to avoid the lookup at the cost of a larger
certificate that has to be updated more often.

> In the above I am not sure the words a quite right.

Does "not to digits associated with “*” or “#”" mean?

a. a count can't be used with a number that includes either "*" or "#"
b. a count applies to the numerical value preceding any "*" or "#"
b. a count applies to the numerical value after the final "*" or "#",
if any are present
c. something else

(a) seems right to me.  I can see a case for describing a range of
extensions, but it probably makes sense to disavow that use case and
have the bare number asserted on its own.  Thus, I would say:

> national policies.  A count is added to the numeric value of the telephone number.  A count cannot cause the telephone number to increase in length, thus "123" + 100 is not valid.  A number that includes "*" or "#" cannot be included in TelephoneNumberRange.

That suggests a different grammar might be useful, so maybe you really
do mean b.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Oct 2017 10:44:45 -0400

> That suggests a different grammar might be useful, so maybe you really

+1 to a different grammar, restricting the start for a range to just a 
numeric string, or whatever is intended. And then an explicit generation 
rule for the additional numbers in the range.

What is supposed to be done for variable length numbering schemes?

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Nov 2017 15:06:52 +1100

> What is supposed to be done for variable length numbering schemes?

I figure that you would simply have multiple ranges, one for each
possible length.  That might mean 15 ranges in the worst case, but
it's probably better than any alternative I can think of.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 1 Nov 2017 00:40:22 -0400

> it's probably better than any alternative I can think of.

That sounds unpleasant.

How about describing the range using a RE, or something similar to an RE 
restricted to digits?

	Thanks,
	Paul