Re: [stir] current draft charter

["Peterson, Jon" <[e-mail]>]

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" <[e-mail]> 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
>
>
>On Jun 12, 2013, at 6:02 PM, Brian Rosen <[e-mail]> wrote:
>
>> 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
>> 
>
>_______________________________________________
>stir mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/stir