[stir] Re: [art] Re: For those of you who follow this kind of stuff.

Chris Wendt <chris-ietf@chriswendt.net> Wed, 08 October 2025 06:44 UTC

Return-Path: <chris-ietf@chriswendt.net>
X-Original-To: stir@mail2.ietf.org
Delivered-To: stir@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6A5236F2C9C4 for <stir@mail2.ietf.org>; Tue, 7 Oct 2025 23:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level:
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt.net
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKv3dHWSpy_h for <stir@mail2.ietf.org>; Tue, 7 Oct 2025 23:44:04 -0700 (PDT)
Received: from quail.birch.relay.mailchannels.net (quail.birch.relay.mailchannels.net [23.83.209.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 764256F2C9C1 for <stir@ietf.org>; Tue, 7 Oct 2025 23:44:04 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|chris-ietf@chriswendt.net
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A7EFE8617E2; Wed, 08 Oct 2025 06:43:57 +0000 (UTC)
Received: from pdx1-sub0-mail-a236.dreamhost.com (100-114-109-65.trex-nlb.outbound.svc.cluster.local [100.114.109.65]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 65E4E8619D4; Wed, 08 Oct 2025 06:43:52 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1759905832; a=rsa-sha256; cv=none; b=1nA32VfZuYQZTVJMoZlfdOTqqhENTigLuP8Rrp0PleVOh6KsUWhsOEGgpqF9jumSAepO2w q/MjrpvJk+Q0GUBf8YCX7mjIfpy1B18bLRPozHETrKxb1NQkIwwpO4bKMney4om6LDN4jw gCdAaOS1OQdOVzWCOS9Nul9GE28LMjW+s4yU81IBussm4V82n/a92sZx/w+YHSzYsdxHQM LuuFoWZYIoYN8AQKespyBU0DjiNGTYtzoUQHlkMgvL2eyGGXdWa1Vorntx4ALi1n/V9lgZ X+lfvIdy4Wygw7LW1nl4vS15gJf6TmJU4rrnIMVhiB2Yb2UqpDaZ2bx38i4DDQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1759905832; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jIaGg27G+uY/B0mGFfXK4o6TLsLSEzguWmxV7Gm1x7s=; b=6GZICtst/cwFviBFTM+EB4dIyrgvopD3C97vRJS0vwL1uXlitYDmpKRTsaTgOUGEs9rcPB bOeSycW6zGz5MXxRKtfrR4Kv/YLVIwGa6jF1LZ/fqNh+oF0vUYpw52aXRxEHAmFm2flqsN gXe7qCp4TsyAVLzU2GK7aH88dWNsYKOCG1TPhWMbPB1D0C6dDrgartz3piwjKeiFcU8Pup 0R+tlYFJIwFyB8CTnjd9tZVtRZL/KTxQTKYMfU56p1KNtuuSOplNV/es/EL0azVx/AWDhc lVkB6kikajUdFHqj930EIE3MWkeO3ATy3+ut8SJbqZje4lNs59RMt0GpzH0XxQ==
ARC-Authentication-Results: i=1; rspamd-668c7f7ff9-6xkmk; auth=pass smtp.auth=dreamhost smtp.mailfrom=chris-ietf@chriswendt.net
X-Sender-Id: dreamhost|x-authsender|chris-ietf@chriswendt.net
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|chris-ietf@chriswendt.net
X-MailChannels-Auth-Id: dreamhost
X-Macabre-Befitting: 23ae729d0d90b0c1_1759905837512_357605160
X-MC-Loop-Signature: 1759905837512:1875328212
X-MC-Ingress-Time: 1759905837512
Received: from pdx1-sub0-mail-a236.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.114.109.65 (trex/7.1.3); Wed, 08 Oct 2025 06:43:57 +0000
Received: from smtpclient.apple (unknown [45.88.222.58]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: chris-ietf@chriswendt.net) by pdx1-sub0-mail-a236.dreamhost.com (Postfix) with ESMTPSA id 4chNkv6wsJz33; Tue, 7 Oct 2025 23:43:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt.net; s=dreamhost; t=1759905832; bh=jIaGg27G+uY/B0mGFfXK4o6TLsLSEzguWmxV7Gm1x7s=; h=Content-Type:Content-Transfer-Encoding:From:Subject:Date:Cc:To; b=BumW1BsGWywk4xjbbLAYZf0oQT2P9L0JjtI+22bdsIN+kqotjBN/MBgW9G4TZQC/u F1fZXAKLkFwxo/UdiNu/dvPzJVmagsdZzl/GMI2BG+mXUZi9BOY4QiZDC16GtL/rQ9 xBBbzQM4xg5cdSDG8h1nL2Vw1wIXDyZdP70CO87T7xJoYeIRJ4HUmuTJC6yZIjlBPZ 9ygjRX21SlpSgJeQQkjuTYW8s0bbkaK9Cf6qCe2//EzAY6hRxcCcPzpB3aV8jj/TQq kv0sdJoX2/tJ2o6mv1TlkQ1mmdG1YBEcLrC8ky8to2XndncQJZOnYBSleu8vKQ3lsP +711ufnLgyahQ==
Content-Type: multipart/alternative; boundary="Apple-Mail-2895ECD2-26CB-494E-B9F7-12CC661B8190"
Content-Transfer-Encoding: 7bit
From: Chris Wendt <chris-ietf@chriswendt.net>
Mime-Version: 1.0 (1.0)
Date: Wed, 08 Oct 2025 01:43:30 -0500
Message-Id: <0687B06D-E2A6-4461-8486-91D6DF64CF85@chriswendt.net>
References: <CAD5OKxsCDRA_TWfqBNQjpoACntFfqOS98cVHL8aWNR8YKvjR+Q@mail.gmail.com>
In-Reply-To: <CAD5OKxsCDRA_TWfqBNQjpoACntFfqOS98cVHL8aWNR8YKvjR+Q@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: iPad Mail (23A355)
Message-ID-Hash: GPWT3IKULM7FFM27X4VE7I7A4FIDPFGQ
X-Message-ID-Hash: GPWT3IKULM7FFM27X4VE7I7A4FIDPFGQ
X-MailFrom: chris-ietf@chriswendt.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-stir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Brett Nemeroff <Brett.Nemeroff@numeracle.com>, Richard Shockey <richard@shockey.us>, IETF STIR Mail List <stir@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [stir] Re: [art] Re: For those of you who follow this kind of stuff.
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/LpbS1UxSKWk33gVwCyDgeajMUsg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Owner: <mailto:stir-owner@ietf.org>
List-Post: <mailto:stir@ietf.org>
List-Subscribe: <mailto:stir-join@ietf.org>
List-Unsubscribe: <mailto:stir-leave@ietf.org>

Removing art mailing list and only keeping stir mailing list on cc.  Let’s keep this on stir list only to avoid spamming art participants.

RCD, I’m a fan, i guess the party is really kicking in to gear.

-Chris

On Oct 8, 2025, at 12:19 AM, Roman Shpount <roman@telurix.com> wrote:


Brett,

FCC was very deliberate in not specifying the KYC requirements. This being said, all carriers introducing traffic to the US phone network should have a KYC policy described in the RMD database. Carriers that did not provide an adequate policy have been removed from the RMD database and are no longer permitted to originate traffic. Additionally, if, as a carrier, I can set the A-level attestation for the call based on my KYC policy, I should be able to specify the Rich Call Data accordingly, especially if this is required when A-level attestation is provided.

I have a strong feeling that certain providers care more about creating new sources of revenue for themselves through regulatory arbitrage than about creating a healthy infrastructure to prevent robocalls. A glaring example is iConnectiv providing SPC tokens, but not the signing certificates, which artificially creates business for specialized certificate authorities. Ironically, this business opportunity is so small and labour-intensive that no one actually wants to do it, trying to shepherd carriers towards the hosted signing solution.

To summarize, if, as a carrier, I am entrusted with an SPC token, I should be trusted to provide the Rich Call Data. If I am not trusted to provide Rich Call Data into the network, I should not be introducing any traffic into it. If the FCC mandates Rich Call Data, it should mandate that carriers accept it without creating walled gardens, with each carrier charging a fee to actually accept the data.

Finally, if we intend to mandate the transmission of personally identifiable data with every call, we need to update SIP with a scalable and secure transport protocol. Most current carrier SIP implementations still use UDP. SIP-over-TLS suffers from head-of-the-line congestion issues. SIP is in dire need of a secure datagram-based protocol, such as QUIC. I am surprised that no one from the STIR group brought this to the SIPCore, so that a more scalable and secure protocol capable of carrying Rich Call Data could be standardized.

Best Regards,
_____________
Roman Shpount


On Tue, Oct 7, 2025 at 8:42 PM Brett Nemeroff <Brett.Nemeroff@numeracle.com> wrote:
Hello Roman,

In my opinion, US Carriers are unlikely to accept vanilla RCD data because of the lack of defined KYC.  RCD is a very good vehicle for delivering the RCD, but it depends upon implicit trust of the originating service provider. “Vanilla” RCD offered like this to terminating service providers gives no assurance to the terminating service provider that the originator performed any specific KYC.

CTIA’s BCID is based on RCD but details an ecosystem with specific KYC requirements. Participating in this ecosystem will allow for the delivery and native presentation of RCD. 

It’s worth noting that without a defined ecosystem for RCD such as BCID, RCD provides little (trust)  benefit over traditional CNAM other than the fingerprints of the originating service provider for enforcement purposes. 

-Brett



Brett Nemeroff
VP of Engineering - Voice
Brett.Nemeroff@numeracle.com | 1-512-203-3884

https://www.numeracle.com/" target="_blank" rel="nofollow">

<C2_signature_logo_ccb8cfe8-4171-4801-978c-931782d067de.png>

Empowering Calls with
https://www.numeracle.com/insights/entity-identity-management-to-empower-your-calls" target="_blank" rel="nofollow">Identity Management 


CONFIDENTIAL

From: Roman Shpount <roman@telurix.com>
Date: Tuesday, October 7, 2025 at 7:24 PM
To: Richard Shockey <richard@shockey.us>
Cc: IETF STIR Mail List <stir@ietf.org>, art@ietf.org <art@ietf.org>
Subject: [stir] Re: [art] Re: For those of you who follow this kind of stuff.

You don't often get email from roman@telurix.com. https://aka.ms/LearnAboutSenderIdentification" target="_blank" rel="nofollow"> Learn why this is important
In my day job, I see a lot of robocalls coming through the LEC local switches as TDM, as local re-origination with spoofed ANI. 

I would also love to sign Rich Call Data with my SPC token and not have wireless carriers discard this data. If I provide the information about my customer, I am unsure why I need to pay someone else to sign this information.
_____________
Roman Shpount


On Tue, Oct 7, 2025 at 8:11 PM Richard Shockey <richard@shockey.us> wrote:

 

It wont . You mean the legacy TDM/SS7 crap…this is the beginning of mandating all SIP in the US realtime US voice network as the British have done.

 

I would not want to own a Tandem Access network.

 

The US industry is pretty clear on this.  You only need to read the FCC 17-97 docket at the FCC ECFS website to understand where the players actually are.

 

This again is my day job.

 

 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

http://www.shockey.us/" target="_blank" rel="nofollow">www.shockey.us

http://www.sipforum.org/" target="_blank" rel="nofollow">www.sipforum.org

richard<at>http://shockey.us/" target="_blank" rel="nofollow">shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

 

 

From: Roman Shpount <roman@telurix.com>
Date: Tuesday, October 7, 2025 at 7:37 PM
To: Richard Shockey <richard@shockey.us>
Cc: IETF STIR Mail List <stir@ietf.org>, <art@ietf.org>
Subject: [art] Re: [stir] For those of you who follow this kind of stuff.

 

How would this work with PSTN links?

_____________
Roman Shpount

 

 

On Tue, Oct 7, 2025 at 6:59PM Richard Shockey <richard@shockey.us> wrote:


The United States government is going to mandate Rich Call Data in the network.

https://docs.fcc.gov/public/attachments/DOC-415059A1.pdf" target="_blank" rel="nofollow">https://docs.fcc.gov/public/attachments/DOC-415059A1.pdf


Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
http://www.shockey.us/" target="_blank" rel="nofollow">www.shockey.us <http://www.shockey.us/" target="_blank" rel="nofollow">http://www.shockey.us>
http://www.sipforum.org/" target="_blank" rel="nofollow">www.sipforum.org

richard<at>http://shockey.us/" target="_blank" rel="nofollow">shockey.us
Skype-Linkedin-Facebook –Twitter rshockey101
PSTN +1 703-593-2683






_______________________________________________
stir mailing list -- stir@ietf.org
To unsubscribe send an email to stir-leave@ietf.org

_______________________________________________ art mailing list -- art@ietf.org To unsubscribe send an email to art-leave@ietf.org

_______________________________________________
art mailing list -- art@ietf.org
To unsubscribe send an email to art-leave@ietf.org