Re: [dispatch] EXTERNAL:Re: New I-D - SPIN - on voice/video interop between app providers
Jonathan Rosenberg <jdrosen@jdrosen.net> Sun, 24 July 2022 13:16 UTC
Return-Path: <jdrosen2@gmail.com>
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 15FBDC14F746 for <dispatch@ietfa.amsl.com>; Sun, 24 Jul 2022 06:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.162
X-Spam-Level:
X-Spam-Status: No, score=-1.162 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 dE3PbUdTbxDw for <dispatch@ietfa.amsl.com>; Sun, 24 Jul 2022 06:16:41 -0700 (PDT)
Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) (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 EB77FC159481 for <dispatch@ietf.org>; Sun, 24 Jul 2022 06:16:39 -0700 (PDT)
Received: by mail-oi1-f169.google.com with SMTP id s204so10531752oif.5 for <dispatch@ietf.org>; Sun, 24 Jul 2022 06:16:39 -0700 (PDT)
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=Msn8E9SZVBsmFZjpS3KRzWcPE13xjwcAxal0t/Rl7oc=; b=J1FDN57uJsu6iRFRjAH6purkQycQi4LL8w/Fxdyo6vYM8x/u4Xg1UBq9t2cjsuHtfU wbpgCovRVXSmGlr4q3L/9zbv08U7qwkk9rxtj2z3czCAQoDX2V+stngZBbovcAuzh8EZ mV5plpRTFmoxCbQ9H/ArRxAFswifg6FwjRP8liJjNqI94iaBzthGME0TLb17ogbPs68N ayNggscrBIOfwT4/lBCRFmH7Cd1rloQ5h+MXq4T3f/E8sQ78gCv3GhFxrfQhUWXpLlUT IhKVspXtle31KlQLAucPUQmKSKHFrDCbo4CHiEI9EGiJVHlxUdrqNH/Bm+zMO0k4aMAl m1ww==
X-Gm-Message-State: AJIora/70izIzmDjlIpNafGpL/FflrzLF0+2rZFX/0fbY4KjQ2Vv/0ij gCGRyqKi64X4Gb+llf73B4Vjec1FvRQ=
X-Google-Smtp-Source: AGRyM1uCq6AnsAIjfbhO8u3HD0QCqUTFGzp0+ubFTCYumo59LKvMNNSEjm0dzNFSUrHJXdpoezX3uA==
X-Received: by 2002:a05:6808:1998:b0:33a:63d9:63c2 with SMTP id bj24-20020a056808199800b0033a63d963c2mr10594960oib.263.1658668598617; Sun, 24 Jul 2022 06:16:38 -0700 (PDT)
Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com. [209.85.167.179]) by smtp.gmail.com with ESMTPSA id g5-20020a056870c14500b0010c0d04eb00sm4995535oad.2.2022.07.24.06.16.37 for <dispatch@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Jul 2022 06:16:38 -0700 (PDT)
Received: by mail-oi1-f179.google.com with SMTP id bb16so10506386oib.11 for <dispatch@ietf.org>; Sun, 24 Jul 2022 06:16:37 -0700 (PDT)
X-Received: by 2002:a05:6808:3091:b0:33a:5f00:c43 with SMTP id bl17-20020a056808309100b0033a5f000c43mr3546784oib.35.1658668596827; Sun, 24 Jul 2022 06:16:36 -0700 (PDT)
MIME-Version: 1.0
References: <CA+23+fFReP7fi2XmhGoxmeUph8F7HcABsFwriXPzBvuBPBXLMg@mail.gmail.com> <CABcZeBME68imZqnOqc3hE7OOHWsTgRz+c1y9NKTT6vUHfSCLsQ@mail.gmail.com> <CA+23+fECuFKC9KPiJD0rugw4TWwDEsJr6MtGPVdLmsr4iopAjQ@mail.gmail.com> <CABcZeBNWqY3z4TCwpg6f0hTdDwc_rD+ReJ0M8Nyz_v5EUcUmow@mail.gmail.com> <BD6088D2-5C18-49F6-BB01-694102749E8B@shockey.us> <BL0PR06MB44991E3E2770B267EA8433E2FB939@BL0PR06MB4499.namprd06.prod.outlook.com> <LO0P123MB4858D4FDF92A3C95E44F3026A5929@LO0P123MB4858.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <LO0P123MB4858D4FDF92A3C95E44F3026A5929@LO0P123MB4858.GBRP123.PROD.OUTLOOK.COM>
From: Jonathan Rosenberg <jdrosen@jdrosen.net>
Date: Sun, 24 Jul 2022 09:17:23 -0400
X-Gmail-Original-Message-ID: <CA+23+fFL188C0tJ5L+df7D5obFrmdpQ6k8w9aFbR++TEsTaL3A@mail.gmail.com>
Message-ID: <CA+23+fFL188C0tJ5L+df7D5obFrmdpQ6k8w9aFbR++TEsTaL3A@mail.gmail.com>
To: Patrick Tarpey <Patrick.Tarpey=40ofcom.org.uk@dmarc.ietf.org>
Cc: Jonathan Rosenberg <jdrosen@five9.com>, Richard Shockey <richard@shockey.us>, Eric Rescorla <ekr@rtfm.com>, DISPATCH <dispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000839d5605e48ce02d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/dV-PWwLpNwnJwSu8YLxxzIGYPFU>
Subject: Re: [dispatch] EXTERNAL:Re: 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 <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jul 2022 13:16:46 -0000
https://trac.ietf.org/trac/ietf/meeting/wiki/114sidemeetings That said, if there is time and interest, I would be happy to discuss at dispatch as well. Thx, Jonathan R. On Sun, Jul 24, 2022 at 3:38 AM Patrick Tarpey <Patrick.Tarpey= 40ofcom.org.uk@dmarc.ietf.org> wrote: > Sorry Jonathan, I don't see a "mimi BOF" on the agenda. Can you clarify? > > Pat > ------------------------------ > *From:* dispatch <dispatch-bounces@ietf.org> on behalf of Jonathan > Rosenberg <jdrosen@five9.com> > *Sent:* 23 July 2022 23:18 > *To:* Richard Shockey <richard@shockey.us>; Eric Rescorla <ekr@rtfm.com>; > Jonathan Rosenberg <jdrosen@jdrosen.net> > *Cc:* DISPATCH <dispatch@ietf.org> > *Subject:* EXTERNAL:Re: [dispatch] New I-D - SPIN - on voice/video > interop between app providers > > > *CAUTION: This email originated outside your organisation. Do not click > links or open attachments unless you recognise the sender and know the > content is safe.* > > Not currently on dispatch agenda. I was planning to discuss it at the mimi > bof on Monday. > > Get Outlook for iOS > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fo0ukef&data=05%7C01%7Cpatrick.tarpey%40ofcom.org.uk%7Cd73def72761b43ea960108da6cf94724%7C0af648de310c40688ae4f9418bae24cc%7C0%7C1%7C637942115151293401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=RmV%2FC%2BxPjv7yr%2BnOg9GhyG2AIK73GV1zmTi1tsjYq2E%3D&reserved=0> > ------------------------------ > *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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F6uh-C5yVlksMp4LYTzsKYN%3Fdomain%3Dshockey.us&data=05%7C01%7Cpatrick.tarpey%40ofcom.org.uk%7Cd73def72761b43ea960108da6cf94724%7C0af648de310c40688ae4f9418bae24cc%7C0%7C1%7C637942115151293401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=6v0c8zCvBjOhBOdQGcsMX%2FJIIqyGN37pBMlkVmnCb9I%3D&reserved=0> > > www.sipforum.org > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FV4MECjR5vjtYGPQ1hxn_5N%3Fdomain%3Dsipforum.org&data=05%7C01%7Cpatrick.tarpey%40ofcom.org.uk%7Cd73def72761b43ea960108da6cf94724%7C0af648de310c40688ae4f9418bae24cc%7C0%7C1%7C637942115151293401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=vUIMs%2BPXHEE9TKtl70GquNXfi6i%2BIfL3b55a6GB2H1I%3D&reserved=0> > > www.sipnoc.org > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FEiuSCkRBwktkX1z3F0Wymz%3Fdomain%3Dsipnoc.org&data=05%7C01%7Cpatrick.tarpey%40ofcom.org.uk%7Cd73def72761b43ea960108da6cf94724%7C0af648de310c40688ae4f9418bae24cc%7C0%7C1%7C637942115151293401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=%2BjtOri8sBllUlD5svHkvKvdQWdmYtCdcb4fiAQv4AzY%3D&reserved=0> > (2022) > > richard<at>shockey.us > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FRsxEC82WonSXPLp8UM6_rg%3Fdomain%3Dshockey.us&data=05%7C01%7Cpatrick.tarpey%40ofcom.org.uk%7Cd73def72761b43ea960108da6cf94724%7C0af648de310c40688ae4f9418bae24cc%7C0%7C1%7C637942115151293401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=Uj6MRmRLSo3%2Fp4kttJfi8nu4xkmX4S6oVqRAM6Zd%2BnI%3D&reserved=0> > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FzrWFC9rGpoSzN9EVCPeIjN%3Fdomain%3Dietf.org&data=05%7C01%7Cpatrick.tarpey%40ofcom.org.uk%7Cd73def72761b43ea960108da6cf94724%7C0af648de310c40688ae4f9418bae24cc%7C0%7C1%7C637942115151293401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=ssQZhN98y8o5Gv5w8g%2F6NF55CPn%2BJGHKNmvocr2ynxk%3D&reserved=0> > > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FVbm-C0RE2NtkgZw0F3V7Le%3Fdomain%3Djdrosen.net%2F&data=05%7C01%7Cpatrick.tarpey%40ofcom.org.uk%7Cd73def72761b43ea960108da6cf94724%7C0af648de310c40688ae4f9418bae24cc%7C0%7C1%7C637942115151762052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=CBfoQjYd9%2FSpbHuQBXe7H4yQ5PNcv6DVC1RGRRa9WIY%3D&reserved=0> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FJ12sCgJ8xOfqwpZ5cZUHyI%3Fdomain%3Dietf.org&data=05%7C01%7Cpatrick.tarpey%40ofcom.org.uk%7Cd73def72761b43ea960108da6cf94724%7C0af648de310c40688ae4f9418bae24cc%7C0%7C1%7C637942115151762052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=StwHEFfMVvqPpOJa1ievDccJigeILC96X9dm%2BlRy0JM%3D&reserved=0> > > _______________________________________________ dispatch mailing list > dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FJ12sCgJ8xOfqwpZ5cZUHyI%3Fdomain%3Dietf.org&data=05%7C01%7Cpatrick.tarpey%40ofcom.org.uk%7Cd73def72761b43ea960108da6cf94724%7C0af648de310c40688ae4f9418bae24cc%7C0%7C1%7C637942115151762052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=StwHEFfMVvqPpOJa1ievDccJigeILC96X9dm%2BlRy0JM%3D&reserved=0> > > ------------------------------ > > 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. > > ------------------------------ > > > ****************************************************************************************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the use > of the addressee only. > > If you have received this email in error please notify the originator of > the message and delete it from your system. > > This email has been scanned for viruses. However, you open any attachments > at your own risk. > > Any views expressed in this message are those of the individual sender and > do not represent the views or opinions of Ofcom unless expressly stated > otherwise. > > ****************************************************************************************************************** > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >
- [dispatch] New I-D - SPIN - on voice/video intero… Jonathan Rosenberg
- Re: [dispatch] New I-D - SPIN - on voice/video in… Brian Rosen
- Re: [dispatch] New I-D - SPIN - on voice/video in… Paul Kyzivat
- Re: [dispatch] New I-D - SPIN - on voice/video in… Stephen Farrell
- Re: [dispatch] New I-D - SPIN - on voice/video in… Richard Barnes
- Re: [dispatch] New I-D - SPIN - on voice/video in… Richard Shockey
- Re: [dispatch] New I-D - SPIN - on voice/video in… worley
- Re: [dispatch] New I-D - SPIN - on voice/video in… Jonathan Rosenberg
- Re: [dispatch] New I-D - SPIN - on voice/video in… Jonathan Rosenberg
- Re: [dispatch] New I-D - SPIN - on voice/video in… Jonathan Rosenberg
- Re: [dispatch] New I-D - SPIN - on voice/video in… Jonathan Rosenberg
- Re: [dispatch] New I-D - SPIN - on voice/video in… Stephen Farrell
- Re: [dispatch] New I-D - SPIN - on voice/video in… John Levine
- Re: [dispatch] New I-D - SPIN - on voice/video in… Alissa Cooper
- Re: [dispatch] New I-D - SPIN - on voice/video in… Brian Rosen
- Re: [dispatch] New I-D - SPIN - on voice/video in… Stephen Farrell
- Re: [dispatch] New I-D - SPIN - on voice/video in… Stephen Farrell
- Re: [dispatch] New I-D - SPIN - on voice/video in… Richard Shockey
- Re: [dispatch] New I-D - SPIN - on voice/video in… Brian Rosen
- Re: [dispatch] New I-D - SPIN - on voice/video in… Eric Rescorla
- Re: [dispatch] New I-D - SPIN - on voice/video in… Eric Rescorla
- Re: [dispatch] New I-D - SPIN - on voice/video in… Jonathan Rosenberg
- Re: [dispatch] New I-D - SPIN - on voice/video in… Eric Rescorla
- Re: [dispatch] New I-D - SPIN - on voice/video in… Richard Shockey
- Re: [dispatch] New I-D - SPIN - on voice/video in… Jonathan Rosenberg
- Re: [dispatch] New I-D - SPIN - on voice/video in… Richard Shockey
- Re: [dispatch] EXTERNAL:Re: New I-D - SPIN - on v… Patrick Tarpey
- Re: [dispatch] EXTERNAL:Re: New I-D - SPIN - on v… Marc Petit-Huguenin
- Re: [dispatch] EXTERNAL:Re: New I-D - SPIN - on v… Jonathan Rosenberg
- Re: [dispatch] New I-D - SPIN - on voice/video in… Peterson, Jon
- Re: [dispatch] New I-D - SPIN - on voice/video in… Eric Rescorla
- Re: [dispatch] New I-D - SPIN - on voice/video in… Peterson, Jon
- Re: [dispatch] New I-D - SPIN - on voice/video in… Eric Rescorla
- Re: [dispatch] New I-D - SPIN - on voice/video in… Rohan Mahy
- Re: [dispatch] New I-D - SPIN - on voice/video in… Eric Rescorla