Re: [stir] CA Certs (was: Re: Rollout timeframe)

[Hadriel Kaplan <[e-mail]>]

On Jul 17, 2013, at 10:58 AM, Brian Rosen <[e-mail]> wrote:

> Small note:
> You would have to keep TTLs for at least U.S. zones under a few minutes to allow the 15 minute port.
> I'd actually probably set it at a minute or two.

I'm not sure if it really matters if the TTL is short, but it doesn't have to be short - at least not with CIDER.  The DNS name uses a "key index", which identifies which specific public key was used for signing the call - i.e., a single E.164 can have multiple public keys in DNS. (it's like a DKIM "selector", but an integer instead of string)  That key index value is sent in the SIP header.  It then becomes part of the generated DNS name used for the lookup.  So when a key changes, the DNS full name changes, and there's no cache collision.

You have to do something like that no matter what solution we end up with (even HTTP), because the carriers have to be able to change their key whenever they want without affecting in-flight call requests, and give time for the new key to propagate to the local copies carriers might have of the whole DB.  Plus it lets two or more agents claim the same phone number, for example the outsourced call-center or medical doctor scenarios.

So when a number gets ported, the new carrier uploads a public key into a new/unused key index value, and thus there's no collision when verifiers query for it, and no problem if they have an older key cached locally.  The TTL won't affect it.

For example, suppose my number is [phone].  My carrier has a private key for that, and it had uploaded the public key into the CIDER DB for index "2".  When it signs the message, that number "2" gets put into the STIR header info somewhere (draft-kaplan-stir-ikes-out-00 describes where it could be encoded, for SIP/SS7/XMPP).  When some verifier receives that message, it sees the "2" and the caller-id of [phone], and creates a DNS query for the name "2._cidkey.0.0.0.1.5.5.5.3.0.6.1.cid.example.org".  It gets back a TXT RR with the base64-encoded public key, verifies the message, etc.

So suppose I port the number to a new carrier.  The porting process happens, and the new carrier now uploads a new public key into the CIDER DB, but will now use/get index "3" or "12" or whatever.  It then uses that "3" in its SIP messages.  So a verifier will generate a DNS query for name "3._cidkey.0.0.0.1.5.5.5.3.0.6.1.cid.example.org".  Thus there's no DNS cache hit to worry about.


> Note that you are sure to get a bunch of trawlers looking for TNs that ported recently.  That may be a big problem, both for the server and for the idea.

It may be a problem, but it's not a problem for the server or the idea.  For one thing, CIDER can be deployed in a purely private/controlled manner.  That's up to the specific admin of each branch to decide (i.e., each national authority, or national admin, or whatever).  There's plenty of evidence of private DNS in use, including in the SIP provider world.

But anyway, *any* database-based solution which is deployed as open/unrestricted query access would have that problem.  Using HTTP doesn't mean people can't write scripts to generate HTTP queries, and putting certs in HTTP servers certainly doesn't prevent learning when the cert contents change.  It's not the protocol that causes the issue... it's how it's administered, deployed, and controlled.

-hadriel