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

Eric Rescorla <> Sun, 24 July 2022 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10AC4C14F73E for <>; Sun, 24 Jul 2022 07:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.804
X-Spam-Status: No, score=-1.804 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, SPF_HELO_NONE=0.001, SPF_NONE=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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VgzdXmG-a9xr for <>; Sun, 24 Jul 2022 07:28:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (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 (Postfix) with ESMTPS id 6842EC14EB1E for <>; Sun, 24 Jul 2022 07:28:09 -0700 (PDT)
Received: by with SMTP id e69so6942162iof.5 for <>; Sun, 24 Jul 2022 07:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3dvx1M8JO3IwBTUuxTR+iAby5GtBE+Sj6skJaZwk3pE=; b=5owbHr5r/cFmTR9Whzgy5DXl93O/3zamGCTFNe6qMSJeD6o6IgXnDuYtsiz/apzpmb 2Ksj+sNkqxxP83Y+Y8QATBLMQWr+tFXkTZ3+dtPb4o5E5vCU1Ihsk3NUhYW4FBGMu0Al IDhkcEXdm85AFu2yZKYVgHVVhw3JwRzpbu4w1TpT1x93WOmue1T4NShqXbcika7y6HWq GQJ3xPadm9iDQpBy5Ylipbqnk8kUJdQeqCHkniKOVnKopQCyypmthA31rxfiiNrpo8fI DHQQa9RVMIAdX5k9Oc4wYuKmQY1GKym9mXMQ+peWYj98uyxjzNR4aCnSOfeTOnyer3An JeWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3dvx1M8JO3IwBTUuxTR+iAby5GtBE+Sj6skJaZwk3pE=; b=PkEYEpUX3EiYTEIr4w2072gpebRm0TifVpzj32UmoaKU9NnOrAASsv9ZIoqINDLbLx wWJM9Rg/j8BPrfZhN0Gn5Sbry4JIUHQUEL8cziWhxLkATJVgATZXU2hwfxDgdABay53p dSLipNYtctAw7YLcpCAq59sWE3hGQJiVxBKeEjRr6RMni+ymZD8ESiL9ra4KhsosQPnH dDPoa89PNuRIb8s0i7eE8r5VEACQKi5fkHryE1SSISC6zn9Bs0D7NjYHLSQWcJ9YDT3l 3dxBnK04zw+93Xqfve40iQySpTYssxr/V2dXzqU7+dUFG1WwkEUEqW0MZiJHzwjAsZHG IAqQ==
X-Gm-Message-State: AJIora95ZOvSbVJPIBzE+oaqM8utVDeSpFdv0lutuYpRBwyFsIaPNc4A O90g49/X2CC8YtR/bGQ4hFzXRxni/VIpif7mJxf/tA==
X-Google-Smtp-Source: AGRyM1uEbcZQKu7bjl10TkCpeTcUzAFIUmj4YRbwhipIoNABFl1AIyMzyh9YxhHbejeifuGEcdCWH1bFthPML7XTUs4=
X-Received: by 2002:a05:6602:2cce:b0:67c:17ec:f1c1 with SMTP id j14-20020a0566022cce00b0067c17ecf1c1mr2782292iow.96.1658672888487; Sun, 24 Jul 2022 07:28:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Sun, 24 Jul 2022 07:27:32 -0700
Message-ID: <>
To: "Peterson, Jon" <>
Cc: Richard Shockey <>, Jonathan Rosenberg <>, DISPATCH <>
Content-Type: multipart/alternative; boundary="0000000000005139da05e48de037"
Archived-At: <>
Subject: Re: [dispatch] New I-D - SPIN - on voice/video interop between app providers
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 14:28:13 -0000

On Sun, Jul 24, 2022 at 7:19 AM Peterson, Jon <>

> .
> 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. ☺
> I mean, this is an expression of two strategies for telephone number
> mapping we’ve been playing around with here forever: using some kind of
> proof-of-possession check that is based on actually invoking the routing
> system; and building some kind of centralized DB that is populated based on
> authoritative information about where numbers get routed. Certainly I agree
> that our experience with ENUM should make us cautious about centralized
> approaches. But ultimately, to Ekr’s point, iMessage and similar
> applications build walled-garden versions of such databases for their own
> application routing, and while they elicit some interest from regulators,
> they are not only suffered to exist, but are among the dominant
> communications systems in the world.
> Ekr’s notion that the applications themselves could conduct their own
> proof-of-possession tests and then share that data strikes me as something
> that could be incrementally added to the basic SPIN idea. Whether that data
> is being shared with a centralized DB, or bilaterally between peering
> devices, the data should have the same security properties and format, I
> imagine. We could abstract that out and explore a couple different
> architectures for getting it where it needs to go. Doing the
> proof-of-possession check in real time with forward routing has the benefit
> of guaranteeing freshness, but the cost of not working for offline devices.

Freshness can be both good and bad. For instance, if each pair of users
does a freshness check, it is possible for a powerful attacker to *just*
impersonate Alice and Bob to each other and to nobody else. This is much
more difficult with a public credentials system because you can add
something like CT/KT.

> My intuition is that there’s less opportunities for shenanigans with
> forward routing than with letting applications do the proof-of-possession
> and vouch for it themselves. But we’d need to drill a little deeper to see
> if that’s true.

I do want to clarify that I'm not suggesting that applications should vouch
for themselves. Rather, I am suggesting that there be a set of certificate
authorities which require applications to do proof of possession and then
issue them a credential which is publicly verifiable.


> Jon Peterson
> Neustar (a TransUnion company)
> _______________ dispatch mailing list
> <;!!N14HnBHF!_TYntjGyg5uNCLSI_-nlD2HuOE9K-OLN5D_G2jWixsWT84fvv6ZIsEO4aFCBWl0enMPpdcIFAoY9yafOU56I$>