Re: [dispatch] New I-D - SPIN - on voice/video interop between app providers

[Eric Rescorla <[e-mail]>]

On Sun, Jul 24, 2022 at 7:19 AM Peterson, Jon <[e-mail]>
wrote:

> .
>
>
>
> Ok but I do want to make abundantly clear that I have no objections for
> this work to go forward.  I do have some experience in the issues involving
> discovery <cough cough> … BTW I’ve been anxious for Brother Peterson to
> chime in here. ☺
>
>
>
> I mean, this is an expression of two strategies for telephone number
> mapping we’ve been playing around with here forever: using some kind of
> proof-of-possession check that is based on actually invoking the routing
> system; and building some kind of centralized DB that is populated based on
> authoritative information about where numbers get routed. Certainly I agree
> that our experience with ENUM should make us cautious about centralized
> approaches. But ultimately, to Ekr’s point, iMessage and similar
> applications build walled-garden versions of such databases for their own
> application routing, and while they elicit some interest from regulators,
> they are not only suffered to exist, but are among the dominant
> communications systems in the world.
>
>
>
> Ekr’s notion that the applications themselves could conduct their own
> proof-of-possession tests and then share that data strikes me as something
> that could be incrementally added to the basic SPIN idea. Whether that data
> is being shared with a centralized DB, or bilaterally between peering
> devices, the data should have the same security properties and format, I
> imagine. We could abstract that out and explore a couple different
> architectures for getting it where it needs to go. Doing the
> proof-of-possession check in real time with forward routing has the benefit
> of guaranteeing freshness, but the cost of not working for offline devices.
>

Freshness can be both good and bad. For instance, if each pair of users
does a freshness check, it is possible for a powerful attacker to *just*
impersonate Alice and Bob to each other and to nobody else. This is much
more difficult with a public credentials system because you can add
something like CT/KT.


> My intuition is that there’s less opportunities for shenanigans with
> forward routing than with letting applications do the proof-of-possession
> and vouch for it themselves. But we’d need to drill a little deeper to see
> if that’s true.
>

I do want to clarify that I'm not suggesting that applications should vouch
for themselves. Rather, I am suggesting that there be a set of certificate
authorities which require applications to do proof of possession and then
issue them a credential which is publicly verifiable.

-Ekr


>
> Jon Peterson
>
> Neustar (a TransUnion company)
>
>
>
> _______________ dispatch mailing list [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dispatch__;!!N14HnBHF!_TYntjGyg5uNCLSI_-nlD2HuOE9K-OLN5D_G2jWixsWT84fvv6ZIsEO4aFCBWl0enMPpdcIFAoY9yafOU56I$>
>