Re: [dispatch] New I-D - SPIN - on voice/video interop between app providers
Richard Shockey <richard@shockey.us> Fri, 22 July 2022 17:09 UTC
Return-Path: <richard@shockey.us>
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 9A91DC157B49 for <dispatch@ietfa.amsl.com>; Fri, 22 Jul 2022 10:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 (768-bit key) header.d=shockey.us
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 lwPprHshknJQ for <dispatch@ietfa.amsl.com>; Fri, 22 Jul 2022 10:08:58 -0700 (PDT)
Received: from outbound-ss-820.bluehost.com (outbound-ss-820.bluehost.com [69.89.24.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7898DC15791C for <dispatch@ietf.org>; Fri, 22 Jul 2022 10:08:58 -0700 (PDT)
Received: from cmgw10.mail.unifiedlayer.com (unknown [10.0.90.125]) by progateway2.mail.pro1.eigbox.com (Postfix) with ESMTP id BC7ED10049CDD for <dispatch@ietf.org>; Fri, 22 Jul 2022 17:08:45 +0000 (UTC)
Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with ESMTP id Ew8roZQR6CokGEw8roIkJQ; Fri, 22 Jul 2022 17:08:45 +0000
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.4 cv=d+QwdTvE c=1 sm=1 tr=0 ts=62dad99d a=KXpOjjFwo8kCkgxs2x2AJQ==:117 a=KXpOjjFwo8kCkgxs2x2AJQ==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=MKtGQD3n3ToA:10:nop_fastflux_from_domain_1 a=1oJP67jkp3AA:10:nop_fastflux_mid_domain_1 a=RgO8CyIxsXoA:10:nop_rcvd_month_year a=qMgonR0qfJAA:10:endurance_base64_authed_username_1 a=jqBRFv0mrdUA:10:from_fastflux_domain1 a=PeFO9FbFhS32YxYntvkA:9 a=1Z4slDfhAAAA:8 a=48vgC7mUAAAA:8 a=5IsXbjgYAAAA:8 a=1mHy1K9dAAAA:8 a=-nBQ8TuwQS4jDS84qqgA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=GywtkVPW3aO-P5mV:21 a=gKO2Hq4RSVkA:10:nop_mshtml a=UiCQ7L4-1S4A:10:nop_mshtml_css_classes a=hTZeC7Yk6K0A:10:nop_msword_html a=frz4AuCg-hUA:10:nop_css_in_html a=lqcHg5cX4UMA:10:nop_bhvr_url2_hostname_empty a=JwPPQSbBbIoe0w3YtMrH:22 a=w1C3t2QeGrPiZgrLijVG:22 a=RR2nPHISKLg-FD_FhCoU:22 a=YZZQrBN7PEZ4rQoNGmLO:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To: From:Subject:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=vH4yO409oenJSI5EABafM7KOel58hgjbyxyy9vnpoRo=; b=LMKGTeBxL67pCboKRCEGxX0i3a yPkfR5KkKY7pDAfuXdZkVbm9Jd1iG4pAGWs4rYXsU4HN38FIufmWDtb+nHfx7ytBPOc2yPPzjVm4v UJoyUSAMBcT8pXFlim0lD43LN;
Received: from pool-100-36-48-45.washdc.fios.verizon.net ([100.36.48.45]:51407 helo=[192.168.1.214]) by box5527.bluehost.com with esmtpa (Exim 4.95) (envelope-from <richard@shockey.us>) id 1oEw8q-001A1T-PY for dispatch@ietf.org; Fri, 22 Jul 2022 11:08:44 -0600
User-Agent: Microsoft-MacOutlook/16.63.22070801
Date: Fri, 22 Jul 2022 13:08:44 -0400
From: Richard Shockey <richard@shockey.us>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Message-ID: <347F51A3-E309-47CD-ABF0-4DDC3D9AABD3@shockey.us>
Thread-Topic: [dispatch] New I-D - SPIN - on voice/video interop between app providers
References: <CA+23+fFReP7fi2XmhGoxmeUph8F7HcABsFwriXPzBvuBPBXLMg@mail.gmail.com>
In-Reply-To: <CABcZeBME68imZqnOqc3hE7OOHWsTgRz+c1y9NKTT6vUHfSCLsQ@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3741340124_3006427295"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box5527.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - shockey.us
X-BWhitelist: no
X-Source-IP: 100.36.48.45
X-Source-L: No
X-Exim-ID: 1oEw8q-001A1T-PY
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-36-48-45.washdc.fios.verizon.net ([192.168.1.214]) [100.36.48.45]:51407
X-Source-Auth: richard@shockey.us
X-Email-Count: 2
X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20=
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/jvv4DW3TFtdmQx_AivRglnjvhtg>
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 <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: Fri, 22 Jul 2022 17:09:02 -0000
<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 <dispatch-bounces@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com> Date: Friday, July 22, 2022 at 11:21 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 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 <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 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
- [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