Re: [stir] current draft charter - ENUM and databases

[Henning Schulzrinne <[e-mail]>]

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

> 
> On Jun 16, 2013, at 5:39 PM, Henning Schulzrinne <[e-mail]> wrote:
> 
>>> 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?
> 
> 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.

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 [phone]

+1 translates to 

https://oldmoon.com/12025551234

NAPTR 10 100 "u" "E2U+https" "!^.*$!https:\[e-mail]!"

(I'm not a DDDS expert, so this is likely wrong, but hopefully illustrates the idea.)

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

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

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


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

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.


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

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.

> 
> -hadriel
> 
>