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

In case people are interested, I wrote up an overview of the discovery
situation (SPIN, etc.).

https://educatedguesswork.org/posts/messaging-discovery/

This also includes some ideas about how to address the privacy issues
around centralized discovery.

-Ekr

On Sun, Jul 24, 2022 at 2:25 PM Rohan Mahy <rohan.mahy@wire.com> wrote:

> 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 <jdrosen@five9.com> 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 <dispatch-bounces@ietf.org> on behalf of Richard
>> Shockey <richard@shockey.us>
>> *Sent:* Saturday, July 23, 2022 3:30:47 PM
>> *To:* Eric Rescorla <ekr@rtfm.com>; Jonathan Rosenberg <
>> jdrosen@jdrosen.net>
>> *Cc:* DISPATCH <dispatch@ietf.org>
>> *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 +1 703-593-2683
>>
>>
>>
>>
>>
>> *From: *dispatch <dispatch-bounces@ietf.org> on behalf of Eric Rescorla <
>> ekr@rtfm.com>
>> *Date: *Saturday, July 23, 2022 at 11:30 AM
>> *To: *Jonathan Rosenberg <jdrosen@jdrosen.net>
>> *Cc: *DISPATCH <dispatch@ietf.org>
>> *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 <jdrosen@jdrosen.net>
>> 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 <ekr@rtfm.com> 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 <jdrosen@jdrosen.net>
>> 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.
>> jdrosen@jdrosen.net
>> http://www.jdrosen.net
>> <https://protect-us.mimecast.com/s/Vbm-C0RE2NtkgZw0F3V7Le?domain=jdrosen.net/>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>> <https://protect-us.mimecast.com/s/J12sCgJ8xOfqwpZ5cZUHyI?domain=ietf.org>
>>
>> _______________________________________________ dispatch mailing list
>> dispatch@ietf.org 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
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>