Subject: [stir] On OCSP, TNs, and Privacy

From: Richard Barnes <[email-masked]>
Date: Mon, 27 Jul 2015 18:13:43 -0400

After the STIR meeting in Prague, Henning and I spent a few minutes
talking through options for revocation checking and certificate
scoping, and I think we have a better idea of what the optimal
solution looks like.  Some notes are below, and some slides with
pictures attached.

tl;dr: We should:
* Keep TNs in certificates and not bother with any OCSP extensions
* Require Identity-Info to include OCSP responses for all certs in the chain

# Background: Revocation in the web PKI

In an HTTPS transaction, the HTTPS server provides the client with a
certificate, and it can optionally include an OCSP response ("staple"
it to the transaction).

A certificate contains a validity interval, a key, and some names/TNs.
An OCSP responses contains a validity interval, a certificate ID
(i.e., a hash), and a status (good/revoked/unknown).  In the web PKI,
certificates are required to be no more than 39 months long, and OCSP
responses no more than 10 days.

Ideally, a client only considers a certificate valid if it is
accompanied by an OCSP response.  In practice, this is not always
possible; because OCSP queries fail around 3% of the time, browsers
can't require OCSP.  This operational fact will be important below,
but we will continue to have scoping cert lifetimes as an objective.

In the web PKI, there are basically three revocation checking modalities:

1. Live OCSP checking [RFC6069]
2. OCSP stapling / must_staple [RFC6066, draft-hallambaker-tlsfeature]
3. Short-lived certificates (~OCSP lifetime)

(The last of these is relatively novel, and has not been deployed.
Neither has must-staple.  But they're both pretty trivial, and could
be folded into a STIR architecture pretty easily.)

Right now, about 90% of TLS transactions use live OCSP, and about 10%.
CAs and browsers dearly want the world to move toward stapled OCSP or
short-lived certs, because these reduces latency and improve the
quality of revocation information.

Revocation for CA certificates is currently done by having browsers
download a list from a centralized server, since there's no way to
staple more than one OCSP response.  That solution works OK for the
web, but if I were designing something de novo, I would probably use
multi-stapling as well.

# Applying this experience to STIR

Most of the below appear to be desired properties by the WG:

* Verifier neeeds to know that a cert is valid for a specific number
* Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if
issued longer)
* Caller privacy: Don't report what calls someone receives to a central server
* Carrier privacy: Don't allow a third party to figure out all the
numbers a carrier holds
* Minimize the rate at which the CA has to sign things
* Tolerate outages at the CA

I'm going to assume for now that we will not do live OCSP.  It
violates the caller privacy requirement, and as discussed above, it
just sucks operationally.  So STIR should require OCSP to be sent in
"stapled" form, which probably means sending it in Identity-Info.  And
while we're at it, we should also do "multi-stapling" -- send an OCSP
response for CA certs as well.

So if we consider a server with 50k TNs / blocks, that leaves us with
basically 3 options:

1. 50k short-lived certs (no OCSP)
2. 50k long-lived certs scoped to TNs + generic OCSP
3. 1 long-lived cert not scoped to TN (or a few loosely scoped) + OCSP
with TN info

(As I didn't quite get to say in the meeting, regardless of the
approach, you have to have 50k of *something*.)  Of these, it seems
like the preference order is 2 > 1 > 3.

Option 3 is bad from several perspectives:
* Putting TN info in the OCSP response enables someone to trawl for
numbers unless you access-control the OCSP server, so you inherit a
requirement to do that.
* With the rate of churn in number assignments, you're probably going
to have to update the long-lived cert pretty frequently anyway.
* Putting TN-specific stuff in certs is better than putting it in
OCSP.  As bad as X.509 libraries can be, OCSP libraries are much
worse.

Option 1 is mainly bad from the perspective of CA load and outages.
With Option 2, if the CA goes down, client can continue to use the
long-lived cert and just not bother doing OCSP (vs. tolerating an
expired cert).  Slightly cleaner.  Plus, there's a lot more experience
caching OCSP than new certs.  OCSP signing can also be delegated, so
you can have the recurring operation done by a lower-risk key.

Option 2 should be pretty easy to automate.  You can probably re-use
tooling for OCSP stapling that has already been developed for use with
HTTPS.  If you're a big box signing for a bunch of numbers, you do
need to select the right cert and OCSP response for a given call, but
that's a pretty simple lookup table.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 27 Jul 2015 22:39:56 -0400

What this means in practice is that it’s TN per cert.

I wouldn’t say that it’s impossible for a carrier to maintain dozens of copies of millions of private keys securely, but it’s hard.  You need multiple copies because you have multiple elements that can initiate a call, and you don’t want to depend on a centralized resource to do something as basic as create a call.

I think it’s hard enough that REQUIRING cert per TN is not acceptable.

Folks with more intimate knowledge of carrier SIP infrastructure might have more insight than I do.  It may be acceptable to have a centralized resource to manage millions of keys.

Brian

> On Jul 27, 2015, at 6:13 PM, Richard Barnes <[email-masked]> wrote:
> 
> <STIR.pptx>_______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Alex Bobotek <[email-masked]>
Date: Mon, 27 Jul 2015 21:36:26 -0700

What motivation would a carrier have to choose any model other than carrier signing using one of a very limited set of carrier-owned keys?  Large scale certificate management is expensive, and TN-specific certificates are unneeded for securing calls placed by parties who choose to place calls through a single reputable telephone service provider.  Anyone can get many certificates, even a free ones anonymously from some issuers.  It is typically a combination of the strength of the end-user authentication performed by the service provider (or certificate issuer in a provider-agnostic model) and the identity's history that are most useful in security.  

If we're trying to secure the current telephone system, DNS-like key repositories a la DKIM or perhaps a small number (compared to the number of TNs) of certificates are far more practical.  

Regards,

Alex

> -----Original Message-----
> From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: Monday, July 27, 2015 7:40 PM
> To: Richard Barnes <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [stir] On OCSP, TNs, and Privacy
> 
> I wouldn’t say that it’s impossible for a carrier to maintain dozens of copies of
> millions of private keys securely, but it’s hard.  You need multiple copies
> because you have multiple elements that can initiate a call, and you don’t
> want to depend on a centralized resource to do something as basic as create
> a call.
> 
> Folks with more intimate knowledge of carrier SIP infrastructure might have
> more insight than I do.  It may be acceptable to have a centralized resource
> to manage millions of keys.
> 
> Brian
> 
> > 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 long-lived
> > cert not scoped to TN (or a few loosely scoped) + OCSP with TN info
> >
> _______________________________________________
> stir mailing list
> [email-masked]

---

From: "Caron, Guy (A162859)" <[email-masked]>
Date: Tue, 28 Jul 2015 11:25:41 +0000

Fyi...

The CRTC (Canadian regulator) is gathering information from Canadians and the telecommunications industry to enhance the protections for Canadians from unsolicited and illegitimate telemarketing calls delivered on all telephony platforms by telecommunications service providers.

http://www.crtc.gc.ca/eng/archive/2015/2015-333.htm

Guy

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2015 07:54:10 -0400

> What this means in practice is that it’s TN per cert.

That's not quite true.  It requires that the TNs be listed explicitly
in the cert, which doesn't mean one TN, but probably also means not
millions.

> Folks with more intimate knowledge of carrier SIP infrastructure might have more insight than I do.  It may be acceptable to have a centralized resource to manage millions of keys.

Whoa now, having N certs does not mean having N keys.  You can have as
many certificates as you want with the same public key.  A certificate
is just the granularity of the authorization granted to that key.

So if the carrier and the CA are willing, the carrier can have N
certificates with all the same public key.  That would mean that the
carrier couldn't do any load balancing, and would have to revoke all
its certificates if that key pair is compromised, but that's a
trade-off that can be negotiated between consenting adults.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2015 08:10:03 -0400

On Tue, Jul 28, 2015 at 12:36 AM, Alex Bobotek <[email-masked]> wrote:
> What motivation would a carrier have to choose any model other than carrier signing using one of a very limited set of carrier-owned keys?  Large scale certificate management is expensive

As I noted to Brian, key management != cert management.  If you've got
5 signing boxes (each with it's own key pair) and 100k TNs, you can
allocate those TNs among the signing boxes however you like --
including issuing each signing box a set of certs that cover all 100k
numbers.  Key management is hard.  Cert management is only as hard as
you need it to be.

The benefits of "one big cert" are also illusory.   If you're going to
have N changes per week in your set of 100k TNs, then you're going to
have to replace your one big cert N times per week as well if you
don't want to lose fidelity.

>, and TN-specific certificates are unneeded for securing calls placed by parties who choose to place calls through a single reputable telephone service provider.  Anyone can get many certificates, even a free ones anonymously from some issuers.  It is typically a combination of the strength of the end-user authentication performed by the service provider (or certificate issuer in a provider-agnostic model) and the identity's history that are most useful in security.
>

Honestly, this seems like a pretty hand-wavy argument.  Modern web
hosting providers manage many thousands of certificates, and manage to
have their front end systems pick the right ones.  CloudFlare, for
example, has 2 million free-tier subscribers for whom they manage
certificates.  They bundle subscribers 20/certificate, so that's 100k
certificates they're managing.  Given that they're providing that
level of cert managment for their *free* tier, I have a hard time
buying the argument that managing certificates is insanely expensive.

--Richard

---

From: Patrick Tarpey <[email-masked]>
Date: Tue, 28 Jul 2015 12:39:52 +0000

Hi,

How would number porting work in this respect? Would the carrier hold a certificate covering a particular number have to automatically reissue the cert?

Pat

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: 28 July 2015 12:54
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

> What this means in practice is that it’s TN per cert.

That's not quite true.  It requires that the TNs be listed explicitly in the cert, which doesn't mean one TN, but probably also means not millions.

> Folks with more intimate knowledge of carrier SIP infrastructure might have more insight than I do.  It may be acceptable to have a centralized resource to manage millions of keys.

Whoa now, having N certs does not mean having N keys.  You can have as many certificates as you want with the same public key.  A certificate is just the granularity of the authorization granted to that key.

So if the carrier and the CA are willing, the carrier can have N certificates with all the same public key.  That would mean that the carrier couldn't do any load balancing, and would have to revoke all its certificates if that key pair is compromised, but that's a trade-off that can be negotiated between consenting adults.

--Richard

>> 2. OCSP stapling / must_staple [RFC6066,
>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP
>> lifetime)
>>
>> "stapled" form, which probably means sending it in Identity-Info.
>> And while we're at it, we should also do "multi-stapling" -- send an
>> OCSP response for CA certs as well.
>>
>> expired cert).  Slightly cleaner.  Plus, there's a lot more
>> experience caching OCSP than new certs.  OCSP signing can also be
>> delegated, so you can have the recurring operation done by a lower-risk key.
>>
>> tooling for OCSP stapling that has already been developed for use
>> with HTTPS.  If you're a big box signing for a bunch of numbers, you
>> do need to select the right cert and OCSP response for a given call,
>> but that's a pretty simple lookup table.

________________________________

******************************************************************************************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use of the addressee only.

If you have received this email in error please notify the originator of the message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments at your own risk.

Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise.
******************************************************************************************************************

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2015 09:03:31 -0400

> How would number porting work in this respect? Would the carrier hold a certificate covering a particular number have to automatically reissue the cert?

Porting would work pretty much the same in any of these schemes.  The
net effect would be that any certs that the original TN holder has for
the ported TN would have to be revoked, and the recipient TN holder
would be issued a new certificate containing the ported TN.

The major difference between the below options is whether this is
between creating and destroying small objects on the one hand, and
updating large objects on the other hand:
1. Revoke a single- or few-TN certificate from the original holder;
issue a single- or few-TN cert to the new holder
2. Revoke a many-TN cert from the original holder and re-issue with
the ported TN in addition to the others; issue the new holder a new
certificate with his old holdings plus the new TN.

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Jul 2015 13:51:07 +0000

Just to amplify: A CA doesn't use a new public-private key pair for each cert. It uses one for all of them, millions. One model might be one PK pair for each major SBC, with the corresponding cert database for queries, but that's obviously a local implementation choice.

Henning

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, July 28, 2015 7:54 AM
To: Brian Rosen <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

--Richard

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 28 Jul 2015 13:51:59 +0000

"Large scale certificate management is expensive, and TN-specific certificates are unneeded for securing calls placed by parties who choose to place calls through a single reputable telephone service provider."

Are you saying that for "on-net" calls, STIR methodology is unnecessary?

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Alex Bobotek [mailto:[email-masked]]
Sent: July 27, 2015 11:36 PM
To: Brian Rosen <[email-masked]>; Richard Barnes <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

Regards,

Alex

> I wouldn’t say that it’s impossible for a carrier to maintain dozens
> of copies of millions of private keys securely, but it’s hard.  You
> need multiple copies because you have multiple elements that can
> initiate a call, and you don’t want to depend on a centralized
> resource to do something as basic as create a call.
>
> Folks with more intimate knowledge of carrier SIP infrastructure might
> have more insight than I do.  It may be acceptable to have a
> centralized resource to manage millions of keys.
>
> Brian
>
> > (i.e., a hash), and a status (good/revoked/unknown).  In the web
> > PKI, certificates are required to be no more than 39 months long,
> > and OCSP responses no more than 10 days.
> >
> > CAs and browsers dearly want the world to move toward stapled OCSP
> > or short-lived certs, because these reduces latency and improve the
> > So if we consider a server with 50k TNs / blocks, that leaves us
> > with basically 3 options:
> >
> > * With the rate of churn in number assignments, you're probably
> > going to have to update the long-lived cert pretty frequently anyway.

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: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2015 10:12:05 -0400

> Are you saying that for "on-net" calls, STIR methodology is unnecessary?

This seems a little off-topic for this list.

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Jul 2015 14:14:00 +0000

As far as I can tell, managing certs is managing lots of blobs of static (at the scale of years) bits. Easy to do with a database. For a new cert, e.g., after a port, just issue a CSR. Get back cert from next-higher layer (e.g., LNPA in the US). Store blob in database and return upon request. Since this is a strict primary key lookup, use your favorite noSQL database if you're worried about speed or scaling.

For 10M certs, that's very roughly 10 GB of storage. (I used http://fm4dd.com/openssl/certexamples.htm for the size estimate.)

Modify time scales slightly if OCSP stapling is added.

I think we'll make more progress if people are specific - why is something hard? Conversely, is there existence proof of similar systems?

Henning

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, July 28, 2015 8:10 AM
To: Alex Bobotek <[email-masked]>
Cc: [email-masked]; Brian Rosen <[email-masked]>
Subject: Re: [stir] On OCSP, TNs, and Privacy

On Tue, Jul 28, 2015 at 12:36 AM, Alex Bobotek <[email-masked]> wrote:
> What motivation would a carrier have to choose any model other than 
> carrier signing using one of a very limited set of carrier-owned keys?  
> Large scale certificate management is expensive

As I noted to Brian, key management != cert management.  If you've got
5 signing boxes (each with it's own key pair) and 100k TNs, you can allocate those TNs among the signing boxes however you like -- including issuing each signing box a set of certs that cover all 100k numbers.  Key management is hard.  Cert management is only as hard as you need it to be.

The benefits of "one big cert" are also illusory.   If you're going to
have N changes per week in your set of 100k TNs, then you're going to have to replace your one big cert N times per week as well if you don't want to lose fidelity.

> If we're trying to secure the current telephone system, DNS-like key repositories a la DKIM or perhaps a small number (compared to the number of TNs) of certificates are far more practical.

Honestly, this seems like a pretty hand-wavy argument.  Modern web hosting providers manage many thousands of certificates, and manage to have their front end systems pick the right ones.  CloudFlare, for example, has 2 million free-tier subscribers for whom they manage certificates.  They bundle subscribers 20/certificate, so that's 100k certificates they're managing.  Given that they're providing that level of cert managment for their *free* tier, I have a hard time buying the argument that managing certificates is insanely expensive.

--Richard

>> Folks with more intimate knowledge of carrier SIP infrastructure 
>> might have more insight than I do.  It may be acceptable to have a 
>> > In an HTTPS transaction, the HTTPS server provides the client with 
>> > a certificate, and it can optionally include an OCSP response ("staple"
>> > it to the transaction).
>> >
>> > Neither has must-staple.  But they're both pretty trivial, and 
>> > could be folded into a STIR architecture pretty easily.)
>> >
>> > web, but if I were designing something de novo, I would probably 
>> > use multi-stapling as well.
>> >
>> >
>> > just sucks operationally.  So STIR should require OCSP to be sent 
>> > in "stapled" form, which probably means sending it in 
>> > Identity-Info.  And while we're at it, we should also do 
>> > "multi-stapling" -- send an OCSP response for CA certs as well.
>> >
>> > 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 
>> > long-lived cert not scoped to TN (or a few loosely scoped) + OCSP 
>> > with TN info
>> >
>> > Option 2 should be pretty easy to automate.  You can probably 
>> > re-use tooling for OCSP stapling that has already been developed 
>> > for use with HTTPS.  If you're a big box signing for a bunch of 
>> > numbers, you do need to select the right cert and OCSP response for 
>> > a given call, but that's a pretty simple lookup table.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 28 Jul 2015 14:14:24 +0000

I thought the discussion was on key/cert management.  I'm asking if I understood the suggestion to minimize requirements.  How is that off topic?

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: July 28, 2015 9:12 AM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Alex Bobotek <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

--Richard

>> > in "stapled" form, which probably means sending it in Identity-Info.
>> > And while we're at it, we should also do "multi-stapling" -- send
>> > an OCSP response for CA certs as well.
>> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Jul 2015 14:24:22 +0000

In the US alone, we have about 4000 carriers. Managing the reputation of that many entities, reliably (i.e., without making false positive/negative mistakes) seems a whole lot more manual effort than storing bags of bits. Storage and automation is cheap, human judgement and dealing with mistakes is expensive.

Obviously, nothing in the architecture prevents wildcard certificates.

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [CTO]
Sent: Tuesday, July 28, 2015 10:14 AM
To: Richard Barnes <[email-masked]>
Cc: [email-masked]; Alex Bobotek <[email-masked]>; Brian Rosen <[email-masked]>
Subject: Re: [stir] On OCSP, TNs, and Privacy

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: July 28, 2015 9:12 AM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Alex Bobotek <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

--Richard

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Tue, 28 Jul 2015 19:13:49 +0000

Forgive me but my reptile brain keeps whispering in my ear that this would be a lot easier if we simply had a numbering registry, whether distributed or centralized - like we need anyway for at least for number portability - that also contained the public keys. No tedious mucking about in cyberspace with certs, CRLs, or OCSP.

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [CTO]
Sent: Tuesday, July 28, 2015 10:14 AM
To: Richard Barnes <[email-masked]>
Cc: [email-masked]; Alex Bobotek <[email-masked]>; Brian Rosen <[email-masked]>
Subject: Re: [stir] On OCSP, TNs, and Privacy

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: July 28, 2015 9:12 AM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Alex Bobotek <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Jul 2015 19:27:26 +0000

That was certainly one of the models that have been discussed in the past. Particularly for small carriers, this would likely reduce the operational impact to a configuration option in the SBC.

The disadvantage of this model is caller privacy: If the cert is stored at a numbering authority, it would be easy for that authority to know which carrier is receiving calls from whom. (It's not the complete meta data since it's lacking the callee information.)

However, unless the TN-to-LRN (in the US) mapping is cached, this "leak" already exists today.

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [CTO]
Sent: Tuesday, July 28, 2015 10:14 AM
To: Richard Barnes <[email-masked]>
Cc: [email-masked]; Alex Bobotek <[email-masked]>; Brian Rosen <[email-masked]>
Subject: Re: [stir] On OCSP, TNs, and Privacy

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: July 28, 2015 9:12 AM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Alex Bobotek <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

--Richard

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 28 Jul 2015 19:35:29 +0000

It has to be easy and deplorable, without creating a business case for some 3rd party or we may just have white/black lists

Sent from my iPhone

> On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne <[email-masked]> wrote:
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 28 Jul 2015 19:38:42 +0000

One of the better auto-corrections I suspect.

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: DOLLY, MARTIN C [mailto:[email-masked]]
Sent: July 28, 2015 2:35 PM
To: Henning Schulzrinne <[email-masked]>
Cc: PFAUTZ, PENN L <[email-masked]>; Gorman, Pierce A [CTO] <[email-masked]>; [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

Sent from my iPhone

> The disadvantage of this model is caller privacy: If the cert is
> stored at a numbering authority, it would be easy for that authority
> to know which carrier is receiving calls from whom. (It's not the
> complete meta data since it's lacking the callee information.)
>
>>> What this means in practice is that it's TN per cert.
>>>
>>> I wouldn't say that it's impossible for a carrier to maintain dozens
>>> of copies of millions of private keys securely, but it's hard.  You
>>> initiate a call, and you don't want to depend on a centralized
>>> I think it's hard enough that REQUIRING cert per TN is not acceptable.
>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Jul 2015 19:43:41 +0000

I suspect we all deplore CNAM dip fees as a model here. Fortunately, here the caller has an incentive to make it easy to validate the caller identity, so the incentives seem better aligned. Both parties are likely to have an existing relationship to the porting database, and self-provisioning will also likely limit the opportunity for above-cost services. (After all, the originating server can always run their own cert server, so any third party is likely to be limited to the cost of running such a server, even if it isn't made part of some existing service, like number portability, that's paid in some non-dip-fee manner.)

-----Original Message-----
From: DOLLY, MARTIN C [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2015 3:35 PM
To: Henning Schulzrinne <[email-masked]>
Cc: PFAUTZ, PENN L <[email-masked]>; Gorman, Pierce A [CTO] <[email-masked]>; [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

Sent from my iPhone

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Tue, 28 Jul 2015 15:49:11 -0400

In all U.S. networks I'm familiar with, the TN-to-LRN mapping is cached.  I assume that the same model would work if we added public keys to what Penn calls the numbering registry.

This of course is a US -centric solution since it assumes that caches in the originating network are populated from a centralized authority.  

tim

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [CTO]
Sent: Tuesday, July 28, 2015 10:14 AM
To: Richard Barnes <[email-masked]>
Cc: [email-masked]; Alex Bobotek <[email-masked]>; Brian Rosen <[email-masked]>
Subject: Re: [stir] On OCSP, TNs, and Privacy

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: July 28, 2015 9:12 AM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: Alex Bobotek <[email-masked]>; Brian Rosen <[email-masked]>; [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2015 16:06:50 -0400

http://www.afldreamers.com/wp-content/uploads/2014/01/why-not-have-both-300x187.png

You could have a database of certs+OCSP responses as an optimization.
IIRC, Identity-Info only has pointers to certs anyway.

---

From: Richard Shockey <[email-masked]>
Date: Tue, 28 Jul 2015 15:55:57 -0400

LOL .. Its a classic.

‹ 
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

On 7/28/15, 3:38 PM, "stir on behalf of Gorman, Pierce A [CTO]"
<[email-masked] on behalf of [email-masked]> wrote:

>Cc: PFAUTZ, PENN L <[email-masked]>; Gorman, Pierce A [CTO]
><[email-masked]>; [email-masked]
>It has to be easy and deplorable, without creating a business case for
>some 3rd party or we may just have white/black lists
>
>Sent from my iPhone
>
>> That was certainly one of the models that have been discussed in the
>>past. Particularly for small carriers, this would likely reduce the
>>operational impact to a configuration option in the SBC.
>>
>> Forgive me but my reptile brain keeps whispering in my ear that this
>>would be a lot easier if we simply had a numbering registry, whether
>>distributed or centralized - like we need anyway for at least for number
>>portability - that also contained the public keys. No tedious mucking
>>about in cyberspace with certs, CRLs, or OCSP.
>>
>>
>>
>> In the US alone, we have about 4000 carriers. Managing the reputation
>>of that many entities, reliably (i.e., without making false
>>positive/negative mistakes) seems a whole lot more manual effort than
>>storing bags of bits. Storage and automation is cheap, human judgement
>>and dealing with mistakes is expensive.
>>
>> I thought the discussion was on key/cert management.  I'm asking if I
>>understood the suggestion to minimize requirements.  How is that off
>>topic?
>>
>> Best regards,
>>
>>
>> Pierce Gorman
>> Core Network Planning
>> O: 913-439-4368
>> [email-masked]
>>
>>
>>> "Large scale certificate management is expensive, and TN-specific
>>>certificates are unneeded for securing calls placed by parties who
>>>choose to place calls through a single reputable telephone service
>>>provider."
>>>
>>>Large scale certificate management is expensive, and TN-specific
>>>certificates are unneeded for securing calls placed by parties who
>>>choose to place calls through a single reputable telephone service
>>>provider.  Anyone can get many certificates, even a free ones
>>>anonymously from some issuers.  It is typically a combination of the
>>>strength of the end-user authentication performed by the service
>>>provider (or certificate issuer in a provider-agnostic model) and the
>>>identity's history that are most useful in security.
>>>
>>> If we're trying to secure the current telephone system, DNS-like key
>>>repositories a la DKIM or perhaps a small number (compared to the
>>>number of TNs) of certificates are far more practical.
>>>
>>> Regards,
>>>
>>> Alex
>>>
>>> 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.
>>
>> 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.
>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: Richard Shockey <[email-masked]>
Date: Tue, 28 Jul 2015 16:02:56 -0400

Exactly everything is cached.  But its the same system in Canada and most
of the smaller European countries.  The Dutch COIN system operates very
much like the US NPAC model of a centralized authority but it is a non
profit cooperative like RIPE or ARIN. Very very cost effective for the
Dutch operators. Ireland Sweden Finland are the same as well.

On 7/28/15, 3:49 PM, "stir on behalf of Dwight, Timothy M (Tim)"
<[email-masked] on behalf of [email-masked]> wrote:

>In all U.S. networks I'm familiar with, the TN-to-LRN mapping is cached.
>I assume that the same model would work if we added public keys to what
>Penn calls the numbering registry.
>
>This of course is a US -centric solution since it assumes that caches in
>the originating network are populated from a centralized authority.
>
>tim
>
>The disadvantage of this model is caller privacy: If the cert is stored
>at a numbering authority, it would be easy for that authority to know
>which carrier is receiving calls from whom. (It's not the complete meta
>data since it's lacking the callee information.)
>
>In the US alone, we have about 4000 carriers. Managing the reputation of
>that many entities, reliably (i.e., without making false
>>repositories a la DKIM or perhaps a small number (compared to the number
>>of TNs) of certificates are far more practical.
>>
>> Regards,
>>
>> Alex
>>
>>> What this means in practice is that it¹s TN per cert.
>>>
>>> I wouldn¹t say that it¹s impossible for a carrier to maintain dozens
>>> of copies of millions of private keys securely, but it¹s hard.  You
>>> initiate a call, and you don¹t want to depend on a centralized
>>> I think it¹s hard enough that REQUIRING cert per TN is not acceptable.
>>>

---

From: Alex Bobotek <[email-masked]>
Date: Tue, 28 Jul 2015 15:21:46 -0700

Pierce,

I appreciate your question, and will try to be less abstract.  Punch line is near the end.  

I am saying that _certificates_ are not needed for auth.  A collection of service provider public keys stored in some repository (e.g., in ENUM or DNS) is an alternative.  As our transport networks already use registries that can server as repositories, and they have a degree of security that allows a serving carrier to specify a trusted parameter, it seems to be the most practical solution.  This is what was done in DKIM, and it clearly works.

And as others have also suggested, this is simpler than creating a certificate distribution and management infrastructure.  

Punch line: 
Yes, I am most definitely expressing the opinion that IETF should work on standards for a registry-based public key repository and registry-based validation methods to be used for STIR validation.  I hope that there are other like-minded people to join in producing an Internet Draft on this.  

Regards,

Alex

> From: Gorman, Pierce A [CTO] [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2015 6:52 AM
> To: Alex Bobotek <[email-masked]>; Brian Rosen <[email-masked]>;
> Richard Barnes <[email-masked]>
> Cc: [email-masked]
> "Large scale certificate management is expensive, and TN-specific certificates
> are unneeded for securing calls placed by parties who choose to place calls
> through a single reputable telephone service provider."
> 
> What motivation would a carrier have to choose any model other than carrier
> signing using one of a very limited set of carrier-owned keys?  Large scale
> certificate management is expensive, and TN-specific certificates are
> unneeded for securing calls placed by parties who choose to place calls
> through a single reputable telephone service provider.  Anyone can get many
> certificates, even a free ones anonymously from some issuers.  It is typically a
> combination of the strength of the end-user authentication performed by
> the service provider (or certificate issuer in a provider-agnostic model) and
> the identity's history that are most useful in security.
> 
> 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: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2015 18:43:24 -0400

> Yes, I am most definitely expressing the opinion that IETF should work on standards for a registry-based public key repository and registry-based validation methods to be used for STIR validation.…

I'm having a little trouble understanding how this solution is better
than certificates at all.  In either case:
- the authority (CA or registry) has to maintain up-to-date info as to
which numbers go with which public keys
- relying parties have to know who to trust (CA or registry public key)

The only difference is that if the authority issues certificates, then
you don't have the crushing uptime requirements that you do with a
registry.

Also ENUM and DNS are clearly not acceptable solutions, unless they're
done with DNSSEC.

This does not seem like a win to me.

--Richard

---

From: Richard Shockey <[email-masked]>
Date: Tue, 28 Jul 2015 18:30:18 -0400

Richard .. Be reasonable here its not a perfect world and IETF protocols,
especially its security protocols are not perfect.  At some point the
limited competency of the IETF will move into the realm of policy.

In the US that means the usual suspects will have to weigh in. ATIS INC,
the NANC,FCC. Its only a matter of time this ends up being a FCC Docket.
This is not to say engineering concerns do not drive policy, far from it
look at spectrum issues for instance.

But its their [FCC CRTC OFCOM ART BeNetA FICORA) numbers and we (IETF) do
not dictate policy. Only offer options.

‹ 
Richard Shockey
Shockey Consulting LLC

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2015 18:57:29 -0400

> Richard .. Be reasonable here its not a perfect world and IETF protocols,

You are correct that if we build a putative security solution based on
public keys passed DNS, it will not be an IETF protocol.  It will not
become an RFC because it will not meet the IETF's security standards.

And in any case, it's not that much harder to do the really secure
thing.  Even if you want a central registry, do it over HTTPS, and
it'll be just as fast and 100% more secure.

--Richard

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Tue, 28 Jul 2015 23:38:18 +0000

to be clear much as I've labored on ENUM a registry doesn't have to be DNS based.
The the LNP DBOR already has to be robust as do the SP and service bureau platforms it loads so I've added nothing but a new data field and the provisioning that goes with it.
The authority is already built in, synched with portability, and tied to "parties that can be punished." 

regards,

Penn
Sent from my iPad

> On Jul 28, 2015, at 6:43 PM, Richard Barnes <[email-masked]> wrote:
>

---

From: Chris Wendt <[email-masked]>
Date: Tue, 28 Jul 2015 21:22:47 -0400

If the registry is distributed, and the certificate dip is local to the provider, the numbering authority isn’t in the middle of each call, one of the points we are advocating in general, in terms of making this scalable and “deployable”.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2015 21:30:07 -0400

> If the registry is distributed, and the certificate dip is local to the provider, the numbering authority isn’t in the middle of each call, one of the points we are advocating in general, in terms…

Do you happen to have a good standard technology on hand for
synchronizing a database across a potentially unbounded set of
signers/verifiers?  I don't think we can assume that that set of
actors is limited to the set of "providers", for any definition of
that term.  For so it is written in RFC 7340:

"""
   Generation:  Intermediaries as well as end systems must be able to
      generate the source identity information.

   Validation:  Intermediaries as well as end systems must be able to
      validate the source identity information.
"""

If you're going to meet that requirement, I think your distributed
registry ends up looking far more complex than just passing around
certificates.

Of course, if you're just talking about a signer looking up what cert
it should use, then we agree; that's just what I meant when I said
that managing multiple certs is just a hash table lookup.

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Jul 2015 01:35:39 +0000

I admit, like Richard, I'm confused why this offers significant performance or simplicity advantages. A cert contains the public key of the number holder (in our case), some meta data (validity dates, algorithm descriptions, CA name) and a signature of the CA. Like a public key, it would likely be stored either as a binary blob or some base-64 representation.

If you stored just the public key, you'd probably have to replicate at least some of the meta data in other database fields.

What simplicity or performance would be gained here?

I'm all for allowing registries to store certs, which would be downloaded and cached by validating proxies/SBCs at the callee side as *one* option, similar to how the LRN data is maintained today, avoiding both the privacy and single-point-of-failure issues. But storing public keys instead doesn't seem to offer any inherent advantages that I can see.

Another advantage for the cert-by-pointer model is rapid failover: If a carrier experiences a catastrophic failure in their cert retrieval mechanism, they can immediately switch the Identity-Info pointer to the public server (registry), without anybody else being inconvenienced. Or vice versa. This obviously doesn't work since you can't just point at some random public key somewhere.

Henning

________________________________________
From: stir <[email-masked]> on behalf of PFAUTZ, PENN L <[email-masked]>
Sent: Tuesday, July 28, 2015 7:38 PM
To: Richard Barnes
Cc: [email-masked]; Alex Bobotek; Gorman, Pierce A [CTO]; Brian Rosen
Subject: Re: [stir] On OCSP, TNs, and Privacy

regards,

Penn
Sent from my iPad

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Jul 2015 01:42:28 +0000

I'm confused by "numbering authority in the middle of each call" part. The model would be that the numbering authority might serve as the "origin server" and signer, but the cert is stored, at least for high-volume call originators, at the originator, so that you are likely to have fate sharing. Caching at the validator is another option, but calls may not experience sufficient locality to give good cache hit ratios. Downloading all certs is not impossible (with 800M US numbers in use, we're talking 800 GB of data for single-TN certs, every 1-3 years, and somewhat less if you aggregate TNs in a cert).

________________________________________
From: Richard Barnes <[email-masked]>
Sent: Tuesday, July 28, 2015 9:30 PM
To: Chris Wendt
Cc: Henning Schulzrinne; [email-masked]; Gorman, Pierce A [CTO]; PFAUTZ, PENN L
Subject: Re: [stir] On OCSP, TNs, and Privacy

"""

--Richard

---

From: Chris Wendt <[email-masked]>
Date: Tue, 28 Jul 2015 21:43:04 -0400

Henning discussed an example at the modern meeting.  Gossip based distributed mechanisms can be used.

I’m curious what you mean by unbounded, in terms of numbers?  1k/10k/100k/1M?

DNS is a much more brute force mechanism for a distributed system but yet it propagates things pretty quickly globally.

4474bis if i remember correctly even mentions the fact that we will need to store multiple historical certificate records and references (maybe 2 is enough in practice) in order to mitigate delays in propagation of new certificates.

I don’t see the issue.

> On Jul 28, 2015, at 9:30 PM, Richard Barnes <[email-masked]> wrote:
> 
> On Tue, Jul 28, 2015 at 9:22 PM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Chris Wendt <[email-masked]>
Date: Tue, 28 Jul 2015 21:47:01 -0400

> The disadvantage of this model is caller privacy: If the cert is stored at a numbering authority, it would be easy for that authority to know which carrier is receiving calls from whom. (It's not t…

so replace “in the middle of the call” with being able to correlate carrier calling information.

> On Jul 28, 2015, at 9:42 PM, Henning Schulzrinne <[email-masked]> wrote:
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2015 21:51:01 -0400

> I’m curious what you mean by unbounded, in terms of numbers?

How many phones are there out there?  "end systems must be able to
validate the source identity information."

> DNS is a much more brute force mechanism for a distributed system but yet it
> propagates things pretty quickly globally.
>
> 4474bis if i remember correctly even mentions the fact that we will need to
> store multiple historical certificate records and references (maybe 2 is
> enough in practice) in order to mitigate delays in propagation of new
> certificates.
>
> I don’t see the issue.

The point is that when my phone gets a call it needs to be able to
verify the caller's authorization.  The Identity-Info signature binds
the call to the caller's public key.  So the my phone needs to verify
that the public key is authorized.

If I understand you correctly, you're proposing that my phone needs to
sync down a giant database of which public keys are authorized for
which numbers, or it needs to call out to some registry it trusts,
which needs to be online all the time.

Those both seem far worse than my phone just having to look up a
certificate, or verify one that was included in the INVITE directly.
The only cost of on the signer side is that the signer has to pick the
right cert to send, which, as I said before, is just a hash table
lookup.

--Richard

> If the registry is distributed, and the certificate dip is local to the
> provider, the numbering authority isn’t in the middle of each call, one of
> the points we are advocating in general, in terms of making this scalable
> and “deployable”.
>
>
> That was certainly one of the models that have been discussed in the past.
> Particularly for small carriers, this would likely reduce the operational
> impact to a configuration option in the SBC.
>
> The disadvantage of this model is caller privacy: If the cert is stored at a
> numbering authority, it would be easy for that authority to know which
> carrier is receiving calls from whom. (It's not the complete meta data since
> it's lacking the callee information.)
>
> Forgive me but my reptile brain keeps whispering in my ear that this would
> be a lot easier if we simply had a numbering registry, whether distributed
> or centralized - like we need anyway for at least for number portability -
> that also contained the public keys. No tedious mucking about in cyberspace
> with certs, CRLs, or OCSP.
>
>
>
> that many entities, reliably (i.e., without making false positive/negative
> mistakes) seems a whole lot more manual effort than storing bags of bits.
> Storage and automation is cheap, human judgement and dealing with mistakes
> is expensive.
>
> understood the suggestion to minimize requirements.  How is that off topic?
>
> Best regards,
>
>
> Pierce Gorman
> Core Network Planning
> O: 913-439-4368
> [email-masked]
>
>
> certificates are unneeded for securing calls placed by parties who choose to
> place calls through a single reputable telephone service provider."
>
> certificates, even a free ones anonymously from some issuers.  It is
> typically a combination of the strength of the end-user authentication
> performed by the service provider (or certificate issuer in a
> provider-agnostic model) and the identity's history that are most useful in
> security.
>
> repositories a la DKIM or perhaps a small number (compared to the number of
> TNs) of certificates are far more practical.
>
> Regards,
>
> Alex
>

---

From: Chris Wendt <[email-masked]>
Date: Tue, 28 Jul 2015 21:57:07 -0400

Depends on your perspective. 

I would suspect we would both agree that “phones querying the numbering authority registry" is not the problem statement we are working towards, for very different reasons.

> On Jul 28, 2015, at 9:51 PM, Richard Barnes <[email-masked]> wrote:
>

---

From: Richard Shockey <[email-masked]>
Date: Tue, 28 Jul 2015 21:47:12 -0400

Richard.  That is the core problem here. As far as some of us believe
there are no silver bullets and STIR in itself is not the ultimate
solution. It was in the beginning a multifaceted problem. We knew that the
goal was to suppress the problem sufficiently in order to restore public
confidence in the system.

Perfection is not the goal.  Goodness knows I don’t think ENUM is now the
solution for database distrbution.  The model to be sure but we have much
better tools and HTTPS now for distributed databases.

Focus on tools and not policy.

On 7/28/15, 6:57 PM, "stir on behalf of Richard Barnes"
<[email-masked] on behalf of [email-masked]> wrote:

>>>http://www.afldreamers.com/wp-content/uploads/2014/01/why-not-have-both-
>>>30
>>>0x187.png
>>>
>>>> From: stir [mailto:[email-masked]] On Behalf Of Gorman, Pierce
>>>>A
>>>>[CTO]
>>>>>>Identity-Info.
>>>>the

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 29 Jul 2015 02:58:00 +0000

I assume in practice there will be billions of communication endpoints (in the discussion they've been referred to as phones, but laptops, tablets, toasters, cars, M2M/IoT are also candidates) which may authenticate calling number in situ, and others which may have authenticated information proxied to them (over a secure communications channel?), and not necessarily using SIP (think WebRTC) or HTML.

Computing power and time is cheaper in the core as compared to endpoints.  More signaling messages and dips are bad as compared to less signaling and dips.

There are always trade-offs and the safe thing to assume is don't assume anything (with regard to centralized or distributed, cached or dipped).

Sent from my iPad

> On Jul 28, 2015, at 8:57 PM, Chris Wendt <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Jul 2015 10:34:46 +0100

Hi Richard,

> become an RFC because it will not meet the IETF's security standards.

Eh, that's not accurate. DKIM [1] is an Internet Standard
(i.e. not a Proposed Standard) that does exactly that and
that is in widespread use and that does not require DNSSEC.
That is ok in that context because a bad signature is the
same as a missing signature.

If this WG wanted to use a DKIM-like solution and could
justify the lack of 3rd party cryptographic binding between
the TN and the public key, that could be entirely analogous.

I'm not saying the WG should do that, but it could.

Cheers,
S.

[1] https://tools.ietf.org/html/rfc6376

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Jul 2015 09:15:26 -0400

> I'm not saying the WG should do that, but it could.

Yeah, I guess what I'm saying is that I don't really see that
justification in this case.  Doing it right is cheap, so we should.

--Richard

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 29 Jul 2015 14:00:56 +0000

If it isn't obvious already, I'll admit up front I have limited (not zero) experience with building VoIP systems with SBCs engaging in certificate-based (in our case, mutual) authentication, but the experience was onerous, which makes me to be immediately suspicious of the claim, "Doing it right is cheap, so we should".

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: July 29, 2015 8:15 AM
To: Stephen Farrell <[email-masked]>
Cc: Richard Shockey <[email-masked]>; [email-masked]; Gorman, Pierce A [CTO] <[email-masked]>; PFAUTZ, PENN L <[email-masked]>; Henning Schulzrinne <[email-masked]>
Subject: Re: [stir] On OCSP, TNs, and Privacy

On Wed, Jul 29, 2015 at 5:34 AM, Stephen Farrell <[email-masked]> wrote:
>> You are correct that if we build a putative security solution based
>> on public keys passed DNS, it will not be an IETF protocol.  It will
>> not become an RFC because it will not meet the IETF's security standards.
>
> Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e. not a
> Proposed Standard) that does exactly that and that is in widespread
> use and that does not require DNSSEC.
> That is ok in that context because a bad signature is the same as a
> missing signature.
>
> If this WG wanted to use a DKIM-like solution and could justify the
> lack of 3rd party cryptographic binding between the TN and the public
> key, that could be entirely analogous.
>

Yeah, I guess what I'm saying is that I don't really see that justification in this case.  Doing it right is cheap, so we should.

--Richard

---

From: Alex Bobotek <[email-masked]>
Date: Wed, 29 Jul 2015 11:50:21 -0700

Arguably the most important thing STIR can do is to help service providers make intelligent policy decisions.  An endpoint (aka the recipient's phone) policy decision based solely on STIR validation results will not be anywhere near as effective as one based on a large network or even crowd-sourced view.  Network-based inputs such as complaints, submissions of unwanted voicemail, call volumetrics, calling graphs, reputation of the originating service provider, reputation of the originating TN, account history, call completion records and call durations are important.  Privacy considerations make many of these inputs  difficult to crowd source.  And these inputs are difficult to provide to an endpoint even with new standards, but could be conveyed either as an aggregate score or individual parameters.  Endpoint policy enforcement should of course be supported, but we should recognize that network-based enforcement is in practice the most widely adopted and effective policy enforcement implementation (e.g., in email and SMS spaces).  

Therefore STIR should provide network operators with
	* a validated identity of the originating service provider, and 
	* a validated originating service provider assertion of the originating TN.  (Note:  this might be provided to networks but not endpoints in cases where caller ID is masked.)
This provides much needed technical information and accountability for technical and non-technical enforcement.  

Operational considerations are the primary barrier to STIR implementation -- what's easy to create in a lab may take many years and thousands of servers to be implemented in a complex telco production environment.  STIR should consider these as dominant drivers.  It is much more practical for a telco to manage a dozen or so of its private-public key pairs than to create and manage a per-TN (> 100M TNs in the case of some carriers) certificate infrastructure.  Adding a per-call database dip or per-TN cache is a huge impact.    

Public key distribution to carriers can be accomplished using some existing lookup-based registry, and/or via attached certificates.  Using a registry already accessible to policy/routing engines is IMHO more practical in a service provider environment. 

Regards,

Alex

> Sent: Wednesday, July 29, 2015 6:15 AM
> Cc: Henning Schulzrinne <[email-masked]>; [email-masked];
> Gorman, Pierce A [CTO] <[email-masked]>; PFAUTZ, PENN L
> <[email-masked]>; Richard Shockey <[email-masked]>
> Yeah, I guess what I'm saying is that I don't really see that justification in this
> case.  Doing it right is cheap, so we should.
> 
> --Richard
> 
> >
> > Cheers,
> > S.
> >

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 29 Jul 2015 18:59:54 +0000

Yeah, what he said times infinity.  :-)

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Alex Bobotek [mailto:[email-masked]]
Sent: July 29, 2015 1:50 PM
To: Richard Barnes <[email-masked]>; Stephen Farrell <[email-masked]>
Cc: Henning Schulzrinne <[email-masked]>; [email-masked]; Gorman, Pierce A [CTO] <[email-masked]>; PFAUTZ, PENN L <[email-masked]>; Richard Shockey <[email-masked]>
Subject: RE: [stir] On OCSP, TNs, and Privacy

Therefore STIR should provide network operators with
* a validated identity of the originating service provider, and
* a validated originating service provider assertion of the originating TN.  (Note:  this might be provided to networks but not endpoints in cases where caller ID is masked.) This provides much needed technical information and accountability for technical and non-technical enforcement.

Regards,

Alex

> >> on public keys passed DNS, it will not be an IETF protocol.  It
> >> will not become an RFC because it will not meet the IETF's security standards.
> >
> > Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e. not
> > a Proposed Standard) that does exactly that and that is in
> > widespread use and that does not require DNSSEC.
> > lack of 3rd party cryptographic binding between the TN and the
> > public key, that could be entirely analogous.
> >

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 30 Jul 2015 15:27:07 +0000

I don't think those properties are very different from what RFC3325
provides. If all you care about is that someone you deem a "network
operator" has asserted the originating TN, then PAI is surely adequate.

The scope of STIR is different, however. We are considering a more
pluralist world, after the IP transition, wherein a somewhat messy mixture
of network operators, enterprises, and even end users could hold
credentials that let them sign telephone calls. In that environment, the
credentials need to reflect more than just the identity of the signer:
they need to reflect number assignment itself.

Personally, I agree that in this world I would not want to require holders
of large number blocks (carriers) to have a cert per TN. And I totally
agree that in that world, it would make sense for carrier policies to
involve mutual trust that is based on the subject of certificates rather
than the TNAuthList. But in STIR we're defining what goes on the wire, and
in the certs, rather than the particulars of operator policy. We're
providing mechanisms that will help in the messier cases, which may not
need to be exercised in cases that look more like traditional PSTN
operator handoffs.

Yes, STIR treats a more complex world operationally than the effectively
closed network of the PSTN, which RFC3325 tries to emulate. But it is the
world that is coming, as far as I can tell.

Jon Peterson
Neustar, Inc.

On 7/29/15, 11:50 AM, "Alex Bobotek" <[email-masked]> wrote:

>Arguably the most important thing STIR can do is to help service
>providers make intelligent policy decisions.  An endpoint (aka the
>recipient's phone) policy decision based solely on STIR validation
>results will not be anywhere near as effective as one based on a large
>network or even crowd-sourced view.  Network-based inputs such as
>complaints, submissions of unwanted voicemail, call volumetrics, calling
>graphs, reputation of the originating service provider, reputation of the
>originating TN, account history, call completion records and call
>durations are important.  Privacy considerations make many of these
>inputs  difficult to crowd source.  And these inputs are difficult to
>provide to an endpoint even with new standards, but could be conveyed
>either as an aggregate score or individual parameters.  Endpoint policy
>enforcement should of course be supported, but we should recognize that
>network-based enforcement is in practice the most widely adopted and
>effective policy enforcement
>  implementation (e.g., in email and SMS spaces).
>
>	* a validated originating service provider assertion of the originating
>TN.  (Note:  this might be provided to networks but not endpoints in
>cases where caller ID is masked.)
>Operational considerations are the primary barrier to STIR implementation
>-- what's easy to create in a lab may take many years and thousands of
>servers to be implemented in a complex telco production environment.
>STIR should consider these as dominant drivers.  It is much more
>practical for a telco to manage a dozen or so of its private-public key
>pairs than to create and manage a per-TN (> 100M TNs in the case of some
>carriers) certificate infrastructure.  Adding a per-call database dip or
>per-TN cache is a huge impact.
>
>Public key distribution to carriers can be accomplished using some
>existing lookup-based registry, and/or via attached certificates.  Using
>a registry already accessible to policy/routing engines is IMHO more
>practical in a service provider environment.
>
>Regards,
>
>Alex
>
>
>
>>justification in this

---

From: Richard Shockey <[email-masked]>
Date: Thu, 30 Jul 2015 12:13:48 -0400

<sigh>

>world that is coming, as far as I can tell.

This is what I profoundly object to. The attempt to impose by IETF
protocol a policy on how carrier networks should operate in the future.
Its policy by stealth and it needs to stop right now. Code is NOT law. Its
certainly not a R&O.  Our concern should focus on what is the optimal
deliverable on the wire today and we will see in the future how networks
evolve. The problem TODAY lies in the traditional trust model between
service providers that we know is broken. There are clearly tools to
address that now and in the future we can build from success.

As for the operational issue there is little or no empirical evidence that
the future is going to be structured all that different from what we see
today.   The PSTN model of interconnected ³any to any² model, in large
part mediated by carriers, continues to have real and demonstrable
consumer enterprise value. We have swapped out SIP for TD/SS7 ok some
progress.  Contrary to popular opinion its a very good business. Its the
reason we have iPhones and not iPods as the dominant end user device model.

If SIP URI's were the dominant addressing model for real time
communications we would not be having this conversation.  The SMS service
totally crushed instant messaging due to its interconnected model.  I
should have hats made up  NO SILO.  Facebook might be a phone company in
the future.  Now they can get their own E.164 blocks but they will play by
PSTN policy that is not made here.  Don¹t even get me started on WEBRTC.

I don¹t know what world you see in your crystal ball but you might double
check if its cracked or not.

I¹m open minded on the per TN cert issue. So long as the chain of trust is
very very clear it could be a manageable problem. There are sound reasons
for doing that but even how that deploys will not be decided here.

I would like someone to explain when we might see a consensus on 4474bis
so some of us could try and build a proof of concept and move on to
something that can be deployed.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 30 Jul 2015 16:52:33 +0000

On 7/30/15, 9:13 AM, "Richard Shockey" <[email-masked]> wrote:

>
><sigh>
>
>><snip>
>> But in STIR we're defining what goes on the wire, and
>><snip>

And what I profoundly object to is this sort of cynical misrepresentation
of the work here, in light of the fact that what I wrote (excerpted above)
says the opposite of what you are claiming.

But more particularly, the crisis of spoofing today does not result from
traditional carrier handoffs. It comes from the fact that the Internet and
PSTN have interconnected in ways that have made many parties other than
traditional carriers responsible for attesting numbers. That is the
reality on the ground today, not a prophecy about the future. STIR tries
to address that reality head-on. Saying that we should reduce its scope to
1980s PSTN interconnection is woefully short-sighted, and bluntly has no
place in a serious discussion about resolving the problem of spoofing.

Jon Peterson
Neustar, Inc.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Jul 2015 19:12:25 +0000

I think it's helpful to describe specific deployment scenarios and their trade-offs - not to pick one, but to make sure we have one or more plausible systems stories. I would advise caution when discussions arise that seem to favor a "club" of large carriers and that disadvantage smaller carriers or entities. Anti-trust lawyers don't like that, I've been told.

If we get back down from philosophy to engineering, we seem to be discussing three different models (leaving CRL/revocation aside):

(1) A "wildcard" model: An entity signs with a private key that's part of a certificate for all numbers. Essentially, this simply says "this call originated by Carrier A". Maybe you'd get the cert along with the OCN from NECA.

(2) A "multi-TN-per-cert" model: The cert applies to ten to (maybe) hundred numbers, enumerated or identified by range/prefix. If number porting is frequent, this means that either the certs become over-inclusive (which may not be a major problem) or need to be re-issued. Example: with a typical mobile churn rate of around 2% per month (http://www.statista.com/statistics/283511/average-monthly-churn-rate-top-wireless-carriers-us/), a ten-TN cert would have a 19% chance each month of being incorrect.

(3) A single-TN per cert model.

The number of public-private key pairs is independent of the choice, as mentioned by Richard B.

If certs are delivered out-of-band, caching determines the number of HTTP servers needed. #1 will have near-perfect hit ratios (unless carriers use lots of certs), #3 will have a poor hit ratio, particularly if the OCSP object is stapled on and part of the cache. #2 will be somewhere in-between. The alternative is to do what it's being done for LRN lookup, i.e., download the cert database and pub-sub updates. For 800M US numbers, we're talking 800 GB of data for model #3, or about 100 GB a day with OCSP or 1 GB/day with 2 year cert lifetime and some other (e.g., pub-sub) invalidation mechanism.

Obviously, the three models can co-exist.

Random googling claims that there are 3 B calls in the US per day. A significant fraction is likely within the same carrier or may otherwise not require validation or downloading (e.g., because of caching), so this is an upper bound for our purpose. According to

https://wrongsideofmemphis.wordpress.com/2013/10/21/requests-per-second-a-reference/

2,000 RPS are "is a decent amount of load for a normal server for a regular service."

This translates to roughly 0.2 B requests per server per day, so for all of the US, across all carriers, we're talking 15 servers. (As noted, cert retrieval is a trivial static file/object download, so this doesn't seem unrealistic even without custom-designed stacks.) My guess is that SBCs and cert servers will be paired in practice, for a variety of logistical, network access (e.g., VPN) and fate-sharing reasons, but that's obviously an implementation detail.

If a carrier needs hundreds of servers for cert delivery, they may want to check if they are still hoarding 3B2's.

(There is obviously separate overhead for SIP request signing and validation, but that doesn't depend on the model #1, #2 or #3, just on key lengths and algorithm.)

My back of the envelope is full, but I'm sure others can add more.

Henning

________________________________________
From: Peterson, Jon <[email-masked]>
Sent: Thursday, July 30, 2015 11:27 AM
To: Alex Bobotek; Richard Barnes; Stephen Farrell
Cc: [email-masked]; Gorman, Pierce A [CTO]; PFAUTZ, PENN L; Richard Shockey; Henning Schulzrinne
Subject: Re: [stir] On OCSP, TNs, and Privacy

Jon Peterson
Neustar, Inc.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 30 Jul 2015 21:21:31 +0000

Jon,

I didn't follow what you meant in your phrase, " Yes, STIR treats a more complex world operationally than the effectively closed network of the PSTN..."

Can you perhaps explain a little more what you meant there?

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: July 30, 2015 10:27 AM
To: Alex Bobotek <[email-masked]>; Richard Barnes <[email-masked]>; Stephen Farrell <[email-masked]>
Cc: [email-masked]; Gorman, Pierce A [CTO] <[email-masked]>; PFAUTZ, PENN L <[email-masked]>; Richard Shockey <[email-masked]>; Henning Schulzrinne <[email-masked]>
Subject: Re: [stir] On OCSP, TNs, and Privacy

I don't think those properties are very different from what RFC3325 provides. If all you care about is that someone you deem a "network operator" has asserted the originating TN, then PAI is surely adequate.

The scope of STIR is different, however. We are considering a more pluralist world, after the IP transition, wherein a somewhat messy mixture of network operators, enterprises, and even end users could hold credentials that let them sign telephone calls. In that environment, the credentials need to reflect more than just the identity of the signer:
they need to reflect number assignment itself.

Personally, I agree that in this world I would not want to require holders of large number blocks (carriers) to have a cert per TN. And I totally agree that in that world, it would make sense for carrier policies to involve mutual trust that is based on the subject of certificates rather than the TNAuthList. But in STIR we're defining what goes on the wire, and in the certs, rather than the particulars of operator policy. We're providing mechanisms that will help in the messier cases, which may not need to be exercised in cases that look more like traditional PSTN operator handoffs.

Yes, STIR treats a more complex world operationally than the effectively closed network of the PSTN, which RFC3325 tries to emulate. But it is the world that is coming, as far as I can tell.

Jon Peterson
Neustar, Inc.

On 7/29/15, 11:50 AM, "Alex Bobotek" <[email-masked]> wrote:

>complaints, submissions of unwanted voicemail, call volumetrics,
>calling graphs, reputation of the originating service provider,
>reputation of the originating TN, account history, call completion
>records and call durations are important.  Privacy considerations make
>many of these inputs  difficult to crowd source.  And these inputs are
>difficult to provide to an endpoint even with new standards, but could
>be conveyed either as an aggregate score or individual parameters.
>Endpoint policy enforcement should of course be supported, but we
>should recognize that network-based enforcement is in practice the most
>widely adopted and effective policy enforcement
>* a validated originating service provider assertion of the
>originating TN.  (Note:  this might be provided to networks but not
>endpoints in cases where caller ID is masked.) This provides much
>needed technical information and accountability for technical and
>non-technical enforcement.
>
>carriers) certificate infrastructure.  Adding a per-call database dip
>or per-TN cache is a huge impact.
>
>existing lookup-based registry, and/or via attached certificates.
>Using a registry already accessible to policy/routing engines is IMHO
>more practical in a service provider environment.
>
>Regards,
>
>Alex
>
>
>
>> >> You are correct that if we build a putative security solution
>> >> based on public keys passed DNS, it will not be an IETF protocol.
>> >> It will not become an RFC because it will not meet the IETF's
>> >> security
>>standards.
>> >

---

From: Richard Shockey <[email-masked]>
Date: Thu, 30 Jul 2015 19:37:30 -0400

Fair enough but the club here,for the time being, are the entities that
have been assigned telephone numbers by a duly constituted National
Numbering Authority.

That is where I would suggest the trust model begins and as the network
evolves we can look at how other assignees deal with the model. So where
is the trust anchor?  We are not going to decide that issue here. And
Brian has a point in that we can look at a Forrest Guide if this gets
complicated.

 I¹ve always felt we had a much simpler problem in securing the numbering
plan
since the trust anchor could be mandated by the relevant NRA.

Absolute power is sometimes sometimes absolutely fabulous.

This was always a multi faceted problem that required a multi faceted
solution. 

Part one got solved with the recent FCC order that gave the carriers the
legal right ( safe harbor ) to block a call given a clear and explicit
request from the consumer or the enterprise.  This is where several
National Regulatory Authorities want to go.

The second part was creating the tools to actually examine the INVITE to
validate the origin of the call.That is the STIR problem. BTW this is only
applicable to a transitioned networks.  If anyone believes this is going
to work for existing TDM networks the need to consult their drug
counsellors. It will not happen.

The third was the display to the consumer of information on call origin
and reputation data from the validation process in order for the called
party to to make a informed decision on whether to accept the session.

This still includes all smaller carriers and all sorts of folks, or at
least that is what I read into the recent R&O. Look at the chain of trust.
 I see no technical impediment to having 3rd party¹s manage various
aspects of this system for those SP that do not have the resources to
manage this. 

In SIDR the RPKI trust model begins with the
RIR¹s and flows accordingly. So far it seems to work though implementation
is voluntary. I have good reason to believe there is a strong core among
NA carriers that 
actually wants to do something. Its willing to make the investment if the
deployment scenarios is not deplorable.(pun intended)

Granted its been a while since I was a WG chair around here but I don¹t
see the kind of open, multi-stakeholder consensus driven process that
leads to deployable cost effective solutions.

I emphasize multi-stakeholder and we know who the stake holders are and
consensus. And someone presumably has to
get a budget to get any of this deployed so as usual ³Money is the answer
what is the question?²  applies.

Jon if you want to be part of the solution and not the problem itself then
you have to reengage.

This whole discussion looks like something I¹d see out of the US Congress.

On 7/30/15, 3:12 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>I think it's helpful to describe specific deployment scenarios and their
>trade-offs - not to pick one, but to make sure we have one or more
>plausible systems stories. I would advise caution when discussions arise
>that seem to favor a "club" of large carriers and that disadvantage
>smaller carriers or entities. Anti-trust lawyers don't like that, I've
>been told.
>
>If we get back down from philosophy to engineering, we seem to be
>discussing three different models (leaving CRL/revocation aside):
>
>(1) A "wildcard" model: An entity signs with a private key that's part of
>a certificate for all numbers. Essentially, this simply says "this call
>originated by Carrier A". Maybe you'd get the cert along with the OCN
>from NECA.
>
>(2) A "multi-TN-per-cert" model: The cert applies to ten to (maybe)
>hundred numbers, enumerated or identified by range/prefix. If number
>porting is frequent, this means that either the certs become
>over-inclusive (which may not be a major problem) or need to be
>re-issued. Example: with a typical mobile churn rate of around 2% per
>month 
>(http://www.statista.com/statistics/283511/average-monthly-churn-rate-top-
>wireless-carriers-us/), a ten-TN cert would have a 19% chance each month
>of being incorrect.
>
>If certs are delivered out-of-band, caching determines the number of HTTP
>servers needed. #1 will have near-perfect hit ratios (unless carriers use
>lots of certs), #3 will have a poor hit ratio, particularly if the OCSP
>object is stapled on and part of the cache. #2 will be somewhere
>in-between. The alternative is to do what it's being done for LRN lookup,
>i.e., download the cert database and pub-sub updates. For 800M US
>numbers, we're talking 800 GB of data for model #3, or about 100 GB a day
>with OCSP or 1 GB/day with 2 year cert lifetime and some other (e.g.,
>pub-sub) invalidation mechanism.
>
>Random googling claims that there are 3 B calls in the US per day. A
>significant fraction is likely within the same carrier or may otherwise
>not require validation or downloading (e.g., because of caching), so this
>is an upper bound for our purpose. According to
>
>This translates to roughly 0.2 B requests per server per day, so for all
>of the US, across all carriers, we're talking 15 servers. (As noted, cert
>retrieval is a trivial static file/object download, so this doesn't seem
>unrealistic even without custom-designed stacks.) My guess is that SBCs
>and cert servers will be paired in practice, for a variety of logistical,
>network access (e.g., VPN) and fate-sharing reasons, but that's obviously
>an implementation detail.
>
>If a carrier needs hundreds of servers for cert delivery, they may want
>to check if they are still hoarding 3B2's.
>
>(There is obviously separate overhead for SIP request signing and
>validation, but that doesn't depend on the model #1, #2 or #3, just on
>key lengths and algorithm.)
>
>>originating

---

From: Alex Bobotek <[email-masked]>
Date: Thu, 30 Jul 2015 15:27:43 -0700

Jon,

The basic STIR requirements require a trusted identity assertion at or near origination that can be validated at or near termination.  While the concept of PAI is close (and IHMO is very useful in many but an insufficient number of existing scenarios), I do not see how it can provide the needed functionality.  I see that you are one of the authors of RFC3325 and undoubtedly have a better understanding than I of it.  So if I don't understand, I hope you will set me straight.  Here are some issues I see with PAI as defined in standards:

The Boolean trust model assumed in RFC3325 and removal/replacements specified in RFC3325 prevent conveyance of information from originating to terminating service providers.  PAI may not traverse proxies, and may not identify the originating provider by the time it reaches a terminating provider.  Cryptographic signatures rather than chains of trust seem to be the most feasible solution.  

Further, we IMHO need a system that allows for and is interoperable with identity assertions made by a party other than a service provider.  

Regards,

Alex
> Sent: Thursday, July 30, 2015 8:27 AM
> To: Alex Bobotek <[email-masked]>; Richard Barnes <[email-masked]>;
> Stephen Farrell <[email-masked]>
> Cc: [email-masked]; Gorman, Pierce A [CTO] <[email-masked]>;
> PFAUTZ, PENN L <[email-masked]>; Richard Shockey
> <[email-masked]>; Henning Schulzrinne <[email-masked]>
> I don't think those properties are very different from what RFC3325 provides.
> If all you care about is that someone you deem a "network operator" has
> asserted the originating TN, then PAI is surely adequate.
> 
> The scope of STIR is different, however. We are considering a more pluralist
> world, after the IP transition, wherein a somewhat messy mixture of
> network operators, enterprises, and even end users could hold credentials
> that let them sign telephone calls. In that environment, the credentials need
> to reflect more than just the identity of the signer:
> Personally, I agree that in this world I would not want to require holders of
> large number blocks (carriers) to have a cert per TN. And I totally agree that
> in that world, it would make sense for carrier policies to involve mutual trust
> that is based on the subject of certificates rather than the TNAuthList. But in
> STIR we're defining what goes on the wire, and in the certs, rather than the
> particulars of operator policy. We're providing mechanisms that will help in
> the messier cases, which may not need to be exercised in cases that look
> more like traditional PSTN operator handoffs.
>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 31 Jul 2015 01:48:34 +0000

Not correct

Sent from my iPhone

> On Jul 30, 2015, at 9:38 PM, Alex Bobotek <[email-masked]> wrote:
> 
> Jon,
>

---

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

Jon,

1. I'll do my best to help STIR get implemented when it is either required by mandate or just to remain relevant.

2. I personally think STIR will be an expensive, painful, and futile game of wack-a-rat (especially thanks to buying computing resources in the cloud using a credit card and the MODERN WG assuming they will be "successful" in their attempts to bypass traditional policy development and automate provisioning of TNs over the Inernet at the user and non-carrier levels).

3. I think it would be cheaper and more effective for carriers to remind their customers not to trust anyone who calls them that they don't personally know (and maybe not some of them either).

The real danger to consumers is not telephone calls with an unauthenticated calling ID.  The real threat is from the monumental tsunami of bad behavior on non-voice Internet-based communications.  Firewalls, SPAM filters, virus protection software, honey-pots and AUTHENTICATION and encryption protocols have regularly failed to prevent phishing, pharming, intrusion, and truly staggering amounts of theft and misuse of credit card, identity, and other personal information, including the most recent egregious example of the cyberattack on the US Federal Government's Office of Personnel Management which acquired sensitive information on every single US federal employee (including Henning?).

I'm not wishing for the days of the 1980s telephone network.  I'm looking forward to the days when folks finally realize the Internet is the Wild West of the 1880s.

I know none of this is helpful in your quest to develop a useless protocol, but saying it anyway.

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Alex Bobotek [mailto:[email-masked]]
Sent: July 30, 2015 5:28 PM
To: Peterson, Jon <[email-masked]>; Richard Barnes <[email-masked]>; Stephen Farrell <[email-masked]>
Cc: [email-masked]; Gorman, Pierce A [CTO] <[email-masked]>; PFAUTZ, PENN L <[email-masked]>; Richard Shockey <[email-masked]>; Henning Schulzrinne <[email-masked]>
Subject: RE: [stir] On OCSP, TNs, and Privacy

Jon,

Regards,

Alex
> PFAUTZ, PENN L <[email-masked]>; Richard Shockey <[email-masked]>;
> Henning Schulzrinne <[email-masked]>
> If all you care about is that someone you deem a "network operator"
> has asserted the originating TN, then PAI is surely adequate.
>
> pluralist world, after the IP transition, wherein a somewhat messy
> mixture of network operators, enterprises, and even end users could
> hold credentials that let them sign telephone calls. In that
> environment, the credentials need to reflect more than just the identity of the signer:
> Personally, I agree that in this world I would not want to require
> holders of large number blocks (carriers) to have a cert per TN. And I
> totally agree that in that world, it would make sense for carrier
> policies to involve mutual trust that is based on the subject of
> certificates rather than the TNAuthList. But in STIR we're defining
> what goes on the wire, and in the certs, rather than the particulars
> of operator policy. We're providing mechanisms that will help in the
> messier cases, which may not need to be exercised in cases that look more like traditional PSTN operator handoffs.
>
> Yes, STIR treats a more complex world operationally than the
> effectively closed network of the PSTN, which RFC3325 tries to
> emulate. But it is the world that is coming, as far as I can tell.
>
> Jon Peterson
> Neustar, Inc.
>
> >results will not be anywhere near as effective as one based on a
> >large network or even crowd-sourced view.  Network-based inputs such
> >as complaints, submissions of unwanted voicemail, call volumetrics,
> >records and call durations are important.  Privacy considerations
> >make many of these inputs  difficult to crowd source.  And these
> >inputs are difficult to provide to an endpoint even with new
> >standards, but could be conveyed either as an aggregate score or individual parameters.
> >should recognize that network-based enforcement is in practice the
> >most widely adopted and effective policy enforcement
> >-- what's easy to create in a lab may take many years and thousands
> >of servers to be implemented in a complex telco production environment.
> >practical for a telco to manage a dozen or so of its private-public
> >key pairs than to create and manage a per-TN (> 100M TNs in the case
> >of some
> >> Cc: Henning Schulzrinne <[email-masked]>;
> >> [email-masked]; Gorman, Pierce A [CTO] <[email-masked]>;
> >> <[email-masked]>
> >> > Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e.
> >> > not a Proposed Standard) that does exactly that and that is in
> >> > That is ok in that context because a bad signature is the same as
> >> > a missing signature.
> >> >
> >> > If this WG wanted to use a DKIM-like solution and could justify
> >> > the lack of 3rd party cryptographic binding between the TN and
> >> > the public key, that could be entirely analogous.
> >> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 31 Jul 2015 16:42:09 +0000

Just today, I came across

http://www.usatoday.com/story/money/columnist/tompor/2015/07/23/irs-scam-calls-and-threats-heat-up-summer/30575555/

which provides some real-life context for our work. I'm sure the victims would appreciate your advice just to be smarter.

Henning

________________________________________
From: Gorman, Pierce A [CTO] <[email-masked]>
Sent: Friday, July 31, 2015 12:26 PM
To: Alex Bobotek; Peterson, Jon; Richard Barnes; Stephen Farrell
Cc: [email-masked]; PFAUTZ, PENN L; Richard Shockey; Henning Schulzrinne
Subject: RE: [stir] On OCSP, TNs, and Privacy

Jon,

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

---

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

Henning,

What in an authenticated Calling ID will prevent these calls from happening?  (By the way, I've received one of the IRS variety and another on my work phone that looked like it was the US but was most likely from India.)

Pierce

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: July 31, 2015 11:42 AM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

Henning

Jon,

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 31 Jul 2015 17:03:58 +0000

I am serious about my role and effort to get STIR implemented in our network.  When it comes time, for whatever reasons, I will be a staunch advocate of getting it done (not kidding).  Just because I personally don't like it doesn't mean I won't work hard to get it done anyway.  This won't the first example of such an effort.

OK to get back on target and try to be helpful (really).

In our network I would favor a centralized and cached approach to applying call admission policy using STIR and other information.  I don't assume and would not want user equipment dipping and validating anything. (A few hundred semi-centralized platforms doing signaling and processing is fun enough, let alone multiplying a handful of messages by 10s of millions during the busy hour).  I would prefer the network provided the endpoint an in-call-setup indication of authenticated, or not.

Some policy questions (that I know won't be answered here - but that I will risk proposing anyway) is what should be the safe-harbor practice(s) for carriers which block calls based on a user opt-in of call blocking on non-authenticated calling ID?  Should they signal to the user that the call was blocked and provide them the telephone number?  Should they place a record in their monthly bill?  Should they do something akin to a 3-way call where they accept the call, place it on hold, setup a leg to the called party, and let them decide to accept the risk of answering an unauthenticated call?

No answers required.  Just food for thought and by way of response to folks who think implementing STIR will be "cheap".  Perhaps they'd like to setup a fund to help pay for the specialized call signaling treatment, media anchoring, fault and performance management and reporting, and billing capture, development and operational costs?  (And yes, all that and without preventing bad behavior and presumably without being able to charge a premium for the placebo service.)

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

-----Original Message-----
From: Gorman, Pierce A [CTO]
Sent: July 31, 2015 11:44 AM
To: 'Henning Schulzrinne' <[email-masked]>
Cc: [email-masked]
Subject: RE: [stir] On OCSP, TNs, and Privacy

Henning,

Pierce

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: July 31, 2015 11:42 AM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

Henning

Jon,

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 31 Jul 2015 17:09:33 +0000

The article doesn't go into details, but two ways:

(1) We know that some of the fraudulent callers spoof local law enforcement or IRS numbers to increase the chances of being believed. STIR wouldn't prevent the calls, but reduce the chance of success.

(2) As we have discussed, call filtering only works reliably if the filter can trust the caller ID. (Otherwise, if call filtering becomes more common, the bad guys will use even more spoofing than today.)

Thus, I see the STIR work as a necessary ingredient to make call filtering effective, which will in turn make the job of the bad guys much harder and more expensive. (If they have to get a legitimate new number for every call or every ten calls, their business model is likely to break down.)

Henning

________________________________________
From: Gorman, Pierce A [CTO] <[email-masked]>
Sent: Friday, July 31, 2015 12:44 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [stir] On OCSP, TNs, and Privacy

Henning,

Pierce

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: July 31, 2015 11:42 AM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

Henning

Jon,

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 31 Jul 2015 17:16:37 +0000

If/when you're successful in MODERN, your last paragraph will be wrong starting at, "make the job of the bad guys much harder...".

I think MODERN will make it trivial for them to cheaply get all the authenticated numbers they want and impossible to track what got done with them.

I think you're right about spoofing cutting down on spoofing law enforcement and IRS numbers but how much will that matter?  I don't know know my local law enforcement telephone numbers or any IRS numbers.  And FWIW, there is a huge regional IRS processing center in Kansas City so I could get an authenticated call from just about anybody in the 816 area code and for all I would know they really were with the IRS.

Respectfully,

Pierce Gorman

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: July 31, 2015 12:10 PM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

Henning

Henning,

Pierce

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: July 31, 2015 11:42 AM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

Henning

Jon,

Best regards,

Pierce Gorman
Core Network Planning
O: 913-439-4368
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 31 Jul 2015 17:36:02 +0000

I don't want to get into policy issues and this isn't the MODERN list, but "availability" and "cheap" aren't necessarily coupled. Because of issues of number utilization and "hoarding" in the 800 number space, a number of people in the policy space are well aware of these issues.

________________________________________
From: Gorman, Pierce A [CTO] <[email-masked]>
Sent: Friday, July 31, 2015 1:16 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [stir] On OCSP, TNs, and Privacy

Respectfully,

Pierce Gorman

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 31 Jul 2015 17:37:57 +0000

Usually, it's the mapping to CNAM that fools people, not the number itself.

Respectfully,

Pierce Gorman

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 31 Jul 2015 17:43:37 +0000

Agree - and getting a handle on authenticated CNAM information is another can of worms we've discussed before and actually adds to my frustration.

I'll throw Richard Shockey under the bus (a little) by saying his excellent comments caused me to feel the need to vent some pent up frustration.

I'll quit fussing (for now) and try to limit my comments to items I will hope are helpful for protocol development.

Respectfully,

Pierce Gorman

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: July 31, 2015 12:38 PM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] On OCSP, TNs, and Privacy

Respectfully,

Pierce Gorman