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

[Rohan Mahy <[e-mail]>]

Re: discussing SPIN in MIMI

The MIMI bar bof is only an hour. I also have two drafts I would love to
talk about, but we likely won't have time to discuss any specific drafts.
We should figure out scope/requirements and do some BoF proposal bashing.

Thanks,
-rohan

On Sat, Jul 23, 2022, 18:18 Jonathan Rosenberg <[e-mail]> wrote:

> Not currently on dispatch agenda. I was planning to discuss it at the mimi
> bof on Monday.
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
> *From:* dispatch <[e-mail]> on behalf of Richard Shockey
> <[e-mail]>
> *Sent:* Saturday, July 23, 2022 3:30:47 PM
> *To:* Eric Rescorla <[e-mail]>; Jonathan Rosenberg <
> [e-mail]>
> *Cc:* DISPATCH <[e-mail]>
> *Subject:* Re: [dispatch] New I-D - SPIN - on voice/video interop between
> app providers
>
>
>
>
> This is part of dispatch on Monday right? Ok this should be fun and
> Jonathan I did find my Dynamicsoft cap.
>
>
>
> 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. ☺
>
>
>
> Its just I’m enough of an old curmudgeon to understand the very very
> significant headwinds you are going to run into.
>
>
>
> It is a great discussion BTW.
>
>
>
> —
>
> Richard Shockey
>
> Shockey Consulting LLC
>
> Chairman of the Board SIP Forum
>
> www.shockey.us
> <https://protect-us.mimecast.com/s/6uh-C5yVlksMp4LYTzsKYN?domain=shockey.us>
>
> www.sipforum.org
> <https://protect-us.mimecast.com/s/V4MECjR5vjtYGPQ1hxn_5N?domain=sipforum.org>
>
> www.sipnoc.org
> <https://protect-us.mimecast.com/s/EiuSCkRBwktkX1z3F0Wymz?domain=sipnoc.org>
>  (2022)
>
> richard<at>shockey.us
> <https://protect-us.mimecast.com/s/RsxEC82WonSXPLp8UM6_rg?domain=shockey.us>
>
> Skype-Linkedin-Facebook –Twitter  rshockey101
>
> PSTN [phone]
>
>
>
>
>
> *From: *dispatch <[e-mail]> on behalf of Eric Rescorla <
> [e-mail]>
> *Date: *Saturday, July 23, 2022 at 11:30 AM
> *To: *Jonathan Rosenberg <[e-mail]>
> *Cc: *DISPATCH <[e-mail]>
> *Subject: *Re: [dispatch] New I-D - SPIN - on voice/video interop between
> app providers
>
>
>
> > Lots of good thoughts in here. I'll start with two initial reactions
> > to your comments (and hoping we can discuss further at mimi on
> > Monday):
> >
> > You are correct that the current SPIN protocol design does require
> > both parties to be concurrently online. Since the originating party is
> > the one initiating communications, this means they'll be online
> > anyway. So the issue is that of the receiving party. Practically
> > speaking, since this is targeted at mobile, the amount of time these
> > devices are on and connected to the Internet is very high.
>
> This rather to be fitting the problem statement to the solution
> rather than the solution to the problem statement. AFAICT the
> DMA doesn't limit interop requirements to mobile and there are
> plenty of people connected to messengers on desktop. Similar
> comments apply to the limitation to E.164 numbers and not e-mail
> addresses, as sftcd observed.
>
>
> > And that is my second comment - that it requires some kind of central
> > authority (the RS or "Richard SHockey" ;) in your proposal). This
> > central authority will have a full catalog of phone numbers for all
> > users globally along with their communications applications. That is
> > worrisome from a privacy perspective, but also a practical perspective
> > of - who would be willing to run such a service, how does it monetize
> > to justify costs, etc? With SPIN, there is no new actor that needs to
> > be introduced. SPIN also doenst require the user's contact information
> > to ever be stored in the cloud by Apple or Google; the real-time
> > nature of the address resolution means it can be stored locally
> > on-device. I think this provides a higher degree of privacy and doesnt
> > require the OS vendors to do something they arent already doing,
> > reducing the barrier to deployment. Apple/Google dont need to run a
> > new cloud service, they just need to add another preference stored
> > on-device.
>
> I would make several points here.
>
> First, it's a mistake to think that Google and Apple don't need to run
> a new cloud service. In SPIN the originator has a credential from the
> OS vendor, which effectively makes the OS vendor a CA. CAs need high
> availability to handle new issuance, revocation, etc. I suppose you
> could redesign the system to have two-way online SMS verification,
> but that's not how it looks now, and that would come with some
> new potential problems.
>
> Second, as I observed in my email, if we're willing to deal with a
> very small number of mobile device vendors--which is inherent in the
> current SPIN design--then each device vendor can just run its own
> database and callers can try both. Note that by assumption the device
> vendor already knows your number and as a practical matter they at
> least know which messaging apps you have installed, even if not which
> ones you have accounts on (via the app store).
>
> WRT the overhead of the service, I think you're rather overestimating
> the investent here: we have a sense of what it costs to run something
> of about this scale in the form of Let's Encrypt and we're talking on
> the order of 10 million/year. If it's the OS vendors who do it, it's
> not like they don't have much larger services already. It's true that
> it isn't necessarily in their interest to do so, but the whole premise
> of this work is that they are subject to a regulatory mandate, so I
> don't think that's really dispositive. Even if it's to be third party
> service, it doesn't seem like it need be that hard to fund, given
> that, again, this is the result of a government mandate. One could
> also imagine user fees paid by messenger apps, etc.
>
> I do think the privacy point is a very real concern, especially if
> it's not run by the device vendors, who, as I say, largely have this
> information already. There are really two concerns here:
>
> 1. The existence of the database.
> 2. The ability of entities to query it.
>
> The existence seems like it's addressable in a number of ways.  For
> example, you could have a central service which you query which only
> knows which vendor is associated with which device, and then queries
> the vendor on your behalf (insert crypto handwaving here).
>
> The existence of a query interface at all seems somewhat more
> challenging.  However, I would note that many of these systems already
> effectively have such an interface (for instance if you can try to add
> someone to your buddy list and it behaves differently if they exist or
> not), and need to have rate limiting and other anti-scraping measures.
> We might be able to repurpose these techniques here. Finally, I
> would note that SPIN actually provides the same interface in
> the form of the phone and so will need its own anti-probing
> mechanisms, except that those have to be distributed, whereas
> these can be decentralized.
>
> Anyway, looking forward to the discussion next week.
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Jul 23, 2022 at 7:26 AM Jonathan Rosenberg <[e-mail]>
> wrote:
>
> Lots of good thoughts in here. I'll start with two initial reactions to
> your comments (and hoping we can discuss further at mimi on Monday):
>
>
>
> You are correct that the current SPIN protocol design does require both
> parties to be concurrently online. Since the originating party is the one
> initiating communications, this means they'll be online anyway. So the
> issue is that of the receiving party. Practically speaking, since this is
> targeted at mobile, the amount of time these devices are on and connected
> to the Internet is very high. As such, I dont know that its worth
> optimizing for the remaining small percentage when they are not. If this
> didnt come with tradeoffs, it certainly is a limitation worth addressing.
> But, I do worry about the tradeoff.
>
>
>
> And that is my second comment - that it requires some kind of central
> authority (the RS or "Richard SHockey" ;) in your proposal). This central
> authority will have a full catalog of phone numbers for all users globally
> along with their communications applications. That is worrisome from a
> privacy perspective, but also a practical perspective of - who would be
> willing to run such a service, how does it monetize to justify costs, etc?
> With SPIN, there is no new actor that needs to be introduced. SPIN also
> doenst require the user's contact information to ever be stored in the
> cloud by Apple or Google; the real-time nature of the address resolution
> means it can be stored locally on-device. I think this provides a higher
> degree of privacy and doesnt require the OS vendors to do something they
> arent already doing, reducing the barrier to deployment. Apple/Google dont
> need to run a new cloud service, they just need to add another preference
> stored on-device.
>
>
>
> Thx,
>
> Jonathan R.
>
>
>
>
>
> On Fri, Jul 22, 2022 at 11:22 AM Eric Rescorla <[e-mail]> wrote:
>
> Thanks for starting this conversation.
>
> I agree with a number of the the assumptions underlying
> this proposal, specifically:
>
> - What makes this potentially possible where previous efforts have
>   failed is the force of regulation, specifically the DMA.
>
> - Forward message routing is the most practical way
>   to establish who is entitled to a specific number.
>
> However, it seems to me that the specific design you describe
> has a number of suboptimal properties. In particular:
>
> - It requires the sending and receiving endpoints to be jointly
>   online. This is not unreasonable for voice calling but is
>   undesirable for messaging.
>
> - It makes the OS vendors certificate authorities, which (a) they may
>   not to be (b) gives users no real choices in their trust decisions
>   (specifically, even if I am an Apple user, I need to trust Android!)
>   and (c) is incompatible with purely open source systems.
>
> - It requires each individual relying party (caller) to make their own
>   verification, which makes the kinds of transparency mechanisms we
>   ordinarily use to detect impersonation or misissuance/misrouting
>   much more difficult, if not impossible [0].
>
> It seems to me that there are alternative designs which do not have
> this problem.
>
> As an intuition pump, consider a system in which we have a single
> central Resolution Service (RS).
>
> - When a user installs a communications application on their device,
>   that application contacts the RS, demonstrates control of the relevant
>   number via SMS answerback (i.e., the RS sends them a challenge via
>   SMS) [1]. The application is then able to store a record at the
>   RS with the relevant contact information. If there are multiple
>   applications, there would be multiple records.
>
> - The RS issues Alice a credential (e.g., a certificate) which she can
>   use to authenticate ownership of her number.
>
> - When Alice wants to call Bob, she (or rather the calling/messaging
>   application) looks up Bob's phone number in the registration
>   service, retrieves the appropriate records, and is able to select
>   whichever one is appropriate to complete the communication.  Alice
>   uses her credential to authenticate the call.
>
>
> This system addresses most of my objections above. Specifically:
>
> - It doesn't require the endpoints to be jointly online.
>
> - It is fully compatible with open source because it doesn't
>   require trusting the OS or OS vendor on the other end.
>   It doesn't give the user choices about who to trust because
>   they have to trust the RS (but see below).
>
> - It doesn't require online user verification, and so is
>   compatible with Certificate Transparency type systems,
>   audit of the RS, etc.
>
> I do want to flag one potential privacy issue with this class of
> design, which is that it allows the calling party to determine which
> messaging/calling applications a given user uses.  By contrast, a
> design like the one in SPIN allows for filitering on the receiving
> side (though that doesn't seem to be in the document). I'm not sure
> how big an issue this is, given that you can often join each service
> and then try to connect, but it's not ideal.  I do have some handwavy
> ideas for how to address this (e.g., ACLs uploaded the RS), but
> they're not fully fleshed out. I do think it's possible to address,
> however.
>
> Obviously, one giant RS isn't that desirable (although as I understand
> it, this is effectively how Local Number Portability works in the
> NANP). With that said, one view of the current SPIN proposal is that
> it has two big RSes, one run by Apple and one by Google: as described
> in S 5, the originating party has already done effectively the
> registration flow I describe above:
>
>    There are two ways in which the originating OS can obtain such a
>    certificate.  In one approach, the mobile OS would perform SMS
>    verification (again, invisibly, by absorbing the SMS it sends to
>    itself), and add an additional check of comparing it agaisnt the
>    mobile numnber the user claimed they owned during provisioning time
>    of the device.  The mobile OS vendor would be a valid CA, and then
>    generte a certificate valid for that individual phone number.  In an
>    alternative model, the telco uses certificate delegation [RFC9060],
>    and generates a certificate that is handed to the phone during device
>    provisioning.  The latter approach is more secure in some ways (as it
>    would no longer depend on SMS forward routability for authentication
>    of a user), but is much harder to deploy.
>
> In fact, one could design something with roughly similar security
> properties to the current draft by simply having Apple and Google
> expose an RS API for the endpoints which had already registered as
> above. The caller could then look up the target number in both Apple
> and Google APIs and skip the forward SMS pieces entirely. This seems
> less desirable than a single RS, but it would have a number of the
> same advantages, such as not requiring both endpoints to be online
> and being compatible with transparency mechanisms.
>
>
> With that said, we can also do better than a single central RS.  I
> don't have a complete design, but some thoughts are below.
>
> First, it seems like authentication and discovery are separate
> services, so we could have multiple CAs for telephone numbers that
> each do SMS verification (a similar structure to the WebPKI) but a
> single directory service. This would allow users (or really client
> applications) to make their own decisions about who to trust.
>
> One could also imagine having multiple RSes which stored phone number
> records as long as there was some mechanism for determining which RS
> had a given number. That mapping could then be on a single service or
> just replicated to each application vendor (it's really not that
> big). This would allow a diversity of RSs but with a single central
> reference point so the originating party wouldn't need to poll all of
> them.
>
> At any rate, I think this type of architecture is worth considering
> as an alternative to the design in this specification.
>
> -Ekr
>
>
> [0] As an example of this point, consider a nation-state attacker who
> controls the PSTN and wishes to covertly intercept Alice and Bob's
> communications: it reroutes the SMS messages from their communication
> and then completes the call itself. In the analogous context in the
> WebPKI, this creates a record in the CT log which can then be
> detected, but that is not the case here.
>
> [1] This might require some OS affordances, but I don't think
> they would be that hard to design.
>
>
>
>
> On Tue, Jul 12, 2022 at 7:13 AM Jonathan Rosenberg <[e-mail]>
> wrote:
>
> Hi fellow dispatchers -
>
>
>
> I wanted to call attention to the following draft submitted yesterday:
>
> https://www.ietf.org/archive/id/draft-rosenberg-dispatch-spin-00.txt
> <https://protect-us.mimecast.com/s/zrWFC9rGpoSzN9EVCPeIjN?domain=ietf.org>
>
>
>
> Abstract:
>
> This document introduces a framework and a protocol for facilitating
>
>    voice, video and messaging interoperability between application
>
>    providers.  This work is motivated by the recent passage of
>
>    regulation in the European Union - the Digital Markets Act (DMA) -
>
>    which, amongst many other provisions, requires that vendors of
>
>    applications with a large number of users enable interoperability
>
>    with applications made by other vendors.  While such interoperability
>
>    is broadly present within the public switched telephone network, it
>
>    is not yet commonplace between over-the-top applications, such as
>
>    Facetime, WhatsApp, and Facebook Messenger.  This document
>
>    specifically defines the Simple Protocol for Inviting Numbers (SPIN)
>
>    which is used to deliver invitations to mobile phone numbers that can
>
>    bootstrap subsequent communications over the Internet.
>
>
>
> Right now, we're looking to see if there is interest in working on this.
> Comments welcome.
>
>
>
> Thx,
>
> Jonathan R.
>
>
>
> --
>
> Jonathan Rosenberg, Ph.D.
> [e-mail]
> http://www.jdrosen.net
> <https://protect-us.mimecast.com/s/Vbm-C0RE2NtkgZw0F3V7Le?domain=jdrosen.net/>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
> <https://protect-us.mimecast.com/s/J12sCgJ8xOfqwpZ5cZUHyI?domain=ietf.org>
>
> _______________________________________________ dispatch mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/dispatch
> <https://protect-us.mimecast.com/s/J12sCgJ8xOfqwpZ5cZUHyI?domain=ietf.org>
>
> ------------------------------
>
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential information of Five9 and/or its affiliated entities. Access by
> the intended recipient only is authorized. Any liability arising from any
> party acting, or refraining from acting, on any information contained in
> this e-mail is hereby excluded. If you are not the intended recipient,
> please notify the sender immediately, destroy the original transmission and
> its attachments and do not disclose the contents to any other person, use
> it for any purpose, or store or copy the information in any medium.
> Copyright in this e-mail and any attachments belongs to Five9 and/or its
> affiliated entities.
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>