From nobody Sun Jul 24 14:25:26 2022 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2663AC16ED04 for ; Sun, 24 Jul 2022 14:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.805 X-Spam-Level: X-Spam-Status: No, score=-6.805 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20210112.gappssmtp.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsE6JXReT0LE for ; Sun, 24 Jul 2022 14:25:19 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8FCC136304 for ; Sun, 24 Jul 2022 14:25:19 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id bf9so15360502lfb.13 for ; Sun, 24 Jul 2022 14:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0W80LyK5BvPdeMSpoEF1STkJ6oSM2J5+ZojcVAWoD1w=; b=M1HE5mO2KtoGpI+qf7QJGi2SuE2lbZJXP3m2MXnvjtGoYHHvvpunRMQ2yhA1adBpCA qTyAVhQ/6cO/q08ts3nE08edXsjFNYzGOqo03GwMvSru2bqO/UTKWQd7ioiTCLPLOsdf iq3M0RdvoHFda530ZbJcD5yiuZzJkigMNbXGl1IDj9GA4nLjgl5UdBeKwmMOakzmoyX5 j1+Ue+1ooSbjXSyfRpkI2zi+/53d0iYQ2lrDgz0t4zxAoS+RyU5PiBdV0fG8AgCrj0kS PDJBaR4BxfzfHxK69vQpFJMu0ZpQrOqDAgOcoGaLFbwUHsXdtzwa5t+lNROcLxjRM/JD FQNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0W80LyK5BvPdeMSpoEF1STkJ6oSM2J5+ZojcVAWoD1w=; b=PB+UzoUForQWnijXJiSMDjt29fIDUHbBeY1JA/cYNgTa/gw6Qup5MeQkGsOhSaQlsE VI06CGuh+Dw4g/mAJE2r6hZYlnVrZzIIz4GuyX56vtL7jNAA3jmhvtNg/G538Fuh3RXI du/2gNcS7HqvlybohV2Ehozj1psL+hs/if8cIK5XCNue+h+VuytmjbLEoYXIG6YeRfIH q3vg2Ir+j1ywG3oGLKO3EsJznC86KrCxrWxmXdP4JLHDpUKBhxD6nAfMS+/b6rI6tvR9 Y0Z3zOnBUKN1NsZaoowSsditjfB8ODPqQUogHEviFIaecIsvI8vp6g1QXi03BMfDgHnC Wrdw== X-Gm-Message-State: AJIora8Yx0zT5+fdQ1d7RnxFTo6gtE+pcZi03hJFRFbJPFHVgpsnDm3l pGu7f1k0R6MfA8ee0vYnauoQ7jQkD66FLcGL2vNuOg== X-Google-Smtp-Source: AGRyM1szy5XM0mEMJ01qVjI57uGR8Qezacl0VKAZgYzxafmSiACKbSCT+fmwC+I92D2seKdJxs7mnlz2yIgwIqV/ULY= X-Received: by 2002:a19:6449:0:b0:47f:86b3:f87b with SMTP id b9-20020a196449000000b0047f86b3f87bmr3397305lfj.644.1658697916849; Sun, 24 Jul 2022 14:25:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rohan Mahy Date: Sun, 24 Jul 2022 17:25:07 -0400 Message-ID: To: Jonathan Rosenberg Cc: Richard Shockey , Eric Rescorla , Jonathan Rosenberg , DISPATCH Content-Type: multipart/alternative; boundary="0000000000001fbd1a05e493b470" Archived-At: Subject: Re: [dispatch] New I-D - SPIN - on voice/video interop between app providers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2022 21:25:24 -0000 --0000000000001fbd1a05e493b470 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Not currently on dispatch agenda. I was planning to discuss it at the mim= i > bof on Monday. > > Get Outlook for iOS > ------------------------------ > *From:* dispatch on behalf of Richard Shockey > > *Sent:* Saturday, July 23, 2022 3:30:47 PM > *To:* Eric Rescorla ; Jonathan Rosenberg < > jdrosen@jdrosen.net> > *Cc:* DISPATCH > *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 involvi= ng > discovery =E2=80=A6 BTW I=E2=80=99ve been anxious for Broth= er Peterson to > chime in here. =E2=98=BA > > > > Its just I=E2=80=99m enough of an old curmudgeon to understand the very v= ery > significant headwinds you are going to run into. > > > > It is a great discussion BTW. > > > > =E2=80=94 > > Richard Shockey > > Shockey Consulting LLC > > Chairman of the Board SIP Forum > > www.shockey.us > > > www.sipforum.org > > > www.sipnoc.org > > (2022) > > richardshockey.us > > > Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 > > PSTN +1 703-593-2683 > > > > > > *From: *dispatch on behalf of Eric Rescorla < > ekr@rtfm.com> > *Date: *Saturday, July 23, 2022 at 11:30 AM > *To: *Jonathan Rosenberg > *Cc: *DISPATCH > *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 > 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 globall= y > 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 don= t > 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 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 > 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. > jdrosen@jdrosen.net > http://www.jdrosen.net > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ dispatch mailing list > dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch > > > ------------------------------ > > 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 a= nd > 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 > --0000000000001fbd1a05e493b470 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Re: discussing SPIN in MIMI

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

Thanks,<= /div>
-rohan

On Sat, Jul 23, 2022, 18:18 Jonathan Ros= enberg <jdrosen@five9.com> w= rote:
Not currently on dispatch agenda. I was planning to discus= s it at the mimi bof on Monday.=C2=A0
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 <jdrose= n@jdrosen.net>
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] New I-D - SPIN - on voice/video interop betw= een app providers
=C2=A0

=C2=A0

This is part of dispatch on Monday righ= t? Ok this should be fun and Jonathan I did find my Dynamicsoft cap.=

=C2=A0

Ok but I do want to make abundantly cle= ar that I have no objections for this work to go forward.=C2=A0 I do have s= ome experience in the issues involving discovery <cough cough> =E2=80= =A6 BTW I=E2=80=99ve been anxious for Brother Peterson to chime in here. =E2=98=BA

=C2=A0

Its just I=E2=80=99m enough of an old c= urmudgeon to understand the very very significant headwinds you are going t= o run into.

=C2=A0

It is a great discussion BTW.

=C2=A0

=E2=80=94=C2=A0

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Fo= rum

Skype-Linkedin-Facebook =E2= =80=93Twitter =C2=A0rshockey101

PSTN +1 703-593-2683<= /p>

=C2=A0

=C2=A0

From: dispatch <dispat= ch-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 betw= een app providers

=C2=A0

> 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<= br> > 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<= br> > to justify costs, etc? With SPIN, there is no new actor that needs to<= br> > be introduced. SPIN also doenst require the user's contact informa= tion
> 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 th= at
it isn't necessarily in their interest to do so, but the whole premise<= br> 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.=C2=A0 Fo= r
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.=C2=A0 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















=C2=A0

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

=C2=A0

You are correct that the current SPIN protocol design does require both = parties to be concurrently online. Since the originating party is the one i= nitiating communications, this means they'll be online anyway. So the i= ssue is that of the receiving party. Practically speaking, since this is targeted at mobil= e, the amount of time these devices are on and connected to the Internet is= very high. As such, I dont=C2=A0know that its worth optimizing for the rem= aining small percentage when they are not. If this didnt=C2=A0come with tradeoffs, it certainly is a limitation = worth addressing. But, I do worry about the tradeoff.

=C2=A0

And that is my second comment - that it requires some kind of central au= thority (the RS or "Richard SHockey" ;) in your proposal). This c= entral authority will have a full catalog of phone numbers for all users gl= obally 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 s= ervice, 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 sto= red in the cloud by Apple or Google; the real-time nature of the address re= solution 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 servic= e, they just need to add another preference stored on-device.

=C2=A0

Thx,

Jonathan R.

=C2=A0

=C2=A0

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
=C2=A0 failed is the force of regulation, specifically the DMA.

- Forward message routing is the most practical way
=C2=A0 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
=C2=A0 online. This is not unreasonable for voice calling but is
=C2=A0 undesirable for messaging.

- It makes the OS vendors certificate authorities, which (a) they may
=C2=A0 not to be (b) gives users no real choices in their trust decisions =C2=A0 (specifically, even if I am an Apple user, I need to trust Android!)=
=C2=A0 and (c) is incompatible with purely open source systems.

- It requires each individual relying party (caller) to make their own
=C2=A0 verification, which makes the kinds of transparency mechanisms we =C2=A0 ordinarily use to detect impersonation or misissuance/misrouting
=C2=A0 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,
=C2=A0 that application contacts the RS, demonstrates control of the releva= nt
=C2=A0 number via SMS answerback (i.e., the RS sends them a challenge via =C2=A0 SMS) [1]. The application is then able to store a record at the
=C2=A0 RS with the relevant contact information. If there are multiple
=C2=A0 applications, there would be multiple records.

- The RS issues Alice a credential (e.g., a certificate) which she can
=C2=A0 use to authenticate ownership of her number.

- When Alice wants to call Bob, she (or rather the calling/messaging
=C2=A0 application) looks up Bob's phone number in the registration
=C2=A0 service, retrieves the appropriate records, and is able to select =C2=A0 whichever one is appropriate to complete the communication.=C2=A0 Al= ice
=C2=A0 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
=C2=A0 require trusting the OS or OS vendor on the other end.
=C2=A0 It doesn't give the user choices about who to trust because
=C2=A0 they have to trust the RS (but see below).

- It doesn't require online user verification, and so is
=C2=A0 compatible with Certificate Transparency type systems,
=C2=A0 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.=C2=A0 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.=C2=A0 I do have some handw= avy
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<= br> 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:

=C2=A0 =C2=A0There are two ways in which the originating OS can obtain such= a
=C2=A0 =C2=A0certificate.=C2=A0 In one approach, the mobile OS would perfor= m SMS
=C2=A0 =C2=A0verification (again, invisibly, by absorbing the SMS it sends = to
=C2=A0 =C2=A0itself), and add an additional check of comparing it agaisnt t= he
=C2=A0 =C2=A0mobile numnber the user claimed they owned during provisioning= time
=C2=A0 =C2=A0of the device.=C2=A0 The mobile OS vendor would be a valid CA,= and then
=C2=A0 =C2=A0generte a certificate valid for that individual phone number.= =C2=A0 In an
=C2=A0 =C2=A0alternative model, the telco uses certificate delegation [RFC9= 060],
=C2=A0 =C2=A0and generates a certificate that is handed to the phone during= device
=C2=A0 =C2=A0provisioning.=C2=A0 The latter approach is more secure in some= ways (as it
=C2=A0 =C2=A0would no longer depend on SMS forward routability for authenti= cation
=C2=A0 =C2=A0of 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. =C2=A0I
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.


=C2=A0

On Tue, Jul 12, 2022 at 7:13 AM Jonathan Rosenberg <jdrosen@jdrosen.= net> wrote:

Hi fellow dispatchers -=C2=A0

=C2=A0

I wanted to call attention to the following draft submitted yesterday:

=C2=A0

Abstract:

This docume=
nt introduces a framework and a protocol for facilitating
=C2=A0=C2=A0 voice, video and messaging in=
teroperability between application
=C2=A0=C2=A0 providers.=C2=A0 This work is=
 motivated by the recent passage of
=C2=A0=C2=A0 regulation in the European Un=
ion - the Digital Markets Act (DMA) -
=C2=A0=C2=A0 which, amongst many other pro=
visions, requires that vendors of
=C2=A0=C2=A0 applications with a large num=
ber of users enable interoperability
=C2=A0=C2=A0 with applications made by oth=
er vendors.=C2=A0 While such interoperability
=C2=A0=C2=A0 is broadly present within the=
 public switched telephone network, it
=C2=A0=C2=A0 is not yet commonplace betwee=
n over-the-top applications, such as
=C2=A0=C2=A0 Facetime, WhatsApp, and Faceb=
ook Messenger.=C2=A0 This document
=C2=A0=C2=A0 specifically defines the Simp=
le Protocol for Inviting Numbers (SPIN)
=C2=A0=C2=A0 which is used to deliver invi=
tations to mobile phone numbers that can
=C2=A0=C2=A0 bootstrap subsequent communic=
ations over the Internet.

=C2=A0

Right now, we're looking to see if there is interest in working on t= his. Comments welcome.

=C2=A0

Thx,

Jonathan R.

=C2=A0

--

Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net
http://www.jdrosen.net

_______________________________________________
dispatch mailing list
d= ispatch@ietf.org
https://www.ietf.org/mail= man/listinfo/dispatch

_______________________________________________ dispatch mailing list dis= patch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch



CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y 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 conte= nts 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
d= ispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispa= tch
--0000000000001fbd1a05e493b470--