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

[Eric Rescorla <[e-mail]>]

On Fri, Jul 22, 2022 at 12:06 PM Brian Rosen <[e-mail]> wrote:

> IVC was never about replacing VRS, although it would have significantly
> changed how it worked if IVC ever became a reality.  There was a clear path
> forward, and we may yet take it, but I understand the issues of ever
> getting it adopted.
>
> I think if you don’t trust the platform vendor, you can’t trust any system
> that depends on a telephone number.  The fact that an SMS arrives with the
> TN that purportedly sent it depends completely on the platform correctly
> sending it and the one correctly receiving it (as well as the network
> operators).  It makes no sense to me not to trust it.  We HAVE to trust it.
>

I think perhaps you and I mean something different by "trust the platform
vendor". I inherently have to trust the device that I am using (though
perhaps that trust is verified by various mechanisms) but  (for instance)
if I am on an iPhone calling someone who has an iPhone I don't need to
trust Android. In addition, it's different to trust the software on a given
device than it is to trust the CA operations of a given vendor.

-Ekr




> Brian
>
> On Jul 22, 2022, at 1:08 PM, Richard Shockey <[e-mail]> wrote:
>
> <SIGH>
>
> OK btw here is the report the NANC produced on interoperable Video Calling
> at the request of the Hearing Impaired community to ultimately replace the
> US Video Relay System.  Of course the FCC never acted on the report. Eric
> you are correct the issue is ultimately regulatory since control of
> telephone numbers are fundamentally a nation state issue by statue. In the
> US BTW is USC 251 (e) 1
>
>
> https://nanc-chair.org/docs/reports/190912NANCInteroperableVideoCallingWorkingGroupFinalReport.docx
>
> More in line.
>
> *From: *dispatch <[e-mail]> on behalf of Eric Rescorla <
> [e-mail]>
> *Date: *Friday, July 22, 2022 at 11:21 AM
> *To: *Jonathan Rosenberg <[e-mail]>
> *Cc: *DISPATCH <[e-mail]>
> *Subject: *Re: [dispatch] New I-D - SPIN - on voice/video interop between
> app providers
>
>
> 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).
>
>
>
> RS>  Been there done that  ☺
>
>
>
> - 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.
>
> RS> There are serious privacy issues here in exposing the capabilities of
> end points.
>
>
>
>
>
>
>
> 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:
>
>
>
> RS> Yes the NPAC is a big hub and spoke database system that is very
> secure. Ultimately the NPAC data is cached within carrier networks for more
> distributed access.   Its also the way nearly every nation state actually
> does LNP Canada France Brazil etc. There are endless ancillary numbering
> databases that are also incorporated that address things like Do Not Call,
> the NANP itself, Reclaimed numbers etc that would have to be incorporated.
> Needless to say I get at least one call every 6 months or so about 6116 and
> I have been aware that there are some lunatics out there that have actually
> suggested Hyperledger for this kind of thing..
>
>
>
>
>
>    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.
>
> RS>  I would agree with this.
>
>
>
>
>
> 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
>
> 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
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________ dispatch mailing list
> [e-mail]://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>