Re: [stir] New draft draft-rosenberg-stir-callback-00

[Jonathan Rosenberg <[e-mail]>]

Good to be here Jon. Frankly, I got so tired of multiple robocalls each
day, I woke up one morning and decided to do something about it. That, in
addition to feeling some personal accountability for the problem for not
having baked in a solution into SIP at the outset.

You are of course correct that one could in fact take just the SIP aspect
of this draft, and emit it from the CA to rather than have it be
distributed amongst agents. Though that is a lower bar still for deployment
than an ENUM-style process, I think its still quite a high bar for a CA in
terms of the accountability that it entails. The CA still becomes
accountable for holding an accurate and authoritative database of numbers
for (presumably) a very large number of users, for keeping it up to date,
for handling corrections should an error get made (which invariably it will
for some reason), for deciding how to price such a service, for dealing
with whatever local regulations their lawyers think they may be signing up
for by being in the telco business. Since, regardless of how this database
gets populate, they are in the telco business because they sell a telco
database.

Distributing the work distributes the accountability, and places it in the
first party (the entity that consumes it) rather than the third party (with
someone else). That is a dramatic difference.

-Jonathan R.


On Fri, Mar 2, 2018 at 12:56 PM, Peterson, Jon <[e-mail]>
wrote:

>
> Well nice of you to join us here, finally!
>
> So broadly, we have long needed some kind of proof-of-possession test for
> calling party numbers to help expedite STIR deployment. We've sketched out
> various approaches like doing that with SMS return-routability tests (see
> section 4.2 of draft-ietf-acme-telephone, say), and having a SIP-level way
> to do such a test definitely seems like a valid approach. I don't recall
> that we've considered a kind of "callback on first use" (COFU?) approach to
> this before. It has some good properties.
>
> I guess the one comment I'd make about the overall direction though is
> that up until now, I've been envisioning staging these proof-of-possession
> tests within ACME. In other words, propping up a boulder implementation
> that would challenge with some kind of routability test to establish
> effective proof of control of a number in order to get you an 8226
> individual-TN cert. Practically speaking, that ACME challenge could use
> stir-callback pretty much as your draft describes it. I don't think
> deploying an ACME CA to do this faces anything like the practical hurdles
> that faced public ENUM, say. It's something anyone could do tomorrow (if
> the necessary elements supported stir-callback tomorrow).
>
> I suppose, speaking to the example in the stir-callback Overview section,
> that requiring Bob's call agent to maintain a "validation cache" that maps
> calling party numbers to public keys serves a similar purpose to having a
> CA that effectively attests that calling party numbers are associated with
> certificates. The question is whether that mapping database is better
> staged in one or more ACME-style CAs or in every call agent that
> participates in this architecture. Off the top of my head it doesn't seem
> easier to be from an implementation or deployment standpoint to stage this
> in the call agents. And doing this in a way that gives you an 8226 cert -
> even a self-signed one - would I think have a more realistic incremental
> deployment path toward the long-term STIR architecture.
>
> So definitely support having this capability, I think there are choices to
> make about exactly how to approach it, and we should discuss in London. We
> need this, so I'm happy to see some energy around it.
>
> Jon Peterson
> Neustar, Inc.
>
> From: stir <[e-mail]> on behalf of Jonathan Rosenberg <
> [e-mail]>
> Date: Thursday, March 1, 2018 at 6:14 PM
> To: "[e-mail]" <[e-mail]>
> Subject: [stir] New draft draft-rosenberg-stir-callback-00
>
> Hey all - been a while :)
>
> Cullen and I wrote up a concept for using STIR with self-signed or domain
> based certs, and then handling number validation with an in-band callback.
> We think its a promising approach to accelerate STIR deployments, since it
> allows them to happen without the cert infrastructure being in place.
>
> https://www.ietf.org/id/draft-rosenberg-stir-callback-00.txt
>
> Comments welcome.
>
> -Jonathan R.
>
> --
> Jonathan Rosenberg, Ph.D.
> [e-mail]
> http://www.jdrosen.net
>
>


-- 
Jonathan Rosenberg, Ph.D.
[e-mail]
http://www.jdrosen.net