Subject: [stir] current draft charter

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2013 01:02:59 +0000

Below is the current draft of the charter, based on our prior discussions.

Jon Peterson
Neustar, Inc.

----

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

Chairs: TBD
Area Advisor: TBD (Barnes)

Mailing list: (current source-auth)
To Subscribe: --

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. Many of these problems are familiar from our experience with email: bulk unsolicited commercial communications remain a challenge for the traditional telephone network largely because the source of calls can be hidden. Others are potentially more serious: voicemail hacking, impersonating banks and similar attacks are becoming commonplace. The technologies that obscure the caller’s identity are frequently gateways between the telephone network and the Internet.

SIP is one of the main VoIP technologies employed by these gateways. A number of previous efforts have attacked the problem of securing the origins of SIP communications, including RFC3325, RFC4474 and the VIPR WG. To date, however, true cryptographic authentication of the source of SIP calls has not seen any appreciable deployment. While several factors contributed to this lack of success, two seem like the largest culprits: 1) the lack of any real means of asserting authority over telephone numbers on the Internet; and 2) a misalignment of the integrity mechanisms proposed by RFC4474 with the highly interworked, mediated and policy-driven deployment environment that has emerged for SIP. The VIPR alternative, while promising, faced apparently unavoidable privacy problems and other significant deployment hurdles.

Given the pressing difficulties caused by the lack of a useful identity solution, the problem of securing the origins of SIP communication must be revisited. Because SIP deployments are so closely tied to the telephone network, we moreover must investigate solutions that can work when one side of a call is in the PSTN – or potentially even both. This will require a two-pronged approach: one prong relying on information carried in SIP signaling; the other prong relying on forming out-of-band connections between IP endpoints that are participating in a call.

The changes to the RFC4474 approach to SIP signaling must include a new capability for Identity assertions to cover telephone numbers, rather than domain names. To conform with realistic deployments, we must also study ways to rebalance the requirements for the scope of RFC4474’s integrity protection to emphasize preventing third-party impersonation over preventing men-in-the-middle from capturing media.

Finally, the solution must encompass an out-of-band means for endpoints to establish identity when there is no direct SIP signaling path between them available, due to interworking or similar factors. This working group will investigate a means for Internet endpoints to discover one another in real time to verify that a telephone call between them is in progress based on minimal evidence or configuration. This architecture will, to the degree that is possible, reuse the credentials defined for telephone numbers for the in-band signaling solution, and define a discovery mechanism that provides better than hop-by-hop security.

The working group will coordinate with the security area on certificate management.

The working group will coordinate with RAI area groups studying the problem of signaling through existing deployments, including INSIPID.

Identity is closely linked to privacy, and frequently one comes at the cost of the other. This working group is not chartered to mandate the presence of identity in SIP requests, and to the extent feasible it will find privacy-friendly solutions that leak minimal information about calls to third parties.

The working group will deliver the following:

- A problem statement detailing the deployment environment and difficulties motivate work on secure origins

- A revision to SIP’s identity features to provide several fixes:
    Changes to support certification for telephone numbers
    Changes to the signature

- A document describing the certificate profile required to support telephone numbers in certificates

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

Milestones

Sep 2013   Submit problem statement for Info
Nov 2013   Submit RFC4474bis for PS
Jan 2013   Submit TN cert profile for Info
Mar 2014   Submit fallback for PS

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Jun 2013 02:46:40 +0100

So based on many recent mails, I'd suggest adding "and threat model"
to the problem statement deliverable and s/certificate/key management/g
might be better so as not to preclude a non-certificate based
solution.

And one near-nit: I think the term "identity" generates quite a bit
of confusion and its generally better to talk about identifiers and
not identities. In other cases that's more of a deal but since we're
only dealing with phone numbers here its almost a nit.

Cheers,
S.

On 06/12/2013 02:02 AM, Peterson, Jon wrote:
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2013 02:28:58 +0000

>might be better so as not to preclude a non-certificate based

Fine with adding a threat model to the problem statement.

And non-certificate based key management solutions are in scope, sure.
RFC4474bis lists in its action items studying how to point at DANE from
the Identity-Info header, and this could extend to alternatives for
credentials in the DNS. Ironically, back when we wrote RFC4474, we assumed
there would be keys in public ENUM and that we'd solve the problem this
way eventually. Lack of public ENUM (and to a lesser extent, tardiness of
DNSSEC) back-burnered that plan. I'm personally less concerned about the
syntax of the credentials than the authority structures behind them.

>only dealing with phone numbers here its almost a nit.

I hesitate to back out the term "identity" given that it's what we've used
for more than ten years for this. The header even in RFC4474 is called
Identity. The RFC3325 header is P-Asserted-Identity. I hear what you're
saying - this signature is over an identifier - but it's pretty clear that
this identifier serves as an identity. The calling TN, or a derivative
from it, is what telephony UIs show their users when alerting for an
incoming call. Whether CNAM does it in the PSTN, or your address book does
on your smart phone, applications translate callings TNs into proper names
of various kind to represent callers. To secure calling TNs is to secure
the identity of the caller.

Jon Peterson
Neustar, Inc.

>> Over the last decade, a growing set of problems have resulted from the
>>lack of security mechanisms for attesting the origins of real-time
>>communications. Many of these problems are familiar from our experience
>>with email: bulk unsolicited commercial communications remain a
>>challenge for the traditional telephone network largely because the
>>source of calls can be hidden. Others are potentially more serious:
>>voicemail hacking, impersonating banks and similar attacks are becoming
>>commonplace. The technologies that obscure the caller¹s identity are
>>frequently gateways between the telephone network and the Internet.
>> 
>> SIP is one of the main VoIP technologies employed by these gateways. A
>>number of previous efforts have attacked the problem of securing the
>>origins of SIP communications, including RFC3325, RFC4474 and the VIPR
>>WG. To date, however, true cryptographic authentication of the source of
>>SIP calls has not seen any appreciable deployment. While several factors
>>contributed to this lack of success, two seem like the largest culprits:
>>1) the lack of any real means of asserting authority over telephone
>>numbers on the Internet; and 2) a misalignment of the integrity
>>mechanisms proposed by RFC4474 with the highly interworked, mediated and
>>policy-driven deployment environment that has emerged for SIP. The VIPR
>>alternative, while promising, faced apparently unavoidable privacy
>>problems and other significant deployment hurdles.
>> 
>> Given the pressing difficulties caused by the lack of a useful identity
>>solution, the problem of securing the origins of SIP communication must
>>be revisited. Because SIP deployments are so closely tied to the
>>telephone network, we moreover must investigate solutions that can work
>>when one side of a call is in the PSTN  or potentially even both. This
>>will require a two-pronged approach: one prong relying on information
>>carried in SIP signaling; the other prong relying on forming out-of-band
>>connections between IP endpoints that are participating in a call.
>> 
>> The changes to the RFC4474 approach to SIP signaling must include a new
>>capability for Identity assertions to cover telephone numbers, rather
>>than domain names. To conform with realistic deployments, we must also
>>study ways to rebalance the requirements for the scope of RFC4474¹s
>>integrity protection to emphasize preventing third-party impersonation
>>over preventing men-in-the-middle from capturing media.
>> 
>> Finally, the solution must encompass an out-of-band means for endpoints
>>to establish identity when there is no direct SIP signaling path between
>>them available, due to interworking or similar factors. This working
>>group will investigate a means for Internet endpoints to discover one
>>another in real time to verify that a telephone call between them is in
>>progress based on minimal evidence or configuration. This architecture
>>will, to the degree that is possible, reuse the credentials defined for
>>telephone numbers for the in-band signaling solution, and define a
>>discovery mechanism that provides better than hop-by-hop security.
>> 
>> The working group will coordinate with RAI area groups studying the
>>problem of signaling through existing deployments, including INSIPID.
>> 
>> Identity is closely linked to privacy, and frequently one comes at the
>>cost of the other. This working group is not chartered to mandate the
>>presence of identity in SIP requests, and to the extent feasible it will
>>find privacy-friendly solutions that leak minimal information about
>>calls to third parties.
>> 
>> - A problem statement detailing the deployment environment and
>>difficulties motivate work on secure origins
>> 
>> - A revision to SIP¹s identity features to provide several fixes:

---

From: <[email-masked]>
Date: Wed, 12 Jun 2013 09:50:48 +0000

Jon,

The only comment I would have is on the general phrasing of the first paragraph, which at least for an outsider, may sometimes seem to be focused on anonymous calls rather than on 'illegitimate' CPNs in general (whilst the "more serious" problems that are listed there have indeed more to do with the latter than the former). 

If this restriction is not deliberate, maybe you want to say "can be hidden or forged" instead of only "hidden" and "that obscure or falsify" as opposed to only "obscure".

Regards,

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Wednesday, June 12, 2013 3:03 AM
To: [email-masked]
Subject: [stir] current draft charter

Jon Peterson
Neustar, Inc.

----

Chairs: TBD

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. Many of these problems are familiar from our experience with email: bulk unsolicited commercial communications remain a challenge for the traditional telephone network largely because the source of calls can be hidden. Others are potentially more serious: voicemail hacking, impersonating banks and similar attacks are becoming commonplace. The technologies that obscure the caller's identity are frequently gateways between the telephone network and the Internet.

Given the pressing difficulties caused by the lack of a useful identity solution, the problem of securing the origins of SIP communication must be revisited. Because SIP deployments are so closely tied to the telephone network, we moreover must investigate solutions that can work when one side of a call is in the PSTN - or potentially even both. This will require a two-pronged approach: one prong relying on information carried in SIP signaling; the other prong relying on forming out-of-band connections between IP endpoints that are participating in a call.

The changes to the RFC4474 approach to SIP signaling must include a new capability for Identity assertions to cover telephone numbers, rather than domain names. To conform with realistic deployments, we must also study ways to rebalance the requirements for the scope of RFC4474's integrity protection to emphasize preventing third-party impersonation over preventing men-in-the-middle from capturing media.

- A revision to SIP's identity features to provide several fixes:
    Changes to support certification for telephone numbers
    Changes to the signature 

Milestones

_________________________________________________________________________________________________________________________

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

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

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Wed, 12 Jun 2013 11:52:19 +0200

Question on identifier usage:

Could one think about a model where the identifier "phone number" is asserted in the digest of the service request and signed by any authorized identity of the originating authority or user?

Identifier:        Authoritative Signee:
+1 xxx yyy zzzz    Signs private key of assigned 
                   or delegated certificate
                   This cert does not necessary need the 
                   phone number as a Cname or alt-cname

This would solve a number of issues discussed in various threats I think. It also would allow free binding to existing certificates and could avoid generating yet another cert for each phone number. 
We shall avoid ending up in the same lifetime management issues as we know from passwords today.

Willi

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Jun 2013 11:21:30 +0100

Hi Jon,

> Fine with adding a threat model to the problem statement.

Lovely.

> syntax of the credentials than the authority structures behind them.

That's a fair point. However, I'd argue that the difference between
a DKIM-like and RPKI-like approach is far from just syntax. For
example, in an RPKI-like approach the callee has to verify who
delegated what to whom in order to check the signature (e.g. via
5280 NameConstraints). With a DKIM-like approach, that's done in
some un- or differently-specified way by some infrastructure (before
making the public key available) and isn't directly visible to the
callee. That's definitely not just syntax I reckon.

> for more than ten years for this. 

I'm fine with that in this case. It'll probably come up though
so just as well to try get it out of the way:-)

S.

> The header even in RFC4474 is called

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Jun 2013 10:12:51 -0700

> callee. That's definitely not just syntax I reckon.

My simplistic description of the DKIM-like model is that the storage 
location constitutes the cert.

The semantic of the cert is "the owner of this location authorizes use 
of the key".  Since the 'location' is a place in the DNS, the owner of 
the domain name at that location is validating use of the private key.

For very simple cert semantics like this, it works.  Semantics that are 
more complex probably won't.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Jun 2013 13:23:47 -0400

The simple semantics sounds similar to the RFC 4744 model for SIP URIs. As discussed in various drafts, this model unfortunately doesn't work well for the domain-less case, such as telephone numbers.

On Jun 12, 2013, at 1:12 PM, Dave Crocker <[email-masked]> wrote:

> My simplistic description of the DKIM-like model is that the storage location constitutes the cert.
> 
> The semantic of the cert is "the owner of this location authorizes use of the key".  Since the 'location' is a place in the DNS, the owner of the domain name at that location is validating use of the private key.
> 
> For very simple cert semantics like this, it works.  Semantics that are more complex probably won't.
> 
> d/
> 
> -- 
> Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Jun 2013 10:40:23 -0700

> The simple semantics sounds similar to the RFC 4744 model for SIP URIs. As discussed in various drafts, this model unfortunately doesn't work well for the domain-less case, such as telephone number…

Not definitionally, no, but of course we know it can be encoded as one. 
  Ignoring the politics of that moves the discussion to a comparison of 
the choices among alternatives.

At a minimum, any solution here has to provide cert semantics, encoding 
and operation, query protocol and integrated server operation.  (There 
are probably some additional requirements, but these three will do for a 
start.)

My understanding of the requirements for cert semantics here is that 
it's pretty trivial.  Administering and enforcing it might not be, but 
the basic semantic quite simple.

New protocols are expensive and risky, even when built on top of a solid 
technical infrastructure.

We know that establishing a globally integrated set of server operations 
is risky to the point of being nearly impossible, based on a long 
history of many attempts and very, very few successes.

      (The word "integrated" is the challenge here -- the service being 
proposed here is for a unified number space; servers handling queries 
therefore need to compose into a unified service; for example this is 
quite different from fully independent web servers that might have 
pointers to each other.)

My suggestion is that any proposed solution be considered carefully for 
comparative effort and risk.  The challenge of course is to be fair to 
whatever choice isn't one's favorite.  Perhaps a cliche, but on the 
average we think the challenges for the choice we prefer are less than 
they actually are, and for non-favorites higher than they actually are.

d/

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2013 17:49:51 +0000

If I understand you correctly, I agree this is a model we should explore:
one where an authority over a number (like a carrier) could sign a
credential controlled by an end user, who then uses that delegated
authority to assert identity in a SIP request. While the end user cert, as
you say, conceivably might not have the phone number in its cname or
subjectAltName or what have you, relying parties could verify that the
credential that signed this end user cert does indeed have that authority
in scope.

I don't think anyone here expects a model where there would literally be a
new certificate for every telephone number, but in some use cases, having
a certificate for an individual telephone number might be appropriate. I
don't think we need to make this an either/or choice, though, both models
can coexist peaceably.

Jon Peterson
Neustar, Inc.

On 6/12/13 2:52 AM, "Wilhelm Wimmreuter" <[email-masked]> wrote:

>Could one think about a model where the identifier "phone number" is
>asserted in the digest of the service request and signed by any
>authorized identity of the originating authority or user?
>
>
>This would solve a number of issues discussed in various threats I think.
>It also would allow free binding to existing certificates and could avoid
>generating yet another cert for each phone number.
>>>WG. To date, however, true cryptographic authentication of the source
>>>of SIP calls has not seen any appreciable deployment. While several
>>>factors contributed to this lack of success, two seem like the largest
>>>culprits: 1) the lack of any real means of asserting authority over
>>>telephone numbers on the Internet; and 2) a misalignment of the
>>>integrity mechanisms proposed by RFC4474 with the highly interworked,
>>>mediated and policy-driven deployment environment that has emerged for
>>>SIP. The VIPR alternative, while promising, faced apparently
>>>unavoidable privacy problems and other significant deployment hurdles.
>>> 
>>> Given the pressing difficulties caused by the lack of a useful
>>>identity solution, the problem of securing the origins of SIP
>>>communication must be revisited. Because SIP deployments are so closely
>>>tied to the telephone network, we moreover must investigate solutions
>>>that can work when one side of a call is in the PSTN  or potentially
>>>even both. This will require a two-pronged approach: one prong relying
>>>on information carried in SIP signaling; the other prong relying on
>>>forming out-of-band connections between IP endpoints that are
>>>participating in a call.
>>> 
>>> The changes to the RFC4474 approach to SIP signaling must include a
>>>new capability for Identity assertions to cover telephone numbers,
>>>rather than domain names. To conform with realistic deployments, we
>>>must also study ways to rebalance the requirements for the scope of
>>>RFC4474¹s integrity protection to emphasize preventing third-party
>>>impersonation over preventing men-in-the-middle from capturing media.
>>> 
>>> Finally, the solution must encompass an out-of-band means for
>>>endpoints to establish identity when there is no direct SIP signaling
>>>path between them available, due to interworking or similar factors.
>>>This working group will investigate a means for Internet endpoints to
>>>discover one another in real time to verify that a telephone call
>>>between them is in progress based on minimal evidence or configuration.
>>>This architecture will, to the degree that is possible, reuse the
>>>credentials defined for telephone numbers for the in-band signaling
>>>solution, and define a discovery mechanism that provides better than
>>>hop-by-hop security.
>>> 
>>>presence of identity in SIP requests, and to the extent feasible it
>>>will find privacy-friendly solutions that leak minimal information
>>>about calls to third parties.
>>>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2013 18:22:50 +0000

Agreed. Though I do think that even for the domain model, we could get
some value from looking at DANE to improve the way that credentials are
managed. Whether we put the keys in the DNS or just point to the approved
cert by reference, we should probably have some means for the successor to
RFC4474 Identity-Info to tip off relying parties to DANE.

But yes, for the telephone model it seems unlikely that casting these as
domain names will get us very far.

Jon Peterson
Neustar, Inc.

On 6/12/13 10:23 AM, "Henning Schulzrinne" <[email-masked]> wrote:

>The simple semantics sounds similar to the RFC 4744 model for SIP URIs.
>As discussed in various drafts, this model unfortunately doesn't work
>well for the domain-less case, such as telephone numbers.
>

---

From: Dan York <[email-masked]>
Date: Wed, 12 Jun 2013 20:40:11 +0000

>RFC4474 Identity-Info to tip off relying parties to DANE.

Agreed (as you would expect me to say). I've been thinking about how DANE
could help here, but...

>domain names will get us very far.

... I think this issue will get in the way right now.  As much as I would
love to see this as a good example of where DANE can help, I still haven't
been able to wrap my brain around how we could use DNS for telephone
numbers without running into all the exact same issues that made public
ENUM non-deployable.  :-(

I agree, though, that it would be helpful to have some way for a header to
alert relying parties to DANE in the event that there is a way it can work.

Dan

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Jun 2013 14:38:55 -0700 (PDT)

> numbers without running into all the exact same issues that made public

That begs the question of what issues you think made Public ENUM fail, and why we won't hit the same issues in whatever model we choose.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Jun 2013 14:42:12 -0700

> That begs the question of what issues you think made Public ENUM fail, and why we won't hit the same issues in whatever model we choose.

+1

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Jun 2013 14:42:36 -0700

+1

d/

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2013 22:01:10 +0000

It's always hard to say with any certainty why something failed. We can
point to various causes and effects, one of which in this case certainly
would be the difficulty of getting every world government to implement the
system. ENUM was also designed from the start to empower end users to
control how their numbers would be associated with Internet services, yet
because of its built-in regulatory structures it required that empowerment
to be driven by carriers with different interests.

But we don't even have to be asking ourselves about the relevance of
public ENUM to the proposed work here in STIR unless we want to try to
base everything on keying in the public DNS for telephone numbers. There
are other models for this that don't have the liabilities I described
above, anyway. Keying in private DNS is more viable, for example. I think
a PKI is more viable.

Securing the origin of calls is a different problem than providing a
global routing directory, and we'd be wise not to muddle them together.

Jon Peterson
Neustar, Inc.

On 6/12/13 2:42 PM, "Dave Crocker" <[email-masked]> wrote:

>> That begs the question of what issues you think made Public ENUM fail,
>>and why we won't hit the same issues in whatever model we choose.
>
>
>+1
>
>
>d/
>
>
>-- 
>Dave Crocker

---

From: Brian Rosen <[email-masked]>
Date: Wed, 12 Jun 2013 18:02:33 -0400

1. the "global root" problem - who owns and manages e164.arpa, and what are the rules?
2. It took action by the regulator before anything happened.  Because many regulators didn't understand what this thing was, and still don't, they didn't act
3. It took a level of cooperation between service providers who owned parts of the hierarchy that could not be gained
4. Any public database that was able to show any information about a telephone number was considered a privacy issue, requiring a lot of "sign off", which never happened. 
5. Everyone objected to being able to determine what numbers were "live"
6. Carriers objected to a public database that told competitors what numbers they controlled
7. The DNS query was a poor fit for the problem - what evolved was a SIP redirect interface because no vendors liked the DNS interface
8. Delegation of numbers don't fit a tree model any more
9. URIs and other things you put in the DNS were insufficient for the problem
10. Other databases for the problems existed, and it was easier to use them, mostly because they existed.  These are non-public databases

As Rich Shockey notes, there is a fair amount of "ENUM" deployment inside carriers, although it's a SIP redirect interface.  The underlying data structures are the same as ENUM.  Actually, it's only the interfaces for provisioning that are the same.  No one ever does a DNS query.

If we want this deployed soon, it's my considered opinion you can't have a public per-TN database.

We learned in ENUM that DNS is not a good fit for a telephone number.  We understand it looks attractive, but it doesn't fit, primarily because the tree doesn't reflect the delegation model, and a complete tree out to each individual TN is not really a practical solution.  Delegations are ranges.  DNS doesn't do ranges.  Delegations have port-out issues, which DNS doesn't do unless you populate the whole tree.  It's a bad fit.

The DNS guys, at the time, kept asking us "do the limitations of DNS work for you"?  We kept believing, and saying yes.  I now understand why they kept asking the same damn question over and over.  The limitations do not work for us.

My company has built ENUM based systems.  We continuously trip over the mismatch between the DNS model and the problem.  We fix it by ignoring the DNS model, building a database that matches the actual delegation model and treating the DNS query as an awkward, but solvable interface issue.  And it still bites us on things like UDP (very bad for DDoS security) and the restrictions on what a NAPTR can do.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Jun 2013 18:51:39 -0400

Before I respond to your points below in a separate email, I think we might be talking past each other somewhat...

When I say "we might be able to use an ENUM model", I certainly don't mean populating the e164.arpa subtree with NAPTRs of SIP URIs.

I mean populating a new DNS subtree, say cid.arpa or whatever, with cert/pub-key information records (e.g. a CERT Resource Record or whatever), but based on the same reverse-number-dotted-notation for the domain name "key" as described in ENUM.  This new subtree would be purely for the purposes of caller-id verification, not routing.

In a perfect world, IANA would delegate the authority/owner of .cid.arpa to be the ITU, and the ITU would delegate .1.cid.arpa to NANPA and .4.4.cid.arpa to OFCOM and .9.4.cid.arpa to the Bundesnetzagentur and so on. 

Nor would I call it "ENUM" at all in any document whatsoever, just to avoid this type of confusion and stigma.  It just seemed like a convenient way to describe it in this email list discussion so far.

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2013 23:46:12 +0000

This is indeed how, ten years ago, we originally imagined RFC4474 would
handle telephone numbers, whether we fancied it would be in e164.arpa or
elsewhere. Part of what is different about the STIR proposal is that it
explores a more chaotic approach to authority in the hopes of seeding
adoption.

The proposed STIR charter outlines two ways to secure identity: an in-band
and an out-of-band approach. Discussion so far on this list has focused
largely on the in-band. For the out-of-band approach, we need to be able
to explore credentials whose authority rests on some other means than
delegation from on high: perhaps, like in ViPR, from probing how numbers
are routed and using this to prove possession of the number.

Ideally, the credentials used in the two prongs should be compatible (the
charter text says that, anyway). For example, it would be great if, at the
start of an adoption curve, a savvy end user could acquire a credential
through proving SMS return routability, say, which is stored in the user's
smart phone and from there used to secure communications - then later,
when the user's service provider implements this system, they could sign
that same credential to allow its use in more contexts.

So could DNS protocols play a role in a system with those properties? They
could, in some places. I certainly wouldn't rule it out. But arguing from
what the ITU or IANA would delegate doesn't have much relevance to the
out-of-band dimension here. One of the differences between PKI as it has
been implemented for the web (with all its warts) and the DNS is that the
CAs can rely on enrollment methods that don't assume a secure chain of
delegation. That strikes me as analogous to our situation in the
out-of-band prong here.

Jon Peterson
Neustar, Inc.

On 6/12/13 3:51 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>Before I respond to your points below in a separate email, I think we
>might be talking past each other somewhat...
>
>When I say "we might be able to use an ENUM model", I certainly don't
>mean populating the e164.arpa subtree with NAPTRs of SIP URIs.
>
>I mean populating a new DNS subtree, say cid.arpa or whatever, with
>cert/pub-key information records (e.g. a CERT Resource Record or
>whatever), but based on the same reverse-number-dotted-notation for the
>domain name "key" as described in ENUM.  This new subtree would be purely
>for the purposes of caller-id verification, not routing.
>
>In a perfect world, IANA would delegate the authority/owner of .cid.arpa
>to be the ITU, and the ITU would delegate .1.cid.arpa to NANPA and
>.4.4.cid.arpa to OFCOM and .9.4.cid.arpa to the Bundesnetzagentur and so
>on. 
>
>Nor would I call it "ENUM" at all in any document whatsoever, just to
>avoid this type of confusion and stigma.  It just seemed like a
>convenient way to describe it in this email list discussion so far.
>
>-hadriel
>
>
>> 2. It took action by the regulator before anything happened.  Because
>>many regulators didn't understand what this thing was, and still don't,
>>they didn't act
>> 3. It took a level of cooperation between service providers who owned
>>parts of the hierarchy that could not be gained
>> 4. Any public database that was able to show any information about a
>>telephone number was considered a privacy issue, requiring a lot of
>>"sign off", which never happened.
>> 7. The DNS query was a poor fit for the problem - what evolved was a
>>SIP redirect interface because no vendors liked the DNS interface
>> 10. Other databases for the problems existed, and it was easier to use
>>them, mostly because they existed.  These are non-public databases
>> 
>> As Rich Shockey notes, there is a fair amount of "ENUM" deployment
>>inside carriers, although it's a SIP redirect interface.  The underlying
>>data structures are the same as ENUM.  Actually, it's only the
>>interfaces for provisioning that are the same.  No one ever does a DNS
>>query.
>> 
>> We learned in ENUM that DNS is not a good fit for a telephone number.
>>We understand it looks attractive, but it doesn't fit, primarily because
>>the tree doesn't reflect the delegation model, and a complete tree out
>>to each individual TN is not really a practical solution.  Delegations
>>are ranges.  DNS doesn't do ranges.  Delegations have port-out issues,
>>which DNS doesn't do unless you populate the whole tree.  It's a bad fit.
>> 
>> The DNS guys, at the time, kept asking us "do the limitations of DNS
>>work for you"?  We kept believing, and saying yes.  I now understand why
>>they kept asking the same damn question over and over.  The limitations
>>do not work for us.
>> 
>> My company has built ENUM based systems.  We continuously trip over the
>>mismatch between the DNS model and the problem.  We fix it by ignoring
>>the DNS model, building a database that matches the actual delegation
>>model and treating the DNS query as an awkward, but solvable interface
>>issue.  And it still bites us on things like UDP (very bad for DDoS
>>security) and the restrictions on what a NAPTR can do.
>> 
>> Brian
>> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Jun 2013 17:50:17 -0700 (PDT)

> 1. the "global root" problem - who owns and manages e164.arpa, and what are the rules?

We're not talking about e164.arpa per se, but let's assume cid.arpa: the owner of cid.arpa in theory should be the ITU, and they should delegate the country-code subdomains to the respective country number admin authorities (a list that is relatively small and very static).  In practice, however, we might be able to get away with having IANA just do it directly to the country admin authorities.  The actual *work* of administration and running servers wouldn't be done by them, but rather contracted out.

> 3. It took a level of cooperation between service providers who owned parts of the hierarchy that could not be gained

The reason for both those above issues is the same: because there was nothing to gain by the stakeholders.  A Public ENUM wouldn't do anything new for carriers, just cause headaches.  It wouldn't even benefit consumers.  It was a solution looking for a problem.

If, on the other hand, we think caller-id validation is a real problem for service providers themselves, that either they themselves recognize and want to fix or the regulators force them to recognize and fix, then that's a very different ballgame.  As long as the solution doesn't disrupt their business models and operations overhead.

> 6. Carriers objected to a public database that told competitors what numbers they controlled

Agreed, the above are real problems.  But it's not clear if they apply to E.164 signature keys.  #4 and #5 are easy to avoid... #6 not so much.  I can't quite figure out how to avoid #6.  :(

(I'll skip #7 and move it to later)
> 8. Delegation of numbers don't fit a tree model any more

Agreed, but we don't need to delegate anything out to anyone.  The subdomain authority could remain with the country number admins for ALL their numbers.  For example, all country-code-44 number certs in the DNS records could be issued by OFCOM as the CA, not by the UK carriers.  The UK carriers would do the signing, because OFCOM would give them the priv keys for their numbers.

> 9. URIs and other things you put in the DNS were insufficient for the problem

Actually people have fit a crap-load of stuff into ENUM NAPTR URIs, but we're not talking about NAPTR nor URIs for this new thing anyway.

> 10. Other databases for the problems existed, and it was easier to use them, mostly because they existed.  These are non-public databases

Yup, existing deployment invariably trumps something new if the something new doesn't provide new capabilities/features/revenue/cost-savings.  But I don't know of an existing caller-id verification database.  There are existing caller-name databases of course, but that's different.
And the ENUM ones are non-public because the data itself is (1) private and (2) not usable in a public context.  The entries in the database (the results of the lookup) aren't meaningful to anyone but the carrier asking the query.  That doesn't apply for caller-id keys.

> As Rich Shockey notes, there is a fair amount of "ENUM" deployment inside carriers, although it's a SIP redirect interface.  The underlying data structures are the same as ENUM.  Actually, it's onl…

I think you and I live in different worlds.  Perhaps you never see ENUM being used because maybe it doesn't reach Neustar's services?  In my world, ENUM gets used a LOT.  If you run Wireshark inside the carrier on the right links/subnets, you'll see constant DNS queries for NAPTRs using reverse-number-dotted domain-name format for the query key.  It's not SIP Redirect, it's actual DNS over UDP packets.  But it never leaves the carrier's private network.  It's generated by proxies, gateways, and SBCs as clients, to databases.  And speaking for one vendor, we like it way more than SIP Redirect (which we also support); and apparently so do some of our big customers.  It has some real benefits.

> If we want this deployed soon, it's my considered opinion you can't have a public per-TN database.

Of course, it's always faster/easier to deploy something in private contexts at the start.  If we go with a Public-Internet DNS-based model as the ultimate goal/solution, for example: one could start earlier with the data for some subset of numbers, on servers run by Neustar or whomever, only accessible by members "in-the-club".  I.e., similar to a private or carrier ENUM model.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Jun 2013 21:01:21 -0700

> above, anyway. Keying in private DNS is more viable, for example. I think

Other models?

Is there a written description of the integrated query service that you 
folks are considering, in terms of design, administration and operation?

It would help to also hear where such a design has already been 
successfully deployed.

As the Enum experience showed, schemes can be intelligent and appealing 
but not succeed.  So for any new deployment, any analysis needs to start 
with skepticism and work its way up with pragmatics.

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Jun 2013 00:42:47 -0400

On Jun 12, 2013, at 6:01 PM, "Peterson, Jon" <[email-masked]> wrote:

> above, anyway.

The liability you described above for ENUM is the same liability for caller-id: we need the carriers to agree to do this.  We don't need *all* of them to, at least not at the start, but we need a critical mass within at least one country, preferably more than one country.  Convincing just Enterprises to do it is neither necessary nor sufficient.

> Keying in private DNS is more viable, for example. I think
> a PKI is more viable.

In what way is DNS with DNSSEC/DANE *not* a PKI?

-hadriel

---

From: Dan York <[email-masked]>
Date: Thu, 13 Jun 2013 12:51:35 +0000

Hadriel,

>and why we won't hit the same issues in whatever model we choose.

Since you addressed this question to me, I feel compelled to answer... but
in the meantime both Brian and Jon have given much more detailed answers
with which I mostly agree.

I saw security/privacy issues as the main issues that made Public ENUM not
work, i.e. Brian's points 4, 5 and 6:

>telephone number was considered a privacy issue, requiring a lot of "sign
>off", which never happened.

The potential for spam was also high.  Five or six years ago there was at
least one tool circulating around that would walk an ENUM tree, generate a
list of all potential phone numbers and then send SIP INVITEs to all of
those numbers.  I remember either seeing a video or reading about how
someone did this with all the public ENUM numbers published for Germany
(at that time). So using Public ENUM could be a fantastic way to
potentially get yourself on the calling lists for telemarketers.

Ideally, I think a public service *would* be a useful way to enable
ubiquitous usage. I'm just not sure how to get there without also opening
a solution up to these same kind of security/privacy issues.

Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked] <mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked] <mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: "Wendt, Chris" <[email-masked]>
Date: Thu, 13 Jun 2013 13:37:31 +0000

Hi Folks,

I believe it couldn't be a better time to start discussing public routing.  While this is a little beyond the scope of protecting caller-id, I think the effort is highly complimentary, and solving both together will provide a better path to get things implemented in service provider networks.

IP communications is evolving whether you want to get on the train or not.  I applaud Henning's efforts to push the ball forward.

Moving more to an internet model for routing is inevitable, IMHO.  There is questions about how relevant TN is or will be in the near future.  For the sake of having any chance of success, let's simplify the effort and focus on the future.  There will be a transition process to get there, no doubt, but let's focus on the end goal, and not focus on fixing problems of the past.  We are already in a world of multiple private peering arrangements, LCR, and managing multiple egress points anyway, so the transition should not be that difficult.

I believe a common routing mechanism for both user@domain and TN/e164 based identities should be the focus.  Treat both as first class citizens for IP communications.

Use DNS and domain based routing for all.  Use DNSEC to validate and cryptographically associate TN/caller-id with a domain (for good guys) and do domain routing from there.  
Forget about trying to protect TN's individually, that is too complex.

It's up to the consumer service providers to enforce and block bad things from bad domains.
It's up to wholesale/trunking providers to allow customers to assert their own domain, or be responsible for asserting domains on their behalf at the risk of being considered a "bad guy".

This is high level, and perhaps a sunny day view of the world, but I don't think unrealistic.  Frankly, if there is any chance of a common federated communications system continuing to be relevant, I believe a simple approach that matches the internet model is the only choice.

You should see more concrete opinions from Comcast in the future, but I wanted to take the opportunity to express these thoughts and would love feedback on why this should or should not be the model going forward.

If there is agreement, I believe some of this should be addressed in the charter, because I think some of the assumptions may not enable this path. 

-Chris

---

From: Brian Rosen <[email-masked]>
Date: Thu, 13 Jun 2013 10:08:15 -0400

The IETF is starting a new effort on routing,  see the TERQ work.  If you have ideas on routing, that would be the place to bring them.

I think the problem we have here is trying to decide who is a "good guy".  Most of the service providers who would would call "pink" in this context would claim they are good guys.  Trying to create a mechanism to separate good guys from bad guys is very hard.

I'm not sure why protecting TNs individually is more complex then the view you have of routing, especially because we have tried what you are suggesting, although we did not have DNSSEC.  Dealing with the privacy issues, just to start, would be the first real barrier.

Let's say we got beyond that.  We then need someone, probably someone like Neustar, to maintain a per country portion of the database.  How would it do that?

Basically, every time a number was delegated, it would change the domain of the entry to reflect the delegation.  That could work.  What it means is that delegation of any kind has to be recorded in the new database.  If you note, certs follow delegation, with you inserting "domain" in the middle (domain follows delegation).  The twist is that instead of a 2nd level reseller issuing a cert to a 3rd level reseller, the 2nd level reseller goes to the new database and has them effectively do the same thing.   

Having databases that associate a domain with a TN might help things like finding a cert, but it doesn't affect the basic issue of how you avoid spoofing.  Do you think the approach we have suggested here (signing of From/To/Time/Session Id) with a cert traceable to the identity is appropriate?

If you are "simply" suggesting the cert is located via DANE in the domain of the caller, then for user@domain, I think we're probably saying the same thing.  Where we seem to differ is that you suggest we have a DNS entry for the TN that has the domain in it, and then you use that to find the cert used for signing.  In the basic case, we're suggesting a URI to the cert in the signaling, which seems simpler.  What matters however is how the DNS tree for the TNs is maintained.

So, my response is the same as I have given before: the privacy and operational issues of putting per TN information in the public DNS are overwhelming.  We have tried it, and it has failed.  

Unlike Hadriel, you really do want to disclose domain with TN.  That has been a non-starter for many carriers.

Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Jun 2013 12:13:51 -0400

> So, my response is the same as I have given before: the privacy and operational issues of putting per TN information in the public DNS are overwhelming.  We have tried it, and it has failed.

The privacy issues can be avoided.

The operational issues, however, are quite significant.  But I don't see how they're not significant no matter what databases we put them in.  No matter whether it's a private database or public one: there will be new operational procedures, forms to fill out, help desk people to handle problems with it, configuration and deployment of stuff, NOC personnel to train, testing to do, monitoring systems to monitor it, etc., etc.

In short: it's a very big deal.

Luckily history has shown that some third-party service companies will make themselves available to do most of the work for carriers that don't want to do it themselves, for a fee.  It might be the number portability vendors, or CNAM vendors, or something new.  Either way, they can handle most of the heavy lifting for carriers who don't want to.  If we choose a DNS model, then those third-party vendors would then interface to the DNS admin; or maybe they start with a private federation of servers just among the third-party companies.

The reason Public ENUM failed wasn't because it was an operational nightmare - if Public ENUM had some actual useful benefit to the stakeholders, then all other issues would have gone away or been dealt with.  I.e., if the carriers *want* something, then they figure out how to get it done, how to lobby their Regulators, and how to get the ITU to go along.  If they don't want it, then every possible issue that can be raised becomes "impossible to fix".  And I'm not saying that's wrong either. (and everyone does the same thing in the IETF, regularly)

> Unlike Hadriel, you really do want to disclose domain with TN.  That has been a non-starter for many carriers.

In my defense, it's not that *I* don't want to disclose the domain of the TN - I'd be perfectly happy with it - it's that I'm pretty sure a lot of providers AND Enterprises would not, if it means you can discover all the TNs belonging to the domain.  And you don't need to go very far to find evidence of that: how many companies want to publicly disclose all their users' email addresses?  Of my current and half-dozen previous employers, none would want them exposed.

-hadriel

---

From: "Wendt, Chris" <[email-masked]>
Date: Thu, 13 Jun 2013 16:18:03 +0000

Thanks Brian. 

Answer inline.

> I think the problem we have here is trying to decide who is a "good guy".  Most of the service providers who would would call "pink" in this context would claim they are good guys.  Trying to creat…

Sure, they assert their domain, provide DNSSEC to verify, but we notice customer complaints and shut them down.  Plus have cryptographic evidence that it was indeed coming from them.  I think that works pretty well.  
If a "bad guy" chooses not to participate in asserting domain, then the service provider can choose whether to accept the calls.

> I'm not sure why protecting TNs individually is more complex then the view you have of routing, especially because we have tried what you are suggesting, although we did not have DNSSEC.  Dealing w…

I probably don't fully understand the privacy issue, but to me the only thing potentially exposed is the domain that owns the telephone number.

> Basically, every time a number was delegated, it would change the domain of the entry to reflect the delegation.  That could work.  What it means is that delegation of any kind has to be recorded i…

So, I defer here to better experts than myself.

> Having databases that associate a domain with a TN might help things like finding a cert, but it doesn't affect the basic issue of how you avoid spoofing.  Do you think the approach we have suggest…

I just think it's overboard to have a cert per identity and I don't believe a service provider I want to police calls TN by TN.  
It's the domain representing the wholesale provider or PBX or whatever that we want to police, I think.

> If you are "simply" suggesting the cert is located via DANE in the domain of the caller, then for user@domain, I think we're probably saying the same thing.  Where we seem to differ is that you sug…

I think using standard DNSSEC mechanisms is simpler and more straight forward, but that's an opinion guided by domain routing as the end state.
Although, I think perhaps it might be wise to have a guiding philosophy that I hope most would agree with.  If we are creating new mechanisms to do things, we are doing it wrong.

> So, my response is the same as I have given before: the privacy and operational issues of putting per TN information in the public DNS are overwhelming.  We have tried it, and it has failed.  

I think the main issue, to your point above, is management of a TLD, but i think it's solvable, we have lots of smart people.  
If the privacy issue is really an issue, then lets discuss further.

This will be a transition from private databases to a fully distributed system, and I think the long term issue will be the desire to move to this model or a push from regulatory entities if that is where we/they want to go.  In some sense, I think there will be a lot of benefit to it and allow for much better communications applications in the future, but this is speculation.

In the end, we have a great distributed internet model for transporting data, securing data, cryptographic verification of destination and origination, why shouldn't we push that direction for communications as well, isn't that the point?  Or better yet, why won't it be the end state anyway whether the traditional players are involved or not.

Failure is not an option :)

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 Jun 2013 12:39:13 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Thursday, June 13, 2013 10:08 AM
To: Wendt, Chris
Cc: Dan York; Peterson, Jon; Hadriel Kaplan; [email-masked]; Dave Crocker;
Henning Schulzrinne; Stephen Farrell
Subject: Re: [stir] current draft charter

The IETF is starting a new effort on routing,  see the TERQ work.  If you
have ideas on routing, that would be the place to bring them.
[RS> ] 
[RS> ]  Wait a second.. You are demonstrating a profound misunderstanding of
what a service provider has in place or are capable of actually implementing
within a reasonable time frame.  It is not utterly unreasonable to at least
consider that the issues of number resolution for TN Source Authentication
or Routing would be somewhat similar.  There is infrastructure and
technology in place.  Dismissing that question out of hand is absurd.
Frankly the way the IETF works these days the chances of TERQ actually
deploying before the End of Ages is debatable.  You know the timelines as
well as anyone ... 4 years for a RFC then 2 years for it to show up on
carrier requirements, regression testing .. vendor selection.  Get a grip. 

I think the problem we have here is trying to decide who is a "good guy".
Most of the service providers who would would call "pink" in this context
would claim they are good guys.  Trying to create a mechanism to separate
good guys from bad guys is very hard.

I'm not sure why protecting TNs individually is more complex then the view
you have of routing, especially because we have tried what you are
suggesting, although we did not have DNSSEC.  Dealing with the privacy
issues, just to start, would be the first real barrier.

Let's say we got beyond that.  We then need someone, probably someone like
Neustar, to maintain a per country portion of the database.  How would it do
that?

[RS> ]  OH PLEASE.. I love a good global domination strategy as much as the
next red blooded capitalist but these endless references to ..."somelike
NeuStar"  are becoming tedious and inappropriate. 

Basically, every time a number was delegated, it would change the domain of
the entry to reflect the delegation.  That could work.  What it means is
that delegation of any kind has to be recorded in the new database.  If you
note, certs follow delegation, with you inserting "domain" in the middle
(domain follows delegation).  The twist is that instead of a 2nd level
reseller issuing a cert to a 3rd level reseller, the 2nd level reseller goes
to the new database and has them effectively do the same thing.   

Having databases that associate a domain with a TN might help things like
finding a cert, but it doesn't affect the basic issue of how you avoid
spoofing.  Do you think the approach we have suggested here (signing of
From/To/Time/Session Id) with a cert traceable to the identity is
appropriate?

If you are "simply" suggesting the cert is located via DANE in the domain of
the caller, then for user@domain, I think we're probably saying the same
thing.  Where we seem to differ is that you suggest we have a DNS entry for
the TN that has the domain in it, and then you use that to find the cert
used for signing.  In the basic case, we're suggesting a URI to the cert in
the signaling, which seems simpler.  What matters however is how the DNS
tree for the TNs is maintained.

So, my response is the same as I have given before: the privacy and
operational issues of putting per TN information in the public DNS are
overwhelming.  We have tried it, and it has failed.  

Unlike Hadriel, you really do want to disclose domain with TN.  That has
been a non-starter for many carriers.

Brian

On Jun 13, 2013, at 9:37 AM, "Wendt, Chris" <[email-masked]>
wrote:

> Hi Folks,
> 
> I believe it couldn't be a better time to start discussing public routing.
While this is a little beyond the scope of protecting caller-id, I think the
effort is highly complimentary, and solving both together will provide a
better path to get things implemented in service provider networks.
> 
> IP communications is evolving whether you want to get on the train or not.
I applaud Henning's efforts to push the ball forward.
> 
> Moving more to an internet model for routing is inevitable, IMHO.  There
is questions about how relevant TN is or will be in the near future.  For
the sake of having any chance of success, let's simplify the effort and
focus on the future.  There will be a transition process to get there, no
doubt, but let's focus on the end goal, and not focus on fixing problems of
the past.  We are already in a world of multiple private peering
arrangements, LCR, and managing multiple egress points anyway, so the
transition should not be that difficult.
> 
> I believe a common routing mechanism for both user@domain and TN/e164
based identities should be the focus.  Treat both as first class citizens
for IP communications.
> 
> Use DNS and domain based routing for all.  Use DNSEC to validate and
cryptographically associate TN/caller-id with a domain (for good guys) and
do domain routing from there.  
> It's up to wholesale/trunking providers to allow customers to assert their
own domain, or be responsible for asserting domains on their behalf at the
risk of being considered a "bad guy".
> 
> This is high level, and perhaps a sunny day view of the world, but I don't
think unrealistic.  Frankly, if there is any chance of a common federated
communications system continuing to be relevant, I believe a simple approach
that matches the internet model is the only choice.
> 
> You should see more concrete opinions from Comcast in the future, but I
wanted to take the opportunity to express these thoughts and would love
feedback on why this should or should not be the model going forward.
> 
> If there is agreement, I believe some of this should be addressed in the
charter, because I think some of the assumptions may not enable this path. 
>>> That begs the question of what issues you think made Public ENUM 
>>> fail, and why we won't hit the same issues in whatever model we choose.
>> 
>> Since you addressed this question to me, I feel compelled to 
>> answer... but in the meantime both Brian and Jon have given much more 
>> detailed answers with which I mostly agree.
>> 
>> I saw security/privacy issues as the main issues that made Public 
>> ENUM not work, i.e. Brian's points 4, 5 and 6:
>> 
>> The potential for spam was also high.  Five or six years ago there 
>> was at least one tool circulating around that would walk an ENUM 
>> tree, generate a list of all potential phone numbers and then send 
>> SIP INVITEs to all of those numbers.  I remember either seeing a 
>> video or reading about how someone did this with all the public ENUM 
>> numbers published for Germany (at that time). So using Public ENUM 
>> could be a fantastic way to potentially get yourself on the calling lists
for telemarketers.
>> ubiquitous usage. I'm just not sure how to get there without also 
>> opening a solution up to these same kind of security/privacy issues.
>> 
>> Dan
>> 
>> --
>> Dan York

---

From: Brian Rosen <[email-masked]>
Date: Thu, 13 Jun 2013 12:51:46 -0400

This particular effort is aimed at trying to do something about robocalling, vishing and swatting in a relatively short time frame.  To many of us, that seems doable.

Re-doing how routing of telephone number based identities work is the charter of TERQ.  It probably can't be done relatively quickly, no matter what mechanisms are used.

Restricting charter is a time-honored way of getting stuff done.  I'll take that path without any qualms.  I'm not interested in re-doing routing of telephone number identities as part of this work.

The point of asserting that it takes someone like Neustar to handle a database like what is being described is that a DNS based tree doesn't map into the way number delegation works - so the entire tree has to be handled by one entity - you can't delegate part of it to someone else, especially when porting is considered.   I was trying to contrast that with the model I've described where cert delegation follows number delegation.  That doesn't require a monolithic database.

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 Jun 2013 11:30:48 -0400

<sigh>  Since it seems folks want some authoritative history of 6116 I
suppose I should oblige.  I only co-chaired the ENUM WG for nearly 8 years.
Brother Pfautz can also relate the issues.

There were multiple reasons e164.arpa failed though 6116 technology has
worked very well imbedded in carrier networks as a TCAP replacement where
the CSCF or SIP proxy needs to perform some form of number translation for
some data or metadata, typically for the call routing function. On a
localized, distributed and fully cached basis ENUM  essentially becomes a
Central Routing Server. One of the big holes in IMS BTW.   Essentially an IP
Service Control Point in old TDM/SS7 terms.  

ENUM did not fail .. e164.arpa failed.  Like lots of IETF protocols they
sometimes get use for things not originally intended. MIME immediately comes
to mind. 

If I recall ENUM still baked into the IMS architecture.  SIP Redirect also
works well for number translation functions and modern database technology
has made the difference in query response time negligible.  It's now only a
question of network preference on which protocol to use. There is a lot of
real 6116 technology out there.   Hadriel is right and Brian is simply wrong
6116 IS everywhere and it's baked into every SIP Session Border Controller
sold on the Planet. 

There is no question you could develop some HTTPS like methodology that
would equally well for number translations but as a practical matter it's
simply a matter of taste.  Provisioning is the larger problem and DRINKS is
still at it after 4 years. 

Dan and Brian correctly points out one of the issues with a public tree was
privacy. The idea that since the tree was public on the global Internet an
enterprising Voice Spammer could scrape the tree to identify all active
E.164 numbers.   Brian's issue #6 is a not true since any US carrier for
instance can actually see the underlying carrier number for any NANP number
in the system.  For other jurisdictions carrier identification in the
underlying numbering databases is different. 

Obviously the #1 problem e164.arpa was the delegation model which required
endless fights with the ITU which no one, I assume wants to repeat.

Second the DNS is what it is, so you were left with no methodology for
Authentication or Authorization of the query itself. In private
instantiations this was solved by requiring VPN access even down to a
limited set of IP addresses.  It works if the application using 6116 was
limited enough.    IN the US this was done for the MMS mobile picture
routing application and the FCC's own I-TRS database for the hearing
impaired. 

Third ... one answer.  In SIP call routing this posed a problem generally
referred to Determinate Response.  The target URI for the terminating
Carrier SBC might be different based on who was asking the question and
ultimately where.  Obviously we got nowhere with Kaplan source URI though I
understand it has been implemented in private ENUM instantiations. Private
firms like Akamai munge DNS all the time in CDN networks to optimize the
source of content to the location of the query. 

Fourth was the obvious political problem of having carriers agree to allow
user control of routing data and that was a nonstarter.  However if the tree
was actually in control of the service providers ... gee  GSMA Pathfinder..
well then that was NOOOOOO problem. But Pathfinder had its own set of
issues.  There were at least 2 other well-funded ENUM initiatives driven by
carriers in the US alone, but in my judgment they have not deployed since
the market conditions and requirements were not ready.  In addition there
are at least a dozen private ENUM services in existence. 

"Money is the answer what is the question?"  Shockey's Law.   

http://www.gsma.com/technicalprojects/pathfinder

That said the proposed requirements here are actually different and the
market conditions have demonstrably changed so certainly 6116 technology
COULD work but you would have to revisit a lot of  issues like the E2MD
problem etc Source URI and the provisioning issues.  The interest of the
carriers and the regulators are in actual alignment here. 

6116 is a reasonable option that should be left on the table for
consideration as the STIR process moves forward and the full requirements
are actually understood. One of those is the structure for E.164 numbers
controlled by Public Safety and Government authorities themselves. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
York
Sent: Thursday, June 13, 2013 8:52 AM
To: Hadriel Kaplan
Cc: [email-masked]; Stephen Farrell; Dave Crocker; Peterson, Jon; Henning
Schulzrinne
Subject: Re: [stir] current draft charter

Hadriel,

The potential for spam was also high.  Five or six years ago there was at
least one tool circulating around that would walk an ENUM tree, generate a
list of all potential phone numbers and then send SIP INVITEs to all of
those numbers.  I remember either seeing a video or reading about how
someone did this with all the public ENUM numbers published for Germany (at
that time). So using Public ENUM could be a fantastic way to potentially get
yourself on the calling lists for telemarketers.

Ideally, I think a public service *would* be a useful way to enable
ubiquitous usage. I'm just not sure how to get there without also opening a
solution up to these same kind of security/privacy issues.

Dan

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Jun 2013 17:18:12 +0000

> The liability you described above for ENUM is the same liability for
>caller-id: we need the
> carriers to agree to do this.

The purpose of the proposed work is not to change or extend the authority
of end users - and make no mistake, that was the purpose of public ENUM.
Politically, that ambition was a significant barrier to carrier adoption.
What we're proposing to do here instead is to leverage existing authority
structures to the fullest capacity to increase the security of caller ID.
There are roles carriers could play in this that would help, if they are
interested and able. There are also techniques like iMessage that could
help where carriers are not, or where things are just too early for
carrier involvement. But I don't think this all reduces to just "we need
the carriers to agree to do this," and nor that this has the same
implications for carrier adoption that public ENUM did.

Today there are use cases where carriers delegate some of their authority
over numbers to entities like service bureaus or enterprises. Arguably,
end users in many jurisdictions have certain authority over their numbers
(like the authority to port) and in the future it's possible that
regulators would broaden it. I can't readily speak to the question of
whether or not carriers want to extend the authority of users over numbers
except to say that some probably do and others probably don't. If we look
at a service like Google Voice, say, and how carriers support that
service, we can see at least some evidence for carriers who would benefit
from increasing the authority of users in certain deployments. For the
purposes of securing caller ID, I think activities at many of these
different levels could be effective and that we shouldn't rule them out.

> In what way is DNS with DNSSEC/DANE *not* a PKI?

That is a fair question, I agree, and I don't mean to create some
artificial distinction here. As I've suggested previously, I think the
public DNS dictates a particular delegation and enrollment model for the
pseudo-PKI that is DNSSEC/DANE. It may be that model is a fit for some of
our use cases and not others. In any event, I think the charter and
problem statement should be broad enough to encompass "key management" as
Stephen suggested rather than limiting this to certificates.

Jon Peterson
Neustar, Inc.

On 6/12/13 9:42 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>The liability you described above for ENUM is the same liability for
>caller-id: we need the carriers to agree to do this.  We don't need *all*
>of them to, at least not at the start, but we need a critical mass within
>at least one country, preferably more than one country.  Convincing just
>Enterprises to do it is neither necessary nor sufficient.
>
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Jun 2013 17:25:27 +0000

>> above, anyway. Keying in private DNS is more viable, for example. I

I just meant for example private DNS, or PKI, as it says up there.

>folks are considering, in terms of design, administration and operation?

I wasn't talking about some kind of integrated query service, I was
talking about where the keys should live. So, written descriptions would
be CP/CPS sorts of things, if that's what you mean here?

>It would help to also hear where such a design has already been

Do you think that is an issue for CAs/PKIs? Certainly they have some rough
edges, which is why we see the DNS (through DANE) potentially playing a
role in their future. Or maybe it will be more like the SSL Observatory or
any of several other private cert verification initiatives going around. I
don't think I'm ready to give up entirely on the future of issuing certs -
yet anyway.

Jon Peterson
Neustar, Inc.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 Jun 2013 13:49:34 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Thursday, June 13, 2013 12:52 PM
To: Richard Shockey
Cc: 'Wendt, Chris'; 'Dan York'; 'Peterson, Jon'; 'Hadriel Kaplan';
[email-masked]; 'Dave Crocker'; 'Stephen Farrell'; 'Henning Schulzrinne'
Subject: Re: [stir] current draft charter

This particular effort is aimed at trying to do something about robocalling,
vishing and swatting in a relatively short time frame.  To many of us, that
seems doable.
[RS> ] I agree. No argument there. 

Re-doing how routing of telephone number based identities work is the
charter of TERQ.  It probably can't be done relatively quickly, no matter
what mechanisms are used.

Restricting charter is a time-honored way of getting stuff done.  I'll take
that path without any qualms.  I'm not interested in re-doing routing of
telephone number identities as part of this work.
[RS> ] 
[RS> ] <sigh>  but the practical issues of deployment are and that still is
related which to what  Chris and certainly Penn will constantly point out.
What are the optimal structures for the databases and query mechanisms that
do not necessarily require a 3 -7 year product cycle.  That may actually be
the national numbering databases where they exist.  Focusing on one or two
national use cases is in fact useful and as Penn correctly points out some
LOST like structure over time could work for internationalizing the system.
One thing would help is more data.  

It would be nice to hear from the Dutch COIN people, for instance since the
structure of their LNP DB closely follows that of North American real time
models.   So is Ireland and ComReg I haven't monitored that stuff in years.

The point of asserting that it takes someone like Neustar to handle a
database like what is being described is that a DNS based tree doesn't map
into the way number delegation works - so the entire tree has to be handled
by one entity - you can't delegate part of it to someone else, especially
when porting is considered.   I was trying to contrast that with the model
I've described where cert delegation follows number delegation.  That
doesn't require a monolithic database.
[RS> ] 
[RS> ] You are really going to have to re explain that what you mean ENUM
like delegation does not map into number delegation. Granted that having
dealt with ENUM for as many years as I have may have totally dulled my
synapses but you need to walk through that more carefully.   Ok so walk me
through how the Canadian NANP will be separated from the US NANP and
individual Public Safety numbers will the separated from both. 

Brian

On Jun 13, 2013, at 12:39 PM, Richard Shockey <[email-masked]> wrote:

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Brian Rosen
> Cc: Dan York; Peterson, Jon; Hadriel Kaplan; [email-masked]; Dave 
> Crocker; Henning Schulzrinne; Stephen Farrell
> The IETF is starting a new effort on routing,  see the TERQ work.  If 
> you have ideas on routing, that would be the place to bring them.
> [RS> ]
> [RS> ]  Wait a second.. You are demonstrating a profound 
> misunderstanding of what a service provider has in place or are 
> capable of actually implementing within a reasonable time frame.  It 
> is not utterly unreasonable to at least consider that the issues of 
> number resolution for TN Source Authentication or Routing would be 
> somewhat similar.  There is infrastructure and technology in place.
Dismissing that question out of hand is absurd.
> deploying before the End of Ages is debatable.  You know the timelines 
> as well as anyone ... 4 years for a RFC then 2 years for it to show up 
> on carrier requirements, regression testing .. vendor selection.  Get a
grip.
> Most of the service providers who would would call "pink" in this 
> context would claim they are good guys.  Trying to create a mechanism 
> to separate good guys from bad guys is very hard.
> 
> I'm not sure why protecting TNs individually is more complex then the 
> view you have of routing, especially because we have tried what you 
> are suggesting, although we did not have DNSSEC.  Dealing with the 
> privacy issues, just to start, would be the first real barrier.
> 
> Let's say we got beyond that.  We then need someone, probably someone 
> like Neustar, to maintain a per country portion of the database.  How 
> would it do that?
> 
> [RS> ]  OH PLEASE.. I love a good global domination strategy as much 
> as the next red blooded capitalist but these endless references to 
> ..."somelike NeuStar"  are becoming tedious and inappropriate.
> 
> 
> Basically, every time a number was delegated, it would change the 
> domain of the entry to reflect the delegation.  That could work.  What 
> it means is that delegation of any kind has to be recorded in the new 
> database.  If you note, certs follow delegation, with you inserting 
> "domain" in the middle (domain follows delegation).  The twist is that 
> instead of a 2nd level reseller issuing a cert to a 3rd level reseller,
the 2nd level reseller goes
> Having databases that associate a domain with a TN might help things 
> like finding a cert, but it doesn't affect the basic issue of how you 
> avoid spoofing.  Do you think the approach we have suggested here 
> (signing of From/To/Time/Session Id) with a cert traceable to the 
> identity is appropriate?
> 
> If you are "simply" suggesting the cert is located via DANE in the 
> domain of the caller, then for user@domain, I think we're probably 
> saying the same thing.  Where we seem to differ is that you suggest we 
> have a DNS entry for the TN that has the domain in it, and then you 
> use that to find the cert used for signing.  In the basic case, we're 
> suggesting a URI to the cert in the signaling, which seems simpler.  
> What matters however is how the DNS tree for the TNs is maintained.
> 
> Unlike Hadriel, you really do want to disclose domain with TN.  That 
> has been a non-starter for many carriers.
> 
> Brian
> 
> 
> While this is a little beyond the scope of protecting caller-id, I 
> think the effort is highly complimentary, and solving both together 
> will provide a better path to get things implemented in service provider
networks.
> is questions about how relevant TN is or will be in the near future.  
> For the sake of having any chance of success, let's simplify the 
> effort and focus on the future.  There will be a transition process to 
> get there, no doubt, but let's focus on the end goal, and not focus on 
> fixing problems of the past.  We are already in a world of multiple 
> private peering arrangements, LCR, and managing multiple egress points 
> anyway, so the transition should not be that difficult.
>> 
> based identities should be the focus.  Treat both as first class 
> citizens for IP communications.
>> 
> cryptographically associate TN/caller-id with a domain (for good guys) 
> and do domain routing from there.
>> It's up to the consumer service providers to enforce and block bad 
>> things
> from bad domains.
> own domain, or be responsible for asserting domains on their behalf at 
> the risk of being considered a "bad guy".
>> 
> think unrealistic.  Frankly, if there is any chance of a common 
> federated communications system continuing to be relevant, I believe a 
> simple approach that matches the internet model is the only choice.
>> 
> wanted to take the opportunity to express these thoughts and would 
> love feedback on why this should or should not be the model going forward.
>> 

>>> answer... but in the meantime both Brian and Jon have given much 
>>> more detailed answers with which I mostly agree.
>>> 
>>>> 4. Any public database that was able to show any information about 
>>>> a telephone number was considered a privacy issue, requiring a lot 
>>>> of "sign off", which never happened.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 13 Jun 2013 14:16:00 -0400

> individual Public Safety numbers will the separated from both. 

Number delegation is now, and increasingly moving to range sizes that are not power of 10.

Where you still get PA assignments in the US in 1000 number blocks, a typical resell as likely  25 numbers or 5 as it is 100 or 10.   The latest moves in the US will force the PA to do small assignments also.

Unless the delegation size is a power of 10, it doesn't map into the delegation model of DNS with reverse-dotted zones.

You end up fully populating the tree down to the full e.164, and delegating multiples of 1 TN rather than being able to delegate a higher level part of the tree.

That is so unwieldy that you wouldn't do it - you get someone like Neustar to maintain the entire tree and provide a provisioning interface that handles an arbitrary sized delegation.  We could still delegate the NPAs out of +1 to the appropriate contractors on a per nation basis, but of course,  all of the nations that share +1 have to agree on a common +1 domain operator.  cc1enum anyone?  anyone?

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 Jun 2013 14:54:15 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Thursday, June 13, 2013 2:16 PM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [stir] current draft charter

> [RS> ] You are really going to have to re explain that what you mean 
> ENUM like delegation does not map into number delegation. Granted that 
> having dealt with ENUM for as many years as I have may have totally dulled
my
> individual Public Safety numbers will the separated from both.

Number delegation is now, and increasingly moving to range sizes that are
not power of 10.

Where you still get PA assignments in the US in 1000 number blocks, a
typical resell as likely  25 numbers or 5 as it is 100 or 10.   The latest
moves in the US will force the PA to do small assignments also.

Unless the delegation size is a power of 10, it doesn't map into the
delegation model of DNS with reverse-dotted zones.

You end up fully populating the tree down to the full e.164, and delegating
multiples of 1 TN rather than being able to delegate a higher level part of
the tree.
[
[RS> ]  Well what's wrong with TN level delegations?    

That is so unwieldy that you wouldn't do it - you get someone like Neustar
to maintain the entire tree and provide a provisioning interface that
handles an arbitrary sized delegation.  We could still delegate the NPAs out
of +1 to the appropriate contractors on a per nation basis, but of course,
all of the nations that share +1 have to agree on a common +1 domain
operator.  cc1enum anyone?  anyone?

Brian

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jun 2013 15:24:15 -0700

Jon, et al,

> I just meant for example private DNS, or PKI, as it says up there.

1. The functional description that's been offered said that validation 
is to be permitted by entities such as callee-side enterprises and even 
callee UAs.  That precludes any sort of private service.  Whatever 
parameters must be obtained outside of the SIP headers -- such as public 
keys -- they need to be publicly accessible.

2. From one of your earlier notes, I gather that by "PKI" you mean the 
bushy (multi-root) system that operates for SSL/TLS web services?  You 
appear to be using PKI to mean a specific, integrated, operating 
credential service, so I would like to be clear about which specific one 
you mean; the one used by the Web seems to be it?

> be CP/CPS sorts of things, if that's what you mean here?

I suspect you mean more than where they live, since they aren't much use 
if they can't be retrieved, and in fact retrieved publicly.

By "query service" I meant the term generically as a mechanism that 
askes for something and gets it. I didn't want to imply or constrain any 
details about the form of the request or what was returned; merely that 
it's in the service of performing validation.

Since the intent here is to develop a global validation service for 
SIP-based calls and since such a service will need to obtain some types 
of information to permit validation, it will need a mechanism for 
retrieving whatever that information is.  That's all I meant by query 
service.

While yes, one can imagine designing a service that permits packaging 
everything in-line with the SIP data, it's clear that that won't be 
sufficient, based on one or more of the documents -- and much of the 
message postings -- for this topic.  Hence, it needs a query service of 
some sort.

> Do you think that is an issue for CAs/PKIs? Certainly they have some rough

The PKI service used for the web has the advantage of existing and being 
heavily used.  A base of experience is goodness, when considering 
out-sourcing a component of a new service.  Whether its characteristics 
suffice for the current project, I don't know.  Some times, rough edges 
cut thing and bleed them dry.

> edges, which is why we see the DNS (through DANE) potentially playing a

Ah yes, the great promise of DANE.  I'm sure it will yet deliver, as 
have all of the other promising efforts in the IETF.  Oh, no, this one 
really will.  No, honest, it will.  And I hope I'm serious.

That's not a criticism of DANE.  It's an attempt to raise a flag about 
relying on it.

One of the classic errors in a new project is creating a critical 
dependency on a parallel, independent project.  Sometimes it's 
necessary, but it's always extremely risky.  Extremely.  Always.

> role in their future. Or maybe it will be more like the SSL Observatory or

The 'maybe' -- and equivalent phrasings that you've used -- point up 
something that I've become confused about.  What I was told (rather 
forcefully offline) is that there is a solution already formulated. 
However what's been put forward on the list so far sounds more like some 
ideas, at least some of which are not yet close to being solid.

If there is in fact a concrete, detailed design already in hand, that 
attends to relevant security, privacy, scaling, deployment, 
administration and operations issues, let's hear it.

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Jun 2013 21:12:48 -0400

Instead of looking at this as an ENUM-like problem, another angle is to consider this somewhat similar to the whois issue.

Also, I suspect there would be fewer concerns if the DNS-like database mainly referred to other databases, which can then be access-controlled as needed, and can evolve. This model might also allow for combining the CDS-like approach with the PKI approach for the same number, and allow for multiple operators for both models. The DNS (or similar) public database would only indicate which methods the number supports and redirect to the rendezvous or PKI service. I'm not sure that qualifies as DANE-like.

My general gut feeling is that we don't guess well on how public infrastructure evolves (or doesn't), so allowing for multiple outcomes and abstracting it, as well as allowing for functionality that gets better over time, might be more productive, as this allows for partial success, rather than just "exactly as planned" or "complete failure".

Also, keeping scale in mind helps: In our case, the scale for "number-holding service providers" is currently a few thousand, not millions, so management solutions that don't scale to millions are acceptable to get started. The backend process today is pretty manual (faxes, web pages and proprietary APIs), so expectations are fairly low.

Henning

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 14 Jun 2013 01:58:42 +0000

Inline below.

>keys -- they need to be publicly accessible.

Potentially, yes, callee-side enterprises and even callee UAs would be
able to validate. The original RFC4474 model describes an abstract
"verification service" function that can be performed either by an
intermediary or an endpoint. I've been assuming we'd retain that
architecture.

The RFC4474 model also has the concept that a URI is carried alongside the
signature, in a separate header called Identity-Info, to designate the
credential that was used to generate the signature. So yes, any
verification service needs to be able to resolve that URI, so it must be
public in at least that sense (and the verification service must trust
whatever trust anchor generated the credential on the other side of that
URI too). IF we were to transpose this to a DNS-like model, presumably the
Identity-Info header or its successor would be extended in some fashion to
allow it to designate that the DNS should be consulted.

>you mean; the one used by the Web seems to be it?

I mean a system that resembles that "bushy" system, yes. I imagine it
could encompass multiple roots. The secure-origins-ps document does
however contain some text to the effect that it would be real nice if we
could avoid having different roots claiming authority over the same name,
though, given what the consequences of that have been for web PKI.

And by PKI I here I'm not sure I mean any specific, integrated, operating
credential service as such, though certainly one that would use technical
components familiar to anyone who was familiar with web PKI.

>if they can't be retrieved, and in fact retrieved publicly.

Right, no, as I said above I was assuming something like Identity-Info
from RFC4474 would be available to facilitate retrieval.

>it's in the service of performing validation.

Sure, as specified in RFC4474, https or even cid (to designate a multipart
MIME body attached to the request) are examples of how the credential
fetch would happen. It is definitely in the scope of proposed work to
expand those options.

>retrieving whatever that information is.  That's all I meant by query

Sure, agreed, we're on the same page.

>message postings -- for this topic.  Hence, it needs a query service of

Gotcha.

>cut thing and bleed them dry.

Like I said, I'd hope we could benefit from some of the operational
lessons of web PKI while still retaining the tried and true technologies
that have succeeded here.

>necessary, but it's always extremely risky.  Extremely.  Always.

I want to make an allowance for DANE, especially where it can help with
greenfield SIP URIs rather than telephone numbers (e.g. Which cert should
I trust for sip:[email-masked]?). I do have some sense of the state of
DANE adoption, and I've certainly heard pushback from browser vendors and
others about its mid-term prospects.

But DANE wouldn't play a role in our story about how credentials are
managed for TNs unless of course we assume some ENUM-like TN hierarchy in
the DNS is a part of this key management solution.

>ideas, at least some of which are not yet close to being solid.

Um. In so far as there is IETF work already formulated, as far as I know
it's what's captured in the various drafts under discussion. I would say
you can judge for yourself how baked those ideas are. We have two proposed
areas of IETF work, one on providing a better in-band identity indication
in SIP, and another (more ambitious) effort to work on an out-of-band
solution. 

Both have some dependency on credentials which capture authority over
telephone numbers. The degree to which those credentials are a subject of
IETF work is less obvious to me. Let's assume we're talking about a PKI,
for the moment. In the web world, we have RFCs that talk about how you
need to process certs to make web security work, what information needs to
be in them and where it lives, and that is all clearly IETF work. But we
don't have RFCs that constrain the set of CAs to any particular vendor(s)
or that overly prescribe their operational environment, like how a CA
enrolls customers or sorts them into levels of assurance, say.

So right now in the proposed charter there is a placeholder for a document
that would cover the sorts of things about the key management system that
would be in the scope of the IETF, to foster interoperability of signers
and verifiers. I think we'd need to know more about where we're going
before I could tell you in more detail what the document would contain. So
yeah, a lot of things are not solid at this stage.

>administration and operations issues, let's hear it.

For what part of the work?

But I guess whichever part you mean, I don't think having a document with
that level of detail in hand is necessary to charter this proposed work or
to set a direction for it. If we assume the two main key management
options here are something like the DNS (public or private, with or
without DNSSEC/DANE) and something like a web PKI, I think both are fairly
well understood in the dimensions you describe here. I would be hesitant
to explore options where that didn't seem to be case.

Jon Peterson
Neustar, Inc.

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 14 Jun 2013 18:05:02 -0400

In line 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Thursday, June 13, 2013 9:13 PM
To: Dan York
Cc: [email-masked]
Subject: Re: [stir] current draft charter - ENUM and databases

Instead of looking at this as an ENUM-like problem, another angle is to
consider this somewhat similar to the whois issue.

Also, I suspect there would be fewer concerns if the DNS-like database
mainly referred to other databases, which can then be access-controlled as
needed, and can evolve. This model might also allow for combining the
CDS-like approach with the PKI approach for the same number, and allow for
multiple operators for both models. The DNS (or similar) public database
would only indicate which methods the number supports and redirect to the
rendezvous or PKI service. I'm not sure that qualifies as DANE-like.

[RS> ]  For what it's worth several of the designs for Carrier 6116 systems
relied specifically on this model where the tree was essentially a "thin
registry" and the E2U functions relied on NS records of one form or another
to indicate a level of redirection where the carrier of record (or whomever)
for a TN was presumed authoritative and you could also use other protocol
methodologies like HTTPS for access control.  The other model assumed the
"thick registry" where indirection was not present and it more closely
resembled a CDB model like the NPAC where the registry preformed the role of
validating the provisioning and the URI data was ultimately "pushed" into
the carrier networks or was available through other means to smaller
carriers by whatever protocol method they choose 6116,  SIP Redirect so long
as they were able to be "certified" for access as a" licensed" user etc.

I'll say it again if we deal with Telephony carriers provisioning within
OSS/BSS systems has to be taken into account.  In the US that is, I think
700 Million or so assigned TN's It would be easy for some folks to check
with the NANPA Administrator to find out how many are actually active. 

I'm not saying STIR should go down this path only that that idea has had
some serious proposals associated with it.  

My general gut feeling is that we don't guess well on how public
infrastructure evolves (or doesn't), so allowing for multiple outcomes and
abstracting it, as well as allowing for functionality that gets better over
time, might be more productive, as this allows for partial success, rather
than just "exactly as planned" or "complete failure".

Also, keeping scale in mind helps: In our case, the scale for
"number-holding service providers" is currently a few thousand, not
millions, so management solutions that don't scale to millions are
acceptable to get started. The backend process today is pretty manual
(faxes, web pages and proprietary APIs), so expectations are fairly low.
[RS> ] 
[RS> ]   +1 to that ...

Henning

On Jun 12, 2013, at 4:40 PM, Dan York wrote:

>> Agreed. Though I do think that even for the domain model, we could 
>> get some value from looking at DANE to improve the way that 
>> credentials are managed. Whether we put the keys in the DNS or just 
>> point to the approved cert by reference, we should probably have some 
>> means for the successor to
> Agreed (as you would expect me to say). I've been thinking about how 
> DANE could help here, but...
> 
>> But yes, for the telephone model it seems unlikely that casting these 
>> as domain names will get us very far.
> 
> ... I think this issue will get in the way right now.  As much as I 
> would love to see this as a good example of where DANE can help, I 
> still haven't been able to wrap my brain around how we could use DNS 
> for telephone numbers without running into all the exact same issues 
> that made public ENUM non-deployable.  :-(
> 
> I agree, though, that it would be helpful to have some way for a 
> header to alert relying parties to DANE in the event that there is a way
it can work.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 15 Jun 2013 14:56:53 -0400

> are routed and using this to prove possession of the number.

If you mean check return routability, Dan Wing had a draft on a return-routability check:
http://tools.ietf.org/html/draft-wing-sip-e164-rrc-01

Unfortunately, legitimate caller-ids are sourced by elements/entities that are not necessarily the same ones used for reaching the same number back.  For example the call-center scenarios, or doctor cellphone scenario, or even Skype-out scenario.

With regard to ViPR, I was under the impression ViPR's entire foundation for trust authority rested on the PSTN, with the original PSTN call and its caller-ids being part of the shared secret for later use in ViPR peer discovery and authentication.  If the caller-id's in the PSTN can be faked, ViPR would have been in very big trouble, because it would have enabled incorrectly finding and authenticating a malicious peer for that spoofed number and making all future calls back to that malicious peer for the number.  No? (maybe ViPR changed after I stopped following it)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 15 Jun 2013 15:06:18 -0400

On Jun 13, 2013, at 9:12 PM, Henning Schulzrinne <[email-masked]> wrote:

> Also, I suspect there would be fewer concerns if the DNS-like database mainly referred to other databases, which can then be access-controlled as needed, and can evolve.

But that's just moving the problem around, isn't it?

I mean ultimately some of us might want to actually implement the signing and verification into our systems.  If it uses public-key signatures, then we need a standardized protocol by which our systems can query for a certificate signed by some authority we trust for a given E.164 number.  If DNS tells us "go look over at FOO": then what standardized protocol does FOO use that we need to implement? why should we trust it for this caller-id? and how does it avoid the privacy problems and ownership problems and so on?  How do you even know we can reach FOO, if it's not necessarily publicly reachable?

I mean all I've heard is this: 
Step-1) Some magic happens somewhere, to enable the caller to generate a HTTP URL anyone can use**
Step-2) You get the HTTP URL in SIP from the caller through some chain of providers
Step-3) You send a GET request to above URL
Step-4) Some more magic happens**
Step-5) You get back a magic certificate
Step-6) You trust the magic was real, and use the cert to verify
Step-7) Ta-da! You've now verified the caller-id!
Step-8) Profit.

**note: please contact the universal magician so we can make the magic stuff happen for you and everyone else.

> My general gut feeling is that we don't guess well on how public infrastructure evolves (or doesn't), so allowing for multiple outcomes and abstracting it, as well as allowing for functionality tha…

I agree - we (the IETF) don't guess well on those things; we do much better if there's an existing solution we're asked to improve or standardize.  ISTM usually IETF BOFs for new work are more successful if they can point to existing proprietary solutions and say "see, it's possible".  But I don't think we have that for this work, do we?  So I think we have to discuss how such a thing would be possible, to assure ourselves we're not going to be wasting time.

> Also, keeping scale in mind helps: In our case, the scale for "number-holding service providers" is currently a few thousand, not millions, so management solutions that don't scale to millions are…

See, that matches up well with DNS too! The backend management/admin process is pretty manual afaict. ;)

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Jun 2013 09:38:27 -0700

On 6/13/2013 6:58 PM, Peterson, Jon wrote:
>> callee UAs.  That precludes any sort of private service.
...
> able to validate.

OK.  Again:  No "private" mechanisms.

> The original RFC4474 model describes an abstract

RFC 4474 has been standards track for 7 years; that's a long time.

What is its level of operational deployment and use, so far?  If the 
answer is "not much", then it's not clear that automatically invoking 
its application here is as comforting or facilitative as one might wish...

The cornerstone of RFC 4474 is an (independent) authentication service. 
  Where are it's details specified?  (Note that you correctly described 
RFC 4474 as describing an abstract service; that begs the question of 
the concrete details for its cornerstone. I'm also therefore assuming 
that Section 5 of that document is not the concrete service protocol 
details, since it's far from complete, in spite of having quite a bit of 
detail. A telling example is the text in Step 2: "Some possible ways in 
which this authentication might be performed include:")

If I understand the RFC 4474 model correctly, a validated Identity field 
has the semantics of asserting that the From field is valid.  So the 
assertion is not limited to the owner of the From field value.  Correct? 
  While such a model is understandable, it dramatically increases the 
reputation-management complexity of the task.  I'm not aware of an 
extant service over the public Internet of similar complexity.

Better still is that it's the entity making the assertion that tells the 
verifier where to look for verification information...  What's seems to 
be missing from the text in RFC 4474 is how the verifier can tell 
whether the credential is a valid authorization for use of the From 
field value. (If it wasn't clear before, now you can understand why I'm 
curious about the concrete details of this authentication service.)

> whatever trust anchor generated the credential on the other side of that

"in that sense"?  What other sense is possible and plausible?

Perhaps I missed the details about the credential use that are specific 
to this application.  Where are they provided, so that it's possible to 
tell how the credential is applicable for authorization validation?

(Naive question:  Are the details of the referenced URI use for 
credential acquisition sufficient and well-deployed?  It's a significant 
protocol mechanism for this service and I'm not clear that it's the 
mechanism or its semantics are standard practice.)

> allow it to designate that the DNS should be consulted.

This being a global, public, integrated query service, and the track 
record of deploying such things being highly discouraging, it's 
definitely good to stay with a proven, deployed service.  That's why I 
asked after the experience with the independent authentication service 
specified in RFC 4474.

> I mean a system that resembles that "bushy" system, yes. I imagine it

"Resembles" implies that it doesn't exist yet.  So it's subject to 
whatever challenges any other proposal must address.

> though, given what the consequences of that have been for web PKI.

That mostly says that the reality of this mechanism hasn't been 
established yet.  If it had, we'd know whether it had multiple roots and 
whether that approach scaled well.

The use of a multiple roots model for web validation is already showing 
some signs of stress.

> fetch would happen. It is definitely in the scope of proposed work to

https is not a query service.  In this context, it is at most a 
transport service, that might have a query protocol running on top of it.

> that have succeeded here.

Operational lessons abound.  Globally viable query services that are 
applicable to real-time use do not.

To date, the Web's PKI's has seen extremely narrow success. The biggest 
lesson to take from a mechanism intended to be so flexible, after this 
long, is that the continuing narrowness of current use should be a caution.

>> really will.  No, honest, it will.  And I hope I'm serious.
...
> the DNS is a part of this key management solution.

Ok.  So it's /not/ "potentially playing a role" for this discussion.

> it's what's captured in the various drafts under discussion.
...
> telephone numbers.

Unless I've missed something, this translates into creation of a new 
global PKI service for authorizing third-party validation of number use. 
  (The third-party aspect refers to the use of the Identity field I 
cited above.)

That's pretty ambitious, especially in terms of OA&M, nevermind viable 
trust/reputation.

> The degree to which those credentials are a subject of

Nevermind the IETF.  Credentials are at the heart of your proposal for 
this globally-integrated authorization service.  So the details had 
better be specified and reviewed somewhere.

> and verifiers.

"Foster" suggests that the service could be viable without that 
interoperability being standardized?

> I think we'd need to know more about where we're going

Any of it.

As I said, I had been told private and rather forcefully that this 
effort already had a solution in hand.

I'm trying to re-gauge things, now that's it's clear that none of the 
details are actually worked out yet.

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 16 Jun 2013 13:39:01 -0400

On Jun 16, 2013, at 12:38 PM, Dave Crocker <[email-masked]> wrote:

> What is its level of operational deployment and use, so far?  If the answer is "not much", then it's not clear that automatically invoking its application here is as comforting or facilitative as one might wish…

The answer is less than "not much"... more like "not at all".
I'd argue the reasons it has never been deployed are: (1) people didn't believe there was an identity spoofing problem yet, (2) it only really validates email-style identities such as [email-masked], not E.164 numbers, and (3) it's not deployable due to B2BUAs changing the fields it would sign.

> If I understand the RFC 4474 model correctly, a validated Identity field has the semantics of asserting that the From field is valid.  So the assertion is not limited to the owner of the From field value.  Correct?  While such a model is understandable, it dramatically increases the reputation-management complexity of the task.  I'm not aware of an extant service over the public Internet of similar complexity.
> 
> Better still is that it's the entity making the assertion that tells the verifier where to look for verification information...  What's seems to be missing from the text in RFC 4474 is how the verifier can tell whether the credential is a valid authorization for use of the From field value. (If it wasn't clear before, now you can understand why I'm curious about the concrete details of this authentication service.)

I think the general idea was a DKIM-like model, so if the From field value is [email-masked]', then you check the cert it points you to is for foo.com and signed by a CA you trust.  That works for email-style names like that, because you can verify it's coming from foo.com, and foo.com is the authority for a [email-masked]' name. (Assuming all CAs you trust are not compromised of course)

The hard part comes with E.164 numbers, because even if they appear as user@domain strings, like [email-masked]', most SIP devices would treat it as an E.164 number - and that means it's not scoped to foo.com at all but rather a separate, global namespace that foo.com has no natural authority for.  So with 4474 you'd have to believe foo.com is authoritative for the number based on reputation alone - i.e., you have a local list of domains you trust to claim E.164 numbers.  That would work for a limited number of domain names, for example the domain names of the major carriers within a country, but it would fall apart quickly if we ever want Enterprises to sign, or international scenarios to work.

So one proposal so far is that there would be certs which identify the E.164 numbers they're authoritative for (in a CN/SAN field for example), and that cert would be signed by some CA (or chain leading to one) that you trust.  If it's a chain rather than directly signed by a CA, then it's not clear how one goes about retrieving the certs for the chain's links, and doing so could cause unacceptable delay.  It also means we need revocation checks for the chain.  And I'd argue the management aspects for this thing would be just as difficult as anything else proposed so far.

-hadriel

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 16 Jun 2013 17:46:34 +0000

Hello all,

Charter:
1. The issue/problem is "spoofing", and not routing nor media security.
2. And WRT spoofing, IP to IP spoofing solution is the low hanging fruit, and we need to have a timely solution (timely includes standard, deployable, including affordable) 
3. validation is associated with authentication, which is best done by the carrier or enterprise (though enterprises are a source of the robo-calls), but should be allowed to be done by callee UAs (IF trusted, this is a big IF)
4. ISUP cannot be modified, FULL STOP 
5. Creatively using/reusing an existing ISUP parameter/field could only between trust domains. (WTS PAI works between trust domains)

Regards,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Sunday, June 16, 2013 12:38 PM
To: Peterson, Jon
Cc: [email-masked]
Subject: Re: [stir] current draft charter

...

...

...

Any of it.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Jun 2013 10:52:32 -0700

On 6/16/2013 10:39 AM, Hadriel Kaplan wrote:
>> Better still is that it's the entity making the assertion that
>> tells the verifier where to look for verification information...
>> What's seems to be missing from the text in RFC 4474 is how the
>> verifier can tell whether the credential is a valid authorization
>> for use of the From field value.
...
> I think the general idea was a DKIM-like model, so if the From field
> value is [email-masked]', then you check the cert it points you to is
> for foo.com and signed by a CA you trust.  That works for email-style

We're in a space that requires quite a bit of care and precision, so 
forgive my pedantry when I note that DKIM does not have anything to do 
with the address in the rfc5322.From field, contrary to popular beliefs.[*]

DKIM has its own identifier field (the d= parameter of the 
DKIM-Signature header field).  It's entirely independent of all other 
identification information in the message.  But note that DKIM semantics 
are completely different than what is proposed for STIR.  The signer in 
DKIM merely asserts "some responsibility" for the message; this 
pointedly does /not/ include validating any of the message content, such 
as the From: address.

The more recent DMARC, on the other hand, does assert "alignment" 
between the d= value and the From: field domain.  However DMARC is 
intended for narrow use.  In particular, it does not work for messages 
that get re-posted, such as mailing lists.  I think that such cases 
match concerns for SIP/PSTN gateways.

> So one proposal so far is that there would be certs which identify
> the E.164 numbers they're authoritative for (in a CN/SAN field for
> example), and that cert would be signed by some CA (or chain leading
> to one) that you trust.  If it's a chain rather than directly signed
> by a CA, then it's not clear how one goes about retrieving the certs
> for the chain's links, and doing so could cause unacceptable delay.
> It also means we need revocation checks for the chain.  And I'd argue
> the management aspects for this thing would be just as difficult as
> anything else proposed so far.

Ack.  FWIW, I've always viewed the administrative requirements for DKIM 
far, far more challenging than the signing/verifying mechanisms.  After 
some years of extensive deployment experience with DKIM, my opinion has 
not changed...

d/

[*] The DKIM signing hash does include the From field, but that's 
different from using the value semantically.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Jun 2013 10:53:05 -0700

...

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 Jun 2013 17:39:14 -0400

> But that's just moving the problem around, isn't it?

Yes, in the spirit of "All problems in computer science can be solved by another level of indirection". My hunch is that directories/databases/DNS that try to enforce policy are likely to fail, but relatively policy-neutral ones have a better chance.

> 
> I mean ultimately some of us might want to actually implement the signing and verification into our systems.  If it uses public-key signatures, then we need a standardized protocol by which our systems can query for a certificate signed by some authority we trust for a given E.164 number.  If DNS tells us "go look over at FOO": then what standardized protocol does FOO use that we need to implement?

Wouldn't plain HTTPS do the trick, as in 4474?

> why should we trust it for this caller-id? and how does it avoid the privacy problems and ownership problems and so on?  How do you even know we can reach FOO, if it's not necessarily publicly reachable?
> 

I don't think it's quite *that* bad. What I've heard so far is some version of:

* Very small number of entities (1-10ish per country code) sign "public key X is entitled to use TN [range] A". The cert is conveyed in some proprietary fashion to the number holder, similar to how today's web CA's deliver certs to their customers. A single entity can have any number of public keys, if they want to obscure their number holdings or for operational reasons. Working group to-do: Define appropriate X.509 content for numbers.

* Small number of "convenience" database providers host certs, including possibly carriers (if they don't care about identifying themselves). The database providers offer scaling and access control. National policy decides what kind of access needs to be granted to whom (fees, non-discrimination, etc.).

* Certs are retrieved via the HTTPS URL that's included in 4474bis header. Clearly, the entity doing the signing has to know where to find the cert, but as long as the number of entities signing is small, this seems quite manageable.

* The validator knows trusted root CAs. Future work: A DANE-like mechanism to list those, e.g., based on prefixes (e.g., +1 might list the number administrator(s) in the US and other +1 countries). As long as the number of CAs for each country code prefix is very small (which seems likely, at least initially), there's no great need to have references for each TN, while still preventing the Nigerian NRA signing +1 numbers.

It might be interesting to see how much of EPP is applicable here.

As far as I can tell, assuming 4474bis header mods and the X.509 customs, you could build a system that allows interoperable validation. The only proprietary piece, initially, would be the cert delivery to the number holder.

Is that a bit less magic?

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 Jun 2013 17:54:30 -0400

While you can spoof the caller ID, you (generally) cannot spoof the calls that reach you, unless you can get the real number holder to redirect calls to you.

According to a brief discussion at the FTC robocalling workshop [http://www.ftc.gov/bcp/workshops/robocalls/], the latter is actually not too far-fetched, particularly since many such redirection settings are now just web configurations or are done via apps on a cell phone. Thus, you don't have to compromise the carrier infrastructure to redirect calls, just an end user. Probably not a major threat yet for a call center or large-business number at the moment, but possibly for an individual or small business.

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 16 Jun 2013 22:31:58 +0000

No, I didn't mean return routability as a real-time check during call
processing a la Jabber, I meant some system of proving possession of a
number as a means of enrolling into the PKI (or whatever other key
management system there may be). ViPR's technique is one example; other
examples would be things like sending an SMS to a smartphone with a link
you could click to prove possession. In the email world, you might compare
this to S/MIME credentials you receive in return for proving you control
an email address. I don't think we need to prescribe what the possible set
of enrollment mechanisms are here, just to say that there exist
alternative ways to enroll other than top-down delegation. And I don't
mean to suggest that credentials secured for this purpose would only be
useful in the out-of-band solution, either.

Just to second Henning here, faking the calling party number is a very
different matter than forcing calls for a number to be routed to a
different endpoint. Subverting VIPR required doing the latter, not the
former. This is the difference between arbitrarily populating the From
header field of SIP with "sip:[email-masked]" to pretend to be me, and
then then making it so when someone else sends a request to
sip:[email-masked] it ends up ringing your phone. One is trivial, the
other not so much. Now that much said, there were lots of lingering
question in VIPR about what happens when you're not directly connected to
the PSTN, due to SIP trunking or what have you, and how VIPR endpoints can
be assured that PSTN routing was actually invoked. This is something we'll
need to be mindful of.

Jon Peterson
Neustar, Inc.

On 6/15/13 11:56 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>Unfortunately, legitimate caller-ids are sourced by elements/entities
>that are not necessarily the same ones used for reaching the same number
>back.  For example the call-center scenarios, or doctor cellphone
>scenario, or even Skype-out scenario.
>
>With regard to ViPR, I was under the impression ViPR's entire foundation
>for trust authority rested on the PSTN, with the original PSTN call and
>its caller-ids being part of the shared secret for later use in ViPR peer
>discovery and authentication.  If the caller-id's in the PSTN can be
>faked, ViPR would have been in very big trouble, because it would have
>enabled incorrectly finding and authenticating a malicious peer for that
>spoofed number and making all future calls back to that malicious peer
>for the number.  No? (maybe ViPR changed after I stopped following it)
>
>-hadriel
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 16 Jun 2013 23:27:55 +0000

>>its application here is as comforting or facilitative as one might wishŠ
>
>I'd argue the reasons it has never been deployed are: (1) people didn't
>believe there was an identity spoofing problem yet, (2) it only really
>validates email-style identities such as [email-masked], not E.164
>numbers, and (3) it's not deployable due to B2BUAs changing the fields it
>would sign.

I agree with those three reasons. I'd further say (1) is part of a broader
trend in which the deployment community hasn't shown much interest in the
security mechanisms available in SIP versus operating in effectively
private environments. These identity spoofing concerns show a limitation
of transitive trust in these private communities.

>> If I understand the RFC 4474 model correctly, a validated Identity
>>field has the semantics of asserting that the From field is valid.  So
>>the assertion is not limited to the owner of the From field value.
>>Correct?  While such a model is understandable, it dramatically
>>increases the reputation-management complexity of the task.  I'm not
>>aware of an extant service over the public Internet of similar
>>complexity.

We weren't exactly proposing a domain assurance council or something like
that. The authorization decision was supposed to be checking the reference
integrity of the domain in the From header field against the domain in the
subjectAltName of the cert (provided the cert is valid and the root
trusted): if there's a match, then this was signed for by the right
entity, if not, then not. I'm not sure what you mean by "not limited to
the owner of the From field value." In so far as the originating domain is
the "owner," then only they can sign it, if that's the limitation you're
concerned about.

>> 
>> Better still is that it's the entity making the assertion that tells
>>the verifier where to look for verification information...  What's seems
>>to be missing from the text in RFC 4474 is how the verifier can tell
>value is [email-masked]', then you check the cert it points you to is for
>foo.com and signed by a CA you trust.  That works for email-style names
>like that, because you can verify it's coming from foo.com, and foo.com
>is the authority for a [email-masked]' name. (Assuming all CAs you trust
>are not compromised of course)

Correct. The entity making the assertion tells the verifier where a cert
can be fetched, in the case that the verifier doesn't already have a cert
for the signer. Whether the cert is valid, or the CA itself is trusted by
the verifier, is however a different and prior question.

>The hard part comes with E.164 numbers, because even if they appear as
>user@domain strings, like [email-masked]', most SIP devices would
>treat it as an E.164 number - and that means it's not scoped to foo.com
>at all but rather a separate, global namespace that foo.com has no
>natural authority for.  So with 4474 you'd have to believe foo.com is
>authoritative for the number based on reputation alone - i.e., you have a
>local list of domains you trust to claim E.164 numbers.  That would work
>for a limited number of domain names, for example the domain names of the
>major carriers within a country, but it would fall apart quickly if we
>ever want Enterprises to sign, or international scenarios to work.

Right. At the risk of waxing philosophical about it, I'd say that RFC4474
took for granted the baseline assumption that RFC3263 would be how SIP
requests were routed. If you assume SIP requests get routed by taking the
domain portion of the request-URI and looking it up in the DNS to locate a
SIP server, RFC4474 probably isn't a bad fit for what you do. If however
SIP requests get routed based on the user portion of the Request-URI (like
a TN) without reference to the DNS, then probably having a domain sign for
identity won't be appropriate. JDR's I-D on rfc4474-concerns is pretty
much all about that.

>So one proposal so far is that there would be certs which identify the
>E.164 numbers they're authoritative for (in a CN/SAN field for example),
>and that cert would be signed by some CA (or chain leading to one) that
>you trust.  If it's a chain rather than directly signed by a CA, then
>it's not clear how one goes about retrieving the certs for the chain's
>links, and doing so could cause unacceptable delay.  It also means we
>need revocation checks for the chain.  And I'd argue the management
>aspects for this thing would be just as difficult as anything else
>proposed so far.

Although I'm not the expert, my understanding is that there are various
cert chain compression techniques that could be applicable here. I've
squinted a bit at OCSP and other possible real-time revocation checks for
this as well.

The exact amount of tolerable delay is a very interesting dimension of
this problem space. I suspect we have a considerable amount of time, given
all the human expectations about both post-dial delay and the wait for
someone to pick up after altering. I think it's enough time to perform
some non-trivial operations.

But I do agree that there's no such thing as a free lunch, and that
implementing a credential system for telephone numbers, even just in a
single nation state, is operationally complex. In my day job, we have a
few different credentials today that carriers can use to interface with
various NANPA/NPAC system, and some of them already have requirements
similar to what we've discussed here, like delegation for example. I think
if we go down this STIR path, at the end of the day we'll end up with a
system that relies on many numbers aggregated behind a single credential,
on signatures and validations being performed by network elements much
more so than endpoints, and similar optimizations. Provided we can do this
without making e2e security impracticable, I think we'll be on the right
track.

Jon Peterson
Neustar, Inc.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 16 Jun 2013 23:45:29 +0000

John,

You said, 

[mcd] - the issue is not between trusted carriers, but rather traffic of the wholesale/enterprise.

{mcd} - further the charter needs to focus on the violating parties.

Regards,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Sunday, June 16, 2013 7:28 PM
To: Hadriel Kaplan; [email-masked]
Cc: [email-masked]
Subject: Re: [stir] current draft charter

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 17 Jun 2013 00:21:53 +0000

>the wholesale/enterprise.

I'm sure you're right, but from a technology perspective it's the
protocol-level trust itself that we can improve here.

>{mcd} - further the charter needs to focus on the violating parties.

Again, I think the IETF can only focusing on designing technology that
doesn't suffer from these problems. Violating parties will not exactly be
early adopters of protocols that constrain them, so we can't expect to
charter work that they will abide by. What we can do is try to make the
identity story better all around, so that violating parties are
marginalized.

But if there's something specific in the charter text you'd want to see
different to capture this, let me know.

Jon Peterson
Neustar, Inc.

>Peterson, Jon

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 17 Jun 2013 00:31:07 +0000

So, we define a charter to a solution that we want to get at, versus in REALLITY need to solve... I am simple, so please explain...

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Sunday, June 16, 2013 8:22 PM
To: DOLLY, MARTIN C; Hadriel Kaplan; [email-masked]
Cc: [email-masked]
Subject: Re: [stir] current draft charter

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Jun 2013 17:48:54 -0700

> We weren't exactly proposing a domain assurance council or something like

DAC merely worked on a standardized query mechanism; it was not a 
service.  But as far as defining a reputation-reporting service, 
actually you are.

You are defining the ability of a third-party to vouch for a caller-id 
value that is not (necessarily) their own.

That's different from defining a mechanism that let's someone assert 
direct ownership.

> trusted): if there's a match, then this was signed for by the right

That seems to be the first reference to the specific field in the cert, 
and assigning specific semantics to it. Any chance this is part of an 
existing spec relating to STIR?

In any event, note that a premise of the model you've been describing is 
that the guy being validated gets to tell you where to look for the 
validation.  That seems an odd trust model. I'd normally expect the 
verifying agent to choose the server with validation information separately.

> the "owner," then only they can sign it, if that's the limitation you're

That's not what RFC 4474 specifies, according to my reading of it:

    Section 4:

    The authentication service authenticates Alice (possibly by sending a
    Digest authentication challenge) and validates that she is authorized
    to assert the identity that is populated in the From header field.

"authorized to assert" does not have the same semantics as "is the owner 
of".

    Section 5, Step 2:

    The authentication service MUST determine whether or not the sender
    of the request is authorized to claim the identity given in the
    identity field.

ditto.

What you've defined permits multiple, separate third-parties to be able 
to make validity assertions about the use of the caller-id value.

> the verifier, is however a different and prior question.

When I ask someone for money, I think it's really nice that I get to 
tell them who to talk to, to vouch for my credit-worthiness...

> requests were routed.

The idea that an authorization-checking mechanism would somehow depend 
upon the SIP routing service doesn't make obvious sense to me. 
Consequently I do not see how it should/can/will affect choice of the 
validation query service.

> squinted a bit at OCSP and other possible real-time revocation checks for

The essential point behind this line of discussion is that an entirely 
new cert semantic and trust structure will need to be invented and deployed.

Note that this must be globally integrated and openly accessible.

> single nation state, is operationally complex.

+1

d/

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 17 Jun 2013 01:50:51 +0000

>value that is not (necessarily) their own.

I'll speak this below, but I don't think we're on the same page here about
who is a third party versus a first party to the names in question.

>existing spec relating to STIR?

It's in RFC4474, and as far as I remember not nuked (yet anyway) from
RFC4474bis.

>verifying agent to choose the server with validation information

I addressed that in my last mail. The "guy being validated" provides a
pointer to the cert, yes, but whether or not you trust that cert is a fact
about your relationship to the CA that issued it. The relying party only
dereferences the Identity-Info header if they don't already have the cert
by some other means. What happens if the guy being validated provides a
problem cert in that link? Then the validation fails and nothing untoward
happens. This is not a problem.

>"authorized to assert" does not have the same semantics as "is the owner

Alice is not the signer, or owner, in this use case; the authentication
service is implemented by an intermediary. The intermediary is the "owner"
(in the sense I'm guessing you) of the domain name that appears in the URI
Alice puts in her From header field. I don't want to get too entrenched in
terminology that we're unlikely to use here, but Alice only "owns" her URI
to my mind in so far as it was allocated to her by the owner of the domain
name  - they get to choose who gets to be [email-masked] and who gets to
be [email-masked]. If they decide they don't like me anymore,
[email-masked] can vanish in the blink of an eye.

>to make validity assertions about the use of the caller-id value.

What we've defined allows the owner of example.com to decide who gets to
be [email-masked] and who gets to be [email-masked]. It doesn't allow
multiple entities to be example.com.

There are harder edges in this neighborhood when we look at subdomains
(sip.example.com) and other delegation structures, but at the level you're
discussing, it doesn't have the properties you're describing.

>tell them who to talk to, to vouch for my credit-worthiness...

I've already explained above (and in my previous mail) that the ability to
supply a pointer to a certificate does not cause relying parties to trust
that certificate - trust anchors provisioned at the relying parties do. If
the signer provides an untrustworthy certificate, then it won't be trusted.

Now that much said, if the relying party trusts thousands of trust anchors
a la web PKI and we're in that space, then sure, there's always the
potential for mischief we've seen lately in web PKI. That potential would
exist regardless of the presence of the Identity-Info header and its URI.
The problem statement draft already discusses this and talks about how, if
there would be certificates for telephone numbers, we should try to
address it.

>validation query service.

It's a subtle point, again dancing around the questions you were raising
about "owning" names. One of the reasons RFC4474 adopted the design it did
was because the "owner" of example.com controls what traffic goes to jon
versus dave in the RFC3263 model, and authenticates jon or dave when they
register to receive traffic. The trust relationships that were built for
that served as a model for the use case you were reviewing above, where
Alice authenticates to a local intermediary that instantiates the RFC4474
authentication service role. In cases where those registration concepts
and routing concepts don't conform to the expectations of RFC3263 (which
includes routing to E.164 numbers), the assumptions of RFC4474 break down.
Just giving more color on why RFC4474 didn't set the world on fire.

>Note that this must be globally integrated and openly accessible.

I'm not sure it's a new cert semantic, or a new trust structure, or that
something needs to be "invented" to support this. Definitely agreed
something needs to be deployed, and that it needs to be openly accessible.
Global integration will come if it's successful, it won't come if it's not.

Jon Peterson
Neustar, Inc.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Jun 2013 22:32:29 -0700

> who is a third party versus a first party to the names in question.

Note that I'm not stating my own preference, but rather what the spec says.

> about your relationship to the CA that issued it.

Then what is the point in having the pointer, rather than letting the 
validator decide where to get the cert from?

I suspect the answer is that it's a search efficiency hack, rather than 
a required mechanism, helping to find a knowledgeable CA amongst 
potentially thousands.

> [email-masked] can vanish in the blink of an eye.

That has become nicely confusing (for me.)

The basic entity of interest is the phone number.  The basic ownership 
of internet is for the phone number.

Who owns the validating service is (or, for this topic, should be) 
secondary.

> multiple entities to be example.com.

That's not the constraint I read in the RFC.  What you've just described 
here is ownership of the string being validated.  In the SIP case, that 
means ownership of the phone number.  RFC 4474 does not specify that, 
according to my reading of it.

> potential for mischief we've seen lately in web PKI.

As I understand it, this model of thousands of trust anchors is showing 
some very rough edges for scaling, accuracy, and scope. I believe it 
also has had a single semantic, unrelated to the one being proposed.

> register to receive traffic.

I think I'm beginning to understand:  The provider that is giving SIP 
service is the one that vouches for its use.  In effect, the provider 
has the authority of the number owner, rather than the user to whom the 
number is assigned.

That's not subtle; it's quite basic.  It would be like requiring that my 
ISP be the one that vouches for my use of my domain name.

> The trust relationships that were built for

This sounds like a transitive trust model based on trust amongst telcos.

+1

> something needs to be "invented" to support this.

Feel free to point to instances of each that are deployed and used.

Absent that, we can all be quite sure that all three assertions are... 
valid.

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Jun 2013 02:18:13 -0400

> Wouldn't plain HTTPS do the trick, as in 4474?

Of course that's one possibility - my only point was we can't just make the solution be "have DNS refer to another database"; we have to specify what that referred-to database protocol would be so we can use it.  And if we're going to do that, then just stick that URL in the Identity-Info header and avoid DNS.  One of the advantages of the DNS proposal was the DNS would *be* the database access protocol, and we wouldn't need a URL in the Identity-Info header - we wouldn't even need the header at all.

> * Very small number of entities (1-10ish per country code) sign "public key X is entitled to use TN [range] A". The cert is conveyed in some proprietary fashion to the number holder, similar to how…

The "magic" part of that which I was referring to was how a CA would know what entities are entitled to what TNs, and for which various country-codes.  For example, let's assume Thawte is a trusted CA for E.164's for +1 NANP... when some mom&pop "carrier" gets a number ported into them, how does the process work to get Thawte to agree that mom&pop now owns the ported number, and that the previous CA (if it's different) revokes it for its previous carrier?  When mom&pop get a number block, how does Thawte verify that?

> * Certs are retrieved via the HTTPS URL that's included in 4474bis header. Clearly, the entity doing the signing has to know where to find the cert, but as long as the number of entities signing is…

I'm not so sure.  If we actually use the literal URL to get the cert, then all the HTTPS servers have to be accessible to any querying device of any carrier in the World.  That doesn't scale if "access control" is involved and charging for it.  If we expect some service bureaus act as middlemen for this retrieval instead, to alleviate the headache of billing and access control between all carriers in the world, then we have to create some standard way for the devices in the carriers to talk to the middlemen and give them the URL for each call and get the cert or have the signature verified; and that's assuming that their particular middleman has a relationship with all databases in the World to access the URL, or else they too have to use a protocol to give the URL to another middleman, etc.

Besides which the possible charging models for this thing probably needs to be discussed.  I'm not sure it makes sense for the caller side to charge the called side to verify the caller-id it sent; nor vice-versa.  I'm all for letting each nation decide how to manage their numbers and certs and authority model and so on, but letting each determine fees for every other nation worries me in terms of the viability of getting this to happen.  I'm no expert in that area, but I would think it would be a lot messier to get this stuff done if charging money between nations is involved.  It'd almost be better to make that not possible, and if a nation doesn't want to play along and have its caller-ids verifiable by everyone else then so be it.

> Is that a bit less magic?

Almost all of that lends itself to having the certs simply be in the DNS.  There's nothing secret about the certs - they don't need to convey any information about the organization that has the E.164 and signs the SIP message using the private key.  And the organization that has the E.164 and signs doesn't even need a copy of the cert, because they never give it to anyone themselves - they use the private key to sign the SIP message stuff, while the public DNS serves the cert and thus its public key to anyone asking; the only thing they need is a way to give the public key (or pre-signed cert info) to the DNS to be installed there for the E.164 numbers they own.

The advantages of using the DNS as the repository for the cert data, instead of giving an HTTP URL in a header to get a cert from, are:
1) There's no header needed for carrying a URL.
2) There's no need to worry about revocation, because the instant a number changes ownership, the DNS entry of its cert changes.
3) There're far fewer potential CAs to have to trust - ideally only one per country-code, the same one that's authoritative for its country-code branch of the DNS tree; and we'd be using DNSSEC so its cert is in the DNS, and it's the signer of its entries.  In fact you might be able to just have the raw public key in the DNS instead of the whole cert, because the rest of the DNSSEC-provided info is redundant with the stuff in a cert for this use-case.
4) It's generally faster, and with tighter client control for retransmit/timeout because it's UDP.
5) For bigger carriers, they can have local DNS servers with copies of the frequently accessed data (e.g., local nation E.164s) that their verification systems can query.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Jun 2013 02:18:28 -0400

> some non-trivial operations.

I've been thinking about that and I'm not sure we actually have much time.  I've been looking at what the CNAM guys are doing, and at least one them (used in a large mobile provider) goes so far as to sometimes skip it on the INVITE and send their CNAM info in an UPDATE or INFO afterwards due to the delay.  I.e., they have us queue the INVITE while they retrieve the CNAM info for the given caller-id, but if they take too long then we send the INVITE and send their results separately afterwards in another message.  Another operator that uses private ENUM for CNAM querying also sets very low timeouts on the query, and just don't provide a calling name if it times out (ie., the INVITE gets sent on without it, and nothing updates it later).

Also, Brian at one point mentioned transit providers possibly doing the verification check as well, and that might be difficult if it takes non-trivial time I think, because one of the SLA measurements they get ranked on is how fast they route their calls onward.  (Besides which they're never involved this type of stuff so I'd doubt they'd start now anyway.)

Anecdotally, I find that intra-nation calls get to ringing stage much faster than international calls, so people are probably ok with international caller-id verification taking longer.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Jun 2013 02:46:15 -0400

On Jun 17, 2013, at 1:32 AM, Dave Crocker <[email-masked]> wrote:

> Then what is the point in having the pointer, rather than letting the validator decide where to get the cert from?
> I suspect the answer is that it's a search efficiency hack, rather than a required mechanism, helping to find a knowledgeable CA amongst potentially thousands.

No, for 4474 he was talking about the cert belonging to the SIP-identity hash signer, not the CA that signed that cert as the trusted root/issuer.  For example if you receive a message with the From of [email-masked]', then foo.com needs to tell you where to get its cert to prove it is foo.com that signed the SIP From of [email-masked]'.  As the verifier, you have no direct relationship with foo.com, nor know which trusted CA foo.com uses.  So foo.com stores its cert at some web server, which it tells you to get the cert from with this URL.  If the URL was changed by an evil middleman to give you a different cert, then the cert won't be for 'foo.com' so verification correctly fails.

An alternative could have been to just have you automatically go to 'https://foo.com/sipcert' or some such thing, or have you look for some DNS record for foo.com to tell you where to get the cert.  But with the URL being sent in the message then foo.com could use different certs for different calls; for example if it uses different PBXs in multiple branch offices, it could give them each unique keys to sign the SIP messages with, without having to use separate domain names in its SIP From.

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 17 Jun 2013 06:56:01 +0000

On 6/16/13 10:32 PM, "Dave Crocker" <[email-masked]> wrote:

>[snip]

I wouldn't say that's an unfair characterization. It gives the
verification service quick and easy access to the right cert, provided of
course that the signer provides the right cert. Otherwise there would have
to be some kind of cert discovery process implemented by the verification
service.

>of internet is for the phone number.

Perhaps this has become confusing for you because RFC4474 doesn't make any
real provision for telephone numbers, but you're trying to read telephone
numbers into the RFC4474 text. Think like RFC4474 is only talking about
user@domain URIs. The proposed STIR work is, in part, to broaden the scope
of identity protection to include telephone numbers.

>according to my reading of it.

RFC4474 does not cover telephone numbers - we propose to fix that with
this new work.

>also has had a single semantic, unrelated to the one being proposed.

Right, the rough edges there are why the current problem statement for
STIR suggests we do things a bit differently.

>has the authority of the number owner, rather than the user to whom the

Almost - again, RFC4474 doesn't cover telephone numbers, and neither did
RFC3263.

>ISP be the one that vouches for my use of my domain name.

If your ISP actually owned your domain name instead of you, sure. If in
fact you own your own domain name, RFC4474 lets you (as in, your UA) act
as your authentication service. The authentication service is a logical
function that can be instantiated by either the UA or an intermediary. Who
should do it depends pretty much entirely on who owns the domain name.

Do I own the email address "[email-masked]"? No, Neustar owns
it. I use it at their pleasure. If our IT staff wanted to, they could send
all my email to someone else in the company. I do own my own domain names,
though, and I control who gets what account under them. Since there are
similar use cases for SIP, we included this use case in RFC4474.

>This sounds like a transitive trust model based on trust amongst telcos.

Not really. example.com gets to vouch for example.com addresses, and the
signature they add is end-to-end visible to verification services
implemented at intermediaries or at terminating endpoints.

>Feel free to point to instances of each that are deployed and used.

The structures that underly trust in the proposed STIR work are simply the
extent ones in the telephone network. There are currently number block
assignees, delegates of those assignees, and ultimately end users who
possess numbers. Databases exist that contain all that information, and
credentials exist that reflect those scopes of authority. The proposed
work is only to leverage those structures.

Certs have I believe had the capacity to contain telephone numbers since
X.520 or so.

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 17 Jun 2013 07:07:23 +0000

I think the advantages below, with the exception of 4, would be true of
any golden root we created for whatever protocol, be it HTTP or something
else. I'm sure I could define an HTTP golden root such that the
verification service could synthesize the proper fetch request from the
URI in the From with an Identity-Info, one that updated in real time so
you never needed to worry about revocation, one for which there was only
one CA, and which you could locally cache (well, okay, 5 does conflict a
bit with 2). 

Also, all of the (snipped) concerns you raised about access control,
middlemen, charging, etc are just as likely to arise for DNS as for any
other proposal.

Now that much said, I'm not convinced HTTP is the end-all-be-all for
Identity-Info. I had high hopes for CID when RFC4474 was written. But more
seriously, I don't think we should rule out DNS as an access method for
credentials at this stage. Even if we were just copying public keys out of
certs from a cert store into the appropriate node of the DNS, and totally
duplicating effort, if that helped adoption for some use cases it would
probably be worth it. Maybe some of Henning's "convenience" databases
could take this form.

Jon Peterson
Neustar, Inc.

>The advantages of using the DNS as the repository for the cert data,
>instead of giving an HTTP URL in a header to get a cert from, are:
>2) There's no need to worry about revocation, because the instant a
>number changes ownership, the DNS entry of its cert changes.
>3) There're far fewer potential CAs to have to trust - ideally only one
>per country-code, the same one that's authoritative for its country-code
>branch of the DNS tree; and we'd be using DNSSEC so its cert is in the
>DNS, and it's the signer of its entries.  In fact you might be able to
>just have the raw public key in the DNS instead of the whole cert,
>because the rest of the DNSSEC-provided info is redundant with the stuff
>in a cert for this use-case.
>5) For bigger carriers, they can have local DNS servers with copies of
>the frequently accessed data (e.g., local nation E.164s) that their
>verification systems can query.
>
>-hadriel
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 17 Jun 2013 07:24:36 +0000

I don¹t think I previously replied to say, works for me. Those fixes are
added.

Jon Peterson
Neustar, Inc.

On 6/12/13 2:50 AM, "[email-masked]"
<[email-masked]> wrote:

>Jon,
>
>The only comment I would have is on the general phrasing of the first
>paragraph, which at least for an outsider, may sometimes seem to be
>focused on anonymous calls rather than on 'illegitimate' CPNs in general
>(whilst the "more serious" problems that are listed there have indeed
>more to do with the latter than the former).
>
>If this restriction is not deliberate, maybe you want to say "can be
>hidden or forged" instead of only "hidden" and "that obscure or falsify"
>as opposed to only "obscure".
>
>Regards,
>
>Philippe Fouquart
>Orange Labs Networks
>+33 (0) 1 45 29 58 13
>
>with email: bulk unsolicited commercial communications remain a challenge
>for the traditional telephone network largely because the source of calls
>can be hidden. Others are potentially more serious: voicemail hacking,
>impersonating banks and similar attacks are becoming commonplace. The
>technologies that obscure the caller's identity are frequently gateways
>between the telephone network and the Internet.
>
>when one side of a call is in the PSTN - or potentially even both. This
>study ways to rebalance the requirements for the scope of RFC4474's
>find privacy-friendly solutions that leak minimal information about calls
>to third parties.
>
>__________________________________________________________________________
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>As emails may be altered, France Telecom - Orange is not liable for
>messages that have been modified, changed or falsified.
>Thank you.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Jun 2013 08:03:06 -0400

It might be helpful to explicitly distinguish three models, independent of whether the cert is stored in DNS or some HTTP-accessed data store:

(1) Single CA per country code (CC); no chaining. All delegations and multiple-use are explicitly generated by the CC CA, based on requests by the primary holder of the number.

(2) Single CA per country code, but with chaining.

(3) Lots of CAs per country code, e.g., for proof-of-possession systems. (Example: Existing webCAs get into the E.164 validation business.)

I think we've been commingling the three in discussion, making the trade-offs harder to identify.

On #2 below (expiration), I'm not sure that it matters whether the entry is stored in DNS or data store. With DNS and HTTP, you have to deal with caching just the same.

Also, for DNS, it would be helpful to be specific whether this is run by one entity or, if not, how entries are doled out, given the lack of natural hierarchy.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Jun 2013 08:14:19 -0400

I wouldn't be surprised if the large carriers cache all certs locally. For +1, I'd suggest that's less than a TB, i.e., a single disk, even if every number has their own cert, rather than number ranges. They would then subscribe to a notification service for any porting-related changes, given that such changes affect a very small fraction of the numbers (quarterly churn of mobile carriers is about 1-2%). This can all be done within the carrier network, i.e., without affecting the external public data interface.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Jun 2013 08:41:06 -0700

> STIR suggests we do things a bit differently.

In looking over the draft charter that you circulated last Tuesday, I'm 
not seeing text that obviously covers this.  In contrast, all of the 
list discussion about CAs appears to be based on the current model that 
uses very large numbers of anchors.

Even with text in the charter, the deeper question is what changes are 
feasible to the current model that are viable with the scale, diversity 
and reliability needed for the proposed service?  Absent a vetted design 
approach, it won't mean much to have a charter task covering it; in fact 
it will be more appropriate as an IRTF task...

...
> it.

Number portability changes this. The number does not belong to the 
service provider.

> Not really. example.com gets to vouch for example.com addresses, and the

Unlike email addresses, the relationship between the service provider 
and the user is not built into the identifier.  What you've been 
describing is an unspecified service in the background that establishing 
this relationship.  It's key because it authorizes the provider to vouch 
for use of the number.

> extent ones in the telephone network.

By way of considering edge cases, to the extent that this mechanism is 
going to validate uses of numbers for calls that do not originate from 
their home -- such as the mobile physician calling from someone else's 
phone -- the extant trust mechanisms don't cover them.

In any event, the considerable barrier to adoption you've just described 
is adoption by all telcos.

> There are currently number block

Forgive me but I don't see any of that in the charter or discussions so 
far.  It seems to be left as the "then a miracle happens" part of the 
specification.  As such, it isn't possible to evaluate its practicality.

On 6/17/2013 12:07 AM, Peterson, Jon wrote:>
> I think the advantages below, with the exception of 4, would be true
> of any golden root we created for whatever protocol, be it HTTP or
> something else. I'm sure I could define an HTTP golden root such that

The real point of practical leverage here is existing deployment.  It's 
easy to 'define' almost anything.  Getting deployment and adequate 
operational service is the hard part.

> the verification service could synthesize the proper fetch request
> from the URI in the From with an Identity-Info, one that updated in
> real time so you never needed to worry about revocation, one for

For any existing capability, I'm sure one can define a new service that 
contains it.  The question is what risks and benefits come with that new 
effort?

On 6/17/2013 5:03 AM, Henning Schulzrinne wrote:
> It might be helpful to explicitly distinguish three models,
 > independent of whether the cert is stored in DNS or some HTTP-accessed
 > data store:

Big +1 for this sort of analytic discipline in the effort...

d/

---

From: Michael Hammer <[email-masked]>
Date: Mon, 17 Jun 2013 16:04:11 +0000

All,

I am following the thread and trying to grasp the heart of the matter.

First point:  This is about E.164 number delegation and proof of ownership.

So, I find much of the discussion that seems to rely on DNS structure or
Domain name structuring to be a distraction.
How you prove proof of ownership of a domain is a separate, albeit twin
problem.
But, I think that is out of scope.  I do not believe the answer here is to
ask my evil twin if he owns the E.164.

Second point:  The delegation of E.164 numbers down the tree inextricable
defines who owns the number, 
so any collection of certs into an authoritative repository MUST follow the
same path back up, or you lose sight of that ownership.
E.164 is already the hierarchy, so no second hierarchy is needed.
The recipient of a number block or an individual number may need to receive
the private key, 
else the carrier signs and inserts the signature on the path out from that
user.
(Note, still need to determine how many bytes constitute the signature such
that it fits into an existing SS7 parameter.
Perhaps the answer is to include an indicator in SS7 that the gateway to SIP
must perform the signature outbound.
But, that may limit this to a single hop, else need to trust follow-on SS7
networks to sign properly, but that may be acceptable.)

Third point:  The called party needs to unequivocally know how to validate
an assertion and who to go to for the inputs to perform that validation.
The how should be defined by the RFC, but the who ultimately depends on the
root of each E.164 country code (see point 2).
If the DNS is involved, I think that there is an IAB draft/RFC that says the
DNS should not be used for all things.
So, it is likely that the called party search would start with a well-known
URI to the CC authority, communication to which could be secure, 
who could then point to one or more authoritative services, depending on how
the out-sourcing is done, 
who have the official cert associated with the official delegation of E.164
number blocks or numbers.

This seems to be a parallel to the number portability databases, except that
one is now looking for a cert rather than a route to the serving carrier.
I am not suggesting that the NP databases be used, as this could be
orthogonal to that.

Doing a search based on using the E.164 as an index should not be an issue, 
since in many cases a 10k block of numbers may point to a single cert.
In those cases where portability occurs and single numbers have a different
cert, 
the database could have an indicator of which 10k blocks require full E.164
search to be performed. 
(For international, blocks are defined by how many leading digits are used.)

Fourth point:  Lastly, so the called party has all the elements from the
signaling with which to validate the signature, 
the RFC needs to specify what elements are prohibited from changing
end-to-end.
Given that some of the existing parameters do change in current systems, I
don't know how you get around doing one of the following:
- define new header that contains complete signature package that is added
by whomever does the signing.
- re-define existing headers to add the signature and restrict any
intermediary from modifying those values.
Seeing that the existing already have usage baggage, the first option seems
more likely to succeed.

Also, need to ensure that the SS7 network can carry elements E2E without
changes.
SS7 terminations may have to rely on the SIP-to-SS7 GW to perform
validation.
SIP terminations may have to rely on the SS7-to-SIP GW to generate
signatures.
SIP-SS7-SIP would be an issue given the "no change SS7" limitation.

Did I miss any requirements or constraints here?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Monday, June 17, 2013 8:14 AM
To: Hadriel Kaplan
Cc: [email-masked]; [email-masked]; Peterson, Jon
Subject: Re: [stir] current draft charter

I wouldn't be surprised if the large carriers cache all certs locally. For
+1, I'd suggest that's less than a TB, i.e., a single disk, even if every
number has their own cert, rather than number ranges. They would then
subscribe to a notification service for any porting-related changes, given
that such changes affect a very small fraction of the numbers (quarterly
churn of mobile carriers is about 1-2%). This can all be done within the
carrier network, i.e., without affecting the external public data interface.

On Jun 17, 2013, at 2:18 AM, Hadriel Kaplan wrote:

>> The exact amount of tolerable delay is a very interesting dimension 
>> of this problem space. I suspect we have a considerable amount of 
>> time, given all the human expectations about both post-dial delay and 
>> the wait for someone to pick up after altering. I think it's enough 
>> time to perform some non-trivial operations.
> 
> I've been thinking about that and I'm not sure we actually have much time.
I've been looking at what the CNAM guys are doing, and at least one them
(used in a large mobile provider) goes so far as to sometimes skip it on the
INVITE and send their CNAM info in an UPDATE or INFO afterwards due to the
delay.  I.e., they have us queue the INVITE while they retrieve the CNAM
info for the given caller-id, but if they take too long then we send the
INVITE and send their results separately afterwards in another message.
Another operator that uses private ENUM for CNAM querying also sets very low
timeouts on the query, and just don't provide a calling name if it times out
(ie., the INVITE gets sent on without it, and nothing updates it later).
> 
> Also, Brian at one point mentioned transit providers possibly doing 
> the verification check as well, and that might be difficult if it 
> takes non-trivial time I think, because one of the SLA measurements 
> they get ranked on is how fast they route their calls onward.  
> (Besides which they're never involved this type of stuff so I'd doubt 
> they'd start now anyway.)
> 
> Anecdotally, I find that intra-nation calls get to ringing stage much
faster than international calls, so people are probably ok with
international caller-id verification taking longer.

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 17 Jun 2013 12:11:54 -0400

[RS> ] Dave this is a very good point which creates part of the complication
here. There is a very specific relationship between service provider and the
number that traditional Internet naming and addressing abstracts. The number
is Owned by the nation state. Though the delegation process is different for
each there are some exceptions such as the wholesale numbering markets where
a provider sells blocks to an alternative service provider.. Skype, Google
Voice, WhatsApp etc. Even in those cases the number is traditionally tied to
the wholesale service provisioning by the originating provider.  This
situation created issues around who has access to national numbering
resources that has caused endless regulatory disputes.   If you are bored
sometime  you can do a search on FCC and Vonage ..

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 17 Jun 2013 12:45:19 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Hammer
Sent: Monday, June 17, 2013 12:04 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [stir] current draft charter

All,

Second point:  The delegation of E.164 numbers down the tree inextricable
defines who owns the number, so any collection of certs into an
authoritative repository MUST follow the same path back up, or you lose
sight of that ownership.
E.164 is already the hierarchy, so no second hierarchy is needed.
The recipient of a number block or an individual number may need to receive
the private key, else the carrier signs and inserts the signature on the
path out from that user.
(Note, still need to determine how many bytes constitute the signature such
that it fits into an existing SS7 parameter.
Perhaps the answer is to include an indicator in SS7 that the gateway to SIP
must perform the signature outbound.
But, that may limit this to a single hop, else need to trust follow-on SS7
networks to sign properly, but that may be acceptable.)

[RS> ]  I was waiting for that little subject to come up. :-)   Personally I
detest this draft since it was clearly designed as an anti 6116 statement.
Ive never liked it and personally I hope it is never published. 

Title           : Architectural Considerations on Application Features in
the DNS
	Author(s)       : Jon Peterson
                          Olaf Kolkman
                          Hannes Tschofenig
                          Bernard Aboba
	Filename        : draft-iab-dns-applications-07.txt
	Pages           : 37
	Date            : 2013-02-25

Abstract:
   A number of Internet applications rely on the Domain Name System
   (DNS) to support their operations.  Many applications use the DNS to
   locate services for a domain; some for example transform identifiers
   other than domain names into formats that the DNS can process, and
   then fetch application data or service location data from the DNS.
   Proposals incorporating sophisticated application behavior using DNS
   as a substrate have raised questions about the role of the DNS as an
   application platform.  This document explores the architectural
   consequences of using the DNS to implement certain application
   features, and provides guidance to future application designers as to
   the limitations of the DNS as a substrate and the situations in which
   alternative designs should be considered.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-iab-dns-applications

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-iab-dns-applications-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-iab-dns-applications-07

So, it is likely that the called party search would start with a well-known
URI to the CC authority, communication to which could be secure, who could
then point to one or more authoritative services, depending on how the
out-sourcing is done, who have the official cert associated with the
official delegation of E.164 number blocks or numbers.

RS> I wish to point out that reliance on 10K block delegations in most cases
is essentially a nonstarter for endless reasons in the US and is irrelevant
in other national jurisdictions.  

In those cases where portability occurs and single numbers have a different
cert, the database could have an indicator of which 10k blocks require full
E.164 search to be performed. 
(For international, blocks are defined by how many leading digits are used.)

signaling with which to validate the signature, the RFC needs to specify
what elements are prohibited from changing end-to-end.

Mike

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

+1, I'd suggest that's less than a TB, i.e., a single disk, even if 
+every

On Jun 17, 2013, at 2:18 AM, Hadriel Kaplan wrote:

> 
> On Jun 16, 2013, at 7:27 PM, "Peterson, Jon" 
> <[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Jun 2013 09:57:04 -0700

On 6/17/2013 9:45 AM, Richard Shockey wrote:
> [RS> ]  I was waiting for that little subject to come up.:-)    Personally I

yup:

    Review: draft-iab-dns-applications-07

    http://www.ietf.org/mail-archive/web/ietf/current/msg77934.html

and its two predecessors for earlier versions of the draft:

    http://trac.tools.ietf.org/group/iab/trac/ticket/35

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Jun 2013 12:58:43 -0400

> ask my evil twin if he owns the E.164.

There've been a bunch of emails so you've probably missed it, or maybe it wasn't made clear, but the idea behind the DNS proposal is to use reverse-number dotted notation for the E.164.  So an E.164 of '+16035551212' becomes the domain name '2.1.2.1.5.5.5.3.0.6.1.cid.arpa'.

The authority for .cid.arpa is the ITU, and they delegate the country-codes within it to the national number admins for each country (ie, exactly what they do for E.164 numbers).  At that point each nation decides what they want to do, whether to have their whole country-code number tree under one admin authority, or to have it split up.

Oh, and this would all use DNSSEC, which might mean we don't even need to store full certs in this tree, but can just store public keys. (because the DNSSEC info is the same as would be in the certs)

> E.164 is already the hierarchy, so no second hierarchy is needed.

Right, and the DNS proposal follows the E.164 ownership hierarchy.

> else the carrier signs and inserts the signature on the path out from that

No, the recipient of the number block creates their own private/public key pair, and upload the public key to the DNS admin for their E.164 number.  In the DNS it gets signed by the number authority.  So the number authority (ie the DNS) never knows the private key - only the actual user of the private key does.

> networks to sign properly, but that may be acceptable.)

If we can use a SS7 param, I believe the Identity signature can fit - if I'm doing my math right, it's 128 bytes binary (or 172 bytes if base64 encoded ascii).
You'd need to include some other info as well to make this work, but I'm pretty sure we could fit it all in the 255 bytes of an ISUP param.  Unless we have to include a URL, in which case all bets are off.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Jun 2013 17:47:52 -0700

Section 4:

    Section 5, Step 2:

ditto.

The essential point behind this line of discussion is that an entirely 
new cert semantic and trust structure will need to be invented and 
deployed.

+1

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Jun 2013 10:10:10 -0700

> There've been a bunch of emails so you've probably missed it, or maybe it wasn't made clear, but the idea behind the DNS proposal is to use reverse-number dotted notation for the E.164.  So an E.16…

The authorization-checking topic that is driving this list needs to 
distinguish between the basic semantics of what is being done --  who 
are the actors, what are their roles and authorities, what are their 
interactions -- from the low-level mechanics -- such as syntactic 
encoding form -- that are used to permit the 'interesting' stuff.

One thing that seems to be a continuing distraction is "pure" E.164 
number vs. domain name.

As discussed in this venue, to domain name form is a syntactic encoding. 
  On its own, it's no more interesting or terrible than any other 
encoding form.  It makes sense to consider here only to the extent that 
the operational platform using it makes sense.

The significant parts of determining whether a platform makes sense to 
consider are the many aspects of its operational details, ranging from 
beneficial history -- deployed and well-used -- to its administrative 
alignment with what is needed.

> Oh, and this would all use DNSSEC, which might mean we don't even need to store full certs in this tree, but can just store public keys. (because the DNSSEC info is the same as would be in the cert…

Or possibly not.  DNSSec is still only partially deployed, and the use 
being discussed here is probably a re-purposing of its functionality. 
My own guess is that DNSSec makes sense for providing an important 
enhancement to reassurances about the operational platform, but that 
it's not essential to the core semantics.  But of course, that's just my 
opinion...

d/

---

From: Dan York <[email-masked]>
Date: Mon, 17 Jun 2013 17:27:00 +0000

>I've been thinking about that and I'm not sure we actually have much

+1.  As we as a society move more systems from the PSTN over to "IP
communications" I suspect that we will see a growing expectation to have
connections occur more quickly.  Other factors may enter in here, too, in
feeding that expectation.  For instance, we may see WebRTC apps that
quickly connect a calling user with another endpoint, and users may grow
to expect that kind of quick connection.  Or there may be a new IP-based
telco that attempts to differentiate itself by providing the fastest
connection time.  Or there may be a major vendor that launches a campaign
for IP communications like Google's "Speed Up The Web" that is aimed at
providing quicker connections.

I think you are right, Jon, based on *current* human expectations, but I
could easily see those expectations changing and I think we need to be
careful about tying a solution to current expectations. (Or at least if we
do that needs to be a conscious choice.)

>international caller-id verification taking longer.

Agreed, based again on *current* expectations around user behavior.  On
the other hand, when I make a call using Skype or Facetime I expect the
call to connect quickly. With some other apps browser-based apps I expect
to be able to pretty much push the button to initiate a call and start
talking.

I think we need to plan for the success of communication moving over to IP
and reaping some of the benefits of IP, including no longer being shackled
to legacy PSTN behavior.

My 2 cents,
Dan

---

From: Michael Hammer <[email-masked]>
Date: Mon, 17 Jun 2013 17:31:45 +0000

My point was that the mere fact of being in DNS did not convey any
trustability.

So, not objecting to DNS being used to find authoritative servers, just that
it itself is not authoritative.

Mike

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Monday, June 17, 2013 12:45 PM
To: Michael Hammer; [email-masked]
Subject: RE: [stir] current draft charter

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

All,

Abstract:

RS> I wish to point out that reliance on 10K block delegations in most 
RS> cases
is essentially a nonstarter for endless reasons in the US and is irrelevant
in other national jurisdictions.  

Mike

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Jun 2013 13:37:32 -0400

> one CA, and which you could locally cache (well, okay, 5 does conflict a

Sure, there's no debate one could replicate the DNS protocol and architecture to use HTTP as the accessing protocol instead of DNS query/response.  I have no idea why one would want to make a simple database query protocol heavier for no benefit gain, but sure it's possible. :)

> middlemen, charging, etc are just as likely to arise for DNS as for any

No, they're not.  For the middlemen issue, middlemen are of course also possible using a DNS approach (they already exist today), but the protocol used for the client to access the middleman would be well-specified, because it's exactly the same as that used for cases where there is no middleman: DNS.

With regards to the access control and charging, the important point is DNS would make it virtually impossible to *have* an access control and charging model for queries.  The protocol's characteristics actually make it practically impossible to do.  Country-A couldn't charge Country-B to access the calling cert info for Country-A; and Carrier-A couldn't charge Carrier-B to access the calling cert info for Carrier-A.  Instead, Country-A would incur the cost for managing their own E.164 entries in DNS, and likewise Country-B pays for Country-B's numbers; or Carrier-A would incur the cost for their E.164 numbers, and likewise Carrier-B.

I know that's a controversial position.  It means deciding, up front, that the only supportable pricing model for this thing in the grand scale would be the same as for DNS domain names: charging only for adding/managing entries in the database, not charging _other_ entities per-query of the database.  I think (but don't know) that this would actually make this thing easier to get adoption for.  At least in my simple naive view, it might help international adoption if the decisions each country makes are only technical and logistic for their own country, rather than involve money between countries.

[Note: this doesn't mean NPAC can't be used for this database in the NANP, even though NPAC is a closed model and charged for query access I think.]

-hadriel

---

From: Dan York <[email-masked]>
Date: Mon, 17 Jun 2013 17:38:16 +0000

>an assertion and who to go to for the inputs to perform that validation.

I would not necessarily restrict it to the "called party".  This is the
dominant use case we've been discussing, I.e that I receive a call and
want to be as certain as possible about the identity of the endpoint
calling me.

However, I could be calling out to my customers or clients and as the
"calling party" would like to be as certain as possible that I am reaching
the correct endpoint.  Consider a bank wanting to reach a customer about
issues with the customer's account - or to verify a recent transaction. Or
a doctor's office want to relay results to a patient and wanting to be
sure they are reaching the patient's number.

My understanding is that we are aiming to solve the "secure origin
identification" challenge - and that could apply to either or both ends of
the conversation.

Dan

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Jun 2013 13:43:47 -0400

> it itself is not authoritative.

Just to be clear I've been using the term "DNS", but actually meaning it with DNSSEC.  If the country-code level domains are under the authority of the national numbering plan admins for each country, then with DNSSEC they'd be the ones signing the resource record entries in their DNS tree.  I can't imagine who could be more authoritative for a country's E.164 numbers than the national number plan admin.  They're certainly more authoritative than existing certificate CAs, for example.
:)

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 17 Jun 2013 17:46:01 +0000

There are some more specific replies inline, but first this:

Upleveling, there are a set of problems out there in the world that are
caused by impersonation of calling numbers, and we have a choice here to
try to address them or not. The STIR proposal does make the foundational
assumption that we would have more leverage on the impersonation problem
if Internet devices could somehow rely on the authority structures over
numbering that are defined in the PSTN. I've tried here not to be overly
prescriptive about what the best way is to project those authority
structures onto the Internet.

Certainly we could just decide at the get-go "it's certificates, there'll
be a CA, based on existing CAs used by the numbering databases."
Personally I'd rather hear more discussion about the alternatives under
consideration, like putting credentials in the DNS. However, willingness
to explore alternatives and understand the design space is not
hand-waving, it's not sweeping things under the rug, it's not believing in
unspecified miracles.

Certificate authorities and the DNS are both fairly well understood
commodities. The operational and deployment characteristics of these
services are not particularly mysterious. If these are the possibilities
under consideration, then I don't think we're in unfamiliar waters. We can
examine these possibilities, and ultimately if appropriate we can allow
either or both, in rfc447bis and the related specifications. Once we have
the protocol machinery in place, maybe letting industry and regulators
build out structures until we see what works would be instructive.

As the PSTN transitions further onto the Internet in the coming years,
there are going to have to be systems in place for authority, for routing,
and so on that help bring telephone numbers onto the Internet. We don't
have all the answers today about what that world will look like. All we
can do is to move the ball forward, based on what we know today and what
is achievable today, and the challenges we face in this transitional and
transitioning system (like robocalling, vishing, swatting, etc). In order
to do this, we need to fix things like RFC4474 so that it has hooks for
supporting telephone numbers. That is the work in the proposed scope of
STIR.

>uses very large numbers of anchors.

Obviously charters are at a low level of detail, as opposed to the input
documents, but if this is enough of a hot-button issue to warrant a
mention in the charter, I wouldn't oppose it.

And as for the list discussion, well, we're all still coming to understand
the problem space. I don't think I've heard people arguing that a very
large number of overlapping trust anchors would be a wise way to start off.

>it will be more appropriate as an IRTF task...

I think you need to be able to modularize in design to get anywhere. What
is actually in the scope of the proposed charter are a set of narrow and
achievable deliverables (at least for the first prong). It is not in the
scope of the charter to design that "proposed service," any more than it
is in the scope of the TLS working group to design web PKI. The TLS work
doesn't have to operationally prove out web PKI in order to get a charter,
and well, if it did, there are enough operational problems with web PKI
that some might argue TLS should never be chartered. However, SSL/TLS have
done a ton of good. Various efforts in the IETF and the industry at large
are working to improve web PKI.

If you'd like to form an IRTF working group to discuss the problems of
scale, diversity and reliability of various credential systems, I won't
stand in your way. The scope of this proposed working group is orthogonal
to that.

>Number portability changes this. The number does not belong to the

Again, I've just been trying to get us on the same page about what RFC4474
says - then we talk about what it should be amended to say about numbers
(or rather, that's the scope of the proposed work here).

You may know more about number portability than me, but I don't agree with
your assessment of it here. At best, I'd say that number portability in
America allows consumers to choose which carrier "owns" a number. This is
also a reason I keep putting scare quotes around "owns," because the
assumptions of the DNS don't apply to users of telephone numbers, at least
not in our current regulatory environment. If you are a registrant, you
have the authority to configure your zone - that sounds close enough to be
ownership to me (even though the UDRP or ICE can end your ownership under
extreme conditions). If you have a telephone number assigned to you, a
carrier still decides what number it rings.

>this relationship.  It's key because it authorizes the provider to vouch

What I've been describing is the existing relationship between the service
provider and the user. Agreed that a credential should be able to allow a
service provider to vouch for the end user in some circumstances, just as
the owner of "example.com" vouches for "[email-masked]."

>phone -- the extant trust mechanisms don't cover them.

There are corner cases that are going to be challenging here that we won't
know the right way to address out of the gate. "Legitimate spoofing" is
one where I'm aware of a few possible approaches but I anyway don't yet
know which one would be best. This would be something for the working
group to examine. 
 
>is adoption by all telcos.

I didn't just describe a system that requires adoption by all telcos, not
in the sense you mean.

In so far as all telcos are part of the PSTN where those structures are
codified already in various databases and credentials, telcos are already
part of a numbering authority system. For example, if you are a carrier in
North America, you get number blocks from your national regulator and
interface with databases that let you update routes or perform similar
administrative tasks. You get various kinds of credentials, with various
scopes of authority, to authenticate yourself to these systems.

Incrementally, systems on the Internet could begin to depend on that
authority, if it were projected onto the Internet in some fashion - like
through a CA, for example. It would not require every telco to suddenly
start using it for it to be useful. The STIR proposal also has a second
approach (the fallback mechanism) that tries to build grass-roots, bottom
credentials as well to cover more of the problem space.

>specification.  As such, it isn't possible to evaluate its practicality.

No, what's in the charter is the work that's in the scope of the IETF -
things like fixing RFC4474 so it could contain assertions that cover
telephone numbers. 

The creation of a certificate with a telephone number inside which you
fetch with a web get is not a miracle. It is possible to evaluate its
practicality. 

>operational service is the hard part.

In the IETF, we define things. The world deploys and operates them. We
need to define things in a way that make it possible that they can be
deployed and operated, sure.

>contains it.  The question is what risks and benefits come with that new

HTTP is not a "new service." Its trade-offs are fairly well understood.

Jon Peterson
Neustar, Inc,

---

From: Michael Hammer <[email-masked]>
Date: Mon, 17 Jun 2013 17:52:43 +0000

Inline...

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, June 17, 2013 12:59 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

On Jun 17, 2013, at 12:04 PM, Michael Hammer <[email-masked]>
wrote:

> So, I find much of the discussion that seems to rely on DNS structure 
> or Domain name structuring to be a distraction.
> How you prove proof of ownership of a domain is a separate, albeit 
> twin problem.
> But, I think that is out of scope.  I do not believe the answer here 
> is to ask my evil twin if he owns the E.164.

There've been a bunch of emails so you've probably missed it, or maybe it
wasn't made clear, but the idea behind the DNS proposal is to use
reverse-number dotted notation for the E.164.  So an E.164 of '+16035551212'
becomes the domain name '2.1.2.1.5.5.5.3.0.6.1.cid.arpa'.

The authority for .cid.arpa is the ITU, and they delegate the country-codes
within it to the national number admins for each country (ie, exactly what
they do for E.164 numbers).  At that point each nation decides what they
want to do, whether to have their whole country-code number tree under one
admin authority, or to have it split up.

Oh, and this would all use DNSSEC, which might mean we don't even need to
store full certs in this tree, but can just store public keys. (because the
DNSSEC info is the same as would be in the certs)

MH> I didn't miss any and saw the ENUM-style discussion.  That is an
inheritance.  My point is that SPs were able to do number string analysis
without the reverse tree building, so something more like a CIDR reading of
an E.164 would be sufficient.  I don't object to the above per se, but the
key is who is allowed to populate that tree and how do you enforce that?  I
assume that the DNSSEC would need to do that.  You would have to define how
any delegation is enforced with DNSSEC.  Also, explain how the called user
(even on PTSN) is going know he is not being spoofed by DNS.

> Second point:  The delegation of E.164 numbers down the tree 
> inextricable defines who owns the number, so any collection of certs 
> into an authoritative repository MUST follow the same path back up, or 
> you lose sight of that ownership.

> The recipient of a number block or an individual number may need to 
> receive the private key, else the carrier signs and inserts the 
> signature on the path out from that user.

No, the recipient of the number block creates their own private/public key
pair, and upload the public key to the DNS admin for their E.164 number.  In
the DNS it gets signed by the number authority.  So the number authority (ie
the DNS) never knows the private key - only the actual user of the private
key does.

MH>  Not worded so well apparently.  Yes, I was implying that the individual
number user would need to generate the key pair, or that the carrier could
do that for them.  Also, if the numbers were aggregated, i.e. blocks, the
carrier could generate and report up the chain the key pair.  So, we are
saying the same thing.

> (Note, still need to determine how many bytes constitute the signature 
> such that it fits into an existing SS7 parameter.
> Perhaps the answer is to include an indicator in SS7 that the gateway 
> to SIP must perform the signature outbound.
> But, that may limit this to a single hop, else need to trust follow-on 
> SS7 networks to sign properly, but that may be acceptable.)

If we can use a SS7 param, I believe the Identity signature can fit - if I'm
doing my math right, it's 128 bytes binary (or 172 bytes if base64 encoded
ascii).
You'd need to include some other info as well to make this work, but I'm
pretty sure we could fit it all in the 255 bytes of an ISUP param.  Unless
we have to include a URL, in which case all bets are off.

MH> Still waiting on the specifics of that.

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 17 Jun 2013 18:00:03 +0000

I hear what you're saying, but I'd imagine there will always be a
difference in time-frame between "speeding up the web" and waiting for a
human to pick up a phone. Humans have to react to altering, get their
phone out of a pocket, etc. Nothing about how much faster we make the web
will reduce the distance (physical and psychological) between my pool and
my phone charger when a call comes in.

Now, what if we hope to make the phone never ring at all? The potential
laziness of callees is meaningful because only the caller perceives the
delay. Certainly we can play alerting back to the caller even if the
callee phone is trying to resolve authorization. In fact, in many blocking
circumstances, continuing to play alerting forever might be the right
thing to do if the callee is declining the caller.

Ultimately we are going to have to have some estimate of what the budget
is here and match it against what we hope to accomplish.

Jon Peterson
Neustar, Inc.

---

From: Michael Hammer <[email-masked]>
Date: Mon, 17 Jun 2013 18:01:32 +0000

By doing that you turn this from a source identity non-repudiation
capability to 
a routing assurance capability (receipt non-repudiation).

Despite being useful, I thought that was not in scope.

Mike

-----Original Message-----
From: Dan York [mailto:[email-masked]] 
Sent: Monday, June 17, 2013 1:38 PM
To: Michael Hammer; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Not just "called party" - Re: [stir] current draft charter

On 6/17/13 12:04 PM, "Michael Hammer" <[email-masked]> wrote:

>Third point:  The called party needs to unequivocally know how to 
>validate an assertion and who to go to for the inputs to perform that
validation.

I would not necessarily restrict it to the "called party".  This is the
dominant use case we've been discussing, I.e that I receive a call and want
to be as certain as possible about the identity of the endpoint calling me.

However, I could be calling out to my customers or clients and as the
"calling party" would like to be as certain as possible that I am reaching
the correct endpoint.  Consider a bank wanting to reach a customer about
issues with the customer's account - or to verify a recent transaction. Or a
doctor's office want to relay results to a patient and wanting to be sure
they are reaching the patient's number.

Dan

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 17 Jun 2013 14:01:57 -0400

[Note: this doesn't mean NPAC can't be used for this database in the NANP,
even though NPAC is a closed model and charged for query access I think.]
[RS> ] 

[RS> ] Not since 2009. The NPAC like most national numbering databases are
now operated on fixed price contracts.  The days of transaction based or dip
charges are long long gone.  Cost recovery is usually based on the number of
entries or TN's in the data base and an annual allocation model approved by
the national regulator. 

-hadriel

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 17 Jun 2013 18:03:18 +0000

How is this n the scope of this charter, Jon...can we focus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Monday, June 17, 2013 2:00 PM
To: Dan York; Hadriel Kaplan
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] current draft charter

Jon Peterson
Neustar, Inc.

---

From: Michael Hammer <[email-masked]>
Date: Mon, 17 Jun 2013 18:05:00 +0000

That is a key distinction and ties into my assertion that the CC numbering
authority must control that.

But, clarify one thing for me.  Does DNSSEC ensure both:
-  that the uploading of information is authentic,
-  attempts to read the data actually get to that secure entry?

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, June 17, 2013 1:44 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] current draft charter

On Jun 17, 2013, at 1:31 PM, Michael Hammer <[email-masked]>
wrote:

> So, not objecting to DNS being used to find authoritative servers, 
> just that it itself is not authoritative.

Just to be clear I've been using the term "DNS", but actually meaning it
with DNSSEC.  If the country-code level domains are under the authority of
the national numbering plan admins for each country, then with DNSSEC they'd
be the ones signing the resource record entries in their DNS tree.  I can't
imagine who could be more authoritative for a country's E.164 numbers than
the national number plan admin.  They're certainly more authoritative than
existing certificate CAs, for example.
:)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Jun 2013 14:13:44 -0400

> entries or TN's in the data base and an annual allocation model approved by

Excellent.  Then there's no problem on that front, either. :)

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Jun 2013 11:28:22 -0700

> hand-waving, it's not sweeping things under the rug, it's not believing in

I have an even more extreme suggestion:

      Get some clarity and agreement on the services that are needed, 
independent of the way they might be implemented.  That will permit 
evaluating alternative implementation approaches more systematically and 
equitably.

      The key to such an exercise is to make /non-technical/ statements 
about functionality.  What are the semantics of the service?  Who are 
the actors? What are their roles?  What flexibilities in the service are 
desirable?  All stated without reference to technologies.

I find that such an exercise often helps avoid distracting debates about 
minor points and moves things to consensus about requirements that 
really are core.

d/

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 17 Jun 2013 18:45:32 +0000

I think it's a much harder problem, anyway, and I wouldn't want to put it
on our plate until we've understood more about source identity.

I imagine that there are alternative ways to approach the fallback
mechanism that could probably confer this property for some use cases.

Jon Peterson
Neustar, Inc.

On 6/17/13 11:01 AM, "Michael Hammer" <[email-masked]> wrote:

>want

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Jun 2013 14:57:00 -0400

> -  that the uploading of information is authentic,

I am not-at-all an expert on DNSSEC, but I don't believe it covers how the info gets uploaded into the DNS database.  Of course neither does anything else.

Regardless of what protocol and architecture we end up using, at the end of the day the administrator of a given database has to provision the "customers" that can upload for which E.164 entries.  Each customer account is provisioned with some set of credentials with which to do so - for example a username+password, or whatever.  The customers then use some mechanism to upload/update their entries with the credentials.  This could be through a web portal, or Dynamic DNS, or sending faxes.

It would definitely be nice to provide a defined protocol means of doing some of that, for at least the part of: customer-X which already has an account with credentials in database Y, and is already assigned E.164 number Z, being able to upload a public-key or unsigned cert for number Z into the database Y.  I don't really care what the protocol is for that to happen, although defining something over HTTPS makes the most sense to me for that.

> -  attempts to read the data actually get to that secure entry?

If I understand it right, it doesn't actually matter if you reach the right server or not - if another server responds with a false/fake entry, you'll correctly detect it is fake; if another server responds with a correct entry, you'll detect that it's not fake and it's perfectly ok to use it.

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 17 Jun 2013 18:58:59 +0000

I agree it would be great to find a technical approach to this that
simplified business relationships, but I don't think we can depend on
technical standards to restrain policy. That would be like stipulating
that intermediaries can't change RFC3261 request bodies in order to - but
never mind. It is ingenious to turn the inability to authenticate queries
to the DNS into a virtue in this regard, but I'm still not sure I
understand how this model would really prevent middlemen from charging if
they wanted to, short of recreating e164.arpa as some comparable public
golden root. Without it, there will always be ways that nation-states
could restrict access to queries from outside their borders, say, unless
they go through this for-pay VPN or what have you.

Jon Peterson
Neustar, Inc.

On 6/17/13 10:37 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>Sure, there's no debate one could replicate the DNS protocol and
>architecture to use HTTP as the accessing protocol instead of DNS
>query/response.  I have no idea why one would want to make a simple
>database query protocol heavier for no benefit gain, but sure it's
>possible. :)
>
>
>No, they're not.  For the middlemen issue, middlemen are of course also
>possible using a DNS approach (they already exist today), but the
>protocol used for the client to access the middleman would be
>well-specified, because it's exactly the same as that used for cases
>where there is no middleman: DNS.
>
>With regards to the access control and charging, the important point is
>DNS would make it virtually impossible to *have* an access control and
>charging model for queries.  The protocol's characteristics actually make
>it practically impossible to do.  Country-A couldn't charge Country-B to
>access the calling cert info for Country-A; and Carrier-A couldn't charge
>Carrier-B to access the calling cert info for Carrier-A.  Instead,
>Country-A would incur the cost for managing their own E.164 entries in
>DNS, and likewise Country-B pays for Country-B's numbers; or Carrier-A
>would incur the cost for their E.164 numbers, and likewise Carrier-B.
>
>I know that's a controversial position.  It means deciding, up front,
>that the only supportable pricing model for this thing in the grand scale
>would be the same as for DNS domain names: charging only for
>adding/managing entries in the database, not charging _other_ entities
>per-query of the database.  I think (but don't know) that this would
>actually make this thing easier to get adoption for.  At least in my
>simple naive view, it might help international adoption if the decisions
>each country makes are only technical and logistic for their own country,
>rather than involve money between countries.
>
>[Note: this doesn't mean NPAC can't be used for this database in the
>NANP, even though NPAC is a closed model and charged for query access I
>think.]
>
>-hadriel
>

---

From: Michael Hammer <[email-masked]>
Date: Mon, 17 Jun 2013 19:03:18 +0000

I would suspect that if a called party attempt to fetch a cert and is told
to pay, you will find users will just not accept the call.
That could occur prior to ringing based on service provisioning.
So, if countries don't want their calls to cross boundaries, that will do
it.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peterson, Jon
Sent: Monday, June 17, 2013 2:59 PM
To: Hadriel Kaplan
Cc: [email-masked]; Henning Schulzrinne
Subject: Re: [stir] current draft charter - ENUM and databases

I agree it would be great to find a technical approach to this that
simplified business relationships, but I don't think we can depend on
technical standards to restrain policy. That would be like stipulating that
intermediaries can't change RFC3261 request bodies in order to - but never
mind. It is ingenious to turn the inability to authenticate queries to the
DNS into a virtue in this regard, but I'm still not sure I understand how
this model would really prevent middlemen from charging if they wanted to,
short of recreating e164.arpa as some comparable public golden root. Without
it, there will always be ways that nation-states could restrict access to
queries from outside their borders, say, unless they go through this for-pay
VPN or what have you.

Jon Peterson
Neustar, Inc.

On 6/17/13 10:37 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>>which there was only  one CA, and which you could locally cache (well, 
>>okay, 5 does conflict a  bit with 2).
>
>> middlemen, charging, etc are just as likely to arise for DNS as for 
>> any other proposal.
>
>charging model for queries.  The protocol's characteristics actually 
>make it practically impossible to do.  Country-A couldn't charge 
>Country-B to access the calling cert info for Country-A; and Carrier-A 
>couldn't charge Carrier-B to access the calling cert info for 
>Carrier-A.  Instead, Country-A would incur the cost for managing their 
>own E.164 entries in DNS, and likewise Country-B pays for Country-B's 
>numbers; or Carrier-A would incur the cost for their E.164 numbers, and
likewise Carrier-B.
>that the only supportable pricing model for this thing in the grand 
>scale would be the same as for DNS domain names: charging only for 
>simple naive view, it might help international adoption if the 
>decisions each country makes are only technical and logistic for their 
>own country, rather than involve money between countries.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Jun 2013 15:04:56 -0400

For sake of focus and having a prayer of getting this done before we all retire, I think we should focus exclusively on caller-id reputability.  No bank would ever trust this type of thing for called-party identity anyway, because it only identifies phone numbers not humans - i.e., at best it identifies a phone, not the person on the other end.  Thus they'll have to ask you a bunch of identifying questions anyway.

-hadriel

---

From: Dan York <[email-masked]>
Date: Mon, 17 Jun 2013 19:55:13 +0000

Mike,

>-  that the uploading of information is authentic,

DNSSEC ensures that the information the recipient is retrieving from DNS
is the same information that was put into DNS by the entity operating the
DNS servers for that domain (and signing the records).  It provides an
integrity check on the data received in a DNS query.

It can make no assertions about the quality or authenticity of the data
that was uploaded into the DNS servers.  All it can say is that the data
you are receiving matches the data that was served by the DNS servers
(based on the cryptographic signatures).  If an attacker compromised the
DNS servers, including the ability to generate DNSSEC signatures, he or
she would be able to upload bogus data - but if this happens there are
probably larger issues for the operator of the servers to worry about.

In the STIR example, if we were to use DNS we would need to assume a
certain level of trust in the entities putting the phone numbers and
corresponding identities into the DNS.  As you mentioned this is probably
the CC numbering authority in many/most cases.

>-  attempts to read the data actually get to that secure entry?

DNSSEC has a concept of a "global chain of trust" that links the
individual records and their signatures up to an ultimate trust anchor,
which, in the case of public DNSSEC would be the root of the DNS.
Essentially, you have a DNSKEY record with your public key.  There is then
a Delegation Signer (DS) record in the parent zone that is a hash of the
DNSKEY[1]. This continues on up to the TLDs and to the root.

If STIR were to use DNS/DNSSEC, the entity (server, IP-PBX, SBC, endpoint,
whatever) performing the DNSSEC validation for the call would know that it
was reaching the secure entry because:

1. the info for the telephone number identifier (cert, text record,
whatever) would be cryptographically signed by the zone's public key
(carried in the matching RRSIG record).

2. the entity would be able to use the DS records to walk back up the
global chain of trust to be sure that it was using the correct key for
validation.

If either of these cases failed (a bad (or nonexistent) signature or an
inability to verify the chain of trust), the entity performing validation
would know that it had probably NOT been able to get to that secure entry.

Note that this assumes that DNSSEC would *always* be used so that a
nonexistent signature would also cause a warning.

Dan

[1] And yes, I'm simplifying this a bit for the purpose of illustration.
Those who want more gory details can see RFC 6781 -
http://tools.ietf.org/html/rfc6781

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]  +1-802-735-1624
Jabber: [email-masked]
Skype: danyork   http://twitter.com/danyork

---

From: Michael Hammer <[email-masked]>
Date: Mon, 17 Jun 2013 20:15:33 +0000

Thanks for that clarification.

The crux still seems to be the linking of a domain node to an E.164
delegation node point.
So, DNSSEC would require ENUM style domain structure to some level.
Note, that will lead to the usual root wars.
Possible, but likely need to get everyone on the same tree.

Mike

-----Original Message-----
From: Dan York [mailto:[email-masked]] 
Sent: Monday, June 17, 2013 3:55 PM
To: Michael Hammer; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] current draft charter

Mike,

>-  that the uploading of information is authentic,

DNSSEC ensures that the information the recipient is retrieving from DNS is
the same information that was put into DNS by the entity operating the DNS
servers for that domain (and signing the records).  It provides an integrity
check on the data received in a DNS query.

It can make no assertions about the quality or authenticity of the data that
was uploaded into the DNS servers.  All it can say is that the data you are
receiving matches the data that was served by the DNS servers (based on the
cryptographic signatures).  If an attacker compromised the DNS servers,
including the ability to generate DNSSEC signatures, he or she would be able
to upload bogus data - but if this happens there are probably larger issues
for the operator of the servers to worry about.

In the STIR example, if we were to use DNS we would need to assume a certain
level of trust in the entities putting the phone numbers and corresponding
identities into the DNS.  As you mentioned this is probably the CC numbering
authority in many/most cases.

>-  attempts to read the data actually get to that secure entry?

DNSSEC has a concept of a "global chain of trust" that links the individual
records and their signatures up to an ultimate trust anchor, which, in the
case of public DNSSEC would be the root of the DNS.
Essentially, you have a DNSKEY record with your public key.  There is then a
Delegation Signer (DS) record in the parent zone that is a hash of the
DNSKEY[1]. This continues on up to the TLDs and to the root.

2. the entity would be able to use the DS records to walk back up the global
chain of trust to be sure that it was using the correct key for validation.

Dan

--
Dan York
Senior Content Strategist, Internet Society [email-masked]  +1-802-735-1624
Jabber: [email-masked]
Skype: danyork   http://twitter.com/danyork

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Jun 2013 16:18:29 -0400

> Number portability changes this. The number does not belong to the

Number portability doesn't apply to URIs like 
"sip:"[email-masked]". (I have no expectation that I can port 
sip:[email-masked] to [email-masked].)

Number portability pertains to telephone numbers. The reality that we 
paste telephone numbers onto domain names to form SIP URIs confuses the 
issue. In general doing so in no way implies that the domain has any 
responsibility for or ownership of the phone number.

If we always used tel URIs for phone numbers then this would be clearer, 
though no easier to solve.

	Thanks,
	Paul

---

From: Dan York <[email-masked]>
Date: Mon, 17 Jun 2013 20:30:29 +0000

Hadriel,

On 6/17/13 3:04 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>For sake of focus and having a prayer of getting this done before we all
>retire, 

Ack!  We need something deployable - and sooner rather than later.  I
definitely agree with that.

>I think we should focus exclusively on caller-id reputability.  No bank
>would ever trust this type of thing for called-party identity anyway,
>because it only identifies phone numbers not humans - i.e., at best it
>identifies a phone, not the person on the other end.  Thus they'll have
>to ask you a bunch of identifying questions anyway.

Yes, using a bank as an example was a poor choice on my part because they
do have many other processes for identifying the person they are calling.

In this era of call automation, though, being able to have better
confidence in the identifier of the number being called would be
advantageous and could feed application calling logic.  If an outbound
application called a number and received as the secure identifier the
number/identifier it had on file, the application could deliver whatever
message it had.  If there was a mismatch, the app could deliver a
different message ("please call us back") or transfer the call to a
waiting agent to perform an additional identification test of the person
being called.  

I agree that for the sake of getting a secure identifier out we should
focus on the called party identifying the caller, but as we look at
architectural choices it would be good if whatever we choose does not rule
out the usage by the calling party.

Dan

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Jun 2013 17:03:20 -0400

On Jun 17, 2013, at 2:58 PM, "Peterson, Jon" <[email-masked]> wrote:

> never mind.

I don't think that analogy holds.  Such a stipulation would fail because the guys who run the SIP networks themselves *must* change the request bodies to get things to actually *work*, for their users/customers.  Even if you think they change bodies to maintain existing charging practices: this caller-id verification thing is completely new, which is a horse of a different color.  There are no existing charging practices for this currently.

I believe the closest things would be:
1) CNAM, for which typically the called party pays.  I don't think the *carriers* want it to be that way, but it is that way.  This STIR work could end up being quite disruptive to the CNAM providers, because one could imagine a means of providing CNAM using the STIR infrastructure and cutting out the CNAM providers.  But to brutal about this: we don't need the CNAM providers to buy into this STIR work, so we don't need to care if it impacts their business or not.

2) NPAC-type databases, or anything already holding a bunch of E.164-based record entries.  I don't know what the business model is for them - obviously you would know a crapload more about that than I would.  I don't *think* it would be disruptive to make *only* E.164 caller-id certificates in the NPAC publicly and freely accessible for retrieval.  Maybe it would be disruptive.  But again to be brutal: we don't even really need the NPAC-type databases, although it would sure make things a heck of a lot easier.  But ultimately all we need is for the carriers to want to do this, with some model they're ok with.

> It is ingenious to turn the inability to authenticate queries
> golden root. 

I am indeed claiming/assuming we do create a golden root if we do this DNS thing.  I don't care if it's cid.arpa, cid.sipforum.org, a new gTLD, or even hadriel.com. 

I didn't say it prevented middlemen - even just purely as a practical matter there will likely be middlemen to do the signing and verifying for mom&pop carriers, for example.  Or the CNAM provider might do the verifying function for their customer carriers.  They can charge their customers however they like, including on a per-query basis (e.g., private ENUM is already used for some CNAM providers today).

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 17 Jun 2013 17:47:34 -0400

2) NPAC-type databases, or anything already holding a bunch of E.164-based
record entries.  I don't know what the business model is for them -
obviously you would know a crapload more about that than I would.  I don't
*think* it would be disruptive to make *only* E.164 caller-id certificates
in the NPAC publicly and freely accessible for retrieval.  Maybe it would be
disruptive.  But again to be brutal: we don't even really need the NPAC-type
databases, although it would sure make things a heck of a lot easier.  But
ultimately all we need is for the carriers to want to do this, with some
model they're ok with.

[RS> ]  Amen to that.. 

> It is ingenious to turn the inability to authenticate queries to the 
> DNS into a virtue in this regard, but I'm still not sure I understand 
> how this model would really prevent middlemen from charging if they 
> wanted to, short of recreating e164.arpa as some comparable public 
> golden root.

I am indeed claiming/assuming we do create a golden root if we do this DNS
thing.  I don't care if it's cid.arpa, cid.sipforum.org, 

[RS> ]  sipforum.org   Humm I like that idea. :-)  We tried that idea in SIP
UA Config and it didn't fly too far.  

a new gTLD, or even hadriel.com. 

[RS> ]  stir.org... we need to support the Internet Society. 

I didn't say it prevented middlemen - even just purely as a practical matter
there will likely be middlemen to do the signing and verifying for mom&pop
carriers, for example.  Or the CNAM provider might do the verifying function
for their customer carriers.  They can charge their customers however they
like, including on a per-query basis (e.g., private ENUM is already used for
some CNAM providers today).

[RS> ]  I remember I wrote the ENUM CNAM draft that everyone in the IETF
hated but everyone else implemented.  That said it's not unreasonable to
discuss rational business models here since in one form another it will be
the service providers that have the ultimate say in deployment.  I don't
care if its ATT, VZ, Telefonica, Bell Canada, Telus or Rostelcom, FT DT BT
TI  or whatever. If it's not simple and implementable within the rough
protocol stack of IMS and the SBC's it's a non-starter. 

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Jun 2013 19:02:59 -0400

> DNS should not be used for all things.

Yes, and it's a fair point - not that the IAB's RFC is fair or even valid - but it's fair point that a very big downside of using DNS for STIR is: we'd be using DNS, which means we'd never be able to extend it if we needed to.  We'd have to be very sure it's the right solution for the problem.

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 18 Jun 2013 00:47:17 +0000

Definitely I agree that there needs to be a root here, at least at the
national level. A few people have commented that working from the national
level makes more sense than trying to delegate something globally from on
high. Choosing that scope could make it harder to guarantee your vision of
a tariff-free identity, admittedly. I've name-dropped LoST a couple times
here as a place to look for inspiration, perhaps.

But at the end of the day I was also envisioning that this revisited
identity system would still work for regular domain names per RFC4474, and
that we'd probably even keep CID as an option for Identity-Info (or its
successor). So I was anticipating there'd be diversity in the means by
which credentials could be indicated by Identity-Info, and that having a
"root" wouldn't be exclusive in that there are identifiers other than
telephone numbers in the system too.

So again, to the question of how golden the root is, I at least pictured a
national-level root for telephone number identity that would, if at all
possible, eliminate the problem of multiple trust anchors issuing
credentials for the same identity. Just like the same cert could be
included by CID or referred to by HTTP, though, I imagine there could be
more than one protocol for getting at those credentials.

As for whether or not we need NPAC-style databases - agreed that here we
don't need most of the data that's in them (like, LRNs aren't obviously
material to solving our problem), but the authority structures they
reflect are absolutely integral to this. Ultimately, STIR proposes only to
project onto the Internet the authority over numbers that is today
administered in those databases.

I'd hesitate to start talking about delivering CNAM via STIR lest we get
into some serious mission creep. But perhaps more materially, a root which
is completely public can begin to have privacy implications when we start
looking at adding in more personally identifiable information to the
system. 

Jon Peterson
Neustar, Inc.

On 6/17/13 2:03 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>I don't think that analogy holds.  Such a stipulation would fail because
>the guys who run the SIP networks themselves *must* change the request
>bodies to get things to actually *work*, for their users/customers.  Even
>if you think they change bodies to maintain existing charging practices:
>this caller-id verification thing is completely new, which is a horse of
>a different color.  There are no existing charging practices for this
>currently.
>
>1) CNAM, for which typically the called party pays.  I don't think the
>*carriers* want it to be that way, but it is that way.  This STIR work
>could end up being quite disruptive to the CNAM providers, because one
>could imagine a means of providing CNAM using the STIR infrastructure and
>cutting out the CNAM providers.  But to brutal about this: we don't need
>the CNAM providers to buy into this STIR work, so we don't need to care
>if it impacts their business or not.
>
>2) NPAC-type databases, or anything already holding a bunch of
>E.164-based record entries.  I don't know what the business model is for
>them - obviously you would know a crapload more about that than I would.
>I don't *think* it would be disruptive to make *only* E.164 caller-id
>certificates in the NPAC publicly and freely accessible for retrieval.
>Maybe it would be disruptive.  But again to be brutal: we don't even
>really need the NPAC-type databases, although it would sure make things a
>heck of a lot easier.  But ultimately all we need is for the carriers to
>want to do this, with some model they're ok with.
>
>
>I am indeed claiming/assuming we do create a golden root if we do this
>DNS thing.  I don't care if it's cid.arpa, cid.sipforum.org, a new gTLD,
>or even hadriel.com.
>
>I didn't say it prevented middlemen - even just purely as a practical
>matter there will likely be middlemen to do the signing and verifying for
>mom&pop carriers, for example.  Or the CNAM provider might do the
>verifying function for their customer carriers.  They can charge their
>customers however they like, including on a per-query basis (e.g.,
>private ENUM is already used for some CNAM providers today).
>
>-hadriel
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Jun 2013 21:47:06 -0400

I tend to agree (particularly given that we just had a house-sitter watching our home, and I most definitely don't want the bank to take his identity for ours).

It would, e.g., for two-factor authentication, be useful to be able to tell if a number has been redirected. I don't see much hope there, however - if you have a malicious app on your phone that redirects the call to the impostor, the phone is dutifully going to respond that the call has indeed reached the right number.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Jun 2013 21:56:55 -0400

For number assignment, we currently have an industry-cooperative model (NANC, North American Numbering Council) that ensures that the system is run reasonably efficiently and for the benefit of the industry participants. Clearly, this isn't the only model, but I suspect there are existing arrangements that can be extended. (Also, since the large carriers are likely to both originate and validate a huge fraction of the legitimate calls, there are built-in incentives for reasonable behavior. For other behaviors, there is always 47 USC 201(b).)

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Jun 2013 22:01:18 -0400

For the boring details, see

http://www.nanc-chair.org/

See http://www.nanc-chair.org/docs/documents.html ("Contribution factor") for the latest.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Jun 2013 22:21:50 -0400

I've been trying diligently to avoid any ownership terminology - if they have any similarity to IP-related things, it's probably much more like IP addresses: you have to show need and you can't always take them with you. (For landline, it's *local* number portability. If you obtained a 212 number, you can't get a landline in LA with that number, at least at the moment. You can't request a specific number, even if it is available, etc.)

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 Jun 2013 22:49:34 -0400

> Of course that's one possibility - my only point was we can't just make the solution be "have DNS refer to another database"; we have to specify what that referred-to database protocol would be so…

In this split model, you could do a partial match, e.g., by country code and then use DDDS/ENUM-style translation to get the URL, e.g., starting with +1-202-555-1234

+1 translates to 

https://oldmoon.com/12025551234

NAPTR 10 100 "u" "E2U+https" "!^.*$!https:\[email-masked]!"

(I'm not a DDDS expert, so this is likely wrong, but hopefully illustrates the idea.)

> The "magic" part of that which I was referring to was how a CA would know what entities are entitled to what TNs, and for which various country-codes.  For example, let's assume Thawte is a trusted…

I mentioned earlier the three models (single national regulator-sponsored CA, CA with delegation and proof-of-possession CA). You seem to refer to the third option, in which case we're back to the webPKI model of trusting a finite number of CAs, possibly with DANE-style assistance. I wouldn't rule out this option if others fail, but it may not be necessary or optimal in this case, given the properties of phone numbers. (Given the namespace issues, you'd then likely go back to having a single logical database to keep track of the CA for each number, run by a single trusted entity, which doesn't seem to buy you much decentralization.)

> I'm not so sure.  If we actually use the literal URL to get the cert, then all the HTTPS servers have to be accessible to any querying device of any carrier in the World.  That doesn't scale if "ac…

That's what CDNs are made for... The originating entity has an inherent interest in having the call go through. If my carrier charges a lot for access to my cert, and receiving carriers decide not to validate my number, I'm very likely to find an alternative (or complain to my national regulator or congressman; look up "rural call completion" if you don't think that call delivery doesn't get congressional attention.)

> 1) There's no header needed for carrying a URL.

Assuming we can all agree on a single, global DNS tree. That seems like a big "if" at the moment. I suspect we all agree at this point that we don't want to rule this out, so DNS seems like a good option to pursue as ONE option. Relying on this happening as the ONLY option seems risky, however. The operational coordination for certs and distributed retrieval databases seems lower - the number assignment entity simply has to somehow convey certs to a relative handful (dozens to low-thousands) of entities it already conveys data to today. ftp or mailing a USB stick will do in a pinch, if need be. No need to operate anything real-time.

I'm trying to lower the bar for deployment, with as little coordinated machinery as possible.

> 4) It's generally faster, and with tighter client control for retransmit/timeout because it's UDP.

With caching, the data is likely very local either way.

> 5) For bigger carriers, they can have local DNS servers with copies of the frequently accessed data (e.g., local nation E.164s) that their verification systems can query.

Same for any other retrieval protocol, I suspect.

---

From: <[email-masked]>
Date: Tue, 18 Jun 2013 12:55:11 +0000

FWIW, this notion of ownership of E.164 resources has indeed always been distinct of that of assignment. E.164 is actually governed by the overarching principles of E.190, which on this says that "assignment confers use of the resource but does not imply ownership by the assignee". 

In numbering plans I'm familiar with, this principle translates into an article in all NRA assignment rulings stating that the assignment doesn't confer the right to protect a number as a trademark for instance. Or some limitations in time and transfer under conditions. 

Although people sometimes like using ownership as a shortcut, it's more of a right of use really. (I'm sure some here will remember discussions on the notion of carrier of record with eye-watering nostalgia) 

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

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 18 Jun 2013 10:06:20 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Monday, June 17, 2013 9:57 PM
To: Peterson, Jon
Cc: [email-masked]; Hadriel Kaplan
Subject: Re: [stir] current draft charter - ENUM and databases

For number assignment, we currently have an industry-cooperative model
(NANC, North American Numbering Council) that ensures that the system is run
reasonably efficiently 

[RS> ]  you are very very charitable Henning.  

To your point we also have industry operational entities such as the NAPM
North American Portability Management LLC which actually contracts for the
LNP function in the US where the NANC is more a policy body and is a formal
US TAC under the Federal Advisory Act of 1972 and the COIN Association in
the Netherlands that runs the LNP DB there and is a Non Profit Corporation
of 70 Dutch Carriers. There are lots of these in the EC.   In Canada there
is the Canadian Steering Committee on Numbering.  In the UK there is NICC
though OFFCOM directly administers the +44 plan. 

http://www.niccstandards.org.uk/

http://www.crtc.gc.ca/cisc/eng/cisf3f.htm

The term of art for these cooperative industry entities comes from the UK
QUANGO.. Quasi Non Governmental whatever's. Operationally no matter what
technical model selected virtually every nation state has some entity that
can deal with these kinds of things.   That is the least of our problems. 

and for the benefit of the industry participants. Clearly, this isn't the
only model, but I suspect there are existing arrangements that can be
extended. (Also, since the large carriers are likely to both originate and
validate a huge fraction of the legitimate calls, there are built-in
incentives for reasonable behavior. For other behaviors, there is always 47
USC 201(b).)

[RS> ]  Correct! 

We will now return you to your regularly scheduled program. 

On Jun 17, 2013, at 2:58 PM, Peterson, Jon wrote:

> that intermediaries can't change RFC3261 request bodies in order to - 
> but never mind. It is ingenious to turn the inability to authenticate 
> queries to the DNS into a virtue in this regard, but I'm still not 
> sure I understand how this model would really prevent middlemen from 
> charging if they wanted to, short of recreating e164.arpa as some 
> comparable public golden root. Without it, there will always be ways 
> that nation-states could restrict access to queries from outside their 
> borders, say, unless they go through this for-pay VPN or what have you.
> 
> Jon Peterson
> Neustar, Inc.
> 
>> On Jun 17, 2013, at 3:07 AM, "Peterson, Jon" 
>>> something else. I'm sure I could define an HTTP golden root such 
>>> that the verification service could synthesize the proper fetch 
>>> request from the URI in the From with an Identity-Info, one that 
>>> updated in real time so you never needed to worry about revocation, 
>>> one for which there was only one CA, and which you could locally 
>>> cache (well, okay, 5 does conflict a bit with 2).
>> 
>> No, they're not.  For the middlemen issue, middlemen are of course 
>> also possible using a DNS approach (they already exist today), but 
>> the protocol used for the client to access the middleman would be 
>> With regards to the access control and charging, the important point 
>> is DNS would make it virtually impossible to *have* an access control 
>> and charging model for queries.  The protocol's characteristics 
>> actually make it practically impossible to do.  Country-A couldn't 
>> charge Country-B to access the calling cert info for Country-A; and 
>> Carrier-A couldn't charge Carrier-B to access the calling cert info 
>> for Carrier-A.  Instead, Country-A would incur the cost for managing 
>> their own E.164 entries in DNS, and likewise Country-B pays for 
>> Country-B's numbers; or Carrier-A would incur the cost for their E.164
numbers, and likewise Carrier-B.
>> adding/managing entries in the database, not charging _other_ 
>> entities per-query of the database.  I think (but don't know) that 
>> this would actually make this thing easier to get adoption for.  At 
>> least in my simple naive view, it might help international adoption 
>> if the decisions each country makes are only technical and logistic 
>> for their own country, rather than involve money between countries.
>> 
>> NANP, even though NPAC is a closed model and charged for query access 
>> I think.]
>> 
>> -hadriel
>> 
> 
>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 18 Jun 2013 11:06:24 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, June 18, 2013 8:55 AM
To: Henning Schulzrinne; Peterson, Jon
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] current draft charter

FWIW, this notion of ownership of E.164 resources has indeed always been
distinct of that of assignment. E.164 is actually governed by the
overarching principles of E.190, which on this says that "assignment confers
use of the resource but does not imply ownership by the assignee". 

In numbering plans I'm familiar with, this principle translates into an
article in all NRA assignment rulings stating that the assignment doesn't
confer the right to protect a number as a trademark for instance. Or some
limitations in time and transfer under conditions. 
[RS> ] 
[RS> ]  In general you are right though there are some odd corner cases.
Specifically the free phone number ranges 800 and 8XX ranges in the US and
Canada.

Although people sometimes like using ownership as a shortcut, it's more of a
right of use really. (I'm sure some here will remember discussions on the
notion of carrier of record with eye-watering nostalgia) 

[RS> ] <sigh> I wouldn't call it nostalgia,  more a review of the battle
scars and the cumulative effects of cranial concussion. 

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

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

I've been trying diligently to avoid any ownership terminology - if they
have any similarity to IP-related things, it's probably much more like IP
addresses: you have to show need and you can't always take them with you.
(For landline, it's *local* number portability. If you obtained a 212
number, you can't get a landline in LA with that number, at least at the
moment. You can't request a specific number, even if it is available, etc.)

On Jun 17, 2013, at 1:46 PM, Peterson, Jon wrote:
> 
> You may know more about number portability than me, but I don't agree 
> with your assessment of it here. At best, I'd say that number 
> portability in America allows consumers to choose which carrier "owns" 
> a number. This is also a reason I keep putting scare quotes around 
> "owns," because the assumptions of the DNS don't apply to users of 
> telephone numbers, at least not in our current regulatory environment. 
> If you are a registrant, you have the authority to configure your zone 
> - that sounds close enough to be ownership to me (even though the UDRP 
> or ICE can end your ownership under extreme conditions). If you have a 
> telephone number assigned to you, a carrier still decides what number it
rings.

____________________________________________________________________________
_____________________________________________

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

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Jun 2013 08:12:49 -0700

> notion of carrier of record with eye-watering nostalgia)

As someone who's been using the term ownership here, I'll note that I 
indeed meant it as an expedient and am happy to use whatever term is 
already common or that the group prefers.  The 'right to use' is the 
important issue here, not the legality of ownership.

Absent there being an established term, how about assignment and 
assignee, in place of ownership and owner?

d/

---

From: Michael Hammer <[email-masked]>
Date: Tue, 18 Jun 2013 15:15:20 +0000

Agree.  I had used it in the end-user perspective sense.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Crocker
Sent: Tuesday, June 18, 2013 11:13 AM
To: Richard Shockey
Cc: [email-masked]; [email-masked]; [email-masked];
'Peterson, Jon'; 'Henning Schulzrinne'
Subject: Re: [stir] current draft charter

On 6/18/2013 8:06 AM, Richard Shockey wrote:
> Although people sometimes like using ownership as a shortcut, it's 
> more of a right of use really. (I'm sure some here will remember 
> discussions on the notion of carrier of record with eye-watering 
> nostalgia)

As someone who's been using the term ownership here, I'll note that I indeed
meant it as an expedient and am happy to use whatever term is already common
or that the group prefers.  The 'right to use' is the important issue here,
not the legality of ownership.

Absent there being an established term, how about assignment and assignee,
in place of ownership and owner?

d/

---

From: Richard Barnes <[email-masked]>
Date: Tue, 18 Jun 2013 11:17:21 -0400

> in place of ownership and owner?

That would be consistent with usage in the Internet number / RPKI space.
 The verb "to hold" is also used, e.g., the holder of number resources.

--Richard

> ______________________________**_________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/stir<https://www.ietf.org/mailman/listinfo/stir>
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Jun 2013 08:43:27 -0700

> telephone numbers in the system too.

The task of the current effort is to be able to determine whether the 
value in the From header field is authorized for use.  This means 
checking with an authority for the assignment of the value.

(Forgive me, but on review I don't see any text in the draft charter 
that is as simple and direct as the above, in terms of stating the basic 
deliverable for this effort.)

For each type of data that can go in the From field, there's likely to 
be a different assignment authority and very possibly important 
differences in the mechanisms for doing queries, to determine 
authorization.

The desire for keeping things generic is understandinable; it's 
appealing.  But I doubt there's an existence proof for its working on 
something of this scale and criticality over the open Internet.

That is, take the current, known case and solve it as cleanly as 
possible.  Trying to solve possible future alternatives is almost 
certainly a distraction, of the type that will introduce complexity and 
delays.

d/

---

From: <[email-masked]>
Date: Tue, 18 Jun 2013 15:44:53 +0000

Either of these would work fine for me.

I don't want to make it sound more complex than necessary but would just note that using the term "assignee" is sometimes also tricky. For example, a number range assignee may remain the same even though numbers have been ported out of that range. (Incidentally, in a number of national numbering plan, it's always the assignee's responsibility to provide an annual report on the use of that range (and on all of its assigned ranges), which may therefore oddly enough include numbers that have been ported out)

Using your terms, in these cases, the holder has a number in a range which is and remains assigned to a party it (the holder) has no relationship with.

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

From: Richard Barnes [mailto:[email-masked]]
Sent: Tuesday, June 18, 2013 5:17 PM
To: Dave Crocker
Cc: Richard Shockey; FOUQUART Philippe OLNC/OLN; [email-masked]; Peterson, Jon; Henning Schulzrinne
Subject: Re: [stir] current draft charter

On Tue, Jun 18, 2013 at 11:12 AM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:

As someone who's been using the term ownership here, I'll note that I indeed meant it as an expedient and am happy to use whatever term is already common or that the group prefers.  The 'right to use' is the important issue here, not the legality of ownership.

Absent there being an established term, how about assignment and assignee, in place of ownership and owner?

That would be consistent with usage in the Internet number / RPKI space.  The verb "to hold" is also used, e.g., the holder of number resources.

--Richard

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net<http://bbiw.net>
_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

---

From: <[email-masked]>
Date: Tue, 18 Jun 2013 15:54:50 +0000

I agree, you may find exceptions in Europe as well more in the short number category though (eg 118 series used as a brand), but they're just that, an exception. 

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

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Tuesday, June 18, 2013 5:06 PM
To: FOUQUART Philippe OLNC/OLN; 'Henning Schulzrinne'; 'Peterson, Jon'
Cc: [email-masked]; [email-masked]
Subject: RE: [stir] current draft charter

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

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

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

rings.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Jun 2013 13:36:18 -0400

> here as a place to look for inspiration, perhaps.

I read LoST a long time ago, and skimmed it again today, but I don't get any inspiration relative to STIR.  What dots am I supposed to be connecting?
No need for a long explanation, just some hints would be good. :)

> telephone numbers in the system too.

Right, so I was thinking about that too, if we were to use a DNS-based approach (or anything with a derived URL).

I think that's still possible even for email-style names.  For example, when receiving a request from [email-masked]' we could do a DNS lookup for '_cid.foo.com' or some such pre-defined naming scheme, to get the caller-id cert for 'foo.com'; or the RR for that DNS key could redirect us to somewhere else if need be.  Or we could do an HTTP automatically for 'http://foo.com/cid', or even 'http://foo.com/cid/ldkjhlashl' where the last part is a hash of the username.

Or if we want the signer to be able to specify different certs for different requests, we support including a small token that gets appended to the automatic DNS or URL scheme for cert retrieval.  For example up to a 16-character token.  The only reason to limit its size would be to possibly get it (along with the signature and other info) through PSTN links in a UUI or whatever, but if we don't care about that for the email-style name cases then we could continue using the Identity-Info header for that case.  I recognize the nice property of Identity-Info giving the URL was the cert could be hosted somewhere else, separate from the From's domain.

> credentials for the same identity.

Right so I think we're all on the same page for that then. :)

> Just like the same cert could be

I'm ok with specifying multiple protocols for accessing it - I mean that'll probably happen anyway (my company's products support half a dozen different ones to access routing DBs, for example) - but I think there needs to be one that's mandatory-to-implement, to get interoperability.  Even if we believe *only* carriers will be the ones to query for STIR certs, many carriers buy products from multiple vendors they need to interoperate.  Even the ones that buy the SIP-based equipment from only one vendor, often get the databases (or access to a separately managed one) from someone else.

> administered in those databases.

Yup.  As I said, it would help a heck of a lot to get this into the NPAC-type databases. :)

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 18 Jun 2013 13:55:33 -0400

> No need for a long explanation, just some hints would be good. :)
LoST avoids a golden root by establishing a kind of transitive trust model where an entity called a "Forest Guide" knows about other Forest Guides and their coverage region by some unspecified means and can refer a request for service in one of the known coverage regions to the proper Forest Guide.  Rather than having a root and a delegation model, it relies on Forest Guide operators working out who should be trusted among themselves.

---

From: "Wendt, Chris" <[email-masked]>
Date: Tue, 18 Jun 2013 18:02:11 +0000

+1 
We are very much on-board with the direction of this discussion, DNS lookup is the way we would lean given vendor support for DNS/ENUM vs. HTTP.  I think there is also something to say for keeping a limited scope of DNS as a good thing, vs. the infinite extensibility of HTTP.

Does the current draft charter include this general direction as in scope?

---

From: Michael Hammer <[email-masked]>
Date: Tue, 18 Jun 2013 18:12:11 +0000

But, I would modify that to have a Chief Forester (aka FCC) that points to
the respective Forest Guides (aka SP number block holders) to resolve a
query from the general public.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Tuesday, June 18, 2013 1:56 PM
To: Hadriel Kaplan
Cc: [email-masked]; Peterson, Jon; Henning Schulzrinne
Subject: Re: [stir] current draft charter - ENUM and databases

> I read LoST a long time ago, and skimmed it again today, but I don't get
any inspiration relative to STIR.  What dots am I supposed to be connecting?
> No need for a long explanation, just some hints would be good. :)
LoST avoids a golden root by establishing a kind of transitive trust model
where an entity called a "Forest Guide" knows about other Forest Guides and
their coverage region by some unspecified means and can refer a request for
service in one of the known coverage regions to the proper Forest Guide.
Rather than having a root and a delegation model, it relies on Forest Guide
operators working out who should be trusted among themselves.
_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Jun 2013 14:54:02 -0400

We already have a transitive-trust of model for caller-id: P-Asserted-Identity.
It's the lack of faith in transitive-trust that brought us here, isn't it?

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 18 Jun 2013 19:26:38 +0000

I wouldn't characterize it as transitive trust in that sense, no. Think
about it like a whole nation-state is under a tree, and you ask your local
Forest Guide if you need to find the tree of another nation-state. It's a
way to let non-overlapping authorities opt in to cooperating on a global
system. So yes, you trust your own tree to be able to point you to other
trees as a form of lateral delegation, as an alternative to top-down. But
within the +1 tree, for example, there is a direct delegation of
authority. 

Jon Peterson
Neustar, Inc.

On 6/18/13 11:54 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>>> I read LoST a long time ago, and skimmed it again today, but I don't
>>>get any inspiration relative to STIR.  What dots am I supposed to be
>>>connecting?
>> LoST avoids a golden root by establishing a kind of transitive trust
>>model where an entity called a "Forest Guide" knows about other Forest
>>Guides and their coverage region by some unspecified means and can refer
>>a request for service in one of the known coverage regions to the proper
>>Forest Guide.  Rather than having a root and a delegation model, it
>>relies on Forest Guide operators working out who should be trusted among
>>themselves.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Jun 2013 12:36:20 -0700

On 6/18/2013 12:26 PM, Peterson, Jon wrote:
>So yes, you trust your own tree to be able to point you to other
> trees as a form of lateral delegation, as an alternative to top-down.

Huh?  How is this not a transitive trust model?

d/

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 18 Jun 2013 15:38:33 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peterson, Jon
Sent: Tuesday, June 18, 2013 3:27 PM
To: Hadriel Kaplan; Brian Rosen
Cc: [email-masked]; Henning Schulzrinne
Subject: Re: [stir] current draft charter - ENUM and databases

within the +1 tree, for example, there is a direct delegation of authority. 

[RS> ]  Sort of .. The North American Numbering Plan (NANP) is an integrated
telephone numbering plan serving 20 North American countries that share its
resources. These countries include the United States and its territories,
Canada, Bermuda, Anguilla, Antigua & Barbuda, the Bahamas, Barbados, the
British Virgin Islands, the Cayman Islands, Dominica, the Dominican
Republic, Grenada, Jamaica, Montserrat, St. Maarten, St. Kitts and Nevis,
St. Lucia, St. Vincent and the Grenadines, Trinidad and Tobago, and Turks &
Caicos.

Jon Peterson
Neustar, Inc.

On 6/18/13 11:54 AM, "Hadriel Kaplan" <[email-masked]> wrote:

>>Guides and their coverage region by some unspecified means and can 
>>refer a request for service in one of the known coverage regions to 
>>the proper Forest Guide.  Rather than having a root and a delegation 
>>model, it relies on Forest Guide operators working out who should be 
>>trusted among themselves.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 18 Jun 2013 19:54:37 +0000

I'm not saying that you don't trust your Forest Guide to find you other
trees, but I don't think it is an apples-to-apples comparison to suggest
this is comparable to the transitive trust we see in SS7 signaling and in
PAI. 

And Mr. Shockey your point is well taken that "nation-state" was imprecise
there.

Jon Peterson
Neustar, Inc.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Jun 2013 18:29:52 -0400

Having been involved in LoST, this isn't quite the same as the PAI "transitive trust". In this particular case, NRA or number assignment authorities would announce their coverage regions, and maybe additional information, such as entry points into DNS or data stores. Each entity would only have to trust announcements, presumably signed, that it likes, rather than receiver of information D trusting that A, B and C on the call path are trustworthy and didn't mangle or fake the information, as in PAI.

I don't think there's much of an issue with number allocators trusting each other, compared to trusting a random carrier the recipient has never heard of.

Thus, I'd avoid the use of the term "transitive" trust here.

Henning

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 19 Jun 2013 13:14:32 +0000

I am on board using dns for lookup. One question in your example: When you
receive [email-masked], how do you derive it to "_cid.foo.com"? Do you
suggest _cid is the tn or some other identifier?

On 6/18/13 1:36 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>I think that's still possible even for email-style names.  For example,
>when receiving a request [email-masked]' we could do a DNS lookup for
>'_cid.foo.com' or some such pre-defined naming scheme, to get the
>caller-id cert for 'foo.com'; or the RR for that DNS key could redirect
>us to somewhere else if need be.  Or we could do an HTTP automatically
>for 'http://foo.com/cid', or even 'http://foo.com/cid/ldkjhlashl' where
>the last part is a hash of the username.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 19 Jun 2013 13:37:04 +0000

Is that out of scope?

Should we focus on E.164 first, email-style names second, and the
interworking of the two third?

That wouldn't preclude reuse of solution to one for the other, or thinking
about that in advance.
But, we are talking about two different authority delegation trees here and 
I am not sure if you want one constrained by solutions for the other.

If we do, then at least make it clear that is a decision being made.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lee,
Yiu
Sent: Wednesday, June 19, 2013 9:15 AM
To: [email-masked]
Subject: Re: [stir] current draft charter - ENUM and databases

On 6/18/13 1:36 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>when receiving a request [email-masked]' we could do a DNS lookup 
>for '_cid.foo.com' or some such pre-defined naming scheme, to get the

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Jun 2013 06:40:51 -0700

> interworking of the two third?

That does sound pragmatic, doesn't it?

d/

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 19 Jun 2013 14:37:23 +0000

No disagreement. I am curious what Hadriel tried to illustrate in the
example so that I can understand his idea better.

On 6/19/13 9:37 AM, "Michael Hammer" <[email-masked]> wrote:

>Lee,

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Jun 2013 13:12:09 -0400

[background:] For the "email-style" case what I mean is a source identity of something like [email-masked]', where by definition 'foo.com' is authoritative for usernames within its domain, and the scope of the 'alice' is constrained to the 'foo.com' domain.  What I *don't* mean is an E.164 that just happens to be encoded in a SIP URI like 'sip:[email-masked]'.  There is no TN for a "email-style" URI, for the term "email-style" I'm using anyway.

So for en email-style URI, the premise I'm assuming is the same as RFC 4474: a certificate identifying 'foo.com' signed by a trusted CA is sufficient to believe it's really a valid From of [email-masked]'.  So all the verifier needs is the certificate of the From's domain, to verify the signer/originator can claim the user name.  In RFC 4474 that certificate is retrieved via an HTTP URL that the originator provides in a SIP header.  I'm just saying it's not absolutely necessary that a URL be provided in a SIP header, but we could instead get it from DNS.

We have can't just look up the DNS domain key of 'foo.com' to get the certificate, though, because 'foo.com' will resolve to stuff used for other things that we don't care about.  So a relatively common tactic people use is to prefix the DNS query key with a pre-defined/standardized/agreed-upon string for a specific node of the domain (creating an artificial name basically).  The '_cid' is just an example of such a prefix string we could standardize using.  So everyone would know to add a '_cid.' to the domain name of the email-stlye domain in the received From to find the cert in DNS for that domain; and that domain would know to put it there for everyone to get.

-hadriel

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 19 Jun 2013 17:23:43 +0000

Can we get the dnskey record and verify it by the ds record and forget the
whole CA thing?

On 6/19/13 1:12 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>We have can't just look up the DNS domain key of 'foo.com' to get the
>certificate

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Jun 2013 13:47:15 -0400

Yup, though I still think you'd want to do that for an artificial node name like '_cid.foo.com' or whatever, rather than for 'foo.com'.

-hadriel

---

From: "Wendt, Chris" <[email-masked]>
Date: Wed, 19 Jun 2013 18:04:24 +0000

Or overload something like sbc.foo.com for both SIP routing as well as public key distribution for validating signed SIP URI, for example. ;)

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 19 Jun 2013 18:18:33 +0000

I think this list has gotten bogged down in the question of how to
download credentials at the verification service. I sense this is
motivated by a feeling that we are going to have a beauty contest and pick
one way to download credentials, and everyone would like it to be their
favorite way.

I don't really look at the STIR problem that way, though. I don't really
care, at the end of the day, how a verification service downloads
credentials. I don't think we even need to arrival a single way of doing
it. The Identity-Info header of RFC4474 gives verification services a hint
of where they could acquire credentials. Nothing about RFC4474 assumes
though that the verification service doesn't already have a public key for
the auth service, or that the verification service doesn't have its own
means of looking up credentials in a store, say (see Step 1 of Section 6
of RFC4474). Dereferencing the Identity-Info is not in that strict sense
required.

Even when there verification service does dereference the URI in
Identity-Info to get a credential, RFC4474 leaves the door pretty wide
open for what protocols can be used: it does specify HTTP as MTI, but this
is not exclusive. We discussed using SIP itself (with a fetch SUB), CID
for multipart MIME and several other options. I can even imagine using a
DNS URI for this, especially for a DANE or DANE-like case where you want
to tip off the verifier that the public key can be found in the DNS.
Again, the presence of a DNS URI in Identity-Info would just be a hint, a
"in case you didn't know, my public key is in a DANE record." Maybe some
verification services wouldn't need that hint as they always check the DNS
for a public key.

So you could argue even that at an over-the-wire level, we wouldn't even
need to change Identity-Info to support using the DNS as a way to access
credentials. What would need to change, of course, is the logic used by
auth/verification services to handle telephone numbers, and for DANE-like
cases, to check reference integrity. This, I think, is where the actual
STIR work should lie. I don't think we should try to legislate a one true
way that services must make credentials available. We should introduce
flexibility here, even if it means perhaps having two MTIs for
Identity-Info URI schemes instead of one. But we shouldn't get caught up
on what protocol you use to fetch credentials.

Jon Peterson
Neustar, Inc.

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 19 Jun 2013 21:30:30 +0000

I pretty much agree what you said. The Identity-Info field is very
flexible. I guess we need to agree with the problem we tried to solve
first in stir. My gut feeling is we may be able to use rfc4474 plus some
minor twists to get what we want.

---

From: Wilhelm Wimmreuter <[email-masked]>
Date: Fri, 28 Jun 2013 15:59:33 +0200

Sorry, overlooked this replay.

Guess it basically does not matter how many certs we have.

There must be just be at least one authoritative cert be attached to each number.

 This can be a cert of an end-user or the cert of the operator that is attached to multiple numbers in case the operator / PBX or service provider signs "on behalf of" users.

 Such a model also would allow re-signing of "legitimate spoofers" such as call-centers and that like.

 It perfectly supports a delegation model which by default can be setup in a way to make the telco the primary signee and that allows the end user become a signee later on.
... This of course will allow some fiddling on the access part prior we reach the signee in that case the telco. Therefore we shall try to make the end-user the only signee for the long run.

Willi