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

[Eric Rescorla <[e-mail]>]

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
>
> 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
>