Re: [stir] current draft charter

[Michael Hammer <[e-mail]>]

Inline...

-----Original Message-----
From: Hadriel Kaplan [mailto:[e-mail]] 
Sent: Monday, June 17, 2013 12:59 PM
To: Michael Hammer
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: Re: [stir] current draft charter


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

> 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.


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 '[phone]'
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.
> E.164 is already the hierarchy, so no second hierarchy is needed.

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


> 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