Subject: [stir] stir input drafts

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Jun 2013 02:17:07 +0000

For the benefit of those recently tuning in to this channel, the input
drafts that kicked off the initial STIR discussion were the following:

First, as a bit of background, ISOC asked the IAB to comment on some
contributions to the WCIT process related to identifying the source of
communications. These included a pretty diverse set of problems, which we
addressed in a brief white paper that we then decided to immortalize as an
I-D:
http://tools.ietf.org/html/draft-cooper-iab-secure-origin-00

Henning saw that draft and asked to meet with a few IAB members and IETF
contributors to discuss the telephone side of this problem in Orlando. He
expressed particular interest in robocalling, as some of you may recall
from his IAB plenary presentation. We took an action item to write a
problem statement that focused on why we never managed to get identity
right for SIP, and what may have changed that might give us new leverage:
http://tools.ietf.org/html/draft-peterson-secure-origin-ps-00

Wracked with guilt over my own culpability in this mess, I got together
with Cullen and EKR to discuss RFC4474, and to at least get down a
statement of intention for what here needed fixing in the future. This
tries to divide cleanly between the question of how to improve the
coverage from signature (the Identity header) from how to specify
credentials other than domain name certs (the Identity-Info header).
http://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00

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

Of course there are a slew of other related drafts, many of which have
already been cited on the list here, as there has been investigation of
the failings of prior work for more than a decade now. There is now a
pressing need to address the problem, and the stars do seem to be aligning
in terms of new avenues for solutions.

We now return you to your regularly scheduled programming, already in
progress...

Jon Peterson
Neustar, Inc.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Jun 2013 01:29:09 -0400

> https://github.com/ekr/ietf-drafts/blob/master/draft-rescorla-callerid-fall

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