From nobody Mon Apr 4 11:24:54 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFEF3A10DF for ; Mon, 4 Apr 2022 11:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.687 X-Spam-Level: X-Spam-Status: No, score=-0.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MAY_BE_FORGED=1, RCVD_IN_DNSWL_BLOCKED=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aphxYzDjPoiv for ; Mon, 4 Apr 2022 11:24:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56373A10E1 for ; Mon, 4 Apr 2022 11:24:29 -0700 (PDT) Received: from smtpclient.apple (mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged)) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 234IOG5A046353 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Apr 2022 13:24:17 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1649096658; bh=8j1E32XKNylfn2W/7g8U9IaXstp3oHhf3Xnga/vo4S0=; h=From:Subject:Date:Cc:To; b=JWORME5kjajE955P1YZLCd/0H9KZizj9MuSGWYAWEWZQN1YhpJ4Vz7VD6GovQThFx 9EsLTTQt4ltDamV031V0FbqgD7BJ/tcy0OUH/asgmah7p4iZrkDAife7PN1EeOVzyD JRwrHup35cHq9mVqlfD/2sOqYHXRrEaAhw3i5cEM= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged) claimed to be smtpclient.apple From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_41C6509E-47BF-4E51-B0FE-01EA426E1542" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Message-Id: Date: Mon, 4 Apr 2022 13:24:10 -0500 Cc: Robert Sparks , Russ Housley , Jon Peterson , Chris Wendt To: IETF STIR Mail List X-Mailer: Apple Mail (2.3696.80.82.1.1) Archived-At: Subject: [stir] Doodle: Potential April Virtual Interim Meeting X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 18:24:45 -0000 --Apple-Mail=_41C6509E-47BF-4E51-B0FE-01EA426E1542 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Everyone, Since we did not have a meeting in Vienna, we=E2=80=99d like to arrange = a virtual interim. We are attempting to target the third or fourth week = of April. We are currently planning a 2 hour meeting, but that could = change as we figure out the agenda. Please indicate your availability in the linked doodle poll, preferably = by the end of this week. We=E2=80=99ve picked US friendly time slots, = since I think most of our participants are from the US=E2=80=94but if = these times cause pain for anyone who would like to participant, please = let us know ASAP and we will look at some other slots. https://doodle.com/meeting/participate/id/mbkJAq5a = Thanks! Ben (for the STIR chairs)= --Apple-Mail=_41C6509E-47BF-4E51-B0FE-01EA426E1542 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Everyone,

Since we = did not have a meeting in Vienna, we=E2=80=99d like to arrange a virtual = interim. We are attempting to target the third or fourth week of April. = We are currently planning a 2 hour meeting, but that could change as we = figure out the agenda.

Please indicate your availability in the linked doodle poll, = preferably by the end of this week. We=E2=80=99ve picked US friendly = time slots, since I think most of our participants are from the US=E2=80=94= but if these times cause pain for anyone who would like to participant, = please let us know ASAP and we will look at some other slots.

https://doodle.com/meeting/participate/id/mbkJAq5a

Thanks!

Ben (for the STIR = chairs)
= --Apple-Mail=_41C6509E-47BF-4E51-B0FE-01EA426E1542-- From nobody Mon Apr 4 11:53:58 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743823A1216 for ; Mon, 4 Apr 2022 11:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.186, NICE_REPLY_A=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4LdiukCJOgo for ; Mon, 4 Apr 2022 11:53:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064D33A1215 for ; Mon, 4 Apr 2022 11:53:51 -0700 (PDT) Received: from [192.168.1.114] ([47.186.48.51]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 234Irlur050351 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Apr 2022 13:53:47 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1649098428; bh=+AOFpzG8ZMj4zc5y5CoREa66C5gyuWHzSyfelI+PGt0=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=h2HnxoojPI67FMPoWo91uiK06PNTGRoqi7ldBuizkuR4tkAtZ/lHbYwu9W2/fUSDl s3Ewn+P9Dc3F5BH4n8L8kBjqFG/XNAp5cihKlEXhKqOjNIHNOS/tOgiJkJbQIjrrZ/ W+vy4YbyBjU+wBOe03Ska3+SjeNgjHjcJVaRfzd4= X-Authentication-Warning: raven.nostrum.com: Host [47.186.48.51] claimed to be [192.168.1.114] Message-ID: Date: Mon, 4 Apr 2022 13:53:42 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Ben Campbell , IETF STIR Mail List Cc: Russ Housley , Jon Peterson , Chris Wendt References: From: Robert Sparks In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [stir] Doodle: Potential April Virtual Interim Meeting X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 18:53:57 -0000 Everyone please note that doodle's interface may have changed since you touched it last. Be careful to see, and use, the +10 more options in the week-scroller at the top of the page so that you pick options for both weeks. RjS On 4/4/22 1:24 PM, Ben Campbell wrote: > Hi Everyone, > > Since we did not have a meeting in Vienna, we’d like to arrange a > virtual interim. We are attempting to target the third or fourth week > of April. We are currently planning a 2 hour meeting, but that could > change as we figure out the agenda. > > Please indicate your availability in the linked doodle poll, > preferably by the end of this week. We’ve picked US friendly time > slots, since I think most of our participants are from the US—but if > these times cause pain for anyone who would like to participant, > please let us know ASAP and we will look at some other slots. > > https://doodle.com/meeting/participate/id/mbkJAq5a > > Thanks! > > Ben (for the STIR chairs) From nobody Mon Apr 11 08:29:39 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD493A1012 for ; Mon, 11 Apr 2022 08:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.186, MAY_BE_FORGED=1, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWVkoI6-b310 for ; Mon, 11 Apr 2022 08:29:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADB93A100F for ; Mon, 11 Apr 2022 08:29:33 -0700 (PDT) Received: from smtpclient.apple (mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged)) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 23BFTKBl046732 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Apr 2022 10:29:21 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1649690962; bh=MaFww17Cda9PAAyhhUlT90cyI43NgEQ4/mCqerjt4gk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=iDuj0YHT/wQmBcw3ayTf0jb79GNbZRPqrGtvZOi+sOvBWn4aH06+G2l4zAML8B419 c/6qB8N7gjogHxpzL5nxg0NPV/yOfvfiVNbCGcqkDF8eEXvyydt/zQ3+1T0g9alsPj 8TrGJa4/y4dQVuztl+rD5O0G6N8QgCDNEgDgAaFc= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged) claimed to be smtpclient.apple From: Ben Campbell Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3FEB4247-095E-41DE-A3EB-74B07B3E9F93" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Date: Mon, 11 Apr 2022 10:29:15 -0500 In-Reply-To: Cc: Chris Wendt , Russ Housley , Jon Peterson , Robert Sparks To: IETF STIR Mail List References: X-Mailer: Apple Mail (2.3696.80.82.1.1) Archived-At: Subject: Re: [stir] Doodle: Potential April Virtual Interim Meeting X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 15:29:38 -0000 --Apple-Mail=_3FEB4247-095E-41DE-A3EB-74B07B3E9F93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, It looks like we have a doodle quorum. We will hold a 2 hour interim = meeting at 10:00 EST (I think that=E2=80=99s 15:00 UTC) on 22 April. = Watch for an =E2=80=9Cofficial=E2=80=9D announcement shortly. Thanks! Ben. > On Apr 4, 2022, at 1:24 PM, Ben Campbell wrote: >=20 > Hi Everyone, >=20 > Since we did not have a meeting in Vienna, we=E2=80=99d like to = arrange a virtual interim. We are attempting to target the third or = fourth week of April. We are currently planning a 2 hour meeting, but = that could change as we figure out the agenda. >=20 > Please indicate your availability in the linked doodle poll, = preferably by the end of this week. We=E2=80=99ve picked US friendly = time slots, since I think most of our participants are from the US=E2=80=94= but if these times cause pain for anyone who would like to participant, = please let us know ASAP and we will look at some other slots. >=20 > https://doodle.com/meeting/participate/id/mbkJAq5a = >=20 > Thanks! >=20 > Ben (for the STIR chairs) > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_3FEB4247-095E-41DE-A3EB-74B07B3E9F93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

It = looks like we have a doodle quorum. We will hold a 2 hour interim = meeting at 10:00 EST (I think that=E2=80=99s 15:00 UTC) on 22 April. = Watch for an =E2=80=9Cofficial=E2=80=9D announcement shortly.

Thanks!

Ben.

On = Apr 4, 2022, at 1:24 PM, Ben Campbell <ben@nostrum.com> = wrote:

Hi Everyone,

Since we did not have a = meeting in Vienna, we=E2=80=99d like to arrange a virtual interim. We = are attempting to target the third or fourth week of April. We are = currently planning a 2 hour meeting, but that could change as we figure = out the agenda.

Please indicate your availability in the linked doodle poll, = preferably by the end of this week. We=E2=80=99ve picked US friendly = time slots, since I think most of our participants are from the US=E2=80=94= but if these times cause pain for anyone who would like to participant, = please let us know ASAP and we will look at some other slots.

https://doodle.com/meeting/participate/id/mbkJAq5a

Thanks!

Ben (for the STIR = chairs)
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_3FEB4247-095E-41DE-A3EB-74B07B3E9F93-- From nobody Mon Apr 11 12:27:59 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43DC3A0884 for ; Mon, 11 Apr 2022 12:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.186, MAY_BE_FORGED=1, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaMJ9K-odJU0 for ; Mon, 11 Apr 2022 12:27:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124333A0859 for ; Mon, 11 Apr 2022 12:27:52 -0700 (PDT) Received: from smtpclient.apple (mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged)) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 23BJRcUT027680 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Apr 2022 14:27:40 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1649705267; bh=tYiwk5+wmo0u/EKgcNgmR+64GBxIsHUI4ceJYGgwioU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=tL30llDKfOvkQ2B2Lpkh5zFVJmp4f1WegqpWnhz5Kfji8nZvN0SZzwdYbI1Og/sSw iDTYsNMHQHgXI6UPd4DOnjv84YmWTjFJRK9JlJNnO373xYmjFVsLfWpYq+Tk7KIuqm Z6Xrii3L+wSeBcc1DLGByC8A3a90dRJbiFbG2v7c= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged) claimed to be smtpclient.apple From: Ben Campbell Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9C2D89C6-B122-49D0-9C99-5C7539F1EFA0" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Date: Mon, 11 Apr 2022 14:27:32 -0500 In-Reply-To: Cc: Chris Wendt , Russ Housley , Jon Peterson , Robert Sparks To: IETF STIR Mail List References: X-Mailer: Apple Mail (2.3696.80.82.1.1) Archived-At: Subject: Re: [stir] Doodle: Potential April Virtual Interim Meeting X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 19:27:57 -0000 --Apple-Mail=_9C2D89C6-B122-49D0-9C99-5C7539F1EFA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Oops, make that 10:00 _EDT_ and 1400 UCT. (Sigh, I hate time zones) Ben. > On Apr 11, 2022, at 10:29 AM, Ben Campbell wrote: >=20 > Hi, >=20 > It looks like we have a doodle quorum. We will hold a 2 hour interim = meeting at 10:00 EST (I think that=E2=80=99s 15:00 UTC) on 22 April. = Watch for an =E2=80=9Cofficial=E2=80=9D announcement shortly. >=20 > Thanks! >=20 > Ben. >=20 >> On Apr 4, 2022, at 1:24 PM, Ben Campbell > wrote: >>=20 >> Hi Everyone, >>=20 >> Since we did not have a meeting in Vienna, we=E2=80=99d like to = arrange a virtual interim. We are attempting to target the third or = fourth week of April. We are currently planning a 2 hour meeting, but = that could change as we figure out the agenda. >>=20 >> Please indicate your availability in the linked doodle poll, = preferably by the end of this week. We=E2=80=99ve picked US friendly = time slots, since I think most of our participants are from the US=E2=80=94= but if these times cause pain for anyone who would like to participant, = please let us know ASAP and we will look at some other slots. >>=20 >> https://doodle.com/meeting/participate/id/mbkJAq5a = >>=20 >> Thanks! >>=20 >> Ben (for the STIR chairs) >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_9C2D89C6-B122-49D0-9C99-5C7539F1EFA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Oops,= make that 10:00 _EDT_ and 1400 UCT. (Sigh, I hate time zones)

Ben.

On Apr 11, 2022, at 10:29 AM, Ben Campbell <ben@nostrum.com> = wrote:

Hi,

It looks like we have a doodle quorum. = We will hold a 2 hour interim meeting at 10:00 EST (I think that=E2=80=99s= 15:00 UTC) on 22 April. Watch for an =E2=80=9Cofficial=E2=80=9D = announcement shortly.

Thanks!

Ben.

On Apr 4, 2022, at 1:24 PM, Ben Campbell = <ben@nostrum.com> = wrote:

Hi Everyone,

Since we did not have a = meeting in Vienna, we=E2=80=99d like to arrange a virtual interim. We = are attempting to target the third or fourth week of April. We are = currently planning a 2 hour meeting, but that could change as we figure = out the agenda.

Please indicate your availability in the linked doodle poll, = preferably by the end of this week. We=E2=80=99ve picked US friendly = time slots, since I think most of our participants are from the US=E2=80=94= but if these times cause pain for anyone who would like to participant, = please let us know ASAP and we will look at some other slots.

https://doodle.com/meeting/participate/id/mbkJAq5a

Thanks!

Ben (for the STIR = chairs)
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_____________________________________________= __
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_9C2D89C6-B122-49D0-9C99-5C7539F1EFA0-- From nobody Mon Apr 11 14:48:06 2022 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8765E3A1CB8; Mon, 11 Apr 2022 14:48:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164971368339.27063.16920313800107401744@ietfa.amsl.com> Date: Mon, 11 Apr 2022 14:48:03 -0700 Archived-At: Subject: [stir] Secure Telephone Identity Revisited (stir) WG Virtual Meeting: 2022-04-22 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 21:48:04 -0000 The Secure Telephone Identity Revisited (stir) WG will hold a virtual interim meeting on 2022-04-22 from 10:00 to 12:00 America/New_York (14:00 to 16:00 UTC). Agenda: Agenda TBA on STIR mail list Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=aa0d3d42-863f-4e0d-ac30-54914401d828 From nobody Tue Apr 12 13:18:32 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03443A0B48; Tue, 12 Apr 2022 13:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.186, MAY_BE_FORGED=1, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOZk4Yu0accX; Tue, 12 Apr 2022 13:18:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A573A0B2A; Tue, 12 Apr 2022 13:18:25 -0700 (PDT) Received: from smtpclient.apple (mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged)) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 23CKIA1t093085 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 12 Apr 2022 15:18:11 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1649794695; bh=dleMO8Xi6fKcJDm8zC7JuX0fLEA5ibHQFSlFXOnNUaI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Bc6S0M0DNH3nvbJl3ZeVYHGUAMGQd5XKpGqRlXho1m6UanxUtxf3k8/maWNlTnDCl D0e1GbUvfiKQiCmVWhmmVlZWc6hDQ2yTlw6BC42R0KNZLVQ/lQQt4/86ZuCY7YV4ma BbprlqCbGfh8fic8vaglc9ccci4Gw7smiKyFclLM= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged) claimed to be smtpclient.apple From: Ben Campbell Message-Id: <97AB0ACC-011C-48F8-826A-2E7238485D30@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BDA0A27B-2C24-408B-996B-79CB1EE66650" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Date: Tue, 12 Apr 2022 15:18:05 -0500 In-Reply-To: <28766342-130D-4FED-AD38-7A817D4B525B@chriswendt.net> Cc: Henning Schulzrinne , IETF STIR Mail List , SIPCORE To: Chris Wendt References: <86BE36F5-7CFE-48BE-B0A7-7458B67EB208@chriswendt.net> <51718867-9092-4423-B895-8069A8AF3D07@chriswendt.net> <28766342-130D-4FED-AD38-7A817D4B525B@chriswendt.net> X-Mailer: Apple Mail (2.3696.80.82.1.1) Archived-At: Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 20:18:31 -0000 --Apple-Mail=_BDA0A27B-2C24-408B-996B-79CB1EE66650 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (as individual) (as individual) Apologies for coming to this thread late. I agree we should keep the crn claim for =E2=80=9Crcd=E2=80=9D passports = at this point. I also understand there to be some implementations that = either use it or plan to use it.. I don=E2=80=99t have a strong opinion on the Callinfo param vs Subject = question, as long as we have a consistent mapping. I guess there is the = question of whether SBCs will mess with either, but I don=E2=80=99t know = if that is more likely for one or the other.=20 Thanks! Ben. > On Mar 20, 2022, at 10:47 AM, Chris Wendt = wrote: >=20 > Hi Henning, >=20 > Just to focus on call-reason for passport-rcd at the moment, we do = have that, it is an independent claim =E2=80=9Ccrn=E2=80=9D explicitly = separate from the =E2=80=9Crcd=E2=80=9D claim. It is defined in same = passport-rcd document, but that doesn=E2=80=99t change how it=E2=80=99s = defined or used. I think one hopefully simple fix is to maybe reference = Subject as a mapping for this claim and maybe point to callinfo-rcd in a = more generic way that we can further discuss subject vs callinfo in the = sipcore draft as we move that forward. As i understand it, most = implementations are focused on passport-rcd at the moment, so i don=E2=80=99= t want to hold that up if possible. >=20 > To everyone, >=20 > It would be great to get further input on this whether anyone has = strong feelings about using Subject vs callinfo parameter call-reason. = I have the sense that there isn=E2=80=99t yet much implementation if any = at all (of callinfo/call-reason, i believe there is implementation of = passport-rcd =E2=80=9Ccrn=E2=80=9D), and there won't strong feeling one = way or the other, but if anyone does have strong feelings please speak = up. >=20 > -Chris >=20 >> On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne > wrote: >>=20 >> Hi Chris, >>=20 >> tl;dr: My suggestions are: (1) leave call purpose out of = draft-ietf-stir-passport-rcd; (2) drop call-purpose from = draft-ietf-sipcore-call-info-rcd; (3) consider a new JWT claim "subject" = [or whatever] that encapsulates the signed call purpose in the future. >>=20 >> More details inline below. >>=20 >> On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt = > wrote: >> Hi Henning, >>=20 >> I understand what you are saying. I do however think there is = reasons to protect call-reason/Subject of call. I think these = situations are mostly in the context of delegation to perhaps a call = center, where you have authorized them to represent your company in = particular ways, including not only your identity, but for different = context of calls that you have authorized them to represent you. We all = know there is some call centers that use call identities with good = reputation for customers that may exploit that reputation for other = customers. I would look at this as similar situation. >>=20 >> I think we generally agree - your example of a call center is = probably, in my view, the most likely case where some indication of call = purpose will be used, probably with explicit arrangement with the = carrier. This may well turn out to be similar to the current model for = SMS, where (in the US and some other countries) you'll have to register = your "campaign" with the carrier or designated third party. This may = even take the notion of a template ("This call is about your recent = order from {date}") that can be auto-enforced. It's clear that carriers = seem quite concerned about their individual customers messaging, in = volume, to their subscribers, given the abuse. >> =20 >>=20 >> There is also potential for future of Subject/call-reason to be more = than just a text string. >>=20 >> I suspect that's best handled separately, once we have a clearer use = case. I don't think we can just stick this into call-reason without all = kinds of backwards-compatibility issues.=20 >> =20 >>=20 >> I=E2=80=99m struggling a bit on your point that we should sign some = data but not other data because it is less likely to be manipulated. Is = that the bar we should be striving for here? Seems to conflict with my = understanding of some of the goals. >>=20 >> Maybe this indicates that we should be clearer on the goals. My take = on the value of STIR "classic" (for TNs) is that the main purpose of = signing is to make it clear who is responsible for the information = provided - thus, the whole discussion of A/B/C attestation. Indeed, the = experience seems to indicate that C-level attestation is actually a = signal for a robocall, i.e,. C-level calls are *more* likely to be = robocalls than unsigned calls. A/B/C obviously have the same = cryptographic strength and all prevent modification by third parties. >>=20 >> I don't think that carrier manipulation of the caller information = (except in various normalization ways) has ever been a major problem - = it's originator (OSP or end user) spoofing. This is rather different = than the typical threat model where the originator worries about evil = Mallory changing their data, e.g., by redirecting a money transfer to = them. >> =20 >> But for call-purpose, this is less relevant - this is clearly = (mostly) useful if inserted by the originating caller, and unlike for = A-level attestation, the carrier can't really validate that the message = is truthful. How would it know that "You have won a cruise!" in the = call-purpose/Subject was correct or a scam? Indeed, as mentioned, if I = were a carrier, I'd never want to attest to that purpose, as somebody = could reasonably claim that the carrier should have known that the = recipients hadn't won anything. >>=20 >> This is the main reason that I think this should be a separate claim = - if anybody should sign/attest this, it's the enterprise call center = and only that call center. >>=20 >>=20 >> Why not have the framework that we can do that. You are free to = protect or not protect data depending on your own policy.=20 >>=20 >> Nothing wrong as such. My argument is that RCD and = call-purpose/Subject are very different, so they shouldn't be in the = *same* framework. If we need Subject/call-purpose, they should be in = separate claims, for the operational reasons mentioned.=20 >> =20 >>=20 >> I guess i want to be sure whether you are reacting to us not using = Subject vs call-info as a common container for =E2=80=9Crich call = data=E2=80=9D related info or that we have both call-info and =E2=80=98rcd= =E2=80=99 as a container for Rich Call Data more generally? I think = there is many reasons why we landed there, we can re-hash that in the = context of call-info vs subject. I would be less excited about = re-hashing it for passport/rcd. >>=20 >> For the reasons above, I think this is a bad idea for both cases, in = my view. It's worse for Call-Info, because of the duplication of = existing functionality. >>=20 >> To use an analogy: The RCD is mostly like a business card. We don't = typically write our contracts and messages on business cards - we might = staple our business card to a note. >>=20 >> My constructive suggestion is to create a separate claim if needed. = (My understanding is that rcd-14 does not contain the call purpose, so = this is the current state.) >> =20 >>=20 >> I do believe both of these frameworks need to be extensible, i = don=E2=80=99t think we are finished. We can define more passport = extensions, but at the same time, do we want to redefine =E2=80=9Crcd=E2=80= =9D and =E2=80=9Crcdi=E2=80=9D for new passport extensions? >>=20 >> No, we should create, in my view, a separate document that focuses on = signing the call purpose, expressed either as Subject (as the compact = form) or an explicit JWT claim, such as "subject". >>=20 >>=20 >> -Chris >>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = --Apple-Mail=_BDA0A27B-2C24-408B-996B-79CB1EE66650 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
(as individual)

(as individual)

Apologies for coming to this thread late.

I agree we should keep = the crn claim for =E2=80=9Crcd=E2=80=9D passports at this point. I also = understand there to be some implementations that either use it or plan = to use it..

I = don=E2=80=99t have a strong opinion on the Callinfo param vs Subject = question, as long as we have a consistent mapping. I guess there is the = question of whether SBCs will mess with either, but I don=E2=80=99t know = if that is more likely for one or the other. 

Thanks!

Ben.

On Mar = 20, 2022, at 10:47 AM, Chris Wendt <chris-ietf@chriswendt.net> wrote:

Hi Henning,

Just to focus on = call-reason for passport-rcd at the moment, we do have that, it is an = independent claim =E2=80=9Ccrn=E2=80=9D explicitly separate from the = =E2=80=9Crcd=E2=80=9D claim. It is defined in same passport-rcd = document, but that doesn=E2=80=99t change how it=E2=80=99s defined or = used. I think one hopefully simple fix is to maybe reference Subject as = a mapping for this claim and maybe point to callinfo-rcd in a more = generic way that we can further discuss subject vs callinfo in the = sipcore draft as we move that forward.  As i understand it, most = implementations are focused on passport-rcd at the moment, so i don=E2=80=99= t want to hold that up if possible.

To everyone,

It would be great to get further input on this = whether anyone has strong feelings about using Subject vs callinfo = parameter call-reason.  I have the sense that there isn=E2=80=99t = yet much implementation if any at all (of callinfo/call-reason, i = believe there is implementation of passport-rcd =E2=80=9Ccrn=E2=80=9D), = and there won't strong feeling one way or the other, but if anyone does = have strong feelings please speak up.

-Chris

On Mar 19, 2022, at 3:25 PM, = Henning Schulzrinne <hgs@cs.columbia.edu> wrote:

Hi Chris,

tl;dr: My suggestions are: (1) leave = call purpose out of draft-ietf-stir-passport-rcd; (2) drop = call-purpose from draft-ietf-sipcore-call-info-rcd; (3) consider a = new JWT claim "subject" [or whatever] that encapsulates the signed call = purpose in the future.

More details inline below.

On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <chris-ietf@chriswendt.net> wrote:
Hi Henning,

I understand what you are saying.  I do however think = there is reasons to protect call-reason/Subject of call.  I think = these situations are mostly in the context of delegation to perhaps a = call center, where you have authorized them to represent your company in = particular ways, including not only your identity, but for different = context of calls that you have authorized them to represent you.  = We all know there is some call centers that use call identities with = good reputation for customers that may exploit that reputation for other = customers.  I would look at this as similar = situation.

I think we generally = agree - your example of a call center is probably, in my view, the most = likely case where some indication of call purpose will be used, probably = with explicit arrangement with the carrier. This may well turn out to be = similar to the current model for SMS, where (in the US and some other = countries) you'll have to register your "campaign" with the carrier or = designated third party. This may even take the notion of a template = ("This call is about your recent order from {date}") that can be = auto-enforced. It's clear that carriers seem quite concerned about their = individual customers messaging, in volume, to their subscribers, given = the abuse.
 

There is also potential = for future of Subject/call-reason to be more than just a text = string.

I suspect that's best handled separately, once we have a = clearer use case. I don't think we can just stick this into call-reason = without all kinds of backwards-compatibility issues. 
 

I=E2=80=99= m struggling a bit on your point that we should sign some data but not = other data because it is less likely to be manipulated.  Is that = the bar we should be striving for here? Seems to conflict with my = understanding of some of the goals.

Maybe = this indicates that we should be clearer on the goals. My take on the = value of STIR "classic" (for TNs) is that the main purpose of signing is = to make it clear who is responsible for the information provided - thus, = the whole discussion of A/B/C attestation. Indeed, the experience seems = to indicate that C-level attestation is actually a signal for a = robocall, i.e,. C-level calls are *more* likely to be robocalls than = unsigned calls. A/B/C obviously have the same cryptographic strength and = all prevent modification by third parties.

I don't think that carrier manipulation = of the caller information (except in various normalization ways) has = ever been a major problem - it's originator (OSP or end user) spoofing. = This is rather different than the typical threat model where the = originator worries about evil Mallory changing their data, e.g., by = redirecting a money transfer to them.
 
But for call-purpose, this is = less relevant - this is clearly (mostly) useful if inserted by the = originating caller, and unlike for A-level attestation, the carrier = can't really validate that the message is truthful. How would it know = that "You have won a cruise!" in the call-purpose/Subject was correct or = a scam? Indeed, as mentioned, if I were a carrier, I'd never want to = attest to that purpose, as somebody could reasonably claim that the = carrier should have known that the recipients hadn't won = anything.

This = is the main reason that I think this should be a separate claim - = if anybody should sign/attest this, it's the enterprise call center and = only that call center.


Why not = have the framework that we can do that.  You are free to protect or = not protect data depending on your own = policy. 

Nothing wrong as such. My argument is = that RCD and call-purpose/Subject are very different, so they shouldn't = be in the *same* framework. If we need Subject/call-purpose, they should = be in separate claims, for the operational reasons = mentioned. 
 

I guess i want to be = sure whether you are reacting to us not using Subject vs call-info as a = common container for =E2=80=9Crich call data=E2=80=9D related info or = that we have both call-info and =E2=80=98rcd=E2=80=99 as a container for = Rich Call Data more generally?  I think there is many reasons why = we landed there, we can re-hash that in the context of call-info vs = subject.  I would be less excited about re-hashing it for = passport/rcd.

For the reasons above, I think this is = a bad idea for both cases, in my view. It's worse for = Call-Info, because of the duplication of existing = functionality.

To use an analogy: The RCD is mostly like a business card. We = don't typically write our contracts and messages on business cards - we = might staple our business card to a note.

My constructive suggestion is to create = a separate claim if needed. (My understanding is that rcd-14 does not = contain the call purpose, so this is the current state.)
 

I do = believe both of these frameworks need to be extensible, i don=E2=80=99t = think we are finished.  We can define more passport extensions, but = at the same time, do we want to redefine =E2=80=9Crcd=E2=80=9D and = =E2=80=9Crcdi=E2=80=9D for new passport = extensions?

No, we should create, in my view, a = separate document that focuses on signing the call purpose, expressed = either as Subject (as the compact form) or an explicit JWT claim, such = as "subject".


-Chris


<= br class=3D"">
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_BDA0A27B-2C24-408B-996B-79CB1EE66650-- From nobody Tue Apr 12 13:23:29 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D7D3A0CFD; Tue, 12 Apr 2022 13:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=X09jGiRX; dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=X09jGiRX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Teknya1XSrb0; Tue, 12 Apr 2022 13:23:16 -0700 (PDT) Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam07on20731.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e83::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674603A0CDE; Tue, 12 Apr 2022 13:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mcI4zy59DUlBb0OZBhXoO1r3Xn12SJ1t5ydSxGT+H4g=; b=X09jGiRXPKsCwjB4K3HCuu6mGwWYf0TRd2QCbhL5/zgjAmTFYLKcWTPtXIsxbo2mWaXe5w0yh3O1HHii84bx0OQ/YPux//gJJRdr3oFfhHHqgOrL4BWq1tOVQlxwRPBnvs6EBTiAWjNz8lG3mZO/rM+8LzK7y23d4JFdu6yrT3Q= Received: from DM6PR02CA0144.namprd02.prod.outlook.com (2603:10b6:5:332::11) by DM6PR02MB4523.namprd02.prod.outlook.com (2603:10b6:5:2b::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Tue, 12 Apr 2022 20:23:12 +0000 Received: from DM3NAM02FT030.eop-nam02.prod.protection.outlook.com (2603:10b6:5:332:cafe::1f) by DM6PR02CA0144.outlook.office365.com (2603:10b6:5:332::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29 via Frontend Transport; Tue, 12 Apr 2022 20:23:12 +0000 X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 144.49.247.42) smtp.mailfrom=t-mobile.com; dkim=pass (signature was verified) header.d=TMobileUSA.onmicrosoft.com;dmarc=fail action=none header.from=t-mobile.com; Received-SPF: Fail (protection.outlook.com: domain of t-mobile.com does not designate 144.49.247.42 as permitted sender) receiver=protection.outlook.com; client-ip=144.49.247.42; helo=mail.ds.dlp.protect.symantec.com; Received: from mail.ds.dlp.protect.symantec.com (144.49.247.42) by DM3NAM02FT030.mail.protection.outlook.com (10.13.4.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.19 via Frontend Transport; Tue, 12 Apr 2022 20:23:11 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RvRcVdCqSHmljw1tyWXU567PilZW1LZaEzQsGDNH9luuj1c9+KhjjkR814DxCYbOMdQdqZK5zYUqgonX6eB+zFNjAyqtp2lEO4cVfSDahoBVDYSSNgu8ligJH9/mpKSYWLD25b7g5OGNgdV+MLOk6lAYsN2BRIbu5raHUyEQ8WXlJDiTUt3eLoCkwt6ybg7qPgzLOq0u8PAHJ3iZAm+J6Vc9mBuJfTxvWxZb1OJ+ktsx0pNG6iwNBAlPFaCnzNJr6kN4uelEtBNZgzKpEVxOykhQDJeyvF+GZ+2eUqrDd0HkC4gdnFAqQgWqElAc9ITxMt+6ARL4jhIkMp3QLwBLng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mcI4zy59DUlBb0OZBhXoO1r3Xn12SJ1t5ydSxGT+H4g=; b=HmTTGfn56LhaEfLc+s7SJ6RcESKQtocK9dwnScLrtVgui09YH/teIeL8txWlHsyX5X+6FoxcKXNVVsQzP9B7v2N8ikkaapaUNuFsNcfW6y+bjBT8UZqIjCNP4rNnxxaV21lSs2TquGV1oSf9MAYsPgOkb+RkYXT7gno13wP4zFLP+5tqbU+4CS2wGYPd/UopgXh9AL+JDZVGXFuTcOvbb0E3SdnOID/aYAbV3RUJ7ge4ln/xvUL7tRwXTN+d1PcCV8xOWaZ9LGxgEbQsLhllHgL5s5GRWHJJPSgC6+okFcrtvc/WDXaYr/l2cMX2WfzF26gj4JofF7XufVFQV5bEsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=t-mobile.com; dmarc=pass action=none header.from=t-mobile.com; dkim=pass header.d=t-mobile.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mcI4zy59DUlBb0OZBhXoO1r3Xn12SJ1t5ydSxGT+H4g=; b=X09jGiRXPKsCwjB4K3HCuu6mGwWYf0TRd2QCbhL5/zgjAmTFYLKcWTPtXIsxbo2mWaXe5w0yh3O1HHii84bx0OQ/YPux//gJJRdr3oFfhHHqgOrL4BWq1tOVQlxwRPBnvs6EBTiAWjNz8lG3mZO/rM+8LzK7y23d4JFdu6yrT3Q= Received: from BYAPR02MB4168.namprd02.prod.outlook.com (2603:10b6:a02:f4::11) by BYAPR02MB4231.namprd02.prod.outlook.com (2603:10b6:a02:fc::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Tue, 12 Apr 2022 20:23:09 +0000 Received: from BYAPR02MB4168.namprd02.prod.outlook.com ([fe80::d879:56a0:3a11:6f73]) by BYAPR02MB4168.namprd02.prod.outlook.com ([fe80::d879:56a0:3a11:6f73%3]) with mapi id 15.20.5144.029; Tue, 12 Apr 2022 20:23:09 +0000 From: "Gorman, Pierce" To: Ben Campbell , Chris Wendt CC: IETF STIR Mail List , SIPCORE , Henning Schulzrinne Thread-Topic: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) Thread-Index: AQHYOtLeZhFqIWu2qEWgbx5Bv5s9yqzFlosAgAAPAICAAXMeAIABVT8AgCRxR4CAAACJ8A== Date: Tue, 12 Apr 2022 20:23:09 +0000 Message-ID: References: <86BE36F5-7CFE-48BE-B0A7-7458B67EB208@chriswendt.net> <51718867-9092-4423-B895-8069A8AF3D07@chriswendt.net> <28766342-130D-4FED-AD38-7A817D4B525B@chriswendt.net> <97AB0ACC-011C-48F8-826A-2E7238485D30@nostrum.com> In-Reply-To: <97AB0ACC-011C-48F8-826A-2E7238485D30@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=t-mobile.com; X-MS-Office365-Filtering-Correlation-Id: ea017663-cb0d-40be-4983-08da1cc24427 x-ms-traffictypediagnostic: BYAPR02MB4231:EE_|DM3NAM02FT030:EE_|DM6PR02MB4523:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: jVubeJij7BKawnXVqLbgHlCzdo3FuZdBkB5Wax3DetIWRel2eMeWMb9kKw8uTAsZquZV1kZgm5KTGaykMWVFpLdPRR+NMAU7XRLMnue4JslfyoUubTKVR2qNgD1306n8pEHaAi/HiAGoX948sIGG01W+obbiCQ17J8zQLeNhCtzRyLtdXNagt+6g+QetsdY6Nyv0c9DQgu+SOEKtUhKyKkI3qooRZ5ldwzRBUphUBPNf2Fx0ZkU8PKLVCvZPj+VxNmctXFQ2bsHoCizOZ0qE5eYAlpZCM3rx8TeZQKgPXVXDEQd0pacy8qlonq9pCPtJgqqupWzDECXP7FnfRbZFyvkHjyrAF2paw5j2GLTtTu3cpO+/Dxwt+42LqSDO42zkTrFWDw+qpipevdSR8XHm9Uu216UJbxj1+OU3PNxT8cVFrzxgii5r7joQSvnah8+wBurffWAMCFLxe4nwoDo47qshK7suvpDgJtXoxD15UNTZmfQC/FIqdm+g53JNgMbFdFZcgnDRLS1AxjWH2QVQzFpUygHxqXYgm6CjACjrIUfwKUqagQty3/tfWqgg6QTUm66i0LV0ydzs2zksHyyuD7Y5E55jZbMw5eSbtumnKAVSLpwIEbO8aAMmHov+r37TP/K0djjyiikHX6FA2ro8XWrN7sJG9jA76vgHkaN/G1ahxAaNRaAMjXPLfg1khWj7OJjfrhYspTbrhqaEgEc+GCZMcr/6JAw1nfRJ5+dnyCkWdRcs+RNpvdR+R6T9/ITF+9Qorc6BcNCVYJMcz62uw22sqxMgnG/On9c3Ep1uzRM= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR02MB4168.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(86362001)(33656002)(38070700005)(2906002)(38100700002)(82960400001)(26005)(71200400001)(186003)(55016003)(53546011)(7696005)(6506007)(9686003)(66446008)(66476007)(66556008)(83380400001)(66946007)(76116006)(64756008)(8676002)(52536014)(5660300002)(122000001)(8936002)(166002)(508600001)(4326008)(966005)(54906003)(316002)(110136005); DIR:OUT; SFP:1102; Content-Type: multipart/alternative; boundary="_000_BYAPR02MB4168AC85059C24E4D6186387D2ED9BYAPR02MB4168namp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB4231 X-CFilter-Loop: Reflected X-DetectorID-Processed: 8c846453-0f50-46b3-95ab-8bbaf7238615 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DM3NAM02FT030.eop-nam02.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 123a8753-d362-468a-b5c8-08da1cc242c5 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gykht0INiOR69ZsAK3OA03C029gQstZd1fJCIbdwIEatDaK7vYgbKpotOkufdOTLtvZ+62xUCi6ReVELMxUwyv5fdrjSeBTmiWUTx12DLDa1e+uYmJ3j8OrJDK6f3p22n6Iuy9uLQAZjvp0VYhWmslBJtKATO54R2GbB+e0wzoLyL3F/zoebuMgNJq5b44elLt9/4GRzAVum9vEdMNBkiS5OphMQcGvcL6c3s2Zwi4BHVXTIMY+KvMj96p3AqfbaJmACz++7pSpSuz21Pp+aR3Ik6gl52y7FYGpDYIEkTTXw6XkHnvhUsrzKuHVgo7kBVf1nqpDeMto5j8tKq4uic/bC/C/usIBFm7IdxzKKXBxHKaTzY+CTdku/ECi7eX/gSzHVLNfrU9n601QhjcGO7d8jL7ZYS8VW0zMYRE7XJdAq/kWM9C/YkQJRH1NapHhBvft0lyIyLwnyT3dKN/g4Ze2wr1aQZroHZbAa0T8UshQitNPHex9FjJhsqndV+/aAdJVGTtqp9KwrQ2H7a9yf88H1Low5fk1jF5/0WtAG6OaFMe+ZcnYp7tvJXPMipwmg8tCii8QsRbD+8A1FTnbXp/cn1GX3MkfO+v/KwbBNyR/FR7HtDUY6nlayLdi2/Loj5RExP4oh4qGFoqmLzETY5KGJwEL82C48fGmu9eoY+0yQdes8PCrbGp9PZjy5LvnYvfnfQIVq/ZbQT2hlXdtNv8wU9fsguL5TQVdILl7xYnMtXbNO104EgHJJ+pkhZ3fb4jeF9vsOE0v5WBjy7mTwtnTPAE5lHy3uoFbmkSNs1Ys= X-Forefront-Antispam-Report: CIP:144.49.247.42; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.ds.dlp.protect.symantec.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230001)(4636009)(46966006)(36840700001)(40470700004)(55016003)(86362001)(52536014)(8936002)(966005)(82960400001)(508600001)(356005)(6506007)(30864003)(5660300002)(4326008)(70586007)(316002)(54906003)(70206006)(8676002)(36860700001)(336012)(7696005)(47076005)(40460700003)(186003)(26005)(110136005)(83380400001)(82310400005)(166002)(81166007)(45080400002)(9686003)(53546011)(33656002)(2906002)(36900700001); DIR:OUT; SFP:1102; X-OriginatorOrg: t-mobile.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2022 20:23:11.6973 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ea017663-cb0d-40be-4983-08da1cc24427 X-MS-Exchange-CrossTenant-Id: be0f980b-dd99-4b19-bd7b-bc71a09b026c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=be0f980b-dd99-4b19-bd7b-bc71a09b026c; Ip=[144.49.247.42]; Helo=[mail.ds.dlp.protect.symantec.com] X-MS-Exchange-CrossTenant-AuthSource: DM3NAM02FT030.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB4523 Archived-At: Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 20:23:21 -0000 --_000_BYAPR02MB4168AC85059C24E4D6186387D2ED9BYAPR02MB4168namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I assume Call-Info or Subject are likely to be stripped by SBCs. From: stir On Behalf Of Ben Campbell Sent: Tuesday, April 12, 2022 3:18 PM To: Chris Wendt Cc: IETF STIR Mail List ; SIPCORE ; Hennin= g Schulzrinne Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) [External] (as individual) (as individual) Apologies for coming to this thread late. I agree we should keep the crn claim for "rcd" passports at this point. I a= lso understand there to be some implementations that either use it or plan = to use it.. I don't have a strong opinion on the Callinfo param vs Subject question, as= long as we have a consistent mapping. I guess there is the question of whe= ther SBCs will mess with either, but I don't know if that is more likely fo= r one or the other. Thanks! Ben. On Mar 20, 2022, at 10:47 AM, Chris Wendt > wrote: Hi Henning, Just to focus on call-reason for passport-rcd at the moment, we do have tha= t, it is an independent claim "crn" explicitly separate from the "rcd" clai= m. It is defined in same passport-rcd document, but that doesn't change how= it's defined or used. I think one hopefully simple fix is to maybe referen= ce Subject as a mapping for this claim and maybe point to callinfo-rcd in a= more generic way that we can further discuss subject vs callinfo in the si= pcore draft as we move that forward. As i understand it, most implementati= ons are focused on passport-rcd at the moment, so i don't want to hold that= up if possible. To everyone, It would be great to get further input on this whether anyone has strong fe= elings about using Subject vs callinfo parameter call-reason. I have the s= ense that there isn't yet much implementation if any at all (of callinfo/ca= ll-reason, i believe there is implementation of passport-rcd "crn"), and th= ere won't strong feeling one way or the other, but if anyone does have stro= ng feelings please speak up. -Chris On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne > wrote: Hi Chris, tl;dr: My suggestions are: (1) leave call purpose out of draft-ietf-stir-pa= ssport-rcd; (2) drop call-purpose from draft-ietf-sipcore-call-info-rcd; (3= ) consider a new JWT claim "subject" [or whatever] that encapsulates the si= gned call purpose in the future. More details inline below. On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt > wrote: Hi Henning, I understand what you are saying. I do however think there is reasons to p= rotect call-reason/Subject of call. I think these situations are mostly in= the context of delegation to perhaps a call center, where you have authori= zed them to represent your company in particular ways, including not only y= our identity, but for different context of calls that you have authorized t= hem to represent you. We all know there is some call centers that use call= identities with good reputation for customers that may exploit that reputa= tion for other customers. I would look at this as similar situation. I think we generally agree - your example of a call center is probably, in = my view, the most likely case where some indication of call purpose will be= used, probably with explicit arrangement with the carrier. This may well t= urn out to be similar to the current model for SMS, where (in the US and so= me other countries) you'll have to register your "campaign" with the carrie= r or designated third party. This may even take the notion of a template ("= This call is about your recent order from {date}") that can be auto-enforce= d. It's clear that carriers seem quite concerned about their individual cus= tomers messaging, in volume, to their subscribers, given the abuse. There is also potential for future of Subject/call-reason to be more than j= ust a text string. I suspect that's best handled separately, once we have a clearer use case. = I don't think we can just stick this into call-reason without all kinds of = backwards-compatibility issues. I'm struggling a bit on your point that we should sign some data but not ot= her data because it is less likely to be manipulated. Is that the bar we s= hould be striving for here? Seems to conflict with my understanding of some= of the goals. Maybe this indicates that we should be clearer on the goals. My take on the= value of STIR "classic" (for TNs) is that the main purpose of signing is t= o make it clear who is responsible for the information provided - thus, the= whole discussion of A/B/C attestation. Indeed, the experience seems to ind= icate that C-level attestation is actually a signal for a robocall, i.e,. C= -level calls are *more* likely to be robocalls than unsigned calls. A/B/C o= bviously have the same cryptographic strength and all prevent modification = by third parties. I don't think that carrier manipulation of the caller information (except i= n various normalization ways) has ever been a major problem - it's originat= or (OSP or end user) spoofing. This is rather different than the typical th= reat model where the originator worries about evil Mallory changing their d= ata, e.g., by redirecting a money transfer to them. But for call-purpose, this is less relevant - this is clearly (mostly) usef= ul if inserted by the originating caller, and unlike for A-level attestatio= n, the carrier can't really validate that the message is truthful. How woul= d it know that "You have won a cruise!" in the call-purpose/Subject was cor= rect or a scam? Indeed, as mentioned, if I were a carrier, I'd never want t= o attest to that purpose, as somebody could reasonably claim that the carri= er should have known that the recipients hadn't won anything. This is the main reason that I think this should be a separate claim - if a= nybody should sign/attest this, it's the enterprise call center and only th= at call center. Why not have the framework that we can do that. You are free to protect or= not protect data depending on your own policy. Nothing wrong as such. My argument is that RCD and call-purpose/Subject are= very different, so they shouldn't be in the *same* framework. If we need S= ubject/call-purpose, they should be in separate claims, for the operational= reasons mentioned. I guess i want to be sure whether you are reacting to us not using Subject = vs call-info as a common container for "rich call data" related info or tha= t we have both call-info and 'rcd' as a container for Rich Call Data more g= enerally? I think there is many reasons why we landed there, we can re-has= h that in the context of call-info vs subject. I would be less excited abo= ut re-hashing it for passport/rcd. For the reasons above, I think this is a bad idea for both cases, in my vie= w. It's worse for Call-Info, because of the duplication of existing functio= nality. To use an analogy: The RCD is mostly like a business card. We don't typical= ly write our contracts and messages on business cards - we might staple our= business card to a note. My constructive suggestion is to create a separate claim if needed. (My und= erstanding is that rcd-14 does not contain the call purpose, so this is the= current state.) I do believe both of these frameworks need to be extensible, i don't think = we are finished. We can define more passport extensions, but at the same t= ime, do we want to redefine "rcd" and "rcdi" for new passport extensions? No, we should create, in my view, a separate document that focuses on signi= ng the call purpose, expressed either as Subject (as the compact form) or a= n explicit JWT claim, such as "subject". -Chris _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_BYAPR02MB4168AC85059C24E4D6186387D2ED9BYAPR02MB4168namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I assume Call-= Info or Subject are likely to be stripped by SBCs.

 

 

From: stir <stir-bounces@ietf.org> O= n Behalf Of Ben Campbell
Sent: Tuesday, April 12, 2022 3:18 PM
To: Chris Wendt <chris-ietf@chriswendt.net>
Cc: IETF STIR Mail List <stir@ietf.org>; SIPCORE <sipcore@i= etf.org>; Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-r= eason)

 

<= span style=3D"font-size:10.0pt;color:#9C6500">[External]

 

(as individual)

 

(as individual)

 

Apologies for coming to this thread late.

 

I agree we should keep the crn claim for “rcd&= #8221; passports at this point. I also understand there to be some implemen= tations that either use it or plan to use it..

 

I don’t have a strong opinion on the Callinfo = param vs Subject question, as long as we have a consistent mapping. I guess= there is the question of whether SBCs will mess with either, but I donR= 17;t know if that is more likely for one or the other. 

 

Thanks!

 

Ben.



On Mar 20, 2022, at 10:47 AM, Chris Wendt <chris-ietf@chriswendt.net> wr= ote:

 

Hi Henning,

 

Just to focus on call-reason for passport-rcd at t= he moment, we do have that, it is an independent claim “crn” ex= plicitly separate from the “rcd” claim. It is defined in same passport-rcd document, but that doesn’t change how it’s define= d or used. I think one hopefully simple fix is to maybe reference Subject a= s a mapping for this claim and maybe point to callinfo-rcd in a more generi= c way that we can further discuss subject vs callinfo in the sipcore draft as we move that forward.  As i understa= nd it, most implementations are focused on passport-rcd at the moment, so i= don’t want to hold that up if possible.

 

To everyone,

 

It would be great to get further input on this whe= ther anyone has strong feelings about using Subject vs callinfo parameter c= all-reason.  I have the sense that there isn’t yet much implementation if any at all (of callinfo/call-reason, i believe = there is implementation of passport-rcd “crn”), and there won't= strong feeling one way or the other, but if anyone does have strong feelin= gs please speak up.

 

-Chris



On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne &= lt;hgs@cs.columbia.edu> wrote= :

 

Hi Chris,

 

tl;dr: My suggestions are: (1) leave call purpose = out of draft-ietf-stir-passport-rcd; (2) drop call-purpose from d= raft-ietf-sipcore-call-info-rcd; (3) consider a new JWT claim "subject" [or whatever] that encapsulates the signed call = purpose in the future.

 

More details inline below.

 

On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <chris-ietf@chr= iswendt.net> wrote:

Hi Henning,

 

I understand what you are saying.  I do howev= er think there is reasons to protect call-reason/Subject of call.  I t= hink these situations are mostly in the context of delegation to perhaps a call center, where you have authorized them to represent your= company in particular ways, including not only your identity, but for diff= erent context of calls that you have authorized them to represent you. = ; We all know there is some call centers that use call identities with good reputation for customers that may explo= it that reputation for other customers.  I would look at this as simil= ar situation.

 

I think we generally agree - your example of a cal= l center is probably, in my view, the most likely case where some indicatio= n of call purpose will be used, probably with explicit arrangement with the carrier. This may well turn out to be simila= r to the current model for SMS, where (in the US and some other countries) = you'll have to register your "campaign" with the carrier or desig= nated third party. This may even take the notion of a template ("This call is about your recent order from {dat= e}") that can be auto-enforced. It's clear that carriers seem quite co= ncerned about their individual customers messaging, in volume, to their sub= scribers, given the abuse.

 

 

There is also potential for future of Subject/call= -reason to be more than just a text string.

 

I suspect that's best handled separately, once we = have a clearer use case. I don't think we can just stick this into call-rea= son without all kinds of backwards-compatibility issues. 

 

 

I’m struggling a bit on your point that we s= hould sign some data but not other data because it is less likely to be man= ipulated.  Is that the bar we should be striving for here? Seems to conflict with my understanding of some of the goals.

 

Maybe this indicates that we should be clearer on = the goals. My take on the value of STIR "classic" (for TNs) is th= at the main purpose of signing is to make it clear who is responsible for the information provided - thus, the whole discussion of A= /B/C attestation. Indeed, the experience seems to indicate that C-level att= estation is actually a signal for a robocall, i.e,. C-level calls are *more= * likely to be robocalls than unsigned calls. A/B/C obviously have the same cryptographic strength and all preven= t modification by third parties.

 

I don't think that carrier manipulation of the cal= ler information (except in various normalization ways) has ever been a majo= r problem - it's originator (OSP or end user) spoofing. This is rather different than the typical threat model where the= originator worries about evil Mallory changing their data, e.g., by redire= cting a money transfer to them.

 

But for call-purpose, this is less relevant - this= is clearly (mostly) useful if inserted by the originating caller, and unli= ke for A-level attestation, the carrier can't really validate that the message is truthful. How would it know that "= ;You have won a cruise!" in the call-purpose/Subject was correct or a = scam? Indeed, as mentioned, if I were a carrier, I'd never want to attest t= o that purpose, as somebody could reasonably claim that the carrier should have known that the recipients hadn't won an= ything.

 

This is the main reason that I think this should b= e a separate claim - if anybody should sign/attest this, it's the ente= rprise call center and only that call center.

 

 

Why not have the framework that we can do that.&nb= sp; You are free to protect or not protect data depending on your own polic= y. 

 

Nothing wrong as such. My argument is that RCD and= call-purpose/Subject are very different, so they shouldn't be in the *same= * framework. If we need Subject/call-purpose, they should be in separate claims, for the operational reasons mentioned.&= nbsp;

 

 

I guess i want to be sure whether you are reacting= to us not using Subject vs call-info as a common container for “rich= call data” related info or that we have both call-info and ‘rcd’ as a container for Rich Call Data more generally?&nb= sp; I think there is many reasons why we landed there, we can re-hash that = in the context of call-info vs subject.  I would be less excited about= re-hashing it for passport/rcd.

 

For the reasons above, I think this is a bad idea = for both cases, in my view. It's worse for Call-Info, because of = the duplication of existing functionality.

 

To use an analogy: The RCD is mostly like a busine= ss card. We don't typically write our contracts and messages on business ca= rds - we might staple our business card to a note.

 

My constructive suggestion is to create a separate= claim if needed. (My understanding is that rcd-14 does not contain the cal= l purpose, so this is the current state.)

 

 

I do believe both of these frameworks need to be e= xtensible, i don’t think we are finished.  We can define more pa= ssport extensions, but at the same time, do we want to redefine “rcd” and “rcdi” for new passport extensions?=

 

No, we should create, in my view, a separate docum= ent that focuses on signing the call purpose, expressed either as Subject (= as the compact form) or an explicit JWT claim, such as "subject".

 

 

-Chris

 

 

 

_______________________________________________ sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore=

 

--_000_BYAPR02MB4168AC85059C24E4D6186387D2ED9BYAPR02MB4168namp_-- From nobody Tue Apr 12 13:47:40 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998A63A1763; Tue, 12 Apr 2022 13:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYrxQXQLBabf; Tue, 12 Apr 2022 13:47:13 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5763A179F; Tue, 12 Apr 2022 13:46:51 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id i27so39676401ejd.9; Tue, 12 Apr 2022 13:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UXdzH9bZa3eSWG6sAZRgNbs7a0CnwwLcCPVzPoYkJnk=; b=CbTVDQzseKvZ7naghjoSwohn7pO8UaaNDJougE6GsWjFp96qW5GLmqNFsyRwDwMbwu UOlUcQazkrB8JOpgGWMWLsqgAo+lnypfj7HWa+dkZqctKGOKHHrzEWmnM9YHyQH8NSVL Tnb8/LAUxxBvPaTJ9kRKk0g4tHk87Qj6Avq7bQAUL+jxC2s2AHlkIDLEqX2+57Khhscf 7EdBMYS+iei4Bb52RmiElqM9V6mU8snwS55YJIYh/Fhol9HWqV1c3keX+2Mmj9n18GPK cmxvkk7qW2YPoAiOtAjFXGttth7AaI1Q0ypAlB20y8DLfIRKX+J6CBJclMaNM5N7Te++ TUGQ== 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=UXdzH9bZa3eSWG6sAZRgNbs7a0CnwwLcCPVzPoYkJnk=; b=WP+YnSG/MvpvsU9zklZ3tCwpweWo4dH5ThC+ZEWgOJ6V7prSmmssEuxXD5iwmr4Y82 zEwDXOeRe7sSMo8oMSyQ+WSVVVzB3S/gxKMCVxz+pHzyehWlYFzqMDVsJQkv9O0IuDaS fLoRCc/U7Kq8SwyzFSbkbuDG5eYU1SlYJzQnLXX7HA1F9ftljwnAP1y8i/WlJ1km2oTo +xY+uuRjtHsvHWK9bvXVRF/P1jwArYgIV2GAEWlaGt9O1BJ7gZlUvLH459vliLtRAiAc o3EYwCfHdLAcmDKeRC1v0qSwoUOSlGJ7mE342M6xafgr5VvZIAYvcfGmKHpgtG4AN+wl No9Q== X-Gm-Message-State: AOAM532h3tm4YT/wezPYnn152TjiKFPd1XPQ1l81s7sXok+0zZqVwu9a Di/thnDNo41VF96wJIk39NtOhS4f0/2UxZWesm9DnYun X-Google-Smtp-Source: ABdhPJxGJerkmzOVgvMpLGywP8Otoh/joII0Xc5HnHk+kDZ4j9L2fOrH9E1ekMk64Nnbsm4Byfh7dC7R5h/L9MEbDKU= X-Received: by 2002:a17:906:c344:b0:6b4:c768:4a9a with SMTP id ci4-20020a170906c34400b006b4c7684a9amr36622401ejb.151.1649796409200; Tue, 12 Apr 2022 13:46:49 -0700 (PDT) MIME-Version: 1.0 References: <86BE36F5-7CFE-48BE-B0A7-7458B67EB208@chriswendt.net> <51718867-9092-4423-B895-8069A8AF3D07@chriswendt.net> <28766342-130D-4FED-AD38-7A817D4B525B@chriswendt.net> <97AB0ACC-011C-48F8-826A-2E7238485D30@nostrum.com> In-Reply-To: From: Ranjit Avasarala Date: Tue, 12 Apr 2022 15:46:38 -0500 Message-ID: To: "Gorman, Pierce" Cc: Ben Campbell , Chris Wendt , IETF STIR Mail List , SIPCORE Content-Type: multipart/alternative; boundary="000000000000ec17cb05dc7b286a" Archived-At: Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 20:47:26 -0000 --000000000000ec17cb05dc7b286a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Depends on policy, but they could be passed thru to if needed Regards Ranjit On Tue, Apr 12, 2022 at 3:23 PM Gorman, Pierce wrote: > I assume Call-Info or Subject are likely to be stripped by SBCs. > > > > > > *From:* stir *On Behalf Of * Ben Campbell > *Sent:* Tuesday, April 12, 2022 3:18 PM > *To:* Chris Wendt > *Cc:* IETF STIR Mail List ; SIPCORE ; > Henning Schulzrinne > *Subject:* Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 > (call-reason) > > > > *[External]* > > > > (as individual) > > > > (as individual) > > > > Apologies for coming to this thread late. > > > > I agree we should keep the crn claim for =E2=80=9Crcd=E2=80=9D passports = at this point. I > also understand there to be some implementations that either use it or pl= an > to use it.. > > > > I don=E2=80=99t have a strong opinion on the Callinfo param vs Subject qu= estion, > as long as we have a consistent mapping. I guess there is the question of > whether SBCs will mess with either, but I don=E2=80=99t know if that is m= ore likely > for one or the other. > > > > Thanks! > > > > Ben. > > > > On Mar 20, 2022, at 10:47 AM, Chris Wendt > wrote: > > > > Hi Henning, > > > > Just to focus on call-reason for passport-rcd at the moment, we do have > that, it is an independent claim =E2=80=9Ccrn=E2=80=9D explicitly separat= e from the =E2=80=9Crcd=E2=80=9D > claim. It is defined in same passport-rcd document, but that doesn=E2=80= =99t change > how it=E2=80=99s defined or used. I think one hopefully simple fix is to = maybe > reference Subject as a mapping for this claim and maybe point to > callinfo-rcd in a more generic way that we can further discuss subject vs > callinfo in the sipcore draft as we move that forward. As i understand i= t, > most implementations are focused on passport-rcd at the moment, so i don= =E2=80=99t > want to hold that up if possible. > > > > To everyone, > > > > It would be great to get further input on this whether anyone has strong > feelings about using Subject vs callinfo parameter call-reason. I have t= he > sense that there isn=E2=80=99t yet much implementation if any at all (of > callinfo/call-reason, i believe there is implementation of passport-rcd > =E2=80=9Ccrn=E2=80=9D), and there won't strong feeling one way or the oth= er, but if anyone > does have strong feelings please speak up. > > > > -Chris > > > > On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne > wrote: > > > > Hi Chris, > > > > tl;dr: My suggestions are: (1) leave call purpose out > of draft-ietf-stir-passport-rcd; (2) drop call-purpose > from draft-ietf-sipcore-call-info-rcd; (3) consider a new JWT claim > "subject" [or whatever] that encapsulates the signed call purpose in the > future. > > > > More details inline below. > > > > On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt > wrote: > > Hi Henning, > > > > I understand what you are saying. I do however think there is reasons to > protect call-reason/Subject of call. I think these situations are mostly > in the context of delegation to perhaps a call center, where you have > authorized them to represent your company in particular ways, including n= ot > only your identity, but for different context of calls that you have > authorized them to represent you. We all know there is some call centers > that use call identities with good reputation for customers that may > exploit that reputation for other customers. I would look at this as > similar situation. > > > > I think we generally agree - your example of a call center is probably, i= n > my view, the most likely case where some indication of call purpose will = be > used, probably with explicit arrangement with the carrier. This may well > turn out to be similar to the current model for SMS, where (in the US and > some other countries) you'll have to register your "campaign" with the > carrier or designated third party. This may even take the notion of a > template ("This call is about your recent order from {date}") that can be > auto-enforced. It's clear that carriers seem quite concerned about their > individual customers messaging, in volume, to their subscribers, given th= e > abuse. > > > > > > There is also potential for future of Subject/call-reason to be more than > just a text string. > > > > I suspect that's best handled separately, once we have a clearer use case= . > I don't think we can just stick this into call-reason without all kinds o= f > backwards-compatibility issues. > > > > > > I=E2=80=99m struggling a bit on your point that we should sign some data = but not > other data because it is less likely to be manipulated. Is that the bar = we > should be striving for here? Seems to conflict with my understanding of > some of the goals. > > > > Maybe this indicates that we should be clearer on the goals. My take on > the value of STIR "classic" (for TNs) is that the main purpose of signing > is to make it clear who is responsible for the information provided - thu= s, > the whole discussion of A/B/C attestation. Indeed, the experience seems t= o > indicate that C-level attestation is actually a signal for a robocall, > i.e,. C-level calls are *more* likely to be robocalls than unsigned calls= . > A/B/C obviously have the same cryptographic strength and all prevent > modification by third parties. > > > > I don't think that carrier manipulation of the caller information (except > in various normalization ways) has ever been a major problem - it's > originator (OSP or end user) spoofing. This is rather different than the > typical threat model where the originator worries about evil Mallory > changing their data, e.g., by redirecting a money transfer to them. > > > > But for call-purpose, this is less relevant - this is clearly (mostly) > useful if inserted by the originating caller, and unlike for A-level > attestation, the carrier can't really validate that the message is > truthful. How would it know that "You have won a cruise!" in the > call-purpose/Subject was correct or a scam? Indeed, as mentioned, if I we= re > a carrier, I'd never want to attest to that purpose, as somebody could > reasonably claim that the carrier should have known that the recipients > hadn't won anything. > > > > This is the main reason that I think this should be a separate claim - if > anybody should sign/attest this, it's the enterprise call center and only > that call center. > > > > > > Why not have the framework that we can do that. You are free to protect > or not protect data depending on your own policy. > > > > Nothing wrong as such. My argument is that RCD and call-purpose/Subject > are very different, so they shouldn't be in the *same* framework. If we > need Subject/call-purpose, they should be in separate claims, for the > operational reasons mentioned. > > > > > > I guess i want to be sure whether you are reacting to us not using Subjec= t > vs call-info as a common container for =E2=80=9Crich call data=E2=80=9D r= elated info or > that we have both call-info and =E2=80=98rcd=E2=80=99 as a container for = Rich Call Data > more generally? I think there is many reasons why we landed there, we ca= n > re-hash that in the context of call-info vs subject. I would be less > excited about re-hashing it for passport/rcd. > > > > For the reasons above, I think this is a bad idea for both cases, in > my view. It's worse for Call-Info, because of the duplication of existing > functionality. > > > > To use an analogy: The RCD is mostly like a business card. We don't > typically write our contracts and messages on business cards - we might > staple our business card to a note. > > > > My constructive suggestion is to create a separate claim if needed. (My > understanding is that rcd-14 does not contain the call purpose, so this i= s > the current state.) > > > > > > I do believe both of these frameworks need to be extensible, i don=E2=80= =99t think > we are finished. We can define more passport extensions, but at the same > time, do we want to redefine =E2=80=9Crcd=E2=80=9D and =E2=80=9Crcdi=E2= =80=9D for new passport extensions? > > > > No, we should create, in my view, a separate document that focuses on > signing the call purpose, expressed either as Subject (as the compact for= m) > or an explicit JWT claim, such as "subject". > > > > > > -Chris > > > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000ec17cb05dc7b286a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Depends on policy, but they could be passed thru to if nee= ded

Regards
Ranjit

On Tue, Apr 12, 2022= at 3:23 PM Gorman, Pierce <Pierce.Gorman@t-mobile.com> wrote:

I= assume Call-Info or Subject are likely to be stripped by SBCs.

=C2=A0

=C2=A0

From: stir <stir-bounces@ietf.org> On Behalf Of = Ben Campbell
Sent: Tuesday, April 12, 2022 3:18 PM
To: Chris Wendt <chris-ietf@chriswendt.net>
Cc: IETF STIR Mail List <stir@ietf.org>; SIPCORE <sipcore@ietf.org>; Henning Schulzrinne <= ;hgs@cs.columbia.e= du>
Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-r= eason)

=C2=A0

[External]=

=C2=A0

(as individual)

=C2=A0

(as individual)

=C2=A0

Apologies for coming to this thread late. =

=C2=A0

I agree we should keep the crn claim for =E2=80=9Crc= d=E2=80=9D passports at this point. I also understand there to be some impl= ementations that either use it or plan to use it..

=C2=A0

I don=E2=80=99t have a strong opinion on the Callinf= o param vs Subject question, as long as we have a consistent mapping. I gue= ss there is the question of whether SBCs will mess with either, but I don= =E2=80=99t know if that is more likely for one or the other.=C2=A0

=C2=A0

Thanks!

=C2=A0

Ben.



On Mar 20, 2022, at 10:47 AM, Chris Wendt <chris-ietf@chriswe= ndt.net> wrote:

=C2=A0

Hi Henning,

=C2=A0

Just to focus on call-reason for passport-rcd at the moment, we = do have that, it is an independent claim =E2=80=9Ccrn=E2=80=9D explicitly s= eparate from the =E2=80=9Crcd=E2=80=9D claim. It is defined in same passport-rcd document, but that doesn=E2=80=99t change how it=E2=80=99s de= fined or used. I think one hopefully simple fix is to maybe reference Subje= ct as a mapping for this claim and maybe point to callinfo-rcd in a more ge= neric way that we can further discuss subject vs callinfo in the sipcore draft as we move that forward.=C2=A0 As i understa= nd it, most implementations are focused on passport-rcd at the moment, so i= don=E2=80=99t want to hold that up if possible.

=C2=A0

To everyone,

=C2=A0

It would be great to get further input on this whether anyone ha= s strong feelings about using Subject vs callinfo parameter call-reason.=C2= =A0 I have the sense that there isn=E2=80=99t yet much implementation if any at all (of callinfo/call-reason, i believe = there is implementation of passport-rcd =E2=80=9Ccrn=E2=80=9D), and there w= on't strong feeling one way or the other, but if anyone does have stron= g feelings please speak up.

=C2=A0

-Chris



On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne <hgs@cs.columbia.edu> w= rote:

=C2=A0

Hi=C2=A0Chris,

=C2=A0

tl;dr: My suggestions are: (1) leave call purpose out of=C2=A0dr= aft-ietf-stir-passport-rcd; (2) drop call-purpose from=C2=A0draft-ietf-sipc= ore-call-info-rcd; (3) consider a new JWT claim "subject" [or whatever] that encapsulates the signed call = purpose in the future.

=C2=A0

More details inline below.

=C2=A0

On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <chris-ietf@chriswendt.net> wrote:

Hi Henning,

=C2=A0

I understand what you are saying.=C2=A0 I do however think there= is reasons to protect call-reason/Subject of call.=C2=A0 I think these sit= uations are mostly in the context of delegation to perhaps a call center, where you have authorized them to represent your= company in particular ways, including not only your identity, but for diff= erent context of calls that you have authorized them to represent you.=C2= =A0 We all know there is some call centers that use call identities with good reputation for customers that may explo= it that reputation for other customers.=C2=A0 I would look at this as simil= ar situation.

=C2=A0

I think we generally agree - your example of a call center is pr= obably, in my view, the most likely case where some indication of call purp= ose will be used, probably with explicit arrangement with the carrier. This may well turn out to be simila= r to the current model for SMS, where (in the US and some other countries) = you'll have to register your "campaign" with the carrier or d= esignated third party. This may even take the notion of a template ("This call is about your recent order from {dat= e}") that can be auto-enforced. It's clear that carriers seem quit= e concerned about their individual customers messaging, in volume, to their= subscribers, given the abuse.

=C2=A0

=C2=A0

There is also potential for future of Subject/call-reason to be = more than just a text string.

=C2=A0

I suspect that's best handled separately, once we have a cle= arer use case. I don't think we can just stick this into call-reason wi= thout all kinds of backwards-compatibility issues.=C2=A0

=C2=A0

=C2=A0

I=E2=80=99m struggling a bit on your point that we should sign s= ome data but not other data because it is less likely to be manipulated.=C2= =A0 Is that the bar we should be striving for here? Seems to conflict with my understanding of some of the goals.=

=C2=A0

Maybe this indicates that we should be clearer on the goals. My = take on the value of STIR "classic" (for TNs) is that the main pu= rpose of signing is to make it clear who is responsible for the information provided - thus, the whole discussion of A= /B/C attestation. Indeed, the experience seems to indicate that C-level att= estation is actually a signal for a robocall, i.e,. C-level calls are *more= * likely to be robocalls than unsigned calls. A/B/C obviously have the same cryptographic strength and all preven= t modification by third parties.

=C2=A0

I don't think that carrier manipulation of the caller inform= ation (except in various normalization ways) has ever been a major problem = - it's originator (OSP or end user) spoofing. This is rather different than the typical threat model where the= originator worries about evil Mallory changing their data, e.g., by redire= cting a money transfer to them.

=C2=A0

But for call-purpose, this is less relevant - this is clearly (m= ostly) useful if inserted by the originating caller, and unlike for A-level= attestation, the carrier can't really validate that the message is truthful. How would it know that "= ;You have won a cruise!" in the call-purpose/Subject was correct or a = scam? Indeed, as mentioned, if I were a carrier, I'd never want to atte= st to that purpose, as somebody could reasonably claim that the carrier should have known that the recipients hadn't wo= n anything.

=C2=A0

This is the main reason that I think this should be a separate= =C2=A0claim - if anybody should sign/attest this, it's the enterprise c= all center and only that call center.

=C2=A0

=C2=A0

Why not have the framework that we can do that.=C2=A0 You are fr= ee to protect or not protect data depending on your own policy.=C2=A0

=C2=A0

Nothing wrong as such. My argument is that RCD and call-purpose/= Subject are very different, so they shouldn't be in the *same* framewor= k. If we need Subject/call-purpose, they should be in separate claims, for the operational reasons mentioned.= =C2=A0

=C2=A0

=C2=A0

I guess i want to be sure whether you are reacting to us not usi= ng Subject vs call-info as a common container for =E2=80=9Crich call data= =E2=80=9D related info or that we have both call-info and =E2=80=98rcd=E2=80=99 as a container for Rich Call Data more generally= ?=C2=A0 I think there is many reasons why we landed there, we can re-hash t= hat in the context of call-info vs subject.=C2=A0 I would be less excited a= bout re-hashing it for passport/rcd.

=C2=A0

For the reasons above, I think this is a bad idea for both cases= ,=C2=A0in my=C2=A0view. It's worse for Call-Info, because of the duplic= ation of existing functionality.

=C2=A0

To use an analogy: The RCD is mostly like a business card. We do= n't typically write our contracts and messages on business cards - we m= ight staple our business card to a note.

=C2=A0

My constructive suggestion is to create a separate claim if need= ed. (My understanding is that rcd-14 does not contain the call purpose, so = this is the current state.)

=C2=A0

=C2=A0

I do believe both of these frameworks need to be extensible, i d= on=E2=80=99t think we are finished.=C2=A0 We can define more passport exten= sions, but at the same time, do we want to redefine =E2=80=9Crcd=E2=80=9D and =E2=80=9Crcdi=E2=80=9D for new passport extensio= ns?

=C2=A0

No, we should create, in my view, a separate document that focus= es on signing the call purpose, expressed either as Subject (as the compact= form) or an explicit JWT claim, such as "subject".

=C2=A0

=C2=A0

-Chris

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore=

=C2=A0

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000ec17cb05dc7b286a-- From nobody Tue Apr 12 14:00:39 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC8E3A12CA; Tue, 12 Apr 2022 13:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=zdiONXoE; dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=zdiONXoE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dYMn63fdWbX; Tue, 12 Apr 2022 13:59:36 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2071e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5a::71e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF183A12A0; Tue, 12 Apr 2022 13:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rjuNy+XuJ6wefMBJ3M1ZPOf22HD77TOlvxbDg5BSKtA=; b=zdiONXoE9R+44YLXwxLXLGyQcT2EWVYDMwG02Z4U8LmaOp7HjSuRMSjYtV4MPxSwi5LaOnuIhp86ymuHvwfwA+6H35UMGEcfVSvFIArkw2qtB9gtoo3TYVbPVZhVVTqQRDksDzH6NjTyMHVvyQUjo0FkypPHGJf+W0cw7OWmpbo= Received: from BN0PR04CA0020.namprd04.prod.outlook.com (2603:10b6:408:ee::25) by SA1PR02MB8462.namprd02.prod.outlook.com (2603:10b6:806:1f6::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.18; Tue, 12 Apr 2022 20:59:32 +0000 Received: from BN1NAM02FT044.eop-nam02.prod.protection.outlook.com (2603:10b6:408:ee:cafe::cb) by BN0PR04CA0020.outlook.office365.com (2603:10b6:408:ee::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29 via Frontend Transport; Tue, 12 Apr 2022 20:59:32 +0000 X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 144.49.247.5) smtp.mailfrom=t-mobile.com; dkim=pass (signature was verified) header.d=TMobileUSA.onmicrosoft.com;dmarc=fail action=none header.from=t-mobile.com; Received-SPF: Fail (protection.outlook.com: domain of t-mobile.com does not designate 144.49.247.5 as permitted sender) receiver=protection.outlook.com; client-ip=144.49.247.5; helo=mail.ds.dlp.protect.symantec.com; Received: from mail.ds.dlp.protect.symantec.com (144.49.247.5) by BN1NAM02FT044.mail.protection.outlook.com (10.13.2.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.21 via Frontend Transport; Tue, 12 Apr 2022 20:59:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eylmuhuMwjgNBG/NWYfVefyI+y4rcdveLfhYxi7QhQHQ8K2DtkS5Gk94yUNEJrVP7pI2k8vLguKSJ3YyVBLPrKIX3JYqaixwbdXswLoEt/IRQ+Gkg8St+5e7+xDGjhdYyk91Wz2sR2pS8kQint6Avul+zDi7flNCvO8TbhRyyHJYWdB7uxvf7Gid3XN5c8oLhQBMYgRcqFHtS0Df7WzqEHVwugJ8nJ++53BG8cSD7esSNYvmzWxyHT2mcHrLg/m/Ms1tL/3zDs4o+CCBz0B8gdt8FJ6lqEbwOnLO8dswHDVATUzAr74khr7yhpgs1yhA5LOE+Zn5D+FWxeVh/Io5AA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rjuNy+XuJ6wefMBJ3M1ZPOf22HD77TOlvxbDg5BSKtA=; b=MdTPJoMyDWwzTH4zz3NWcp7ANmbyXpLhm6uy+Y7dQJyYxTERINc2c+uOeKNiR5xuy7ODHwRQqwgOmF0LJE1IclIXaiiYpjBppUZ8jNjYB8NG08QOXCVtGVUHyVJHIBVsAkXPJBxHn+aPNZRaRb3wCoANInL3QFkEa481aN6MvLXHEkiRE4dbXjoPduakENTmZlNb6sx3e3DaIbhbNKeB8AZQn/evlKFn7rGN65UtYdz4sse4L1PzNjyd7GpGDdzGIXdZ4myFUKQFWr8WllIVT73QJkUn2AfhCOm3RnD8wIvMxUjRs1y8u3dc32n9NhFnIsGjmdq2ZzEy6/lEl7FHlw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=t-mobile.com; dmarc=pass action=none header.from=t-mobile.com; dkim=pass header.d=t-mobile.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rjuNy+XuJ6wefMBJ3M1ZPOf22HD77TOlvxbDg5BSKtA=; b=zdiONXoE9R+44YLXwxLXLGyQcT2EWVYDMwG02Z4U8LmaOp7HjSuRMSjYtV4MPxSwi5LaOnuIhp86ymuHvwfwA+6H35UMGEcfVSvFIArkw2qtB9gtoo3TYVbPVZhVVTqQRDksDzH6NjTyMHVvyQUjo0FkypPHGJf+W0cw7OWmpbo= Received: from BYAPR02MB4168.namprd02.prod.outlook.com (2603:10b6:a02:f4::11) by CY4PR02MB3175.namprd02.prod.outlook.com (2603:10b6:910:7f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Tue, 12 Apr 2022 20:59:29 +0000 Received: from BYAPR02MB4168.namprd02.prod.outlook.com ([fe80::d879:56a0:3a11:6f73]) by BYAPR02MB4168.namprd02.prod.outlook.com ([fe80::d879:56a0:3a11:6f73%3]) with mapi id 15.20.5144.029; Tue, 12 Apr 2022 20:59:29 +0000 From: "Gorman, Pierce" To: Ranjit Avasarala CC: Ben Campbell , Chris Wendt , IETF STIR Mail List , SIPCORE Thread-Topic: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-reason) Thread-Index: AQHYTq5xOr0BQdd/g02frIkAGlSD1Kzsv7pw Date: Tue, 12 Apr 2022 20:59:29 +0000 Message-ID: References: <86BE36F5-7CFE-48BE-B0A7-7458B67EB208@chriswendt.net> <51718867-9092-4423-B895-8069A8AF3D07@chriswendt.net> <28766342-130D-4FED-AD38-7A817D4B525B@chriswendt.net> <97AB0ACC-011C-48F8-826A-2E7238485D30@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=t-mobile.com; X-MS-Office365-Filtering-Correlation-Id: 92eebf0a-0950-4d14-1652-08da1cc757fc x-ms-traffictypediagnostic: CY4PR02MB3175:EE_|BN1NAM02FT044:EE_|SA1PR02MB8462:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: zSqNzqdXwXEK3ZiB+Wc/hct3cAW1ZgQIP7GJ92zVruCOsJSQ8Wi9OkpOu3cenD2A4F9M9Y7DellUJvTJ1jJgHmrpQCwyu79slZlU7nK5qJpnbcSzdEIUGs1mtKPSv5vQ45++iknaaSXAWry4Kls0cShn6iq6apk4FSGgU20wAikq0K+KHG8K3cD9Q+ycmunwauo9H8cOwZjC+zPlNPB0Bjs+SeYUxTWjx0L+T7YM6BHc80Y53NEoTCLj4osWSstKxKvGZaT5M5PDfcpDPxUwx/IT/2VK74s4TilMx2YoHDs/LbDJmIqUKWPXxIjxNW5AKwEofh0+arGeSnPAh4MGveJyaDoU+kHnIOn1n6zeZbjtjtORdjGlBx1RtOrStxFwAKvRB/Gb+ASc+KPju+l+B4iMRtVTj3UXFy4PY+nLkou/9xr+31WDAQ/5vfmrRYXtEy7vMS4A+1bkyaBkPC3AHriZp0sZZG17RhyShJNBJvZfaViBJoyZ/+4Bty3WUsSCJClyHaBAjHC+MIsGabKmsEo42/wFE2U6Qb6/jtOdQFRAV4832qoIr6SVFptctGmbeDkceYkkzmtrEvb0SAeQpK2PXfKy6AcTIxgYCtRtBNTFLPKgKs5gBFYhBRG0+xM+hZ8GDp25BXopPwxHbBobr6kVHqkwK1ufAUxZwpzXIzzSGj9cRH3qicfPxk74npJ/QGmV9vdY2E+E/J9vNGZD5Q0GlHPfUmY7NfF1NQDUqY4aAisKPccdr5f5+79+3uKHVF+W9ahvRJ4SkVwu0NEj6dg3kmQGlxjP6R9C7PGMvlc= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR02MB4168.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(66946007)(52536014)(7696005)(6506007)(122000001)(66556008)(33656002)(186003)(66476007)(55016003)(508600001)(166002)(54906003)(8936002)(6916009)(71200400001)(82960400001)(38100700002)(86362001)(64756008)(66446008)(83380400001)(26005)(966005)(53546011)(5660300002)(9686003)(2906002)(38070700005)(8676002)(4326008)(316002)(76116006); DIR:OUT; SFP:1102; Content-Type: multipart/alternative; boundary="_000_BYAPR02MB41682FF2EBB9E4139229DEF7D2ED9BYAPR02MB4168namp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR02MB3175 X-CFilter-Loop: Reflected X-DetectorID-Processed: 8c846453-0f50-46b3-95ab-8bbaf7238615 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: BN1NAM02FT044.eop-nam02.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: c549b9f0-9362-4d79-6caa-08da1cc75645 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jVwFBO60JaciHPJoEqEju1YPtX9pY9c9IyZoQAgHEDOeTmPvQokmBHqGWY1nNuFn/3kSkpWZeuYvKvW373CaeJP0xNWoWFKdvS248lLfqXQ9K6QS8YEu+seQ+Ylzf+sfUzJWt4DONphYIWFn3tk9Ohaz9094/qMg/qEsp0yxvxWaUt2aLY/efqgm/W1tl5iUatUSoOXI3caZ4NBVp3GUWW0tOGtJ8XkSjTWxhIhvMZT9BjjuTdNzkBs2hHRR1crHPLDvlQH453qkHp0zZXG3O34pthiEylPxeFIXpVQgcxXK1kRLhu7wN6OGFhNjzOA/8K48kFo838Vb09QlomOqF9u22q748o9Qchm3oXKwihmcKq2kJlqe1Lo7c4APr+uqpDoV0GjbSa25rK/vWiIOEEgJnDbgJeoHuswElWTD/6Okvb2UGGkhTiMM47u5rnV+LE/pMMGZ+GYVfExzgy20o9D0qJD6J0cJT598V8vIR3I8jR2ZmG8mCFRJb7befRWx4bK5n1O0En3zPza6/wLlQqfD4R3SoOqYcNRoVlXqS7l3G0yBsmxsI8zBck7+Ev+w+Z9848/f7Y7jqBz0ANpMSgCP5aAn2x3OC8smDng1x8RYlhjF6FkHJEeka2t+knlqKqRfRs3CNnAeYUfxUW/MJbFfjHvcF3DTWas9mxBdkLJYE98oSSz5jknRrkRyDM6Uqmp9oNXl+VKQe3c8XWQyMKMn2rbCNi/OqFhwEiznrgN96SbbOhb2QAz2RFYicVdgLirp1eJZOCv8RIqdZERrZbK+xWPP8+8HistXaOGJOxQ= X-Forefront-Antispam-Report: CIP:144.49.247.5; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.ds.dlp.protect.symantec.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230001)(4636009)(46966006)(40470700004)(36840700001)(86362001)(55016003)(47076005)(53546011)(36860700001)(186003)(26005)(4326008)(70586007)(316002)(9686003)(33656002)(8676002)(54906003)(336012)(70206006)(45080400002)(508600001)(966005)(82310400005)(7696005)(83380400001)(6506007)(6916009)(30864003)(5660300002)(8936002)(82960400001)(2906002)(40460700003)(52536014)(166002)(356005)(81166007)(36900700001)(579004); DIR:OUT; SFP:1102; X-OriginatorOrg: t-mobile.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2022 20:59:32.4211 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 92eebf0a-0950-4d14-1652-08da1cc757fc X-MS-Exchange-CrossTenant-Id: be0f980b-dd99-4b19-bd7b-bc71a09b026c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=be0f980b-dd99-4b19-bd7b-bc71a09b026c; Ip=[144.49.247.5]; Helo=[mail.ds.dlp.protect.symantec.com] X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT044.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR02MB8462 Archived-At: Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 20:59:42 -0000 --_000_BYAPR02MB41682FF2EBB9E4139229DEF7D2ED9BYAPR02MB4168namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Could be passed through, yes, but you'll need to define "if needed". The general policy for inbound SIP traffic of the service provider I was em= ployed by for more than 30 years, including in my role as lead SBC design e= ngineer, was to strip proprietary and non-essential SIP headers at the untr= usted interface of the SBC. Call-Info in particular would be in that categ= ory since it can include URLs which refer to goodness knows what. Ben said, "there is the question of whether SBCs will mess with either" (he= ader), and my opinion is he is right, there is a question, and my opinion i= s folks should assume, yes, those headers are at risk of being stripped (as= they most likely are today). From: Ranjit Avasarala Sent: Tuesday, April 12, 2022 3:47 PM To: Gorman, Pierce Cc: Ben Campbell ; Chris Wendt = ; IETF STIR Mail List ; SIPCORE Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-reason) [External] Depends on policy, but they could be passed thru to if needed Regards Ranjit On Tue, Apr 12, 2022 at 3:23 PM Gorman, Pierce > wrote: I assume Call-Info or Subject are likely to be stripped by SBCs. From: stir > On Behalf = Of Ben Campbell Sent: Tuesday, April 12, 2022 3:18 PM To: Chris Wendt > Cc: IETF STIR Mail List >; SIPCORE >; Henning Schulzrinne > Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) [External] (as individual) (as individual) Apologies for coming to this thread late. I agree we should keep the crn claim for "rcd" passports at this point. I a= lso understand there to be some implementations that either use it or plan = to use it.. I don't have a strong opinion on the Callinfo param vs Subject question, as= long as we have a consistent mapping. I guess there is the question of whe= ther SBCs will mess with either, but I don't know if that is more likely fo= r one or the other. Thanks! Ben. On Mar 20, 2022, at 10:47 AM, Chris Wendt > wrote: Hi Henning, Just to focus on call-reason for passport-rcd at the moment, we do have tha= t, it is an independent claim "crn" explicitly separate from the "rcd" clai= m. It is defined in same passport-rcd document, but that doesn't change how= it's defined or used. I think one hopefully simple fix is to maybe referen= ce Subject as a mapping for this claim and maybe point to callinfo-rcd in a= more generic way that we can further discuss subject vs callinfo in the si= pcore draft as we move that forward. As i understand it, most implementati= ons are focused on passport-rcd at the moment, so i don't want to hold that= up if possible. To everyone, It would be great to get further input on this whether anyone has strong fe= elings about using Subject vs callinfo parameter call-reason. I have the s= ense that there isn't yet much implementation if any at all (of callinfo/ca= ll-reason, i believe there is implementation of passport-rcd "crn"), and th= ere won't strong feeling one way or the other, but if anyone does have stro= ng feelings please speak up. -Chris On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne > wrote: Hi Chris, tl;dr: My suggestions are: (1) leave call purpose out of draft-ietf-stir-pa= ssport-rcd; (2) drop call-purpose from draft-ietf-sipcore-call-info-rcd; (3= ) consider a new JWT claim "subject" [or whatever] that encapsulates the si= gned call purpose in the future. More details inline below. On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt > wrote: Hi Henning, I understand what you are saying. I do however think there is reasons to p= rotect call-reason/Subject of call. I think these situations are mostly in= the context of delegation to perhaps a call center, where you have authori= zed them to represent your company in particular ways, including not only y= our identity, but for different context of calls that you have authorized t= hem to represent you. We all know there is some call centers that use call= identities with good reputation for customers that may exploit that reputa= tion for other customers. I would look at this as similar situation. I think we generally agree - your example of a call center is probably, in = my view, the most likely case where some indication of call purpose will be= used, probably with explicit arrangement with the carrier. This may well t= urn out to be similar to the current model for SMS, where (in the US and so= me other countries) you'll have to register your "campaign" with the carrie= r or designated third party. This may even take the notion of a template ("= This call is about your recent order from {date}") that can be auto-enforce= d. It's clear that carriers seem quite concerned about their individual cus= tomers messaging, in volume, to their subscribers, given the abuse. There is also potential for future of Subject/call-reason to be more than j= ust a text string. I suspect that's best handled separately, once we have a clearer use case. = I don't think we can just stick this into call-reason without all kinds of = backwards-compatibility issues. I'm struggling a bit on your point that we should sign some data but not ot= her data because it is less likely to be manipulated. Is that the bar we s= hould be striving for here? Seems to conflict with my understanding of some= of the goals. Maybe this indicates that we should be clearer on the goals. My take on the= value of STIR "classic" (for TNs) is that the main purpose of signing is t= o make it clear who is responsible for the information provided - thus, the= whole discussion of A/B/C attestation. Indeed, the experience seems to ind= icate that C-level attestation is actually a signal for a robocall, i.e,. C= -level calls are *more* likely to be robocalls than unsigned calls. A/B/C o= bviously have the same cryptographic strength and all prevent modification = by third parties. I don't think that carrier manipulation of the caller information (except i= n various normalization ways) has ever been a major problem - it's originat= or (OSP or end user) spoofing. This is rather different than the typical th= reat model where the originator worries about evil Mallory changing their d= ata, e.g., by redirecting a money transfer to them. But for call-purpose, this is less relevant - this is clearly (mostly) usef= ul if inserted by the originating caller, and unlike for A-level attestatio= n, the carrier can't really validate that the message is truthful. How woul= d it know that "You have won a cruise!" in the call-purpose/Subject was cor= rect or a scam? Indeed, as mentioned, if I were a carrier, I'd never want t= o attest to that purpose, as somebody could reasonably claim that the carri= er should have known that the recipients hadn't won anything. This is the main reason that I think this should be a separate claim - if a= nybody should sign/attest this, it's the enterprise call center and only th= at call center. Why not have the framework that we can do that. You are free to protect or= not protect data depending on your own policy. Nothing wrong as such. My argument is that RCD and call-purpose/Subject are= very different, so they shouldn't be in the *same* framework. If we need S= ubject/call-purpose, they should be in separate claims, for the operational= reasons mentioned. I guess i want to be sure whether you are reacting to us not using Subject = vs call-info as a common container for "rich call data" related info or tha= t we have both call-info and 'rcd' as a container for Rich Call Data more g= enerally? I think there is many reasons why we landed there, we can re-has= h that in the context of call-info vs subject. I would be less excited abo= ut re-hashing it for passport/rcd. For the reasons above, I think this is a bad idea for both cases, in my vie= w. It's worse for Call-Info, because of the duplication of existing functio= nality. To use an analogy: The RCD is mostly like a business card. We don't typical= ly write our contracts and messages on business cards - we might staple our= business card to a note. My constructive suggestion is to create a separate claim if needed. (My und= erstanding is that rcd-14 does not contain the call purpose, so this is the= current state.) I do believe both of these frameworks need to be extensible, i don't think = we are finished. We can define more passport extensions, but at the same t= ime, do we want to redefine "rcd" and "rcdi" for new passport extensions? No, we should create, in my view, a separate document that focuses on signi= ng the call purpose, expressed either as Subject (as the compact form) or a= n explicit JWT claim, such as "subject". -Chris _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_BYAPR02MB41682FF2EBB9E4139229DEF7D2ED9BYAPR02MB4168namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Could be passe= d through, yes, but you’ll need to define “if needed”.

 

The general policy for inbound SIP traffic of the service provider I was= employed by for more than 30 years, including in my role as lead SBC design engineer, was to strip proprietary and non-esse= ntial SIP headers at the untrusted interface of the SBC.  Call-Info in= particular would be in that category since it can include URLs which refer= to goodness knows what.

 

Ben said, “there is the question of whether SBCs will mess = with either&#= 8221; (header), and my opinion is he is right, there is a question, and my opini= on is folks should assume, yes, those headers are at risk of being stripped= (as they most likely are today).

 

 

From: Ranjit Avasarala <ranjitkav12@gmail.= com>
Sent: Tuesday, April 12, 2022 3:47 PM
To: Gorman, Pierce <Pierce.Gorman@t-mobile.com>
Cc: Ben Campbell <ben@nostrum.com>; Chris Wendt <chris-ietf= @chriswendt.net>; IETF STIR Mail List <stir@ietf.org>; SIPCORE <= ;sipcore@ietf.org>
Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-r= eason)

 

<= span style=3D"font-size:10.0pt;color:#9C6500">[External]

 

Depends on policy, but they could be passed thru to = if needed

 

Regards

Ranjit

 

On Tue, Apr 12, 2022 at 3:23 PM Gorman, Pierce <<= a href=3D"mailto:Pierce.Gorman@t-mobile.com">Pierce.Gorman@t-mobile.com= > wrote:

I assu= me Call-Info or Subject are likely to be stripped by SBCs.

 

 

From: stir <stir-bounces@ietf.org> On Behalf Of Ben Campbell
Sent: Tuesday, April 12, 2022 3:18 PM
To: Chris Wendt <chris-ietf@chriswendt.net>
Cc: IETF STIR Mail List <stir@ietf.org>; SIPCORE <sipcore@ietf.org>; Henning Schulzrinne <= ;hgs@cs.columbia.e= du>
Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-r= eason)

 

[External]

 

(as individual)

 

(as individual)

 

Apologies for coming to this thread late.

 

I agree we should keep the crn claim for “rcd” passpor= ts at this point. I also understand there to be some implementations that e= ither use it or plan to use it..

 

I don’t have a strong opinion on the Callinfo param vs Subje= ct question, as long as we have a consistent mapping. I guess there is the = question of whether SBCs will mess with either, but I don’t know if that is more likely for one or the other. <= o:p>

 

Thanks!

 

Ben.

 

On Mar 20, 2022, at 10:47 AM, Chris Wendt <chris-ietf@chriswendt.net>= ; wrote:

 

Hi Henning,

 

Just to focus on call-reason for passport-rcd at the moment, we = do have that, it is an independent claim “crn” explicitly separate from the “rcd” claim. It is defined in same passport-= rcd document, but that doesn’t change how it’s defined or used.= I think one hopefully simple fix is to maybe reference Subject as a mappin= g for this claim and maybe point to callinfo-rcd in a more generic way that we can further discuss subject vs callinfo in the sipcore= draft as we move that forward.  As i understand it, most implementati= ons are focused on passport-rcd at the moment, so i don’t want to hol= d that up if possible.

 

To everyone,

 

It would be great to get further input on this whether anyone ha= s strong feelings about using Subject vs callinfo parameter call-reason.  I have the sense that there isn’t yet m= uch implementation if any at all (of callinfo/call-reason, i believe there = is implementation of passport-rcd “crn”), and there won't stron= g feeling one way or the other, but if anyone does have strong feelings please speak up.

 

-Chris

 

On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:

 

Hi Chris,

 

tl;dr: My suggestions are: (1) leave call purpose out of dr= aft-ietf-stir-passport-rcd; (2) drop call-purpose from draft-ietf-sipc= ore-call-info-rcd; (3) consider a new JWT claim "subject" [or whatever] that encaps= ulates the signed call purpose in the future.

 

More details inline below.

 

On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <chris-ietf@chriswendt.net> wrote:

Hi Henning,

 

I understand what you are saying.  I do however think there= is reasons to protect call-reason/Subject of call.  I think these situations are mostly in the context of delegation to perhap= s a call center, where you have authorized them to represent your company i= n particular ways, including not only your identity, but for different cont= ext of calls that you have authorized them to represent you.  We all know there is some call centers that u= se call identities with good reputation for customers that may exploit that= reputation for other customers.  I would look at this as similar situ= ation.

 

I think we generally agree - your example of a call center is pr= obably, in my view, the most likely case where some indication of call purpose will be used, probably with explicit arrangemen= t with the carrier. This may well turn out to be similar to the current mod= el for SMS, where (in the US and some other countries) you'll have to regis= ter your "campaign" with the carrier or designated third party. This may even take the notion of a template (&q= uot;This call is about your recent order from {date}") that can be aut= o-enforced. It's clear that carriers seem quite concerned about their indiv= idual customers messaging, in volume, to their subscribers, given the abuse.

 

 

There is also potential for future of Subject/call-reason to be = more than just a text string.

 

I suspect that's best handled separately, once we have a clearer= use case. I don't think we can just stick this into call-reason without all kinds of backwards-compatibility issues. = ;

 

 

I’m struggling a bit on your point that we should sign som= e data but not other data because it is less likely to be manipulated.  Is that the bar we should be striving for here? Seem= s to conflict with my understanding of some of the goals.=

 

Maybe this indicates that we should be clearer on the goals. My = take on the value of STIR "classic" (for TNs) is that the main purpose of signing is to make it clear who is responsible fo= r the information provided - thus, the whole discussion of A/B/C attestatio= n. Indeed, the experience seems to indicate that C-level attestation is act= ually a signal for a robocall, i.e,. C-level calls are *more* likely to be robocalls than unsigned calls. A/B/C= obviously have the same cryptographic strength and all prevent modificatio= n by third parties.

 

I don't think that carrier manipulation of the caller informatio= n (except in various normalization ways) has ever been a major problem - it's originator (OSP or end user) spoofing. This is= rather different than the typical threat model where the originator worrie= s about evil Mallory changing their data, e.g., by redirecting a money tran= sfer to them.

 

But for call-purpose, this is less relevant - this is clearly (m= ostly) useful if inserted by the originating caller, and unlike for A-level attestation, the carrier can't really validate that= the message is truthful. How would it know that "You have won a cruis= e!" in the call-purpose/Subject was correct or a scam? Indeed, as ment= ioned, if I were a carrier, I'd never want to attest to that purpose, as somebody could reasonably claim that the car= rier should have known that the recipients hadn't won anything.=

 

This is the main reason that I think this should be a separate&n= bsp;claim - if anybody should sign/attest this, it's the enterprise call center and only that call center.

 

 

Why not have the framework that we can do that.  You are fr= ee to protect or not protect data depending on your own policy. 

 

Nothing wrong as such. My argument is that RCD and call-purpose/= Subject are very different, so they shouldn't be in the *same* framework. If we need Subject/call-purpose, they should be i= n separate claims, for the operational reasons mentioned. =

 

 

I guess i want to be sure whether you are reacting to us not usi= ng Subject vs call-info as a common container for “rich call data” related info or that we have both call-info a= nd ‘rcd’ as a container for Rich Call Data more generally? = ; I think there is many reasons why we landed there, we can re-hash that in= the context of call-info vs subject.  I would be less excited about re-hashing it for passport/rcd.

 

For the reasons above, I think this is a bad idea for both cases= , in my view. It's worse for Call-Info, because of the duplication of existing functionality.

 

To use an analogy: The RCD is mostly like a business card. We do= n't typically write our contracts and messages on business cards - we might staple our business card to a note.<= /o:p>

 

My constructive suggestion is to create a separate claim if need= ed. (My understanding is that rcd-14 does not contain the call purpose, so this is the current state.)

 

 

I do believe both of these frameworks need to be extensible, i d= on’t think we are finished.  We can define more passport extensions, but at the same time, do we want to redefine “r= cd” and “rcdi” for new passport extensions?

 

No, we should create, in my view, a separate document that focus= es on signing the call purpose, expressed either as Subject (as the compact form) or an explicit JWT claim, such as "s= ubject".

 

 

-Chris

 

 

 

_______________________________________________
sipcore mailing list
sipcore@ietf= .org
https://www.ietf.org/mailman/listinfo/sipcore

 

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore=

--_000_BYAPR02MB41682FF2EBB9E4139229DEF7D2ED9BYAPR02MB4168namp_-- From nobody Wed Apr 13 09:00:16 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BDA3A1131 for ; Wed, 13 Apr 2022 09:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh7S1QFYi7qE for ; Wed, 13 Apr 2022 09:00:08 -0700 (PDT) Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221163A1135 for ; Wed, 13 Apr 2022 09:00:08 -0700 (PDT) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 2F797163AC4 for ; Wed, 13 Apr 2022 12:00:07 -0400 (EDT) Received: from [10.0.1.3] (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 24FAA163598 for ; Wed, 13 Apr 2022 12:00:07 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Wed, 13 Apr 2022 12:00:06 -0400 References: <164971368339.27063.16920313800107401744@ietfa.amsl.com> To: IETF STIR Mail List In-Reply-To: <164971368339.27063.16920313800107401744@ietfa.amsl.com> Message-Id: <509AB426-9E98-4A47-92CB-FB7C446AF3ED@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [stir] Secure Telephone Identity Revisited (stir) WG Virtual Meeting: 2022-04-22 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 16:00:14 -0000 Some of the drafts on the agenda have not been posted yet... However, = here is the DRAFT agenda. Russ (for the STIR WG chairs) =3D =3D =3D =3D =3D =3D =3D STIR Working Group at Virtual Interim in 22 April 2022 1) Administrivia - Agenda Bashing - Minute Taker 2) PASSporT Extension for Rich Call Data - Chris Wendt and Jon Peterson - draft-ietf-stir-passport-rcd-15 - Resolve open issues from WG Last Call 3) Connected Identity for STIR - Jon Peterson and Chris Wendt - draft-ietf-stir-rfc4916-update-00 - Discuss open issues; get ready for WG Last Call 4) Identity Header Error Handling - Chris Wendt - draft-ietf-stir-identity-header-errors-handling-00 - Discuss open issues; get ready for WG Last Call 5) Out-of-Band STIR for Service Providers - Jon Peterson - draft-ietf-stir-servprovider-oob-02 - Discuss open issues; get ready for WG Last Call 6) STIR for Messaging - Chris Wendt and Jon Peterson - draft-ietf-stir-messaging-01 - Discuss open issues; get ready for WG Last Call 7) Any Other Business (if time permits) > On Apr 11, 2022, at 5:48 PM, IESG Secretary = wrote: >=20 > The Secure Telephone Identity Revisited (stir) WG will hold > a virtual interim meeting on 2022-04-22 from 10:00 to 12:00 = America/New_York (14:00 to 16:00 UTC). >=20 > Agenda: > Agenda TBA on STIR mail list >=20 > Information about remote participation: > = https://meetings.conf.meetecho.com/interim/?short=3Daa0d3d42-863f-4e0d-ac3= 0-54914401d828 From nobody Wed Apr 13 14:01:05 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44B13A0D0E; Wed, 13 Apr 2022 14:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9BsnneGeVid; Wed, 13 Apr 2022 14:00:31 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84AEA3A0CF3; Wed, 13 Apr 2022 14:00:30 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id t11so6349741eju.13; Wed, 13 Apr 2022 14:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CNfsPRCnQ54CBKM75BCOnNyxAZnYsWGsEGAsxu+X1FY=; b=kPWPZF+i+wQ1HFBD1/NhPSaZN/BC/mXQTHS/Jk/WdFAH1DFbO0WphufURU1Gzj6NnP G878+qD+GtKxFTCICQUuTIcsev8wBIfAIsvXvtAhfPO8v6QT1/2vgytMSN3i9CARPuUl AuaGJJb9wQf/OfCOwQLnIwWHS6pS9c4kd4wpwt/jRyZUHCylAdbLf3++oe4QlRn2l5cB conYintt79khK/eKxmxfVKFdcDoT7b4n050l/HwaJv+vKKLGRhAP+3nknPY2Zhha9eb2 SA2hIf80pchIh7rjrWiOAu9of2J3grI34uRkWcSrVWd6moB5EwXtTM6E29tnlgXt3imG /+zw== 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=CNfsPRCnQ54CBKM75BCOnNyxAZnYsWGsEGAsxu+X1FY=; b=f0eSD6NwRLVRDsBOx22g0HUvHRd2nZjj/y9TlhwOrQXWNmcoZnUg0pR53ADZTUjlnD E6yR2QXpgzT3XKQrfNK8MGke9DkWYXZRIHncC/gcwxHwkE8ddQ8f0YgLk5/kd/yTGQJB yeXpA/ow0t61u0QbKBTV+mKPopjOSdCZpls+R9wO4G3tX3Fpw6Fw/leMV9YzFP6ruE6a ZQ7p5ZAKeT9ZKqPMWzBYwYWwESL1sHDKCZoOK1yIv4Iu+HBzOpuXhlJH77UaGaD6M4kM LcJZ0c7pJdYTPZ1ex1EB7ZwWnVEt9rqJsalYO0bQcCQmfErmZK+L47Zj1W6AEpNNDjrx /EfQ== X-Gm-Message-State: AOAM533+IVY+mYDNK+Le8clyoXjlSGXz0HW1dERyEMKFG6CAoaWG9zu1 RDCxHWWBSsdpfBvQNwB6Nut7nq3tnIrUnp92GnSKRP6U X-Google-Smtp-Source: ABdhPJw8CUtOTnyRWl92XlDHfqOT2Aa7wNgYjH8Y3hk1QZaf/+QPBtqPWUxfJ/E86zUkYNNaiOWmt0a6Fgx8NIwhnh0= X-Received: by 2002:a17:906:d055:b0:6e8:6cc1:124c with SMTP id bo21-20020a170906d05500b006e86cc1124cmr21789522ejb.758.1649883628395; Wed, 13 Apr 2022 14:00:28 -0700 (PDT) MIME-Version: 1.0 References: <86BE36F5-7CFE-48BE-B0A7-7458B67EB208@chriswendt.net> <51718867-9092-4423-B895-8069A8AF3D07@chriswendt.net> <28766342-130D-4FED-AD38-7A817D4B525B@chriswendt.net> <97AB0ACC-011C-48F8-826A-2E7238485D30@nostrum.com> In-Reply-To: From: Ranjit Avasarala Date: Wed, 13 Apr 2022 16:00:16 -0500 Message-ID: To: "Gorman, Pierce" Cc: Ben Campbell , Chris Wendt , IETF STIR Mail List , SIPCORE Content-Type: multipart/alternative; boundary="000000000000980c8405dc8f77d2" Archived-At: Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 21:00:36 -0000 --000000000000980c8405dc8f77d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pierce Yes I do agree that SBC could strip the call-info header and not pass it through. But in case the information contained in that header is needed downstream like by CSCF, then SBC could map the contents of the Call-Info header to a new Private header and send it across. Regards Ranjit On Tue, Apr 12, 2022 at 3:59 PM Gorman, Pierce wrote: > Could be passed through, yes, but you=E2=80=99ll need to define =E2=80=9C= if needed=E2=80=9D. > > > > The general policy for inbound SIP traffic of the service provider I was > employed by for more than 30 years, including in my role as lead SBC desi= gn > engineer, was to strip proprietary and non-essential SIP headers at the > untrusted interface of the SBC. Call-Info in particular would be in that > category since it can include URLs which refer to goodness knows what. > > > > Ben said, =E2=80=9Cthere is the question of whether SBCs will mess with e= ither=E2=80=9D > (header), and my opinion is he is right, there is a question, and my > opinion is folks should assume, yes, those headers are at risk of being > stripped (as they most likely are today). > > > > > > *From:* Ranjit Avasarala > *Sent:* Tuesday, April 12, 2022 3:47 PM > *To:* Gorman, Pierce > *Cc:* Ben Campbell ; Chris Wendt < > chris-ietf@chriswendt.net>; IETF STIR Mail List ; SIPCORE = < > sipcore@ietf.org> > *Subject:* Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 > (call-reason) > > > > *[External]* > > > > Depends on policy, but they could be passed thru to if needed > > > > Regards > > Ranjit > > > > On Tue, Apr 12, 2022 at 3:23 PM Gorman, Pierce > wrote: > > I assume Call-Info or Subject are likely to be stripped by SBCs. > > > > > > *From:* stir *On Behalf Of *Ben Campbell > *Sent:* Tuesday, April 12, 2022 3:18 PM > *To:* Chris Wendt > *Cc:* IETF STIR Mail List ; SIPCORE ; > Henning Schulzrinne > *Subject:* Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 > (call-reason) > > > > *[External]* > > > > (as individual) > > > > (as individual) > > > > Apologies for coming to this thread late. > > > > I agree we should keep the crn claim for =E2=80=9Crcd=E2=80=9D passports = at this point. I > also understand there to be some implementations that either use it or pl= an > to use it.. > > > > I don=E2=80=99t have a strong opinion on the Callinfo param vs Subject qu= estion, > as long as we have a consistent mapping. I guess there is the question of > whether SBCs will mess with either, but I don=E2=80=99t know if that is m= ore likely > for one or the other. > > > > Thanks! > > > > Ben. > > > > On Mar 20, 2022, at 10:47 AM, Chris Wendt > wrote: > > > > Hi Henning, > > > > Just to focus on call-reason for passport-rcd at the moment, we do have > that, it is an independent claim =E2=80=9Ccrn=E2=80=9D explicitly separat= e from the =E2=80=9Crcd=E2=80=9D > claim. It is defined in same passport-rcd document, but that doesn=E2=80= =99t change > how it=E2=80=99s defined or used. I think one hopefully simple fix is to = maybe > reference Subject as a mapping for this claim and maybe point to > callinfo-rcd in a more generic way that we can further discuss subject vs > callinfo in the sipcore draft as we move that forward. As i understand i= t, > most implementations are focused on passport-rcd at the moment, so i don= =E2=80=99t > want to hold that up if possible. > > > > To everyone, > > > > It would be great to get further input on this whether anyone has strong > feelings about using Subject vs callinfo parameter call-reason. I have t= he > sense that there isn=E2=80=99t yet much implementation if any at all (of > callinfo/call-reason, i believe there is implementation of passport-rcd > =E2=80=9Ccrn=E2=80=9D), and there won't strong feeling one way or the oth= er, but if anyone > does have strong feelings please speak up. > > > > -Chris > > > > On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne > wrote: > > > > Hi Chris, > > > > tl;dr: My suggestions are: (1) leave call purpose out > of draft-ietf-stir-passport-rcd; (2) drop call-purpose > from draft-ietf-sipcore-call-info-rcd; (3) consider a new JWT claim > "subject" [or whatever] that encapsulates the signed call purpose in the > future. > > > > More details inline below. > > > > On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt > wrote: > > Hi Henning, > > > > I understand what you are saying. I do however think there is reasons to > protect call-reason/Subject of call. I think these situations are mostly > in the context of delegation to perhaps a call center, where you have > authorized them to represent your company in particular ways, including n= ot > only your identity, but for different context of calls that you have > authorized them to represent you. We all know there is some call centers > that use call identities with good reputation for customers that may > exploit that reputation for other customers. I would look at this as > similar situation. > > > > I think we generally agree - your example of a call center is probably, i= n > my view, the most likely case where some indication of call purpose will = be > used, probably with explicit arrangement with the carrier. This may well > turn out to be similar to the current model for SMS, where (in the US and > some other countries) you'll have to register your "campaign" with the > carrier or designated third party. This may even take the notion of a > template ("This call is about your recent order from {date}") that can be > auto-enforced. It's clear that carriers seem quite concerned about their > individual customers messaging, in volume, to their subscribers, given th= e > abuse. > > > > > > There is also potential for future of Subject/call-reason to be more than > just a text string. > > > > I suspect that's best handled separately, once we have a clearer use case= . > I don't think we can just stick this into call-reason without all kinds o= f > backwards-compatibility issues. > > > > > > I=E2=80=99m struggling a bit on your point that we should sign some data = but not > other data because it is less likely to be manipulated. Is that the bar = we > should be striving for here? Seems to conflict with my understanding of > some of the goals. > > > > Maybe this indicates that we should be clearer on the goals. My take on > the value of STIR "classic" (for TNs) is that the main purpose of signing > is to make it clear who is responsible for the information provided - thu= s, > the whole discussion of A/B/C attestation. Indeed, the experience seems t= o > indicate that C-level attestation is actually a signal for a robocall, > i.e,. C-level calls are *more* likely to be robocalls than unsigned calls= . > A/B/C obviously have the same cryptographic strength and all prevent > modification by third parties. > > > > I don't think that carrier manipulation of the caller information (except > in various normalization ways) has ever been a major problem - it's > originator (OSP or end user) spoofing. This is rather different than the > typical threat model where the originator worries about evil Mallory > changing their data, e.g., by redirecting a money transfer to them. > > > > But for call-purpose, this is less relevant - this is clearly (mostly) > useful if inserted by the originating caller, and unlike for A-level > attestation, the carrier can't really validate that the message is > truthful. How would it know that "You have won a cruise!" in the > call-purpose/Subject was correct or a scam? Indeed, as mentioned, if I we= re > a carrier, I'd never want to attest to that purpose, as somebody could > reasonably claim that the carrier should have known that the recipients > hadn't won anything. > > > > This is the main reason that I think this should be a separate claim - if > anybody should sign/attest this, it's the enterprise call center and only > that call center. > > > > > > Why not have the framework that we can do that. You are free to protect > or not protect data depending on your own policy. > > > > Nothing wrong as such. My argument is that RCD and call-purpose/Subject > are very different, so they shouldn't be in the *same* framework. If we > need Subject/call-purpose, they should be in separate claims, for the > operational reasons mentioned. > > > > > > I guess i want to be sure whether you are reacting to us not using Subjec= t > vs call-info as a common container for =E2=80=9Crich call data=E2=80=9D r= elated info or > that we have both call-info and =E2=80=98rcd=E2=80=99 as a container for = Rich Call Data > more generally? I think there is many reasons why we landed there, we ca= n > re-hash that in the context of call-info vs subject. I would be less > excited about re-hashing it for passport/rcd. > > > > For the reasons above, I think this is a bad idea for both cases, in > my view. It's worse for Call-Info, because of the duplication of existing > functionality. > > > > To use an analogy: The RCD is mostly like a business card. We don't > typically write our contracts and messages on business cards - we might > staple our business card to a note. > > > > My constructive suggestion is to create a separate claim if needed. (My > understanding is that rcd-14 does not contain the call purpose, so this i= s > the current state.) > > > > > > I do believe both of these frameworks need to be extensible, i don=E2=80= =99t think > we are finished. We can define more passport extensions, but at the same > time, do we want to redefine =E2=80=9Crcd=E2=80=9D and =E2=80=9Crcdi=E2= =80=9D for new passport extensions? > > > > No, we should create, in my view, a separate document that focuses on > signing the call purpose, expressed either as Subject (as the compact for= m) > or an explicit JWT claim, such as "subject". > > > > > > -Chris > > > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --000000000000980c8405dc8f77d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Pierce

Yes I do agree that SBC could= strip the call-info header and not pass it through. But in case the inform= ation contained in that header is needed downstream like by CSCF, then SBC = could map the contents of the Call-Info header to a new Private header and = send it across.

Regards
Ranjit

On T= ue, Apr 12, 2022 at 3:59 PM Gorman, Pierce <Pierce.Gorman@t-mobile.com> wrote:

= Could be passed through, yes, but you=E2=80=99ll need to define =E2=80=9Cif= needed=E2=80=9D.

=C2=A0

The general policy for inbound SIP traffic= of the service provider I was employed by for more than 30 years, includin= g in my role as lead SBC design engineer, was to strip proprietary and non-esse= ntial SIP headers at the untrusted interface of the SBC.=C2=A0 Call-Info in= particular would be in that category since it can include URLs which refer= to goodness knows what.

=C2=A0

Ben said, =E2=80=9Cthere is the que= stion of whether SBCs will mess with either=E2=80=9D (header), and my opinion is he is right, there is a question, and my opini= on is folks should assume, yes, those headers are at risk of being stripped= (as they most likely are today).

=C2=A0<= /u>

=C2=A0

From: Ranjit Avasarala <ranjitkav12@gmail.com>
Sent: Tuesday, April 12, 2022 3:47 PM
To: Gorman, Pierce <Pierce.Gorman@t-mobile.com>
Cc: Ben Campbell <ben@nostrum.com>; Chris Wendt <chris-ietf@chriswendt.net>; IETF = STIR Mail List <stir@= ietf.org>; SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-r= eason)

=C2=A0

[External]=

=C2=A0

Depends on policy, but they could be passed thru to = if needed

=C2=A0

Regards

Ranjit

=C2=A0

On Tue, Apr 12, 2022 at 3:23 PM Gorman, Pierce <<= a href=3D"mailto:Pierce.Gorman@t-mobile.com" target=3D"_blank">Pierce.Gorma= n@t-mobile.com> wrote:

I assume Call-Info or Subject are likely to be stripp= ed by SBCs.

=C2=A0

=C2=A0

From: stir <stir-bounces@ietf.org> On Behalf Of Ben Campbell
Sent: Tuesday, April 12, 2022 3:18 PM
To: Chris Wendt <chris-ietf@chriswendt.net>
Cc: IETF STIR Mail List <stir@ietf.org>; SIPCORE <sipcore@ietf.org>; Henning Schulzrinne <= ;hgs@cs.columbia.e= du>
Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-r= eason)

=C2=A0

[External]

=C2=A0

(as individual)

=C2=A0

(as individual)

=C2=A0

Apologies for coming to this thread late.

=C2=A0

I agree we should keep the crn claim for =E2=80=9Crc= d=E2=80=9D passports at this point. I also understand there to be some impl= ementations that either use it or plan to use it..

=C2=A0

I don=E2=80=99t have a strong opinion on the Callinf= o param vs Subject question, as long as we have a consistent mapping. I gue= ss there is the question of whether SBCs will mess with either, but I don=E2=80=99t know if that is more likely for one or the other.=C2= =A0

=C2=A0

Thanks!

=C2=A0

Ben.

=C2=A0

On Mar 20, 2022, at 10:47 AM, Chris Wendt <chris-ietf@chriswe= ndt.net> wrote:

=C2=A0

Hi Henning,

=C2=A0

Just to focus on call-reason for passport-rcd at the moment, we = do have that, it is an independent claim =E2=80=9Ccrn=E2=80=9D explicitly separate from the =E2=80=9Crcd=E2=80=9D claim. It is defined in same passp= ort-rcd document, but that doesn=E2=80=99t change how it=E2=80=99s defined = or used. I think one hopefully simple fix is to maybe reference Subject as = a mapping for this claim and maybe point to callinfo-rcd in a more generic way that we can further discuss subject vs callinfo in the sipcore= draft as we move that forward.=C2=A0 As i understand it, most implementati= ons are focused on passport-rcd at the moment, so i don=E2=80=99t want to h= old that up if possible.

=C2=A0

To everyone,

=C2=A0

It would be great to get further input on this whether anyone ha= s strong feelings about using Subject vs callinfo parameter call-reason.=C2=A0 I have the sense that there isn=E2=80=99t yet= much implementation if any at all (of callinfo/call-reason, i believe ther= e is implementation of passport-rcd =E2=80=9Ccrn=E2=80=9D), and there won&#= 39;t strong feeling one way or the other, but if anyone does have strong feelings please speak up.

=C2=A0

-Chris

=C2=A0

On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:

=C2=A0

Hi=C2=A0Chris,

=C2=A0

tl;dr: My suggestions are: (1) leave call purpose out of=C2=A0dr= aft-ietf-stir-passport-rcd; (2) drop call-purpose from=C2=A0draft-ietf-sipc= ore-call-info-rcd; (3) consider a new JWT claim "subject" [or whatever] that encaps= ulates the signed call purpose in the future.

=C2=A0

More details inline below.

=C2=A0

On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <chris-ietf@chriswendt.net> wrote:

Hi Henning,

=C2=A0

I understand what you are saying.=C2=A0 I do however think there= is reasons to protect call-reason/Subject of call.=C2=A0 I think these situations are mostly in the context of delegation to perhap= s a call center, where you have authorized them to represent your company i= n particular ways, including not only your identity, but for different cont= ext of calls that you have authorized them to represent you.=C2=A0 We all know there is some call centers that u= se call identities with good reputation for customers that may exploit that= reputation for other customers.=C2=A0 I would look at this as similar situ= ation.

=C2=A0

I think we generally agree - your example of a call center is pr= obably, in my view, the most likely case where some indication of call purpose will be used, probably with explicit arrangemen= t with the carrier. This may well turn out to be similar to the current mod= el for SMS, where (in the US and some other countries) you'll have to r= egister your "campaign" with the carrier or designated third party. This may even take the notion of a template (&q= uot;This call is about your recent order from {date}") that can be aut= o-enforced. It's clear that carriers seem quite concerned about their i= ndividual customers messaging, in volume, to their subscribers, given the abuse.

=C2=A0

=C2=A0

There is also potential for future of Subject/call-reason to be = more than just a text string.

=C2=A0

I suspect that's best handled separately, once we have a cle= arer use case. I don't think we can just stick this into call-reason without all kinds of backwards-compatibility issues.=C2= =A0

=C2=A0

=C2=A0

I=E2=80=99m struggling a bit on your point that we should sign s= ome data but not other data because it is less likely to be manipulated.=C2=A0 Is that the bar we should be striving for here? Seem= s to conflict with my understanding of some of the goals.<= /u>

=C2=A0

Maybe this indicates that we should be clearer on the goals. My = take on the value of STIR "classic" (for TNs) is that the main purpose of signing is to make it clear who is responsible fo= r the information provided - thus, the whole discussion of A/B/C attestatio= n. Indeed, the experience seems to indicate that C-level attestation is act= ually a signal for a robocall, i.e,. C-level calls are *more* likely to be robocalls than unsigned calls. A/B/C= obviously have the same cryptographic strength and all prevent modificatio= n by third parties.

=C2=A0

I don't think that carrier manipulation of the caller inform= ation (except in various normalization ways) has ever been a major problem - it's originator (OSP or end user) spoofing. Thi= s is rather different than the typical threat model where the originator wo= rries about evil Mallory changing their data, e.g., by redirecting a money = transfer to them.

=C2=A0

But for call-purpose, this is less relevant - this is clearly (m= ostly) useful if inserted by the originating caller, and unlike for A-level attestation, the carrier can't really validate = that the message is truthful. How would it know that "You have won a c= ruise!" in the call-purpose/Subject was correct or a scam? Indeed, as = mentioned, if I were a carrier, I'd never want to attest to that purpose, as somebody could reasonably claim that the car= rier should have known that the recipients hadn't won anything.<= u>

=C2=A0

This is the main reason that I think this should be a separate= =C2=A0claim - if anybody should sign/attest this, it's the enterprise call center and only that call center.=

=C2=A0

=C2=A0

Why not have the framework that we can do that.=C2=A0 You are fr= ee to protect or not protect data depending on your own policy.=C2=A0

=C2=A0

Nothing wrong as such. My argument is that RCD and call-purpose/= Subject are very different, so they shouldn't be in the *same* framework. If we need Subject/call-purpose, they should be i= n separate claims, for the operational reasons mentioned.=C2=A0

=C2=A0

=C2=A0

I guess i want to be sure whether you are reacting to us not usi= ng Subject vs call-info as a common container for =E2=80=9Crich call data=E2=80=9D related info or that we have both call-in= fo and =E2=80=98rcd=E2=80=99 as a container for Rich Call Data more general= ly?=C2=A0 I think there is many reasons why we landed there, we can re-hash= that in the context of call-info vs subject.=C2=A0 I would be less excited about re-hashing it for passport/rcd.

=C2=A0

For the reasons above, I think this is a bad idea for both cases= ,=C2=A0in my=C2=A0view. It's worse for Call-Info, because of the duplication of existing functionality.

=C2=A0

To use an analogy: The RCD is mostly like a business card. We do= n't typically write our contracts and messages on business cards - we might staple our business card to a note.

=C2=A0

My constructive suggestion is to create a separate claim if need= ed. (My understanding is that rcd-14 does not contain the call purpose, so this is the current state.)

=C2=A0

=C2=A0

I do believe both of these frameworks need to be extensible, i d= on=E2=80=99t think we are finished.=C2=A0 We can define more passport extensions, but at the same time, do we want to redefine =E2=80= =9Crcd=E2=80=9D and =E2=80=9Crcdi=E2=80=9D for new passport extensions?

=C2=A0

No, we should create, in my view, a separate document that focus= es on signing the call purpose, expressed either as Subject (as the compact form) or an explicit JWT claim, such as "s= ubject".

=C2=A0

=C2=A0

-Chris

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore=

=C2=A0

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--000000000000980c8405dc8f77d2-- From nobody Wed Apr 13 14:27:16 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD523A08B1; Wed, 13 Apr 2022 14:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=cLowUVsy; dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=cLowUVsy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwUI0nodgezh; Wed, 13 Apr 2022 14:27:08 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2070b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe59::70b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328343A0884; Wed, 13 Apr 2022 14:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=glqMXBg9LqrdZSVSM10KkLIdxmgJQ0JBsraNBmy1ezs=; b=cLowUVsyev6o1JsPitkDf5JRM3B5BU1kXulY1YN9s//qWch9Veo1PnQykit5cp837hIBF028oWlPy5u0kgSFOOaV28Zc9NUT09NwsrhN6mfYm/y4qz/tANNOJqQzLQiB99GCQg+F1bwSDdMl8OqxPJrUPD3I/Dzq8XDwGi8mxLE= Received: from BN9PR03CA0500.namprd03.prod.outlook.com (2603:10b6:408:130::25) by BY5PR02MB6916.namprd02.prod.outlook.com (2603:10b6:a03:234::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Wed, 13 Apr 2022 21:27:03 +0000 Received: from BN1NAM02FT010.eop-nam02.prod.protection.outlook.com (2603:10b6:408:130:cafe::f7) by BN9PR03CA0500.outlook.office365.com (2603:10b6:408:130::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20 via Frontend Transport; Wed, 13 Apr 2022 21:27:02 +0000 X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 144.49.247.87) smtp.mailfrom=t-mobile.com; dkim=pass (signature was verified) header.d=TMobileUSA.onmicrosoft.com;dmarc=fail action=none header.from=t-mobile.com; Received-SPF: Fail (protection.outlook.com: domain of t-mobile.com does not designate 144.49.247.87 as permitted sender) receiver=protection.outlook.com; client-ip=144.49.247.87; helo=mail.ds.dlp.protect.symantec.com; Received: from mail.ds.dlp.protect.symantec.com (144.49.247.87) by BN1NAM02FT010.mail.protection.outlook.com (10.13.2.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.19 via Frontend Transport; Wed, 13 Apr 2022 21:27:02 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kp7fTyNYtZU+zKuiwSGhDKNHruYT5MbrvTXnVQ6zJSytyixwMIhTzIuKuSR1OWevda8iCs3VUNj30VzLBXU6jxTXyZ9CwhbWiZD8ozhmF59dn6Qx96ammlrOhlOulci9YA3V6sd8vfzoigsZ3COBtvhl9FCT8K70KVaYuG6e7r4a3CWd7Dwb+9DdE/wv6wxgaP3xw/peCpfPzz181kCX7NDFeOK2/rzMezapmEP2cQyIb5+6ldmsZJDRCF23/g6bKqSW55L7L5+L9daWwcON7OPKUMKX796wHzTVjN4nbB70392/R+ngyeD6Vd5QPDJLnVd3YKGAcHqRfDqpBRwpXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=glqMXBg9LqrdZSVSM10KkLIdxmgJQ0JBsraNBmy1ezs=; b=kV9Xqy+yETDgpDW+wbrhKTHXXasQ/+mwlss/FWhhPbhU6jjfc5PQzw6uvo54bUM/BuQl5O9SvIeIkgGE1h6KnP+iaw4TidyVnFmb/EAPBpD/r8NQ7iA0gHVYjxMjEgMVlbk/hxRANNsiORU/UnWaXOh9m3UFOJW7QO6EfAQzCVfgvon/MSlNazq3K0sKiIwEs8AhWSh0R9iV+f7YdGHI5CbtydcSvCVv7dlPqQt/7wwwMcrT0pneKkflsFtVqBF6OmcN2tID4Gy5nZQ0H68YKI3A5FTJWiN+iWLnDjFdyYRPZ5DqfG6+8phmNw3Mv35fiHuqMOd93tfDOX7K/mKfeA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=t-mobile.com; dmarc=pass action=none header.from=t-mobile.com; dkim=pass header.d=t-mobile.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=glqMXBg9LqrdZSVSM10KkLIdxmgJQ0JBsraNBmy1ezs=; b=cLowUVsyev6o1JsPitkDf5JRM3B5BU1kXulY1YN9s//qWch9Veo1PnQykit5cp837hIBF028oWlPy5u0kgSFOOaV28Zc9NUT09NwsrhN6mfYm/y4qz/tANNOJqQzLQiB99GCQg+F1bwSDdMl8OqxPJrUPD3I/Dzq8XDwGi8mxLE= Received: from BYAPR02MB4168.namprd02.prod.outlook.com (2603:10b6:a02:f4::11) by BYAPR02MB4213.namprd02.prod.outlook.com (2603:10b6:a02:f3::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Wed, 13 Apr 2022 21:27:00 +0000 Received: from BYAPR02MB4168.namprd02.prod.outlook.com ([fe80::d879:56a0:3a11:6f73]) by BYAPR02MB4168.namprd02.prod.outlook.com ([fe80::d879:56a0:3a11:6f73%3]) with mapi id 15.20.5144.030; Wed, 13 Apr 2022 21:27:00 +0000 From: "Gorman, Pierce" To: Ranjit Avasarala CC: Ben Campbell , Chris Wendt , IETF STIR Mail List , SIPCORE Thread-Topic: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-reason) Thread-Index: AQHYTq5xOr0BQdd/g02frIkAGlSD1Kzsv7pwgAGV3ACAAAAxYA== Date: Wed, 13 Apr 2022 21:27:00 +0000 Message-ID: References: <86BE36F5-7CFE-48BE-B0A7-7458B67EB208@chriswendt.net> <51718867-9092-4423-B895-8069A8AF3D07@chriswendt.net> <28766342-130D-4FED-AD38-7A817D4B525B@chriswendt.net> <97AB0ACC-011C-48F8-826A-2E7238485D30@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=t-mobile.com; X-MS-Office365-Filtering-Correlation-Id: a6540b4c-00a9-48f1-6b7b-08da1d945a0c x-ms-traffictypediagnostic: BYAPR02MB4213:EE_|BN1NAM02FT010:EE_|BY5PR02MB6916:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: UskDotLB51ORQEIHnOkOPARkvz7v3K3QtNxlgIYwFHcgrU493/qiIvQ+eNSawWHsIao1Su3oRoy/tEh4I4ThOT4n4ZHaoF8223v5f26gFRcQ2hVe43aXh4jNDZVJlJFvF9EOCAfcBMuSWg52nNbJQjCJz6L4yyb+XslRba64xuWUUF6kB47kPrXe1K8a+HFhVPkL79f9MrD7rFfUHwfwDrqtnFIdPfr7gNX/IFvgJLYOA7KbHEyrxmprbiDUsufyQ8SLqGxcd4WvG3DSo9Q5G0/esdfGLHxTXI70um8OTmA4vADMP7ZbiHuszdr7kp1WhmP7KPPUO4zFZvYr/6n/aLucU01ZPdLWjqI2fYSmhPPjk4rC6sBtTWfvwChqezgq7Gx8y9GxRPkTPSqSJeWdEJcOg7Uq/2vFTTl/F5GjdphvUxI6vhIYOWsJsumE/xHJEadvlevZ9tohA4Ksk40aG/fyEScLOUrPsg3ZePvZlacdDd6Yde0U1iI7jCDL3DBrb0CY0Cj4wbtaZatZGOn3vrDn7fjoc7jRk9bK1O1vxcmGy9P2AlHu9647nsVg4ipQ56PCQvFsFRn9qK7gITqCT6nbt1oF+r2f0ZtBq5uuPbS+91Sd99LGlCx+XANp4HAxS5FIMiOXRUlNx0xjclY3SdSAUZ1PEFVssAOnULbZ7hoF9Rz9xUTEXPvu/jPqwgFvr0Ds9Gxo0tFtt8HS+INqBkkk5tUGacprW4b1sM0zTtMZ9/o8Wymlou1Q07+q2ZhghZV1mjdG6tW9VCNora8wIji+6N9KQfYE7FVMAsvaczw= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR02MB4168.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(508600001)(316002)(9686003)(7696005)(53546011)(66556008)(55016003)(76116006)(4326008)(66476007)(64756008)(6506007)(66946007)(82960400001)(166002)(122000001)(38070700005)(38100700002)(86362001)(26005)(186003)(33656002)(83380400001)(66446008)(2906002)(54906003)(6916009)(966005)(8676002)(52536014)(30864003)(71200400001)(5660300002)(8936002); DIR:OUT; SFP:1102; Content-Type: multipart/alternative; boundary="_000_BYAPR02MB41681397D76162E0D2BA46B7D2EC9BYAPR02MB4168namp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB4213 X-CFilter-Loop: Reflected X-DetectorID-Processed: 8c846453-0f50-46b3-95ab-8bbaf7238615 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: BN1NAM02FT010.eop-nam02.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 5679ae95-35d4-42f8-6331-08da1d94587e X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6aj4zICP2ExbRWNVhvvx3MjYTB4HitY14X2rxl/5ZLh5HfV/LukzW1If2z1wAXOA3sszGSqIpPf9CPcdMyEuaTg3kxhatSZ0XfloqMnKgT9V1ZZFi4wfFGOw0Y+khmOGSwCzjm+w7d5obJykJXLkVyz3GaMgfpg9ne70JQH1Mo8aWjbNNSKnJACOYaKUivRxZl7mzNDp6A8TDy8l2Z0NY64cJ20t7GhED5B9KJJSpVld6gAG0dDGsBrj5P7BbahV8uMbd+KNsBlUTr/i7aDxQrLkukizwYM8qZLprwWbMjY7l63mvug/ODRUVNucLtYGCthVjvQ7dXwUBhQJGEAeheJabVrv322UC4CxStVj5set7z6OeqgQn+q2p2W8GrqBuPDjxNUp09VsWCF+XyVEEJOn5Ozhed71wwKUz3ECeFej5RnpSVvSbhdOyfv0x4/8Dxgo0cGtev8a5WrlfIInRJp7CEE+ZB2ndUynBqACYMnsLHzV5oVuKrTrZWz/dneJIXd1bqO+LZiXvQT4TkhV7tCjmLGkOCKs/YUaHHUWzqPLyNabRLRo1sS6Ldt8M4Y5etJWzpegC/Ng3HsWcp6R1gxDrJ91WoVtXXLEssLJOQ0YnoTc+PddZwlloQ3vh8WxDTYDn5i2k87O49Tce5YDfeQzboCNt9HP3QqZSQXbUbpbEwK9U4GyqLfukWQUyHrRraG7K87Yxl1/xg733fmdTjFAMsoLUr0XDyzuQZcUnI4zV/U+DD04k0cjIDr1hdyXKsyptWx8b8amaGCHSQefJOeOql3k0H+QmtIhNToYVTw= X-Forefront-Antispam-Report: CIP:144.49.247.87; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.ds.dlp.protect.symantec.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230001)(4636009)(40470700004)(36840700001)(46966006)(7696005)(45080400002)(82310400005)(8936002)(52536014)(53546011)(40460700003)(6506007)(6916009)(83380400001)(966005)(86362001)(81166007)(4326008)(8676002)(70586007)(36860700001)(70206006)(5660300002)(166002)(2906002)(54906003)(316002)(33656002)(356005)(30864003)(47076005)(508600001)(336012)(82960400001)(186003)(26005)(55016003)(9686003)(36900700001)(559001)(579004); DIR:OUT; SFP:1102; X-OriginatorOrg: t-mobile.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2022 21:27:02.7131 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a6540b4c-00a9-48f1-6b7b-08da1d945a0c X-MS-Exchange-CrossTenant-Id: be0f980b-dd99-4b19-bd7b-bc71a09b026c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=be0f980b-dd99-4b19-bd7b-bc71a09b026c; Ip=[144.49.247.87]; Helo=[mail.ds.dlp.protect.symantec.com] X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT010.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR02MB6916 Archived-At: Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 21:27:15 -0000 --_000_BYAPR02MB41681397D76162E0D2BA46B7D2EC9BYAPR02MB4168namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ranjit I didn't say a service provider SBC could strip the Subject and Call-info h= eaders. I implied the SBC was likely to be configured to strip those heade= rs. i.e., not possible, probable. All sorts of foo gets sent in SIP to service providers whether accidentally= or intentionally. Either way, SIP INVITEs routinely get stripped of extra= neous non-essential headers to reduce interworking problems and potential a= ttacks. I do agree the contents could be mapped to get across the SBC boundary and = where I would map them to is the RCD PASSporT in a SIP Identity header. BR, Pierce From: Ranjit Avasarala Sent: Wednesday, April 13, 2022 4:00 PM To: Gorman, Pierce Cc: Ben Campbell ; Chris Wendt = ; IETF STIR Mail List ; SIPCORE Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-reason) [External] Hi Pierce Yes I do agree that SBC could strip the call-info header and not pass it th= rough. But in case the information contained in that header is needed downs= tream like by CSCF, then SBC could map the contents of the Call-Info header= to a new Private header and send it across. Regards Ranjit On Tue, Apr 12, 2022 at 3:59 PM Gorman, Pierce > wrote: Could be passed through, yes, but you'll need to define "if needed". The general policy for inbound SIP traffic of the service provider I was em= ployed by for more than 30 years, including in my role as lead SBC design e= ngineer, was to strip proprietary and non-essential SIP headers at the untr= usted interface of the SBC. Call-Info in particular would be in that categ= ory since it can include URLs which refer to goodness knows what. Ben said, "there is the question of whether SBCs will mess with either" (he= ader), and my opinion is he is right, there is a question, and my opinion i= s folks should assume, yes, those headers are at risk of being stripped (as= they most likely are today). From: Ranjit Avasarala = > Sent: Tuesday, April 12, 2022 3:47 PM To: Gorman, Pierce > Cc: Ben Campbell >; Chris Wendt >; IETF STIR Mail = List >; SIPCORE > Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-reason) [External] Depends on policy, but they could be passed thru to if needed Regards Ranjit On Tue, Apr 12, 2022 at 3:23 PM Gorman, Pierce > wrote: I assume Call-Info or Subject are likely to be stripped by SBCs. From: stir > On Behalf = Of Ben Campbell Sent: Tuesday, April 12, 2022 3:18 PM To: Chris Wendt > Cc: IETF STIR Mail List >; SIPCORE >; Henning Schulzrinne > Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) [External] (as individual) (as individual) Apologies for coming to this thread late. I agree we should keep the crn claim for "rcd" passports at this point. I a= lso understand there to be some implementations that either use it or plan = to use it.. I don't have a strong opinion on the Callinfo param vs Subject question, as= long as we have a consistent mapping. I guess there is the question of whe= ther SBCs will mess with either, but I don't know if that is more likely fo= r one or the other. Thanks! Ben. On Mar 20, 2022, at 10:47 AM, Chris Wendt > wrote: Hi Henning, Just to focus on call-reason for passport-rcd at the moment, we do have tha= t, it is an independent claim "crn" explicitly separate from the "rcd" clai= m. It is defined in same passport-rcd document, but that doesn't change how= it's defined or used. I think one hopefully simple fix is to maybe referen= ce Subject as a mapping for this claim and maybe point to callinfo-rcd in a= more generic way that we can further discuss subject vs callinfo in the si= pcore draft as we move that forward. As i understand it, most implementati= ons are focused on passport-rcd at the moment, so i don't want to hold that= up if possible. To everyone, It would be great to get further input on this whether anyone has strong fe= elings about using Subject vs callinfo parameter call-reason. I have the s= ense that there isn't yet much implementation if any at all (of callinfo/ca= ll-reason, i believe there is implementation of passport-rcd "crn"), and th= ere won't strong feeling one way or the other, but if anyone does have stro= ng feelings please speak up. -Chris On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne > wrote: Hi Chris, tl;dr: My suggestions are: (1) leave call purpose out of draft-ietf-stir-pa= ssport-rcd; (2) drop call-purpose from draft-ietf-sipcore-call-info-rcd; (3= ) consider a new JWT claim "subject" [or whatever] that encapsulates the si= gned call purpose in the future. More details inline below. On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt > wrote: Hi Henning, I understand what you are saying. I do however think there is reasons to p= rotect call-reason/Subject of call. I think these situations are mostly in= the context of delegation to perhaps a call center, where you have authori= zed them to represent your company in particular ways, including not only y= our identity, but for different context of calls that you have authorized t= hem to represent you. We all know there is some call centers that use call= identities with good reputation for customers that may exploit that reputa= tion for other customers. I would look at this as similar situation. I think we generally agree - your example of a call center is probably, in = my view, the most likely case where some indication of call purpose will be= used, probably with explicit arrangement with the carrier. This may well t= urn out to be similar to the current model for SMS, where (in the US and so= me other countries) you'll have to register your "campaign" with the carrie= r or designated third party. This may even take the notion of a template ("= This call is about your recent order from {date}") that can be auto-enforce= d. It's clear that carriers seem quite concerned about their individual cus= tomers messaging, in volume, to their subscribers, given the abuse. There is also potential for future of Subject/call-reason to be more than j= ust a text string. I suspect that's best handled separately, once we have a clearer use case. = I don't think we can just stick this into call-reason without all kinds of = backwards-compatibility issues. I'm struggling a bit on your point that we should sign some data but not ot= her data because it is less likely to be manipulated. Is that the bar we s= hould be striving for here? Seems to conflict with my understanding of some= of the goals. Maybe this indicates that we should be clearer on the goals. My take on the= value of STIR "classic" (for TNs) is that the main purpose of signing is t= o make it clear who is responsible for the information provided - thus, the= whole discussion of A/B/C attestation. Indeed, the experience seems to ind= icate that C-level attestation is actually a signal for a robocall, i.e,. C= -level calls are *more* likely to be robocalls than unsigned calls. A/B/C o= bviously have the same cryptographic strength and all prevent modification = by third parties. I don't think that carrier manipulation of the caller information (except i= n various normalization ways) has ever been a major problem - it's originat= or (OSP or end user) spoofing. This is rather different than the typical th= reat model where the originator worries about evil Mallory changing their d= ata, e.g., by redirecting a money transfer to them. But for call-purpose, this is less relevant - this is clearly (mostly) usef= ul if inserted by the originating caller, and unlike for A-level attestatio= n, the carrier can't really validate that the message is truthful. How woul= d it know that "You have won a cruise!" in the call-purpose/Subject was cor= rect or a scam? Indeed, as mentioned, if I were a carrier, I'd never want t= o attest to that purpose, as somebody could reasonably claim that the carri= er should have known that the recipients hadn't won anything. This is the main reason that I think this should be a separate claim - if a= nybody should sign/attest this, it's the enterprise call center and only th= at call center. Why not have the framework that we can do that. You are free to protect or= not protect data depending on your own policy. Nothing wrong as such. My argument is that RCD and call-purpose/Subject are= very different, so they shouldn't be in the *same* framework. If we need S= ubject/call-purpose, they should be in separate claims, for the operational= reasons mentioned. I guess i want to be sure whether you are reacting to us not using Subject = vs call-info as a common container for "rich call data" related info or tha= t we have both call-info and 'rcd' as a container for Rich Call Data more g= enerally? I think there is many reasons why we landed there, we can re-has= h that in the context of call-info vs subject. I would be less excited abo= ut re-hashing it for passport/rcd. For the reasons above, I think this is a bad idea for both cases, in my vie= w. It's worse for Call-Info, because of the duplication of existing functio= nality. To use an analogy: The RCD is mostly like a business card. We don't typical= ly write our contracts and messages on business cards - we might staple our= business card to a note. My constructive suggestion is to create a separate claim if needed. (My und= erstanding is that rcd-14 does not contain the call purpose, so this is the= current state.) I do believe both of these frameworks need to be extensible, i don't think = we are finished. We can define more passport extensions, but at the same t= ime, do we want to redefine "rcd" and "rcdi" for new passport extensions? No, we should create, in my view, a separate document that focuses on signi= ng the call purpose, expressed either as Subject (as the compact form) or a= n explicit JWT claim, such as "subject". -Chris _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_BYAPR02MB41681397D76162E0D2BA46B7D2EC9BYAPR02MB4168namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ranjit=

 

I didn’t say a service provider SBC could strip the Subject and Call-info headers.  I implied the S= BC was likely to be configured to strip those headers.  i.e., not poss= ible, probable.

 

All sorts of foo gets sent in SIP to service providers whether accidenta= lly or intentionally.  Either way, SIP INVITEs routinely get stripped of extraneous non-essential headers to reduce interworking pr= oblems and potential attacks.

 

I do agree the contents could be mapped to get across the SBC boundary a= nd where I would map them to is the RCD PASSporT in a SIP Identity header.

 

BR, Pierce

 

From: Ranjit Avasarala <ranjitkav12@gmail.= com>
Sent: Wednesday, April 13, 2022 4:00 PM
To: Gorman, Pierce <Pierce.Gorman@t-mobile.com>
Cc: Ben Campbell <ben@nostrum.com>; Chris Wendt <chris-ietf= @chriswendt.net>; IETF STIR Mail List <stir@ietf.org>; SIPCORE <= ;sipcore@ietf.org>
Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-r= eason)

 

<= span style=3D"font-size:10.0pt;color:#9C6500">[External]

 

Hi Pierce

 

Yes I do agree that SBC could strip the call-info he= ader and not pass it through. But in case the information contained in that= header is needed downstream like by CSCF, then SBC could map the contents = of the Call-Info header to a new Private header and send it across.

 

Regards

Ranjit

 

On Tue, Apr 12, 2022 at 3:59 PM Gorman, Pierce <<= a href=3D"mailto:Pierce.Gorman@t-mobile.com">Pierce.Gorman@t-mobile.com= > wrote:

Could= be passed through, yes, but you’ll need to define “if needed”.

 

The general policy for inbound SIP traffic of the ser= vice provider I was employed by for more than 30 years, including in my role as lead SBC design engineer, was to strip prop= rietary and non-essential SIP headers at the untrusted interface of the SBC= .  Call-Info in particular would be in that category since it can incl= ude URLs which refer to goodness knows what.

 

Ben said, “there is the question of whet= her SBCs will mess with either” (header), and my opinion is he is right, there is a question, and my opini= on is folks should assume, yes, those headers are at risk of being stripped= (as they most likely are today).

 

 

From: Ranjit Avasarala <ranjitkav12@gmail.com>
Sent: Tuesday, April 12, 2022 3:47 PM
To: Gorman, Pierce <Pierce.Gorman@t-mobile.com>
Cc: Ben Campbell <ben@nostrum.com>; Chris Wendt <chris-ietf@chriswendt.net>; IETF = STIR Mail List <stir@= ietf.org>; SIPCORE <sipcore@= ietf.org>
Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-r= eason)

 

[External]

 

Depends on policy, but they could be passed thru to if needed

 

Regards

Ranjit

 

On Tue, Apr 12, 2022 at 3:23 PM Gorman, Pierce <Pierce.Gorman@t-mobile.com= > wrote:

I assume Call-Info or Subject are likely to be stripped by SBCs.

 

 

From: stir <stir-bounces@ietf.org> On Behalf Of Ben Campbell
Sent: Tuesday, April 12, 2022 3:18 PM
To: Chris Wendt <chris-ietf@chriswendt.net>
Cc: IETF STIR Mail List <stir@ietf.org>; SIPCORE <sipcore@ietf.org>; Henning Schulzrinne <= ;hgs@cs.columbia.e= du>
Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-r= eason)

 

[External]

 

(as individual)

 

(as individual)

 

Apologies for coming to this thread late.

 

I agree we should keep the crn claim for “rcd” passpor= ts at this point. I also understand there to be some implementations that e= ither use it or plan to use it..

 

I don’t have a strong opinion on the Callinfo param vs Subje= ct question, as long as we have a consistent mapping. I guess there is the = question of whether SBCs will mess with either, but I don’t know if that is more likely for one or the other. <= o:p>

 

Thanks!

 

Ben.

 

On Mar 20, 2022, at 10:47 AM, Chris Wendt <chris-ietf@chriswendt.net>= ; wrote:

 

Hi Henning,

 

Just to focus on call-reason for passport-rcd at the moment, we = do have that, it is an independent claim “crn” explicitly separate from the “rcd” claim. It is defined in same passport-= rcd document, but that doesn’t change how it’s defined or used.= I think one hopefully simple fix is to maybe reference Subject as a mappin= g for this claim and maybe point to callinfo-rcd in a more generic way that we can further discuss subject vs callinfo in the sipcore= draft as we move that forward.  As i understand it, most implementati= ons are focused on passport-rcd at the moment, so i don’t want to hol= d that up if possible.

 

To everyone,

 

It would be great to get further input on this whether anyone ha= s strong feelings about using Subject vs callinfo parameter call-reason.  I have the sense that there isn’t yet m= uch implementation if any at all (of callinfo/call-reason, i believe there = is implementation of passport-rcd “crn”), and there won't stron= g feeling one way or the other, but if anyone does have strong feelings please speak up.

 

-Chris

 

On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:

 

Hi Chris,

 

tl;dr: My suggestions are: (1) leave call purpose out of dr= aft-ietf-stir-passport-rcd; (2) drop call-purpose from draft-ietf-sipc= ore-call-info-rcd; (3) consider a new JWT claim "subject" [or whatever] that encaps= ulates the signed call purpose in the future.

 

More details inline below.

 

On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <chris-ietf@chriswendt.net> wrote:

Hi Henning,

 

I understand what you are saying.  I do however think there= is reasons to protect call-reason/Subject of call.  I think these situations are mostly in the context of delegation to perhap= s a call center, where you have authorized them to represent your company i= n particular ways, including not only your identity, but for different cont= ext of calls that you have authorized them to represent you.  We all know there is some call centers that u= se call identities with good reputation for customers that may exploit that= reputation for other customers.  I would look at this as similar situ= ation.

 

I think we generally agree - your example of a call center is pr= obably, in my view, the most likely case where some indication of call purpose will be used, probably with explicit arrangemen= t with the carrier. This may well turn out to be similar to the current mod= el for SMS, where (in the US and some other countries) you'll have to regis= ter your "campaign" with the carrier or designated third party. This may even take the notion of a template (&q= uot;This call is about your recent order from {date}") that can be aut= o-enforced. It's clear that carriers seem quite concerned about their indiv= idual customers messaging, in volume, to their subscribers, given the abuse.

 

 

There is also potential for future of Subject/call-reason to be = more than just a text string.

 

I suspect that's best handled separately, once we have a clearer= use case. I don't think we can just stick this into call-reason without all kinds of backwards-compatibility issues. = ;

 

 

I’m struggling a bit on your point that we should sign som= e data but not other data because it is less likely to be manipulated.  Is that the bar we should be striving for here? Seem= s to conflict with my understanding of some of the goals.=

 

Maybe this indicates that we should be clearer on the goals. My = take on the value of STIR "classic" (for TNs) is that the main purpose of signing is to make it clear who is responsible fo= r the information provided - thus, the whole discussion of A/B/C attestatio= n. Indeed, the experience seems to indicate that C-level attestation is act= ually a signal for a robocall, i.e,. C-level calls are *more* likely to be robocalls than unsigned calls. A/B/C= obviously have the same cryptographic strength and all prevent modificatio= n by third parties.

 

I don't think that carrier manipulation of the caller informatio= n (except in various normalization ways) has ever been a major problem - it's originator (OSP or end user) spoofing. This is= rather different than the typical threat model where the originator worrie= s about evil Mallory changing their data, e.g., by redirecting a money tran= sfer to them.

 

But for call-purpose, this is less relevant - this is clearly (m= ostly) useful if inserted by the originating caller, and unlike for A-level attestation, the carrier can't really validate that= the message is truthful. How would it know that "You have won a cruis= e!" in the call-purpose/Subject was correct or a scam? Indeed, as ment= ioned, if I were a carrier, I'd never want to attest to that purpose, as somebody could reasonably claim that the car= rier should have known that the recipients hadn't won anything.=

 

This is the main reason that I think this should be a separate&n= bsp;claim - if anybody should sign/attest this, it's the enterprise call center and only that call center.

 

 

Why not have the framework that we can do that.  You are fr= ee to protect or not protect data depending on your own policy. 

 

Nothing wrong as such. My argument is that RCD and call-purpose/= Subject are very different, so they shouldn't be in the *same* framework. If we need Subject/call-purpose, they should be i= n separate claims, for the operational reasons mentioned. =

 

 

I guess i want to be sure whether you are reacting to us not usi= ng Subject vs call-info as a common container for “rich call data” related info or that we have both call-info a= nd ‘rcd’ as a container for Rich Call Data more generally? = ; I think there is many reasons why we landed there, we can re-hash that in= the context of call-info vs subject.  I would be less excited about re-hashing it for passport/rcd.

 

For the reasons above, I think this is a bad idea for both cases= , in my view. It's worse for Call-Info, because of the duplication of existing functionality.

 

To use an analogy: The RCD is mostly like a business card. We do= n't typically write our contracts and messages on business cards - we might staple our business card to a note.<= /o:p>

 

My constructive suggestion is to create a separate claim if need= ed. (My understanding is that rcd-14 does not contain the call purpose, so this is the current state.)

 

 

I do believe both of these frameworks need to be extensible, i d= on’t think we are finished.  We can define more passport extensions, but at the same time, do we want to redefine “r= cd” and “rcdi” for new passport extensions?

 

No, we should create, in my view, a separate document that focus= es on signing the call purpose, expressed either as Subject (as the compact form) or an explicit JWT claim, such as "s= ubject".

 

 

-Chris

 

 

 

_______________________________________________
sipcore mailing list
sipcore@ietf= .org
https://www.ietf.org/mailman/listinfo/sipcore

 

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore=

--_000_BYAPR02MB41681397D76162E0D2BA46B7D2EC9BYAPR02MB4168namp_-- From nobody Wed Apr 13 14:44:51 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8269E3A1171; Wed, 13 Apr 2022 14:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgR9St2VYSvQ; Wed, 13 Apr 2022 14:44:44 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E278D3A1169; Wed, 13 Apr 2022 14:44:44 -0700 (PDT) Received: from pps.filterd (m0288873.ppops.net [127.0.0.1]) by m0288873.ppops.net-00191d01. (8.17.1.5/8.17.1.5) with ESMTP id 23DLJvCL010781; Wed, 13 Apr 2022 17:44:42 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0288873.ppops.net-00191d01. (PPS) with ESMTPS id 3fe0jrakvd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Apr 2022 17:44:41 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 23DLiek5007910; Wed, 13 Apr 2022 17:44:40 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 23DLiWjG007781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Apr 2022 17:44:32 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id 25C51401698E; Wed, 13 Apr 2022 21:44:32 +0000 (GMT) Received: from MISOUT7MSGEX2CB.ITServices.sbc.com (unknown [135.66.184.206]) by zlp27126.vci.att.com (Service) with ESMTP id EB6004014789; Wed, 13 Apr 2022 21:44:31 +0000 (GMT) Received: from MISOUT7MSGEX2DF.ITServices.sbc.com (135.66.184.225) by MISOUT7MSGEX2CB.ITServices.sbc.com (135.66.184.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 13 Apr 2022 17:44:25 -0400 Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGEX2DF.ITServices.sbc.com (135.66.184.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24 via Frontend Transport; Wed, 13 Apr 2022 17:44:25 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.175) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Wed, 13 Apr 2022 17:44:25 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SnW6k+IW2h3kcom2JzTJuwyV5q/GXMeofSBnzwRsGuEE/i7tSocKa2wcyO4ugI4ya0sbLR358joK9o1cortCkdTqYG0oBPsB50RfNCBAySg5nLiFHs3rJtk8pNcKmetYcL7LCzJNrD6D7PRwX2DGckGF3DL5qVK2opgGbrOVM4gmK/b57AWiadmk7v3SAQm6/FO/NB599KXs7Gqjfhk7jN5kF9FKUxXAGEjausgVStdvOI4z+cUbwNAFfmcC158498Uf34ZhSHmVFU8pn53t6zKL60vjxNL1FLtveJwy+Crbxms8YJI57Ge/nuUNoGCTGM9NBwsFRSvst2+dgaSjDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3CIM4KMKdp+j7NiF7pvnVyN3l1nHQ1vYTLIZdpEKYQ0=; b=dvFzDuPraw9ODJnEEYdvEqw4sH3ONMV2imd5MEEqi/psTMhBbKkNfz8CYbIeT+jHRMcJ8F/sh/gMLzXAnhRKFLOxEfWauF/rbW7ThUx3Hbx49i/htTbYw9KYc3gcDc+/y+AUP0HLxmwcuqlbyFhplBbVxg7vHFZ9+nTZnuDv+eAs5tmtDeuj/fus6vUr0SYUdCro5eImqnTmHQkh00gryUekt5kchIDCkbrUWLJmLCEinY8axA+0musZp23mmwes3PejTJo9dWVlPxOLLq1MqVTwotCLjqiKEReNEGLl+WLRkoYOo5g7cZl872mGk5mWvzwGatWkWxm8wGvdTsyN6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3CIM4KMKdp+j7NiF7pvnVyN3l1nHQ1vYTLIZdpEKYQ0=; b=PvMgfxy8kQECf1aBM71Ft+AQsozbn6rUE+u+4qhon0PIOxg7KfR2lT20/ZDMUl8XdFvnbxbU899CrzAWzOz7RRCvfuxZOpxCcp9kOT1PYhMoctiFe9ZeotwZBe0Yv7pkwVZz+RtcYMvIcAxaLVMkclk2lxUJ7l9cUSOTRGb71Yw= Received: from BN0PR02MB8080.namprd02.prod.outlook.com (2603:10b6:408:16f::21) by CY4PR02MB2310.namprd02.prod.outlook.com (2603:10b6:903:b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Wed, 13 Apr 2022 21:44:23 +0000 Received: from BN0PR02MB8080.namprd02.prod.outlook.com ([fe80::dc26:c3a5:4f04:acfb]) by BN0PR02MB8080.namprd02.prod.outlook.com ([fe80::dc26:c3a5:4f04:acfb%5]) with mapi id 15.20.5164.018; Wed, 13 Apr 2022 21:44:23 +0000 From: "DOLLY, MARTIN C" To: "Gorman, Pierce" , Ranjit Avasarala CC: Ben Campbell , SIPCORE , "IETF STIR Mail List" , Chris Wendt Thread-Topic: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) Thread-Index: AQHYT31StKPJrv9PakinHiEb93ddIKzuX4C/ Date: Wed, 13 Apr 2022 21:44:23 +0000 Message-ID: References: <86BE36F5-7CFE-48BE-B0A7-7458B67EB208@chriswendt.net> <51718867-9092-4423-B895-8069A8AF3D07@chriswendt.net> <28766342-130D-4FED-AD38-7A817D4B525B@chriswendt.net> <97AB0ACC-011C-48F8-826A-2E7238485D30@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c3ce4fd8-f941-45e7-4bce-08da1d96c659 x-ms-traffictypediagnostic: CY4PR02MB2310:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nMUiIZpg+VwDS77HJgVRCO4oiG/d6rn4x8/dUHHRerNxvWRO41176vdx2SsntD6y7qEVzkvExVStrwYG9Gn5nhQULJTfancaZ+WNwmb+rdnAoPmPwtAMQMobOT05lslUJkn0BZ7Hro0R3xWW/FJU8rtjJAqXEjD8IoyAZrNtCeGpt4JzASVhAzC6SxJD6S/c3LBFuPqyIDlJ040vYRqron0cnU7YPIEe4Vy9Zq0uHFyQpwWIpIEHiN+6tprOhhki4YsGftZfidydkdg7MKIdkVgVEOlSFGodJfkLOgClEMwfDMDcJ8jZtzIFG2CMtDRPMGeAVsk4HGFfKv9LOCzXuk+d7UIRyUGo9FnQYedNhJ0RxUJAoqfc9hJBLEwLWB0MgWFpPNkvyn2ZEzusBZB4m1uSr9135Gmf4QBYupB4qazpTZ1pvuw+tvKyplD12nqeDxRw2TZzI2PogduZKGUMGMPf/jZNBU974PuQw/3ZZNfLSni5Vp9jooAQVpXZBCUz/gUTtVPUcWtys2mv40BFw5TzuDec26xtEDxUtQvZO6PfWYZEGdvxacob49WW5AzTX0ClglDd0c9x0CxVRPuSVM00Isk3gdVolAuvDad14uhl7KxZ+JdGcxl48wV19bRYMyF0kzlGH7aiewOn7xd6+f9ThUTswhgqLn9Ne2CvmSQjc+x6nGJbZrsGqLyn8+1s6W3tU/YmeiUYM8eKNZxo7oDVb7OXqLoXSi+ZyeuxK27skFL+ImWONA2FP852PGYwKJiHMXE2HU/SarHHjdEcu29hXg4V829joxIBX/2Xqyo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0PR02MB8080.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(508600001)(30864003)(82202003)(91956017)(66556008)(66446008)(122000001)(76116006)(66476007)(55016003)(38100700002)(2906002)(166002)(86362001)(82960400001)(33656002)(38070700005)(8936002)(316002)(186003)(26005)(52536014)(83380400001)(296002)(66946007)(966005)(8676002)(53546011)(4326008)(7696005)(64756008)(9686003)(6506007)(110136005)(5660300002)(71200400001)(19627235002)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?bfiQgVzSESvOG5MHit8Ixl0oFeA2jTfc71AOhuhf+VWbuRX8LLQv0Vsu?= =?Windows-1252?Q?BmJ5E6kp5R7ZcNjcN1uKgzfJ6nsA913NjdrLw/e/A9dF7BScz0O+dkDc?= =?Windows-1252?Q?5RDs9Q7coACKSg5Ww8N1wNbZ2KzQySwbb6L9/TObjGiAQIyUUM/6nR4Q?= =?Windows-1252?Q?8+3tOJovqcwXF6L8HZ/+nDXY9R41RAB6vzeRbwgO6Esf4+2QZUKfC2th?= =?Windows-1252?Q?BXh3zlmKXG8Zyy6d1vqOVqmfpeN4673qFf1vFMNHMNvaPGpVl9nmYV5P?= =?Windows-1252?Q?iGTHtKH6A86Ctd93K2y1kgwgIHcXJ7wFRTkiw1ArXUHS8wZuOpkohCPd?= =?Windows-1252?Q?6VCGEAOGApw/R69uI69VzSU+UQQgwxH7y2X7g9qX6bRa0wUJ7FPQwu2v?= =?Windows-1252?Q?jltLKqU9OTilMZsr0UthLzTo7rG+2nGQ58GOqq2Ym9mn9KolCHw7rw46?= =?Windows-1252?Q?NU71j2zZqwZ6lElKNHaQkxD4a0WLA5e2nWvgn3HE+tv5n0og4h5wsMWv?= =?Windows-1252?Q?IRFulomGurlS2p1AQLTw/VYlqZuthnTP4M7zP0O/R+RceQNCtTMlSkSD?= =?Windows-1252?Q?eDipEDp1L1NBtRCIG28PPDjjL9XNCvpGqVHS5Eg5rwixNdueTHHIHpIB?= =?Windows-1252?Q?Sl6vcZSSi5lzKyVHcexpPAn+O9yiCs0X9pa/EWvoxpXT9iRxsPcUwoi+?= =?Windows-1252?Q?L5gBxMqLNUSH6JFhAcFGwrExtBC5sDrPReFTu3kdigzY5mkhhbPvv13l?= =?Windows-1252?Q?f5HJNqC9JjoMAPF7RZxP2KRdrSFoyviJgzhXYrzJPYuinhBTtbG9DhXt?= =?Windows-1252?Q?UPuPr/jJ9fOfPIYtLFvd0sazbutbCFga5D4FyzE5UY7WZtxPXQTKEyTg?= =?Windows-1252?Q?NeHBeEEfKQhRn5+mYb/T6C3xTspJRXq9zLbsyzD+ErtM0KBFCihrJa3G?= =?Windows-1252?Q?j5YOe+A93ySbkFOr3sdjusp1U2jNuEFRuxv2jQfegjt2LRYFyxVcChX8?= =?Windows-1252?Q?RDvP1uWXJToMdEUU/kXGyP5xz4m3etcgwIhA51HEnnya8CPIq6MV51Tk?= =?Windows-1252?Q?f6sKrHRqIXL9+yI+zivCms/f2mTRsiE/gAmQa9zrfDizhdIhnJnAIOhn?= =?Windows-1252?Q?16FGOmBVauAOO57M+xma0cwfs5jGoS2x3LHauMR/Bd9If5QwzCiDm5cL?= =?Windows-1252?Q?Ti6KoUuifIxTdQTingvVa1d04oFIANwvE1er34LB9wXy90PVjC6mY088?= =?Windows-1252?Q?hT5Y+wjWc6VDk8japUW5Q/z1jJVQCoMxr43/pbhzLpw5vRFpsJePfBo4?= =?Windows-1252?Q?0vpoH4sUebWPQYiNq2NVTBUxC7QZX8vchVm6NOJcpJEY1rysugMl1RPz?= =?Windows-1252?Q?Mae/cI5sZBtjMyueGECe/xDxDWlY3S6+VImFxyVqqxKUBAzdzZu7V/2O?= =?Windows-1252?Q?cNIsVodZdxMyzBTGV/HWR3QcrJF4bccEcxIpIA/dXcM6Rvkbz5hod6UU?= =?Windows-1252?Q?hmdNTTaeO0Qqf3EUqJHX64csBH0trnA9lokWxUqb92qfxKO8IPiHdcej?= =?Windows-1252?Q?gzAYxjf0h2q3WcDpMfxiFig/+DRUPEEqT08ygT3dgUP3FHXrFM+cK3Cu?= =?Windows-1252?Q?VARHiUHkVpjcScyNHaFotQuZnFkdh452QecNFd2Rnvf0jJuINRpt6G+V?= =?Windows-1252?Q?wRfeCACCpLlLPRGhFk1Z/hkt56UTAyIsRzLcwKEF4f1KQWmcAWs0joZQ?= =?Windows-1252?Q?umreLa1hv/AJbhVkiB8jfm84zvQrReGTxPrMmJ2oox7hKoUduEvGOsC+?= =?Windows-1252?Q?OHsYnRTrfMUuZJdo/Xsv2IxCiqTFnBp19zZz8JdpmTVn4vY/1b3gGeie?= =?Windows-1252?Q?B+vfRlMomvT1xx8dPV5bgEm4RsMB9mGCODY=3D?= Content-Type: multipart/alternative; boundary="_000_BN0PR02MB80802B9D44E1E1DE3986E3BED9EC9BN0PR02MB8080namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN0PR02MB8080.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3ce4fd8-f941-45e7-4bce-08da1d96c659 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2022 21:44:23.5762 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LLu86cTDua8pE0Q4n3pYy7I078gPmnz58dnxtPN696nbI8KUfgskRCZ5hgNFyL6y X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR02MB2310 X-TM-SNTS-SMTP: A37E6D8E2D605B0AA332FF71CEB12FA2E3825B899670F7CDEDE3E2E2978AC5B82 X-Proofpoint-GUID: Fu1f4VbhTMtf1NwfVnDvNSyB7bitdUOK X-Proofpoint-ORIG-GUID: Fu1f4VbhTMtf1NwfVnDvNSyB7bitdUOK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-13_04,2022-04-13_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 clxscore=1011 bulkscore=0 suspectscore=0 priorityscore=1501 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204130104 Archived-At: Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 21:44:50 -0000 --_000_BN0PR02MB80802B9D44E1E1DE3986E3BED9EC9BN0PR02MB8080namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable At the NNI, stripping is based on interconnection Agreements ________________________________ From: stir on behalf of Gorman, Pierce Sent: Wednesday, April 13, 2022 5:27:00 PM To: Ranjit Avasarala Cc: Ben Campbell ; SIPCORE ; IETF STIR M= ail List ; Chris Wendt Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) Hi Ranjit I didn=92t say a service provider SBC could strip the Subject and Call-info= headers. I implied the SBC was likely to be configured to strip those hea= ders. i.e., not possible, probable. All sorts of foo gets sent in SIP to service providers whether accidentally= or intentionally. Either way, SIP INVITEs routinely get stripped of extra= neous non-essential headers to reduce interworking problems and potential a= ttacks. I do agree the contents could be mapped to get across the SBC boundary and = where I would map them to is the RCD PASSporT in a SIP Identity header. BR, Pierce From: Ranjit Avasarala Sent: Wednesday, April 13, 2022 4:00 PM To: Gorman, Pierce Cc: Ben Campbell ; Chris Wendt = ; IETF STIR Mail List ; SIPCORE Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-reason) [External] Hi Pierce Yes I do agree that SBC could strip the call-info header and not pass it th= rough. But in case the information contained in that header is needed downs= tream like by CSCF, then SBC could map the contents of the Call-Info header= to a new Private header and send it across. Regards Ranjit On Tue, Apr 12, 2022 at 3:59 PM Gorman, Pierce > wrote: Could be passed through, yes, but you=92ll need to define =93if needed=94. The general policy for inbound SIP traffic of the service provider I was em= ployed by for more than 30 years, including in my role as lead SBC design e= ngineer, was to strip proprietary and non-essential SIP headers at the untr= usted interface of the SBC. Call-Info in particular would be in that categ= ory since it can include URLs which refer to goodness knows what. Ben said, =93there is the question of whether SBCs will mess with either=94= (header), and my opinion is he is right, there is a question, and my opini= on is folks should assume, yes, those headers are at risk of being stripped= (as they most likely are today). From: Ranjit Avasarala = > Sent: Tuesday, April 12, 2022 3:47 PM To: Gorman, Pierce > Cc: Ben Campbell >; Chris Wendt >; IETF STIR Mail = List >; SIPCORE > Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-reason) [External] Depends on policy, but they could be passed thru to if needed Regards Ranjit On Tue, Apr 12, 2022 at 3:23 PM Gorman, Pierce > wrote: I assume Call-Info or Subject are likely to be stripped by SBCs. From: stir > On Behalf = Of Ben Campbell Sent: Tuesday, April 12, 2022 3:18 PM To: Chris Wendt > Cc: IETF STIR Mail List >; SIPCORE >; Henning Schulzrinne > Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) [External] (as individual) (as individual) Apologies for coming to this thread late. I agree we should keep the crn claim for =93rcd=94 passports at this point.= I also understand there to be some implementations that either use it or p= lan to use it.. I don=92t have a strong opinion on the Callinfo param vs Subject question, = as long as we have a consistent mapping. I guess there is the question of w= hether SBCs will mess with either, but I don=92t know if that is more likel= y for one or the other. Thanks! Ben. On Mar 20, 2022, at 10:47 AM, Chris Wendt > wrote: Hi Henning, Just to focus on call-reason for passport-rcd at the moment, we do have tha= t, it is an independent claim =93crn=94 explicitly separate from the =93rcd= =94 claim. It is defined in same passport-rcd document, but that doesn=92t = change how it=92s defined or used. I think one hopefully simple fix is to m= aybe reference Subject as a mapping for this claim and maybe point to calli= nfo-rcd in a more generic way that we can further discuss subject vs callin= fo in the sipcore draft as we move that forward. As i understand it, most = implementations are focused on passport-rcd at the moment, so i don=92t wan= t to hold that up if possible. To everyone, It would be great to get further input on this whether anyone has strong fe= elings about using Subject vs callinfo parameter call-reason. I have the s= ense that there isn=92t yet much implementation if any at all (of callinfo/= call-reason, i believe there is implementation of passport-rcd =93crn=94), = and there won't strong feeling one way or the other, but if anyone does hav= e strong feelings please speak up. -Chris On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne > wrote: Hi Chris, tl;dr: My suggestions are: (1) leave call purpose out of draft-ietf-stir-pa= ssport-rcd; (2) drop call-purpose from draft-ietf-sipcore-call-info-rcd; (3= ) consider a new JWT claim "subject" [or whatever] that encapsulates the si= gned call purpose in the future. More details inline below. On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt > wrote: Hi Henning, I understand what you are saying. I do however think there is reasons to p= rotect call-reason/Subject of call. I think these situations are mostly in= the context of delegation to perhaps a call center, where you have authori= zed them to represent your company in particular ways, including not only y= our identity, but for different context of calls that you have authorized t= hem to represent you. We all know there is some call centers that use call= identities with good reputation for customers that may exploit that reputa= tion for other customers. I would look at this as similar situation. I think we generally agree - your example of a call center is probably, in = my view, the most likely case where some indication of call purpose will be= used, probably with explicit arrangement with the carrier. This may well t= urn out to be similar to the current model for SMS, where (in the US and so= me other countries) you'll have to register your "campaign" with the carrie= r or designated third party. This may even take the notion of a template ("= This call is about your recent order from {date}") that can be auto-enforce= d. It's clear that carriers seem quite concerned about their individual cus= tomers messaging, in volume, to their subscribers, given the abuse. There is also potential for future of Subject/call-reason to be more than j= ust a text string. I suspect that's best handled separately, once we have a clearer use case. = I don't think we can just stick this into call-reason without all kinds of = backwards-compatibility issues. I=92m struggling a bit on your point that we should sign some data but not = other data because it is less likely to be manipulated. Is that the bar we= should be striving for here? Seems to conflict with my understanding of so= me of the goals. Maybe this indicates that we should be clearer on the goals. My take on the= value of STIR "classic" (for TNs) is that the main purpose of signing is t= o make it clear who is responsible for the information provided - thus, the= whole discussion of A/B/C attestation. Indeed, the experience seems to ind= icate that C-level attestation is actually a signal for a robocall, i.e,. C= -level calls are *more* likely to be robocalls than unsigned calls. A/B/C o= bviously have the same cryptographic strength and all prevent modification = by third parties. I don't think that carrier manipulation of the caller information (except i= n various normalization ways) has ever been a major problem - it's originat= or (OSP or end user) spoofing. This is rather different than the typical th= reat model where the originator worries about evil Mallory changing their d= ata, e.g., by redirecting a money transfer to them. But for call-purpose, this is less relevant - this is clearly (mostly) usef= ul if inserted by the originating caller, and unlike for A-level attestatio= n, the carrier can't really validate that the message is truthful. How woul= d it know that "You have won a cruise!" in the call-purpose/Subject was cor= rect or a scam? Indeed, as mentioned, if I were a carrier, I'd never want t= o attest to that purpose, as somebody could reasonably claim that the carri= er should have known that the recipients hadn't won anything. This is the main reason that I think this should be a separate claim - if a= nybody should sign/attest this, it's the enterprise call center and only th= at call center. Why not have the framework that we can do that. You are free to protect or= not protect data depending on your own policy. Nothing wrong as such. My argument is that RCD and call-purpose/Subject are= very different, so they shouldn't be in the *same* framework. If we need S= ubject/call-purpose, they should be in separate claims, for the operational= reasons mentioned. I guess i want to be sure whether you are reacting to us not using Subject = vs call-info as a common container for =93rich call data=94 related info or= that we have both call-info and =91rcd=92 as a container for Rich Call Dat= a more generally? I think there is many reasons why we landed there, we ca= n re-hash that in the context of call-info vs subject. I would be less exc= ited about re-hashing it for passport/rcd. For the reasons above, I think this is a bad idea for both cases, in my vie= w. It's worse for Call-Info, because of the duplication of existing functio= nality. To use an analogy: The RCD is mostly like a business card. We don't typical= ly write our contracts and messages on business cards - we might staple our= business card to a note. My constructive suggestion is to create a separate claim if needed. (My und= erstanding is that rcd-14 does not contain the call purpose, so this is the= current state.) I do believe both of these frameworks need to be extensible, i don=92t thin= k we are finished. We can define more passport extensions, but at the same= time, do we want to redefine =93rcd=94 and =93rcdi=94 for new passport ext= ensions? No, we should create, in my view, a separate document that focuses on signi= ng the call purpose, expressed either as Subject (as the compact form) or a= n explicit JWT claim, such as "subject". -Chris _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_BN0PR02MB80802B9D44E1E1DE3986E3BED9EC9BN0PR02MB8080namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
At the NNI, stripping is based on interconnection
Agreements
From: stir <stir-bounces= @ietf.org> on behalf of Gorman, Pierce <Pierce.Gorman@t-mobile.com>= ;
Sent: Wednesday, April 13, 2022 5:27:00 PM
To: Ranjit Avasarala <ranjitkav12@gmail.com>
Cc: Ben Campbell <ben@nostrum.com>; SIPCORE <sipcore@ietf.o= rg>; IETF STIR Mail List <stir@ietf.org>; Chris Wendt <chris-ie= tf@chriswendt.net>
Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-r= eason)
 
 --_000_BN0PR02MB80802B9D44E1E1DE3986E3BED9EC9BN0PR02MB8080namp_-- From nobody Mon Apr 18 08:47:34 2022 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2994F3A0BDA; Mon, 18 Apr 2022 08:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 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, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rbbn.com header.b=JJOSp6Mn; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com header.b=COb7FTOS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPI23qmXCxmm; Mon, 18 Apr 2022 08:47:14 -0700 (PDT) Received: from mail1.bemta36.messagelabs.com (mail1.bemta36.messagelabs.com [85.158.142.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7333A0BCA; Mon, 18 Apr 2022 08:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=rbbnselector03122020; t=1650296831; i=@rbbn.com; bh=v+RynaMYRohhEWWPBpDEhje/UPbAPmjIr/HMT58ZJ18=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=JJOSp6MnB99zaQlozCEGWp6WPSD49rrSBJMLAuvqyVQfH16506UliI3fSka/nzq4F zuPZJmMVl/2oibTIMVk1cgjdkb/Kqwt/O1Y4Aq7FSo8IhmNbgxEAL+Uk2punFZ5dmH UyzZhf5wwjnNwwtCwGsjnvpIjCWrXzuGaCIcl5WPXduM85m6hhN1KUZCwpjleJRWh+ UFZBvTDYIkKQiAgxYs1pXk6iblRSDAr3IrPmyRCFF65tg4lqHT25+s/lxCDc0ol9di 8DJaODE9GuhxSnp+1FamfWBeRmSygAIKxg13//NN9XA5klq5rHlVXZXsml3wSe7rnC m7GQ24mD/88zg== X-Brightmail-Tracker: H4sIAAAAAAAAA1WTfUxTVxjGOb23t1do8baAvHbilprJArZrpyO FOTMTjfWDbdkytinIbuVCm5TCekusS8wIIhM2PiRuItq1MNDJhyI6PiVDtoACRqTEDQhqtZBB 3ZxsyNgE1vYW5/45+T3v8573PDk5h8QklQIpyVjMjMlIG2REIK57ObZGPvNZklY5NhirtuX3C dTHp9sxddfdcYF65rxYXTtqxdQzfzUS6jP1Tbw3BJrJ4lNIU1JUx9e0lo8JNFVVczxNeasL19 yu3vA2sZuvN2ozLB/xdRX2jZnONszS2NeCZaPFL7ACFEgiqhqD7yqH/aKSD47OSoITNQjybU+ QV+BUOwYXbdk+R0LZeTD6rUPAiTEEE/du8grQMpKgouC3yQu+YaFUNoJT7qt8r8CoQgQ5t+/w vV0h1E6odTl9HErtAlffIsHxK3Apdwh5GadeBMexBoGXRVQS2At6EXdcgQDKSspwr7GM2guH+ 3/yNSFqBcz21vliYFQ4jLhsPgaKgqrLNzCOw2Dy/gKf6zeBw1mHuHoEDNo+93M8jF9xERzLoW UyD+fYAEf/vOCfsxpqCp3++vPwVeVDAcer4O7Pzb5LAmqAgGtjRX5xGIe5nhz/CUr4+vGPfmN QDGPf5BMlaF35M8k5NkKZw4qX+65ADNdOuHCuvg7s7dMEx9FwusKNLXF/533es3U7EtSgTVqT Pk1nTqf1BrlKqZSrVK/KY9Ry1Yb1CvoTOa1gsuT7GKPZRHtsBb2fVTAsq2APpO8zpCiMjLkRe Z5lCruluAXdKZpTdKGVJE8WJlqMT9JKgrUZKQd0NKtLNmUZGLYLrSJJGYgScj2e2MSkMZZUvc HzuJdsIIWyUFFMnscWsZl0OqtP46xetJUcaurowMjWSw7PevaHIc/a7lvnp+c7MAluzDAy0nC RxbuZ8m7WZRmfjl76OoMoQhoiQgEBARJhJmNK15v/70+hcBLJQkQ7vVOEeqP5aYIpTzieJ1yz 7UNvODP9nyXN5p00uteHy0OUH6cJM97p/kNpDa9vkv0+kpOaPV8ar7gy+89K2bbS6cmNygeGc WHcp0FTT/q3Vise7ZnI2aT99dCJ1cll0VmPl68NKhYO7nf27yg/OCAKEOY2w0IF3DJYs7ounj u7HVnX5lSopI1tbw0TkTNiumBvG38i8fxV7NF7wi2LCe9m/l28OdVy5KU1QUWuY3lBmwufO0h 98H6pdKE2bE3V9y+MviaRNXx5OUC3beTcinv9i/HFUfwEd3DNdOFyd9z8UGTiLw3Rsw2dETGn u3Y9GI6b6+uJDE4MTDxzaCjpeDdZ/7DbuSPFpgzefrPn9VjNjesDyabre05OHHHvFutuvSnDW R2tisJMLP0vz6H9zrUEAAA= X-Env-Sender: tasveren@rbbn.com X-Msg-Ref: server-8.tower-532.messagelabs.com!1650296820!211780!1 X-Originating-IP: [104.47.57.170] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.85.8; banners=rbbn.com,-,- X-VirusChecked: Checked Received: (qmail 22871 invoked from network); 18 Apr 2022 15:47:01 -0000 Received: from mail-dm6nam11lp2170.outbound.protection.outlook.com (HELO NAM11-DM6-obe.outbound.protection.outlook.com) (104.47.57.170) by server-8.tower-532.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 18 Apr 2022 15:47:01 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TWgpjT6aNPotroa35jcV1hMuQAEooJywTpPR+yWq7WzB98KosUF+JiRXEAYR2JnZHzHgrL593T3X/DIGy8hGUiy0UI7WEbD5jarjsXVo+/JV6eWHu9/EHUOKJMY+st4T20g216maZmiUIqpeIM8A9ViwHyqFA9P7SiwXZveflfCsx7Y1Bvol9ri00OToyGVeVuLvzh6m6DtG0/SxPSeReqGKeZxvLSKN3bN7ZoAV+C8OxsNej+0dH6bQsWUfruZdNWXNHJyAlVK9/Ht7UFOe7xDVyU3g8uG3RdnQLvB8jwUfpU565kZ1BRLQjZX6PMfUW5JpwITGwhnTsOURD6jV5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gt5+cbX5mCSjeRS3y9l70oMAH/6LlvI8FQ2AMiWtPMI=; b=LH2qVtAIVmHynRu99sqy4WVxNGLmdw7sq/WlSknIAK+80AnLpvNbMR4XdJUkzW8lKMDx4i1iumlSnNJ1kWh2yEJfhHSMXxvGiSAuTRIqjtX/lDX/Ud9yi93nlZXF3Xa6OIRL8sx31fXYzcGHUlZ41/ui2tnO5jyxVJ1f0L52tQFCCpw79Q6VXBbjYP/4T/gbTRd8NxhYKTkuT9ZgRxH8IvqtZi12gB8fEcZ4vb/31ZXsWcUENMbRf035WaUlGXotXYhj3OF543ty4njvt37Nzlxe8PcMGtpXEnNsyFUX+LQlBuqFT02LMmi5ANA+fkgxDIfGPOSY3U5jCCdjM3guNg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rbbn.com; dmarc=pass action=none header.from=rbbn.com; dkim=pass header.d=rbbn.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector2-SonusNetworks-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gt5+cbX5mCSjeRS3y9l70oMAH/6LlvI8FQ2AMiWtPMI=; b=COb7FTOSoNs6nRQFWK8p6JDWJtLPJz1nwo9hW76WKbamvoe/2Tz5XqBcdgszjhxaQtJ2TZiz3V1NJexBQOqpAsJQjbR3rJ2wGFGNdpOnOTHhLUs2NKSLz/QpRxI4yl6burvDptLbzLQZA79VXL1m6Lt/maoJr1ru1eUiMVHphhM= Received: from BL1PR03MB5974.namprd03.prod.outlook.com (2603:10b6:208:313::23) by SN6PR03MB3471.namprd03.prod.outlook.com (2603:10b6:805:45::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Mon, 18 Apr 2022 15:46:57 +0000 Received: from BL1PR03MB5974.namprd03.prod.outlook.com ([fe80::283c:1631:4bee:d65]) by BL1PR03MB5974.namprd03.prod.outlook.com ([fe80::283c:1631:4bee:d65%4]) with mapi id 15.20.5164.025; Mon, 18 Apr 2022 15:46:57 +0000 From: "Asveren, Tolga" To: "DOLLY, MARTIN C" , "Gorman, Pierce" , Ranjit Avasarala CC: Chris Wendt , Ben Campbell , SIPCORE , IETF STIR Mail List Thread-Topic: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) Thread-Index: AQHYT3/AptM6ft2kWEW3aOCZJoiSF6z10D0w Date: Mon, 18 Apr 2022 15:46:57 +0000 Message-ID: References: <86BE36F5-7CFE-48BE-B0A7-7458B67EB208@chriswendt.net> <51718867-9092-4423-B895-8069A8AF3D07@chriswendt.net> <28766342-130D-4FED-AD38-7A817D4B525B@chriswendt.net> <97AB0ACC-011C-48F8-826A-2E7238485D30@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0ae7c287-a969-4fd7-6d37-08da2152aba8 x-ms-traffictypediagnostic: SN6PR03MB3471:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gOT66tq4MuQdT+RWYfAp0el1m7t/7/QU+wlToJWnKC1AATKMNDTIeN0EvfYYsAnRRH95CUUA2yfkO0uy/qOhEiLeCJ5PcsJwS0oWQ4uFmDHTokc5CmOFNGQQFw91djLH7C2W6F2FUiwy//GQlXYTQHScFtEjF2HJ7a6VPd6xlJChfntZrAid6ta54lYK07HtkSVr8KpycOBRiLCAyb+8ijxmdeMmKwUz4DHAmTVk0eIfwKNFK65KJL2kErhqfNnVTXA14PPnwxDxY8JlLhJ+n2FsXTD3hWjbDlOQG6TI8olXJUWuUNgLVmD1XUKbhHOcn9Mu1Yy7WOjSvhBKsztM5aHqasXK4WnwnjhfKa3ih94O1f7OZUMYII2QP6yuLZp79HrIVc/B7Jsg50kJeEVnL6M4awqZnOQ8YfTDt2EXIvliQzei/PwvpX+lPYh0ZtL9xRcPzTCX81WffzRhZ4jxrwcLxlYk1RCZvEPRMKJPUgi3B9yiAzZkGB14FSRol27sRteLNJ0e/+/p7myd5m3zJnkvNlQ9j6IV+Ai5P4urLEYGH/y+OMQpkrXzMMTLtgxZTLCavXARoB7JjOZJdzRq6TWfdujUpDum+CEfjQP184DdCfXHCzte8QPjPfMSyZGHpIQUSJSAC0GbYRMxI5iLGQ2KsS7VgCtZJuAWXR0pIvzjyAFG/MndztrECk1eKROa4fAIGZHDQ+Q5c91DuXPRZMqsSKPElVsSN8r2rATi45FErCwaZIgKeQ8Phr35mlXRAMTbpWWmwortkT8QRMehVUZ/Biy+SGRyaiy6B1KJKiU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL1PR03MB5974.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(110136005)(2906002)(166002)(9686003)(66446008)(53546011)(316002)(508600001)(54906003)(122000001)(33656002)(186003)(38100700002)(38070700005)(966005)(5660300002)(6506007)(26005)(86362001)(71200400001)(7696005)(52536014)(8936002)(66476007)(66556008)(66946007)(64756008)(8676002)(4326008)(30864003)(76116006)(55016003)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?4q5BEe7XutW9JhHMHIyAYvtDKmQZhPWZ1tyJv5tm/GvqNiM3MjBEA3dEX+kd?= =?us-ascii?Q?hrj5hojuDVEngqfbBZ/ljTXvmWQ0M4C9L7DtG+hUc3ZOYxkl75DdGMMuLtbU?= =?us-ascii?Q?vIuzNEH0lSXAr8CGqiRyUP/vG8S3P35x+uo4EQwtW0Tj7Mmu9VNojg0qDVL8?= =?us-ascii?Q?2tZBysn1JYCCNXljA4ju5iRlt0IgazTqVG7ZJHlORrTgYTBnpi5Djnq6UrzI?= =?us-ascii?Q?FxvmD2jgTTCuPKjQwJ/u2bhWn51UeEeQmdWKRDYHiNquVnHSiyAvHRccHvNY?= =?us-ascii?Q?xtX4Pslk9VPQvMLGCoRitiJYgumXcl+xlQKjp2KAIQBC/uTyVWX8/opJeTwW?= =?us-ascii?Q?iD+kmRWZR/UNeUQsznConRCyqmIdueLy6UDM6yDsAiddLBbfXJJjIx3xvbcg?= =?us-ascii?Q?hoQe1zfPoc9OJZPTA++sN6T1c0gtax5x2HjBJJEHdkeLUZF5d9TIGAV8TfbD?= =?us-ascii?Q?FOBgtCw8weZlALGPvC4CEZGoT2v2U3O+ZVEqwmaURsoh/ZP7mgOV+32v0lDr?= =?us-ascii?Q?9DoxMcJJAMZcZjFmJV+bII/cWnzvp9xQDaG4ExePpjmdIKtTHklergk0+XZr?= =?us-ascii?Q?X8+AF1Ihkl9qt2FP3CvnQyNZQjl1gVHzRUOpWKJ+5u0Y+/pJBYzKFQ8JDMYN?= =?us-ascii?Q?cEH4Vu0kYyN6Zac7BliExv4NAch9LWGWEEmJsBPT9TGxWv/kEWe3V6S4Lzdf?= =?us-ascii?Q?ijOdlruAXjS3DzBNKNPcbXuh/tob22r2gc117B8rPqjcdIKmcb6tU2pf2KJV?= =?us-ascii?Q?aPtsW5qgM4awazU1xQl+ZJIY4g6yQJlwTaCM9WWkDJDGiUbJackaq6i+yKnG?= =?us-ascii?Q?zkO/xFl2g/GeYEYqnIShD1WFCGky8nilemDNPCjcr/zIuUWVfqDyRIJ5VAHZ?= =?us-ascii?Q?9YseHQkrt34AxUdqf4CsuuX7MFiV44H5ML43QH4w5j6DB1xpFDxrDL9quB8X?= =?us-ascii?Q?EJBcHL+XH9oK9WGGpzebhzqWunAUaKL+3ashnE+iPigo/8voOzare+ds6Mtj?= =?us-ascii?Q?kGTapnoh5JCNXix7WuVdJLMmy5igOvjk2hHfng9pbakawx8sXM0wFWGh8Mcb?= =?us-ascii?Q?pYhdEbIx7t8u3nEsh0WLhSfcecAG9LZdLZ6Q+gaFTT6fxsHH1L03QujArbuI?= =?us-ascii?Q?YOvTwbvEzJpv1WVv2oPGpIdG0+shMfSpIRkcdMYYixQk5ovjXjSN8b8jao4p?= =?us-ascii?Q?/7XQLmOVatgtCZpVIxRm6SLmZJj+/eXUhSo8sK2oVYjy9aoienULB3VhpRz0?= =?us-ascii?Q?f0cdx0e9zz8Wh+Iee77bY+6FFvOL6YYk+LUUGgGZv8p/0IkLd3wg+OW8Eyxg?= =?us-ascii?Q?qW2LHqtG7dZgxJl3+GGObXddrJAByaZY9O5EPAj3Y65A8XVhNtaS5Tis/VNC?= =?us-ascii?Q?NJxU3sNL5DJTuv0msZ+Rr7rK6Y02fPAokzH0LTC+LiRSPcKqZOyBS7OLFdRu?= =?us-ascii?Q?zcr0H4xeNDylIoemsRtnWrgm6wuSmcd8ScnPfOd+9Sv7VLrCVG5HjCeKDpD9?= =?us-ascii?Q?Kc1oixYmh1qHEPyHRABR416NnLfk47zOi8D2I7vqb2MlZeH0sOVSAaqMF8tZ?= =?us-ascii?Q?bL25S++moKw6dYa6g0mZE0+keSk24lr6XgP8wYZTf/i6o9m8ebia4qaF5Rs+?= =?us-ascii?Q?Z8rnmk0jBvpln6iHdwAqBiyV48/x34RxZXmuMToVtUDbpVJ9Ukirhd/ZsyBq?= =?us-ascii?Q?7QK1aHAGq540rkoGrToQiGDCBdBr0dZZlMyD82Km+ZGHHjb1?= Content-Type: multipart/alternative; boundary="_000_BL1PR03MB5974F468D148E01EEE6F75EDA5F39BL1PR03MB5974namp_" MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL1PR03MB5974.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ae7c287-a969-4fd7-6d37-08da2152aba8 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2022 15:46:57.5136 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4UcbuiDRp7Rm+b9/s0lx837HsvOlCYoMfKOssw6BQ1cWOihXGoFlXmgJlZzV8HnuY9Yo/nfQSz2ZzotTnIoQug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR03MB3471 Archived-At: Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2022 15:47:21 -0000 --_000_BL1PR03MB5974F468D148E01EEE6F75EDA5F39BL1PR03MB5974namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few thoughts about various topics in this thread/related threads: * Technically, there is no need to match any claim with a correspondin= g SIP header * Claim value can be used directly * The only exception is orig/dest matching to From/PAI and Request-= URI * As these are needed to link the PASSporT with a particular cal= l -at least as good as it gets together with freshness check- * With Identity header, we have the luxury of e2e delivery * Expecting this for other SIP headers is not realistic/a very risk= y assumption -at least not in the short-term- * Keeping "crn" in "rcd" is practically the right decision IMHO * Having a standard set of "crn" values could be useful * It is probably a good idea to allow non-standard values as well * It is true that there won't be any guarantees on the honest use o= f the value except the implicit trust/business relationship/assumed reputa= tion of the signer * I think there would be deployment scenarios where=20such implicit= trust can be assumed on a per signer basis and this would allow downstre= am elements/entities to apply certain policies based on "crn" content Thanks, Tolga From: stir On Behalf Of DOLLY, MARTIN C Sent: Wednesday, April 13, 2022 5:44 PM To: Gorman, Pierce ; Ranjit Avasarala Cc: Chris Wendt ; Ben Campbell ; SIPCORE ; IETF STIR Mail List Subject: [EXTERNAL] Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (c= all-reason) At the NNI, stripping is based on interconnection Agreements ________________________________ From: stir > on behalf= of Gorman, Pierce > Sent: Wednesday, April 13, 2022 5:27:00 PM To: Ranjit Avasarala >= Cc: Ben Campbell >;=20SIPCORE >; IETF STIR Mail List >; Chris Wendt > Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason)= Hi Ranjit I didn't say a service provider SBC could strip the Subject and Call-info = headers. I implied the SBC was likely to be configured to strip those hea= ders. i.e., not possible, probable. All sorts of foo gets sent in SIP to service providers whether accidentall= y or intentionally. Either way, SIP INVITEs routinely get stripped of ext= raneous non-essential headers to reduce interworking problems and potentia= l attacks. I do agree the contents could be mapped to get across the SBC boundary and= where I would map them to is the RCD PASSporT in a SIP Identity header. BR, Pierce From: Ranjit Avasarala > Sent: Wednesday, April 13, 2022 4:00 PM To: Gorman, Pierce > Cc: Ben Campbell >; Chris Wendt >; IETF STIR Mai= l List >; SIPCORE > Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-reason)= [External] Hi Pierce Yes I do agree that SBC could strip the call-info header and not pass it t= hrough. But in case the information contained in that header is needed dow= nstream like by CSCF, then SBC could map the contents of the Call-Info hea= der to a new Private header and send it across. Regards Ranjit On Tue, Apr 12, 2022 at 3:59 PM Gorman, Pierce > wrote: Could be passed through, yes, but you'll need to define "if needed". The general policy for inbound SIP traffic of the service provider I was e= mployed by for more than 30 years, including in my role as lead SBC design= engineer, was to strip proprietary and non-essential SIP headers at the u= ntrusted interface of the SBC. Call-Info in particular would be in that c= ategory since it can include URLs which refer to goodness knows what. Ben said, "there is the question of whether SBCs will mess with either" (h= eader), and my opinion is he is right, there is a question, and my opinion= is folks should assume, yes, those headers are at risk of being stripped = (as they most likely are today). From: Ranjit Avasarala > Sent: Tuesday, April 12, 2022 3:47 PM To: Gorman, Pierce > Cc: Ben Campbell >; Chris Wendt >; IETF STIR Mai= l List >; SIPCORE > Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-reason)= [External] Depends on policy, but they could be passed thru to if needed Regards Ranjit On Tue, Apr 12, 2022 at 3:23 PM Gorman, Pierce > wrote: I assume Call-Info or Subject are likely to be stripped by SBCs. From: stir > On Behalf= Of Ben Campbell Sent: Tuesday, April 12, 2022 3:18 PM To: Chris Wendt > Cc: IETF STIR Mail List >; SIPCORE >; Henning Schulzrinne > Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason)= [External] (as individual) (as individual) Apologies for coming to this thread late. I agree we should keep the crn claim for "rcd" passports at this point. I = also understand there to be some implementations that either use it or pla= n to use it.. I don't have a strong opinion on the Callinfo param vs Subject question, a= s long as we have a consistent mapping. I guess there is the question of w= hether SBCs will mess with either, but I don't know if that is more likely= for one or the other. Thanks! Ben. On Mar 20, 2022, at 10:47 AM, Chris Wendt > wrote: Hi Henning, Just to focus on call-reason for passport-rcd at the moment, we do have th= at, it is an independent claim "crn" explicitly separate from the "rcd" cl= aim. It is defined in same passport-rcd document, but that doesn't change = how it's defined or used. I think one hopefully simple fix is to maybe ref= erence Subject as a mapping for this claim and maybe point to callinfo-rcd= in a more generic way that we can further discuss subject vs callinfo in = the sipcore draft as we move that forward. As i understand it, most imple= mentations are focused on passport-rcd at the moment, so i don't want to h= old that up if possible. To everyone, It would be great to get further input on this whether anyone has strong f= eelings about using Subject vs callinfo parameter call-reason. I have the= sense that there isn't yet much implementation if any at all (of callinfo= /call-reason, i believe there is implementation of passport-rcd "crn"), an= d there won't strong feeling one way or the other, but if anyone does have= strong feelings please speak up. -Chris On Mar 19, 2022, at 3:25 PM, Henning Schulzrinne > wrote: Hi Chris, tl;dr: My suggestions are: (1) leave call purpose out of draft-ietf-stir-p= assport-rcd; (2) drop call-purpose from draft-ietf-sipcore-call-info-rcd; = (3) consider a new JWT claim "subject" [or whatever] that encapsulates the= signed call purpose in the future. More details inline below. On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt > wrote: Hi Henning, I understand what you are saying. I do however think there is reasons to = protect call-reason/Subject of call. I think these situations are mostly = in the context of delegation to perhaps a call center, where you have auth= orized them to represent your company in particular ways, including not on= ly your identity, but for different context of calls that you have authori= zed them to represent you. We all know there is some call centers that us= e call identities with good reputation for customers that may exploit that= reputation for other customers. I would look at this as similar situatio= n. I think we generally agree - your example of a call center is probably, in= my view, the most likely case where some indication of call purpose will = be used, probably with explicit arrangement with the carrier. This may wel= l turn out to be similar to the current model for SMS, where (in the US an= d some other countries) you'll have to register your "campaign" with the c= arrier or designated third party. This may even take the notion of a templ= ate ("This call is about your recent order from {date}") that can be auto-= enforced. It's clear that carriers seem quite concerned about their indivi= dual customers messaging, in volume, to their subscribers, given the abuse= . There is also potential for future of Subject/call-reason to be more than = just a text string. I suspect that's best handled separately, once we have a clearer use case.= I don't think we can just stick this into call-reason without all kinds o= f backwards-compatibility issues. I'm struggling a bit on your point that we should sign some data but not o= ther data because it is less likely to be manipulated. Is that the bar we= should be striving for here? Seems to conflict with my understanding of s= ome of the goals. Maybe this indicates that we should be clearer on the goals. My take on th= e value of STIR "classic" (for TNs) is that the main purpose of signing is= to make it clear who is responsible for the information provided - thus, = the whole discussion of A/B/C attestation. Indeed, the experience seems to= indicate that C-level attestation is actually a signal for a robocall, i.= e,. C-level calls are *more* likely to be robocalls than unsigned calls. A= /B/C obviously have the same cryptographic strength and all prevent modifi= cation by third parties. I don't think that carrier manipulation of the caller information (except = in various normalization ways) has ever been a major problem - it's origin= ator (OSP or end user) spoofing. This is rather different than the typical= threat model where the originator worries about evil Mallory changing the= ir data, e.g., by redirecting a money transfer to them. But for call-purpose, this is less relevant - this is clearly (mostly) use= ful if inserted by the originating caller, and unlike for A-level attestat= ion, the carrier can't really validate that the message is truthful. How w= ould it know that "You have won a cruise!" in the call-purpose/Subject was= correct or a scam? Indeed, as mentioned, if I were a carrier, I'd never w= ant to attest to that purpose, as somebody could reasonably claim that the= carrier should have known that the recipients hadn't won anything. This is the main reason that I think this should be a separate claim - if = anybody should sign/attest this, it's the enterprise call center and only = that call center. Why not have the framework that we can do that. You are free to protect o= r not protect data depending on your own policy. Nothing wrong as such. My argument is that RCD and call-purpose/Subject ar= e very different, so they shouldn't be in the *same* framework. If we need= Subject/call-purpose, they should be in separate claims, for the operatio= nal reasons mentioned. I guess i want to be sure whether you are reacting to us not using Subject= vs call-info as a common container for "rich call data" related info or t= hat we have both call-info and 'rcd' as a container for Rich Call Data mor= e generally? I think there is many reasons why we landed there, we can re= -hash that in the context of call-info vs subject. I would be less excite= d about re-hashing it for passport/rcd. For the reasons above, I think this is a bad idea for both cases, in my vi= ew. It's worse for Call-Info, because of the duplication of existing funct= ionality. To use an analogy: The RCD is mostly like a business card. We don't typica= lly write our contracts and messages on business cards - we might staple o= ur business card to a note. My constructive suggestion is to create a separate claim if needed. (My un= derstanding is that rcd-14 does not contain the call purpose, so this is t= he current state.) I do believe both of these frameworks need to be extensible, i don't think= we are finished. We can define more passport extensions, but at the same= time, do we want to redefine "rcd" and "rcdi" for new passport extensions= ? No, we should create, in my view, a separate document that focuses on sign= ing the call purpose, expressed either as Subject (as the compact form) or= an explicit JWT claim, such as "subject". -Chris _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore Notice: This e-mail together with any attachments may contain information = of Ribbon Communications Inc. and its Affiliates that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, dis= closure, reliance or distribution by others or forwarding without express = permission is strictly prohibited. If you are not the intended recipient, = please notify the sender immediately and then delete all copies, including= any attachments. --_000_BL1PR03MB5974F468D148E01EEE6F75EDA5F39BL1PR03MB5974namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A few thoughts about various topics in this thread/= related threads:

 

  • Technically, there is no need to match any claim with a correspondi= ng SIP header
      • =
    • Claim value can be used directly
    • The only exc= eption is orig/dest matching to From/PAI and Request-URI
    • As these are needed to link the PASSporT with a particular call -at= least as good as it gets together with freshness check-
  • With Identity header, we have the luxury of e2e delivery=
  • Expecting this for other SIP headers is not realistic/a very risky = assumption -at least not in the short-term-
  • Keeping “crn” in “rcd” is practically the r= ight decision IMHO
  • Having a standard set of “c= rn” values could be useful
    • It is probably a good idea to allow non-standard values as well
    • It is true that there won’t be any guarantees on = the honest use of the value except the implicit trust/business relationshi= p/assumed reputation of the signer
    • I think there wou= ld be deployment scenarios where such implicit trust can be assumed on a p= er signer basis and this would  allow downstream elements/entities to= apply certain policies based on “crn” content

     

    Thanks,

    Tolga

    From: stir <stir-bounces@ietf.org> = On Behalf Of DOLLY, MARTIN C
    Sent: Wednesday, April 13, 2022 5:44 PM
    To: Gorman, Pierce <Pierce.Gorman@t-mobile.com>; Ranjit Avasa= rala <ranjitkav12@gmail.com>
    Cc: Chris Wendt <chris-ietf@chriswendt.net>; Ben Campbell <= ;ben@nostrum.com>; SIPCORE <sipcore@ietf.org>; IETF STIR Mail Lis= t <stir@ietf.org>
    Subject: [EXTERNAL] Re: [stir] [sipcore] draft-ietf-sipcore-callinf= o-04 (call-reason)

     

    At the NNI, stripping is based on interconnection

    Agreements

    From: stir <stir-bounces@ietf.org> on behalf of Gorman, Pierce <Pierce.Gorman@t-mobile.com>
    Sent: Wednesday, April 13, 2022 5:27:00 PM
    To: Ranjit Avasarala <r= anjitkav12@gmail.com>
    Cc: Ben Campbell <ben@nostrum= .com>; SIPCORE <sipcore@ietf= .org>; IETF STIR Mail List <sti= r@ietf.org>; Chris Wendt <chris-ietf@chriswendt.net>
    Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-= reason)

     

    Hi Ranjit=

     

    I didn’t say a service provide= r SBC could strip the Subject and Call-info headers.  I implied the = SBC was likely to be configured to strip those headers.  i.e., not po= ssible, probable.

     

    All sorts of foo gets sent in SIP to= service providers whether accidentally or intentionally.  Either way= , SIP INVITEs routinely get stripped of extraneous non-essential headers to reduce interworking problems and potential attacks.

     

    I do agree the contents could be map= ped to get across the SBC boundary and where I would map them to is the RC= D PASSporT in a SIP Identity header.

     

    BR, Pierce

     

    From: Ranjit Avasarala <ranjitkav12@gmail.com>
    Sent: Wednesday, April 13, 2022 4:00 PM
    To: Gorman, Pierce <Pierce.Gorman@t-mobile.com>
    Cc: Ben Campbell <ben@nostrum= .com>; Chris Wendt <chris-ietf@chriswendt.net>; IETF STIR Mail List <stir@ietf.org>; SIPCORE <sipcore@ietf.org>
    Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-= reason)

     

    =

    [External]=

     

    Hi Pierce

     

    Yes I do agree that SBC could strip the call-info = header and not pass it through. But in case the information contained in t= hat header is needed downstream like by CSCF, then SBC could map the conte= nts of the Call-Info header to a new Private header and send it across.

     

    Regards

    Ranjit

     

    On Tue, Apr 12, 2022 at 3:59 PM Gorman, Pierce <= ;Pierce.Gorman@t-mobile.com<= /a>> wrote:

    = Could be passed through, yes, but you’ll need to defin= e “if needed”.

     

    The general policy for inbound SIP t= raffic of the service provider I was employed by for more than 30 years, i= ncluding in my role as lead SBC design engineer, was to strip proprietary and non-essential SIP headers at the untrusted i= nterface of the SBC.  Call-Info in particular would be in that catego= ry since it can include URLs which refer to goodness knows what.

     

    Ben said, “there is the= question of whether SBCs will mess with either” (head= er), and my opinion is he is right, there is a question, and my opinion is fol= ks should assume, yes, those headers are at risk of being stripped (as the= y most likely are today).

     

     

    From: Ranjit Avasarala <ranjitkav12@gmail.com>
    Sent: Tuesday, April 12, 2022 3:47 PM
    To: Gorman, Pierce <Pierce.Gorman@t-mobile.com>
    Cc: Ben Campbell <ben@nostrum.com>; Chris Wendt <chris-ietf@chriswendt.net>; IE= TF STIR Mail List <s= tir@ietf.org>; SIPCORE <sipcore= @ietf.org>
    Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-= reason)

     

    =

    [External]=

     

    Depends on policy, but they could be passed thru t= o if needed

     

    Regards

    Ranjit

     

    On Tue, Apr 12, 2022 at 3:23 PM Gorman, Pierce <= ;Pierce.Go= rman@t-mobile.com> wrote:

    I assume Call-Info or Subject are likely to be stripped b= y SBCs.

     

     

    From: stir <stir-bounces@ietf.org> On Behalf Of Ben Campbell
    Sent: Tuesday, April 12, 2022 3:18 PM
    To: Chris Wendt <chris-ietf@chriswendt.net>
    Cc: IETF STIR Mail List <stir@ietf.org>; SIPCORE <sipcore@ietf.org>; Henning Schulzrinne &= lt;hgs@cs.columbi= a.edu>
    Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-= reason)

     

    =

    [External]=

     

    (as individual)

     

    (as individual)

     

    Apologies for coming to this thread late.

     

    I agree we should keep the crn claim for “rc= d” passports at this point. I also understand there to be some imple= mentations that either use it or plan to use it..

     

    I don’t have a strong opinion on the Callinf= o param vs Subject question, as long as we have a consistent mapping. I gu= ess there is the question of whether SBCs will mess with either, but I don= ’t know if that is more likely for one or the other. 

     

    Thanks!

     

    Ben.

     

    On Mar 20, 2022, at 10:47 AM, Chris Wendt <chris-ietf@chri= swendt.net> wrote:

     

    Hi Henning,

     

    Just to focus on call-reason for passport-rcd a= t the moment, we do have that, it is an independent claim “crn”= ; explicitly separate from the “rcd” claim. It is defined in same passport-rcd document, but that doesn’t change how it’s = defined or used. I think one hopefully simple fix is to maybe reference Su= bject as a mapping for this claim and maybe point to callinfo-rcd in a mor= e generic way that we can further discuss subject vs callinfo in the sipcore draft as we move that forward.  As i unde= rstand it, most implementations are focused on passport-rcd at the moment,= so i don’t want to hold that up if possible.

     

    To everyone,

     

    It would be great to get further input on this = whether anyone has strong feelings about using Subject vs callinfo paramet= er call-reason.  I have the sense that there isn’t yet much implementation if any at all (of callinfo/call-reason, i believe= there is implementation of passport-rcd “crn”), and there won= 't strong feeling one way or the other, but if anyone does have strong fee= lings please speak up.

     

    -Chris

     

    On Mar 19, 2022, at 3:25 PM, Henning Schulzrinn= e <hgs@cs.colu= mbia.edu> wrote:

     

    Hi Chris,

     

    tl;dr: My suggestions are: (1) leave call purpo= se out of draft-ietf-stir-passport-rcd; (2) drop call-purpose from&nb= sp;draft-ietf-sipcore-call-info-rcd; (3) consider a new JWT claim "subject" [or whatever] that encapsulates the signed call= purpose in the future.

     

    More details inline below.

     

    On Fri, Mar 18, 2022 at 5:17 PM Chris Wendt <= ;chris-ietf= @chriswendt.net> wrote:

    Hi Henning,

     

    I understand what you are saying.  I do ho= wever think there is reasons to protect call-reason/Subject of call. = I think these situations are mostly in the context of delegation to perhaps a call center, where you have authorized them to represent you= r company in particular ways, including not only your identity, but for di= fferent context of calls that you have authorized them to represent you.&n= bsp; We all know there is some call centers that use call identities with good reputation for customers that may expl= oit that reputation for other customers.  I would look at this as sim= ilar situation.

     

    I think we generally agree - your example of a = call center is probably, in my view, the most likely case where some indic= ation of call purpose will be used, probably with explicit arrangement with the carrier. This may well turn out to be simil= ar to the current model for SMS, where (in the US and some other countries= ) you'll have to register your "campaign" with the carrier or de= signated third party. This may even take the notion of a template ("This call is about your recent order from {da= te}") that can be auto-enforced. It's clear that carriers seem quite = concerned about their individual customers messaging, in volume, to their = subscribers, given the abuse.

     

     

    There is also potential for future of Subject/c= all-reason to be more than just a text string.

     

    I suspect that's best handled separately, once = we have a clearer use case. I don't think we can just stick this into call= -reason without all kinds of backwards-compatibility issues. 

     

     

    I’m struggling a bit on your point that w= e should sign some data but not other data because it is less likely to be= manipulated.  Is that the bar we should be striving for here? Seems to conflict with my understanding of some of the goals.

     

    Maybe this indicates that we should be clearer = on the goals. My take on the value of STIR "classic" (for TNs) i= s that the main purpose of signing is to make it clear who is responsible for the information provided - thus, the whole discussion = of A/B/C attestation. Indeed, the experience seems to indicate that C-leve= l attestation is actually a signal for a robocall, i.e,. C-level calls are= *more* likely to be robocalls than unsigned calls. A/B/C obviously have the same cryptographic strength and = all prevent modification by third parties.

     

    I don't think that carrier manipulation of the = caller information (except in various normalization ways) has ever been a = major problem - it's originator (OSP or end user) spoofing. This is rather different than=20the typical threat model where = the originator worries about evil Mallory changing their data, e.g., by re= directing a money transfer to them.

     

    But for call-purpose, this is less relevant - t= his is clearly (mostly) useful if inserted by the originating caller, and = unlike for A-level attestation, the carrier can't really validate that the message is truthful. How would it know that &quo= t;You have won a cruise!" in the call-purpose/Subject was correct or = a scam? Indeed, as mentioned, if I were a carrier, I'd never want to attes= t to that purpose, as somebody could reasonably claim that the carrier should have known that the recipients hadn't won a= nything.

     

    This is the main reason that I think this shoul= d be a separate claim - if anybody should sign/attest this, it's the = enterprise call center and only that call center.

     

     

    Why not have the framework that we can do that.=   You are free to protect or not protect data depending on your own p= olicy. 

     

    Nothing wrong as such. My argument is that RCD = and call-purpose/Subject are very different, so they shouldn't be in the *= same* framework. If we need Subject/call-purpose, they should be in separate claims, for the operational reasons mentioned.=  

     

     

    I guess i want to be sure whether you are react= ing to us not using Subject vs call-info as a common container for “= rich call data” related info or that we have both call-info and ‘rcd’ as a container for Rich Call Data more generally?&n= bsp; I think there is many reasons why we landed there, we can re-hash tha= t in the context of call-info vs subject.  I would be less excited ab= out re-hashing it for passport/rcd.

     

    For the reasons above, I think this is a bad id= ea for both cases, in my view. It's worse for Call-Info, because= of the duplication of existing functionality.

     

    To use an analogy: The RCD is mostly like a bus= iness card. We don't typically write our contracts and messages on busines= s cards - we might staple our business card to a note.

     

    My constructive suggestion is to create a separ= ate claim if needed. (My understanding is that rcd-14 does not contain the= call purpose, so this is the current state.)

     

     

    I do believe both of these frameworks need to b= e extensible, i don’t think we are finished.  We can define mor= e passport extensions, but at the same time, do we want to redefine “rcd” and “rcdi” for new passport extensions?

     

    No, we should create, in my view, a separate do= cument that focuses on signing the call purpose, expressed either as Subje= ct (as the compact form) or an explicit JWT claim, such as "subject".

     

     

    -Chris

     

     

     

    _______________________________________________=
    sipcore mailing list
    sipcore@iet= f.org
    https://www.ietf.org/mailman/listinfo/sipcore<= o:p>

     

    _______________________________________________ sipcore mailing list
    sipcore@ietf.org=
    https://www.ietf.org/mailman/listinfo/sipcore


    Notice: This e-mail together with any attachments may contain information = of Ribbon Communications Inc. and its Affiliates that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, dis= closure, reliance or distribution by others or forwarding without express = permission is strictly prohibited. If you are not the intended recipient, = please notify the sender immediately and then delete all copies, including= any attachments.
    --_000_BL1PR03MB5974F468D148E01EEE6F75EDA5F39BL1PR03MB5974namp_--

    Hi Ranji= t

     

    I didn=92t say a s= ervice provider SBC could strip the Subject and Call-info headers.  I implied the S= BC was likely to be configured to strip those headers.  i.e., not poss= ible, probable.

     

    All sorts of foo g= ets sent in SIP to service providers whether accidentally or intentionally.=   Either way, SIP INVITEs routinely get stripped of extraneous non-essential headers to reduce interworking problems and po= tential attacks.

     

    I do agree the con= tents could be mapped to get across the SBC boundary and where I would map = them to is the RCD PASSporT in a SIP Identity header.

     

    BR, Pierce<= /span>

     

    From: Ranjit Avasarala <ranjitkav12@gmai= l.com>
    Sent: Wednesday, April 13, 2022 4:00 PM
    To: Gorman, Pierce <Pierce.Gorman@t-mobile.com>
    Cc: Ben Campbell <ben@nostrum.com>; Chris Wendt <chris-ietf= @chriswendt.net>; IETF STIR Mail List <stir@ietf.org>; SIPCORE <= ;sipcore@ietf.org>
    Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-r= eason)

     

    <= b>[External]

     

    Hi Pierce

     

    Yes I do agree that SBC could strip the call-info = header and not pass it through. But in case the information contained in th= at header is needed downstream like by CSCF, then SBC could map the content= s of the Call-Info header to a new Private header and send it across.

     

    Regards

    Ranjit

     

    On Tue, Apr 12, 2022 at 3:59 PM Gorman, Pierce <= ;Pierce.Gorman@t-mobile.com> wrote:

    Could be passed through, yes, but you=92ll need t= o define =93if needed=94.

     

    The general policy for i= nbound SIP traffic of the service provider I was employed by for more than = 30 years, including in my role as lead SBC design engineer, was to strip proprietary and non-essential SIP headers at the un= trusted interface of the SBC.  Call-Info in particular would be in tha= t category since it can include URLs which refer to goodness knows what.

     

    Ben said, =93ther= e is the question of whether SBCs will mess with either=94 (header), and my opinion is he is right, there is a question, and my opini= on is folks should assume, yes, those headers are at risk of being stripped= (as they most likely are today).

     

     

    From: Ranjit Avasarala <ranjitkav12@gmail.com= >
    Sent: Tuesday, April 12, 2022 3:47 PM
    To: Gorman, Pierce <Pierce.Gorman@t-mobile.com>
    Cc: Ben Campbell <ben@nostrum.com>; Chris Wendt <chris-ietf@chriswendt.net>; IETF = STIR Mail List <stir@= ietf.org>; SIPCORE <sipcore@= ietf.org>
    Subject: Re: [sipcore] [stir] draft-ietf-sipcore-callinfo-04 (call-r= eason)

     

    <= b>[External]

     

    Depends on policy, but they could be pa= ssed thru to if needed

     

    Regards

    Ranjit

     

    On Tue, Apr 12, 2022 at 3:23 PM Gorman,= Pierce <Pierce.Gorman@t-mobile.com> wrote:

    I assume Call-Info or Subject are likely to = be stripped by SBCs.

     

     

    From: stir <stir-bounces@ietf.org> On Behalf Of Ben Campbell
    Sent: Tuesday, April 12, 2022 3:18 PM
    To: Chris Wendt <chris-ietf@chriswendt.net>
    Cc: IETF STIR Mail List <stir@ietf.org>; SIPCORE <sipcore@ietf.org>; Henning Schulzrinne <= ;hgs@cs.columbia.e= du>
    Subject: Re: [stir] [sipcore] draft-ietf-sipcore-callinfo-04 (call-r= eason)

     

    <= b>[External]

     

    (as individual)

     

    (as individual)

     

    Apologies for coming to this thread lat= e.

     

    I agree we should keep the crn claim fo= r =93rcd=94 passports at this point. I also understand there to be some imp= lementations that either use it or plan to use it..

     

    I don=92t have a strong opinion on the = Callinfo param vs Subject question, as long as we have a consistent mapping= . I guess there is the question of whether SBCs will mess with either, but = I don=92t know if that is more likely for one or the other. 

     

    Thanks!

     

    Ben.

     

    On Mar 20, 2022, at 10:47 AM, Chris Wen= dt <chris= -ietf@chriswendt.net> wrote:

     

    Hi Henning,

     

    Just to focus on call-reason for pas= sport-rcd at the moment, we do have that, it is an independent claim =93crn= =94 explicitly separate from the =93rcd=94 claim. It is defined in same passport-rcd document, but that doesn=92t change how it=92= s defined or used. I think one hopefully simple fix is to maybe reference S= ubject as a mapping for this claim and maybe point to callinfo-rcd in a mor= e generic way that we can further discuss subject vs callinfo in the sipcore draft as we move that forward.  As= i understand it, most implementations are focused on passport-rcd at the m= oment, so i don=92t want to hold that up if possible.

     

    To everyone,

     

    It would be great to get further inp= ut on this whether anyone has strong feelings about using Subject vs callin= fo parameter call-reason.  I have the sense that there isn=92t yet much implementation if any at all (of callinfo/call-reas= on, i believe there is implementation of passport-rcd =93crn=94), and there= won't strong feeling one way or the other, but if anyone does have strong = feelings please speak up.

     

    -Chris

     

    On Mar 19, 2022, at 3:25 PM, Henning= Schulzrinne <h= gs@cs.columbia.edu> wrote:

     

    Hi Chris,

     

    tl;dr: My suggestions are: (1) leave= call purpose out of draft-ietf-stir-passport-rcd; (2) drop call-purpo= se from draft-ietf-sipcore-call-info-rcd; (3) consider a new JWT claim "subject" [or whatever] that encapsulates the si= gned call purpose in the future.

     

    More details inline below.

     

    On Fri, Mar 18, 2022 at 5:17 PM Chri= s Wendt <= chris-ietf@chriswendt.net> wrote:

    Hi Henning,

     

    I understand what you are saying.&nb= sp; I do however think there is reasons to protect call-reason/Subject of c= all.  I think these situations are mostly in the context of delegation to perhaps a call center, where you have authorized them to = represent your company in particular ways, including not only your identity= , but for different context of calls that you have authorized them to repre= sent you.  We all know there is some call centers that use call identities with good reputation for custom= ers that may exploit that reputation for other customers.  I would loo= k at this as similar situation.

     

    I think we generally agree - your ex= ample of a call center is probably, in my view, the most likely case where = some indication of call purpose will be used, probably with explicit arrangement with the carrier. This may well turn out to be s= imilar to the current model for SMS, where (in the US and some other countr= ies) you'll have to register your "campaign" with the carrier or = designated third party. This may even take the notion of a template ("This call is about your recent order from = {date}") that can be auto-enforced. It's clear that carriers seem quit= e concerned about their individual customers messaging, in volume, to their= subscribers, given the abuse.

     

     

    There is also potential for future o= f Subject/call-reason to be more than just a text string.

     

    I suspect that's best handled separa= tely, once we have a clearer use case. I don't think we can just stick this= into call-reason without all kinds of backwards-compatibility issues. 

     

     

    I=92m struggling a bit on your point= that we should sign some data but not other data because it is less likely= to be manipulated.  Is that the bar we should be striving for here? Seems to conflict with my understanding of some of the = goals.

     

    Maybe this indicates that we should = be clearer on the goals. My take on the value of STIR "classic" (= for TNs) is that the main purpose of signing is to make it clear who is responsible for the information provided - thus, the whole di= scussion of A/B/C attestation. Indeed, the experience seems to indicate tha= t C-level attestation is actually a signal for a robocall, i.e,. C-level ca= lls are *more* likely to be robocalls than unsigned calls. A/B/C obviously have the same cryptographic strength = and all prevent modification by third parties.

     

    I don't think that carrier manipulat= ion of the caller information (except in various normalization ways) has ev= er been a major problem - it's originator (OSP or end user) spoofing. This is rather different than the typical threat model= where the originator worries about evil Mallory changing their data, e.g.,= by redirecting a money transfer to them.

     

    But for call-purpose, this is less r= elevant - this is clearly (mostly) useful if inserted by the originating ca= ller, and unlike for A-level attestation, the carrier can't really validate that the message is truthful. How would it know that= "You have won a cruise!" in the call-purpose/Subject was correct= or a scam? Indeed, as mentioned, if I were a carrier, I'd never want to at= test to that purpose, as somebody could reasonably claim that the carrier should have known that the recipients hadn't won an= ything.

     

    This is the main reason that I think= this should be a separate claim - if anybody should sign/attest this,= it's the enterprise call center and only that call center.

     

     

    Why not have the framework that we c= an do that.  You are free to protect or not protect data depending on = your own policy. 

     

    Nothing wrong as such. My argument i= s that RCD and call-purpose/Subject are very different, so they shouldn't b= e in the *same* framework. If we need Subject/call-purpose, they should be in separate claims, for the operational reasons mentioned.&= nbsp;

     

     

    I guess i want to be sure whether yo= u are reacting to us not using Subject vs call-info as a common container f= or =93rich call data=94 related info or that we have both call-info and =91rcd=92 as a container for Rich Call Data more genera= lly?  I think there is many reasons why we landed there, we can re-has= h that in the context of call-info vs subject.  I would be less excite= d about re-hashing it for passport/rcd.

     

    For the reasons above, I think this = is a bad idea for both cases, in my view. It's worse for Call-Inf= o, because of the duplication of existing functionality.

     

    To use an analogy: The RCD is mostly= like a business card. We don't typically write our contracts and messages = on business cards - we might staple our business card to a note.

     

    My constructive suggestion is to cre= ate a separate claim if needed. (My understanding is that rcd-14 does not c= ontain the call purpose, so this is the current state.)

     

     

    I do believe both of these framework= s need to be extensible, i don=92t think we are finished.  We can defi= ne more passport extensions, but at the same time, do we want to redefine =93rcd=94 and =93rcdi=94 for new passport extensions?

     

    No, we should create, in my view, a = separate document that focuses on signing the call purpose, expressed eithe= r as Subject (as the compact form) or an explicit JWT claim, such as "subject".

     

     

    -Chris

     

     

     

    ____________________________________= ___________
    sipcore mailing list
    sipcore@iet= f.org
    https://www.ietf.org/mailman/listinfo/sipcor= e

     

    _______________________________________= ________
    sipcore mailing list
    sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore