Re: [stir] stir input drafts

[Hadriel Kaplan <[e-mail]>]

On Jun 11, 2013, at 10:17 PM, "Peterson, Jon" <[e-mail]> wrote:

> However, based on all of our prior discussions we knew that there were use
> cases where no amount of refining RFC4474 was going to help. Pretty much
> any use case that transited a PSTN gateway necessarily would need
> something different. We therefore started sketching out some strawmen for
> how we could attack that part of the problem by creating an out-of-band
> connection of some kind, without resorting the DHT of ViPR. EKR came up
> with a model for this that had less security problems than what I was
> thinking of, which is documented here:
> https://github.com/ekr/ietf-drafts/blob/master/draft-rescorla-callerid-fall
> back.txt

One nice thing about the Call Detail Service idea is the Call Detail database already exists, for US-based calls.
It's at something like:
calls.prism.nsa.gov
Unfortunately they probably won't let us access it for caller-id verification.

But on a more serious note, I mentioned this at the meeting in DC but I'll repeat it for posterity: the really useful property of a CDS model, or potentially other models that don't rely on the signaling to carry anything, is that once a calling party opts-in to the idea, they prevent anyone else from spoofing them so long as the called party verifies.  By that I mean you can know when a received call's caller-id *must* be verifiable, and thus be able to reject it if it's not.  For example the instant Fidelity joins such a model for their outbound calls, no one else can spoof their numbers, because no matter how their call got to you, as soon as you check the CDS you'll know if it's legit or being spoofed.

As opposed to any in-band method (4474, p-asserter signing, etc.), where you can only know a caller-id is valid if and only if the received signaling has whatever new headers we define.  So when you receive a call claiming to be from Fidelity, but it has no such headers, you don't know if it doesn't have the headers because the call is fraudulent, or just Fidelity isn't doing this new thing yet, or just the call came through some PRI circuit in the middle somewhere.

So it's very useful for overcoming the typical early adoption problem.

If we use an in-band method with a DNSSEC/DANE-type model, regardless of whether we get the new headers or not we can get the property of knowing whether Fidelity is doing this new thing or not yet; but we still don't know if the headers just got lost in translation. (huh, there's a triple pun there for old bell-heads)

-hadriel