From nobody Fri Nov 2 09:15:05 2018 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 016CC123FFD; Fri, 2 Nov 2018 09:14:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini To: Cc: draft-ietf-stir-passport-shaken.all@ietf.org, stir@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154117528787.7013.6199833371829068074@ietfa.amsl.com> Date: Fri, 02 Nov 2018 09:14:47 -0700 Archived-At: Subject: [stir] Genart last call review of draft-ietf-stir-passport-shaken-04 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: Fri, 02 Nov 2018 16:14:48 -0000 Reviewer: Francesca Palombini Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-stir-passport-shaken-04 Reviewer: Francesca Palombini Review Date: 2018-11-02 IETF LC End Date: 2018-11-02 IESG Telechat date: Not scheduled for a telechat Summary: This draft is on the right track but has open issues, described in the review. Major issues: * This draft defines the new claim "origid" for the Personal Attestation Token used in the SHAKEN framework, but does not give any privacy considerations about it and its use. [RFC6973] suggests that the privacy considerations of IETF protocols be documented. As required by [RFC7258], work on IETF protocols needs to consider the effects of pervasive monitoring and mitigate them when possible. I don't know SHAKEN well enough to comment on privacy issues on that, but this draft, as part of the IETF work, should have privacy considerations, particularly considering the "origid" claim. Minor issues: * Section 4: the term "verified association" is not defined in this document, nor in [RFC8225], nor in the SHAKEN spec referenced. Is there a way to clarify what is meant by it? It could be a reference. Nits/editorial comments: * Terminology: I would have appreciated a short sentence mentioning [RFC8225] in the Terminology section. * Section 9: [RFC8224] appears without link. * Acknowledgements: "The authors would like acknowledge the work of the ATIS/SIP Forum IP-NNI Task Force to develop the concepts behind this document." -> The authors would like to acknowledge ... I do not repeat nits and editorials reported by Adam Roach in his review of this version of the document (11-19-2018, https://mailarchive.ietf.org/arch/msg/stir/HxVSCLPGfSgwFuvqLkWSVNI0PtQ ) From nobody Fri Nov 2 19:48:17 2018 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 50FD812777C; Fri, 2 Nov 2018 19:48:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Takeshi Takahashi To: Cc: draft-ietf-stir-passport-shaken.all@ietf.org, stir@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154121328916.19556.15556330091107353459@ietfa.amsl.com> Date: Fri, 02 Nov 2018 19:48:09 -0700 Archived-At: Subject: [stir] Secdir last call review of draft-ietf-stir-passport-shaken-04 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: Sat, 03 Nov 2018 02:48:10 -0000 Reviewer: Takeshi Takahashi Review result: Ready I do not have any particular concerns on the Security Considerations section. As mentioned in the section, the proposed extension will not pose any particular threats to the base specification. Having said that, I have minor comments and clarification questions as an individual who has read this document without prior knowledge of this topic. 1. In the abstract, The sentence "from ATIS .... Joint Task Force" will not be neceaary. For those who are familiar with SHAKEN specification, this sentence is obvious. For those who are not familiar with SHAKEN, this sentence will not provide any information that may facilitate the understanding of the overview of the draft. In either cases, the sentence will not be necessary. "to include information defined as part of ..." had better be refined further. I believe the readers wish to know the details (incl., types) of the information instead of where the specification was once defined. 2. In the abstract and/or introduction, STIR should be spelled out. I guess it is Secure Telephony Identity Revisited. 3. Terminology I feel that you use the terms "claims" and "indicators" for pointing to the same objects. If that's the case, I hope you could choose to use only one of them. Example of the use of two terminologies. 1. In the introduction, you have the sentence "This document specifies these indicators...". 2. In the introduction, you have the sentence "there are two additional claims..." 3. The title of section 4 is "Passport attest claim". and so on. 4. In section 5 "PASSporT origid claim", There is a sentence "There will likely be best practices documents that more precisely guide it's usage in real deployments". If you have such a document (including work-in-progress drafts), having a reference to this sentence will be appreciated. If there is no reference, I do not think we need this sentence here. 5. orig and origid claims If I understood correctly, both orig and origid represent identifies the same objects (including service provider-initiated calls, customers, classes of devices, etc.) In this case, if the object identified by orig and the one identified by origid is not the same, how should the receiver interpret these claims? 6. section 7 I am a bit confused. If the use of "attest" and "origid" is already defined elsewhere, what does this document define? Is the document define the use of those claims for some other protols (other than SIP)? 7. security consideration. As mentioned in this section, the values of the new "attest" and "origid" claims added by this extension are not used in the current validation step. Then, do you think we should encourage people to have another step that validates those claims added by this extension? I would appreciate your answers on these issues. From nobody Sat Nov 3 19:55:50 2018 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 9E98012F1A6 for ; Sat, 3 Nov 2018 19:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 UfVBcPhRDKlk for ; Sat, 3 Nov 2018 19:55:47 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 96318130D7A for ; Sat, 3 Nov 2018 19:55:46 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id p16-v6so2770659plr.8 for ; Sat, 03 Nov 2018 19:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q73VO2uYg2HweHeFp9uK5xIprM7Gyf6Kz1SaS+EuW/g=; b=X78h2ZhRC5X6ujfpfYeWVqiw0jvTsAk6Xvvq9/1D5p/XP9N7hgEK3+KO9FnPwH37CP K0y/HBoLHWqF7kFCbw6JyR/76WTVkxdzc85uqXpKXPfuE/sVJh8G+YOtdRIkT2PUFUDV Ue6yTsiFNY9DcsmTm4EllIrs4042gHKivikpe3PL7vggY8LKktCCcZcYUb+/PeohpYUj HYQrQ551mjruRSq5p5l89ipqjE1y0G9Aq3zZsmmoB5GuH7t/kjt1rYBitgQoiBKRxLg2 Qe4uE29OXf7VCusO25L4xYhwX7lwfMGMf2cU3XRl9qF+Uk+l49s2OFjPmAmRJMKfTxNX HK7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q73VO2uYg2HweHeFp9uK5xIprM7Gyf6Kz1SaS+EuW/g=; b=MIT02pygmGAxbJriqUiEye7DIVqsIfRDDYbwpdZMbam4AQx7JPcbCRE0jBZkzimmzj cEZM6DitUqSqD0ZlU2No2qiae/bAM42DawYbY6yYB9Hv7so/oN/96MP9H05RuJ+rDFQB +JjggyZ/R6rKRt7CNcwEizXu+KqpYaS0GHKAPSZtQzWuFEKRS0JavFJEZvgVbei1ADU+ +c4k99LfGE+tJiKS4lYXSmcO1Ponw+XBsV5v/TCq3bb652AIyCoE0F6jycXHhX3fHfXs e2qZ2zaao22r1jzvTIFNtWeWGIuwpgtAelVV1+o7AHzVQPTH4FnuiJVDnqByBsxRol+k 0KJw== X-Gm-Message-State: AGRZ1gKusR0Frk55Mh/+yvzTFVEo0dqGCUl8Z/Y6lMeUTxlX6OCSDdya JT+bYR5Zp0Q1U+r/6KnCiOXZbw== X-Google-Smtp-Source: AJdET5eHZ+Tq+RmKaT/Gm0S2N076OZIFq+uDePqnuy9FnKZf69wLwR5ihthx35E0IQnFXuh//HqUYw== X-Received: by 2002:a17:902:b612:: with SMTP id b18-v6mr17557566pls.205.1541300146070; Sat, 03 Nov 2018 19:55:46 -0700 (PDT) Received: from [10.64.40.10] ([193.37.254.131]) by smtp.gmail.com with ESMTPSA id k72-v6sm84326262pfj.63.2018.11.03.19.55.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Nov 2018 19:55:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: <9237bcc9-9124-24a2-1e95-77715d309daa@nostrum.com> Date: Sat, 3 Nov 2018 22:55:40 -0400 Cc: draft-ietf-stir-passport-shaken@ietf.org, "stir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8745D5CB-F430-4BD8-B560-5B073B9DD9BE@chriswendt.net> References: <9237bcc9-9124-24a2-1e95-77715d309daa@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-passport-shaken-04 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: Sun, 04 Nov 2018 02:55:49 -0000 Hi Adam,=20 Thanks for the review, i have addressed all of your comments in a = forthcoming 05 draft release. -Chris > On Oct 19, 2018, at 7:54 PM, Adam Roach wrote: >=20 > This is my AD review for draft-ietf-stir-passport-shaken-04. I have a = handful > of comments below that I'd like to see addressed prior to asking the = IESG to > consider the document. Please treat them as you would any other = last-call > comments. I have no blocking comments, and will be placing the = document > in IETF last call shortly. >=20 > Thanks to everyone who worked on this document. >=20 > /a >=20 > = --------------------------------------------------------------------------= - >=20 > Abstract: >=20 > > Industry Solutions) and the SIP Forum IP-NNI Joint Task Force. = These >=20 > Please expand "IP-NNI". >=20 > > coming from both STIR participating originating communications as >=20 > Please expand "STIR" on first use. >=20 > Also, as "STIR-participating" is a compound adjective, it needs to be > hyphenated. With the expansion, this would look like: >=20 > coming from both SIP Telephony Identity Revisited = (STIR)-participating > originating communications as... >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A71: >=20 > > The SHAKEN [ATIS-1000074] specification defines a framework for = using > > STIR protocols including PASSporT [RFC8225], SIP Authenticated > ... > > current telephone network contains both VoIP and TDM/SS7 originated >=20 > For the purposes of acronym expansion, the Abstract is not treated as = part of > the document. Please expand SHAKEN, STIR, PASSporT, VoIP, TDM, and SS7 = on > first use. See = https://www.rfc-editor.org/materials/abbrev.expansion.txt for > more details. >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A72: >=20 > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this > > document are to be interpreted as described in [RFC2119]. >=20 > Please update to the boilerplate in RFC 8174. >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A73: >=20 > > and represents the service provider receiving a call from a non > > PASSporT or STI supporting telephone gateway. >=20 > Nit: "...from a non-PASSporT- and non-STI-supporting telephone = gateway." >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A74: >=20 > > can be one of the following three values, 'A', 'B', or 'C' as = defined > > in [ATIS-1000074]. >=20 > Nit: "...one of the following three values: 'A', 'B',..." >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A75: >=20 > > opaque identifier corresponding to the service provider-initiated > > calls themselves, >=20 > Nit: "...service-provider-initiated calls..." >=20 > > documents that more precisely guide it's usage in real deployments. >=20 > Nit: "...its usage..." >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A76: >=20 > > "orig":{"tn":"12155551212"}, >=20 > The NANPA has reserved the range "555-0100" through "555-0199" in all = area > codes for fictitious use. The number used in this example is a valid = number > allocated for directory assistance use. Consider using "12155550121" = (or some > similarly reserved number for this example. See > https://www.nationalnanpa.com/number_resource_info/555_numbers.html = for more > information. >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A77: >=20 > > [RFC3261] aligned with the use of the identity header defined in >=20 > Nit: "...identity header field..." >=20 >=20 >=20 From nobody Sun Nov 4 04:55:27 2018 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 E1D3212D4EC for ; Sun, 4 Nov 2018 04:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 wBgrTItTMtFU for ; Sun, 4 Nov 2018 04:55:22 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 4CDD7130DD9 for ; Sun, 4 Nov 2018 04:55:22 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id r64-v6so3085441pfb.13 for ; Sun, 04 Nov 2018 04:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v5E+wxqgPXszN8irqo42hOyb5syHQ7h0DGqGjjxOuqc=; b=MPJAgqUT2FJvg3nK0OIH5suO+wlr/DSCMr4gkvPl/fw2QeXo69/Z1eJvFUaiQ0+0xl uuXWSHPfL+eNZUYvaZ2NtrTmg42ctOgXN/VTW/wd84c5jWevdlz/aqFEhS3EFhT+R8rs fnq0fnLQ2jc3WrqYQ7yZ8dh/lplfPXna6IImn46gnesLKYqi6VRzJzXayQ45wuc8oQ3a iXiS5YA/TrUyVAlvfU6E63u9eGbAcRNDLWz648XqwhNtx+lqlEXGfZcw3BaTY1AIVvYd 0ikHQ/pXCsm4TvDGcFC8Kig8XjM0ATd3ukqGH6AgwxZHeDhSJQNoeFWfLUJYSoCIAZRO 1ssQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v5E+wxqgPXszN8irqo42hOyb5syHQ7h0DGqGjjxOuqc=; b=rA5gSbQTLh937anxz0lExXDCjzEJMiGk9PRdWZzlPFxbCOXtVv1mZtjmo+B1LbK64q VZO8FhGlz0dKTW6dNFIbf1BYZvIw3Qk4IsBL89uE+nIPHc9di5L60stXeFOzVuwOB4/V 0jWvi8Jj4VhBzRmrvgfWkWMmtvIqDf6Drmm+6IV8ucarMbufGdlKMfxmeM0649I6onBf Tr+dq9VLQKZvpKMmhaXoiJFKIIPZ3O3c6nM2n/u4HDlLN/PJe2jP/BYwBPvsEM36Kgix kpIvb64UnNxW7+bxWXDhwCS5dfR+uz9fxWIP0vdwfF0jrP+yas7Ff7kxpYIJTcybFp0L U4TA== X-Gm-Message-State: AGRZ1gKe+uWS/0NS2DSInm51r0Q4216NxIQfD5HKiYmJY4GahAgTWlhW fLs4lNOdQRUEEMuGLT8qnmcr0w== X-Google-Smtp-Source: AJdET5eq9dlkauee0KdlrUpM7Jem0vAyeE6GiXhq0vqV6ujFyF39IX+3bAyBZUtT1CDUK6SkY+mGNg== X-Received: by 2002:a62:2ec3:: with SMTP id u186-v6mr18419105pfu.189.1541336121790; Sun, 04 Nov 2018 04:55:21 -0800 (PST) Received: from [10.64.48.6] ([193.37.254.131]) by smtp.gmail.com with ESMTPSA id b16-v6sm42593232pgl.66.2018.11.04.04.55.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 04:55:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: <154117528787.7013.6199833371829068074@ietfa.amsl.com> Date: Sun, 4 Nov 2018 07:55:16 -0500 Cc: gen-art@ietf.org, draft-ietf-stir-passport-shaken.all@ietf.org, "stir@ietf.org Mail List" , ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <50F64DCF-E897-4C3F-B77A-6FBA4F8955C5@chriswendt.net> References: <154117528787.7013.6199833371829068074@ietfa.amsl.com> To: Francesca Palombini X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Genart last call review of draft-ietf-stir-passport-shaken-04 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: Sun, 04 Nov 2018 12:55:25 -0000 Thank Francesca for the review. Comments inline. > On Nov 2, 2018, at 12:14 PM, Francesca Palombini = wrote: >=20 > Reviewer: Francesca Palombini > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-stir-passport-shaken-04 > Reviewer: Francesca Palombini > Review Date: 2018-11-02 > IETF LC End Date: 2018-11-02 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This draft is on the right track but has open issues, = described in the > review. >=20 > Major issues: >=20 > * This draft defines the new claim "origid" for the Personal = Attestation Token > used in the SHAKEN framework, but does not give any privacy = considerations > about it and its use. [RFC6973] suggests that the privacy = considerations of > IETF protocols be documented. As required by [RFC7258], work on IETF = protocols > needs to consider the effects of pervasive monitoring and mitigate = them when > possible. I don't know SHAKEN well enough to comment on privacy issues = on that, > but this draft, as part of the IETF work, should have privacy = considerations, > particularly considering the "origid" claim. Here is my proposed privacy consideration section, looking for any = comments if this addresses things properly given the nature of SIP = privacy in general. Privacy Considerations=20 As detailed in {{RFC3261}} Section 26 as well as {{RFC3323}}, SIP as a = protocol inherently carries identifying information of both the = initiator or 'caller' as well as the terminating party or 'callee'. = 'origid', as defined in SHAKEN {{ATIS-1000074}} and described in this = document is intended to be an opaque and unique identifier that is used = by an originating telephone service provider to trace and identify where = within their network (e.g. from a gateway or a particular service within = their network) the call was initiated, so that either bad actors that = may be either trying to illegitamately spoof identities or making = fraudulent calls can be identified and likely stopped or held = responsibiliy for the fraudulent activities. While the opaqueness of = the 'origid' identifier is intended to keep any direct or implied = information regarding the origination of a set of calls that may have = the same 'origid' to a minimum, it should be recognized that potential = patterns whether intended or not may be able to be discovered. >=20 > Minor issues: >=20 > * Section 4: the term "verified association" is not defined in this = document, > nor in [RFC8225], nor in the SHAKEN spec referenced. Is there a way to = clarify > what is meant by it? It could be a reference. I=E2=80=99ve included a new terminology text as follows to address above = comment and comment below: In addition, the following terms are used in this document: o Verified association: is typically defined as an authenticated relationship with a device that initiated a call, for example, a subscriber account with a specific SIM card or set of SIP credentials. o PASSporT: Defined in [RFC8225] is a JSON Web Token defined specifically for securing the identity of an initiator of personal communication. This document defines a specific extension to PASSporT. >=20 > Nits/editorial comments: >=20 > * Terminology: I would have appreciated a short sentence mentioning = [RFC8225] > in the Terminology section. see above >=20 > * Section 9: [RFC8224] appears without link. fixed >=20 > * Acknowledgements: "The authors would like > acknowledge the work of the ATIS/SIP Forum IP-NNI Task Force to > develop the concepts behind this document." -> The authors would = like to > acknowledge =E2=80=A6 >=20 fixed > I do not repeat nits and editorials reported by Adam Roach in his = review of > this version of the document (11-19-2018, > https://mailarchive.ietf.org/arch/msg/stir/HxVSCLPGfSgwFuvqLkWSVNI0PtQ = ) >=20 I have addressed these issues and plan to submit with list consensus on = above text. From nobody Sun Nov 4 05:41:12 2018 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 D74C1130DCF for ; Sun, 4 Nov 2018 05:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 GVnjuFE498P2 for ; Sun, 4 Nov 2018 05:41:09 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 E16DA120072 for ; Sun, 4 Nov 2018 05:41:08 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id w7so2979802pgp.13 for ; Sun, 04 Nov 2018 05:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yol8NjRV9qTBUvNDK22mHJeF6swpMGF3l0UgggoubwA=; b=OfLC7wEGSVCsBpeeeCnLmKiJ6BWxdOtpvV4POWQtc8HQnVULf3UbZ0MW9pKWLlJQQu 3QHUtmKTNRGXPskBZgyPgXQv8W8kDJ8Zud766wUsScPHmnYXaDoA4kY+AtmeIZroaPVl i2HDgnKTSkNFvdzY0lEX0yzaTpifGvyfGO4AD6xEk/LB7PPpTs6UDNdHa98cXxYQanGV I2qyy/zaC3cZAQnnk0t7Lut0y9y1Zidfgj16o6QqEutKllkV9J/B21iO641SulrMd+CQ Qo/eovTj3bilp/sTqwAg75aFppzTooGudtrudHpqJP3oU7XoIpPKdJLQz6cFe9GB2YMm LaCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yol8NjRV9qTBUvNDK22mHJeF6swpMGF3l0UgggoubwA=; b=spgMaTI8RxVCGYeoz5vAKK5616ulOy504Ze6AnwChlTDW18PZhX7xzcmspLrrOHu/n RaMb9JiLJMOkfDcm0wXK3oSJIQjsl3h/KYjS03JzOwoMUKLLNr00wBlONYAcCyMIb04c YEvXw7K2gcZoi5mqYQeGiSwT6xZEJwta6dOsZHpxpc079sdSQn1BvwytNDzl9o8YDiK5 RWiI+GTqDMDFy/if7+Hqpd3dzMPfuq87jMt5pbo5hvu5DsQURmqKxkAlkpSRigHsC8U0 waw8eZqFbGUEFRExgYUt6fAu+rgIsMzjtXg6Pc9W/0lJtiw6FSpH/qo2JYbAZrtrele4 yeqA== X-Gm-Message-State: AGRZ1gIwd7Ezac9ycqYBqDbS3Oxf8+oqEIFuDyQfof8zEY21Cyakbwp9 ZA0FTihwz+oCPrhY0K6yFdBnIQ== X-Google-Smtp-Source: AJdET5ez7DmB7Yw8MlTXrgLDUzB4GQzH+nlCLEaxrhf5nqTt6ZS+h24iwOqDB3PE3b4a5D+YlzPrfQ== X-Received: by 2002:a63:d048:: with SMTP id s8-v6mr16790339pgi.311.1541338868319; Sun, 04 Nov 2018 05:41:08 -0800 (PST) Received: from [10.64.48.6] ([193.37.254.131]) by smtp.gmail.com with ESMTPSA id 5-v6sm76394690pgt.83.2018.11.04.05.41.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 05:41:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: <154121328916.19556.15556330091107353459@ietfa.amsl.com> Date: Sun, 4 Nov 2018 08:41:02 -0500 Cc: secdir@ietf.org, draft-ietf-stir-passport-shaken.all@ietf.org, stir@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7EF1B0D1-60B1-4735-B322-E581BB0539CC@chriswendt.net> References: <154121328916.19556.15556330091107353459@ietfa.amsl.com> To: Takeshi Takahashi X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Secdir last call review of draft-ietf-stir-passport-shaken-04 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: Sun, 04 Nov 2018 13:41:11 -0000 Hi Takeshi, Thanks for the review, comments inline. > On Nov 2, 2018, at 10:48 PM, Takeshi Takahashi = wrote: >=20 > Reviewer: Takeshi Takahashi > Review result: Ready >=20 > I do not have any particular concerns on the Security Considerations = section. > As mentioned in the section, the proposed extension will not pose any > particular threats to the base specification. >=20 > Having said that, I have minor comments and clarification questions as = an > individual who has read this document without prior knowledge of this = topic. >=20 > 1. In the abstract, >=20 > The sentence "from ATIS .... Joint Task Force" will not be neceaary. > For those who are familiar with SHAKEN specification, this sentence is = obvious. > For those who are not familiar with SHAKEN, this sentence will not = provide any > information that may facilitate the understanding of the overview of = the draft. > In either cases, the sentence will not be necessary. removed >=20 > "to include information defined as part of ..." had better be refined = further. > I believe the readers wish to know the details (incl., types) of the > information instead of where the specification was once defined. Changed the abstract to this: This document extends PASSporT, which is a token object that conveys = cryptographically-signed information about the participants involved in = communications. The extension is defined, corresponding to the SHAKEN = specification, to provide both a specific set of levels-of-confidence to = the correctness of the originating identity for a SIP based = Communication Service Provider (CSP) telephone network originated call = as well as an identifier that allows the CSP to uniquely identify the = origination of the call within its network. >=20 > 2. In the abstract and/or introduction, >=20 > STIR should be spelled out. I guess it is Secure Telephony Identity = Revisited. removed based on last comments but in either case i received this = comment from Adam as well. >=20 > 3. Terminology >=20 > I feel that you use the terms "claims" and "indicators" for pointing = to the > same objects. If that's the case, I hope you could choose to use only = one of > them. >=20 > Example of the use of two terminologies. > 1. In the introduction, you have the sentence "This document specifies = these > indicators...". 2. In the introduction, you have the sentence "there = are two > additional claims..." 3. The title of section 4 is "Passport attest = claim". and > so on. Claim is a specific term used to identify a key value in a JWT payload = defined in RFC7519, indicator is used in a more generic way That said, i changed that sentence to the following: This document specifies these values as claims to extend the base set of = PASSporT claims. replacing =E2=80=9Cindicators" to =E2=80=9Cvalues as claims..." >=20 > 4. In section 5 "PASSporT origid claim", >=20 > There is a sentence "There will likely be best practices documents = that more > precisely guide it's usage in real deployments". If you have such a = document > (including work-in-progress drafts), having a reference to this = sentence will > be appreciated. If there is no reference, I do not think we need this = sentence > here. removed >=20 > 5. orig and origid claims > If I understood correctly, both orig and origid represent identifies = the same > objects (including service provider-initiated calls, customers, = classes of > devices, etc.) In this case, if the object identified by orig and the = one > identified by origid is not the same, how should the receiver = interpret these > claims? orig and origid are not really related at all (although based on the = name i suppose that might be a natural conclusion) orig is the telephone or URI identity, origid is a unique id that = represents to a service provider where the call was originated in it=E2=80= =99s network. I added some of this detail to the abstract, and i believe it exists in = the document, but to fully appreciate the difference you probably do = need to be familiar with both PASSporT and SHAKEN documents. I feel like if i explained this difference again in any new text, it = would get repetitive. >=20 > 6. section 7 > I am a bit confused. If the use of "attest" and "origid" is already = defined > elsewhere, what does this document define? I started this document originally mostly referring to SHAKEN by = reference, but received WG comments that i needed to provide more = details in this document for the context and security considerations to = be appreciated, so to remove that would conflict with that WG opinion. > Is the document define the use of > those claims for some other protols (other than SIP)? No, SHAKEN will only be used in the context of telephone numbers and = SIP. >=20 > 7. security consideration. >=20 > As mentioned in this section, the values of the new "attest" and = "origid" > claims added by this extension are not used in the current validation = step. > Then, do you think we should encourage people to have another step = that > validates those claims added by this extension? SHAKEN does define how these values should be interpreted, i think in = the security considerations, we are only trying to say that the addition = of these claims does not impact or change the security properties that = are already discussed in the PASSporT document. >=20 > I would appreciate your answers on these issues. >=20 From nobody Sun Nov 4 18:49:14 2018 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 D2C0B127148 for ; Sun, 4 Nov 2018 18:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=fM5uIjon; dkim=pass (1024-bit key) header.d=ericsson.com header.b=UVBmwbxT 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 JyWhisbxFWd9 for ; Sun, 4 Nov 2018 18:49:04 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 5F6C5128BCC for ; Sun, 4 Nov 2018 18:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541386142; x=1543978142; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=p3J5IXBPDhSIQciD3yTP1EmrlPFEbJbypmDui46OuTY=; b=fM5uIjonM6c/UquFjaTlnoK0VjxPH0YLRRN/zgciZFa3J5sNUM4IrgMMNyg4uowD 6QVyVW7et8cQiODbGtBfouRDsOScfrNL7VqzzW6ZtW2CbfAG53rP4DMJIEtIL9n0 nwQ/XSlmi9il5gaB0Qbsrkyf0fsVe6WrGRHCN9q1iv0=; X-AuditID: c1b4fb2d-425ff7000000434d-43-5bdfaf9e65da Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 16.6C.17229.E9FAFDB5; Mon, 5 Nov 2018 03:49:02 +0100 (CET) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 5 Nov 2018 03:49:01 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 5 Nov 2018 03:49:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p3J5IXBPDhSIQciD3yTP1EmrlPFEbJbypmDui46OuTY=; b=UVBmwbxTQBH1mp6qZvJYORMx3q6MTLFRUYjhVOmzVKY62MFI0L+V4olzSSmDjN0PgIgd1pyu0JHWXyBeDaoY0qoYsabeMtkcxo5UjkB2GpP+fD/Ik+yNV7HULPJIdGkXHTj5x7R2RRx2u4J2j+Zuo7NnR67fMAYLGlhGTelft/c= Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com (10.173.93.139) by AM5PR0701MB2628.eurprd07.prod.outlook.com (10.173.92.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.16; Mon, 5 Nov 2018 02:48:59 +0000 Received: from AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::b832:cefa:fd12:dfdb]) by AM5PR0701MB2737.eurprd07.prod.outlook.com ([fe80::b832:cefa:fd12:dfdb%3]) with mapi id 15.20.1294.032; Mon, 5 Nov 2018 02:48:59 +0000 From: Francesca Palombini To: Chris Wendt CC: "gen-art@ietf.org" , "draft-ietf-stir-passport-shaken.all@ietf.org" , "stir@ietf.org Mail List" , "ietf@ietf.org" Thread-Topic: Genart last call review of draft-ietf-stir-passport-shaken-04 Thread-Index: AQHUdD2q0tuEP8FRI02bTGQ0/H8A+KVA8RAA Date: Mon, 5 Nov 2018 02:48:59 +0000 Message-ID: <1352291F-B58F-42BC-913E-A7159CE19531@ericsson.com> References: <154117528787.7013.6199833371829068074@ietfa.amsl.com> <50F64DCF-E897-4C3F-B77A-6FBA4F8955C5@chriswendt.net> In-Reply-To: <50F64DCF-E897-4C3F-B77A-6FBA4F8955C5@chriswendt.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [110.170.235.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2628; 6:juUKYvcG646bozXdbLOF87rm+Zezby5Jfhc++pjdnNw7bJuYhWWuEBUasGjzBQSISYYBWSgJ5F2C89Vu0i2HCvvCLlc9Rg6GjLhhc0NbXkTa+z5BbvQsUbrGtB7p8JLC5vfEcy2daM5FC7nG6a/64lKyZdgXn05hZO51Gc5qVyjnqGp9W4NZHG5Vw2rWRU/ZPOLuTTScdxbAXFovHGpnZxXzK2NyBOUoYfQdULMvkrZN8q0r1PBcibtPKTBEu2qG+PGGHDB88JthLKbTFkRt2pnG8ArNINDjzv/Bnzplzi7zDimTzCyve+tO5i+D2dC8/X8kOCu35bpm/IZ6bSje321Pw1uGyt7Coql+Jv5RogH1RAwPbeX33VJraFlP1oMSPZhuWNQbACzVi49pygWuKiz+lnLMvphjowu18Vun1WSGnwXP8mVbuL7SB1utLrXeLWPDSmtBkG1gASdqbfoaYg==; 5:90hqdkAqGabMsJlmXxMfguR7dSiJReALFTyUGFlNiE7WTcaQVLIEKW3bGqKEUXz/ZQOFmDgB4FHyTbP5Y7uhwq1A+/E6YwGoFbFyl7aMPneqMidj8ZsUeSlrbOBrOyN1g6exPBWxhQ/3jUC/iMYs7o6fOCnNzk+IP8yAzaJoNtk=; 7:EihARmBKHDhccbxaFu/ZbDyWtyvmqnbfc4ucuzF4mocS4VErOKxmWV6EgF6XLc6DU9SaX6S0qe6piP/G9qvDk1nkkKoIFtl40ztm/D1GyXoxJSGT9vWQDN0SBVq33IodZWSdxfMccc6c1QMSZ1y3SQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9f313bac-9feb-4d42-b2d6-08d642c93cca x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM5PR0701MB2628; x-ms-traffictypediagnostic: AM5PR0701MB2628: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(72170088055959)(100405760836317)(248295561703944)(37575265505322); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:AM5PR0701MB2628; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2628; x-forefront-prvs: 08476BC6EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(396003)(346002)(366004)(199004)(189003)(6436002)(6246003)(71190400001)(2906002)(2616005)(86362001)(36756003)(476003)(5660300001)(6306002)(71200400001)(575784001)(6486002)(25786009)(81156014)(478600001)(229853002)(14444005)(446003)(11346002)(6512007)(256004)(99286004)(68736007)(55236004)(486006)(76176011)(54906003)(6506007)(6916009)(26005)(97736004)(106356001)(966005)(105586002)(8936002)(53546011)(4326008)(82746002)(33656002)(8676002)(53936002)(14454004)(81166006)(3846002)(2900100001)(186003)(305945005)(66066001)(316002)(83716004)(44832011)(102836004)(6116002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2628; H:AM5PR0701MB2737.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: V/2uvb7YilPbZ8XLYsoxj/yuPljr5FKaYPdRojEsriJuc7K2U4AbDtx5PWMj4K4CUnQzX51Pf84u351yj5TqutttJuVNWDkzi6446QxYdnix8ZlCZglArO2r/6Dz0bDEFbZ3xBhggg2tHo5AZnWsRzuKCl9LMLQphm5Gqfq6tDf8aGyJ+5uxnuY0fPorIXWGGGimbdYUbiB16JRoOebzzNhhB/29kE7rCb+dgXAdD40h+X9z4IjdO3Z+rJwcKxL9gGGBkIL0hasrbURGzsYSIUG2BQv2BlFrGb9IjNi57dd2QCv7M6s1vMFSLZ9FcxZqLGyS41TQWYjZOVzmxng2qWJ/p37lJWAyAQpDr5jMJP4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1A485839E222A248A533C457FFF9A0F7@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9f313bac-9feb-4d42-b2d6-08d642c93cca X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 02:48:59.4389 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2628 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85OzvTFu+m4pOywNGXLlPzAhOkVAy0CCwiQiEbevI+bce8 0QdNQ1Nn85ZosBmJykysTDOdmhpZaShikjdsaJZdvFRSUmkez4K+/d7n/3ve93ngZUi5UeTC xGlTWZ1Wk6ik7ajqc4/SVcaWuQjP3BmluuprF6nuHSsm1a8/fqPUi/dNlLqhuZ0IEIUYSu6K QurqNogwItzOP5pNjEtjdR5HLtjFNpYvEinFPhlXf47Q2eitVyGSMIB9oKhCTxUiO0aOnyLo y74h5gM5XkdQPB0i8B0ChvK8eYnCBhKG21rEQsdNAoYfN9PC4R2C3Nkegm+hsT+MWldEPDvi gzAwnI14icRTCNYsxTQfOODjYCo3IUE6AfmbXbTAXjBpMO/MQeF90PhqfpsZRoqPwsT6KWGk LFifrKZ4luAgmGhd2nkLYQV8z2kieSaxM0wtmAhhTwx1lhFSYCdYmt+0+VEwPl0iFupuMFC/ avMVMGYq2pkZ8BsammtrkRCoYLWy0nbRSTD+WCEFaQxB3u1WW3AIZus/2BqSwaK30gInQs7v dpuzF8x6K2VAXjX/DVuzvSeJ90NLp4eAIVBmDRIMN6gosop5lmIZvKheoGqRyIycOJbjkmK8 vN1ZXVwUxyVr3bVs6gO0/Wv6Hv5SdaCmT4H9CDNIuUtqaJqLkIs0aVxmUj8ChlQ6SgeCt0vS aE1mFqtLjtRdTmS5fuTKUEpnqbvZEi7HMZpUNoFlU1jdv5RgJC7ZKM/+0p3KwQ0GJN1Gk3Et 3yF6prOuX+xHBzSNn95SaK/lRYq3lhXzpUkF5+OHbilC9W2SLwuuM3OD3WVuXNJzP71nacaZ 94z958CKe5UqtxlVY+5mlV6W/kxW/ichpjZ0MGxZ/3L5ybGw0R6JS/zZi7LrvruDO/Y0+Bp6 LVcKZEqKi9UcPkDqOM1fzzyx2jEDAAA= Archived-At: Subject: Re: [stir] Genart last call review of draft-ietf-stir-passport-shaken-04 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, 05 Nov 2018 02:49:08 -0000 VGhhbmtzIENocmlzLCB0aGVzZSBjaGFuZ2VzIGFkZHJlc3MgbXkgcmV2aWV3IGNvbW1lbnRzLg0K DQpGcmFuY2VzY2ENCg0K77u/T24gMDQvMTEvMjAxOCwgMTk6NTUsICJDaHJpcyBXZW5kdCIgPGNo cmlzLWlldGZAY2hyaXN3ZW5kdC5uZXQ+IHdyb3RlOg0KDQogICAgVGhhbmsgRnJhbmNlc2NhIGZv ciB0aGUgcmV2aWV3LiAgQ29tbWVudHMgaW5saW5lLg0KICAgIA0KICAgID4gT24gTm92IDIsIDIw MTgsIGF0IDEyOjE0IFBNLCBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5p QGVyaWNzc29uLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IFJldmlld2VyOiBGcmFuY2VzY2Eg UGFsb21iaW5pDQogICAgPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KICAgID4g DQogICAgPiBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0 LiBUaGUgR2VuZXJhbCBBcmVhDQogICAgPiBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBh bGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkDQogICAgPiBieSB0aGUgSUVTRyBmb3Ig dGhlIElFVEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdA0KICAgID4g bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KICAgID4gDQogICAgPiBGb3IgbW9y ZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0DQogICAgPiANCiAgICA+IDxodHRw czovL3RyYWMuaWV0Zi5vcmcvdHJhYy9nZW4vd2lraS9HZW5BcnRmYXE+Lg0KICAgID4gDQogICAg PiBEb2N1bWVudDogZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0LXNoYWtlbi0wNA0KICAgID4gUmV2 aWV3ZXI6IEZyYW5jZXNjYSBQYWxvbWJpbmkNCiAgICA+IFJldmlldyBEYXRlOiAyMDE4LTExLTAy DQogICAgPiBJRVRGIExDIEVuZCBEYXRlOiAyMDE4LTExLTAyDQogICAgPiBJRVNHIFRlbGVjaGF0 IGRhdGU6IE5vdCBzY2hlZHVsZWQgZm9yIGEgdGVsZWNoYXQNCiAgICA+IA0KICAgID4gU3VtbWFy eTogVGhpcyBkcmFmdCBpcyBvbiB0aGUgcmlnaHQgdHJhY2sgYnV0IGhhcyBvcGVuIGlzc3Vlcywg ZGVzY3JpYmVkIGluIHRoZQ0KICAgID4gcmV2aWV3Lg0KICAgID4gDQogICAgPiBNYWpvciBpc3N1 ZXM6DQogICAgPiANCiAgICA+ICogVGhpcyBkcmFmdCBkZWZpbmVzIHRoZSBuZXcgY2xhaW0gIm9y aWdpZCIgZm9yIHRoZSBQZXJzb25hbCBBdHRlc3RhdGlvbiBUb2tlbg0KICAgID4gdXNlZCBpbiB0 aGUgU0hBS0VOIGZyYW1ld29yaywgYnV0IGRvZXMgbm90IGdpdmUgYW55IHByaXZhY3kgY29uc2lk ZXJhdGlvbnMNCiAgICA+IGFib3V0IGl0IGFuZCBpdHMgdXNlLiBbUkZDNjk3M10gc3VnZ2VzdHMg dGhhdCB0aGUgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBvZg0KICAgID4gSUVURiBwcm90b2NvbHMg YmUgZG9jdW1lbnRlZC4gQXMgcmVxdWlyZWQgYnkgW1JGQzcyNThdLCB3b3JrIG9uIElFVEYgcHJv dG9jb2xzDQogICAgPiBuZWVkcyB0byBjb25zaWRlciB0aGUgZWZmZWN0cyBvZiBwZXJ2YXNpdmUg bW9uaXRvcmluZyBhbmQgbWl0aWdhdGUgdGhlbSB3aGVuDQogICAgPiBwb3NzaWJsZS4gSSBkb24n dCBrbm93IFNIQUtFTiB3ZWxsIGVub3VnaCB0byBjb21tZW50IG9uIHByaXZhY3kgaXNzdWVzIG9u IHRoYXQsDQogICAgPiBidXQgdGhpcyBkcmFmdCwgYXMgcGFydCBvZiB0aGUgSUVURiB3b3JrLCBz aG91bGQgaGF2ZSBwcml2YWN5IGNvbnNpZGVyYXRpb25zLA0KICAgID4gcGFydGljdWxhcmx5IGNv bnNpZGVyaW5nIHRoZSAib3JpZ2lkIiBjbGFpbS4NCiAgICANCiAgICANCiAgICBIZXJlIGlzIG15 IHByb3Bvc2VkIHByaXZhY3kgY29uc2lkZXJhdGlvbiBzZWN0aW9uLCBsb29raW5nIGZvciBhbnkg Y29tbWVudHMgaWYgdGhpcyBhZGRyZXNzZXMgdGhpbmdzIHByb3Blcmx5IGdpdmVuIHRoZSBuYXR1 cmUgb2YgU0lQIHByaXZhY3kgaW4gZ2VuZXJhbC4NCiAgICANCiAgICBQcml2YWN5IENvbnNpZGVy YXRpb25zIA0KICAgIA0KICAgIEFzIGRldGFpbGVkIGluIHt7UkZDMzI2MX19IFNlY3Rpb24gMjYg YXMgd2VsbCBhcyB7e1JGQzMzMjN9fSwgU0lQIGFzIGEgcHJvdG9jb2wgaW5oZXJlbnRseSBjYXJy aWVzIGlkZW50aWZ5aW5nIGluZm9ybWF0aW9uIG9mIGJvdGggdGhlIGluaXRpYXRvciBvciAnY2Fs bGVyJyBhcyB3ZWxsIGFzIHRoZSB0ZXJtaW5hdGluZyBwYXJ0eSBvciAnY2FsbGVlJy4gJ29yaWdp ZCcsIGFzIGRlZmluZWQgaW4gU0hBS0VOIHt7QVRJUy0xMDAwMDc0fX0gYW5kIGRlc2NyaWJlZCBp biB0aGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGJlIGFuIG9wYXF1ZSBhbmQgdW5pcXVlIGlk ZW50aWZpZXIgdGhhdCBpcyB1c2VkIGJ5IGFuIG9yaWdpbmF0aW5nIHRlbGVwaG9uZSBzZXJ2aWNl IHByb3ZpZGVyIHRvIHRyYWNlIGFuZCBpZGVudGlmeSB3aGVyZSB3aXRoaW4gdGhlaXIgbmV0d29y ayAoZS5nLiBmcm9tIGEgZ2F0ZXdheSBvciBhIHBhcnRpY3VsYXIgc2VydmljZSB3aXRoaW4gdGhl aXIgbmV0d29yaykgdGhlIGNhbGwgd2FzIGluaXRpYXRlZCwgc28gdGhhdCBlaXRoZXIgYmFkIGFj dG9ycyB0aGF0IG1heSBiZSBlaXRoZXIgdHJ5aW5nIHRvIGlsbGVnaXRhbWF0ZWx5IHNwb29mIGlk ZW50aXRpZXMgb3IgbWFraW5nIGZyYXVkdWxlbnQgY2FsbHMgY2FuIGJlIGlkZW50aWZpZWQgYW5k IGxpa2VseSBzdG9wcGVkIG9yIGhlbGQgcmVzcG9uc2liaWxpeSBmb3IgdGhlIGZyYXVkdWxlbnQg YWN0aXZpdGllcy4gIFdoaWxlIHRoZSBvcGFxdWVuZXNzIG9mIHRoZSAnb3JpZ2lkJyBpZGVudGlm aWVyIGlzIGludGVuZGVkIHRvIGtlZXAgYW55IGRpcmVjdCBvciBpbXBsaWVkIGluZm9ybWF0aW9u IHJlZ2FyZGluZyB0aGUgb3JpZ2luYXRpb24gb2YgYSBzZXQgb2YgY2FsbHMgdGhhdCBtYXkgaGF2 ZSB0aGUgc2FtZSAnb3JpZ2lkJyB0byBhIG1pbmltdW0sIGl0IHNob3VsZCBiZSByZWNvZ25pemVk IHRoYXQgcG90ZW50aWFsIHBhdHRlcm5zIHdoZXRoZXIgaW50ZW5kZWQgb3Igbm90IG1heSBiZSBh YmxlIHRvIGJlIGRpc2NvdmVyZWQuDQogICAgDQogICAgPiANCiAgICA+IE1pbm9yIGlzc3VlczoN CiAgICA+IA0KICAgID4gKiBTZWN0aW9uIDQ6IHRoZSB0ZXJtICJ2ZXJpZmllZCBhc3NvY2lhdGlv biIgaXMgbm90IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwNCiAgICA+IG5vciBpbiBbUkZDODIy NV0sIG5vciBpbiB0aGUgU0hBS0VOIHNwZWMgcmVmZXJlbmNlZC4gSXMgdGhlcmUgYSB3YXkgdG8g Y2xhcmlmeQ0KICAgID4gd2hhdCBpcyBtZWFudCBieSBpdD8gSXQgY291bGQgYmUgYSByZWZlcmVu Y2UuDQogICAgDQogICAgSeKAmXZlIGluY2x1ZGVkIGEgbmV3IHRlcm1pbm9sb2d5IHRleHQgYXMg Zm9sbG93cyB0byBhZGRyZXNzIGFib3ZlIGNvbW1lbnQgYW5kIGNvbW1lbnQgYmVsb3c6DQogICAg DQogICAgICAgSW4gYWRkaXRpb24sIHRoZSBmb2xsb3dpbmcgdGVybXMgYXJlIHVzZWQgaW4gdGhp cyBkb2N1bWVudDoNCiAgICANCiAgICAgICBvICBWZXJpZmllZCBhc3NvY2lhdGlvbjogaXMgdHlw aWNhbGx5IGRlZmluZWQgYXMgYW4gYXV0aGVudGljYXRlZA0KICAgICAgICAgIHJlbGF0aW9uc2hp cCB3aXRoIGEgZGV2aWNlIHRoYXQgaW5pdGlhdGVkIGEgY2FsbCwgZm9yIGV4YW1wbGUsIGENCiAg ICAgICAgICBzdWJzY3JpYmVyIGFjY291bnQgd2l0aCBhIHNwZWNpZmljIFNJTSBjYXJkIG9yIHNl dCBvZiBTSVANCiAgICAgICAgICBjcmVkZW50aWFscy4NCiAgICANCiAgICAgICBvICBQQVNTcG9y VDogRGVmaW5lZCBpbiBbUkZDODIyNV0gaXMgYSBKU09OIFdlYiBUb2tlbiBkZWZpbmVkDQogICAg ICAgICAgc3BlY2lmaWNhbGx5IGZvciBzZWN1cmluZyB0aGUgaWRlbnRpdHkgb2YgYW4gaW5pdGlh dG9yIG9mIHBlcnNvbmFsDQogICAgICAgICAgY29tbXVuaWNhdGlvbi4gIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBhIHNwZWNpZmljIGV4dGVuc2lvbiB0bw0KICAgICAgICAgIFBBU1Nwb3JULg0KICAg IA0KICAgID4gDQogICAgPiBOaXRzL2VkaXRvcmlhbCBjb21tZW50czoNCiAgICA+IA0KICAgID4g KiBUZXJtaW5vbG9neTogSSB3b3VsZCBoYXZlIGFwcHJlY2lhdGVkIGEgc2hvcnQgc2VudGVuY2Ug bWVudGlvbmluZyBbUkZDODIyNV0NCiAgICA+IGluIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uLg0K ICAgIA0KICAgIHNlZSBhYm92ZQ0KICAgIA0KICAgID4gDQogICAgPiAqIFNlY3Rpb24gOTogW1JG QzgyMjRdIGFwcGVhcnMgd2l0aG91dCBsaW5rLg0KICAgIA0KICAgIGZpeGVkDQogICAgDQogICAg PiANCiAgICA+ICogQWNrbm93bGVkZ2VtZW50czogIlRoZSBhdXRob3JzIHdvdWxkIGxpa2UNCiAg ICA+ICAgYWNrbm93bGVkZ2UgdGhlIHdvcmsgb2YgdGhlIEFUSVMvU0lQIEZvcnVtIElQLU5OSSBU YXNrIEZvcmNlIHRvDQogICAgPiAgIGRldmVsb3AgdGhlIGNvbmNlcHRzIGJlaGluZCB0aGlzIGRv Y3VtZW50LiIgLT4gVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0bw0KICAgID4gICBhY2tub3dsZWRn ZSDigKYNCiAgICA+IA0KICAgIGZpeGVkDQogICAgDQogICAgPiBJIGRvIG5vdCByZXBlYXQgbml0 cyBhbmQgZWRpdG9yaWFscyByZXBvcnRlZCBieSBBZGFtIFJvYWNoIGluIGhpcyByZXZpZXcgb2YN CiAgICA+IHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgKDExLTE5LTIwMTgsDQogICAgPiBo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3N0aXIvSHhWU0NMUEdmU2d3RnV2 cUxrV1NWTkkwUHRRICkNCiAgICA+IA0KICAgIA0KICAgIEkgaGF2ZSBhZGRyZXNzZWQgdGhlc2Ug aXNzdWVzIGFuZCBwbGFuIHRvIHN1Ym1pdCB3aXRoIGxpc3QgY29uc2Vuc3VzIG9uIGFib3ZlIHRl eHQuDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Mon Nov 5 12:37:20 2018 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 1E7C2130DCA for ; Mon, 5 Nov 2018 12:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 6E574fmqMqkW for ; Mon, 5 Nov 2018 12:37:16 -0800 (PST) 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 EDC6F1286E7 for ; Mon, 5 Nov 2018 12:37:15 -0800 (PST) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA5KbEmm093487 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 5 Nov 2018 14:37:15 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: stir@ietf.org References: <154117528787.7013.6199833371829068074@ietfa.amsl.com> <50F64DCF-E897-4C3F-B77A-6FBA4F8955C5@chriswendt.net> From: Robert Sparks Message-ID: <48e4be87-0486-8ce7-cd2c-8ef25d31eda1@nostrum.com> Date: Mon, 5 Nov 2018 14:37:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <50F64DCF-E897-4C3F-B77A-6FBA4F8955C5@chriswendt.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [stir] Genart last call review of draft-ietf-stir-passport-shaken-04 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, 05 Nov 2018 20:37:18 -0000 Trimming to just the stir list: This was the text on the slide at Monday's meeting: On 11/4/18 6:55 AM, Chris Wendt wrote: > > Privacy Considerations > > As detailed in {{RFC3261}} Section 26 as well as {{RFC3323}}, SIP as a = protocol inherently carries identifying information of both the initiator= or 'caller' as well as the terminating party or 'callee'. 'origid', as d= efined in SHAKEN {{ATIS-1000074}} and described in this document is inten= ded to be an opaque and unique identifier that is used by an originating = telephone service provider to trace and identify where within their netwo= rk (e.g. from a gateway or a particular service within their network) the= call was initiated, so that either bad actors that may be either trying = to illegitamately spoof identities or making fraudulent calls can be iden= tified and likely stopped or held responsibiliy for the fraudulent activi= ties. While the opaqueness of the 'origid' identifier is intended to kee= p any direct or implied information regarding the origination of a set of= calls that may have the same 'origid' to a minimum, it should be recogni= zed that potential patterns whether intended or not may be able to be dis= covered. > > As Jon noted, the reference to RFC3323 isn't really that helpful, so=20 lets drop that.=C2=A0 There are some really long sentences in there. Here= 's=20 an attempt to simplify, and expand a little on the privacy implications. = Feel free to take the spirit of the suggestion and use different words=20 if these feel problematic. As detailed in {{RFC3261}} Section 26, SIP messages inherently carry=20 identifying information of the caller and callee. The value of the=20 'origid' claim, as defined in SHAKEN {{ATIS-1000074}} and described in=20 this document, is intended to be a opaque and unique identifier of an=20 element on the path of a given request. This identifier is used by an=20 originating telephone service provider to identify where within their=20 network (e.g. a gateway or particular service element) a call was=20 initiated. This facilitates identifying and stopping bad actors trying=20 to spoof identities or make fraudulent calls. The opacity of the=20 'origid' claim value is intended to minimize direct exposure of=20 information about the origination of a set of calls sharing the 'origid' = value. It should be recognized, however, that the potential for=20 discovering patterns through correlation of those calls exists. This=20 could allow a recipient of many calls to, for instance, learn that a set = of callers are using a particular service or coming through a common=20 gateway. However, this threat already exists in SIP. There is=20 information in the SIP messages(in the form of Record-Route, Via, and=20 potentially History-Info header field values that can be analyzed the=20 same way (and may correlate closely with the 'origid' value). From nobody Mon Nov 5 15:02:46 2018 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 78B5F128CE4 for ; Mon, 5 Nov 2018 15:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVO4Ll9O-bHJ for ; Mon, 5 Nov 2018 15:02:41 -0800 (PST) Received: from outbound-ss-579.bluehost.com (outbound-ss-579.bluehost.com [74.220.218.175]) (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 A9632128C65 for ; Mon, 5 Nov 2018 15:02:41 -0800 (PST) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id F41131E078B for ; Mon, 5 Nov 2018 16:02:39 -0700 (MST) Received: from box462.bluehost.com ([74.220.219.62]) by cmsmtp with ESMTP id JntHgMg70E0jMJntHgjeYu; Mon, 05 Nov 2018 16:02:39 -0700 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID: To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nGnweDWW4DCfm3UgbC1o9yAJHpQ8EQwb731PfLwSsAM=; b=MkPKlTweRGpLH3Oo0D6JP9SgWt 2z9z4xTVX2U5ZDomODkBBt5n3B8RE86gsp6L1lBP/QgwG1IQ/cGM8np0kWk/mp1QnHnwbNVo3R/bL Je+fwBJJTi+Iaaf+LEk5z09pT; Received: from pool-100-36-47-17.washdc.fios.verizon.net ([100.36.47.17]:62453 helo=[192.168.1.156]) by box462.bluehost.com with esmtpa (Exim 4.91) (envelope-from ) id 1gJntH-002YC8-AY for stir@ietf.org; Mon, 05 Nov 2018 16:02:39 -0700 User-Agent: Microsoft-MacOutlook/10.12.0.181014 Date: Mon, 05 Nov 2018 18:02:37 -0500 From: Richard Shockey To: "stir@ietf.org" Message-ID: Thread-Topic: FYI ... Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.47.17 X-Source-L: No X-Exim-ID: 1gJntH-002YC8-AY X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-47-17.washdc.fios.verizon.net ([192.168.1.156]) [100.36.47.17]:62453 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [stir] FYI ... 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, 05 Nov 2018 23:02:45 -0000 Wow.. this is pretty close to a mandate=20 https://www.fcc.gov/document/chairman-pai-demands-industry-adopt-protocols-= end-illegal-spoofing =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 From nobody Mon Nov 5 18:54:55 2018 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 A7BCB130F70 for ; Mon, 5 Nov 2018 18:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 vP0HiDWZqifc for ; Mon, 5 Nov 2018 18:54:47 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 6A3D6130F3E for ; Mon, 5 Nov 2018 18:54:47 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id n10-v6so5126791pgv.10 for ; Mon, 05 Nov 2018 18:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/b6ndYMvh0wLqZGe6gjF5eEjUsdMEn1PW0R+Hc+j+oE=; b=W6olU4ZYsT4Z0z+GOEwCuImtRydEYi2Ny+xemmOcDY26XGHTLjP1jG8kiizDiq3XXK tdNrB/KNzYKUe/Ug0cgsJu7Y8uL7UQjqrd1yiDCEVzDfpEjXkEAG7yzVR8HuCT0GSz48 5OM1xkROygN5dsngHWQG72V1USZ2OpV//t2GBjD6Y9bUDhidBiDf8uQJLkrjRLMMYeVi 1WNLsNIG7Uk+3pvuIcWFUoRszHFMCRYaPZwn9ZNRY/LSCmt6+MwJ/HuIxXIhct5rb0aa G+9Fffog/2J8Yn1CRLYoPLRQIGHGBXHQ47wE5k6J+K0Iis2psGVps+lQ2QbxqnwwXWw/ uMfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/b6ndYMvh0wLqZGe6gjF5eEjUsdMEn1PW0R+Hc+j+oE=; b=kOMGGJKSdkMmr04sp1bNTZ441yGxobNFH1g0ZzPSEvLwy2FGJyIStq6cJqj8Jih/55 u+OitDPe5Eb5iMyXDCYxvel4nET9s42IEE5i6J8qSsgBG2YA62ZbUK8HF8SnT+jeDVyF /BtXYlCv22ux+p4qu2G3UzA0l4IGoKyProR/D7rgYFRb/1q+EqwbFWK+KbHx0O9F9Tje gYJ+Cy0oq2HmbhdJpiXVlzH+IDbqmHAd++LQZe9xPjg8f/916eehTWOPoV85Rx4Fa/dk N+qbrJS2yzqJKO0uu1xEsKKVMi3KPcyh2CfBb3NpU2aSvvqZRMVP8UCoti/DUSBKHnX6 fCKw== X-Gm-Message-State: AGRZ1gJc/S/JukpUiO0vg1FcIBJLe6rq6oBXFJra2aLxWxaivPFl31On UEFz3L1lerOURbPaOMVPfbZoFw== X-Google-Smtp-Source: AJdET5eoguNqwSWCiizcwtkq18rEIF6zal3pC35GivPIAShZMOAVzgh0R25Ak+/euFnDKuNbl4XLTg== X-Received: by 2002:a63:8c4:: with SMTP id 187-v6mr22342860pgi.396.1541472886766; Mon, 05 Nov 2018 18:54:46 -0800 (PST) Received: from [10.64.20.2] ([193.37.254.131]) by smtp.gmail.com with ESMTPSA id h128sm13049865pgc.15.2018.11.05.18.54.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 18:54:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: <48e4be87-0486-8ce7-cd2c-8ef25d31eda1@nostrum.com> Date: Mon, 5 Nov 2018 21:54:38 -0500 Cc: stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154117528787.7013.6199833371829068074@ietfa.amsl.com> <50F64DCF-E897-4C3F-B77A-6FBA4F8955C5@chriswendt.net> <48e4be87-0486-8ce7-cd2c-8ef25d31eda1@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Genart last call review of draft-ietf-stir-passport-shaken-04 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, 06 Nov 2018 02:54:54 -0000 Hi Robert,=20 Thank you very much for the edits, i am good with this. I=E2=80=99ll = pause for any other comments from the list, but if i don=E2=80=99t see = any, will proceed with using this for the 05 update. -Chris > On Nov 5, 2018, at 3:37 PM, Robert Sparks = wrote: >=20 > Trimming to just the stir list: >=20 > This was the text on the slide at Monday's meeting: >=20 > On 11/4/18 6:55 AM, Chris Wendt wrote: >>=20 >> Privacy Considerations >>=20 >> As detailed in {{RFC3261}} Section 26 as well as {{RFC3323}}, SIP as = a protocol inherently carries identifying information of both the = initiator or 'caller' as well as the terminating party or 'callee'. = 'origid', as defined in SHAKEN {{ATIS-1000074}} and described in this = document is intended to be an opaque and unique identifier that is used = by an originating telephone service provider to trace and identify where = within their network (e.g. from a gateway or a particular service within = their network) the call was initiated, so that either bad actors that = may be either trying to illegitamately spoof identities or making = fraudulent calls can be identified and likely stopped or held = responsibiliy for the fraudulent activities. While the opaqueness of = the 'origid' identifier is intended to keep any direct or implied = information regarding the origination of a set of calls that may have = the same 'origid' to a minimum, it should be recognized that potential = patterns whether intended or not may be able to be discovered. >>=20 >>=20 > As Jon noted, the reference to RFC3323 isn't really that helpful, so = lets drop that. There are some really long sentences in there. Here's = an attempt to simplify, and expand a little on the privacy implications. = Feel free to take the spirit of the suggestion and use different words = if these feel problematic. >=20 > As detailed in {{RFC3261}} Section 26, SIP messages inherently carry = identifying information of the caller and callee. The value of the = 'origid' claim, as defined in SHAKEN {{ATIS-1000074}} and described in = this document, is intended to be a opaque and unique identifier of an = element on the path of a given request. This identifier is used by an = originating telephone service provider to identify where within their = network (e.g. a gateway or particular service element) a call was = initiated. This facilitates identifying and stopping bad actors trying = to spoof identities or make fraudulent calls. The opacity of the = 'origid' claim value is intended to minimize direct exposure of = information about the origination of a set of calls sharing the 'origid' = value. It should be recognized, however, that the potential for = discovering patterns through correlation of those calls exists. This = could allow a recipient of many calls to, for instance, learn that a set = of callers are using a particular service or coming through a common = gateway. However, this threat already exists in SIP. There is = information in the SIP messages(in the form of Record-Route, Via, and = potentially History-Info header field values that can be analyzed the = same way (and may correlate closely with the 'origid' value). >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Nov 5 19:36:39 2018 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 8C45712D4EA for ; Mon, 5 Nov 2018 19:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 ikaSmRj4gp4r for ; Mon, 5 Nov 2018 19:36:35 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 CD6BD127333 for ; Mon, 5 Nov 2018 19:36:35 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id i4-v6so5174487pgq.9 for ; Mon, 05 Nov 2018 19:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PcSoHPbhw1KZllEV2QSqzzB29r6SQhQzrlh02oh0r7Y=; b=GsGSvmiM+glNJetEPOIrE/DiKfoBqiylZOQcv/20qvXNRc+h70/echv4cmKMnrcmRu aucMyMvcgUXotCCulURj0CMM4QIe/4H00/P7klB/3wjDl5rcXNyxGExt3iyERZZnFvRg lm5691JtY/P02RbCBWesNMhqUJcx8mVq/dNRdnLrd824pXqPZP8i5z+CZ1nWneLGIPhR inlulYo0evfj166rTu342e/U/anBRGk/E5SbhP1xOllG9m3zIHkAstOakXweJRSjCFS/ lDMnUEtyHwjGtpC6/0LYOQIP8pWUA25fQMt7wBdntR8dlqkiOEvIGUznvDSj00qY43Ul BebA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PcSoHPbhw1KZllEV2QSqzzB29r6SQhQzrlh02oh0r7Y=; b=aacvhzlhFhPggVWkqH53exf+TlhaZmJMt/T6jwSCYBsiRqKBAQ0/GiN6V/zR1bm/q5 ym4eAlfSC4SK37me2nBlLHU3pHcPSNL4a4H3lxj4lyOMJ6GfbeR8CboVBMff8lGjBfjN lM41Y/43pw1BYO/hGy192eJ8KnPwa6KNOqd0uN3cR/MvBB6AvGPJPLZVIPT29gKU+PDI bHiSy+egF+DGH5gZvsAWRJ7t8wDoDV7J2lzrfYcqMihll376YgIjdIKEBklsNbV8B5Lm 8ahHhfjE5GiceTg7jovMtZr8E/gwdHvOn28vQsxMkm8ynWuAU0wF77htabt8y7WCGwn8 5VLQ== X-Gm-Message-State: AGRZ1gLpAI7e/3ZR8Zkt/fMsn/bxti4RAi4fMZFUXdCQzonVVKFOwJ1n BDrMXlz30W6kyZYiMXMkH3TsxOAhLJc= X-Google-Smtp-Source: AJdET5e4/s/ArcO9+AZXYYvQD2rG9zMw4E/65Ed+yjMAJcdfhdYk4KIqIu6pz9TFw3lYhh/0eWRLcw== X-Received: by 2002:a65:45c9:: with SMTP id m9-v6mr22026945pgr.212.1541475395219; Mon, 05 Nov 2018 19:36:35 -0800 (PST) Received: from [10.64.20.2] ([193.37.254.131]) by smtp.gmail.com with ESMTPSA id 3-v6sm49298588pga.12.2018.11.05.19.36.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 19:36:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: Date: Mon, 5 Nov 2018 22:36:27 -0500 Cc: stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <02B0BA9F-7D82-4B85-9C07-E107F04090A4@chriswendt.net> References: <154117528787.7013.6199833371829068074@ietfa.amsl.com> <50F64DCF-E897-4C3F-B77A-6FBA4F8955C5@chriswendt.net> <48e4be87-0486-8ce7-cd2c-8ef25d31eda1@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Genart last call review of draft-ietf-stir-passport-shaken-04 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, 06 Nov 2018 03:36:38 -0000 I=E2=80=99m going to add one more sentence to the end to address one of = Jon=E2=80=99s comments about a suggestion to have unique origid=E2=80=99s = mapped to a common network element as a defensive mechanism if privacy = is desired. So text would be as follows: As detailed in {{RFC3261}} Section 26, SIP messages inherently carry = identifying information of the caller and callee. The value of the = 'origid' claim, as defined in SHAKEN {{ATIS-1000074}} and described in = this document, is intended to be a opaque and unique identifier of an = element on the path of a given request. This identifier is used by an = originating telephone service provider to identify where within their = network (e.g. a gateway or particular service element) a call was = initiated. This facilitates identifying and stopping bad actors trying = to spoof identities or make fraudulent calls. The opacity of the = 'origid' claim value is intended to minimize direct exposure of = information about the origination of a set of calls sharing the 'origid' = value. It should be recognized, however, that the potential for = discovering patterns through correlation of those calls exists. This = could allow a recipient of many calls to, for instance, learn that a set = of callers are using a particular service or coming through a common = gateway. However, this threat already exists in SIP. There is = information in the SIP messages(in the form of Record-Route, Via, and = potentially History-Info header field values that can be analyzed the = same way (and may correlate closely with the 'origid' value). If there = is concern about correlation of 'origid' values, the CSP could employ a = mechanism that maps unique per call origid values to a common network = element when doing the lookup in their backend systems. > On Nov 5, 2018, at 9:54 PM, Chris Wendt = wrote: >=20 > Hi Robert,=20 >=20 > Thank you very much for the edits, i am good with this. I=E2=80=99ll = pause for any other comments from the list, but if i don=E2=80=99t see = any, will proceed with using this for the 05 update. >=20 > -Chris >=20 >> On Nov 5, 2018, at 3:37 PM, Robert Sparks = wrote: >>=20 >> Trimming to just the stir list: >>=20 >> This was the text on the slide at Monday's meeting: >>=20 >> On 11/4/18 6:55 AM, Chris Wendt wrote: >>>=20 >>> Privacy Considerations >>>=20 >>> As detailed in {{RFC3261}} Section 26 as well as {{RFC3323}}, SIP as = a protocol inherently carries identifying information of both the = initiator or 'caller' as well as the terminating party or 'callee'. = 'origid', as defined in SHAKEN {{ATIS-1000074}} and described in this = document is intended to be an opaque and unique identifier that is used = by an originating telephone service provider to trace and identify where = within their network (e.g. from a gateway or a particular service within = their network) the call was initiated, so that either bad actors that = may be either trying to illegitamately spoof identities or making = fraudulent calls can be identified and likely stopped or held = responsibiliy for the fraudulent activities. While the opaqueness of = the 'origid' identifier is intended to keep any direct or implied = information regarding the origination of a set of calls that may have = the same 'origid' to a minimum, it should be recognized that potential = patterns whether intended or not may be able to be discovered. >>>=20 >>>=20 >> As Jon noted, the reference to RFC3323 isn't really that helpful, so = lets drop that. There are some really long sentences in there. Here's = an attempt to simplify, and expand a little on the privacy implications. = Feel free to take the spirit of the suggestion and use different words = if these feel problematic. >>=20 >> As detailed in {{RFC3261}} Section 26, SIP messages inherently carry = identifying information of the caller and callee. The value of the = 'origid' claim, as defined in SHAKEN {{ATIS-1000074}} and described in = this document, is intended to be a opaque and unique identifier of an = element on the path of a given request. This identifier is used by an = originating telephone service provider to identify where within their = network (e.g. a gateway or particular service element) a call was = initiated. This facilitates identifying and stopping bad actors trying = to spoof identities or make fraudulent calls. The opacity of the = 'origid' claim value is intended to minimize direct exposure of = information about the origination of a set of calls sharing the 'origid' = value. It should be recognized, however, that the potential for = discovering patterns through correlation of those calls exists. This = could allow a recipient of many calls to, for instance, learn that a set = of callers are using a particular service or coming through a common = gateway. However, this threat already exists in SIP. There is = information in the SIP messages(in the form of Record-Route, Via, and = potentially History-Info header field values that can be analyzed the = same way (and may correlate closely with the 'origid' value). >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 From nobody Mon Nov 5 19:42:27 2018 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 E27B2130E71 for ; Mon, 5 Nov 2018 19:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 A9EcAMriRU_0 for ; Mon, 5 Nov 2018 19:42:20 -0800 (PST) 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 0EE04130EFA for ; Mon, 5 Nov 2018 19:42:20 -0800 (PST) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA63gHrO061934 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 5 Nov 2018 21:42:18 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: Chris Wendt Cc: stir@ietf.org References: <154117528787.7013.6199833371829068074@ietfa.amsl.com> <50F64DCF-E897-4C3F-B77A-6FBA4F8955C5@chriswendt.net> <48e4be87-0486-8ce7-cd2c-8ef25d31eda1@nostrum.com> <02B0BA9F-7D82-4B85-9C07-E107F04090A4@chriswendt.net> From: Robert Sparks Message-ID: <2a9b7a93-53c3-2f29-3f46-891e850b7164@nostrum.com> Date: Mon, 5 Nov 2018 21:42:17 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <02B0BA9F-7D82-4B85-9C07-E107F04090A4@chriswendt.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [stir] Genart last call review of draft-ietf-stir-passport-shaken-04 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, 06 Nov 2018 03:42:25 -0000 Minor wordsmithing suggestion for the new last sentence inline: On 11/5/18 9:36 PM, Chris Wendt wrote: > I=E2=80=99m going to add one more sentence to the end to address one of= Jon=E2=80=99s comments about a suggestion to have unique origid=E2=80=99= s mapped to a common network element as a defensive mechanism if privacy = is desired. > > So text would be as follows: > As detailed in {{RFC3261}} Section 26, SIP messages inherently carry id= entifying information of the caller and callee. The value of the 'origid'= claim, as defined in SHAKEN {{ATIS-1000074}} and described in this docum= ent, is intended to be a opaque and unique identifier of an element on th= e path of a given request. This identifier is used by an originating tele= phone service provider to identify where within their network (e.g. a gat= eway or particular service element) a call was initiated. This facilitate= s identifying and stopping bad actors trying to spoof identities or make = fraudulent calls. The opacity of the 'origid' claim value is intended to = minimize direct exposure of information about the origination of a set of= calls sharing the 'origid' value. It should be recognized, however, that= the potential for discovering patterns through correlation of those call= s exists. This could allow a recipient of many calls to, for instance, le= arn that a set of callers are using a particular service or coming throug= h a common gateway. However, this threat already exists in SIP. There is = information in the SIP messages(in the form of Record-Route, Via, and pot= entially History-Info header field values that can be analyzed the same w= ay (and may correlate closely with the 'origid' value). If there is conc= ern about correlation of 'origid' values, the CSP could employ a mechanis= m that maps unique per call origid values to a common network element whe= n doing the lookup in their backend systems. If the operator of an element is concerned about the correlation of=20 'origid' values, the element could be configured to use a unique=20 'origid' value per call in such a way that the operator can associate=20 those 'origid' values to the correct element when doing lookups in their = backend systems. > >> On Nov 5, 2018, at 9:54 PM, Chris Wendt wr= ote: >> >> Hi Robert, >> >> Thank you very much for the edits, i am good with this. I=E2=80=99ll = pause for any other comments from the list, but if i don=E2=80=99t see an= y, will proceed with using this for the 05 update. >> >> -Chris >> >>> On Nov 5, 2018, at 3:37 PM, Robert Sparks wrot= e: >>> >>> Trimming to just the stir list: >>> >>> This was the text on the slide at Monday's meeting: >>> >>> On 11/4/18 6:55 AM, Chris Wendt wrote: >>>> Privacy Considerations >>>> >>>> As detailed in {{RFC3261}} Section 26 as well as {{RFC3323}}, SIP as= a protocol inherently carries identifying information of both the initia= tor or 'caller' as well as the terminating party or 'callee'. 'origid', a= s defined in SHAKEN {{ATIS-1000074}} and described in this document is in= tended to be an opaque and unique identifier that is used by an originati= ng telephone service provider to trace and identify where within their ne= twork (e.g. from a gateway or a particular service within their network) = the call was initiated, so that either bad actors that may be either tryi= ng to illegitamately spoof identities or making fraudulent calls can be i= dentified and likely stopped or held responsibiliy for the fraudulent act= ivities. While the opaqueness of the 'origid' identifier is intended to = keep any direct or implied information regarding the origination of a set= of calls that may have the same 'origid' to a minimum, it should be reco= gnized that potential patterns whether intended or not may be able to be = discovered. >>>> >>>> >>> As Jon noted, the reference to RFC3323 isn't really that helpful, so = lets drop that. There are some really long sentences in there. Here's an= attempt to simplify, and expand a little on the privacy implications. Fe= el free to take the spirit of the suggestion and use different words if t= hese feel problematic. >>> >>> As detailed in {{RFC3261}} Section 26, SIP messages inherently carry = identifying information of the caller and callee. The value of the 'origi= d' claim, as defined in SHAKEN {{ATIS-1000074}} and described in this doc= ument, is intended to be a opaque and unique identifier of an element on = the path of a given request. This identifier is used by an originating te= lephone service provider to identify where within their network (e.g. a g= ateway or particular service element) a call was initiated. This facilita= tes identifying and stopping bad actors trying to spoof identities or mak= e fraudulent calls. The opacity of the 'origid' claim value is intended t= o minimize direct exposure of information about the origination of a set = of calls sharing the 'origid' value. It should be recognized, however, th= at the potential for discovering patterns through correlation of those ca= lls exists. This could allow a recipient of many calls to, for instance, = learn that a set of callers are using a particular service or coming thro= ugh a common gateway. However, this threat already exists in SIP. There i= s information in the SIP messages(in the form of Record-Route, Via, and p= otentially History-Info header field values that can be analyzed the same= way (and may correlate closely with the 'origid' value). >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir From nobody Mon Nov 5 19:52:12 2018 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 AF99B130DCC for ; Mon, 5 Nov 2018 19:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 tmpIZEFG2WA8 for ; Mon, 5 Nov 2018 19:52:07 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 E2A9D12D4EA for ; Mon, 5 Nov 2018 19:52:02 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id u13-v6so5460348pfm.4 for ; Mon, 05 Nov 2018 19:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z8kvh/1MWFmbQ3KpIwUQmNaA8qoVM8nD1K3Opzwq44c=; b=VGsx20PUZgmr+qAe+ZqtXRgHP8PxkjHnryaIIWmviDt42LphaEXYdF/UMmrUlIXie4 UN+ZtfUIGvgXW5RlJ3xeO8MP2R6oV7DSeSn/1D90yRTJTtdA8QKT4wyY5u5MJ6KU/AdG qxE9+cbMOm0gQypDgdseKOZBMcHSBj+hExq9yQMtjxeZNg2Xljk9xtoCwyTUU0nU+91p XnaUIkxuwR/paLrHouothRM5v+TpfQxv6/bl+PVYj5W10lkqhg43RFYb9lsiNtunZQDX +bZMW3e/dzfAuqcMRfp5PVck/Z6kNC5zqknvP+IyCQfesxLGJqPw4mUOjlAexPCIbbMF uVKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z8kvh/1MWFmbQ3KpIwUQmNaA8qoVM8nD1K3Opzwq44c=; b=itVZq3oaGwnCu222jaNhRQjbz96EkAFLFYEI3OGiMqbAUdUlqQdxmi0iJlCzW17WCp +h9RR10yfpOOrjfFZxQEyndt1AZcSZnW54tCCkSwFu16cuoqrf3RHOCscIgqI3GGoVc0 Zavz0aUgInUV73y6tCqxggrZr3HgNJzMysLur+3/hU6LILAOWyhTasIyRjwHEHawKOvV Qf+t5nNHNL4SiOqbtjCmqhOrafxtdcB+BQERWg427mJLOHQ/OQj6NgPnBt9psGKmsTTq jitHZH6kXZfKoiL/1PCz4cYxpW60lSjPrCA1XEA4YfQ3s7+rDpgAhGIbrLUVBA+Wac3v uwxg== X-Gm-Message-State: AGRZ1gIAV9r8dhZKFLq0yuVjLdKMHLfx1363b7FSDGDR8b3K8Z1uHNpH odio5mRgeiZQcfTCBIDcg5JS5w== X-Google-Smtp-Source: AJdET5cbGqR49/r/3m2Od+0bgNOprswtWfQOiZ8/yC2SIBmDe1TreC4PmftP6GLpAtaTlKjrbwKZgg== X-Received: by 2002:a63:b105:: with SMTP id r5mr7821237pgf.442.1541476322373; Mon, 05 Nov 2018 19:52:02 -0800 (PST) Received: from [10.64.20.2] ([193.37.254.131]) by smtp.gmail.com with ESMTPSA id t4-v6sm47023561pfh.45.2018.11.05.19.51.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 19:52:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: <2a9b7a93-53c3-2f29-3f46-891e850b7164@nostrum.com> Date: Mon, 5 Nov 2018 22:51:54 -0500 Cc: stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <452F7567-8244-4865-91CB-627DCD2B1FDE@chriswendt.net> References: <154117528787.7013.6199833371829068074@ietfa.amsl.com> <50F64DCF-E897-4C3F-B77A-6FBA4F8955C5@chriswendt.net> <48e4be87-0486-8ce7-cd2c-8ef25d31eda1@nostrum.com> <02B0BA9F-7D82-4B85-9C07-E107F04090A4@chriswendt.net> <2a9b7a93-53c3-2f29-3f46-891e850b7164@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Genart last call review of draft-ietf-stir-passport-shaken-04 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, 06 Nov 2018 03:52:11 -0000 Thanks again Robert, i=E2=80=99m good with that. > On Nov 5, 2018, at 10:42 PM, Robert Sparks = wrote: >=20 > Minor wordsmithing suggestion for the new last sentence inline: >=20 >=20 > On 11/5/18 9:36 PM, Chris Wendt wrote: >> I=E2=80=99m going to add one more sentence to the end to address one = of Jon=E2=80=99s comments about a suggestion to have unique origid=E2=80=99= s mapped to a common network element as a defensive mechanism if privacy = is desired. >>=20 >> So text would be as follows: >> As detailed in {{RFC3261}} Section 26, SIP messages inherently carry = identifying information of the caller and callee. The value of the = 'origid' claim, as defined in SHAKEN {{ATIS-1000074}} and described in = this document, is intended to be a opaque and unique identifier of an = element on the path of a given request. This identifier is used by an = originating telephone service provider to identify where within their = network (e.g. a gateway or particular service element) a call was = initiated. This facilitates identifying and stopping bad actors trying = to spoof identities or make fraudulent calls. The opacity of the = 'origid' claim value is intended to minimize direct exposure of = information about the origination of a set of calls sharing the 'origid' = value. It should be recognized, however, that the potential for = discovering patterns through correlation of those calls exists. This = could allow a recipient of many calls to, for instance, learn that a set = of callers are using a particular service or coming through a common = gateway. However, this threat already exists in SIP. There is = information in the SIP messages(in the form of Record-Route, Via, and = potentially History-Info header field values that can be analyzed the = same way (and may correlate closely with the 'origid' value). If there = is concern about correlation of 'origid' values, the CSP could employ a = mechanism that maps unique per call origid values to a common network = element when doing the lookup in their backend systems. > If the operator of an element is concerned about the correlation of = 'origid' values, the element could be configured to use a unique = 'origid' value per call in such a way that the operator can associate = those 'origid' values to the correct element when doing lookups in their = backend systems. >>=20 >>> On Nov 5, 2018, at 9:54 PM, Chris Wendt = wrote: >>>=20 >>> Hi Robert, >>>=20 >>> Thank you very much for the edits, i am good with this. I=E2=80=99ll = pause for any other comments from the list, but if i don=E2=80=99t see = any, will proceed with using this for the 05 update. >>>=20 >>> -Chris >>>=20 >>>> On Nov 5, 2018, at 3:37 PM, Robert Sparks = wrote: >>>>=20 >>>> Trimming to just the stir list: >>>>=20 >>>> This was the text on the slide at Monday's meeting: >>>>=20 >>>> On 11/4/18 6:55 AM, Chris Wendt wrote: >>>>> Privacy Considerations >>>>>=20 >>>>> As detailed in {{RFC3261}} Section 26 as well as {{RFC3323}}, SIP = as a protocol inherently carries identifying information of both the = initiator or 'caller' as well as the terminating party or 'callee'. = 'origid', as defined in SHAKEN {{ATIS-1000074}} and described in this = document is intended to be an opaque and unique identifier that is used = by an originating telephone service provider to trace and identify where = within their network (e.g. from a gateway or a particular service within = their network) the call was initiated, so that either bad actors that = may be either trying to illegitamately spoof identities or making = fraudulent calls can be identified and likely stopped or held = responsibiliy for the fraudulent activities. While the opaqueness of = the 'origid' identifier is intended to keep any direct or implied = information regarding the origination of a set of calls that may have = the same 'origid' to a minimum, it should be recognized that potential = patterns whether intended or not may be able to be discovered. >>>>>=20 >>>>>=20 >>>> As Jon noted, the reference to RFC3323 isn't really that helpful, = so lets drop that. There are some really long sentences in there. = Here's an attempt to simplify, and expand a little on the privacy = implications. Feel free to take the spirit of the suggestion and use = different words if these feel problematic. >>>>=20 >>>> As detailed in {{RFC3261}} Section 26, SIP messages inherently = carry identifying information of the caller and callee. The value of the = 'origid' claim, as defined in SHAKEN {{ATIS-1000074}} and described in = this document, is intended to be a opaque and unique identifier of an = element on the path of a given request. This identifier is used by an = originating telephone service provider to identify where within their = network (e.g. a gateway or particular service element) a call was = initiated. This facilitates identifying and stopping bad actors trying = to spoof identities or make fraudulent calls. The opacity of the = 'origid' claim value is intended to minimize direct exposure of = information about the origination of a set of calls sharing the 'origid' = value. It should be recognized, however, that the potential for = discovering patterns through correlation of those calls exists. This = could allow a recipient of many calls to, for instance, learn that a set = of callers are using a particular service or coming through a common = gateway. However, this threat already exists in SIP. There is = information in the SIP messages(in the form of Record-Route, Via, and = potentially History-Info header field values that can be analyzed the = same way (and may correlate closely with the 'origid' value). >>>>=20 >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir >=20 >=20 From nobody Tue Nov 6 07:55:33 2018 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 1FD7312426A; Tue, 6 Nov 2018 07:55:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: stir@ietf.org Message-ID: <154151973108.30897.9141822078789931773@ietfa.amsl.com> Date: Tue, 06 Nov 2018 07:55:31 -0800 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-passport-shaken-05.txt 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: Tue, 06 Nov 2018 15:55:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF. Title : PASSporT SHAKEN Extension (SHAKEN) Authors : Chris Wendt Mary Barnes Filename : draft-ietf-stir-passport-shaken-05.txt Pages : 9 Date : 2018-11-06 Abstract: This document extends PASSporT, which is a token object that conveys cryptographically-signed information about the participants involved in communications. The extension is defined, corresponding to the SHAKEN specification, to provide both a specific set of levels-of- confidence to the correctness of the originating identity for a SIP based Communication Service Provider (CSP) telephone network originated call as well as an identifier that allows the CSP to uniquely identify the origination of the call within its network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-passport-shaken-05 https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-shaken-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-shaken-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 6 07:57:30 2018 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 625B212426A for ; Tue, 6 Nov 2018 07:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 VCR804J2MFRv for ; Tue, 6 Nov 2018 07:57:26 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 DEBC512D7F8 for ; Tue, 6 Nov 2018 07:57:25 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id n4-v6so6412891plp.2 for ; Tue, 06 Nov 2018 07:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GiavjEvPQDTpFS3vru7dl+1c/3nHnPBLVqorSjilz98=; b=rZ34wP5Zu6DuAEs+tCIMq4TkRKSpGQ0mBVEYLboWPVIIjwmtG4yFifjmhX3lAjNG/V 2Uhow/xhyDh5dt6cqHD/JUv3mYxNvF06qnN49reUbNZ+/WxjsPGExexSG2psZdDDEssM W6G2yia7Z2MGOuyb+cIVUKUq4I+3YlQUVt3NP+8FgrtsS+OAK5TV+l4yAPQaPEtpUjfb 5NpGjIBN/57lh3cB0MZIvar1HQAqTwpekn57mod0OUJ0sve9Sxq7aSK5Q4+KcJ5GTTNz +CSxz/vxDZvQmY3enRvDgoEwqxeUMgatCQqlxL7PztXVGixj41ASwn0c+zayHLW/ys+v aXKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GiavjEvPQDTpFS3vru7dl+1c/3nHnPBLVqorSjilz98=; b=IKdkfE8Xb0yCJJcP/nnMa+0/0sra4NyCC87i9dUKf1qAR3NbiubHlq4Gtgh88cC5Sp xKxGW0N/RSr9gXX/0Oi+XR8hOlOrXODvkY0l7NMD/aAQgxbNvBUGisTC+lGZWPfbz2+n NZTWE18WbkT2NN1nsystVb+mn3cPTQA1mQCboO4/2tym29kTD6vMozXLog++pnR6vqH1 h1xwPpIJjpvc9lJKTQjb0ChHRaTiuURQlIKEMm22HeZ+pEjk9G01a5cIzb9kNsCoZoVT vi4FuavvT9K5ow2b/O7tdmuWr7PgLKrUNnsfl1xRNZjkRe+qEg6/LYr8E5mbMpycULNQ F7Ew== X-Gm-Message-State: AGRZ1gJZZEp90KoalF8NU19zaPY6GJDyl9FBoDs5VbbX89xQ146EwBWh vaSXYpX1Ks9DD5QCYL9RmTtt2lYeGsI= X-Google-Smtp-Source: AJdET5d4yY4fuiVy3xh6TTYlPwtN6HmpzwPcNwfhJE9MVwrDQFc2BVKXchkOU0vVTM87EyWTlIXc3A== X-Received: by 2002:a17:902:d24:: with SMTP id 33-v6mr17881689plu.319.1541519844919; Tue, 06 Nov 2018 07:57:24 -0800 (PST) Received: from [10.64.40.16] ([193.37.254.131]) by smtp.gmail.com with ESMTPSA id g72-v6sm61978984pfd.181.2018.11.06.07.57.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 07:57:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: <154151973108.30897.9141822078789931773@ietfa.amsl.com> Date: Tue, 6 Nov 2018 10:57:19 -0500 Cc: Adam Roach , Russ Housley , Robert Sparks Content-Transfer-Encoding: quoted-printable Message-Id: References: <154151973108.30897.9141822078789931773@ietfa.amsl.com> To: "stir@ietf.org Mail List" X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-shaken-05.txt 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, 06 Nov 2018 15:57:29 -0000 @adam Seeing no additional comments I have posted 05 > On Nov 6, 2018, at 10:55 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Telephone Identity Revisited = WG of the IETF. >=20 > Title : PASSporT SHAKEN Extension (SHAKEN) > Authors : Chris Wendt > Mary Barnes > Filename : draft-ietf-stir-passport-shaken-05.txt > Pages : 9 > Date : 2018-11-06 >=20 > Abstract: > This document extends PASSporT, which is a token object that conveys > cryptographically-signed information about the participants involved > in communications. The extension is defined, corresponding to the > SHAKEN specification, to provide both a specific set of levels-of- > confidence to the correctness of the originating identity for a SIP > based Communication Service Provider (CSP) telephone network > originated call as well as an identifier that allows the CSP to > uniquely identify the origination of the call within its network. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-stir-passport-shaken-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-shaken-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-passport-shaken-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Nov 6 11:13:33 2018 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 4E96B130DF3 for ; Tue, 6 Nov 2018 11:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 Vb7gKsbup4uq for ; Tue, 6 Nov 2018 11:13:29 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 BF38C130DEF for ; Tue, 6 Nov 2018 11:13:29 -0800 (PST) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id E39C5177618 for ; Tue, 6 Nov 2018 11:49:13 -0700 (MST) Received: from box462.bluehost.com ([74.220.219.62]) by cmsmtp with ESMTP id K6PZgib9XE0jMK6PZg5Pha; Tue, 06 Nov 2018 11:49:13 -0700 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID: CC:To:From:Subject:Date:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=wkdOtv6+DxTSWDZlrxsEKLUqgA5WzMD+REFif+LmBNQ=; b=QThl5oGk+GFU0h9pITnJnZgCK3 qjTC+ymonrLI+rYa0eUFh6ofaXcgiFYnITLjYDJS4FwpHPBUaNEj2FK62A1eZRB9nFBEQrTLAUzI5 WSNMzbqhQ9+HFQf24ja/a89IF; Received: from pool-100-36-47-17.washdc.fios.verizon.net ([100.36.47.17]:56103 helo=[192.168.1.156]) by box462.bluehost.com with esmtpa (Exim 4.91) (envelope-from ) id 1gK6PZ-000x1e-CH; Tue, 06 Nov 2018 11:49:13 -0700 User-Agent: Microsoft-MacOutlook/10.12.0.181014 Date: Tue, 06 Nov 2018 13:49:11 -0500 From: Richard Shockey To: "stir@ietf.org" CC: Message-ID: Thread-Topic: So is this the RFC 7131 mandate? Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.47.17 X-Source-L: No X-Exim-ID: 1gK6PZ-000x1e-CH X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-47-17.washdc.fios.verizon.net ([192.168.1.156]) [100.36.47.17]:56103 X-Source-Auth: richard+shockey.us X-Email-Count: 7 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [stir] So is this the RFC 7131 mandate? 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, 06 Nov 2018 19:13:31 -0000 https://www.fcc.gov/document/fcc-urges-more-phone-industry-join-tracing-sca= m-robocalls =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 From nobody Tue Nov 6 16:40:09 2018 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 1918F1277BB for ; Tue, 6 Nov 2018 16:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 28XaRbEamP5M for ; Tue, 6 Nov 2018 16:40:06 -0800 (PST) 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 0465A126CB6 for ; Tue, 6 Nov 2018 16:40:05 -0800 (PST) Received: from dhcp-8111.meeting.ietf.org (dhcp-8111.meeting.ietf.org [31.133.129.17]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA70dxr5071720 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 6 Nov 2018 18:40:01 -0600 (CST) (envelope-from adam@nostrum.com) To: Chris Wendt , "stir@ietf.org Mail List" Cc: Russ Housley , Robert Sparks References: <154151973108.30897.9141822078789931773@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 7 Nov 2018 07:39:55 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-shaken-05.txt 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, 07 Nov 2018 00:40:08 -0000 Thanks! I'll move this forward as soon as I get a moment. /a On 11/6/18 22:57, Chris Wendt wrote: > @adam Seeing no additional comments I have posted 05 > >> On Nov 6, 2018, at 10:55 AM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF. >> >> Title : PASSporT SHAKEN Extension (SHAKEN) >> Authors : Chris Wendt >> Mary Barnes >> Filename : draft-ietf-stir-passport-shaken-05.txt >> Pages : 9 >> Date : 2018-11-06 >> >> Abstract: >> This document extends PASSporT, which is a token object that conveys >> cryptographically-signed information about the participants involved >> in communications. The extension is defined, corresponding to the >> SHAKEN specification, to provide both a specific set of levels-of- >> confidence to the correctness of the originating identity for a SIP >> based Communication Service Provider (CSP) telephone network >> originated call as well as an identifier that allows the CSP to >> uniquely identify the origination of the call within its network. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-stir-passport-shaken-05 >> https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-shaken-05 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-shaken-05 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir From nobody Tue Nov 6 22:46:42 2018 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 781B8129619 for ; Tue, 6 Nov 2018 22:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 g_yhzbNPnxy7 for ; Tue, 6 Nov 2018 22:46:40 -0800 (PST) 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 14888127333 for ; Tue, 6 Nov 2018 22:46:40 -0800 (PST) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA76kdO9030994 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 7 Nov 2018 00:46:39 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: "stir@ietf.org" From: Robert Sparks Message-ID: <6f2a823a-6a23-1795-ec4e-3bb58f45e8ac@nostrum.com> Date: Wed, 7 Nov 2018 00:46:38 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [stir] WGLC: draft-ietf-stir-passport-divert-04 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, 07 Nov 2018 06:46:41 -0000 This is a Working Group Last Call for draft-ietf-stir-passport-divert-04. Please send your comments to the list or the chairs by Fri Nov 30. (This leaves a little over three weeks since many have travel plans after the IETF week). RjS From nobody Thu Nov 8 14:04:32 2018 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 969E4128A5C for ; Thu, 8 Nov 2018 14:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 3bzkh9K6HSPh for ; Thu, 8 Nov 2018 14:04:27 -0800 (PST) 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 9F5A2128C65 for ; Thu, 8 Nov 2018 14:04:27 -0800 (PST) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA8M4QMh021202 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 8 Nov 2018 16:04:27 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: "stir@ietf.org" From: Robert Sparks Message-ID: <321ea237-87f1-cae5-dba5-a3da3bbfe877@nostrum.com> Date: Thu, 8 Nov 2018 16:04:26 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [stir] Raw Notes for STIR@103 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: Thu, 08 Nov 2018 22:04:31 -0000 Many thanks to Jonathan Lennox and Jean Mahoney for taking notes during the STIR session at IETF 103. Jonathan's notes can be found in the etherpad at https://etherpad.tools.ietf.org/p/notes-ietf-103-stir?useMonospaceFont=true Jean's notes are copied below: ==================================================================== STIR WG Session IETF 103 Bangkok MONDAY, 5 November 2018 at 1120 Chairs: Russ Housley, Robert Sparks AD: Adam Roach ------------------------------------------------------------ Administrative tasks Presenter: Adam Roach Presentation: https://datatracker.ietf.org/meeting/103/materials/slides-103-stir-chair-slides-00 (Slight delay in starting the meeting: Chair delays, Meetecho issues for remote participants, stale Agenda cache that did not show session slides.) Minute Taker: Jon (Lennox?), Jean Mahoney (backup) Jabber Scribe: Christer Holmberg (who couldn't get into the Jabber room, Adam Roach became backup scribe) Bluesheets Agenda Bash Jon Peterson - Chris will present RCD, not me. (no other changes to the agenda) ------------------------------------------------------------ draft-ietf-stir-passport-shaken Presenter: Chris Wendt Presentation: https://datatracker.ietf.org/meeting/103/materials/slides-103-stir-passport-shaken-00 slide 1: Title slide 2: Some Comments to discuss Chris - The origid identifier is opaque, and allows the service provider to trace back where the call was originated, not the originator itself, no personal info is being leaked. Robert Sparks - For the Privacy Considerations, you should be able to point to the base PASSporT spec, and it will talk about all these other things. But I haven't verified that. Jon Peterson - The Privacy Considerations in 3323 probably aren't well aligned with this. This identifier doesn't contain any personally identifying info. It's an opaque identifier of network resources rather than people. It's used for service provider tracing. If you are concerned about people tracking this, you can generate a new origid every time you generate a call. It's internal to service provider networks. That closes the privacy gap, but point to PASSport base spec also. Chris - I'm happy to incorporate text like that. ACTION: Chris to add text to Privacy Considerations pointing to base PASSporT spec and explaining that new origids can be generated, and post to mailing list. slide 3: New Terminology text slide 4: New Abstract text slide 5: Other comments Chris - I'll put a new version of the Privacy Considerations on list, and if no comments, I'll release an -05. Adam Roach, as AD - I will put this on the Telechat as soon as -05 comes out unless anyone has an objection? (no comments from room) ------------------------------------------------------------ draft-ietf-stir-passport-divert Presenter: Jon Peterson Presentation: https://datatracker.ietf.org/meeting/103/materials/slides-103-stir-divert-and-out-of-band-00 slide 1: Title slide 2: draft-ietf-stir-passport-divert-04 slide 3: What's New in -04 slide 4: Pre-div in SHAKEN Jon - a recent question came up about having a signature over R-URIs. I think a R-URI is more ephemeral that is frequently modified. We might want to say something about this though. What if you are an authentication service and you get a call that you are supposed to sign, and the To and R-URI are already different? Does the difference reflect a semantic change? A different admin domain perhaps. How do handle it? We want to sign over To so the verification service knows who the original caller was trying to reach. If we want to change that, we'd have to change it in 8224. If you sign over R-URI and not the To, it exposes a new class of attacks. Jon - I kinda like things the way they are, and div was created to handle a change to the admin domain that was semantically meaningful. Since people are concerned about what to do - add language to div spec on why it works the way it does. div is an array, we could sign both the To and the R-URI. Chris? Chris - The freephone use case where the retargeting happens in the originating network or intermediary network that was the most discussed. After we discussed it, it's a different use case than typical call forwarding case vs the case where you call 1-800-United and it's a geographic phone number it's being redirected to and the end user knows it's representing 1-800-United. We need to talk about the differentiation between those two cases in this draft, and accommodate those cases on the shaken side. Jon - Redirection or retargeting cases on the originating side - that's what diversion was created for. We have created plugins that make div work for these use cases. I can imagine a auth service privy to a dip creating the whole div. Whoever is generating those queries should generate the full div for the call. I can add descriptive text to talk a bit more. The core mechanism is correct. I don't see what we would change in the mechanism. We should LC this and be done, right? Robert - +1 on not trying to change the mechanism to address the R-URI. If you consider the ATIS case and simplify it to a pure SIP case, and you receive a R-URI that is wholly unrelated to the To, what does that mean for your signature? Jon - We don't constrain policy decisions of authentication services and verification services. As long as you have the proper credential to sign the To, I can see you doing it in that case. Chris - We tried to make this generic and this adds some logic that makes it complex. I guess that's SIP in general. Jon - We could create a document on why authentication services and verification services  should sign and validate things respectively. What they should present to the application or user as a result of receiving a valid passport. There's a bit of guidance in 8224, but it's policy free, we don't say why you sign. If there was appetite in the WG to explore that more. Chris - it's the exceptions that you can handle R-URI change, but for the standard call forwarding scenarios, you should have a div. Jon - That's my preference, if you are creating a div, if you have a R-URI that is radically different than the original To. It makes it easier for a verification service when it receives the request. So you can have some assurance that it is not a cut and paste attack. slide 5: Issues Jon - I'm comfortable to go to LC with the spec as-is. Happy to have more eyes on it. Russ - Can anyone offer a reason why it is not ready for LC? (silence) ACTION: Start WGLC on draft-ietf-stir-passport-divert this week. ------------------------------------------------------------ draft-ietf-stir-oob Presenter: Jon Peterson Presentation: https://datatracker.ietf.org/meeting/103/materials/slides-103-stir-divert-and-out-of-band-00 slide 6: draft-ietf-stir-oob slide 7: Basic STIR Out of Band slide 8: Next Steps Russ - WGLC has been initiated, but haven't had a consensus call yet. Jon - We can have a consensus call that nobody cares and we can bring this forward. The idea was worth documenting, but not worth driving into a fuller mechanism at this point. Russ - If I recall the agreement in Montreal correctly, we were going to publish framework, but not details of protocol instances that implemented the framework. Jon - if anyone really wants to do this, I'll be waiting. I'll carry a torch. Russ - We will make the consensus call - if there are any last minute issues, post them immediately. ACTION: If anyone has last-minute issues with draft-ietf-stir-oob, post them to the mailing list immediately. ------------------------------------------------------------ draft-ietf-stir-passport-rcd Presenter: Chris Wendt Presentation: https://datatracker.ietf.org/meeting/103/materials/slides-103-stir-rich-call-data-00 slide 1: Title slide 2: Overview of update Chris - Any questions or comments? Jon - The only thing I'd add - for some of the 3rd party cases we discussed, there is a use in defining a ppt type for rcd because it would operate with different passport rules. Chris - Right, we didn't remove that, this is just an additional mechanism that we added to the document. slide 3: Example of 'shaken' + 'rcd' claim slide 4: Additional Update to Discuss Jon - I think we need it. There are a couple of ways to approach this. Do we want to include a jCard by reference or value? Do we want a URL in there? You could sign that compact form style. You could put the whole jCard in a SIP request and sign over that in passport. If you use the URL approach that could be in a separate SIP header, could sign that in compact form style. Doing it by reference, you could have other formats besides jCard. Gives you modularity. Russ - We have experience with a certificate that contains a URL, it's a longer lived thing than a passport. When it is done, you will see a URL followed by a hash. If you chase the value from the URIL you compare it to the hash. The signer and validator are both using the same dereferenced value. Jon - when a SIP call is in flight you can imagine the jCard changing, that could be surprising to the generator of the passport. Ted Hardy - I'm a little confused about what security property would be important when we are talking about a URI to a logo. There is content negotiation possible based on where you dereference it. What your UA is capable of displaying. The hashes to the canonical version have to be each included. You get a lot of failure modes. The value of RCD is not exactly the same as the certificate. I'm hesitant to do that unless you are sure the elements for which you want to do a URL and a hash - the nature of object that you dereference would be sufficiently static and last as the passport did. Russ - Jon said that there are other places in SIP where we do this. My point was, if we wanted to build a more general mechanism, then for some of them, the signer and validator need to make sure they got the same object. Ted - I agree, but where's that line? Would that go into this document or a more general one that addresses the use of URLs in SIP? Russ - Right now, the document has pass the whole value, there's no issue. Only if we choose to support some things passed by reference. If it's only RCD, I don't think there's an issue, if we go beyond that, need to make sure the template isn't applied inappropriately. Ted - That makes sense to me. You should limit the kinds of url schemes permitted here the way SIP does. A mismatch seems problematic. Chris - A jCard itself can have URLs inside them. Ted - That's different, you will sign the jCard as an assemblage. You aren't guaranteeing the objects dereferenced, you are saying this is what was presented as the jCard. The results of that versus the results of trying to sign dereferenced value are pretty different. Jon - I'm just want to get compact form back. I'm worried about the size of these things. If's a shaken passport, and we add a rcd to, and there's a div. Anything we can do to cut the passports down. We can do by value or by reference. By reference may have rough corners with e tags or hashes, that's just a versioning system for content on the other side of it. I'd like to get compact to work with this. Chris - I like including that. To early to know what the industry would do. Could see a future where all jCards are dereferenced through URL. slide 5: Rich Call Data Russ - Any last questions? (silence from room) ------------------------------------------------------------ Any Other Business (if time allows) and Wrap Up Presenters: Chairs Russ - We have wrapped up with 7 minutes to spare. Thank you. From nobody Thu Nov 8 14:08:02 2018 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 AEADD130DD6 for ; Thu, 8 Nov 2018 14:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 52I1OsGOA2VQ for ; Thu, 8 Nov 2018 14:07:59 -0800 (PST) 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 E1C15128C65 for ; Thu, 8 Nov 2018 14:07:58 -0800 (PST) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA8M7v0K021749 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 8 Nov 2018 16:07:58 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: "stir@ietf.org" From: Robert Sparks Message-ID: <6a5c0fc8-b76f-5892-550c-8a67f88cec24@nostrum.com> Date: Thu, 8 Nov 2018 16:07:57 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [stir] Draft minutes for STIR @ IETF103 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: Thu, 08 Nov 2018 22:08:01 -0000 Draft minutes for STIR at IETF103 are uploaded here: Please send any needed corrections or additions to the list or chairs ASAP. Thanks, RjS From nobody Thu Nov 8 14:24:48 2018 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 2B72612D4EC for ; Thu, 8 Nov 2018 14:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 k18F_vznCfHz for ; Thu, 8 Nov 2018 14:24:45 -0800 (PST) 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 6E0581274D0 for ; Thu, 8 Nov 2018 14:24:45 -0800 (PST) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA8MOhCc024518 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 8 Nov 2018 16:24:45 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: stir@ietf.org References: From: Robert Sparks Message-ID: <394dbd6e-0dbe-40bc-9beb-2d0cd06784de@nostrum.com> Date: Thu, 8 Nov 2018 16:24:43 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [stir] WGLC: draft-ietf-stir-oob-03 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: Thu, 08 Nov 2018 22:24:47 -0000 We received no comments on list during this last call. A few late ones (even if they just say "I read this document and am OK with it proceeding") would be welcome. There was support for requesting publication during the IETF 102 session, and no problems were raised at IETF 103, so we plan to move forward with a publication request (modulo addressing any nits found during a shepherd review). RjS On 10/19/18 11:19 AM, Robert Sparks wrote: > Please review and provide comments on > > > > by 2 Nov, 2018. > > I realize this is in the crunch period before IETF 103. If you expect > to have substantive comments, but need more time, just ask. However, > please make a best effort to have any major comments to the list > before we meet in Bangkok. > > RjS > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Sat Nov 17 15:17:26 2018 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 9EC96124BE5; Sat, 17 Nov 2018 15:17:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: stir@ietf.org, rjsparks@nostrum.com, draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks , stir-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> Date: Sat, 17 Nov 2018 15:17:16 -0800 Archived-At: Subject: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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: Sat, 17 Nov 2018 23:17:17 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-stir-passport-shaken-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5207 I would like to discuss the privacy properties of origids. As I read this text, it does not actually require them to be unlinkable or that it not be possible to determine whether two ids represent the same person behind the origid generator, and I believe it should do so. Practically implementing that may require an ID that is longer than a UUID. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- > > This document extends PASSporT, which is a token object that conveys > cryptographically-signed information about the participants involved > in communications. The extension is defined, corresponding to the > SHAKEN specification, to provide both a specific set of levels-of- > confidence to the correctness of the originating identity for a SIP Nit: confidence of or confidence in > in communications. The extension is defined, corresponding to the > SHAKEN specification, to provide both a specific set of levels-of- > confidence to the correctness of the originating identity for a SIP > based Communication Service Provider (CSP) telephone network > originated call as well as an identifier that allows the CSP to > uniquely identify the origination of the call within its network. Nit: originator S 1. > need to be accounted for where PASSporT signatures may represent > either direct or indirect call origination scenarios. The SHAKEN > [ATIS-1000074] specification defines levels of attestation of the > origination of the call as well as an origination identifier that can > help create a unique association with the origination of calls from > various parts of the VoIP or TDM telephone network. This document I can't read this. What is the association between? S 2. > capitals, as shown here. > > In addition, the following terms are used in this document: > > o Verified association: is typically defined as an authenticated > relationship with a device that initiated a call, for example, a relationship between the call and the device? S 4. > > o Has a direct authenticated relationship with the initiator of the > call and can identify the customer associated with the initiator. > > o Has NOT established a verified association with the calling party > telephone number being used for the call. For those who aren't; voice experts, can you give an example of when this would happen? S 10. > integrity protection and non-repudiation properties as the base > claims in the PASSporT. > > 10. Privacy Considerations > > As detailed in [RFC3261] Section 26, SIP messages inherently carry Thanks for including this section. From nobody Sun Nov 18 17:29:23 2018 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 701EF124BAA; Sun, 18 Nov 2018 17:29:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks , stir-chairs@ietf.org, rjsparks@nostrum.com, stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154259095538.2354.17623821529843764623.idtracker@ietfa.amsl.com> Date: Sun, 18 Nov 2018 17:29:15 -0800 Archived-At: Subject: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 19 Nov 2018 01:29:16 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-stir-passport-shaken-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- A nontrivial amount of text in this document appears to have been taken from https://access.atis.org/apps/group_public/download.php/32237/ATIS-1000074.pdf which notes that "No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher." Do we have prior written permission to duplicate such text? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am interested in seeing the resolution of discussion on Ekr's Discuss, but will stick to that thread for such discussion. Section 4 Am I reading this properly that the difference between 'A' and 'B' is that in 'B' we don't have any information about the device that's originating the call, just the identity of the user/customer? From nobody Sun Nov 18 17:34:39 2018 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 892541293FB; Sun, 18 Nov 2018 17:34:37 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 N743TCoNmfp3; Sun, 18 Nov 2018 17:34:35 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 DFAFB127332; Sun, 18 Nov 2018 17:34:34 -0800 (PST) X-AuditID: 1209190c-437ff700000016cd-a4-5bf21328a48f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 88.31.05837.92312FB5; Sun, 18 Nov 2018 20:34:33 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id wAJ1YSxt024261; Sun, 18 Nov 2018 20:34:29 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAJ1YMTI013941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Nov 2018 20:34:25 -0500 Date: Sun, 18 Nov 2018 19:34:22 -0600 From: Benjamin Kaduk To: Eric Rescorla Cc: The IESG , stir@ietf.org, stir-chairs@ietf.org, draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks Message-ID: <20181119013422.GS11132@kduck.kaduk.org> References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT19UU/hRt0D9V3mLbsutsFiten2O3 mPFnIrPFtTmNbBbPdqxntVi+dhuTA5vHkiU/mTxm7XzC4jH5cRtzAHMUl01Kak5mWWqRvl0C V8br6ZuZCr5JVOzZvI+5gXGnSBcjJ4eEgInE5etvGLsYuTiEBNYwScxd+J8dwtnIKLHz3lUo 5y6TxO0fj5hAWlgEVCW+7VjKDmKzCahINHRfZgaxRQQUJH79OcEC0sAssJhR4siaI0AOB4ew QIbEwj4+kBpeoHUL785kBLGFBHwl/rVcZISIC0qcnPmEBcRmFtCSuPHvJRNIK7OAtMTyfxwg YU4BP4m3Pw6DlYsKKEvs7TvEPoFRYBaS7llIumchdC9gZF7FKJuSW6Wbm5iZU5yarFucnJiX l1qka6iXm1mil5pSuokRFNickjw7GM+88TrEKMDBqMTDe+DIx2gh1sSy4srcQ4ySHExKorwr BD5FC/El5adUZiQWZ8QXleakFh9ilOBgVhLhnbnmQ7QQb0piZVVqUT5MSpqDRUmc97fI42gh gfTEktTs1NSC1CKYrAwHh5IE7xlBoKGCRanpqRVpmTklCGkmDk6Q4TxAw4NAaniLCxJzizPT IfKnGBWlxHn/gCQEQBIZpXlwvaDEI5G9v+YVozjQK8K8TSBVPMCkBdf9CmgwE9Dg51ffgwwu SURISTUw+jqWPPsY95y5uV/fdXW5dmI26wHbuzt2NkpovBXNe1kflexwnJdz23tN5jDZs5LP 6n6eFdx7QXETe/qyaybflI/5PBH9+SO1gKdyrzDzTYtba1u+HE/1r7Gcf+zkgvU8iwyX7m6X mRIf73pBLWxXf8LKU/EskpvF0vquaok/Fwme+Dd7T2uOEktxRqKhFnNRcSIAhWrS0RcDAAA= Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 19 Nov 2018 01:34:38 -0000 On Sat, Nov 17, 2018 at 03:17:16PM -0800, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-stir-passport-shaken-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D5207 > > > I would like to discuss the privacy properties of origids. As I read > this text, it does not actually require them to be unlinkable or that > it not be possible to determine whether two ids represent the same > person behind the origid generator, and I believe it should do so. > Practically implementing that may require an ID that is longer than a > UUID. Some notes I took while performing my own review of the doc... Section 5 of the doc says: SHAKEN isn't prescriptive in the exact usage of origid other than the UUID format as a globally unique identifier representing the originator of the call to whatever granularity the PASSporT signer determines is sufficient for the ability to trace the original origination point of the call. The ATIS doc only says that 'origid' "should" be a UUID, so there is some freedom to use other formats. They also give different guidelines for the granularity of origination, allowing the provider to provide an anonymity shield for 'A'-level originations but indicating very fine-grained tracing for 'B'-level origination (e.g., for fraud detection). For 'C'-level attestation there isn't enough information available to make fine-grained tracking worthwhile so a coarser identifier is okay there. The recommended 'B'-level behavior is probably worrisome from a user privacy perspective, as Ekr notes. One thing that seems missing from the document is to back up the "opaque" nature of the origid (which just means that recipients aren't expected to look inside it) with a stronger notion that it should not have discernable internal structure, whether by virtue of being a random value or by being a token self-encrypted at the originating device for later decryption. (Of course, self-encryption brings with it requirements on key management, which may be undesirable.) While it's unclear that we have much room here to provide normative guidance for origid generation, there does seem to be plenty of space for a more in-depth discussion of the privacy landscape, what factors might go into the decision of what granularity of origid to use, possible techniques for generating origids that preserve various privacy properties, etc. -Benjamin From nobody Mon Nov 19 09:01:08 2018 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 26A20130DD3; Mon, 19 Nov 2018 09:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 D6n0LXK3bp7x; Mon, 19 Nov 2018 09:00:55 -0800 (PST) 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 A92811277BB; Mon, 19 Nov 2018 09:00:55 -0800 (PST) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAJH0sHe081893 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 19 Nov 2018 11:00:55 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: Eric Rescorla , The IESG Cc: stir@ietf.org, stir-chairs@ietf.org, draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <58cb9f5a-bbe8-147f-5dfc-8abed5ba0c52@nostrum.com> Date: Mon, 19 Nov 2018 11:00:48 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------9E215A3791B863885FEC67B4" Content-Language: en-US Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 19 Nov 2018 17:00:57 -0000 This is a multi-part message in MIME format. --------------9E215A3791B863885FEC67B4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/17/18 5:17 PM, Eric Rescorla wrote: > S 4. >> >> o Has a direct authenticated relationship with the initiator of the >> call and can identify the customer associated with the initiator. >> >> o Has NOT established a verified association with the calling party >> telephone number being used for the call. > For those who aren't; voice experts, can you give an example of when > this would happen? There are some uncommon but valid cases in which Voice ISPs may allow a calling party to specify a calling number that the Voice ISP can't verify as being assigned to the calling user. Consider, for example, a service like Google Voice, which provides a single number that forwards to multiple destinations. I may want to be able to make calls from my Voice ISP (who has no association with Google) with my Google Voice number as the originating number. While my Voice ISP has authenticated me and knows who I am, it has no way to validate that I have control of that number; so, if it is signing a Shaken token with that number, it would have to mark it as Partial Attestation. There are similar situations that can be employed for whole-PBX failover when multiple Voice ISPs are used for high-availability purposes. We can debate whether these use cases are good to have in the world, but that won't change that they are currently in use; and I think it's clear that using Passport with them is an improvement over the status quo. /a --------------9E215A3791B863885FEC67B4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 11/17/18 5:17 PM, Eric Rescorla wrote:
S 4.

  
     o  Has a direct authenticated relationship with the initiator of the
        call and can identify the customer associated with the initiator.
  
     o  Has NOT established a verified association with the calling party
        telephone number being used for the call.

For those who aren't; voice experts, can you give an example of when
this would happen?


There are some uncommon but valid cases in which Voice ISPs may allow a calling party to specify a calling number that the Voice ISP can't verify as being assigned to the calling user.

Consider, for example, a service like Google Voice, which provides a single number that forwards to multiple destinations. I may want to be able to make calls from my Voice ISP (who has no association with Google) with my Google Voice number as the originating number. While my Voice ISP has authenticated me and knows who I am, it has no way to validate that I have control of that number; so, if it is signing a Shaken token with that number, it would have to mark it as Partial Attestation.

There are similar situations that can be employed for whole-PBX failover when multiple Voice ISPs are used for high-availability purposes.

We can debate whether these use cases are good to have in the world, but that won't change that they are currently in use; and I think it's clear that using Passport with them is an improvement over the status quo.

/a

--------------9E215A3791B863885FEC67B4-- From nobody Mon Nov 19 10:00:59 2018 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 F080F130E69 for ; Mon, 19 Nov 2018 10:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 GKHbeH9TKMTp for ; Mon, 19 Nov 2018 10:00:43 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 D6D0D130E8B for ; Mon, 19 Nov 2018 10:00:37 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id k19-v6so26915171lji.11 for ; Mon, 19 Nov 2018 10:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lp77o0DjHWtJ2TQhcPhtCdXncDR2hlF+EtEX9yDIegg=; b=GXFNRv63j+XHPhO75FZeaN7W488B1taYKWPigvm2ZJMlUJEmnbBX9lwbQT3aXHHgZp 02l5jva9zOKAl2pT+8OSEO0LZTYZqCqycbxuvsBpKRAts5y3/91mYcV9y2giE3TpNwZy owva8ljclOGANX+QYOlniezpOYMQ9egCBaFXOrZVMAN/VZ5Kz3EacOPaqixzII+15A2+ yxkR8m9EJRbemp1CYPQT4T4zIr5UUkjDJ/v2ZLWfHu491HAnY0rVUDsj9wULUWouccHe CpK3tnsOHuZmld4z07tc0Os89lTG3RcfwiNQ/GghzJBgF60yRKVHdMQBz5bVfZJVoi7f v/Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lp77o0DjHWtJ2TQhcPhtCdXncDR2hlF+EtEX9yDIegg=; b=MDbRNyLgpycapJ/loH3XubTh2mOPZqmUHVAnjs9ihhCNmoFYuyc7pR4SknqecT769l 7cbk6xDmVddQuzo3fPgFmOGJ1bHOkWXfgWDXMYKJBKVkWsNbyejmtNGOYmHw/oa+W4/R ClllzD/oQWaSSnxHan9VNPO6agHsicQR8RA662KThlZWzWO0FmfsqntdcVrpE6WKlOy5 +x3hHjYYcO26TOrL/4twL4KP6r0ea4vq2zPIQ2rXoOJix7QrryBSilK+6aMUvJRz6x8b CXHThxcr0DajuJmLMB9hmwN+cigP3O/xTMlN5gF1Hi2+aPpE0kMSH03qe6NjQ0pmv343 w65w== X-Gm-Message-State: AGRZ1gJA3Ctbls5p45iT1k2H2OXjVcqKcBafjDk4oPXs+HuIp+rAzrlQ mFC6R71np9qn7NP3/pcMv6NZseyNPn4j6aUmHTCfRdeo X-Google-Smtp-Source: AJdET5dyqRhiGjIxbouMQBbojJM14MbN3GD+9bpDjLoQdp3eHNecqj0c7pdj4rP7ckxoGhOwHWa0oM3V3a6UKTQC1XI= X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr13304396ljb.51.1542650435697; Mon, 19 Nov 2018 10:00:35 -0800 (PST) MIME-Version: 1.0 References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> <58cb9f5a-bbe8-147f-5dfc-8abed5ba0c52@nostrum.com> In-Reply-To: <58cb9f5a-bbe8-147f-5dfc-8abed5ba0c52@nostrum.com> From: Eric Rescorla Date: Mon, 19 Nov 2018 09:59:58 -0800 Message-ID: To: Adam Roach Cc: IESG , IETF STIR Mail List , stir-chairs@ietf.org, draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks Content-Type: multipart/alternative; boundary="0000000000003b9d85057b084b51" Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 19 Nov 2018 18:00:51 -0000 --0000000000003b9d85057b084b51 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 19, 2018 at 9:00 AM Adam Roach wrote: > On 11/17/18 5:17 PM, Eric Rescorla wrote: > > S 4. > > > o Has a direct authenticated relationship with the initiator of the > call and can identify the customer associated with the initiator. > > o Has NOT established a verified association with the calling party > telephone number being used for the call. > > For those who aren't; voice experts, can you give an example of when > this would happen? > > > There are some uncommon but valid cases in which Voice ISPs may allow a > calling party to specify a calling number that the Voice ISP can't verify > as being assigned to the calling user. > > Consider, for example, a service like Google Voice, which provides a > single number that forwards to multiple destinations. I may want to be able > to make calls from my Voice ISP (who has no association with Google) with > my Google Voice number as the originating number. While my Voice ISP has > authenticated me and knows who I am, it has no way to validate that I have > control of that number; so, if it is signing a Shaken token with that > number, it would have to mark it as Partial Attestation. > OK. There are similar situations that can be employed for whole-PBX failover > when multiple Voice ISPs are used for high-availability purposes. > > We can debate whether these use cases are good to have in the world, but > that won't change that they are currently in use; and I think it's clear > that using Passport with them is an improvement over the status quo. > I'm not arguing against it, I'm just trying to get clarity on what these levels mean. -Ekr --0000000000003b9d85057b084b51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Nov 19, 2018 at 9:00 AM Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 11/17/18 5:17 PM= , Eric Rescorla wrote:
S 4.

 =20
     o  Has a direct authenticated relationship with the initiator of the
        call and can identify the customer associated with the initiator.
 =20
     o  Has NOT established a verified association with the calling party
        telephone number being used for the call.

For those who aren&=
#39;t; voice experts, can you give an example of when
this would happen?


There are some uncommon but valid cases in which Voice ISPs may allow a calling party to specify a calling number that the Voice ISP can't verify as being assigned to the calling user.

Consider, for example, a service like Google Voice, which provides a single number that forwards to multiple destinations. I may want to be able to make calls from my Voice ISP (who has no association with Google) with my Google Voice number as the originating number. While my Voice ISP has authenticated me and knows who I am, it has no way to validate that I have control of that number; so, if it is signing a Shaken token with that number, it would have to mark it as Partial Attestation.

OK.

There are similar situations that can be employed for whole-PBX failover when multiple Voice ISPs are used for high-availability purposes.

We can debate whether these use cases are good to have in the world, but that won't change that they are currently in use; and = I think it's clear that using Passport with them is an improvement over the status quo.


I&= #39;m not arguing against it, I'm just trying to get clarity on what th= ese levels mean.

-Ekr
--0000000000003b9d85057b084b51-- From nobody Mon Nov 19 10:30:57 2018 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 73C46130DDA; Mon, 19 Nov 2018 10:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zipdx.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 9lFKO9hWBjWv; Mon, 19 Nov 2018 10:30:54 -0800 (PST) Received: from xdev1sjc.zipdx.com (sjc-e-66.zipdx.com [166.88.23.66]) (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 65DA8130DC6; Mon, 19 Nov 2018 10:30:54 -0800 (PST) Received: from DPFENVY (unknown [75.104.70.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: dfrankel) by xdev1sjc.zipdx.com (Postfix) with ESMTPSA id AEAFF1B80227; Mon, 19 Nov 2018 10:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=zipdx.com; s=default; t=1542652252; bh=CXb6LTxhG0YelheK8iAg+571WR9f+XasJooSyWXGaOQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From; b=G0wpXE20i8hqWPJT/ZxkqnsALGmwhmzpbjZXRw7t+7haz6ryktDkgM++k6gWutHcK qWQx84gOCsgGBbHOASlVAz5IolnZJ1UJrpWwyFXwU1XhUauPr4OtOFdrib3b6AIt2G a/EJRdJbNs4SyqlTG+lwSo+url/K7VEzUtCySZ/4= From: "David Frankel" To: "'Eric Rescorla'" , "'Adam Roach'" Cc: "'IETF STIR Mail List'" , "'Robert Sparks'" , , "'IESG'" , References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> <58cb9f5a-bbe8-147f-5dfc-8abed5ba0c52@nostrum.com> In-Reply-To: Date: Mon, 19 Nov 2018 10:30:34 -0800 Organization: ZipDX LLC Message-ID: <03e101d48036$001c9710$0055c530$@zipdx.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E2_01D47FF2.F1FF7190" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEz6ziGAlcoMGRra29cN6BLj3SEegLLDCFwAI2CKPGmfcnREA== Content-Language: en-us Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 19 Nov 2018 18:30:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03E2_01D47FF2.F1FF7190 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Eric, =20 I agree with (what I think) you are saying =E2=80=93 it is difficult to = know how a call recipient or their agent should treat Partial = Attestation. =20 As Adam explained, this means that the originating provider = =E2=80=9Cknows the customer=E2=80=9D but can=E2=80=99t =E2=80=9Cvouch = for the specific telephone number.=E2=80=9D =20 This is problematic because what it means to =E2=80=9Cknow the = customer=E2=80=9D may be quite different depending on who the provider = is. To one provider, it may mean =E2=80=9CI have a long-term established = and trusted business relationship with the originating customer, and I = have explicitly permitted them to use third-party numbers.=E2=80=9D = Another provider may say, =E2=80=9CI know this customer=E2=80=99s IP = address, and not much else, and my policy is to pass onward whatever = telephone number is delivered to me.=E2=80=9D =20 Perhaps that second category of provider will earn a =E2=80=9Cbad = reputation=E2=80=9D across the industry and that will result in = differential treatment at the receiving end. That presumes that there = will be a provider reputation database (or multiple databases) that will = no doubt engender its own set of controversies. =20 Even without STIR, providers have always had the opportunity to be = discriminating about the originating telephone numbers they allow their = customers to use. In SS7/ISDN, there was the concept of =E2=80=9Cnetwork = provided=E2=80=9D numbers (inserted by the provider and known to belong = to the calling party); =E2=80=9Ccustomer-provided, = network-screened=E2=80=9D (number supplied by the customer, but checked = against a list of known-OK numbers for that customer maintained by the = provider), and =E2=80=9Cnot screened=E2=80=9D (provider basically says = =E2=80=9CI have no clue=E2=80=9D when it comes to the validity of the = calling number). =20 Today, there are some providers that are quite diligent about only = allowing their customers to use =E2=80=9Cnetwork-screened=E2=80=9D = numbers; they have a variety of approaches for validating those numbers = (for example, by calling each number and making sure the customer = answers). But obviously illegal robocallers use providers that operate = in the =E2=80=9CI have no clue=E2=80=9D regime. =20 Ofcom, the UK regulator, recently published a paper describing proper = provider treatment of what they call Presentation Number (our Caller-ID = or FROM number), and the Network Number (what used to be our Charge = Number or Billing Telephone Number or P-Charge-Info). In the Ofcom = model, the Network Number is always supplied by the provider and is = always a telephone number that is serviced by that provider and is known = to be assigned to the originating caller. =20 The Ofcom Guide, which I think is excellent, can be downloaded from = here: https://www.ofcom.org.uk/phones-telecoms-and-internet/information-for-ind= ustry/telecoms-industry-guidance/calling-line-identification =20 What would be great in the STIR context you are discussing is if the = provider, when signing the call, could insert something equivalent to = the UK =E2=80=9Cnetwork number=E2=80=9D so that the receiving end of the = call could have more certainty about the origin of the call. This would = greatly limit the prevalence of =E2=80=9Canonymous=E2=80=9D calls = flooding our network, and would reduce the necessity of a provider = reputation database. There would still be mechanisms for making calls = anonymously, but the recipient could then make an explicit choice to = reject such calls. David =20 David Frankel ZipDX=C2=AE LLC Monte Sereno, CA USA Tel: 1-800-FRANKEL (1-800-372-6535) Watch Our Video! =20 From: stir On Behalf Of Eric Rescorla Sent: Monday, November 19, 2018 10:00 AM To: Adam Roach Cc: IETF STIR Mail List ; Robert Sparks = ; draft-ietf-stir-passport-shaken@ietf.org; IESG = ; stir-chairs@ietf.org Subject: Re: [stir] Eric Rescorla's Discuss on = draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) =20 =20 On Mon, Nov 19, 2018 at 9:00 AM Adam Roach > wrote: On 11/17/18 5:17 PM, Eric Rescorla wrote: S 4. =20 o Has a direct authenticated relationship with the initiator of = the call and can identify the customer associated with the = initiator. =20 o Has NOT established a verified association with the calling = party telephone number being used for the call. For those who aren't; voice experts, can you give an example of when this would happen? =20 There are some uncommon but valid cases in which Voice ISPs may allow a = calling party to specify a calling number that the Voice ISP can't = verify as being assigned to the calling user. Consider, for example, a service like Google Voice, which provides a = single number that forwards to multiple destinations. I may want to be = able to make calls from my Voice ISP (who has no association with = Google) with my Google Voice number as the originating number. While my = Voice ISP has authenticated me and knows who I am, it has no way to = validate that I have control of that number; so, if it is signing a = Shaken token with that number, it would have to mark it as Partial = Attestation. OK. =20 There are similar situations that can be employed for whole-PBX failover = when multiple Voice ISPs are used for high-availability purposes. We can debate whether these use cases are good to have in the world, but = that won't change that they are currently in use; and I think it's clear = that using Passport with them is an improvement over the status quo. =20 I'm not arguing against it, I'm just trying to get clarity on what these = levels mean. =20 -Ekr ------=_NextPart_000_03E2_01D47FF2.F1FF7190 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Eric,

 

I agree with = (what I think) you are saying =E2=80=93 it is difficult to know how a = call recipient or their agent should treat Partial = Attestation.

 

As Adam explained, this means that the originating = provider =E2=80=9Cknows the customer=E2=80=9D but can=E2=80=99t = =E2=80=9Cvouch for the specific telephone = number.=E2=80=9D

 

This is = problematic because what it means to =E2=80=9Cknow the customer=E2=80=9D = may be quite different depending on who the provider is. To one = provider, it may mean =E2=80=9CI have a long-term established and = trusted business relationship with the originating customer, and I have = explicitly permitted them to use third-party numbers.=E2=80=9D Another = provider may say, =E2=80=9CI know this customer=E2=80=99s IP address, = and not much else, and my policy is to pass onward whatever telephone = number is delivered to me.=E2=80=9D

 

Perhaps that = second category of provider will earn a =E2=80=9Cbad reputation=E2=80=9D = across the industry and that will result in differential treatment at = the receiving end. That presumes that there will be a provider = reputation database (or multiple databases) that will no doubt engender = its own set of controversies.

 

Even without = STIR, providers have always had the opportunity to be discriminating = about the originating telephone numbers they allow their customers to = use. In SS7/ISDN, there was the concept of =E2=80=9Cnetwork = provided=E2=80=9D numbers (inserted by the provider and known to belong = to the calling party); =E2=80=9Ccustomer-provided, = network-screened=E2=80=9D (number supplied by the customer, but checked = against a list of known-OK numbers for that customer maintained by the = provider), and =E2=80=9Cnot screened=E2=80=9D (provider basically says = =E2=80=9CI have no clue=E2=80=9D when it comes to the validity of the = calling number).

 

Today, there = are some providers that are quite diligent about only allowing their = customers to use =E2=80=9Cnetwork-screened=E2=80=9D numbers; they have a = variety of approaches for validating those numbers (for example, by = calling each number and making sure the customer answers). But obviously = illegal robocallers use providers that operate in the =E2=80=9CI have no = clue=E2=80=9D regime.

 

Ofcom, the = UK regulator, recently published a paper describing proper provider = treatment of what they call Presentation Number (our Caller-ID or FROM = number), and the Network Number (what used to be our Charge Number or = Billing Telephone Number or P-Charge-Info). In the Ofcom model, the = Network Number is always supplied by the provider and is always a = telephone number that is serviced by that provider and is known to be = assigned to the originating caller.

 

The Ofcom = Guide, which I think is excellent, can be downloaded from = here:

htt= ps://www.ofcom.org.uk/phones-telecoms-and-internet/information-for-indust= ry/telecoms-industry-guidance/calling-line-identification<= /p>

 

What = would be great in the STIR context you are discussing is if the = provider, when signing the call, could insert something equivalent to = the UK =E2=80=9Cnetwork number=E2=80=9D so that the receiving end of the = call could have more certainty about the origin of the call. This would = greatly limit the prevalence of =E2=80=9Canonymous=E2=80=9D calls = flooding our network, and would reduce the necessity of a provider = reputation database. There would still be mechanisms for making calls = anonymously, but the recipient could then make an explicit choice to = reject such calls.


David

 

David = Frankel

ZipDX=C2=AE<= span style=3D'color:#1F497D;mso-fareast-language:ZH-TW'> LLC

Monte Sereno, CA = USA

Tel: 1-800-FRANKEL = (1-800-372-6535)

Watch Our Video!

 

From: = stir <stir-bounces@ietf.org> On Behalf Of Eric = Rescorla
Sent: Monday, November 19, 2018 10:00 = AM
To: Adam Roach <adam@nostrum.com>
Cc: IETF = STIR Mail List <stir@ietf.org>; Robert Sparks = <rjsparks@nostrum.com>; draft-ietf-stir-passport-shaken@ietf.org; = IESG <iesg@ietf.org>; stir-chairs@ietf.org
Subject: Re: = [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: = (with DISCUSS and COMMENT)

 

 

On Mon, Nov 19, 2018 at 9:00 AM Adam Roach <adam@nostrum.com> = wrote:

On 11/17/18 5:17 PM, Eric Rescorla = wrote:

S =
4.
=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0o=C2=A0 Has a direct =
authenticated relationship with the initiator of =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 call =
and can identify the customer associated with the =
initiator.
=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0o=C2=A0 Has NOT =
established a verified association with the calling =
party
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
telephone number being used for the =
call.
For those who aren't; =
voice experts, can you give an example of when
this =
would =
happen?

 

There = are some uncommon but valid cases in which Voice ISPs may allow a = calling party to specify a calling number that the Voice ISP can't = verify as being assigned to the calling user.

Consider, = for example, a service like Google Voice, which provides a single number = that forwards to multiple destinations. I may want to be able to make = calls from my Voice ISP (who has no association with Google) with my = Google Voice number as the originating number. While my Voice ISP has = authenticated me and knows who I am, it has no way to validate that I = have control of that number; so, if it is signing a Shaken token with = that number, it would have to mark it as Partial = Attestation.

OK.

 

There are similar situations that can be employed for = whole-PBX failover when multiple Voice ISPs are used for = high-availability purposes.

We can debate whether these = use cases are good to have in the world, but that won't change that they = are currently in use; and I think it's clear that using Passport with = them is an improvement over the status = quo.

 

I'm not arguing against it, I'm just trying to get = clarity on what these levels mean.

 

-Ekr

------=_NextPart_000_03E2_01D47FF2.F1FF7190-- From nobody Mon Nov 19 13:24:01 2018 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 BD6EE130DF4 for ; Mon, 19 Nov 2018 13:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 GZmbMoKY9uRz for ; Mon, 19 Nov 2018 13:23:58 -0800 (PST) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id B41BB130934 for ; Mon, 19 Nov 2018 13:23:58 -0800 (PST) X-AuditID: 12074412-41bff70000007195-3a-5bf329edc132 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id E7.A0.29077.DE923FB5; Mon, 19 Nov 2018 16:23:57 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id wAJLNutv017881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 19 Nov 2018 16:23:57 -0500 To: stir@ietf.org References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> <58cb9f5a-bbe8-147f-5dfc-8abed5ba0c52@nostrum.com> From: Paul Kyzivat Message-ID: Date: Mon, 19 Nov 2018 16:23:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <58cb9f5a-bbe8-147f-5dfc-8abed5ba0c52@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixO6iqPtW83O0weQzVhbL125jcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxobDBQVTBCr2TktsYNzB08XIySEhYCJx/dBDti5GLg4hgYNM Ei/f3mGHcL4ySaxY948FpEpYIF/i94k1TCC2iICgxL0Zp5kgipoYJeZcWc0MkmAT0JKYc+g/ WAOvgL3E2gtfwRpYBFQluu7vZwWxRQXSJP52LmGEqBGUODnzCVg9J1B9z9dJYHOYBcwk5m1+ CGWLS9x6Mp8JwpaX2P52DvMERv5ZSNpnIWmZhaRlFpKWBYwsqxjlEnNKc3VzEzNzilOTdYuT E/PyUot0zfRyM0v0UlNKNzFCglJoB+P6k3KHGAU4GJV4eA8c+RgtxJpYVlyZe4hRkoNJSZT3 zP1P0UJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeAOWAeV4UxIrq1KL8mFS0hwsSuK8zCZ7o4QE 0hNLUrNTUwtSi2CyMhwcShK8+zQ+RwsJFqWmp1akZeaUIKSZODhBhvMADX8LUsNbXJCYW5yZ DpE/xajLsedr0wxmIZa8/LxUKXHeS+pARQIgRRmleXBzYMnkFaM40FvCvOtARvEAExHcpFdA S5iAljy/+h5kSUkiQkqqgfHw6f/iV8x+CvEuU7DqDOR0VJ55nl261lnk9HUd5p2G6+/rscv+ tl13NdC3ScFif0ij8oOd4hsKAtnCbhx/8mVq2eR1i98v21Y/lf+D8otLKgvKZe7JH4/5+aXm imMo58PJ71JfBoVzX+D2XrM3tPBchcVpv8bGUu27lndPPHr097zcj+X7OWYqsRRnJBpqMRcV JwIA4xBBnQEDAAA= Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 19 Nov 2018 21:24:01 -0000 On 11/19/18 12:00 PM, Adam Roach wrote: > On 11/17/18 5:17 PM, Eric Rescorla wrote: >> S 4. >>> >>> o Has a direct authenticated relationship with the initiator of the >>> call and can identify the customer associated with the initiator. >>> >>> o Has NOT established a verified association with the calling party >>> telephone number being used for the call. >> For those who aren't; voice experts, can you give an example of when >> this would happen? > > > There are some uncommon but valid cases in which Voice ISPs may allow a > calling party to specify a calling number that the Voice ISP can't > verify as being assigned to the calling user. > > Consider, for example, a service like Google Voice, which provides a > single number that forwards to multiple destinations. I may want to be > able to make calls from my Voice ISP (who has no association with > Google) with my Google Voice number as the originating number. While my > Voice ISP has authenticated me and knows who I am, it has no way to > validate that I have control of that number; so, if it is signing a > Shaken token with that number, it would have to mark it as Partial > Attestation. I don't find this a sufficient justification to allow this behavior. Rather, in this case I think it should be necessary to involve the owner of the claimed number in the call path so that it can attest to the number. IIUC that is what Google Voice does today. Thanks, Paul > There are similar situations that can be employed for whole-PBX failover > when multiple Voice ISPs are used for high-availability purposes. > > We can debate whether these use cases are good to have in the world, but > that won't change that they are currently in use; and I think it's clear > that using Passport with them is an improvement over the status quo. > > /a > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From nobody Mon Nov 19 15:49:55 2018 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 495EF130E5A for ; Mon, 19 Nov 2018 15:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 dXlVcM_IUIzY for ; Mon, 19 Nov 2018 15:49:46 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 C9D0C130E43 for ; Mon, 19 Nov 2018 15:49:45 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id x85-v6so73708ljb.2 for ; Mon, 19 Nov 2018 15:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4CiiutWv2Rh7W80Sol9jaibI/7RMZ7QUVvPvj93Wsz4=; b=p9a8OYkZTURxKliY2eIeBuWdlScFIIbeC6vSMpMrl72nrXWDBpJ6aWlQaajWnAzUde 7hJGjLa6bsFBedkfDheXBoqA94hdV3CSSrrU8XmT2zJGaJJmBR9B///ESk9XQ6mgrZl5 syu7+derboYxVxO31wJsEbi8CE5l4e78KVWOOHkDMpH87HoFw4N/dT+bUnA9LjxvMQUw AJiKmtoVyHiWwBts8b9Jr/RXVVlvIrRUAbgE3alSBTZBBRdJqhdpn2MDd9+ez/bxxr4w N/J0mtiG4PoRhFTzWK29MoD/6bGo6Mde0J36d/uYEnjWNs9K8OHgz8AHWMWgIxf4GzIo 84cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4CiiutWv2Rh7W80Sol9jaibI/7RMZ7QUVvPvj93Wsz4=; b=GaTC1QorJuvQ+qYrTUUuzJ539D5LGbyIm1XMUJaeF2V6GwZ1gkGLZRlijnc0FNok7W hn9CVIToyRG2j29BbSQ2nTbDo3knlQS4n/xaSl76O6d/05uD6PbyVWxNABE++yPDZMq1 r0g2bZNGGacZqp4TCLOpnKzrkiRiPDwQMcyOhej6nUX3f9FcAd/3HVdOWiH5CRvmOHzX wcjxF9DKQJ/LMMNO/YETZ78n+2piF77plfCWClDvN3YCS8z/PuzCPS7wmsLA3/+2q8gR j4Te3SMm7KKNxw376x7RIt5iy3RY241N4E7ftcPYC9ZFHCPU3d2N6eRzCwWugdSr+GI5 DRMA== X-Gm-Message-State: AGRZ1gJSylJPZjZnAKCZNr6Hfi82bp+KgPNxoggq+tgFf1TU7R8TnXuI OXWu2ZWTXYlUd5AHMCLfnb3BvtjLUDHAYTPPra5aNw== X-Google-Smtp-Source: AJdET5cFVsGufDPGtA5HKL9jb+wyrsj7P/gZV50A+C5Kxic2IwT54E2zLzBmiEMDn2YaO32FBKsQ+OoA0lOE+dRlrbY= X-Received: by 2002:a2e:9a84:: with SMTP id p4-v6mr12519142lji.73.1542671383917; Mon, 19 Nov 2018 15:49:43 -0800 (PST) MIME-Version: 1.0 References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> <58cb9f5a-bbe8-147f-5dfc-8abed5ba0c52@nostrum.com> In-Reply-To: From: Eric Rescorla Date: Mon, 19 Nov 2018 15:49:07 -0800 Message-ID: To: Paul Kyzivat Cc: IETF STIR Mail List Content-Type: multipart/alternative; boundary="000000000000d80ae4057b0d2bc8" Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 19 Nov 2018 23:49:54 -0000 --000000000000d80ae4057b0d2bc8 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 19, 2018 at 1:24 PM Paul Kyzivat wrote: > On 11/19/18 12:00 PM, Adam Roach wrote: > > On 11/17/18 5:17 PM, Eric Rescorla wrote: > >> S 4. > >>> > >>> o Has a direct authenticated relationship with the initiator of > the > >>> call and can identify the customer associated with the > initiator. > >>> > >>> o Has NOT established a verified association with the calling > party > >>> telephone number being used for the call. > >> For those who aren't; voice experts, can you give an example of when > >> this would happen? > > > > > > There are some uncommon but valid cases in which Voice ISPs may allow a > > calling party to specify a calling number that the Voice ISP can't > > verify as being assigned to the calling user. > > > > Consider, for example, a service like Google Voice, which provides a > > single number that forwards to multiple destinations. I may want to be > > able to make calls from my Voice ISP (who has no association with > > Google) with my Google Voice number as the originating number. While my > > Voice ISP has authenticated me and knows who I am, it has no way to > > validate that I have control of that number; so, if it is signing a > > Shaken token with that number, it would have to mark it as Partial > > Attestation. > > I don't find this a sufficient justification to allow this behavior. > Rather, in this case I think it should be necessary to involve the owner > of the claimed number in the call path so that it can attest to the > number. IIUC that is what Google Voice does today. > I want to emphasize that I'm not arguing about this behavior (my DISCUSS was about a specific technical point). I just wanted to get an explanation. I would, however, encourage the authors to add an example to the spec. -Ekr > Thanks, > Paul > > > There are similar situations that can be employed for whole-PBX failover > > when multiple Voice ISPs are used for high-availability purposes. > > > > We can debate whether these use cases are good to have in the world, but > > that won't change that they are currently in use; and I think it's clear > > that using Passport with them is an improvement over the status quo. > > > > /a > > > > > > > > _______________________________________________ > > 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 > --000000000000d80ae4057b0d2bc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Nov 19, 2018 at 1:24 PM Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 11/19/18 12:00 PM, Adam Roach wrote:
> On 11/17/18 5:17 PM, Eric Rescorla wrote:
>> S 4.
>>>=C2=A0 =C2=A0
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 Has a direct authenticated r= elationship with the initiator of the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 call and can identify the cu= stomer associated with the initiator.
>>>=C2=A0 =C2=A0
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 Has NOT established a verifi= ed association with the calling party
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 telephone number being used = for the call.
>> For those who aren't; voice experts, can you give an example o= f when
>> this would happen?
>
>
> There are some uncommon but valid cases in which Voice ISPs may allow = a
> calling party to specify a calling number that the Voice ISP can't=
> verify as being assigned to the calling user.
>
> Consider, for example, a service like Google Voice, which provides a <= br> > single number that forwards to multiple destinations. I may want to be=
> able to make calls from my Voice ISP (who has no association with
> Google) with my Google Voice number as the originating number. While m= y
> Voice ISP has authenticated me and knows who I am, it has no way to > validate that I have control of that number; so, if it is signing a > Shaken token with that number, it would have to mark it as Partial > Attestation.

I don't find this a sufficient justification to allow this behavior. Rather, in this case I think it should be necessary to involve the owner of the claimed number in the call path so that it can attest to the
number. IIUC that is what Google Voice does today.
I want to emphasize that I'm not arguing about this behavio= r (my DISCUSS was about
a specific technical point). I just wante= d to get an explanation. I would, however,
encourage the authors = to add an example to the spec.

-Ekr
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

> There are similar situations that can be employed for whole-PBX failov= er
> when multiple Voice ISPs are used for high-availability purposes.
>
> We can debate whether these use cases are good to have in the world, b= ut
> that won't change that they are currently in use; and I think it&#= 39;s clear
> that using Passport with them is an improvement over the status quo. >
> /a
>
>
>
> _______________________________________________
> 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
--000000000000d80ae4057b0d2bc8-- From nobody Tue Nov 20 00:02:08 2018 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 A76D6128B14; Tue, 20 Nov 2018 00:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 ztzv8J8eqpYX; Tue, 20 Nov 2018 00:01:53 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.2]) (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 6526E124408; Tue, 20 Nov 2018 00:01:52 -0800 (PST) Received: from [85.158.142.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.eu-central-1.aws.symcld.net id E2/84-14999-E6FB3FB5; Tue, 20 Nov 2018 08:01:50 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VTbUwTZxzv07teD+TM0ar8RXFZE76IPUGSeX6 ZZGYTl5ktcTGZzOghZ1ttr9grgiabEKJRRFJHmhXWADpWB8RpFuzcUFT8oGJRXgQHbr5Agy8o uFLfnfGuT/Hly5Pf/X8v/1+ePEcThip9Ki2WuEWXJNhNVCK5cIV9r9lxajIvc9iTxp/4/6Cev /jCQ/LBwFWK/3Xskp73vdxP8AP+MoofPX5Exx86HNTm0LmNjc+0ubV/hsnc6pFdRG5pZZT6il yjs0n5zpL1OutI+AVVeDWKSo61XCFKUfsgqkCJtIH9A8FQ1UsSf5xFUP5fmb4CJWCm69UHmOh BEPirM67yaCEU7Yv7byCI9B4lVAvFfgL1bb9pVTyD3QR9we5YFMFOKqKGr1VsZCXY6R3VYY0T zv3UHcefQX/FQyWHpkk2HToGjOqYYb+F5zt/oPCuKIKJax5SJRJYHk6FxmN7EZsG0bIWAu9Kg aFwfawDsCw0nrhMYDwT7o680qlBDBsmYXLwsR6b10JreROFRR/CrciPcUMa9NbvRRgPUHDW+y XGZnjo9cY1K2Eo8jgWCmw3Au/diA4T8yF041gcb4YzNYF4o3nQvO8WiQ3/ENB7pUnnQQtr32m OsQT9VY/0tbErSIYLNWESzxdAQ1uEwjgDAgfGiCkcOj2ifXfegPTNaHG+y2axuh2CzW7Oysw0 Z2VlmzPNH3HCdrPAiUXmDaLkdgkKxwnFMidvc2ywF3CS6P4dKS+xYIuGOo6elVs60Gxaa5rJ5 AQm8wzT850F26yCbF3nKrKLcgeaS9MmYPrbFS7ZJVrEko02u/Kcp2igk0wzGOGkQjNyoeCQbR ZMdaKldLNvt4+gh2PneOwMhvb4CAMpOSUxNYWpUVNZ1WYtkt6ETv0mvSgt1cggjUZjSCoUXQ6 b+33+HkqhkcnIDKopSTbJ/Wb3PaWWVql1u39CreUW3lKppejz5z3jTkfXQPvT9PQHCX9/vOm7 OX1jydXnBK592aqUZq5yxb6ua98vmn5Rzh76pi7jF+LJo+Dg/bzbl9YzDVuEak2tcVnNdXfxe a4lcVrL+OrLkUVtwvC6JXXne/z+raP+zZ8SX5CzJiz8juU3D/or66K+n+9kRzqPNnFtOSz6t7 jVRMpWIWs+4ZKF11rTjqshBAAA X-Env-Sender: paul.rosbotham@vodafone.com X-Msg-Ref: server-4.tower-228.messagelabs.com!1542700907!2312020!4 X-Originating-IP: [47.73.108.139] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10654 invoked from network); 20 Nov 2018 08:01:49 -0000 Received: from vgdpm13vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.139) by server-4.tower-228.messagelabs.com with AES256-SHA256 encrypted SMTP; 20 Nov 2018 08:01:49 -0000 Received: from VOEXH11W.internal.vodafone.com (47.73.211.215) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Nov 2018 09:01:37 +0100 Received: from voxe05hw.internal.vodafone.com (195.232.244.50) by VOEXH11W.internal.vodafone.com (47.73.211.209) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Nov 2018 09:01:36 +0100 Received: from VOEXH08W.internal.vodafone.com (47.73.211.206) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Nov 2018 09:01:34 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (172.17.213.39) by VOEXH08W.internal.vodafone.com (47.73.211.212) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Nov 2018 09:01:32 +0100 Received: from VI1PR05MB5664.eurprd05.prod.outlook.com (20.178.120.214) by VI1PR05MB5216.eurprd05.prod.outlook.com (20.178.12.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.28; Tue, 20 Nov 2018 08:01:28 +0000 Received: from VI1PR05MB5664.eurprd05.prod.outlook.com ([fe80::c4f9:3c3d:edee:bb20]) by VI1PR05MB5664.eurprd05.prod.outlook.com ([fe80::c4f9:3c3d:edee:bb20%3]) with mapi id 15.20.1339.026; Tue, 20 Nov 2018 08:01:28 +0000 From: "Rosbotham, Paul, Vodafone UK" To: David Frankel , 'Eric Rescorla' , "'Adam Roach'" CC: 'IESG' , 'IETF STIR Mail List' , "stir-chairs@ietf.org" , "draft-ietf-stir-passport-shaken@ietf.org" , 'Robert Sparks' Thread-Topic: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) Thread-Index: AQHUfsu2MS+pP+U1gkSLY4w4tNXz7aVXVT4AgAAQiACAAAiNAIAA3cXA Date: Tue, 20 Nov 2018 08:01:28 +0000 Message-ID: References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> <58cb9f5a-bbe8-147f-5dfc-8abed5ba0c52@nostrum.com> <03e101d48036$001c9710$0055c530$@zipdx.com> In-Reply-To: <03e101d48036$001c9710$0055c530$@zipdx.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Enabled=True; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SiteId=68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Owner=paul.rosbotham@vodafone.com; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SetDate=2018-11-20T08:01:24.0157393Z; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Name=C2 General; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Application=Microsoft Azure Information Protection; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Extended_MSFT_Method=Automatic; Sensitivity=C2 General x-originating-ip: [47.73.248.191] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR05MB5216; 6:aqsTES1us6LH+lRFK4tFomxd3a6qFzOElOfNs2NfE5amHLUskjSefwXTl1ld6s6b8sVVCnEeS6ZTsXb5GvbGld43PcOk8qepN+XVHsIhzbBc2S0EdPbwfhiqlXOgBo92aG86KAv+E9nhoDLr3zLlLaTUmkP9s8mb2i3BZT80+EEWU89uLlbxCu2/N0zujSXoBeSSiyKcVBtO2tYLkIbTTBqQdNdQNEIph0S2F2EIb7+jGp7ha1ARVCxQQUeyCX6WI5cOyMZArDWqMISAPEMiI3PEcTvl5he6IztikjX2TZnGNK/g8gHy3tXl72WXk2ajT++lmEiK+JI3gXVc18rXZ7TKNGRhpRAqeezMn3Ou+xUV6cd3DxdkUySl4woA27kcl2VwlfvvNmFuSAFUiuelCgTZqm+D2+8WV5yxLXqbYohXkvd0S9yQ5vj9le887eSCxLiSODEbdtdhN+IPnL7MXA==; 5:NZsNvilG43kTKpw2CEJa0Ry+oMPUi3o0ew3j6eMX8mOvCguRelxHnbP9HnL+kmOIfqW3np8PMR01JffdKyKZCyZUAEM1t34x1DwskoiLrYDln89NlYatIPPEvvqNyox2Y8Sc6wUmUDryktXDAGRRHxlPX6nMbDr3e+I9XgZ29Ew=; 7:mqSLPdbJih1WGlkOhlEK5fqsIevoaPFoWq2749CBTz0pbKb82mHONOGjRqFSNC3a/tKLhrAqc0YiMuFAsDp48qcrmoU7ehCm1Aex+U49pwasX8Nk9Wxa+VaXJq+1TYElPEKUG0wv17yNGwKz59q+Fg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: cfa97dfc-58c7-41d6-d89f-08d64ebe605c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR05MB5216; x-ms-traffictypediagnostic: VI1PR05MB5216: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231442)(11241501184)(806099)(944501410)(52105112)(148016)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR05MB5216; BCL:0; PCL:0; RULEID:; SRVR:VI1PR05MB5216; x-forefront-prvs: 08626BE3A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(376002)(136003)(366004)(209900001)(199004)(189003)(14444005)(54906003)(93886005)(966005)(110136005)(8676002)(316002)(256004)(66066001)(106356001)(55016002)(2906002)(9686003)(236005)(478600001)(733005)(86362001)(6436002)(71200400001)(68736007)(54896002)(81156014)(105586002)(6306002)(606006)(71190400001)(81166006)(25786009)(4326008)(14454004)(53546011)(6506007)(3846002)(6116002)(790700001)(229853002)(5660300001)(53936002)(74316002)(7736002)(33656002)(486006)(7696005)(102836004)(6246003)(76176011)(11346002)(446003)(186003)(26005)(8936002)(99286004)(97736004)(476003)(2900100001)(6606295002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB5216; H:VI1PR05MB5664.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: vodafone.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: GHldaXqdZniHoEq+Fb+O9bAhVJ2ZRVbnRGpaBEtDhVqGrbGX7vGHTfA6p5GDWlt3G5S0WiacRQQVU6Du8dpciaz37T6SZHeRvl2lW/zf3d/oOAuO6c0KVFxIacBwNmGILXEEh6gMltsn1KX6+GTwZXxtnzwDIq7eIiL9qSegPxiFJ4ZxFqi8RlAJOJEQkPhHUISis6xzNC9hhr7/0SNqoJHUvs2HCZOqN7cZgAaUidplyYCWzszy0mXMoLGRAb55hJuDkJeXi1zIBpaK+ftc6Ii/wrIQ5oZ4McutDY+X4OM4D9Q8FAOW106Qa5QxlcdWm/mOvu9DoPV/S3Cqmcscj8oF1F4yjLChQ+ua9raN9yI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM x-ms-exchange-crosstenant-network-message-id: cfa97dfc-58c7-41d6-d89f-08d64ebe605c x-ms-exchange-crosstenant-originalarrivaltime: 20 Nov 2018 08:01:28.5463 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893 x-ms-exchange-transport-crosstenantheadersstamped: VI1PR05MB5216 Content-Type: multipart/alternative; boundary="_000_VI1PR05MB5664FD789A9A55140019D71FFED90VI1PR05MB5664eurp_" MIME-Version: 1.0 X-OriginatorOrg: vodafone.com Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 20 Nov 2018 08:01:58 -0000 --_000_VI1PR05MB5664FD789A9A55140019D71FFED90VI1PR05MB5664eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To be clear (for the UK at least), the SS7 concept "unscreened" doesn't mea= n that the originating network doesn't have a clue about the validity of th= e CLI, it means it's not been checked on a per-call basis by the network -= we have a legal requirement to have a contractual agreement with our origi= nating customers in this scenario that any CLIs they send into the network = will be valid. So "not screened by the network" would be better terminolog= y. At this stage - and we're behind SHAKEN on implementation timelines - in th= e UK we are planning to make use of partial attestation for the unscreened = scenario. As David says, we have a Network Number that's injected by the o= riginating network and represents where the call came into the network (the= number displayed to the called party may be the same thing in the case of = residential or mobile, but for the originating enterprise case will instead= be the number the enterprise customer provided). Our current plan is that it's the Network Number that we'll sign, but wheth= er that's full or partial will depend on whether the *display* (in our term= s Presentation Number) has been statically built in the network or provided= by an enterprise customer. Practicably we have to do it that way, because= we can't link the Presentation Number back to a single originating network= to create a certificate hierarchy, only the Network Number...the same CLI = can be used as a Presentation Number from multiple originating networks, be= cause enterprises & call-centres typically send their calls out via multipl= e providers (or at least the alternative is signing by the enterprise custo= mer, which would be complex). At the terminating end, there is the issue of whether to trust partial atte= station. However, as the terminating network will know who signed with par= tial attestation, they can take a view. Originating operator they trust, p= artial would get the green light. Originating network they know has been d= oing inadequate due diligence and sending spam calls...draw your own conclu= sions. Regards [Vodafone] Paul Rosbotham Senior Regulatory Manager Regulatory Policy Vodafone HQ, The Connection, Newbury, Berkshire, RG14 2FN Registered in England No 1471587 07957805573 paul.rosbotham@vodafone.com vodafone.co.uk The future is exciting. Ready? C2 General From: stir On Behalf Of David Frankel Sent: 19 November 2018 18:31 To: 'Eric Rescorla' ; 'Adam Roach' Cc: 'IESG' ; 'IETF STIR Mail List' ; stir-cha= irs@ietf.org; draft-ietf-stir-passport-shaken@ietf.org; 'Robert Sparks' Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-sha= ken-05: (with DISCUSS and COMMENT) Eric, I agree with (what I think) you are saying - it is difficult to know how a = call recipient or their agent should treat Partial Attestation. As Adam explained, this means that the originating provider "knows the cust= omer" but can't "vouch for the specific telephone number." This is problematic because what it means to "know the customer" may be qui= te different depending on who the provider is. To one provider, it may mean= "I have a long-term established and trusted business relationship with the= originating customer, and I have explicitly permitted them to use third-pa= rty numbers." Another provider may say, "I know this customer's IP address,= and not much else, and my policy is to pass onward whatever telephone numb= er is delivered to me." Perhaps that second category of provider will earn a "bad reputation" acros= s the industry and that will result in differential treatment at the receiv= ing end. That presumes that there will be a provider reputation database (o= r multiple databases) that will no doubt engender its own set of controvers= ies. Even without STIR, providers have always had the opportunity to be discrimi= nating about the originating telephone numbers they allow their customers t= o use. In SS7/ISDN, there was the concept of "network provided" numbers (in= serted by the provider and known to belong to the calling party); "customer= -provided, network-screened" (number supplied by the customer, but checked = against a list of known-OK numbers for that customer maintained by the prov= ider), and "not screened" (provider basically says "I have no clue" when it= comes to the validity of the calling number). Today, there are some providers that are quite diligent about only allowing= their customers to use "network-screened" numbers; they have a variety of = approaches for validating those numbers (for example, by calling each numbe= r and making sure the customer answers). But obviously illegal robocallers = use providers that operate in the "I have no clue" regime. Ofcom, the UK regulator, recently published a paper describing proper provi= der treatment of what they call Presentation Number (our Caller-ID or FROM = number), and the Network Number (what used to be our Charge Number or Billi= ng Telephone Number or P-Charge-Info). In the Ofcom model, the Network Numb= er is always supplied by the provider and is always a telephone number that= is serviced by that provider and is known to be assigned to the originatin= g caller. The Ofcom Guide, which I think is excellent, can be downloaded from here: https://www.ofcom.org.uk/phones-telecoms-and-internet/information-for-indus= try/telecoms-industry-guidance/calling-line-identification What would be great in the STIR context you are discussing is if the provid= er, when signing the call, could insert something equivalent to the UK "net= work number" so that the receiving end of the call could have more certaint= y about the origin of the call. This would greatly limit the prevalence of = "anonymous" calls flooding our network, and would reduce the necessity of a= provider reputation database. There would still be mechanisms for making c= alls anonymously, but the recipient could then make an explicit choice to r= eject such calls. David David Frankel ZipDX(r) LLC Monte Sereno, CA USA Tel: 1-800-FRANKEL (1-800-372-6535) Watch Our Video! From: stir > On Behalf = Of Eric Rescorla Sent: Monday, November 19, 2018 10:00 AM To: Adam Roach > Cc: IETF STIR Mail List >; Robert Spark= s >; draft-ietf-stir-pass= port-shaken@ietf.org; IESG= >; stir-chairs@ietf.org Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-sha= ken-05: (with DISCUSS and COMMENT) On Mon, Nov 19, 2018 at 9:00 AM Adam Roach > wrote: On 11/17/18 5:17 PM, Eric Rescorla wrote: S 4. o Has a direct authenticated relationship with the initiator of the call and can identify the customer associated with the initiator. o Has NOT established a verified association with the calling party telephone number being used for the call. For those who aren't; voice experts, can you give an example of when this would happen? There are some uncommon but valid cases in which Voice ISPs may allow a cal= ling party to specify a calling number that the Voice ISP can't verify as b= eing assigned to the calling user. Consider, for example, a service like Google Voice, which provides a single= number that forwards to multiple destinations. I may want to be able to ma= ke calls from my Voice ISP (who has no association with Google) with my Goo= gle Voice number as the originating number. While my Voice ISP has authenti= cated me and knows who I am, it has no way to validate that I have control = of that number; so, if it is signing a Shaken token with that number, it wo= uld have to mark it as Partial Attestation. OK. There are similar situations that can be employed for whole-PBX failover wh= en multiple Voice ISPs are used for high-availability purposes. We can debate whether these use cases are good to have in the world, but th= at won't change that they are currently in use; and I think it's clear that= using Passport with them is an improvement over the status quo. I'm not arguing against it, I'm just trying to get clarity on what these le= vels mean. -Ekr --_000_VI1PR05MB5664FD789A9A55140019D71FFED90VI1PR05MB5664eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To be clear (for the UK at least), the SS7 concept “unscreened&#= 8221; doesn’t mean that the originating network doesn’t have a = clue about the validity of the CLI, it means it’s not been checked on a per-call basis by the network  - we have a legal requirement to = have a contractual agreement with our originating customers in this scenari= o that any CLIs they send into the network will be valid.  So “n= ot screened by the network” would be better terminology.

 

At this stage – and we’re behind SHAKEN on implementation = timelines – in the UK we are planning to make use of partial attestat= ion for the unscreened scenario.  As David says, we have a Network Number that’s injected by the originating network and repr= esents where the call came into the network (the number displayed to the ca= lled party may be the same thing in the case of residential or mobile, but = for the originating enterprise case will instead be the number the enterprise customer provided).  =

 

Our current plan is that it’s the Network Number that we’l= l sign, but whether that’s full or partial will depend on whether the= *display* (in our terms Presentation Number) has been statically built in the network or provided by an enterprise customer= .  Practicably we have to do it that way, because we can’t link = the Presentation Number back to a single originating network to create a ce= rtificate hierarchy, only the Network Number…the same CLI can be used as a Presentation Number from multiple originating ne= tworks, because enterprises & call-centres typically send their calls o= ut via multiple providers (or at least the alternative is signing by the en= terprise customer, which would be complex).

 

At the terminating end, there is the issue of whether to trust partial= attestation.  However, as the terminating network will know who signe= d with partial attestation, they can take a view.  Originating operator they trust, partial would get the green= light.  Originating network they know has been doing inadequate due d= iligence and sending spam calls…draw your own conclusions.=

 

Regards

 

3D"Vodafone"

Paul Ro= sbotham
Senior Regulatory Manager
Regulatory Policy


Vodafone HQ, The Connection, Newbury, Berkshire, RG14 2FN=

Registered i= n England No 1471587

 <= /o:p>

07957805573<= o:p>


paul.= rosbotham@vodafone.com
vodafone.c= o.uk


The future is exciting.
Ready?

 

 

 

= C2 General

From: stir <stir-bounces@ietf.org> On Behalf Of David Frankel
Sent: 19 November 2018 18:31
To: 'Eric Rescorla' <ekr@rtfm.com>; 'Adam Roach' <adam@nost= rum.com>
Cc: 'IESG' <iesg@ietf.org>; 'IETF STIR Mail List' <stir@iet= f.org>; stir-chairs@ietf.org; draft-ietf-stir-passport-shaken@ietf.org; = 'Robert Sparks' <rjsparks@nostrum.com>
Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passp= ort-shaken-05: (with DISCUSS and COMMENT)

 

Eric,

 

I agree with (what I think) you= are saying – it is difficult to know how a call recipient or their a= gent should treat Partial Attestation.

 

As Adam explained, this means t= hat the originating provider “knows the customer” but can’= ;t “vouch for the specific telephone number.”=

 

This is problematic because wha= t it means to “know the customer” may be quite different depend= ing on who the provider is. To one provider, it may mean “I have a lo= ng-term established and trusted business relationship with the originating customer, and I have explicitly permitted them to use= third-party numbers.” Another provider may say, “I know this c= ustomer’s IP address, and not much else, and my policy is to pass onw= ard whatever telephone number is delivered to me.”<= /p>

 

Perhaps that second category of= provider will earn a “bad reputation” across the industry and = that will result in differential treatment at the receiving end. That presu= mes that there will be a provider reputation database (or multiple databases) that will no doubt engender its own set of controv= ersies.

 

Even without STIR, providers ha= ve always had the opportunity to be discriminating about the originating te= lephone numbers they allow their customers to use. In SS7/ISDN, there was t= he concept of “network provided” numbers (inserted by the provider and known to belong to the calling party); ̶= 0;customer-provided, network-screened” (number supplied by the custom= er, but checked against a list of known-OK numbers for that customer mainta= ined by the provider), and “not screened” (provider basically says “I have no clue” when it comes to the validity = of the calling number).

 

Today, there are some providers= that are quite diligent about only allowing their customers to use “= network-screened” numbers; they have a variety of approaches for vali= dating those numbers (for example, by calling each number and making sure the customer answers). But obviously illegal roboca= llers use providers that operate in the “I have no clue” regime= .

 

Ofcom, the UK regulator, recent= ly published a paper describing proper provider treatment of what they call= Presentation Number (our Caller-ID or FROM number), and the Network Number= (what used to be our Charge Number or Billing Telephone Number or P-Charge-Info). In the Ofcom model, the Net= work Number is always supplied by the provider and is always a telephone nu= mber that is serviced by that provider and is known to be assigned to the o= riginating caller.

 

The Ofcom Guide, which I think = is excellent, can be downloaded from here:

https://www.ofcom.org.uk/phones-tel= ecoms-and-internet/information-for-industry/telecoms-industry-guidance/call= ing-line-identification

 

What would be great in the STIR= context you are discussing is if the provider, when signing the call, coul= d insert something equivalent to the UK “network number” so tha= t the receiving end of the call could have more certainty about the origin of the call. This would greatly limit the preva= lence of “anonymous” calls flooding our network, and would redu= ce the necessity of a provider reputation database. There would still be me= chanisms for making calls anonymously, but the recipient could then make an explicit choice to reject such calls.


David

 

David Frankel

Zip= DX® LLC<= /o:p>

Monte Sereno, CA USA

Tel: 1-800-FRANKEL (1-800-372-6535)

Watch Our Video!

 

From: stir <stir-bounces@= ietf.org> On Behalf Of Eric Rescorla
Sent: Monday, November 19, 2018 10:00 AM
To: Adam Roach <adam@nostrum.= com>
Cc: IETF STIR Mail List <stir@ie= tf.org>; Robert Sparks <r= jsparks@nostrum.com>; draft-ietf-stir= -passport-shaken@ietf.org; IESG <ie= sg@ietf.org>; stir-chairs@ietf.org
Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passp= ort-shaken-05: (with DISCUSS and COMMENT)

 

=  

On Mon, Nov 19, 2018 at 9:00 AM= Adam Roach <adam@nostrum.com>= ; wrote:

On 11/17/18 5:17 PM, Eric Resco= rla wrote:

S 4.
  

    &nb=
sp;o  Has a direct authenticated relationship with the initiator of th=
e


    &nb=
sp;   call and can identify the customer associated with the init=
iator.


  

    &nb=
sp;o  Has NOT established a verified association with the calling part=
y


    &nb=
sp;   telephone number being used for the call.=



For those who aren't; voice experts, can you give=
 an example of when
this would happen?

 

There are some uncommon but valid cases in which Vo= ice ISPs may allow a calling party to specify a calling number that the Voi= ce ISP can't verify as being assigned to the calling user.

Consider, for example, a service like Google Voice,= which provides a single number that forwards to multiple destinations. I m= ay want to be able to make calls from my Voice ISP (who has no association = with Google) with my Google Voice number as the originating number. While my Voice ISP has authenticated me = and knows who I am, it has no way to validate that I have control of that n= umber; so, if it is signing a Shaken token with that number, it would have = to mark it as Partial Attestation.

OK.

 

There are similar situations that can be employed f= or whole-PBX failover when multiple Voice ISPs are used for high-availabili= ty purposes.

We can debate whether these use cases are good to h= ave in the world, but that won't change that they are currently in use; and= I think it's clear that using Passport with them is an improvement over th= e status quo.

 

I'm not arguing against it, I'm= just trying to get clarity on what these levels mean.

 

-Ekr

--_000_VI1PR05MB5664FD789A9A55140019D71FFED90VI1PR05MB5664eurp_-- From nobody Tue Nov 20 09:06:12 2018 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 A0E23130DCD for ; Tue, 20 Nov 2018 09:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 aiAXjDnGDFj2 for ; Tue, 20 Nov 2018 09:06:02 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 E923E130DD8 for ; Tue, 20 Nov 2018 09:05:59 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id e5so780918qtr.12 for ; Tue, 20 Nov 2018 09:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=suxOnPvGs2KxJk8jrMLswZqfPO3APC97pcvkryO1Lgs=; b=G2NiMX7+NDa3QZVfXbKN0zoYJ2nyPI6vxyFYTVERsckl7CG1wpz3hrS5nLRs2oM0+Y faKClHZkyDNsEiAr3oR0+KDylP139i3rAnKXTepTluUw4MYqmcW4rBcHj6KflURTgbN1 qFy0rR7dsfRn9NrQEtfSqKc9eutpWtBghLyPljc7mvGcliGhKj+fliGnHnC731ZSUIPc syOa1OdugZYP2nib9+dqgRKi/ZkrOf1oUz9BqWEGm5eXbvEUdpNr3H/iReoWclTVAHE/ 4N0YVN+bJq2J0dDS6u9nxiJW+0tzGGLBr1sCWXWH8UqF6adZH7s0tDw487u2Q6d3da3M s7Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=suxOnPvGs2KxJk8jrMLswZqfPO3APC97pcvkryO1Lgs=; b=KpZa0d9sU/nSTyNQv74tksIXIt41AnH+hupwCGANAavW93vBnnZCK9Cy5IFTvg/Fkc a4afrQUbeDHObjaTybA6PqHYL4MpwbQme3hvGUfLBCyGyGT1NYLEIPBAwoP177X+G7Ki TFiMFRm50FiCp4LgNZSoC4suVcEdCAd5ZOBU7fRM2WEQtobDo+O1ieSb38JMd85XC7Xi 27iYMV5Wb/KFfPUgIfLG74Q/Vt0vnJy2bZvejCiValbKJ9ehcB/ryhD7+kw1k6w1Xesz oE0VktgC6hY3+Uu9cqURi+W7QUsvL8zmvnPwUOT+sGACCl5WC3zN9Qc2ieDKHhVYr5fB NZqw== X-Gm-Message-State: AGRZ1gKp0lzWtDBYn4fAAM9YG+byvW6zS2P1why9d3sCsexYWd+w0p1m o4oBFmeHf6sK78zELMjt7wcBng== X-Google-Smtp-Source: AJdET5cqiVsdUoa9qxndEKAbM9nDuzRWNLZa6l9ET7XeUdHctpp4QnaWH2tH8sNoQtCDyeJSJV+46g== X-Received: by 2002:ac8:3879:: with SMTP id r54mr2531275qtb.69.1542733558943; Tue, 20 Nov 2018 09:05:58 -0800 (PST) Received: from [10.37.20.14] (209.222.19.251.adsl.inet-telecom.org. [209.222.19.251]) by smtp.gmail.com with ESMTPSA id c11sm11894124qtn.95.2018.11.20.09.05.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 09:05:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: <154259095538.2354.17623821529843764623.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 12:05:55 -0500 Cc: The IESG , draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks , STIR Chairs , stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4E6DAD8F-6104-4215-9EE8-3894A99CD81D@chriswendt.net> References: <154259095538.2354.17623821529843764623.idtracker@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 20 Nov 2018 17:06:05 -0000 Hi Ben, All,=20 Originally in the document, i believe i did have most of this = information defined as a reference to the original SHAKEN document. I = got working group comments that believed the definitions should be = directly in the document themselves versus by reference. I worry about trying to re-write things too much with the potential of = causing confusion between the SHAKEN and STIR specs. I guess i would need higher level guidance on how to proceed with this = if there is a concern about this. While I can check with ATIS folks and = maybe initiate some "written permission=E2=80=9D not sure if that is the = best path here or if i really have the legal standing to do that myself = in either case. -Chris > On Nov 18, 2018, at 8:29 PM, Benjamin Kaduk wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-stir-passport-shaken-05: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > A nontrivial amount of text in this document appears to have been = taken from > = https://access.atis.org/apps/group_public/download.php/32237/ATIS-1000074.= pdf > which notes that "No part of this publication may be reproduced in any > form, in an electronic retrieval system or otherwise, without the = prior > written permission of the publisher." Do we have prior written = permission > to duplicate such text? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I am interested in seeing the resolution of discussion on Ekr's = Discuss, but > will stick to that thread for such discussion. >=20 > Section 4 >=20 > Am I reading this properly that the difference between 'A' and 'B' is = that > in 'B' we don't have any information about the device that's = originating > the call, just the identity of the user/customer? >=20 >=20 From nobody Tue Nov 20 09:19:30 2018 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 339AD12896A for ; Tue, 20 Nov 2018 09:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 i6O4xSutrWdl for ; Tue, 20 Nov 2018 09:19:27 -0800 (PST) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 5407A12007C for ; Tue, 20 Nov 2018 09:19:27 -0800 (PST) Received: by mail-qt1-x842.google.com with SMTP id y20so832261qtm.13 for ; Tue, 20 Nov 2018 09:19:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vwxbPTQr4htfqiVs1Gezdu4bPyBttZwT6Ub7SFxbvVY=; b=ZMZdjtNYYD7yuCFoAXTd15Gwqiw5ZKyZZJHe1h/PpSBYpZ+LLzdTdrAJrGCqrnakP4 or296ENLM9Bo1twfL5GkQxeM7vS/CDqXsV/WxqV3Y6jywZG0yMVdseyHHD6eHHhPpm3G 2K7S0TPdPr83REdaExPdkDQaZ/lSVCUizA9aajP/9Ot2iDDBvt7vk1fSODbrozqWm4lH MHUW1EdFFiC2p1v7yF4Lt1y8Ar3Hlfvx3sgYPWbSiE1CS9MufWTQP54YZbjdtqbOAFoA Btr2yIPE8ucl7q6shYNqxQvykoDS/3QsU8vANoMh4mfDieRdOHyvRYtbcobbcYOyiYyY e20Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vwxbPTQr4htfqiVs1Gezdu4bPyBttZwT6Ub7SFxbvVY=; b=unA657R4DjMT7gABnZJduLliwz9guoTkPgCYb2Mqq6m1gjp4CTvS3xxP9eHk0vEeGq 1JGfPrAuUa52ABODfxbX0IwUEWRlAsBrcQ+31oRvBQiyNZ08Lcg60VqZCNhtQntCMh76 8kWyKj0IEKj06MprAluw5yzO30ooH/1QEJx44Qi7G1Oz7cglL5C9vPMeeI6RYWbelLm/ fdj/q7bU4KcsXaCry0JRjAtsAW2g78/jW7TSI6SH6A0BI34yjB308CfjqMBTlWP4sys9 PWlWJiEu5szIL1gMrx1Ufd7B54So6Px8f+Y6h72kX4jmN5gGByxP1jBo2fmZaz60/KBR 1V4Q== X-Gm-Message-State: AA+aEWbSQoQX088Rck4mlUxZOYcctmkg6jww+F5zxSrMbYvtecjadM+L OtAdzy0/n9KplA02LOjatkOpNQ== X-Google-Smtp-Source: AFSGD/Xxe1Rfq+MlOtiXUzTJ441yxMBGh6Ohwkiqe7dwWwTgqXcZKVIhNKsf2fuUezqHS+8OmFUGUg== X-Received: by 2002:a0c:a242:: with SMTP id f60mr2723105qva.17.1542734366299; Tue, 20 Nov 2018 09:19:26 -0800 (PST) Received: from [10.37.20.14] (209.222.19.251.adsl.inet-telecom.org. [209.222.19.251]) by smtp.gmail.com with ESMTPSA id l33sm17042763qta.57.2018.11.20.09.19.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 09:19:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 12:19:23 -0500 Cc: The IESG , stir@ietf.org, rjsparks@nostrum.com, draft-ietf-stir-passport-shaken@ietf.org, stir-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <022A3421-AFF6-4E0F-AEC2-24902B3D12EB@chriswendt.net> References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 20 Nov 2018 17:19:29 -0000 Hi Eric, Answers inline. > On Nov 17, 2018, at 6:17 PM, Eric Rescorla wrote: >=20 > Eric Rescorla has entered the following ballot position for > draft-ietf-stir-passport-shaken-05: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D5207 >=20 >=20 > I would like to discuss the privacy properties of origids. As I read > this text, it does not actually require them to be unlinkable or that > it not be possible to determine whether two ids represent the same > person behind the origid generator, and I believe it should do so. > Practically implementing that may require an ID that is longer than a > UUID. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 >>=20 >> This document extends PASSporT, which is a token object that = conveys >> cryptographically-signed information about the participants = involved >> in communications. The extension is defined, corresponding to = the >> SHAKEN specification, to provide both a specific set of = levels-of- >> confidence to the correctness of the originating identity for a = SIP >=20 > Nit: confidence of or confidence in fixed >=20 >=20 >=20 >> in communications. The extension is defined, corresponding to = the >> SHAKEN specification, to provide both a specific set of = levels-of- >> confidence to the correctness of the originating identity for a = SIP >> based Communication Service Provider (CSP) telephone network >> originated call as well as an identifier that allows the CSP to >> uniquely identify the origination of the call within its network. >=20 > Nit: originator I believe this should be origination, because it=E2=80=99s not = identifying the =E2=80=9Cuser=E2=80=9D or =E2=80=9Caccount=E2=80=9D = it=E2=80=99s identifying either a network element or some network region = or whatever the CSP needs to use to identify where the call came from, = rather than =E2=80=9Cwho=E2=80=9D the call came from. This is for = traceback purposes and to avoid the issue of having unique identifiers = that are specifically associated with users or accounts. >=20 >=20 > S 1. >> need to be accounted for where PASSporT signatures may represent >> either direct or indirect call origination scenarios. The SHAKEN >> [ATIS-1000074] specification defines levels of attestation of the >> origination of the call as well as an origination identifier that = can >> help create a unique association with the origination of calls = from >> various parts of the VoIP or TDM telephone network. This = document >=20 > I can't read this. What is the association between? Similar to above, the concept is that a CSP maps a unique identifier to = a network element or part of a CSP network that would facilitate the = ability to trace the origination of the call. It is defined to be = intentionally abstract to allow for various ways CSP manage their = networks and for example trunk associations to various network elements. >=20 >=20 > S 2. >> capitals, as shown here. >>=20 >> In addition, the following terms are used in this document: >>=20 >> o Verified association: is typically defined as an authenticated >> relationship with a device that initiated a call, for example, = a >=20 > relationship between the call and the device? No, the point is that to provide this level of attestation, you need to = have a =E2=80=9Cverified=E2=80=9D authentication of the device/user into = your network. Typical example is a cell phone has SIM authentication, = or a SIP digest authentication. A scenario where you don=E2=80=99t have = an authenticated relationship is if you are a wholesale provider or = transit provider or other scenarios where you are receiving an unsigned = call. >=20 >=20 > S 4. >>=20 >> o Has a direct authenticated relationship with the initiator of = the >> call and can identify the customer associated with the = initiator. >>=20 >> o Has NOT established a verified association with the calling = party >> telephone number being used for the call. >=20 > For those who aren't; voice experts, can you give an example of when > this would happen? See above answer, i can see if i can integrate that explanation in the = text, if you think that covers it. >=20 >=20 > S 10. >> integrity protection and non-repudiation properties as the base >> claims in the PASSporT. >>=20 >> 10. Privacy Considerations >>=20 >> As detailed in [RFC3261] Section 26, SIP messages inherently = carry >=20 > Thanks for including this section. >=20 >=20 From nobody Tue Nov 20 11:03:43 2018 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 D50CC130DC6 for ; Tue, 20 Nov 2018 11:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 tcDcMeRtzU_o for ; Tue, 20 Nov 2018 11:03:30 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 AAEE0130DCD for ; Tue, 20 Nov 2018 11:03:29 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id v15-v6so2579084ljh.13 for ; Tue, 20 Nov 2018 11:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HhGF7ETuZ6nmEJWHT+TRzbvtIlbqmpnoOfrgCTbz90k=; b=T7CACsacpxGLDP5zO7fKvlqnjpRAukjVLK8UMRFUeDzYblh+oDliLXY33Weg1JdOoB g3f+xaOQFucJjlVlcF1k2SdgPUoWFnKh84QCXvgTopYeziAeHgIm4k11Pj3nfalGl3n9 DxFjdBbLzN5t6XRb8aNUdiSFRSERmCH//IZxHqTOVWJ7htdJ4Dr3z+v/He9ktP5o/eW5 jwnF9VR3GCTOq7HOCxZzXDaJAt/3gMHOvPTpDlH5SHCsovf74LAkKYNo4rtWID3AX0dC Rs795TZM5Z+ezbcHEEiKGxCFIvkym4uIzNcCCFKNHvsfrUunlE9EzK3OfIxThdVrxiSj Qw4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HhGF7ETuZ6nmEJWHT+TRzbvtIlbqmpnoOfrgCTbz90k=; b=kFP8zc8mPpCTXT5/XoDlAY9TFytR40JuGFjvCP5vMTvaEk/8aAsLPJ9Jzyxjj0k8xL s3h/sYlNkvw9dI45cfoobCcj3mD+MVKWRMuSZe/2QZJl0HeLG0sAjO9LUZBbY8leQv/W rWPYc3gdrtgly8CzVc0ITc7SUKC5Xmx9gnwXTyO3U64ov1nUrp3t703dwOvpvlbNs0m4 wJQsi0gaM3w9MVbTXFleWFlJn6RzhDbNtYIMdDNTN+FR2OqkMcNlS6TjUyfXVg9yHpBc Tl6nJMWwCxmTQ++ZHnOgek1Z7Y9OfLvb1OYWrK7UCXQ3fONfmp6HGKhp346XmhaCx1eY NP4A== X-Gm-Message-State: AGRZ1gJL4Gc2eLP0UDtYt+eDfWy03YQiq5qCN90v4uQZZx8KS4+FnAEO LNET3GpqRjokfVuxuyLmSQKOGxqXaSHOHEjJSWihkQ== X-Google-Smtp-Source: AFSGD/U3nxYbQP3ua3V6GXsCTCBg2D8MAS274eEgWFfMcpdz1jy3YUFsSb6dhv7/TQdbnjnuzbGUiIAoIkPwcYqRR/w= X-Received: by 2002:a2e:1551:: with SMTP id 17-v6mr1939905ljv.68.1542740607781; Tue, 20 Nov 2018 11:03:27 -0800 (PST) MIME-Version: 1.0 References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> <022A3421-AFF6-4E0F-AEC2-24902B3D12EB@chriswendt.net> In-Reply-To: <022A3421-AFF6-4E0F-AEC2-24902B3D12EB@chriswendt.net> From: Eric Rescorla Date: Tue, 20 Nov 2018 11:02:50 -0800 Message-ID: To: Chris Wendt Cc: IESG , IETF STIR Mail List , Robert Sparks , draft-ietf-stir-passport-shaken@ietf.org, stir-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000e875b3057b1d4997" Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 20 Nov 2018 19:03:34 -0000 --000000000000e875b3057b1d4997 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 20, 2018 at 9:19 AM Chris Wendt wrote: > Hi Eric, > > Answers inline. > > > On Nov 17, 2018, at 6:17 PM, Eric Rescorla wrote: > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-stir-passport-shaken-05: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D5207 > > > > > > I would like to discuss the privacy properties of origids. As I read > > this text, it does not actually require them to be unlinkable or that > > it not be possible to determine whether two ids represent the same > > person behind the origid generator, and I believe it should do so. > > Practically implementing that may require an ID that is longer than a > > UUID. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > >> > >> This document extends PASSporT, which is a token object that conve= ys > >> cryptographically-signed information about the participants involv= ed > >> in communications. The extension is defined, corresponding to the > >> SHAKEN specification, to provide both a specific set of levels-of- > >> confidence to the correctness of the originating identity for a SI= P > > > > Nit: confidence of or confidence in > > fixed > > > > > > > > >> in communications. The extension is defined, corresponding to the > >> SHAKEN specification, to provide both a specific set of levels-of- > >> confidence to the correctness of the originating identity for a SI= P > >> based Communication Service Provider (CSP) telephone network > >> originated call as well as an identifier that allows the CSP to > >> uniquely identify the origination of the call within its network. > > > > Nit: originator > > I believe this should be origination, because it=E2=80=99s not identifyin= g the > =E2=80=9Cuser=E2=80=9D or =E2=80=9Caccount=E2=80=9D it=E2=80=99s identify= ing either a network element or some > network region or whatever the CSP needs to use to identify where the cal= l > came from, rather than =E2=80=9Cwho=E2=80=9D the call came from. This is= for traceback > purposes and to avoid the issue of having unique identifiers that are > specifically associated with users or accounts. > I understand, but origination if a funny term here. Perhaps "origin" > > > > > > > S 1. > >> need to be accounted for where PASSporT signatures may represent > >> either direct or indirect call origination scenarios. The SHAKEN > >> [ATIS-1000074] specification defines levels of attestation of the > >> origination of the call as well as an origination identifier that > can > >> help create a unique association with the origination of calls fro= m > >> various parts of the VoIP or TDM telephone network. This document > > > > I can't read this. What is the association between? > > Similar to above, the concept is that a CSP maps a unique identifier to a > network element or part of a CSP network that would facilitate the abilit= y > to trace the origination of the call. It is defined to be intentionally > abstract to allow for various ways CSP manage their networks and for > example trunk associations to various network elements. > Right, but associations are between things. What are the two things. > > > > > > > S 2. > >> capitals, as shown here. > >> > >> In addition, the following terms are used in this document: > >> > >> o Verified association: is typically defined as an authenticated > >> relationship with a device that initiated a call, for example, = a > > > > relationship between the call and the device? > > No, the point is that to provide this level of attestation, you need to > have a =E2=80=9Cverified=E2=80=9D authentication of the device/user into = your network. > Typical example is a cell phone has SIM authentication, or a SIP digest > authentication. A scenario where you don=E2=80=99t have an authenticated > relationship is if you are a wholesale provider or transit provider or > other scenarios where you are receiving an unsigned call. > Here too, relationships are between things. What are the two things. -Ekr > > > > > > S 4. > >> > >> o Has a direct authenticated relationship with the initiator of t= he > >> call and can identify the customer associated with the initiato= r. > >> > >> o Has NOT established a verified association with the calling par= ty > >> telephone number being used for the call. > > > > For those who aren't; voice experts, can you give an example of when > > this would happen? > > See above answer, i can see if i can integrate that explanation in the > text, if you think that covers it. > > > > > > > S 10. > >> integrity protection and non-repudiation properties as the base > >> claims in the PASSporT. > >> > >> 10. Privacy Considerations > >> > >> As detailed in [RFC3261] Section 26, SIP messages inherently carry > > > > Thanks for including this section. > > > > > > --000000000000e875b3057b1d4997 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Nov 20, 2018 at 9:19 AM Chris Wendt <chris-ietf@chriswendt.net> wrote:
Hi Eric,

Answers inline.

> On Nov 17, 2018, at 6:17 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-stir-passport-shaken-05: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/d= oc/draft-ietf-stir-passport-shaken/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D5207<= /a>
>
>
> I would like to discuss the privacy properties of origids. As I read > this text, it does not actually require them to be unlinkable or that<= br> > it not be possible to determine whether two ids represent the same
> person behind the origid generator, and I believe it should do so.
> Practically implementing that may require an ID that is longer than a<= br> > UUID.
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
>
>>
>>=C2=A0 =C2=A0 =C2=A0This document extends PASSporT, which is a toke= n object that conveys
>>=C2=A0 =C2=A0 =C2=A0cryptographically-signed information about the = participants involved
>>=C2=A0 =C2=A0 =C2=A0in communications.=C2=A0 The extension is defin= ed, corresponding to the
>>=C2=A0 =C2=A0 =C2=A0SHAKEN specification, to provide both a specifi= c set of levels-of-
>>=C2=A0 =C2=A0 =C2=A0confidence to the correctness of the originatin= g identity for a SIP
>
> Nit: confidence of or confidence in

fixed

>
>
>
>>=C2=A0 =C2=A0 =C2=A0in communications.=C2=A0 The extension is defin= ed, corresponding to the
>>=C2=A0 =C2=A0 =C2=A0SHAKEN specification, to provide both a specifi= c set of levels-of-
>>=C2=A0 =C2=A0 =C2=A0confidence to the correctness of the originatin= g identity for a SIP
>>=C2=A0 =C2=A0 =C2=A0based Communication Service Provider (CSP) tele= phone network
>>=C2=A0 =C2=A0 =C2=A0originated call as well as an identifier that a= llows the CSP to
>>=C2=A0 =C2=A0 =C2=A0uniquely identify the origination of the call w= ithin its network.
>
> Nit: originator

I believe this should be origination, because it=E2=80=99s not identifying = the =E2=80=9Cuser=E2=80=9D or =E2=80=9Caccount=E2=80=9D it=E2=80=99s identi= fying either a network element or some network region or whatever the CSP n= eeds to use to identify where the call came from, rather than =E2=80=9Cwho= =E2=80=9D the call came from.=C2=A0 This is for traceback purposes and to a= void the issue of having unique identifiers that are specifically associate= d with users or accounts.

I understand,= but origination if a funny term here. Perhaps "origin"

>
>
> S 1.
>>=C2=A0 =C2=A0 =C2=A0need to be accounted for where PASSporT signatu= res may represent
>>=C2=A0 =C2=A0 =C2=A0either direct or indirect call origination scen= arios.=C2=A0 The SHAKEN
>>=C2=A0 =C2=A0 =C2=A0[ATIS-1000074] specification defines levels of = attestation of the
>>=C2=A0 =C2=A0 =C2=A0origination of the call as well as an originati= on identifier that can
>>=C2=A0 =C2=A0 =C2=A0help create a unique association with the origi= nation of calls from
>>=C2=A0 =C2=A0 =C2=A0various parts of the VoIP or TDM telephone netw= ork.=C2=A0 This document
>
> I can't read this. What is the association between?

Similar to above, the concept is that a CSP maps a unique identifier to a n= etwork element or part of a CSP network that would facilitate the ability t= o trace the origination of the call.=C2=A0 It is defined to be intentionall= y abstract to allow for various ways CSP manage their networks and for exam= ple trunk associations to various network elements.
Right, but associations are between things. What are the two t= hings.

>
>
> S 2.
>>=C2=A0 =C2=A0 =C2=A0capitals, as shown here.
>>
>>=C2=A0 =C2=A0 =C2=A0In addition, the following terms are used in th= is document:
>>
>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 Verified association: is typically defi= ned as an authenticated
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 relationship with a device that initiat= ed a call, for example, a
>
> relationship between the call and the device?

No, the point is that to provide this level of attestation, you need to hav= e a =E2=80=9Cverified=E2=80=9D authentication of the device/user into your = network.=C2=A0 Typical example is a cell phone has SIM authentication, or a= SIP digest authentication.=C2=A0 A scenario where you don=E2=80=99t have a= n authenticated relationship is if you are a wholesale provider or transit = provider or other scenarios where you are receiving an unsigned call.

Here too, relationships are between things. = What are the two things.

-Ekr

=

>
>
> S 4.
>>
>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 Has a direct authenticated relationship= with the initiator of the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 call and can identify the customer asso= ciated with the initiator.
>>
>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 Has NOT established a verified associat= ion with the calling party
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 telephone number being used for the cal= l.
>
> For those who aren't; voice experts, can you give an example of wh= en
> this would happen?

See above answer, i can see if i can integrate that explanation in the text= , if you think that covers it.

>
>
> S 10.
>>=C2=A0 =C2=A0 =C2=A0integrity protection and non-repudiation proper= ties as the base
>>=C2=A0 =C2=A0 =C2=A0claims in the PASSporT.
>>
>>=C2=A0 10.=C2=A0 Privacy Considerations
>>
>>=C2=A0 =C2=A0 =C2=A0As detailed in [RFC3261] Section 26, SIP messag= es inherently carry
>
> Thanks for including this section.
>
>

--000000000000e875b3057b1d4997-- From nobody Tue Nov 20 13:24:10 2018 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 77281124D68; Tue, 20 Nov 2018 13:24:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks , stir-chairs@ietf.org, rjsparks@nostrum.com, stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154274904245.29950.16549065592917981460.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 13:24:02 -0800 Archived-At: Subject: [stir] Alissa Cooper's No Objection on draft-ietf-stir-passport-shaken-05: (with COMMENT) 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: Tue, 20 Nov 2018 21:24:02 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-stir-passport-shaken-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Eric's DISCUSS. In addition to points made by Benjamin in that thread, I think if this document is going to say that threats introduced by origids "already existed in SIP," it also needs to talk about expectations for usage of origids in cases were existing SIP features to support anonymous calling are in use. Presumably callers who enable such features may also not expect their calling patterns to be linkable. From nobody Tue Nov 20 13:25:50 2018 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 E9D7E124D68; Tue, 20 Nov 2018 13:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=tQ0Zre5L; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=disk8D21 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 RsdQAcxhVcDD; Tue, 20 Nov 2018 13:25:39 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E693130DCF; Tue, 20 Nov 2018 13:25:38 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 36D08221AD; Tue, 20 Nov 2018 16:25:37 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 20 Nov 2018 16:25:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=d q2W6fN5QcRY2OPpbosT/rUUHVNKL2+T52pGTS/J6kc=; b=tQ0Zre5LMrffXQ7/Y Hbt/Ce4lLTWa3pZLJ/QrVAh1IAIDqRNwAdauPzlBoWJMB/qnozYuXs8G0Vo+CdGz alumWDzwOKDOo/vcgr+X6xr1NaN4SvUXvFq298GBaXKXxM3ieAV6X7sNZcfwR41R j43inoLZ42m6lFjL97I3eetEAJ8v8268HcqAdsJPKog2qD8EGU8GK/txEax+prve hqNbIIK1lQIkP2NyGEJQBir+xridX/NM9dAm5D+Nq+b+/pQG39tsx0WIUZC0zvmy +KZJjQhc4Y8yfhBr8oZ7xBbIrMD5IIQiR+oXNeuweG9AFjEPSrTfZs1RcK/qw/Di WJrIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=dq2W6fN5QcRY2OPpbosT/rUUHVNKL2+T52pGTS/J6 kc=; b=disk8D212Ep7DPAYOA4fuRFVDncR8NgLSmgGYS7bPeT95vyGsWoPBLS9c WowQ07PQmPvHJN6c2dqnxJXtjmcumBqQBY26FjVO23r8grM2+U1aY25bqgaQxT4i KBmHuy+FN0H5E8AYMfjP+rILjogch8qJZmAydHT1aKEtZUhk8twWpqNuE8r+iqNn CUxDWuNdFl5KI0DD48rvKeGAtsWnIbr3NhN6t12bt1dndJAyhu48Wz3x5WQQYy/E 9tr8uvpOCM6PMS3LBHNGVScZRUsdX1vckD5pPYy+iwFTFgRr1Ep4HVB73Bmg92os wXFDz2TbFESmF5jF4fXu/4s8Lb+FA== X-ME-Sender: X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.92]) by mail.messagingengine.com (Postfix) with ESMTPA id 561EB10311; Tue, 20 Nov 2018 16:25:36 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <154117528787.7013.6199833371829068074@ietfa.amsl.com> Date: Tue, 20 Nov 2018 16:25:35 -0500 Cc: General Area Review Team , draft-ietf-stir-passport-shaken.all@ietf.org, stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <158B9954-2651-47F4-97FE-5BF82DA7D21E@cooperw.in> References: <154117528787.7013.6199833371829068074@ietfa.amsl.com> To: Francesca Palombini X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [stir] [Gen-art] Genart last call review of draft-ietf-stir-passport-shaken-04 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, 20 Nov 2018 21:25:42 -0000 Francesca, thanks for your review. All, thanks for addressing = Francesca=E2=80=99s comments. I entered a No Objection ballot but I = think there is more to say about the privacy implications of origids =E2=80= =94 to be discussed in the thread about Eric=E2=80=99s ballot. Thanks, Alissa > On Nov 2, 2018, at 12:14 PM, Francesca Palombini = wrote: >=20 > Reviewer: Francesca Palombini > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-stir-passport-shaken-04 > Reviewer: Francesca Palombini > Review Date: 2018-11-02 > IETF LC End Date: 2018-11-02 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This draft is on the right track but has open issues, = described in the > review. >=20 > Major issues: >=20 > * This draft defines the new claim "origid" for the Personal = Attestation Token > used in the SHAKEN framework, but does not give any privacy = considerations > about it and its use. [RFC6973] suggests that the privacy = considerations of > IETF protocols be documented. As required by [RFC7258], work on IETF = protocols > needs to consider the effects of pervasive monitoring and mitigate = them when > possible. I don't know SHAKEN well enough to comment on privacy issues = on that, > but this draft, as part of the IETF work, should have privacy = considerations, > particularly considering the "origid" claim. >=20 > Minor issues: >=20 > * Section 4: the term "verified association" is not defined in this = document, > nor in [RFC8225], nor in the SHAKEN spec referenced. Is there a way to = clarify > what is meant by it? It could be a reference. >=20 > Nits/editorial comments: >=20 > * Terminology: I would have appreciated a short sentence mentioning = [RFC8225] > in the Terminology section. >=20 > * Section 9: [RFC8224] appears without link. >=20 > * Acknowledgements: "The authors would like > acknowledge the work of the ATIS/SIP Forum IP-NNI Task Force to > develop the concepts behind this document." -> The authors would = like to > acknowledge ... >=20 > I do not repeat nits and editorials reported by Adam Roach in his = review of > this version of the document (11-19-2018, > https://mailarchive.ietf.org/arch/msg/stir/HxVSCLPGfSgwFuvqLkWSVNI0PtQ = ) >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Nov 20 14:49:50 2018 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 921E8130DF4; Tue, 20 Nov 2018 14:49:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks , stir-chairs@ietf.org, rjsparks@nostrum.com, stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154275417951.29810.11674187715451909045.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 14:49:39 -0800 Archived-At: Subject: [stir] Ben Campbell's Yes on draft-ietf-stir-passport-shaken-05: (with COMMENT) 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: Tue, 20 Nov 2018 22:49:40 -0000 Ben Campbell has entered the following ballot position for draft-ietf-stir-passport-shaken-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am balloting "Yes" because I want to see the anti-robocalling framework get deployed sooner than later. But I share some of the privacy concerns that have been raised by others. I will follow that conversation on the thread resulting from Ekr's DISCUSS. Some additional comments: *** Substantive Comments *** §3: "The second claim is a unique origination identifier that should be used by the service provider..." Was that "should" meant as a "SHOULD"? §4 - Some of the terminology in the definitions of the attestation types seems vague to me. Does "authenticated relationship with the initiator" mean the same as "has authenticated the originator of the call"? Does "established a verified association with the calling party telephone number" mean the same as "verified that the calling party has the right to use the calling identity"? (The ATIS doc has more detailed explanations, which makes me wonder if it wouldn't have been better to just reference those definitions.) - The type "C" description includes "Has no relationship with the initiator of the call (e.g., international gateways)" in the list of MUST conditions. Is it the intent that an operator can only use a Type C attestation if it does not have that relationship? That is, an operator that did have a relationship with the initiator of the call is not allowed to use a type C attestation to avoid disclosure of the relationship? (How would one test that?) §10: - As Alissa mentioned, the fact that similar information that might be gleaned from originid is carried in SIP is not very convincing. It's historically been common for operators to use SBCs to hide things like Record-Route and Via. (and I presume History-Info). - Is originid required? Could an operator who had privacy concerns simply choose not to include it? (Maybe that operator has sufficient internal records to hunt down bad actors.) - The ATIS doc talks about using the originid in type B attestations to track "reputation". I assume this sort of tracking could be done by parties other than the attesting operator? If so, I think that's worth some discussion. *** Editorial Comments *** - Abstract: Please expand SHAKEN in the abstract. §1: Please expand VoIP, TDM, and SS7 From nobody Tue Nov 20 18:47:41 2018 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 AAC8A129385; Tue, 20 Nov 2018 18:47:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks , stir-chairs@ietf.org, rjsparks@nostrum.com, stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154276845865.29769.15487419915492003928.idtracker@ietfa.amsl.com> Date: Tue, 20 Nov 2018 18:47:38 -0800 Archived-At: Subject: [stir] Spencer Dawkins' Yes on draft-ietf-stir-passport-shaken-05: (with COMMENT) 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: Wed, 21 Nov 2018 02:47:39 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-stir-passport-shaken-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I echo Ben's "Yes assuming the Discusses can be resolved". It's about time we provided this capability! I did have a couple of comments you might want to consider, along with anything else that pops up during IESG Evaluation. "SHAKEN" isn't spelled out in either the title or Abstract - that would probably help almost all the readers of this document ... I did find it odd that This indicator allows for both identifying the service provider that is vouching for the call as well as clearly indicating what information the service provider is attesting to. The 'attest' claim can be one of the following three values: 'A', 'B', or 'C' as defined in [ATIS-1000074]. used "A", "B", and "C", instead of something like "F"(ull), "P"(artial), and "G"(ateway), because if you discover a need for a fourth value, it's not clear whether anyone would be assuming "A" < "B" < "C" ordering in their code, that would break if the fourth value was naturally between "A" and "B". If you're sure no one but Spencer would be so dumb, that's a fine response ... From nobody Tue Nov 20 19:42:45 2018 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 3293A130E5B; Tue, 20 Nov 2018 19:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 OI65WNafxMc3; Tue, 20 Nov 2018 19:42:42 -0800 (PST) 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 D5F07130E3D; Tue, 20 Nov 2018 19:42:41 -0800 (PST) Received: from [10.0.1.24] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAL3gd6p021693 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Nov 2018 21:42:40 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.24] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C27F1562-D4BC-43B9-B99A-D482B69BE98D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 20 Nov 2018 21:42:38 -0600 In-Reply-To: <154276845865.29769.15487419915492003928.idtracker@ietfa.amsl.com> Cc: The IESG , stir@ietf.org, stir-chairs@ietf.org, draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks To: Spencer Dawkins References: <154276845865.29769.15487419915492003928.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [stir] Spencer Dawkins' Yes on draft-ietf-stir-passport-shaken-05: (with COMMENT) 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, 21 Nov 2018 03:42:44 -0000 --Apple-Mail=_C27F1562-D4BC-43B9-B99A-D482B69BE98D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 20, 2018, at 8:47 PM, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-stir-passport-shaken-05: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I echo Ben's "Yes assuming the Discusses can be resolved". It's about = time we > provided this capability! >=20 > I did have a couple of comments you might want to consider, along with = anything > else that pops up during IESG Evaluation. >=20 > "SHAKEN" isn't spelled out in either the title or Abstract - that = would > probably help almost all the readers of this document ... >=20 > I did find it odd that >=20 > This indicator allows for both identifying the service provider that > is vouching for the call as well as clearly indicating what > information the service provider is attesting to. The 'attest' = claim > can be one of the following three values: 'A', 'B', or 'C' as = defined > in [ATIS-1000074]. >=20 > used "A", "B", and "C", instead of something like "F"(ull), = "P"(artial), and > "G"(ateway), because if you discover a need for a fourth value, it's = not clear > whether anyone would be assuming "A" < "B" < "C" ordering in their = code, that > would break if the fourth value was naturally between "A" and "B". If = you're > sure no one but Spencer would be so dumb, that's a fine response ... >=20 Hi Spencer, I considered making that same comment, but that bit of oddness may = already be written in stone, since it=E2=80=99s the terminology used in = the ATIS SHAKEN document. IIUC that already published in its final form. Ben. --Apple-Mail=_C27F1562-D4BC-43B9-B99A-D482B69BE98D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlv01C4ACgkQgFZKbJXz 1A1VFA//ejg8LywPpuGwfhUoyHctMY0ku/SJ+ltz6lFG1RZU2F7gVZrAlbelFzxg pWEj/iZ9ddJu0/w3AgrM/itG5t8fdmGcCd+QijHq6V/n7XU4tzcsbf5dYwsHHxBy aYWxg/eXUYWKhbl3CGssqXRNBD6p/dQfY6lhyLx913DjXwINkLTy4uRd7iz2Fvpb 3NlwGsim5vM3cJCdhsC8E4XZCz2Jk0fl8gtQ7iw6LuYDQEVducy52Q6q5KWgWsFY kuFURAQXnY4mPfJ05AJeRnhWEo+4D1Rb9TIHrhTK8WKSPoCqVU93S/xPLYLTCrgS aABhgOE5cmsGKD3SR7uM5wDHHF/5HilOcVC6mSEqe+BwHUTX6Il2x58plq8Vxgwy PcmBwM2/1s6qyAlnklHtiyfVj33bBP+Mq39oSOyFWwyhURAT1XnkObVxNu664nff r8p5GyiTmmYSvhgq8AlVXdSebhLXgFJaMXo2HnbTkcqriDE4I0+iXbamg4mbER4H u5K8uP2OUiHSpjgcAP5oBoXhwMs6K1OgOImpRtwUXNg6AtvqRQZK3aCJwphmSJPH ch5KOeGgkNKeVIIldPUJiIrabr+U44WSmZge9bMYt8WuY4ovjeyTaE+gVHxl5oNU coBXA/MThi2Ax/HhuClCcqjiHgFTlgKo7WIx48vW/1KZwh8Iweo= =Musj -----END PGP SIGNATURE----- --Apple-Mail=_C27F1562-D4BC-43B9-B99A-D482B69BE98D-- From nobody Wed Nov 21 05:27:31 2018 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 5FA2D130D7A; Wed, 21 Nov 2018 05:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 hyHGwgUsMjjj; Wed, 21 Nov 2018 05:27:20 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 DD8911298C5; Wed, 21 Nov 2018 05:27:19 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id p17so3979354lfh.4; Wed, 21 Nov 2018 05:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mW/BOf4y3Dkj3niA4eroRyeHHgMzs6MJpO91CbGNHZk=; b=kzlx5wB1BEZmm/c9QmOY7bn0hPHmGAN6iMKj7bKD8CdKGvn+OInjxxlQXkjMrJ2f8K jwu4If+j45PpJ5VzeuLy9N+WMQnVXYCZdQs9Vn6gofWQle5Tj2yTQrF1vlotV3wdog11 ud1mFfCGZ1CPva5iyg1e8ASZoIqxPe4N3NCY5x1t1kUQdjltNY2iJXSAPyE6lwodPRs8 H3/b+8LXwcBlOpyhTQxqymNW7ZqYPwVy8NbySS/ZsLklQTD6j3PvX8+ckyPt459LikGR 6LJqrDMoa53QBk2qSbtv32t8PlAXCWMVbrr2iou4FzhK2LvFWxzFOYpnvVySLG6f1rxf G7Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mW/BOf4y3Dkj3niA4eroRyeHHgMzs6MJpO91CbGNHZk=; b=ae5ySK/nB7fBKjNK1PufiXn//2zKfC34b4D2xNMEVPgX7lp59fiC8xCHJfSuTXGfC3 7JcKFK6Afcola/yUyGCsr+p+voiRVv9YILiwLHGJoK5hbeBjLUVBSuXQZMGaQ7bqPfZZ ZyS23BEAROAuopUZPj0DVcGTWaQS9Tbf/vm3PMnSC10j47HFnwd/3JHECX7cP9CW0F2S 8RZSh83E3WXF3OlP6vofZlTuC2LS9wJtBNTyUfdcs15w+X0MFGtqLTvzcx/Ml2MAsdeH i1ofhJGfYr9r0YF8jERYS3YtRP2ZQWKtaAbQDp4obsK52PQKW3TTa7UJOq+9LEkclCmm fXow== X-Gm-Message-State: AGRZ1gLN484HUXnPSOZXyFA1jEgr+jMRRNslG5rYEKb+Qm+jTcDKlldP M2NpryZWTP7KY9rhYg6SQMwg2aBgMIGe1AbQV/7Irg== X-Google-Smtp-Source: AJdET5e7mIgdtPndDrrZM4mTUbkWcAwK42V2JPXpV1KCtKDFM/dle+FYi6DguvI9P+D/WI9IMeE/uA5ehp0K4sGUOZ4= X-Received: by 2002:a19:d145:: with SMTP id i66mr3976751lfg.97.1542806837908; Wed, 21 Nov 2018 05:27:17 -0800 (PST) MIME-Version: 1.0 References: <154276845865.29769.15487419915492003928.idtracker@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 21 Nov 2018 07:27:04 -0600 Message-ID: To: Ben Campbell Cc: IESG , stir@ietf.org, stir-chairs@ietf.org, draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks Content-Type: multipart/alternative; boundary="00000000000087d70f057b2cb5a7" Archived-At: Subject: Re: [stir] Spencer Dawkins' Yes on draft-ietf-stir-passport-shaken-05: (with COMMENT) 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, 21 Nov 2018 13:27:22 -0000 --00000000000087d70f057b2cb5a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Ben, On Tue, Nov 20, 2018 at 9:42 PM Ben Campbell wrote: > > > > On Nov 20, 2018, at 8:47 PM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-stir-passport-shaken-05: Yes > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I echo Ben's "Yes assuming the Discusses can be resolved". It's about > time we > > provided this capability! > > > > I did have a couple of comments you might want to consider, along with > anything > > else that pops up during IESG Evaluation. > > > > "SHAKEN" isn't spelled out in either the title or Abstract - that would > > probably help almost all the readers of this document ... > > > > I did find it odd that > > > > This indicator allows for both identifying the service provider that > > is vouching for the call as well as clearly indicating what > > information the service provider is attesting to. The 'attest' claim > > can be one of the following three values: 'A', 'B', or 'C' as defined > > in [ATIS-1000074]. > > > > used "A", "B", and "C", instead of something like "F"(ull), "P"(artial)= , > and > > "G"(ateway), because if you discover a need for a fourth value, it's no= t > clear > > whether anyone would be assuming "A" < "B" < "C" ordering in their code= , > that > > would break if the fourth value was naturally between "A" and "B". If > you're > > sure no one but Spencer would be so dumb, that's a fine response ... > > > > Hi Spencer, > > I considered making that same comment, but that bit of oddness may alread= y > be written in stone, since it=E2=80=99s the terminology used in the ATIS = SHAKEN > document. IIUC that already published in its final form. > Yeah. I know that ATIS doesn't engrave their specifications on stone, so that could change if it needed to, but this probably isn't the oddest thing in a draft that I've balloted Yes on, so ... "Do the right thing." Spencer > Ben. > > > --00000000000087d70f057b2cb5a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Ben,



> On Nov 20, 2018, at 8:47 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com= > wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-stir-passport-shaken-05: Yes
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/d= oc/draft-ietf-stir-passport-shaken/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I echo Ben's "Yes assuming the Discusses can be resolved"= ;. It's about time we
> provided this capability!
>
> I did have a couple of comments you might want to consider, along with= anything
> else that pops up during IESG Evaluation.
>
> "SHAKEN" isn't spelled out in either the title or Abstra= ct - that would
> probably help almost all the readers of this document ...
>
> I did find it odd that
>
>=C2=A0 This indicator allows for both identifying the service provider = that
>=C2=A0 =C2=A0is vouching for the call as well as clearly indicating wha= t
>=C2=A0 =C2=A0information the service provider is attesting to.=C2=A0 Th= e 'attest' claim
>=C2=A0 =C2=A0can be one of the following three values: 'A', = 9;B', or 'C' as defined
>=C2=A0 =C2=A0in [ATIS-1000074].
>
> used "A", "B", and "C", instead of somet= hing like "F"(ull), "P"(artial), and
> "G"(ateway), because if you discover a need for a fourth val= ue, it's not clear
> whether anyone would be assuming "A" < "B" <= "C" ordering in their code, that
> would break if the fourth value was naturally between "A" an= d "B".=C2=A0 If you're
> sure no one but Spencer would be so dumb, that's a fine response .= ..
>

Hi Spencer,

I considered making that same comment, but that bit of oddness may already = be written in stone, since it=E2=80=99s the terminology used in the ATIS SH= AKEN document. IIUC that already published in its final form.

Yeah. I know that ATIS doesn't engrave their spe= cifications on stone, so that could change if it needed to, but this probab= ly isn't the oddest thing in a draft that I've balloted Yes on, so = ...

"Do the right thing."

=
Spencer
=C2=A0
Ben= .


--00000000000087d70f057b2cb5a7-- From nobody Wed Nov 21 17:36:42 2018 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 4B17D130E96; Wed, 21 Nov 2018 17:36:32 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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 eI-bPRtIQr1v; Wed, 21 Nov 2018 17:36:29 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 3A204130E8C; Wed, 21 Nov 2018 17:36:26 -0800 (PST) X-AuditID: 1209190e-c7fff70000005413-1c-5bf6081750bd Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E0.9B.21523.81806FB5; Wed, 21 Nov 2018 20:36:24 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id wAM1aIeg028648; Wed, 21 Nov 2018 20:36:20 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAM1aDla030341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Nov 2018 20:36:16 -0500 Date: Wed, 21 Nov 2018 19:36:13 -0600 From: Benjamin Kaduk To: Chris Wendt Cc: The IESG , draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks , STIR Chairs , stir@ietf.org Message-ID: <20181122013612.GC11132@kduck.kaduk.org> References: <154259095538.2354.17623821529843764623.idtracker@ietfa.amsl.com> <4E6DAD8F-6104-4215-9EE8-3894A99CD81D@chriswendt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4E6DAD8F-6104-4215-9EE8-3894A99CD81D@chriswendt.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6noivB8S3a4NgpM4vpn3YzW2xbdp3N YsaficwW1+Y0slk827Ge1WL52m1MDmweE/rWsHosWfKTyWPWzicsAcxRXDYpqTmZZalF+nYJ XBmtxy+wF2wVq3h/6hx7A2O/UBcjJ4eEgInEpOvn2EBsIYE1TBJXW927GLmA7I2MEhd+7WKE cO4ySVzuPcUCUsUioCrxuf86I4jNJqAi0dB9mRnEFhHQljh8pgGsgRmke/r9D6wgCWGBTIlX 6++DreAFWjdn7yQmiKmtjBJPPh1mh0gISpyc+QRsA7OAusSfeZeApnIA2dISy/9xQITlJZq3 zgZbxingJHF0zlqw+aICyhJ7+w6xT2AUnIVk0iwkk2YhTJqFZNICRpZVjLIpuVW6uYmZOcWp ybrFyYl5ealFusZ6uZkleqkppZsYQbHAKcm3g3FSg/chRgEORiUe3obor9FCrIllxZW5hxgl OZiURHnZsoFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgvrADK8aYkVlalFuXDpKQ5WJTEeX+J PI4WEkhPLEnNTk0tSC2CycpwcChJ8Aqzf4sWEixKTU+tSMvMKUFIM3FwggznARquAlLDW1yQ mFucmQ6RP8WoKCXOWwqSEABJZJTmwfWCUpVE9v6aV4ziQK8I83KCVPEA0xxc9yugwUxAg2XP fAYZXJKIkJJqYFx5peEPk86FVTNU+madSH35Ij5QZrH6k0bxH1wc7+TXmZoHH3m8z8zP/H5V 22IpJ8mpKxL6564+nbdg/qJVXRuuCqtv9b/xKn764idL25r2Kt5uPni4bKLi+qDiWt2Msjt7 1jmdX8SR3zJxu8JGuaWvDEIdW38vXxuU7ZNV7NSr+OfHoT1v93EqsRRnJBpqMRcVJwIACaqH czADAAA= Archived-At: Subject: Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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: Thu, 22 Nov 2018 01:36:32 -0000 Hi Chris, On Tue, Nov 20, 2018 at 12:05:55PM -0500, Chris Wendt wrote: > Hi Ben, All, > > Originally in the document, i believe i did have most of this information defined as a reference to the original SHAKEN document. I got working group comments that believed the definitions should be directly in the document themselves versus by reference. > > I worry about trying to re-write things too much with the potential of causing confusion between the SHAKEN and STIR specs. I definitely understand this sentiment. > I guess i would need higher level guidance on how to proceed with this if there is a concern about this. While I can check with ATIS folks and maybe initiate some "written permission†not sure if that is the best path here or if i really have the legal standing to do that myself in either case. I think Adam will be helping to coordinate these efforts, based on our discussions on the telechat today. -Benjamin > -Chris > > > On Nov 18, 2018, at 8:29 PM, Benjamin Kaduk wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-stir-passport-shaken-05: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > A nontrivial amount of text in this document appears to have been taken from > > https://access.atis.org/apps/group_public/download.php/32237/ATIS-1000074.pdf > > which notes that "No part of this publication may be reproduced in any > > form, in an electronic retrieval system or otherwise, without the prior > > written permission of the publisher." Do we have prior written permission > > to duplicate such text? > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I am interested in seeing the resolution of discussion on Ekr's Discuss, but > > will stick to that thread for such discussion. > > > > Section 4 > > > > Am I reading this properly that the difference between 'A' and 'B' is that > > in 'B' we don't have any information about the device that's originating > > the call, just the identity of the user/customer? > > > > > From nobody Mon Nov 26 08:32:20 2018 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 B6CF5130F50 for ; Mon, 26 Nov 2018 08:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 hL6qz15PFXSD for ; Mon, 26 Nov 2018 08:32:11 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 314E1130F4F for ; Mon, 26 Nov 2018 08:32:09 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id e5so18231163qtr.12 for ; Mon, 26 Nov 2018 08:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+sY+Eq8XoKy+CF57mq8rwgg9Xfl1e5pK1LYUeZ9RLBc=; b=C/mlIjzvVl13aiql1D0TPROhHq9iBdtG8n6oz4zz3gr7Jxmd0Kkm3ilOblXfMn+gwP xTBYO+fnwCBcrallzF9ftJyfW3kyiU30n/a39qUW13Rs5ne89VJLa+k67pPHNnQGkPbC LErSgv/jiJMnkdoj+W6K5lSf13b+YIfvVEl9/3pQ+tIzV4l6aqqHDihw5PzHh3whuxYR c5s2Oo3zHQf6t1iSsfBklcwuH++EIGEBp7poSBZcvOU5tPTwnN/5bfZXMqwr5Fp/QLLE eto3m616o5NsLbLK9yHx2zfJeBTCwoG+sWZzrV3UHtCHZBXjvMzeR4eFa0BwWPzLnrym ueUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+sY+Eq8XoKy+CF57mq8rwgg9Xfl1e5pK1LYUeZ9RLBc=; b=mJPrWkV1TFocQuusu53JCqbU2fQ30dgpeIGBpigEIaFQ3Z4p2CVTVDQJYSyKoVTGwU 7AD+qL2Xv3q8VLE55r+KbGyVE6RffKHix4sokzfAIlWqVaYDn/UBkHwOo7NWio0FWO2k 5I+zLWbtq9wRvt9puLCWVBViK3TCNR9YBVHdU/nqO4nMwxHwbV0o1ro5zWMlXDY0na8Q 0ebaqhn0T3syFbWAThYEUiGA5LjmOouZLx+USwG7L5dRcSHZ6iz7cee6ra1AxROs4mq6 DEQejAe9fxZGRZKIFreeZLFMkU8dG1YCmPFTeAK4Hyzl1mHkFHMhENk/YUfBOoUzRiI0 cQHg== X-Gm-Message-State: AA+aEWZzjncckJWEt2c71ZljWqNb6JfJMW7JZ7LxPezmF1OevnoHKh0M V8aTwbwE5D8A04QOi2ZGvWx2sA== X-Google-Smtp-Source: AJdET5fBUyX6rCyQAAzc+/fTumjWiuTQO8e2TtvQveiWRB/EnZV7+RsK5Ibdql7Lidc+TuVLoTiwbw== X-Received: by 2002:ac8:278a:: with SMTP id w10mr26850644qtw.149.1543249928269; Mon, 26 Nov 2018 08:32:08 -0800 (PST) Received: from [10.16.48.17] (23.226.128.22.adsl.inet-telecom.org. [23.226.128.22]) by smtp.gmail.com with ESMTPSA id q17sm623290qtc.19.2018.11.26.08.32.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 08:32:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: <154276845865.29769.15487419915492003928.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2018 11:32:06 -0500 Cc: The IESG , draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks , STIR Chairs , stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154276845865.29769.15487419915492003928.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Spencer Dawkins' Yes on draft-ietf-stir-passport-shaken-05: (with COMMENT) 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, 26 Nov 2018 16:32:13 -0000 Hi Spencer, I definitely wouldn=E2=80=99t say it=E2=80=99s a dumb comment, but the = reasons behind the different levels of attestations is due to some of = the realities of the current telephone network. Going forward, we do = not want to make more levels of attestation, rather we want all calls to = essentially be =E2=80=9CA=E2=80=9D level full attestation, which is = essentially pure STIR where the party signing the call does have the = ownership of the telephone number and has control of the credentials to = sign the call. In the telephone network there is many cases where the = party that owns the telephone number doesn=E2=80=99t have any = relationship with the party that either places the call or originates = the call on to the telephone network. (think a call center that uses the = enterprise phone number as the outgoing calling identity for a customer = service agent, or a snow delay robocall that uses the school district = number)=20 So bottomline, the number of attestation levels should not increase, but = rather B and C should hopefully become less common as time goes on and = SHAKEN/STIR is more widely deployed into these enterprise and call = center environments. -Chris > On Nov 20, 2018, at 9:47 PM, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-stir-passport-shaken-05: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I echo Ben's "Yes assuming the Discusses can be resolved". It's about = time we > provided this capability! >=20 > I did have a couple of comments you might want to consider, along with = anything > else that pops up during IESG Evaluation. >=20 > "SHAKEN" isn't spelled out in either the title or Abstract - that = would > probably help almost all the readers of this document ... >=20 > I did find it odd that >=20 > This indicator allows for both identifying the service provider that > is vouching for the call as well as clearly indicating what > information the service provider is attesting to. The 'attest' = claim > can be one of the following three values: 'A', 'B', or 'C' as = defined > in [ATIS-1000074]. >=20 > used "A", "B", and "C", instead of something like "F"(ull), = "P"(artial), and > "G"(ateway), because if you discover a need for a fourth value, it's = not clear > whether anyone would be assuming "A" < "B" < "C" ordering in their = code, that > would break if the fourth value was naturally between "A" and "B". If = you're > sure no one but Spencer would be so dumb, that's a fine response ... >=20 >=20 From nobody Mon Nov 26 08:42:14 2018 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 EE22A130F2D for ; Mon, 26 Nov 2018 08:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 lhA5skQCkAmq for ; Mon, 26 Nov 2018 08:42:09 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 7C970130DD2 for ; Mon, 26 Nov 2018 08:42:09 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id o125so12706880qkf.3 for ; Mon, 26 Nov 2018 08:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zSpLILDGbkrX7KENVYK1SIgZZ60nWFMdejKGf0crxXU=; b=s8ZmaQtuJdh6Mg9cujIPnJHUZhsOepRhOrMoBHeYf9VOYT5qpj4R6XVn/A0MvX4l13 RUEmKZhrtMkycneviBkDUBS9EC6TFhbgAGupKv36Imzk+930HacNgfJsGfrW+Ofb0OkU L1c+lANvnpffe/GOrRY9A/DUpoY9RYZwsPzhISmNsH67UA8N6XT3GBsELKd/zuDQI7yx swPk49yMdVeNJVO/3Sdy1df8MSoPVVNhw+q5gGmiPpd9VT717EXGqpB/ZnF9Kd93lZod GgleJJQJfoDQyeLQZdj5nfwf0yNld6aTPol23fW3i/MK7lmPR8yYDZBuEbiVR4z9rB75 +8bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zSpLILDGbkrX7KENVYK1SIgZZ60nWFMdejKGf0crxXU=; b=XZukgJilngKQ2VJN02FbO0VvtqLAlS6SCs4haNOttc08X2Ug1K8LgE45UdnVi12Y39 nNmGGx33+piFLas3Ek4yLUIwPBRP4KhfyCPm3GGoGfmMSutI+g8ScSK1KvfTOa09BUAf 6PcLuga++BegbbQ1gG3mmRKOIHFa9nH/vV37a0rr5DcAjwcsfO+E0NpaL1fpYjQzntlb cgvyD1/RPVYeulJLwiCrmoUDqv8Ouu0FIQy8CupFrXbbUJl2DOMxLRw2n7c6z5gqC+of KJLfSRY/mYD27CEATm+iGSQ+yeH9qUtYdvOaJcbXbDU0k4rifUjvjssMkHje5PShwrrV S+Lg== X-Gm-Message-State: AA+aEWYrFHHDb7NDk/Gml9/fsXrVAjMn5XLB1WTWkaUiT9K9dzBute45 HOkiv5cd252f3ui4acNdq0S85Q== X-Google-Smtp-Source: AFSGD/WI7xQWmGXCn5hBO5X7FqzDgwG/G6/dgZRJXaS1esbQVB2zDQ6HUAzr4W//diNfsQEW1JTR/w== X-Received: by 2002:a37:6f45:: with SMTP id k66mr26517045qkc.313.1543250528599; Mon, 26 Nov 2018 08:42:08 -0800 (PST) Received: from [10.16.48.17] (23.226.128.22.adsl.inet-telecom.org. [23.226.128.22]) by smtp.gmail.com with ESMTPSA id t40sm542087qth.46.2018.11.26.08.42.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 08:42:07 -0800 (PST) From: Chris Wendt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2F2475C6-3784-475D-8EE3-501C443DC151" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 26 Nov 2018 11:42:06 -0500 In-Reply-To: Cc: IESG , IETF STIR Mail List , Robert Sparks , draft-ietf-stir-passport-shaken@ietf.org, stir-chairs@ietf.org To: Eric Rescorla References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> <022A3421-AFF6-4E0F-AEC2-24902B3D12EB@chriswendt.net> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 26 Nov 2018 16:42:13 -0000 --Apple-Mail=_2F2475C6-3784-475D-8EE3-501C443DC151 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, Responses inline. > On Nov 20, 2018, at 2:02 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Nov 20, 2018 at 9:19 AM Chris Wendt > wrote: > Hi Eric, >=20 > Answers inline. >=20 > > On Nov 17, 2018, at 6:17 PM, Eric Rescorla > wrote: > >=20 > > Eric Rescorla has entered the following ballot position for > > draft-ietf-stir-passport-shaken-05: Discuss > >=20 > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > >=20 > >=20 > > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > > for more information about IESG DISCUSS and COMMENT positions. > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ = > >=20 > >=20 > >=20 > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > >=20 > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D5207 = > >=20 > >=20 > > I would like to discuss the privacy properties of origids. As I read > > this text, it does not actually require them to be unlinkable or = that > > it not be possible to determine whether two ids represent the same > > person behind the origid generator, and I believe it should do so. > > Practically implementing that may require an ID that is longer than = a > > UUID. > >=20 > >=20 > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > >=20 > >=20 > >>=20 > >> This document extends PASSporT, which is a token object that = conveys > >> cryptographically-signed information about the participants = involved > >> in communications. The extension is defined, corresponding to = the > >> SHAKEN specification, to provide both a specific set of = levels-of- > >> confidence to the correctness of the originating identity for a = SIP > >=20 > > Nit: confidence of or confidence in >=20 > fixed >=20 > >=20 > >=20 > >=20 > >> in communications. The extension is defined, corresponding to = the > >> SHAKEN specification, to provide both a specific set of = levels-of- > >> confidence to the correctness of the originating identity for a = SIP > >> based Communication Service Provider (CSP) telephone network > >> originated call as well as an identifier that allows the CSP to > >> uniquely identify the origination of the call within its = network. > >=20 > > Nit: originator >=20 > I believe this should be origination, because it=E2=80=99s not = identifying the =E2=80=9Cuser=E2=80=9D or =E2=80=9Caccount=E2=80=9D = it=E2=80=99s identifying either a network element or some network region = or whatever the CSP needs to use to identify where the call came from, = rather than =E2=80=9Cwho=E2=80=9D the call came from. This is for = traceback purposes and to avoid the issue of having unique identifiers = that are specifically associated with users or accounts. >=20 > I understand, but origination if a funny term here. Perhaps "origin=E2=80= =9D=20 ok, that works, will change that in the document >=20 > >=20 > >=20 > > S 1. > >> need to be accounted for where PASSporT signatures may = represent > >> either direct or indirect call origination scenarios. The = SHAKEN > >> [ATIS-1000074] specification defines levels of attestation of = the > >> origination of the call as well as an origination identifier = that can > >> help create a unique association with the origination of calls = from > >> various parts of the VoIP or TDM telephone network. This = document > >=20 > > I can't read this. What is the association between? >=20 > Similar to above, the concept is that a CSP maps a unique identifier = to a network element or part of a CSP network that would facilitate the = ability to trace the origination of the call. It is defined to be = intentionally abstract to allow for various ways CSP manage their = networks and for example trunk associations to various network elements. >=20 > Right, but associations are between things. What are the two things.=20= How about this: The SHAKEN [ATIS-1000074] specification defines levels of attestation = of the origination of the call as well as an origination identifier that = can help create a unique association between the origin of a particular = call to the point in the VoIP or TDM telephone network the call came = from to identify, for example, either a customer or class of service = that call represents. >=20 > >=20 > >=20 > > S 2. > >> capitals, as shown here. > >>=20 > >> In addition, the following terms are used in this document: > >>=20 > >> o Verified association: is typically defined as an = authenticated > >> relationship with a device that initiated a call, for = example, a > >=20 > > relationship between the call and the device? >=20 > No, the point is that to provide this level of attestation, you need = to have a =E2=80=9Cverified=E2=80=9D authentication of the device/user = into your network. Typical example is a cell phone has SIM = authentication, or a SIP digest authentication. A scenario where you = don=E2=80=99t have an authenticated relationship is if you are a = wholesale provider or transit provider or other scenarios where you are = receiving an unsigned call. >=20 > Here too, relationships are between things. What are the two things. How about this: Verified association: is typically defined as an authenticated = relationship between a customer and a device that initiated a call on = behalf of that customer, for example, a >=20 > -Ekr >=20 >=20 > >=20 > >=20 > > S 4. > >>=20 > >> o Has a direct authenticated relationship with the initiator = of the > >> call and can identify the customer associated with the = initiator. > >>=20 > >> o Has NOT established a verified association with the calling = party > >> telephone number being used for the call. > >=20 > > For those who aren't; voice experts, can you give an example of when > > this would happen? >=20 > See above answer, i can see if i can integrate that explanation in the = text, if you think that covers it. >=20 > >=20 > >=20 > > S 10. > >> integrity protection and non-repudiation properties as the base > >> claims in the PASSporT. > >>=20 > >> 10. Privacy Considerations > >>=20 > >> As detailed in [RFC3261] Section 26, SIP messages inherently = carry > >=20 > > Thanks for including this section. > >=20 > >=20 --Apple-Mail=_2F2475C6-3784-475D-8EE3-501C443DC151 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

Responses inline.

On Nov = 20, 2018, at 2:02 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Tue, Nov 20, 2018 at 9:19 AM Chris Wendt <chris-ietf@chriswendt.net> wrote:
Hi Eric,

Answers inline.

> On Nov 17, 2018, at 6:17 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Eric = Rescorla has entered the following ballot position for
> = draft-ietf-stir-passport-shaken-05: Discuss
> 
> When = responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel = free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html> for more information about IESG DISCUSS and COMMENT = positions.
> 
> 
> The = document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shake= n/
> 
> 
> 
> = ----------------------------------------------------------------------
> DISCUSS:
> = ----------------------------------------------------------------------
> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D5207
> 
> 
> I would like to discuss the privacy properties of = origids. As I read
> this text, it does not actually = require them to be unlinkable or that
> it not be = possible to determine whether two ids represent the same
> person behind the origid generator, and I believe it = should do so.
> Practically implementing that may = require an ID that is longer than a
> UUID.
> 
> 
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
> 
> 
>> 
>>     This document extends PASSporT, = which is a token object that conveys
>>    =  cryptographically-signed information about the participants = involved
>>     in = communications.  The extension is defined, corresponding to the
>>     SHAKEN specification, to provide = both a specific set of levels-of-
>>    =  confidence to the correctness of the originating identity for a = SIP
> 
> Nit: = confidence of or confidence in

fixed

> 
> 
> 
>> =    in communications.  The extension is defined, = corresponding to the
>>     SHAKEN = specification, to provide both a specific set of levels-of-
>>     confidence to the correctness of = the originating identity for a SIP
>>    =  based Communication Service Provider (CSP) telephone network
>>     originated call as well as an = identifier that allows the CSP to
>>    =  uniquely identify the origination of the call within its = network.
> 
> Nit: = originator

I believe this should be = origination, because it=E2=80=99s not identifying the =E2=80=9Cuser=E2=80=9D= or =E2=80=9Caccount=E2=80=9D it=E2=80=99s identifying either a network = element or some network region or whatever the CSP needs to use to = identify where the call came from, rather than =E2=80=9Cwho=E2=80=9D the = call came from.  This is for traceback purposes and to avoid the = issue of having unique identifiers that are specifically associated with = users or accounts.

I understand, but origination if a = funny term here. Perhaps "origin=E2=80=9D 

ok, that works, will change that in the = document


> 
> 
> S 1.
>>     need to be accounted for where = PASSporT signatures may represent
>>    =  either direct or indirect call origination scenarios.  The = SHAKEN
>>     [ATIS-1000074] = specification defines levels of attestation of the
>>     origination of the call as well = as an origination identifier that can
>>  =    help create a unique association with the origination of = calls from
>>     various parts of = the VoIP or TDM telephone network.  This document
> 
> I can't read this. What is the association between?

Similar to above, the concept is that a CSP = maps a unique identifier to a network element or part of a CSP network = that would facilitate the ability to trace the origination of the = call.  It is defined to be intentionally abstract to allow for = various ways CSP manage their networks and for example trunk = associations to various network elements.

Right, but associations = are between things. What are the two things. 

How about this:

The SHAKEN  [ATIS-1000074] specification = defines levels of attestation of the origination of the call as well as = an origination identifier that can help create a unique association = between the origin of a particular call to the point in the VoIP or TDM = telephone network the call came from to identify, for example, either a = customer or class of service that call represents.



> 
> 
> S 2.
>>     capitals, as shown here.
>> 
>>     In addition, the following terms = are used in this document:
>> 
>> =    o  Verified association: is typically defined as an = authenticated
>>        = relationship with a device that initiated a call, for example, a
> 
> relationship between the call and the device?

No, the point is that to provide this level of = attestation, you need to have a =E2=80=9Cverified=E2=80=9D = authentication of the device/user into your network.  Typical = example is a cell phone has SIM authentication, or a SIP digest = authentication.  A scenario where you don=E2=80=99t have an = authenticated relationship is if you are a wholesale provider or transit = provider or other scenarios where you are receiving an unsigned call.

Here too, relationships are between things. What are the two = things.

How about this:

Verified association: is typically defined as an = authenticated relationship between a customer and a device that = initiated a call on behalf of that customer, for example, = a


-Ekr


> 
> 
> S 4.
>> 
>>     o  Has a direct = authenticated relationship with the initiator of the
>>        call and can identify the = customer associated with the initiator.
>> 
>> =    o  Has NOT established a verified association with = the calling party
>>        = telephone number being used for the call.
> 
> For = those who aren't; voice experts, can you give an example of when
> this would happen?

See = above answer, i can see if i can integrate that explanation in the text, = if you think that covers it.

> 
> 
> S = 10.
>>     integrity protection and = non-repudiation properties as the base
>>  =    claims in the PASSporT.
>> 
>> = 10.  Privacy Considerations
>> 
>> =    As detailed in [RFC3261] Section 26, SIP messages = inherently carry
> 
> Thanks = for including this section.
> 
> 

= --Apple-Mail=_2F2475C6-3784-475D-8EE3-501C443DC151-- From nobody Mon Nov 26 08:42:52 2018 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 E0460130DF4 for ; Mon, 26 Nov 2018 08:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 gMX2aDahu6ue for ; Mon, 26 Nov 2018 08:42:44 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 EBA4D130F73 for ; Mon, 26 Nov 2018 08:42:35 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id y20so18259325qtm.13 for ; Mon, 26 Nov 2018 08:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rn0n9511rQohFvbG6wxP881RdjhDeid3wijTClRW6y8=; b=iqLbq5jtZyOWyPFBk4DL3bLyO8bnVuTrYNS+FynehjPLwBcEIYaE/BokQ3SyAwoFYW niVT8qlg5QL9w1vdfR9d58PsU5u426KZNfjebhBWbLaX8bLobMFgZtSs19mJ2Ag7hRQN RwFhX805PVN4QdPm7JcNj/1SpEQzFAQWtFoXCHsmf6fMpu9Lkksl37oXHMc0j8UERJBQ An2GDV4oosPHt5DcvCkB+6DfuStgq68a/olwVphzY4EPYpBS61Nk4plFsYQnAdtehKwF 4vEQ7HlNhGBap4CSEGNgGzkN3J7j1vhX3708HljhoxKy/N/X2pVLvpidDXrk0b3sD+3M bw1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rn0n9511rQohFvbG6wxP881RdjhDeid3wijTClRW6y8=; b=PAB8dkrnC0HrqO3uTQuvxSrd2PumqoJcOeDLqxgJP4d3LGj9urzriqvhtu3SJD0VPh 0ZyJka5gkIAW+D/qyBvZj6/8yqBazoG8gmq/zNx4N/M9F5KZtHqY6kL3hUabScwYn+/u wt0tbsPok/I6+O3JGFY2q3ilwj6lo6nSrR3EhcmjQMEJLMlKur1iLueiSXTzNG837FTc ffnfGHDZPrCo+nVhJqQZ790AQVJkTzO6c9MPstvi3A/c6taQTnl/ExC8Wu7y6rX4BVO6 37/mwlN7rxcOVDwvTgpA8uaO9tHDHkpI1KlCE6OqSar1nkhWQ4uKN5xispjPEmhSYEgG I8qQ== X-Gm-Message-State: AGRZ1gJv1brFE15DPGE8WAq8iThRTZytzKLvx6pOWH9EKmlAKBtjYmO0 N/i/Sjsfl7VhNuBQ4LuC6ktIo+4pqAk= X-Google-Smtp-Source: AFSGD/XPKZSH0EUaFjBa0jm/lX1darnM/ML6s4nPPMsIt/OHQ59FP+rBUanbJ9ABAEPs3Y6CxMXBFA== X-Received: by 2002:ac8:2502:: with SMTP id 2mr27057561qtm.53.1543250555111; Mon, 26 Nov 2018 08:42:35 -0800 (PST) Received: from [10.16.48.17] (23.226.128.22.adsl.inet-telecom.org. [23.226.128.22]) by smtp.gmail.com with ESMTPSA id t40sm542087qth.46.2018.11.26.08.42.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 08:42:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: <20181122013612.GC11132@kduck.kaduk.org> Date: Mon, 26 Nov 2018 11:42:33 -0500 Cc: The IESG , draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks , STIR Chairs , stir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <62F82506-659D-4BC4-8F68-0C306EC804CF@chriswendt.net> References: <154259095538.2354.17623821529843764623.idtracker@ietfa.amsl.com> <4E6DAD8F-6104-4215-9EE8-3894A99CD81D@chriswendt.net> <20181122013612.GC11132@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 26 Nov 2018 16:42:46 -0000 Ok, will wait for guidance. Thanks > On Nov 21, 2018, at 8:36 PM, Benjamin Kaduk wrote: >=20 > Hi Chris, >=20 > On Tue, Nov 20, 2018 at 12:05:55PM -0500, Chris Wendt wrote: >> Hi Ben, All,=20 >>=20 >> Originally in the document, i believe i did have most of this = information defined as a reference to the original SHAKEN document. I = got working group comments that believed the definitions should be = directly in the document themselves versus by reference. >>=20 >> I worry about trying to re-write things too much with the potential = of causing confusion between the SHAKEN and STIR specs. >=20 > I definitely understand this sentiment. >=20 >> I guess i would need higher level guidance on how to proceed with = this if there is a concern about this. While I can check with ATIS = folks and maybe initiate some "written permission=E2=80=9D not sure if = that is the best path here or if i really have the legal standing to do = that myself in either case. >=20 > I think Adam will be helping to coordinate these efforts, based on our > discussions on the telechat today. >=20 > -Benjamin >=20 >> -Chris >>=20 >>> On Nov 18, 2018, at 8:29 PM, Benjamin Kaduk wrote: >>>=20 >>> Benjamin Kaduk has entered the following ballot position for >>> draft-ietf-stir-passport-shaken-05: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> A nontrivial amount of text in this document appears to have been = taken from >>> = https://access.atis.org/apps/group_public/download.php/32237/ATIS-1000074.= pdf >>> which notes that "No part of this publication may be reproduced in = any >>> form, in an electronic retrieval system or otherwise, without the = prior >>> written permission of the publisher." Do we have prior written = permission >>> to duplicate such text? >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> I am interested in seeing the resolution of discussion on Ekr's = Discuss, but >>> will stick to that thread for such discussion. >>>=20 >>> Section 4 >>>=20 >>> Am I reading this properly that the difference between 'A' and 'B' = is that >>> in 'B' we don't have any information about the device that's = originating >>> the call, just the identity of the user/customer? >>>=20 >>>=20 >>=20 From nobody Mon Nov 26 08:45:56 2018 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 3E436130F27 for ; Mon, 26 Nov 2018 08:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Br-70TCqxJ93 for ; Mon, 26 Nov 2018 08:45:50 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D21B312F295 for ; Mon, 26 Nov 2018 08:45:49 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id l10so14063049lfh.9 for ; Mon, 26 Nov 2018 08:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OwUr4ZDweg8UmxB8RjUXD7HEil+C4tNcJ2+Ty5pBu+M=; b=eFEBKEBMPfCQv05sHG+nlG8tSB7058OeYiik9TuEEe054qrepEaTq1wgJTokmo8Qkd of2jgMVFECiZP1O5bp8t5A0IQ/nuQBn5gg5XTB68zlMuKvu0z/TNfGadYRr0FB10oYSk MgNrXqn6Q8NidOROUGzIPMBGcdMmNApqi2OvuksDntolj4FLntOI+2yL4KpCcVrKOz10 jaVTcweb400YY57OckUcwtle9BIFAsulx3ZrpTtm9ukdpfjbDApeaN6pHDw1jW82EJHS pWabdVNNR4QvwYMXMEogVTYeE9iCDucE5FOIYbpgq1P0SNjejeF+Cx7icDKgwHdCX+jy Z/Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OwUr4ZDweg8UmxB8RjUXD7HEil+C4tNcJ2+Ty5pBu+M=; b=bTJlVZazqI42l+D2mT72+c4/3T5Y/kLhP+I1DX6VdNtd5EOsDdIjJp+1qGC7bZ43+u KhJ3080PseER8N82UyfaqjbrhaMUQrnBS7RkPASNYEG+vYHHGCRcgbNxvsPTN7bZPt3m 5y6ouTGwv/aw3GTpL/12XxwOg64V3f/yQ9yAx0up0zMyvvnlLyvWqeelRepQvanA1SIt gb7tLEULCUMp2kFBYAbSFnteihQYXBZ9V1HBWJmHJOuzetVY2wnNYrAEkIZzawnae4/4 1wDgUNLYDUiIuvA6BZ7T0UJxVu4no47z7+3a9v0TK8ZMPjj4jabzrvaiqSQ16CjTAhcj AfPw== X-Gm-Message-State: AGRZ1gISilWFmRgq2LtoxkbyEqlvZjbypWrQcYlqRpxR7SGzTb8IFjTg +GVBGnVO36CnV70gXqkOj7wuk1qxQAT4BpMRHClmuQ== X-Google-Smtp-Source: AJdET5f6AhOTMnqHdCSPUrucemcpjUZy5eUDA4Mi3u7w9fGNaHdjHtL0l5+0wis+M239EerrIUkZviyUU8ffNDHpVe4= X-Received: by 2002:ac2:4354:: with SMTP id o20mr16996823lfl.129.1543250747996; Mon, 26 Nov 2018 08:45:47 -0800 (PST) MIME-Version: 1.0 References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> <022A3421-AFF6-4E0F-AEC2-24902B3D12EB@chriswendt.net> In-Reply-To: From: Eric Rescorla Date: Mon, 26 Nov 2018 08:45:10 -0800 Message-ID: To: Chris Wendt Cc: IESG , IETF STIR Mail List , Robert Sparks , draft-ietf-stir-passport-shaken@ietf.org, stir-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a25694057b941023" Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 26 Nov 2018 16:45:54 -0000 --000000000000a25694057b941023 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This works. Thanks On Mon, Nov 26, 2018 at 8:42 AM Chris Wendt wrote: > Hi Eric, > > Responses inline. > > On Nov 20, 2018, at 2:02 PM, Eric Rescorla wrote: > > > > On Tue, Nov 20, 2018 at 9:19 AM Chris Wendt > wrote: > >> Hi Eric, >> >> Answers inline. >> >> > On Nov 17, 2018, at 6:17 PM, Eric Rescorla wrote: >> > >> > Eric Rescorla has entered the following ballot position for >> > draft-ietf-stir-passport-shaken-05: Discuss >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut thi= s >> > introductory paragraph, however.) >> > >> > >> > Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > Rich version of this review at: >> > https://mozphab-ietf.devsvcdev.mozaws.net/D5207 >> > >> > >> > I would like to discuss the privacy properties of origids. As I read >> > this text, it does not actually require them to be unlinkable or that >> > it not be possible to determine whether two ids represent the same >> > person behind the origid generator, and I believe it should do so. >> > Practically implementing that may require an ID that is longer than a >> > UUID. >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > >> >> >> >> This document extends PASSporT, which is a token object that >> conveys >> >> cryptographically-signed information about the participants >> involved >> >> in communications. The extension is defined, corresponding to th= e >> >> SHAKEN specification, to provide both a specific set of levels-of= - >> >> confidence to the correctness of the originating identity for a S= IP >> > >> > Nit: confidence of or confidence in >> >> fixed >> >> > >> > >> > >> >> in communications. The extension is defined, corresponding to th= e >> >> SHAKEN specification, to provide both a specific set of levels-of= - >> >> confidence to the correctness of the originating identity for a S= IP >> >> based Communication Service Provider (CSP) telephone network >> >> originated call as well as an identifier that allows the CSP to >> >> uniquely identify the origination of the call within its network. >> > >> > Nit: originator >> >> I believe this should be origination, because it=E2=80=99s not identifyi= ng the >> =E2=80=9Cuser=E2=80=9D or =E2=80=9Caccount=E2=80=9D it=E2=80=99s identif= ying either a network element or some >> network region or whatever the CSP needs to use to identify where the ca= ll >> came from, rather than =E2=80=9Cwho=E2=80=9D the call came from. This i= s for traceback >> purposes and to avoid the issue of having unique identifiers that are >> specifically associated with users or accounts. >> > > I understand, but origination if a funny term here. Perhaps "origin=E2=80= =9D > > > ok, that works, will change that in the document > > >> > >> > >> > S 1. >> >> need to be accounted for where PASSporT signatures may represent >> >> either direct or indirect call origination scenarios. The SHAKEN >> >> [ATIS-1000074] specification defines levels of attestation of the >> >> origination of the call as well as an origination identifier that >> can >> >> help create a unique association with the origination of calls fr= om >> >> various parts of the VoIP or TDM telephone network. This documen= t >> > >> > I can't read this. What is the association between? >> >> Similar to above, the concept is that a CSP maps a unique identifier to = a >> network element or part of a CSP network that would facilitate the abili= ty >> to trace the origination of the call. It is defined to be intentionally >> abstract to allow for various ways CSP manage their networks and for >> example trunk associations to various network elements. >> > > Right, but associations are between things. What are the two things. > > > How about this: > > The SHAKEN [ATIS-1000074] specification defines levels of attestation of > the origination of the call as well as an origination identifier that can > help create a unique association between the origin of a particular call = to > the point in the VoIP or TDM telephone network the call came from to > identify, for example, either a customer or class of service that call > represents. > > > >> > >> > >> > S 2. >> >> capitals, as shown here. >> >> >> >> In addition, the following terms are used in this document: >> >> >> >> o Verified association: is typically defined as an authenticated >> >> relationship with a device that initiated a call, for example,= a >> > >> > relationship between the call and the device? >> >> No, the point is that to provide this level of attestation, you need to >> have a =E2=80=9Cverified=E2=80=9D authentication of the device/user into= your network. >> Typical example is a cell phone has SIM authentication, or a SIP digest >> authentication. A scenario where you don=E2=80=99t have an authenticate= d >> relationship is if you are a wholesale provider or transit provider or >> other scenarios where you are receiving an unsigned call. >> > > Here too, relationships are between things. What are the two things. > > > How about this: > > Verified association: is typically defined as an > authenticated relationship between a customer and a device that initiated= a > call on behalf of that customer, for example, a > > > -Ekr > > >> > >> > >> > S 4. >> >> >> >> o Has a direct authenticated relationship with the initiator of >> the >> >> call and can identify the customer associated with the >> initiator. >> >> >> >> o Has NOT established a verified association with the calling >> party >> >> telephone number being used for the call. >> > >> > For those who aren't; voice experts, can you give an example of when >> > this would happen? >> >> See above answer, i can see if i can integrate that explanation in the >> text, if you think that covers it. >> >> > >> > >> > S 10. >> >> integrity protection and non-repudiation properties as the base >> >> claims in the PASSporT. >> >> >> >> 10. Privacy Considerations >> >> >> >> As detailed in [RFC3261] Section 26, SIP messages inherently carr= y >> > >> > Thanks for including this section. >> > >> > > > > --000000000000a25694057b941023 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This works. Thanks

On Mon, Nov 26, 2018 at 8:42 AM Chris Wendt <chris-ietf@chriswendt.net> wro= te:
Hi Eric,

Responses inline.

On Nov 20, 2018, at 2:02 PM, Er= ic Rescorla <ekr@rtfm.= com> wrote:



On Tue, Nov 20, 2018 at 9:19 AM Chris Wendt <<= a href=3D"mailto:chris-ietf@chriswendt.net" target=3D"_blank">chris-ietf@ch= riswendt.net> wrote:
Hi Eric,

Answe= rs inline.

> On Nov 17, 2018, at 6:17 PM, Eric Rescorla <ekr@rtfm.com> wrote:>=C2=A0
> Eric Rescorla has entered the following ballot position for
= > draft-ietf-stir-passport-shaken-05: Discuss
>=C2=A0
> When respond= ing, please keep the subject line intact and reply to all
> email add= resses included in the To and CC lines. (Feel free to cut this
> intr= oductory paragraph, however.)
>=C2=A0
>=C2=A0
> Please refer to=C2=A0https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
> for more information about IESG DISCUSS and COMMENT position= s.
>=C2= =A0
>=C2=A0
> The document, along with other ballot positions, c= an be found here:
>=C2=A0https://data= tracker.ietf.org/doc/draft-ietf-stir-passport-shaken/
>=C2=A0
>=C2=A0
&g= t;=C2=A0=
> ------------------------------------------------------------------= ----
> DISCUSS:
> ---------------------------------------------= -------------------------
>=C2=A0
> Rich version of this review at:
= >=C2=A0https://mozphab-ietf.devsvcdev.mozaws.net/D5207=
>=C2=A0<= /span>
>= =C2=A0
> I would like to discuss the privacy properties of ori= gids. As I read
> this text, it does not actually require them to be = unlinkable or that
> it not be possible to determine whether two ids = represent the same
> person behind the origid generator, and I believ= e it should do so.
> Practically implementing that may require an ID = that is longer than a
> UUID.
>=C2=A0
>=C2=A0
> -------------------= ---------------------------------------------------
> COMMENT:
>= ; ---------------------------------------------------------------------->=C2=A0
>=C2= =A0
>>=C2=A0
>>=C2=A0 =C2=A0 =C2=A0This document extends P= ASSporT, which is a token object that conveys
>>=C2=A0 =C2=A0 =C2= =A0cryptographically-signed information about the participants involved
= >>=C2=A0 =C2=A0 =C2=A0in communications.=C2=A0 The extension is defin= ed, corresponding to the
>>=C2=A0 =C2=A0 =C2=A0SHAKEN specificatio= n, to provide both a specific set of levels-of-
>>=C2=A0 =C2=A0 = =C2=A0confidence to the correctness of the originating identity for a SIP>=C2=A0
> Nit: confidence of or confidence in

fixed

>=C2=A0
= >=C2=A0
>=C2= =A0
>>=C2=A0 =C2=A0 =C2=A0in communications.=C2=A0 The exte= nsion is defined, corresponding to the
>>=C2=A0 =C2=A0 =C2=A0SHAKE= N specification, to provide both a specific set of levels-of-
>>= =C2=A0 =C2=A0 =C2=A0confidence to the correctness of the originating identi= ty for a SIP
>>=C2=A0 =C2=A0 =C2=A0based Communication Service Pro= vider (CSP) telephone network
>>=C2=A0 =C2=A0 =C2=A0originated cal= l as well as an identifier that allows the CSP to
>>=C2=A0 =C2=A0 = =C2=A0uniquely identify the origination of the call within its network.
= >=C2=A0
> Nit: originator

I believe this should be origination, bec= ause it=E2=80=99s not identifying the =E2=80=9Cuser=E2=80=9D or =E2=80=9Cac= count=E2=80=9D it=E2=80=99s identifying either a network element or some ne= twork region or whatever the CSP needs to use to identify where the call ca= me from, rather than =E2=80=9Cwho=E2=80=9D the call came from.=C2=A0 This i= s for traceback purposes and to avoid the issue of having unique identifier= s that are specifically associated with users or accounts.
=

I understand, but origination if a funny term here. Per= haps "origin=E2=80=9D=C2=A0

<= /div>ok, that works, will change that in the document


>=C2=A0
>=C2=A0
> S 1.
>>=C2=A0 =C2= =A0 =C2=A0need to be accounted for where PASSporT signatures may represent<= br>>>=C2=A0 =C2=A0 =C2=A0either direct or indirect call origination s= cenarios.=C2=A0 The SHAKEN
>>=C2=A0 =C2=A0 =C2=A0[ATIS-1000074] sp= ecification defines levels of attestation of the
>>=C2=A0 =C2=A0 = =C2=A0origination of the call as well as an origination identifier that can=
>>=C2=A0 =C2=A0 =C2=A0help create a unique association with the o= rigination of calls from
>>=C2=A0 =C2=A0 =C2=A0various parts of th= e VoIP or TDM telephone network.=C2=A0 This document
>=C2=A0
> I can= 9;t read this. What is the association between?

Similar to above, th= e concept is that a CSP maps a unique identifier to a network element or pa= rt of a CSP network that would facilitate the ability to trace the originat= ion of the call.=C2=A0 It is defined to be intentionally abstract to allow = for various ways CSP manage their networks and for example trunk associatio= ns to various network elements.

Right, = but associations are between things. What are the two things.=C2=A0
=

How about this:

=
The SHAKEN=C2=A0=C2=A0[ATIS-1000074] specification defines level= s of attestation of the origination of the call as well as an origination i= dentifier that can help create a unique association between the origin of a= particular call to the point in the VoIP or TDM telephone network the call= came from to identify, for example, either a customer or class of service = that call represents.



>=C2= =A0
>=C2=A0
> S 2.
>>=C2=A0 =C2=A0 =C2=A0capitals, as s= hown here.
>>=C2=A0
>>=C2=A0 =C2=A0 =C2=A0In addition, the follow= ing terms are used in this document:
>>=C2=A0
>>=C2=A0 =C2=A0 =C2= =A0o=C2=A0 Verified association: is typically defined as an authenticated>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 relationship with a device that initi= ated a call, for example, a
>=C2=A0
> relationship between the call and= the device?

No, the point is that to provide this level of attestat= ion, you need to have a =E2=80=9Cverified=E2=80=9D authentication of the de= vice/user into your network.=C2=A0 Typical example is a cell phone has SIM = authentication, or a SIP digest authentication.=C2=A0 A scenario where you = don=E2=80=99t have an authenticated relationship is if you are a wholesale = provider or transit provider or other scenarios where you are receiving an = unsigned call.

Here too, relationships = are between things. What are the two things.

How about this:

Verified= association: is typically defined as an authenticated=C2=A0relationship be= tween a customer and a device that initiated a call on behalf of that custo= mer, for example, a


-Ekr


>=C2=A0
>=C2=A0
> S 4.
>= ;>=C2=A0
>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 Has a direct authenticated relat= ionship with the initiator of the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ca= ll and can identify the customer associated with the initiator.
>>= =C2=A0>>=C2=A0 =C2=A0 =C2=A0o=C2=A0 Has NOT established a verified associ= ation with the calling party
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 telepho= ne number being used for the call.
>=C2=A0
> For those who aren't; = voice experts, can you give an example of when
> this would happen?
See above answer, i can see if i can integrate that explanation in th= e text, if you think that covers it.

>=C2=A0
>=C2=A0
> S 10.
>&= gt;=C2=A0 =C2=A0 =C2=A0integrity protection and non-repudiation properties = as the base
>>=C2=A0 =C2=A0 =C2=A0claims in the PASSporT.
>&= gt;=C2=A0
>>=C2=A0 10.=C2=A0 Privacy Considerations
>>=C2=A0
>>= =C2=A0 =C2=A0 =C2=A0As detailed in [RFC3261] Section 26, SIP messages inher= ently carry
>=C2=A0
> Thanks for including this section.
>=C2=A0
><= span class=3D"m_-1180960424295807618Apple-converted-space">=C2=A0

--000000000000a25694057b941023-- From nobody Mon Nov 26 08:58:40 2018 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 C0684130F2D for ; Mon, 26 Nov 2018 08:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 Ovs_MS-mYdyq for ; Mon, 26 Nov 2018 08:58:27 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 E307C130F55 for ; Mon, 26 Nov 2018 08:58:24 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id 131so12721120qkd.4 for ; Mon, 26 Nov 2018 08:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=roV/hjGqlidisrzS3Gn2agoq/qokMthwPX1Y4M0JPMo=; b=Rj0ZpP2CutiCcoJr4KUD2bNUYaD0/ZqhAX5psnw25A+dK6On+zQhTcLrXlxFSQxoIf c2OQ4K8dnMK2/BIvH89Je91hc9vRcon8qPBUF323AeLGjVyweqGaY8MdThsWAM3GB9hR bmxnVRYqe7M/nZ+QDChPD0CmLHi5yXG3JNa1iY2ExU0Tb4iK05zLhnsaRD24ilMzsxZf XuUsb9FgWEk5tcqPv6Hm6bIA+8Kzebqjx2b2nj/VEso4owjaJv8Q2yohVz/9NqsdxzCE vKWh1RcMS855aIK7bUI2G4PNNCyh9bXQXPzR83GNPVtXc4U5h00+jTMD2835+06i3QYo Hm5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=roV/hjGqlidisrzS3Gn2agoq/qokMthwPX1Y4M0JPMo=; b=tn1nwUKwpmUtxS0z2TxPBPYOVXiJd4IAM5+Iyac4T4dyDPoTlpw25dVTmgXy8R/IYk +CMmmiUt3O5NMp8rHz8mJniSHehC9qHR8GCVerDP6HFifjJzKJn01ZeH5Bu8fc9dizbM NbZ3NTKhJJtC8xjYthzOm0SuouLJG3txLTaj6EUjK16SxupMc17K107iBtTeoSoYgoXM 3JXLwVQ/2YU6M7zHlKu9mtzyQousHwb7nb2h91Z3EBpUNcD+NFkyGPkKJCtraS8+/YrG UzidZPSn5N0Xx4wVuQm3NG52mhVPYPSCcdTbPMgRVRYgN0WRK8fMiihbPIKMlqbeKFmX AA+Q== X-Gm-Message-State: AA+aEWZpcpXi7WwZ8O/dNcwZRt+/f4bo+NRlWsLfO6G/MqnyuTwY/vUN 0zdhAl1wcmQUsKmF4H3loYH5Rg== X-Google-Smtp-Source: AFSGD/WDwWRkO14AXpYGOYW0MJcNTwMVsKeWz+aHy6oXPU5MM65XG2wo3mzKYy05C/Tr+zEeaxzz2Q== X-Received: by 2002:a37:8b84:: with SMTP id n126mr24808194qkd.355.1543251501812; Mon, 26 Nov 2018 08:58:21 -0800 (PST) Received: from [10.16.48.17] (23.226.128.22.adsl.inet-telecom.org. [23.226.128.22]) by smtp.gmail.com with ESMTPSA id h25sm667800qtc.49.2018.11.26.08.58.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Nov 2018 08:58:21 -0800 (PST) From: Chris Wendt Message-Id: <10E6924F-A736-47E7-B74E-A3F2CCBC8AA3@chriswendt.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_79E6E1C6-9F24-49C8-8D88-37B344CC11FC" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 26 Nov 2018 11:58:19 -0500 In-Reply-To: Cc: IESG , IETF STIR Mail List , Robert Sparks , draft-ietf-stir-passport-shaken@ietf.org, stir-chairs@ietf.org To: Eric Rescorla References: <154249663657.15860.6836719657022356521.idtracker@ietfa.amsl.com> <022A3421-AFF6-4E0F-AEC2-24902B3D12EB@chriswendt.net> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] Eric Rescorla's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 26 Nov 2018 16:58:30 -0000 --Apple-Mail=_79E6E1C6-9F24-49C8-8D88-37B344CC11FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Great, @all will update with a consolidated 06 with all comments = addressed once i get feedback about Ben=E2=80=99s comments from Adam. > On Nov 26, 2018, at 11:45 AM, Eric Rescorla wrote: >=20 > This works. Thanks >=20 > On Mon, Nov 26, 2018 at 8:42 AM Chris Wendt > wrote: > Hi Eric, >=20 > Responses inline. >=20 >> On Nov 20, 2018, at 2:02 PM, Eric Rescorla > wrote: >>=20 >>=20 >>=20 >> On Tue, Nov 20, 2018 at 9:19 AM Chris Wendt = > wrote: >> Hi Eric, >>=20 >> Answers inline. >>=20 >> > On Nov 17, 2018, at 6:17 PM, Eric Rescorla > wrote: >> >=20 >> > Eric Rescorla has entered the following ballot position for >> > draft-ietf-stir-passport-shaken-05: Discuss >> >=20 >> > When responding, please keep the subject line intact and reply to = all >> > email addresses included in the To and CC lines. (Feel free to cut = this >> > introductory paragraph, however.) >> >=20 >> >=20 >> > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = >> > for more information about IESG DISCUSS and COMMENT positions. >> >=20 >> >=20 >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ = >> >=20 >> >=20 >> >=20 >> > = ---------------------------------------------------------------------- >> > DISCUSS: >> > = ---------------------------------------------------------------------- >> >=20 >> > Rich version of this review at: >> > https://mozphab-ietf.devsvcdev.mozaws.net/D5207 = >> >=20 >> >=20 >> > I would like to discuss the privacy properties of origids. As I = read >> > this text, it does not actually require them to be unlinkable or = that >> > it not be possible to determine whether two ids represent the same >> > person behind the origid generator, and I believe it should do so. >> > Practically implementing that may require an ID that is longer than = a >> > UUID. >> >=20 >> >=20 >> > = ---------------------------------------------------------------------- >> > COMMENT: >> > = ---------------------------------------------------------------------- >> >=20 >> >=20 >> >>=20 >> >> This document extends PASSporT, which is a token object that = conveys >> >> cryptographically-signed information about the participants = involved >> >> in communications. The extension is defined, corresponding to = the >> >> SHAKEN specification, to provide both a specific set of = levels-of- >> >> confidence to the correctness of the originating identity for = a SIP >> >=20 >> > Nit: confidence of or confidence in >>=20 >> fixed >>=20 >> >=20 >> >=20 >> >=20 >> >> in communications. The extension is defined, corresponding to = the >> >> SHAKEN specification, to provide both a specific set of = levels-of- >> >> confidence to the correctness of the originating identity for = a SIP >> >> based Communication Service Provider (CSP) telephone network >> >> originated call as well as an identifier that allows the CSP = to >> >> uniquely identify the origination of the call within its = network. >> >=20 >> > Nit: originator >>=20 >> I believe this should be origination, because it=E2=80=99s not = identifying the =E2=80=9Cuser=E2=80=9D or =E2=80=9Caccount=E2=80=9D = it=E2=80=99s identifying either a network element or some network region = or whatever the CSP needs to use to identify where the call came from, = rather than =E2=80=9Cwho=E2=80=9D the call came from. This is for = traceback purposes and to avoid the issue of having unique identifiers = that are specifically associated with users or accounts. >>=20 >> I understand, but origination if a funny term here. Perhaps = "origin=E2=80=9D=20 >=20 > ok, that works, will change that in the document >=20 >>=20 >> >=20 >> >=20 >> > S 1. >> >> need to be accounted for where PASSporT signatures may = represent >> >> either direct or indirect call origination scenarios. The = SHAKEN >> >> [ATIS-1000074] specification defines levels of attestation of = the >> >> origination of the call as well as an origination identifier = that can >> >> help create a unique association with the origination of calls = from >> >> various parts of the VoIP or TDM telephone network. This = document >> >=20 >> > I can't read this. What is the association between? >>=20 >> Similar to above, the concept is that a CSP maps a unique identifier = to a network element or part of a CSP network that would facilitate the = ability to trace the origination of the call. It is defined to be = intentionally abstract to allow for various ways CSP manage their = networks and for example trunk associations to various network elements. >>=20 >> Right, but associations are between things. What are the two things.=20= >=20 > How about this: >=20 > The SHAKEN [ATIS-1000074] specification defines levels of attestation = of the origination of the call as well as an origination identifier that = can help create a unique association between the origin of a particular = call to the point in the VoIP or TDM telephone network the call came = from to identify, for example, either a customer or class of service = that call represents. >=20 >=20 >>=20 >> >=20 >> >=20 >> > S 2. >> >> capitals, as shown here. >> >>=20 >> >> In addition, the following terms are used in this document: >> >>=20 >> >> o Verified association: is typically defined as an = authenticated >> >> relationship with a device that initiated a call, for = example, a >> >=20 >> > relationship between the call and the device? >>=20 >> No, the point is that to provide this level of attestation, you need = to have a =E2=80=9Cverified=E2=80=9D authentication of the device/user = into your network. Typical example is a cell phone has SIM = authentication, or a SIP digest authentication. A scenario where you = don=E2=80=99t have an authenticated relationship is if you are a = wholesale provider or transit provider or other scenarios where you are = receiving an unsigned call. >>=20 >> Here too, relationships are between things. What are the two things. >=20 > How about this: >=20 > Verified association: is typically defined as an authenticated = relationship between a customer and a device that initiated a call on = behalf of that customer, for example, a >=20 >>=20 >> -Ekr >>=20 >>=20 >> >=20 >> >=20 >> > S 4. >> >>=20 >> >> o Has a direct authenticated relationship with the initiator = of the >> >> call and can identify the customer associated with the = initiator. >> >>=20 >> >> o Has NOT established a verified association with the calling = party >> >> telephone number being used for the call. >> >=20 >> > For those who aren't; voice experts, can you give an example of = when >> > this would happen? >>=20 >> See above answer, i can see if i can integrate that explanation in = the text, if you think that covers it. >>=20 >> >=20 >> >=20 >> > S 10. >> >> integrity protection and non-repudiation properties as the = base >> >> claims in the PASSporT. >> >>=20 >> >> 10. Privacy Considerations >> >>=20 >> >> As detailed in [RFC3261] Section 26, SIP messages inherently = carry >> >=20 >> > Thanks for including this section. >> >=20 >> >=20 >=20 --Apple-Mail=_79E6E1C6-9F24-49C8-8D88-37B344CC11FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Great, @all will update with a consolidated 06 with all = comments addressed once i get feedback about Ben=E2=80=99s comments from = Adam.

On Nov 26, 2018, at 11:45 AM, Eric Rescorla = <ekr@rtfm.com> = wrote:

This works. Thanks

On = Mon, Nov 26, 2018 at 8:42 AM Chris Wendt <chris-ietf@chriswendt.net> wrote:
Hi = Eric,

Responses = inline.

On Nov 20, 2018, at 2:02 PM, Eric Rescorla = <ekr@rtfm.com> wrote:



On Tue, Nov 20, 2018 = at 9:19 AM Chris Wendt <chris-ietf@chriswendt.net> wrote:
Hi Eric,

Answers inline.

> On Nov 17, = 2018, at 6:17 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Eric Rescorla has entered the following ballot position = for
> draft-ietf-stir-passport-shaken-05: Discuss
> 
> When responding, please keep the subject line intact and = reply to all
> email addresses included in the To and = CC lines. (Feel free to cut this
> introductory = paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html> for more information about IESG DISCUSS and COMMENT = positions.
> 
> 
> The document, along with other ballot positions, can be = found here:
> https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shake= n/
> 
> 
> 
> = ----------------------------------------------------------------------
> DISCUSS:
> = ----------------------------------------------------------------------
> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D5207
> 
> 
> I would like to discuss the privacy properties of = origids. As I read
> this text, it does not actually = require them to be unlinkable or that
> it not be = possible to determine whether two ids represent the same
> person behind the origid generator, and I believe it = should do so.
> Practically implementing that may = require an ID that is longer than a
> UUID.
> 
> 
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
> 
> 
>> 
>>     This document extends PASSporT, = which is a token object that conveys
>>    =  cryptographically-signed information about the participants = involved
>>     in = communications.  The extension is defined, corresponding to the
>>     SHAKEN specification, to provide = both a specific set of levels-of-
>>    =  confidence to the correctness of the originating identity for a = SIP
> 
> Nit: confidence of or confidence in

fixed

> 
> 
> 
>>     in communications.  The = extension is defined, corresponding to the
>>  =    SHAKEN specification, to provide both a specific set of = levels-of-
>>     confidence to the = correctness of the originating identity for a SIP
>>     based Communication Service = Provider (CSP) telephone network
>>    =  originated call as well as an identifier that allows the CSP to
>>     uniquely identify the origination = of the call within its network.
> 
> Nit: originator

I believe = this should be origination, because it=E2=80=99s not identifying the = =E2=80=9Cuser=E2=80=9D or =E2=80=9Caccount=E2=80=9D it=E2=80=99s = identifying either a network element or some network region or whatever = the CSP needs to use to identify where the call came from, rather than = =E2=80=9Cwho=E2=80=9D the call came from.  This is for traceback = purposes and to avoid the issue of having unique identifiers that are = specifically associated with users or accounts.

I understand, but origination if a funny term here. Perhaps = "origin=E2=80=9D 

ok, that works, will change that in the = document


> 
> 
> S 1.
>>     need to = be accounted for where PASSporT signatures may represent
>>     either direct or indirect call = origination scenarios.  The SHAKEN
>>  =    [ATIS-1000074] specification defines levels of attestation = of the
>>     origination of the call = as well as an origination identifier that can
>> =    help create a unique association with the origination of = calls from
>>     various parts of = the VoIP or TDM telephone network.  This document
> 
> I can't read this. What is the association between?

Similar to above, the concept is that a CSP = maps a unique identifier to a network element or part of a CSP network = that would facilitate the ability to trace the origination of the = call.  It is defined to be intentionally abstract to allow for = various ways CSP manage their networks and for example trunk = associations to various network elements.

Right, but associations = are between things. What are the two things. 

How about this:

The SHAKEN  [ATIS-1000074] = specification defines levels of attestation of the origination of the = call as well as an origination identifier that can help create a unique = association between the origin of a particular call to the point in the = VoIP or TDM telephone network the call came from to identify, for = example, either a customer or class of service that call = represents.



> 
> 
> S 2.
>>     capitals, = as shown here.
>> 
>>     In addition, the following terms = are used in this document:
>> 
>>     o  Verified association: is = typically defined as an authenticated
>>  =       relationship with a device that initiated a call, = for example, a
> 
> relationship between the call and the device?

No, the point is that to provide this level of = attestation, you need to have a =E2=80=9Cverified=E2=80=9D = authentication of the device/user into your network.  Typical = example is a cell phone has SIM authentication, or a SIP digest = authentication.  A scenario where you don=E2=80=99t have an = authenticated relationship is if you are a wholesale provider or transit = provider or other scenarios where you are receiving an unsigned call.

Here too, relationships are between things. What are the two = things.

How about this:

Verified association: is typically = defined as an authenticated relationship between a customer and a = device that initiated a call on behalf of that customer, for example, = a


-Ekr


> 
> 
> S 4.
>> 
>>     o  Has a direct = authenticated relationship with the initiator of the
>>        call and can identify the = customer associated with the initiator.
>> 
>>     o  Has NOT established a = verified association with the calling party
>>  =       telephone number being used for the call.
> 
> For those who aren't; voice experts, can you give an = example of when
> this would happen?

See above answer, i can see if i can integrate that = explanation in the text, if you think that covers it.

> 
> 
> S 10.
>>    =  integrity protection and non-repudiation properties as the base
>>     claims in the PASSporT.
>> 
>>  10.  Privacy Considerations
>> 
>>     As detailed in [RFC3261] Section = 26, SIP messages inherently carry
> 
> Thanks for including this section.
> 
> 


= --Apple-Mail=_79E6E1C6-9F24-49C8-8D88-37B344CC11FC-- From nobody Mon Nov 26 15:51:54 2018 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 C7FAB127332; Mon, 26 Nov 2018 15:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 0j0KCaygnx4u; Mon, 26 Nov 2018 15:51:43 -0800 (PST) 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 4767012DD85; Mon, 26 Nov 2018 15:51:43 -0800 (PST) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAQNpdAd081911 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 26 Nov 2018 17:51:41 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: Chris Wendt , Benjamin Kaduk Cc: stir@ietf.org, STIR Chairs , Robert Sparks , The IESG , draft-ietf-stir-passport-shaken@ietf.org References: <154259095538.2354.17623821529843764623.idtracker@ietfa.amsl.com> <4E6DAD8F-6104-4215-9EE8-3894A99CD81D@chriswendt.net> <20181122013612.GC11132@kduck.kaduk.org> <62F82506-659D-4BC4-8F68-0C306EC804CF@chriswendt.net> From: Adam Roach Message-ID: <08b375fe-7348-32df-c451-54f84f627e87@nostrum.com> Date: Mon, 26 Nov 2018 17:51:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <62F82506-659D-4BC4-8F68-0C306EC804CF@chriswendt.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-passport-shaken-05: (with DISCUSS and COMMENT) 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, 26 Nov 2018 23:51:45 -0000 To keep everyone in the loop -- the ATIS director for SHAKEN Governance has indicated that he will plans to provide us with written permission from an appropriate party to publish draft-ietf-stir-passport-shaken in its current form. /a On 11/26/18 10:42 AM, Chris Wendt wrote: > Ok, will wait for guidance. > > Thanks > >> On Nov 21, 2018, at 8:36 PM, Benjamin Kaduk wrote: >> >> Hi Chris, >> >> On Tue, Nov 20, 2018 at 12:05:55PM -0500, Chris Wendt wrote: >>> Hi Ben, All, >>> >>> Originally in the document, i believe i did have most of this information defined as a reference to the original SHAKEN document. I got working group comments that believed the definitions should be directly in the document themselves versus by reference. >>> >>> I worry about trying to re-write things too much with the potential of causing confusion between the SHAKEN and STIR specs. >> I definitely understand this sentiment. >> >>> I guess i would need higher level guidance on how to proceed with this if there is a concern about this. While I can check with ATIS folks and maybe initiate some "written permission†not sure if that is the best path here or if i really have the legal standing to do that myself in either case. >> I think Adam will be helping to coordinate these efforts, based on our >> discussions on the telechat today. >> >> -Benjamin >> >>> -Chris >>> >>>> On Nov 18, 2018, at 8:29 PM, Benjamin Kaduk wrote: >>>> >>>> Benjamin Kaduk has entered the following ballot position for >>>> draft-ietf-stir-passport-shaken-05: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> A nontrivial amount of text in this document appears to have been taken from >>>> https://access.atis.org/apps/group_public/download.php/32237/ATIS-1000074.pdf >>>> which notes that "No part of this publication may be reproduced in any >>>> form, in an electronic retrieval system or otherwise, without the prior >>>> written permission of the publisher." Do we have prior written permission >>>> to duplicate such text? >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> I am interested in seeing the resolution of discussion on Ekr's Discuss, but >>>> will stick to that thread for such discussion. >>>> >>>> Section 4 >>>> >>>> Am I reading this properly that the difference between 'A' and 'B' is that >>>> in 'B' we don't have any information about the device that's originating >>>> the call, just the identity of the user/customer? >>>> >>>> > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Nov 28 13:17:09 2018 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 1A3FF1274D0 for ; Wed, 28 Nov 2018 13:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 h1TvhorInu7W for ; Wed, 28 Nov 2018 13:17:06 -0800 (PST) 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 2AFD8126DBF for ; Wed, 28 Nov 2018 13:17:06 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wASL5ree044930; Wed, 28 Nov 2018 16:17:05 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 2p22ewgq9j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Nov 2018 16:17:05 -0500 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 wASLH3HG013666; Wed, 28 Nov 2018 16:17:04 -0500 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [135.66.87.42]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id wASLH2bI013585; Wed, 28 Nov 2018 16:17:02 -0500 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [127.0.0.1]) by zlp27129.vci.att.com (Service) with ESMTP id 35CE040397C7; Wed, 28 Nov 2018 21:17:02 +0000 (GMT) Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (unknown [130.9.129.146]) by zlp27129.vci.att.com (Service) with ESMTPS id 2040840397BA; Wed, 28 Nov 2018 21:17:02 +0000 (GMT) Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.11]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0415.000; Wed, 28 Nov 2018 16:17:01 -0500 From: "DOLLY, MARTIN C" To: Robert Sparks , "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt Thread-Index: AQHUamSlSffpoO8nwU6Rt22Mj10L9aUtcv0AgDh1k4A= Date: Wed, 28 Nov 2018 21:17:01 +0000 Message-ID: References: <154025330720.13787.14022156083126853868@ietfa.amsl.com> <66b6b8d3-2d1b-135a-580a-5c0e06d25452@nostrum.com> In-Reply-To: <66b6b8d3-2d1b-135a-580a-5c0e06d25452@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.18.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-28_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811280183 Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt 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, 28 Nov 2018 21:17:08 -0000 Greetings, We had an ATIS- SIP Forum IPNNI meeting today.=20 Several operators performed lab testing with large SIP headers. It was foun= d that some deployed vendor equipment will drop the SIP INVITE if a single = header exceeds a certain length. The IPNNI requests that the option for support of individual Identity heade= rs be added back into draft-ietf-stir-passport-divert, as nesting may resul= t in failures. Thank you for your consideration. Regards, Martin C. Dolly Lead Member of Technical Staff Government & Services Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com -----Original Message----- From: stir On Behalf Of Robert Sparks Sent: Tuesday, October 23, 2018 2:58 PM To: stir@ietf.org Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt We plan to WGLC this document shortly after the Bangkok meeting, but if any= one has any major issues with it, please bring them up now so we can work t= hem out during that meeting. RjS On 10/22/18 7:08 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Secure Telephone Identity Revisited WG o= f the IETF. > > Title : PASSporT Extension for Diverted Calls > Author : Jon Peterson > Filename : draft-ietf-stir-passport-divert-04.txt > Pages : 12 > Date : 2018-10-22 > > Abstract: > This document extends PASSporT, which conveys cryptographically- > signed information about the people involved in personal > communications, to include an indication that a call has been > diverted from its original destination to a new one. This > information can greatly improve the decisions made by verification > services in call forwarding scenarios. Also specified here is an > encapsulation mechanism for nesting a PASSporT within another > PASSporT that assists relying parties in some diversion scenarios. > > > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf. > org_doc_draft-2Dietf-2Dstir-2Dpassport-2Ddivert_&d=3DDwICAg&c=3DLFYZ-o9_H= U > MeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi= 4 > S4U6ZcvMDUXd0&s=3Dkd2Yz4GCgDKOSymv2aLYUADzjR6AWffmnPSXjuYSGZ0&e=3D > > There are also htmlized versions available at: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_ht > ml_draft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=3DDwICAg&c=3DLFYZ-o9_HU= M > eMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4= S > 4U6ZcvMDUXd0&s=3DBToPQIIkMCUzUrB8XhiVCMFNj7SJIh49AImdMcCRp9c&e=3D > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf. > org_doc_html_draft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=3DDwICAg&c=3D= L > FYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7O0= K > lj1GlIEi4S4U6ZcvMDUXd0&s=3DQgOSunMIP4lN49FN75w2hLI2QZMil7jaW-Q4irYBXVA&e > =3D > > A diff from the previous version is available at: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcd > iff-3Furl2-3Ddraft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=3DDwICAg&c=3D= L > FYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7O0= K > lj1GlIEi4S4U6ZcvMDUXd0&s=3D57v9jHegC0yKQjthkptLgxxjK2OgKFmPXEhJFU5Dfpo&e > =3D > > > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. > > Internet-Drafts are also available by anonymous FTP at: > https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_intern > et-2Ddrafts_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG= 0r2 > g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=3DZOq0I6yZGiy_RDG_MUp= - > vzuBiBQrTPd5q48MABiOxBY&e=3D > > _______________________________________________ > stir mailing list > stir@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail > man_listinfo_stir&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmp= w7I > tG0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=3DZen9oBkuiFcBcM= 1 > Mms4FKeVZxxohlxvrDzJ4Dz0HCxw&e=3D _______________________________________________ stir mailing list stir@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_stir&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG= 0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=3DZen9oBkuiFcBcM1Mms= 4FKeVZxxohlxvrDzJ4Dz0HCxw&e=3D From nobody Wed Nov 28 16:11:03 2018 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 E95A91310D3 for ; Wed, 28 Nov 2018 16:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar 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 BoSEWiWAyYTO for ; Wed, 28 Nov 2018 16:10:58 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 1ABAD1277C8 for ; Wed, 28 Nov 2018 16:10:52 -0800 (PST) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wAT038LB027102; Wed, 28 Nov 2018 19:10:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=xn39U69lpj1uVZc22DofMnYNGpgynHXgDAbph5NVpLs=; b=YEsl9gx0vDFeHwTdmZ3v6CSdRsz73Dkmzct5CStiu/XJ9FdcF+O8PNjdjTyJixI3odxQ QVeUYtEHTGz0K7+GRFTc6J4xjTPWLCys9oP/N+Cyy/9ATc9atZzRld2mZbDXg72OUSfQ lh3Wj5tiyCWuHOKNjdWfswNzzpoQVmRBs5hCa9QEh33CVw5WAoxwf/i1M+lizkiQIGEU QmBDuyFEJCoMVKU22DXDJTlJjsGItvt270kH9ivo8yauYdFY+Poiu9wuTsFfWoUKNlnt uPOK7/ab0s+mZf3ZCxm++nKimPE2/vB3a31Ffa+AfwdkWIC0TlMCmqvIuLviXAVdTJx+ FQ== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2ny3uf3aq8-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Nov 2018 19:10:50 -0500 Received: from STNTEXMB101.cis.neustar.com ([fe80::acd4:1667:da41:9938]) by stntexhc10.cis.neustar.com ([10.31.58.69]) with mapi id 14.03.0279.002; Wed, 28 Nov 2018 19:10:49 -0500 From: "Peterson, Jon" To: "DOLLY, MARTIN C" , Robert Sparks , "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt Thread-Index: AQHUamSdaeNCVpDoVU+UEtpxinThwaUtcv0AgDjLc4D//6pxAA== Date: Thu, 29 Nov 2018 00:10:49 +0000 Message-ID: References: <154025330720.13787.14022156083126853868@ietfa.amsl.com> <66b6b8d3-2d1b-135a-580a-5c0e06d25452@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.3.181015 x-originating-ip: [10.96.12.131] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-28_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811280207 Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt 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: Thu, 29 Nov 2018 00:11:02 -0000 DQpQZXJzb25hbGx5LCBJJ20gZmluZSB3aXRoIHB1dHRpbmcgdGhlIG9wdGlvbiBmb3IgaW5kaXZp ZHVhbCBJZGVudGl0eSBoZWFkZXJzIGJhY2sgaW4uIEkndmUgYmVlbiB0cnlpbmcgdG8gZG8gc29t ZSByZXdyaXRlcyBmb3IgY2xhcml0eSBhYm91dCBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlIGFuZCB2 ZXJpZmljYXRpb24gc2VydmljZSBiZWhhdmlvciBmb3IgImRpdiIgYmFzZWQgb24gc29tZSBlYXJs eSBjb21tZW50cywgYW5kIEknbSBzdXJlIHRoZSBvcmlnaW5hbCB0ZXh0IGFib3V0IG5lc3Rpbmcg YW5kIG5vbi1uZXN0aW5nIHdvdWxkIGhhdmUgbmVlZGVkIGEgc2ltaWxhciBwYXRjaGluZyBhbnl3 YXkuDQoNCklkZWFsbHksIGlmIHRoZXJlJ3MgYW55IGZpcm1lciBkYXRhIGZyb20gb3BlcmF0b3Ig bmV0d29ya3MgYWJvdXQgd2hhdCB0aGUgc2NhbGUgb2YgdGhlIHByb2JsZW0gaXMgLSBsaWtlIHdo YXQgc2l6ZSBoZWFkZXJzIGFyZSByZWFsbHkgYSBwcm9ibGVtIC0gdGhhdCB3b3VsZCBiZSBuaWNl IHRvIGtub3cuDQoNCkpvbiBQZXRlcnNvbg0KTmV1c3RhciwgSW5jLg0KDQrvu79PbiAxMS8yOC8x OCwgMToxNyBQTSwgInN0aXIgb24gYmVoYWxmIG9mIERPTExZLCBNQVJUSU4gQyIgPHN0aXItYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWQzMTM1QGF0dC5jb20+IHdyb3RlOg0KDQogICAg R3JlZXRpbmdzLA0KICAgIA0KICAgIFdlIGhhZCBhbiBBVElTLSBTSVAgRm9ydW0gSVBOTkkgbWVl dGluZyB0b2RheS4gDQogICAgU2V2ZXJhbCBvcGVyYXRvcnMgcGVyZm9ybWVkIGxhYiB0ZXN0aW5n IHdpdGggbGFyZ2UgU0lQIGhlYWRlcnMuIEl0IHdhcyBmb3VuZCB0aGF0IHNvbWUgZGVwbG95ZWQg dmVuZG9yIGVxdWlwbWVudCB3aWxsIGRyb3AgdGhlIFNJUCBJTlZJVEUgaWYgYSBzaW5nbGUgaGVh ZGVyIGV4Y2VlZHMgYSBjZXJ0YWluIGxlbmd0aC4NCiAgICANCiAgICBUaGUgSVBOTkkgcmVxdWVz dHMgdGhhdCB0aGUgb3B0aW9uIGZvciBzdXBwb3J0IG9mIGluZGl2aWR1YWwgSWRlbnRpdHkgaGVh ZGVycyBiZSBhZGRlZCBiYWNrIGludG8gZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0LWRpdmVydCwg YXMgbmVzdGluZyBtYXkgcmVzdWx0IGluIGZhaWx1cmVzLg0KICAgIA0KICAgIFRoYW5rIHlvdSBm b3IgeW91ciBjb25zaWRlcmF0aW9uLg0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgDQogICAgTWFy dGluIEMuIERvbGx5DQogICAgTGVhZCBNZW1iZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQogICAgR292 ZXJubWVudCAmIFNlcnZpY2VzIFN0YW5kYXJkcw0KICAgIEFUJlQNCiAgICBDZWxsOiArMS42MDku OTAzLjMzNjANCiAgICBFbWFpbDogbWQzMTM1QGF0dC5jb20NCiAgICANCiAgICANCiAgICANCiAg ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IHN0aXIgPHN0aXItYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFJvYmVydCBTcGFya3MNCiAgICBTZW50OiBUdWVzZGF5 LCBPY3RvYmVyIDIzLCAyMDE4IDI6NTggUE0NCiAgICBUbzogc3RpckBpZXRmLm9yZw0KICAgIFN1 YmplY3Q6IFJlOiBbc3Rpcl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0LWRp dmVydC0wNC50eHQNCiAgICANCiAgICBXZSBwbGFuIHRvIFdHTEMgdGhpcyBkb2N1bWVudCBzaG9y dGx5IGFmdGVyIHRoZSBCYW5na29rIG1lZXRpbmcsIGJ1dCBpZiBhbnlvbmUgaGFzIGFueSBtYWpv ciBpc3N1ZXMgd2l0aCBpdCwgcGxlYXNlIGJyaW5nIHRoZW0gdXAgbm93IHNvIHdlIGNhbiB3b3Jr IHRoZW0gb3V0IGR1cmluZyB0aGF0IG1lZXRpbmcuDQogICAgDQogICAgUmpTDQogICAgDQogICAg DQogICAgT24gMTAvMjIvMTggNzowOCBQTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3Rl Og0KICAgID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KICAgID4gVGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgU2VjdXJlIFRlbGVwaG9uZSBJZGVudGl0eSBSZXZpc2l0ZWQgV0cgb2Yg dGhlIElFVEYuDQogICAgPg0KICAgID4gICAgICAgICAgVGl0bGUgICAgICAgICAgIDogUEFTU3Bv clQgRXh0ZW5zaW9uIGZvciBEaXZlcnRlZCBDYWxscw0KICAgID4gICAgICAgICAgQXV0aG9yICAg ICAgICAgIDogSm9uIFBldGVyc29uDQogICAgPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi1zdGlyLXBhc3Nwb3J0LWRpdmVydC0wNC50eHQNCiAgICA+IAlQYWdlcyAgICAgICAgICAgOiAx Mg0KICAgID4gCURhdGUgICAgICAgICAgICA6IDIwMTgtMTAtMjINCiAgICA+DQogICAgPiBBYnN0 cmFjdDoNCiAgICA+ICAgICBUaGlzIGRvY3VtZW50IGV4dGVuZHMgUEFTU3BvclQsIHdoaWNoIGNv bnZleXMgY3J5cHRvZ3JhcGhpY2FsbHktDQogICAgPiAgICAgc2lnbmVkIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBwZW9wbGUgaW52b2x2ZWQgaW4gcGVyc29uYWwNCiAgICA+ICAgICBjb21tdW5pY2F0 aW9ucywgdG8gaW5jbHVkZSBhbiBpbmRpY2F0aW9uIHRoYXQgYSBjYWxsIGhhcyBiZWVuDQogICAg PiAgICAgZGl2ZXJ0ZWQgZnJvbSBpdHMgb3JpZ2luYWwgZGVzdGluYXRpb24gdG8gYSBuZXcgb25l LiAgVGhpcw0KICAgID4gICAgIGluZm9ybWF0aW9uIGNhbiBncmVhdGx5IGltcHJvdmUgdGhlIGRl Y2lzaW9ucyBtYWRlIGJ5IHZlcmlmaWNhdGlvbg0KICAgID4gICAgIHNlcnZpY2VzIGluIGNhbGwg Zm9yd2FyZGluZyBzY2VuYXJpb3MuICBBbHNvIHNwZWNpZmllZCBoZXJlIGlzIGFuDQogICAgPiAg ICAgZW5jYXBzdWxhdGlvbiBtZWNoYW5pc20gZm9yIG5lc3RpbmcgYSBQQVNTcG9yVCB3aXRoaW4g YW5vdGhlcg0KICAgID4gICAgIFBBU1Nwb3JUIHRoYXQgYXNzaXN0cyByZWx5aW5nIHBhcnRpZXMg aW4gc29tZSBkaXZlcnNpb24gc2NlbmFyaW9zLg0KICAgID4NCiAgICA+DQogICAgPiBUaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICA+IGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNr ZXIuaWV0Zi4NCiAgICA+IG9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEc3Rpci0yRHBhc3Nwb3J0LTJE ZGl2ZXJ0XyZkPUR3SUNBZyZjPUxGWVotbzlfSFUNCiAgICA+IE1lTVRTUWljdmpJZyZyPUc5djh1 Q1NTUWhDbXB3N0l0RzByMmcmbT1yUE1HcTdrdjJCR3VkZmRaaDdPMEtsajFHbElFaTQNCiAgICA+ IFM0VTZaY3ZNRFVYZDAmcz1rZDJZejRHQ2dES09TeW12MmFMWVVBRHpqUjZBV2ZmbW5QU1hqdVlT R1owJmU9DQogICAgPg0KICAgID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZh aWxhYmxlIGF0Og0KICAgID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odA0KICAgID4gbWxfZHJhZnQtMkRpZXRmLTJE c3Rpci0yRHBhc3Nwb3J0LTJEZGl2ZXJ0LTJEMDQmZD1Ed0lDQWcmYz1MRllaLW85X0hVTQ0KICAg ID4gZU1UU1FpY3ZqSWcmcj1HOXY4dUNTU1FoQ21wdzdJdEcwcjJnJm09clBNR3E3a3YyQkd1ZGZk Wmg3TzBLbGoxR2xJRWk0Uw0KICAgID4gNFU2WmN2TURVWGQwJnM9QlRvUFFJSWtNQ1V6VXJCOFho aVZDTUZOajdTSkloNDlBSW1kTWNDUnA5YyZlPQ0KICAgID4gaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLg0KICAgID4g b3JnX2RvY19odG1sX2RyYWZ0LTJEaWV0Zi0yRHN0aXItMkRwYXNzcG9ydC0yRGRpdmVydC0yRDA0 JmQ9RHdJQ0FnJmM9TA0KICAgID4gRllaLW85X0hVTWVNVFNRaWN2aklnJnI9Rzl2OHVDU1NRaENt cHc3SXRHMHIyZyZtPXJQTUdxN2t2MkJHdWRmZFpoN08wSw0KICAgID4gbGoxR2xJRWk0UzRVNlpj dk1EVVhkMCZzPVFnT1N1bk1JUDRsTjQ5Rk43NXcyaExJMlFaTWlsN2phVy1RNGlyWUJYVkEmZQ0K ICAgID4gPQ0KICAgID4NCiAgICA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDoNCiAgICA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX3JmY2QNCiAgICA+IGlmZi0zRnVybDItM0Rk cmFmdC0yRGlldGYtMkRzdGlyLTJEcGFzc3BvcnQtMkRkaXZlcnQtMkQwNCZkPUR3SUNBZyZjPUwN CiAgICA+IEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUc5djh1Q1NTUWhDbXB3N0l0RzByMmcmbT1y UE1HcTdrdjJCR3VkZmRaaDdPMEsNCiAgICA+IGxqMUdsSUVpNFM0VTZaY3ZNRFVYZDAmcz01N3Y5 akhlZ0MweUtRanRoa3B0TGd4eGpLMk9nS0ZtUFhFaEpGVTVEZnBvJmUNCiAgICA+ID0NCiAgICA+ DQogICAgPg0KICAgID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQogICAgPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQog ICAgPg0KICAgID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KICAgID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWZ0cC0zQV9fZnRwLmlldGYub3JnX2ludGVybg0KICAgID4gZXQtMkRkcmFmdHNfJmQ9RHdJ Q0FnJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUc5djh1Q1NTUWhDbXB3N0l0RzByMg0KICAg ID4gZyZtPXJQTUdxN2t2MkJHdWRmZFpoN08wS2xqMUdsSUVpNFM0VTZaY3ZNRFVYZDAmcz1aT3Ew STZ5WkdpeV9SREdfTVVwLQ0KICAgID4gdnp1QmlCUXJUUGQ1cTQ4TUFCaU94QlkmZT0NCiAgICA+ DQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ICAgID4gc3RpciBtYWlsaW5nIGxpc3QNCiAgICA+IHN0aXJAaWV0Zi5vcmcNCiAgICA+IGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWwNCiAgICA+IG1hbl9saXN0aW5mb19zdGlyJmQ9RHdJQ0FnJmM9TEZZWi1vOV9IVU1l TVRTUWljdmpJZyZyPUc5djh1Q1NTUWhDbXB3N0kNCiAgICA+IHRHMHIyZyZtPXJQTUdxN2t2MkJH dWRmZFpoN08wS2xqMUdsSUVpNFM0VTZaY3ZNRFVYZDAmcz1aZW45b0JrdWlGY0JjTTENCiAgICA+ IE1tczRGS2VWWnh4b2hseHZyRHpKNER6MEhDeHcmZT0NCiAgICANCiAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHN0aXIgbWFpbGluZyBsaXN0 DQogICAgc3RpckBpZXRmLm9yZw0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fc3RpciZk PUR3SUNBZyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1HOXY4dUNTU1FoQ21wdzdJdEcwcjJn Jm09clBNR3E3a3YyQkd1ZGZkWmg3TzBLbGoxR2xJRWk0UzRVNlpjdk1EVVhkMCZzPVplbjlvQmt1 aUZjQmNNMU1tczRGS2VWWnh4b2hseHZyRHpKNER6MEhDeHcmZT0NCiAgICANCiAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHN0aXIgbWFpbGlu ZyBsaXN0DQogICAgc3RpckBpZXRmLm9yZw0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f c3RpciZkPUR3SUNBZyZjPU1PcHRObFZ0SUVUZURBTENfbFVMcncmcj1kUTUxdExmb0d1dUZqYW5t ZmVLQzB3ZVhITk1sOXhabm5zSWl3UmQ2SWdZJm09RnZRWUNuYmZFbHE2VmZEc2YzeFZMb3RmRjBM MmdPYXJPMHNkYzF5SlRyZyZzPTVtekZ5dGtXOWZWVDgya0xPVXNPeGR3TXZxUUVpVHBCWUpUbFZG VmQ2bkkmZT0NCiAgICANCg0K From nobody Wed Nov 28 16:19:08 2018 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 C9FF312426E for ; Wed, 28 Nov 2018 16:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 etGf6euvK3Cp for ; Wed, 28 Nov 2018 16:19:05 -0800 (PST) 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 ECFC2130FB1 for ; Wed, 28 Nov 2018 16:19:04 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wAT0F61U030269; Wed, 28 Nov 2018 19:19:04 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 2p24e5shhe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Nov 2018 19:19:04 -0500 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 wAT0J39L024969; Wed, 28 Nov 2018 19:19:03 -0500 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 wAT0J1Tx024932; Wed, 28 Nov 2018 19:19:01 -0500 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id ED122403E4B5; Thu, 29 Nov 2018 00:19:00 +0000 (GMT) Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (unknown [130.9.129.152]) by zlp27126.vci.att.com (Service) with ESMTPS id D4944400039F; Thu, 29 Nov 2018 00:19:00 +0000 (GMT) Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.11]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0415.000; Wed, 28 Nov 2018 19:19:00 -0500 From: "DOLLY, MARTIN C" To: "Peterson, Jon" CC: Robert Sparks , "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt Thread-Index: AQHUamSlSffpoO8nwU6Rt22Mj10L9aUtcv0AgDh1k4CAAIZvgP//rndj Date: Thu, 29 Nov 2018 00:18:59 +0000 Message-ID: References: <154025330720.13787.14022156083126853868@ietfa.amsl.com> <66b6b8d3-2d1b-135a-580a-5c0e06d25452@nostrum.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-28_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811290000 Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt 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: Thu, 29 Nov 2018 00:19:07 -0000 Sm9uDQoNCkZpcnN0LCB0aGFua3MgZm9yIHVuZGVyc3RhbmRpbmcgDQoNClRvIHlvdXIgcXVlc3Rp b24sIGFzIGxvdyBhcyA4MDAsIHdpdGggdGhlIG1ham9yIGlzc3VlIGF0IDEwMDAgb2N0ZXRzDQoN CkJyZWFrIE5EQSBzYXlpbmcgbW9yZQ0KDQpSZWdhcmRzDQoNCk1hcnRpbiBDIERvbGx5DQpBVCZU DQpMZWFkIE1lbWJlciBvZiBUZWNobmljYWwgU3RhZmYNCkdvdmVybm1lbnQgJiBTZXJ2aWNlcyBT dGFuZGFyZHMNCisxIDYwOSA5MDMgMzM2MA0KDQo+IE9uIE5vdiAyOCwgMjAxOCwgYXQgNzoxMCBQ TSwgUGV0ZXJzb24sIEpvbiA8am9uLnBldGVyc29uQHRlYW0ubmV1c3Rhcj4gd3JvdGU6DQo+IA0K PiANCj4gUGVyc29uYWxseSwgSSdtIGZpbmUgd2l0aCBwdXR0aW5nIHRoZSBvcHRpb24gZm9yIGlu ZGl2aWR1YWwgSWRlbnRpdHkgaGVhZGVycyBiYWNrIGluLiBJJ3ZlIGJlZW4gdHJ5aW5nIHRvIGRv IHNvbWUgcmV3cml0ZXMgZm9yIGNsYXJpdHkgYWJvdXQgYXV0aGVudGljYXRpb24gc2VydmljZSBh bmQgdmVyaWZpY2F0aW9uIHNlcnZpY2UgYmVoYXZpb3IgZm9yICJkaXYiIGJhc2VkIG9uIHNvbWUg ZWFybHkgY29tbWVudHMsIGFuZCBJJ20gc3VyZSB0aGUgb3JpZ2luYWwgdGV4dCBhYm91dCBuZXN0 aW5nIGFuZCBub24tbmVzdGluZyB3b3VsZCBoYXZlIG5lZWRlZCBhIHNpbWlsYXIgcGF0Y2hpbmcg YW55d2F5Lg0KPiANCj4gSWRlYWxseSwgaWYgdGhlcmUncyBhbnkgZmlybWVyIGRhdGEgZnJvbSBv cGVyYXRvciBuZXR3b3JrcyBhYm91dCB3aGF0IHRoZSBzY2FsZSBvZiB0aGUgcHJvYmxlbSBpcyAt IGxpa2Ugd2hhdCBzaXplIGhlYWRlcnMgYXJlIHJlYWxseSBhIHByb2JsZW0gLSB0aGF0IHdvdWxk IGJlIG5pY2UgdG8ga25vdy4NCj4gDQo+IEpvbiBQZXRlcnNvbg0KPiBOZXVzdGFyLCBJbmMuDQo+ IA0KPiDvu79PbiAxMS8yOC8xOCwgMToxNyBQTSwgInN0aXIgb24gYmVoYWxmIG9mIERPTExZLCBN QVJUSU4gQyIgPHN0aXItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWQzMTM1QGF0dC5j b20+IHdyb3RlOg0KPiANCj4gICAgR3JlZXRpbmdzLA0KPiANCj4gICAgV2UgaGFkIGFuIEFUSVMt IFNJUCBGb3J1bSBJUE5OSSBtZWV0aW5nIHRvZGF5LiANCj4gICAgU2V2ZXJhbCBvcGVyYXRvcnMg cGVyZm9ybWVkIGxhYiB0ZXN0aW5nIHdpdGggbGFyZ2UgU0lQIGhlYWRlcnMuIEl0IHdhcyBmb3Vu ZCB0aGF0IHNvbWUgZGVwbG95ZWQgdmVuZG9yIGVxdWlwbWVudCB3aWxsIGRyb3AgdGhlIFNJUCBJ TlZJVEUgaWYgYSBzaW5nbGUgaGVhZGVyIGV4Y2VlZHMgYSBjZXJ0YWluIGxlbmd0aC4NCj4gDQo+ ICAgIFRoZSBJUE5OSSByZXF1ZXN0cyB0aGF0IHRoZSBvcHRpb24gZm9yIHN1cHBvcnQgb2YgaW5k aXZpZHVhbCBJZGVudGl0eSBoZWFkZXJzIGJlIGFkZGVkIGJhY2sgaW50byBkcmFmdC1pZXRmLXN0 aXItcGFzc3BvcnQtZGl2ZXJ0LCBhcyBuZXN0aW5nIG1heSByZXN1bHQgaW4gZmFpbHVyZXMuDQo+ IA0KPiAgICBUaGFuayB5b3UgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4NCj4gDQo+ICAgIFJlZ2Fy ZHMsDQo+IA0KPiAgICBNYXJ0aW4gQy4gRG9sbHkNCj4gICAgTGVhZCBNZW1iZXIgb2YgVGVjaG5p Y2FsIFN0YWZmDQo+ICAgIEdvdmVybm1lbnQgJiBTZXJ2aWNlcyBTdGFuZGFyZHMNCj4gICAgQVQm VA0KPiAgICBDZWxsOiArMS42MDkuOTAzLjMzNjANCj4gICAgRW1haWw6IG1kMzEzNUBhdHQuY29t DQo+IA0KPiANCj4gDQo+ICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgIEZyb206 IHN0aXIgPHN0aXItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFJvYmVydCBTcGFya3MN Cj4gICAgU2VudDogVHVlc2RheSwgT2N0b2JlciAyMywgMjAxOCAyOjU4IFBNDQo+ICAgIFRvOiBz dGlyQGlldGYub3JnDQo+ICAgIFN1YmplY3Q6IFJlOiBbc3Rpcl0gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1zdGlyLXBhc3Nwb3J0LWRpdmVydC0wNC50eHQNCj4gDQo+ICAgIFdlIHBsYW4gdG8gV0dM QyB0aGlzIGRvY3VtZW50IHNob3J0bHkgYWZ0ZXIgdGhlIEJhbmdrb2sgbWVldGluZywgYnV0IGlm IGFueW9uZSBoYXMgYW55IG1ham9yIGlzc3VlcyB3aXRoIGl0LCBwbGVhc2UgYnJpbmcgdGhlbSB1 cCBub3cgc28gd2UgY2FuIHdvcmsgdGhlbSBvdXQgZHVyaW5nIHRoYXQgbWVldGluZy4NCj4gDQo+ ICAgIFJqUw0KPiANCj4gDQo+PiAgICBPbiAxMC8yMi8xOCA3OjA4IFBNLCBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgd3JvdGU6DQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+PiBUaGlzIGRy YWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTZWN1cmUgVGVsZXBob25lIElkZW50aXR5IFJldmlz aXRlZCBXRyBvZiB0aGUgSUVURi4NCj4+IA0KPj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBQ QVNTcG9yVCBFeHRlbnNpb24gZm9yIERpdmVydGVkIENhbGxzDQo+PiAgICAgICAgIEF1dGhvciAg ICAgICAgICA6IEpvbiBQZXRlcnNvbg0KPj4gICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi1zdGlyLXBhc3Nwb3J0LWRpdmVydC0wNC50eHQNCj4+ICAgIFBhZ2VzICAgICAgICAgICA6IDEy DQo+PiAgICBEYXRlICAgICAgICAgICAgOiAyMDE4LTEwLTIyDQo+PiANCj4+IEFic3RyYWN0Og0K Pj4gICAgVGhpcyBkb2N1bWVudCBleHRlbmRzIFBBU1Nwb3JULCB3aGljaCBjb252ZXlzIGNyeXB0 b2dyYXBoaWNhbGx5LQ0KPj4gICAgc2lnbmVkIGluZm9ybWF0aW9uIGFib3V0IHRoZSBwZW9wbGUg aW52b2x2ZWQgaW4gcGVyc29uYWwNCj4+ICAgIGNvbW11bmljYXRpb25zLCB0byBpbmNsdWRlIGFu IGluZGljYXRpb24gdGhhdCBhIGNhbGwgaGFzIGJlZW4NCj4+ICAgIGRpdmVydGVkIGZyb20gaXRz IG9yaWdpbmFsIGRlc3RpbmF0aW9uIHRvIGEgbmV3IG9uZS4gIFRoaXMNCj4+ICAgIGluZm9ybWF0 aW9uIGNhbiBncmVhdGx5IGltcHJvdmUgdGhlIGRlY2lzaW9ucyBtYWRlIGJ5IHZlcmlmaWNhdGlv bg0KPj4gICAgc2VydmljZXMgaW4gY2FsbCBmb3J3YXJkaW5nIHNjZW5hcmlvcy4gIEFsc28gc3Bl Y2lmaWVkIGhlcmUgaXMgYW4NCj4+ICAgIGVuY2Fwc3VsYXRpb24gbWVjaGFuaXNtIGZvciBuZXN0 aW5nIGEgUEFTU3BvclQgd2l0aGluIGFub3RoZXINCj4+ICAgIFBBU1Nwb3JUIHRoYXQgYXNzaXN0 cyByZWx5aW5nIHBhcnRpZXMgaW4gc29tZSBkaXZlcnNpb24gc2NlbmFyaW9zLg0KPj4gDQo+PiAN Cj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19k YXRhdHJhY2tlci5pZXRmLg0KPj4gb3JnX2RvY19kcmFmdC0yRGlldGYtMkRzdGlyLTJEcGFzc3Bv cnQtMkRkaXZlcnRfJmQ9RHdJQ0FnJmM9TEZZWi1vOV9IVQ0KPj4gTWVNVFNRaWN2aklnJnI9Rzl2 OHVDU1NRaENtcHc3SXRHMHIyZyZtPXJQTUdxN2t2MkJHdWRmZFpoN08wS2xqMUdsSUVpNA0KPj4g UzRVNlpjdk1EVVhkMCZzPWtkMll6NEdDZ0RLT1N5bXYyYUxZVUFEempSNkFXZmZtblBTWGp1WVNH WjAmZT0NCj4+IA0KPj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxl IGF0Og0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX190b29scy5pZXRmLm9yZ19odA0KPj4gbWxfZHJhZnQtMkRpZXRmLTJEc3Rpci0yRHBhc3Nw b3J0LTJEZGl2ZXJ0LTJEMDQmZD1Ed0lDQWcmYz1MRllaLW85X0hVTQ0KPj4gZU1UU1FpY3ZqSWcm cj1HOXY4dUNTU1FoQ21wdzdJdEcwcjJnJm09clBNR3E3a3YyQkd1ZGZkWmg3TzBLbGoxR2xJRWk0 Uw0KPj4gNFU2WmN2TURVWGQwJnM9QlRvUFFJSWtNQ1V6VXJCOFhoaVZDTUZOajdTSkloNDlBSW1k TWNDUnA5YyZlPQ0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLg0KPj4gb3JnX2RvY19odG1sX2RyYWZ0LTJEaWV0 Zi0yRHN0aXItMkRwYXNzcG9ydC0yRGRpdmVydC0yRDA0JmQ9RHdJQ0FnJmM9TA0KPj4gRllaLW85 X0hVTWVNVFNRaWN2aklnJnI9Rzl2OHVDU1NRaENtcHc3SXRHMHIyZyZtPXJQTUdxN2t2MkJHdWRm ZFpoN08wSw0KPj4gbGoxR2xJRWk0UzRVNlpjdk1EVVhkMCZzPVFnT1N1bk1JUDRsTjQ5Rk43NXcy aExJMlFaTWlsN2phVy1RNGlyWUJYVkEmZQ0KPj4gPQ0KPj4gDQo+PiBBIGRpZmYgZnJvbSB0aGUg cHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+PiBodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19yZmNkDQo+PiBp ZmYtM0Z1cmwyLTNEZHJhZnQtMkRpZXRmLTJEc3Rpci0yRHBhc3Nwb3J0LTJEZGl2ZXJ0LTJEMDQm ZD1Ed0lDQWcmYz1MDQo+PiBGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1HOXY4dUNTU1FoQ21wdzdJ dEcwcjJnJm09clBNR3E3a3YyQkd1ZGZkWmg3TzBLDQo+PiBsajFHbElFaTRTNFU2WmN2TURVWGQw JnM9NTd2OWpIZWdDMHlLUWp0aGtwdExneHhqSzJPZ0tGbVBYRWhKRlU1RGZwbyZlDQo+PiA9DQo+ PiANCj4+IA0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+PiANCj4+ IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN Cj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1mdHAtM0FfX2Z0 cC5pZXRmLm9yZ19pbnRlcm4NCj4+IGV0LTJEZHJhZnRzXyZkPUR3SUNBZyZjPUxGWVotbzlfSFVN ZU1UU1FpY3ZqSWcmcj1HOXY4dUNTU1FoQ21wdzdJdEcwcjINCj4+IGcmbT1yUE1HcTdrdjJCR3Vk ZmRaaDdPMEtsajFHbElFaTRTNFU2WmN2TURVWGQwJnM9Wk9xMEk2eVpHaXlfUkRHX01VcC0NCj4+ IHZ6dUJpQlFyVFBkNXE0OE1BQmlPeEJZJmU9DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzdGlyIG1haWxpbmcgbGlzdA0KPj4gc3Rp ckBpZXRmLm9yZw0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbA0KPj4gbWFuX2xpc3RpbmZvX3N0aXImZD1Ed0lD QWcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9Rzl2OHVDU1NRaENtcHc3SQ0KPj4gdEcwcjJn Jm09clBNR3E3a3YyQkd1ZGZkWmg3TzBLbGoxR2xJRWk0UzRVNlpjdk1EVVhkMCZzPVplbjlvQmt1 aUZjQmNNMQ0KPj4gTW1zNEZLZVZaeHhvaGx4dnJEeko0RHowSEN4dyZlPQ0KPiANCj4gICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgc3RpciBt YWlsaW5nIGxpc3QNCj4gICAgc3RpckBpZXRmLm9yZw0KPiAgICBodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX3N0aXImZD1Ed0lDQWcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9Rzl2OHVDU1NR aENtcHc3SXRHMHIyZyZtPXJQTUdxN2t2MkJHdWRmZFpoN08wS2xqMUdsSUVpNFM0VTZaY3ZNRFVY ZDAmcz1aZW45b0JrdWlGY0JjTTFNbXM0RktlVlp4eG9obHh2ckR6SjREejBIQ3h3JmU9DQo+IA0K PiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAg ICBzdGlyIG1haWxpbmcgbGlzdA0KPiAgICBzdGlyQGlldGYub3JnDQo+ICAgIGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9fc3RpciZkPUR3SUNBZyZjPU1PcHRObFZ0SUVUZURBTENfbFVMcncmcj1k UTUxdExmb0d1dUZqYW5tZmVLQzB3ZVhITk1sOXhabm5zSWl3UmQ2SWdZJm09RnZRWUNuYmZFbHE2 VmZEc2YzeFZMb3RmRjBMMmdPYXJPMHNkYzF5SlRyZyZzPTVtekZ5dGtXOWZWVDgya0xPVXNPeGR3 TXZxUUVpVHBCWUpUbFZGVmQ2bkkmZT0NCj4gDQo+IA0K From nobody Wed Nov 28 16:45:22 2018 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 D1D1C130E25 for ; Wed, 28 Nov 2018 16:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 iyFgDtilyO74 for ; Wed, 28 Nov 2018 16:45:16 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 31DC4130DD7 for ; Wed, 28 Nov 2018 16:45:16 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id r71so99222qkr.10 for ; Wed, 28 Nov 2018 16:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yuoWUrm8GnhS6xx9s+/nZJ6lPlJHnWeJyrH+fnEX5cI=; b=1Djp+fuP0xLq0l9w3P8z2QOVHK6fb8qVxRsfBgS7noaO0ZX7IRjZzGKmj6ypETVu11 EKUP3qABezfPqgRG+JpiCbtLcItMQkcss6dQruakVzb8myQ6iK9kOqaE7rJqV8s+l6Bf 0OHawJrQi2+W8Es42iBVGkY3lMXdAhWlZpl2beEPXGwFxHPjij04U8TrWC9eJtN26YOc hWrpOHbVjmW7YK5ZFCI5FJFVvOaRwr6nzXZ6A9NI3tfCiPkMMr+uoSYjmThFlNnDEuUl yEpDtaTSSpVTcji4tNhsNsgBaeUPN7oRTiUDFCBZBlAOqrqdiLlrSJvv12IEd9wXXZWE V/ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yuoWUrm8GnhS6xx9s+/nZJ6lPlJHnWeJyrH+fnEX5cI=; b=SsdY7GEQ/1PXqgUm5vzrzsM/anstrGXcNMI1ixfd1P1aUY+MVZKMGtj08LJGzHa3jW wG4TnX2Zby0mX8sdiZMRjlfYNyBLfrob0xximqoSdKdqUYPsWm3DjSfAgSW+0QrFzrxg ihF3fZZcNoxLGeIfr/B6haSTA/gL6OsW0+9I/U9840oVZkFoivMwzw05uH/kiloqGMzi zH1TwXa4lNpImLpD+MumdbOCLf46cBO4sMyV5jAGHAJmLTlVhkUHXfcBrIUDEbd/w6ye U/1dYeKJlryfmk56ABaQGcOnA75prcETJIvhcJttO9dNVsrO6nKdCRBLnfuGc6yGDDzk TjfA== X-Gm-Message-State: AA+aEWZNJm6z/2wcCZU9LDY7r/PY6ftM7W0S/PSixWmKr/U9iY+7LwJW mwtdMrCqIM8M032gitzUFMrLQw== X-Google-Smtp-Source: AFSGD/XPny/I+Z8MRF/xTV02dVybQ+BkrYT3ZyF8RRDanSDU1EeHxxLHRrx/7CqsluCa/RqPEiboDA== X-Received: by 2002:a37:a09:: with SMTP id 9mr35975706qkk.339.1543452315188; Wed, 28 Nov 2018 16:45:15 -0800 (PST) Received: from [10.16.48.3] (23.226.128.22.adsl.inet-telecom.org. [23.226.128.22]) by smtp.gmail.com with ESMTPSA id p3sm214231qkp.48.2018.11.28.16.45.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 16:45:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: Date: Wed, 28 Nov 2018 19:45:13 -0500 Cc: "Peterson, Jon" , "stir@ietf.org" , Robert Sparks Content-Transfer-Encoding: quoted-printable Message-Id: <9D4258CD-6D8E-489E-BE99-A27353F8B069@chriswendt.net> References: <154025330720.13787.14022156083126853868@ietfa.amsl.com> <66b6b8d3-2d1b-135a-580a-5c0e06d25452@nostrum.com> To: Martin C Dolly X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt 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: Thu, 29 Nov 2018 00:45:19 -0000 We also have equipment in the network that also has same behavior. If = the equipment just truncated or just passed the INVITE through, it would = be fine, but given there is equipment that basically just drops calls, = and wrong or right, it does seem to be a prevalent behavior, keeping the = multiple identity header option for div would be the only pragmatic = option.=20 -Chris > On Nov 28, 2018, at 7:18 PM, DOLLY, MARTIN C wrote: >=20 > Jon >=20 > First, thanks for understanding=20 >=20 > To your question, as low as 800, with the major issue at 1000 octets >=20 > Break NDA saying more >=20 > Regards >=20 > Martin C Dolly > AT&T > Lead Member of Technical Staff > Government & Services Standards > +1 609 903 3360 >=20 >> On Nov 28, 2018, at 7:10 PM, Peterson, Jon = wrote: >>=20 >>=20 >> Personally, I'm fine with putting the option for individual Identity = headers back in. I've been trying to do some rewrites for clarity about = authentication service and verification service behavior for "div" based = on some early comments, and I'm sure the original text about nesting and = non-nesting would have needed a similar patching anyway. >>=20 >> Ideally, if there's any firmer data from operator networks about what = the scale of the problem is - like what size headers are really a = problem - that would be nice to know. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> =EF=BB=BFOn 11/28/18, 1:17 PM, "stir on behalf of DOLLY, MARTIN C" = wrote: >>=20 >> Greetings, >>=20 >> We had an ATIS- SIP Forum IPNNI meeting today.=20 >> Several operators performed lab testing with large SIP headers. It = was found that some deployed vendor equipment will drop the SIP INVITE = if a single header exceeds a certain length. >>=20 >> The IPNNI requests that the option for support of individual = Identity headers be added back into draft-ietf-stir-passport-divert, as = nesting may result in failures. >>=20 >> Thank you for your consideration. >>=20 >> Regards, >>=20 >> Martin C. Dolly >> Lead Member of Technical Staff >> Government & Services Standards >> AT&T >> Cell: +1.609.903.3360 >> Email: md3135@att.com >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir On Behalf Of Robert Sparks >> Sent: Tuesday, October 23, 2018 2:58 PM >> To: stir@ietf.org >> Subject: Re: [stir] I-D Action: = draft-ietf-stir-passport-divert-04.txt >>=20 >> We plan to WGLC this document shortly after the Bangkok meeting, = but if anyone has any major issues with it, please bring them up now so = we can work them out during that meeting. >>=20 >> RjS >>=20 >>=20 >>> On 10/22/18 7:08 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Secure Telephone Identity Revisited = WG of the IETF. >>>=20 >>> Title : PASSporT Extension for Diverted Calls >>> Author : Jon Peterson >>> Filename : draft-ietf-stir-passport-divert-04.txt >>> Pages : 12 >>> Date : 2018-10-22 >>>=20 >>> Abstract: >>> This document extends PASSporT, which conveys cryptographically- >>> signed information about the people involved in personal >>> communications, to include an indication that a call has been >>> diverted from its original destination to a new one. This >>> information can greatly improve the decisions made by verification >>> services in call forwarding scenarios. Also specified here is an >>> encapsulation mechanism for nesting a PASSporT within another >>> PASSporT that assists relying parties in some diversion scenarios. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf. >>> = org_doc_draft-2Dietf-2Dstir-2Dpassport-2Ddivert_&d=3DDwICAg&c=3DLFYZ-o9_HU= >>> = MeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4= >>> S4U6ZcvMDUXd0&s=3Dkd2Yz4GCgDKOSymv2aLYUADzjR6AWffmnPSXjuYSGZ0&e=3D >>>=20 >>> There are also htmlized versions available at: >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_ht >>> = ml_draft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=3DDwICAg&c=3DLFYZ-o9_HUM= >>> = eMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4S= >>> 4U6ZcvMDUXd0&s=3DBToPQIIkMCUzUrB8XhiVCMFNj7SJIh49AImdMcCRp9c&e=3D >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf. >>> = org_doc_html_draft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=3DDwICAg&c=3DL= >>> = FYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7O0K= >>> = lj1GlIEi4S4U6ZcvMDUXd0&s=3DQgOSunMIP4lN49FN75w2hLI2QZMil7jaW-Q4irYBXVA&e >>> =3D >>>=20 >>> A diff from the previous version is available at: >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcd >>> = iff-3Furl2-3Ddraft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=3DDwICAg&c=3DL= >>> = FYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7O0K= >>> = lj1GlIEi4S4U6ZcvMDUXd0&s=3D57v9jHegC0yKQjthkptLgxxjK2OgKFmPXEhJFU5Dfpo&e >>> =3D >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of=20 >>> submission until the htmlized version and diff are available at = tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> = https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_intern >>> = et-2Ddrafts_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0= r2 >>> = g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=3DZOq0I6yZGiy_RDG_MUp-= >>> vzuBiBQrTPd5q48MABiOxBY&e=3D >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail >>> = man_listinfo_stir&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw= 7I >>> = tG0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=3DZen9oBkuiFcBcM1= >>> Mms4FKeVZxxohlxvrDzJ4Dz0HCxw&e=3D >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_stir&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7I= tG0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=3DZen9oBkuiFcBcM1= Mms4FKeVZxxohlxvrDzJ4Dz0HCxw&e=3D >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_stir&d=3DDwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3DdQ51tLfoGuuFjanm= feKC0weXHNMl9xZnnsIiwRd6IgY&m=3DFvQYCnbfElq6VfDsf3xVLotfF0L2gOarO0sdc1yJTr= g&s=3D5mzFytkW9fVT82kLOUsOxdwMvqQEiTpBYJTlVFVd6nI&e=3D >>=20 >>=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Nov 28 18:32:10 2018 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 A66A7130DC1 for ; Wed, 28 Nov 2018 18:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (768-bit key) reason="fail (body has been altered)" header.d=shockey.us 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 YRAwytSHiszp for ; Wed, 28 Nov 2018 18:32:06 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 4A150130DCC for ; Wed, 28 Nov 2018 18:32:05 -0800 (PST) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id D1265421AF for ; Wed, 28 Nov 2018 19:27:16 -0700 (MST) Received: from box462.bluehost.com ([74.220.219.62]) by cmsmtp with ESMTP id SC2ugQwkKqZYcSC2ugcSNW; Wed, 28 Nov 2018 19:27:16 -0700 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=lZrgwUwLX8RFU8iZITxCORAz7JwXy6I0euxb2TVwxIo=; b=K4iKxWSRXGxcgUFX0KUvdr1J9V 3tw4VuNILZNZMMoU8PoO7oijx24T63ofFwzJuSx67ZGGSmYQk9FNM9m34eIeX8IZb791SJjI2JvT0 rbBm0A9xzrtJMUzKjYydqppVB; Received: from pool-100-36-47-17.washdc.fios.verizon.net ([100.36.47.17]:65365 helo=[192.168.1.156]) by box462.bluehost.com with esmtpa (Exim 4.91) (envelope-from ) id 1gSC2t-001A3i-U8; Wed, 28 Nov 2018 19:27:16 -0700 User-Agent: Microsoft-MacOutlook/10.13.0.181109 Date: Wed, 28 Nov 2018 21:27:13 -0500 From: Richard Shockey To: Chris Wendt , Martin C Dolly CC: "Peterson, Jon" , Robert Sparks , "stir@ietf.org" Message-ID: <4250EED5-6EF1-4472-8A17-7F89158F3439@shockey.us> Thread-Topic: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt References: <154025330720.13787.14022156083126853868@ietfa.amsl.com> <66b6b8d3-2d1b-135a-580a-5c0e06d25452@nostrum.com> <9D4258CD-6D8E-489E-BE99-A27353F8B069@chriswendt.net> In-Reply-To: <9D4258CD-6D8E-489E-BE99-A27353F8B069@chriswendt.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.47.17 X-Source-L: No X-Exim-ID: 1gSC2t-001A3i-U8 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-47-17.washdc.fios.verizon.net ([192.168.1.156]) [100.36.47.17]:65365 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt 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: Thu, 29 Nov 2018 02:32:08 -0000 +1 I totally support the position that Martin and Chris are advocating. =20 I might add that some of us are looking at formal legal protection for meth= ods for Call Authentication aka STIR/SHAKEN headers to prevent either inadve= rtent or malicious alteration. Some of you vendors should take note.=20 We are looking at extending sections of US 47 CFR 64.1601. CFR is the Code= of Federal Regulations. =20 Other national jurisdictions may want to take a look at this. Film at 11. = =20 =C2=A764.1601 Delivery requirements and privacy restrictions. (a) Delivery. Except as provided in paragraphs (d) and (e) of this section: =20 (1) Telecommunications carriers and providers of interconnected Voice over = Internet Protocol (VoIP) services, in originating interstate or intrastate t= raffic on the public switched telephone network (PSTN) or originating inters= tate or intrastate traffic that is destined for the PSTN (collectively =E2=80=9CPS= TN Traffic=E2=80=9D), are required to transmit for all PSTN Traffic the telephone = number received from or assigned to or otherwise associated with the calling= party to the next provider in the path from the originating provider to the= terminating provider. This provision applies regardless of the voice call s= ignaling and transmission technology used by the carrier or VoIP provider. E= ntities subject to this provision that use Signaling System 7 (SS7) are requ= ired to transmit the calling party number (CPN) associated with all PSTN Tra= ffic in the SS7 ISUP (ISDN User Part) CPN field to interconnecting providers= , and are required to transmit the calling party's charge number (CN) in the= SS7 ISUP CN field to interconnecting providers for any PSTN Traffic where C= N differs from CPN. Entities subject to this provision who use multi-frequen= cy (MF) signaling are required to transmit CPN, or CN if it differs from CPN= , associated with all PSTN Traffic in the MF signaling automatic numbering i= nformation (ANI) field. =20 (2) Intermediate providers within an interstate or intrastate call path tha= t originates and/or terminates on the PSTN must pass unaltered to subsequent= providers in the call path signaling information identifying the telephone = number, or billing number, if different, of the calling party that is receiv= ed with a call. This requirement applies to SS7 information including but no= t limited to CPN and CN, and also applies to MF signaling information or oth= er signaling information intermediate providers receive with a call. This re= quirement also applies to VoIP signaling messages, such as calling party and= charge information identifiers contained in Session Initiation Protocol (SI= P) header fields, and to equivalent identifying information as used in other= VoIP signaling technologies, regardless of the voice call signaling and tra= nsmission technology used by the carrier or VoIP provider. =20 (b) Privacy. Except as provided in paragraph (d) of this section, originati= ng carriers using Signaling System 7 and offering or subscribing to any serv= ice based on Signaling System 7 functionality will recognize *67 dialed as t= he first three digits of a call (or 1167 for rotary or pulse dialing phones)= as a caller's request that the CPN not be passed on an interstate call. Suc= h carriers providing line blocking services will recognize *82 as a caller's= request that the CPN be passed on an interstate call. No common carrier sub= scribing to or offering any service that delivers CPN may override the priva= cy indicator associated with an interstate call. Carriers must arrange their= CPN-based services, and billing practices, in such a manner that when a cal= ler requests that the CPN not be passed, a carrier may not reveal that calle= r's number or name, nor may the carrier use the number or name to allow the = called party to contact the calling party. The terminating carrier must act = in accordance with the privacy indicator unless the call is made to a called= party that subscribes to an ANI or charge number based service and the call= is paid for by the called party. =20 (c) Charges. No common carrier subscribing to or offering any service that = delivers calling party number may =20 (1) Impose on the calling party charges associated with per call blocking o= f the calling party's telephone number, or =20 (2) Impose charges upon connecting carriers for the delivery of the calling= party number parameter or its associated privacy indicator. =20 (d) Exemptions. Section 64.1601(a) and (b) shall not apply when: =20 (1) A call originates from a payphone. =20 (2) A local exchange carrier with Signaling System 7 capability does not ha= ve the software to provide *67 or *82 functionalities. Such carriers are pro= hibited from passing CPN. =20 (3) A Private Branch Exchange or Centrex system does not pass end user CPN.= Centrex systems that rely on *6 or *8 for a function other than CPN blockin= g or unblocking, respectively, are also exempt if they employ alternative me= ans of blocking or unblocking. =20 (4) CPN delivery=E2=80=94 =20 (i) Is used solely in connection with calls within the same limited system,= including (but not limited to) a Centrex system, virtual private network, o= r Private Branch Exchange; =20 (ii) Is used on a public agency's emergency telephone line or in conjunctio= n with 911 emergency services, on a telephone line to contact non-public eme= rgency services licensed by the state or municipality, or on any entity's em= ergency assistance poison control telephone line; or =20 (iii) Is provided in connection with legally authorized call tracing or tra= pping procedures specifically requested by a law enforcement agency. =20 (e) Any person or entity that engages in telemarketing, as defined in secti= on 64.1200(f)(10) must transmit caller identification information. =20 (1) For purposes of this paragraph, caller identification information must = include either CPN or ANI, and, when available by the telemarketer's carrier= , the name of the telemarketer. It shall not be a violation of this paragrap= h to substitute (for the name and phone number used in, or billed for, makin= g the call) the name of the seller on behalf of which the telemarketing call= is placed and the seller's customer service telephone number. The telephone= number so provided must permit any individual to make a do-not-call request= during regular business hours. =20 (2) Any person or entity that engages in telemarketing is prohibited from b= locking the transmission of caller identification information. =20 (3) Tax-exempt nonprofit organizations are not required to comply with this= paragraph. =20 (f) Paragraph (b) of this section shall not apply when CPN delivery is made= in connection with a threatening call. Upon report of such a threatening ca= ll by law enforcement on behalf of the threatened party, the carrier will pr= ovide any CPN of the calling party to law enforcement and, as directed by la= w enforcement, to security personnel for the called party for the purpose of= identifying the party responsible for the threatening call. =20 (g) For law enforcement or security personnel of the called party investiga= ting the threat: =20 (1) The CPN on incoming restricted calls may not be passed on to the line c= alled; =20 (2) Any system used to record CPN must be operated in a secure way, limitin= g access to designated telecommunications and security personnel, as directe= d by law enforcement; =20 (3) Telecommunications and security personnel, as directed by law enforceme= nt, may access restricted CPN data only when investigating phone calls of a = threatening and serious nature, and shall document that access as part of th= e investigative report; =20 (4) Carriers transmitting restricted CPN information must take reasonable m= easures to ensure security of such communications; =20 (5) CPN information must be destroyed in a secure manner after a reasonable= retention period; and =20 (6) Any violation of these conditions must be reported promptly to the Comm= ission. =20 [60 FR 29490, June 5, 1995; 60 FR 54449, Oct. 24, 1995, as amended at 62 FR= 34015, June 24, 1997; 68 FR 44179, July 25, 2003; 71 FR 75122, Dec. 14, 200= 6; 76 FR 73882, Nov. 29, 2011; 82 FR 56917, Dec. 1, 2017] =20 Effective Date Note: At 82 FR 56917, Dec. 1, 2017, =C2=A764.1601 was amended by= revising paragraphs (d)(4)(ii) and adding paragraph (f). These paragraphs c= ontain information collection and recordkeeping requirements and will not be= come effective until approval has been given by the Office of Management and= Budget. =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 =EF=BB=BFOn 11/28/18, 7:45 PM, "stir on behalf of Chris Wendt" wrote: We also have equipment in the network that also has same behavior. If t= he equipment just truncated or just passed the INVITE through, it would be f= ine, but given there is equipment that basically just drops calls, and wrong= or right, it does seem to be a prevalent behavior, keeping the multiple ide= ntity header option for div would be the only pragmatic option.=20 =20 -Chris =20 > On Nov 28, 2018, at 7:18 PM, DOLLY, MARTIN C wrote: >=20 > Jon >=20 > First, thanks for understanding=20 >=20 > To your question, as low as 800, with the major issue at 1000 octets >=20 > Break NDA saying more >=20 > Regards >=20 > Martin C Dolly > AT&T > Lead Member of Technical Staff > Government & Services Standards > +1 609 903 3360 >=20 >> On Nov 28, 2018, at 7:10 PM, Peterson, Jon wrote: >>=20 >>=20 >> Personally, I'm fine with putting the option for individual Identity= headers back in. I've been trying to do some rewrites for clarity about aut= hentication service and verification service behavior for "div" based on som= e early comments, and I'm sure the original text about nesting and non-nesti= ng would have needed a similar patching anyway. >>=20 >> Ideally, if there's any firmer data from operator networks about wha= t the scale of the problem is - like what size headers are really a problem = - that would be nice to know. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> =EF=BB=BFOn 11/28/18, 1:17 PM, "stir on behalf of DOLLY, MARTIN C" wrote: >>=20 >> Greetings, >>=20 >> We had an ATIS- SIP Forum IPNNI meeting today.=20 >> Several operators performed lab testing with large SIP headers. It= was found that some deployed vendor equipment will drop the SIP INVITE if a= single header exceeds a certain length. >>=20 >> The IPNNI requests that the option for support of individual Ident= ity headers be added back into draft-ietf-stir-passport-divert, as nesting m= ay result in failures. >>=20 >> Thank you for your consideration. >>=20 >> Regards, >>=20 >> Martin C. Dolly >> Lead Member of Technical Staff >> Government & Services Standards >> AT&T >> Cell: +1.609.903.3360 >> Email: md3135@att.com >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir On Behalf Of Robert Sparks >> Sent: Tuesday, October 23, 2018 2:58 PM >> To: stir@ietf.org >> Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04= .txt >>=20 >> We plan to WGLC this document shortly after the Bangkok meeting, b= ut if anyone has any major issues with it, please bring them up now so we ca= n work them out during that meeting. >>=20 >> RjS >>=20 >>=20 >>> On 10/22/18 7:08 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Secure Telephone Identity Revisite= d WG of the IETF. >>>=20 >>> Title : PASSporT Extension for Diverted Calls >>> Author : Jon Peterson >>> Filename : draft-ietf-stir-passport-divert-04.txt >>> Pages : 12 >>> Date : 2018-10-22 >>>=20 >>> Abstract: >>> This document extends PASSporT, which conveys cryptographically- >>> signed information about the people involved in personal >>> communications, to include an indication that a call has been >>> diverted from its original destination to a new one. This >>> information can greatly improve the decisions made by verificatio= n >>> services in call forwarding scenarios. Also specified here is an >>> encapsulation mechanism for nesting a PASSporT within another >>> PASSporT that assists relying parties in some diversion scenarios= . >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ie= tf. >>> org_doc_draft-2Dietf-2Dstir-2Dpassport-2Ddivert_&d=3DDwICAg&c=3DLFYZ-o9= _HU >>> MeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlI= Ei4 >>> S4U6ZcvMDUXd0&s=3Dkd2Yz4GCgDKOSymv2aLYUADzjR6AWffmnPSXjuYSGZ0&e=3D >>>=20 >>> There are also htmlized versions available at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org= _ht >>> ml_draft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=3DDwICAg&c=3DLFYZ-o9_= HUM >>> eMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIE= i4S >>> 4U6ZcvMDUXd0&s=3DBToPQIIkMCUzUrB8XhiVCMFNj7SJIh49AImdMcCRp9c&e=3D >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ie= tf. >>> org_doc_html_draft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=3DDwICAg&= c=3DL >>> FYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7= O0K >>> lj1GlIEi4S4U6ZcvMDUXd0&s=3DQgOSunMIP4lN49FN75w2hLI2QZMil7jaW-Q4irYBXV= A&e >>> =3D >>>=20 >>> A diff from the previous version is available at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_r= fcd >>> iff-3Furl2-3Ddraft-2Dietf-2Dstir-2Dpassport-2Ddivert-2D04&d=3DDwICAg&= c=3DL >>> FYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3DrPMGq7kv2BGudfdZh7= O0K >>> lj1GlIEi4S4U6ZcvMDUXd0&s=3D57v9jHegC0yKQjthkptLgxxjK2OgKFmPXEhJFU5Dfp= o&e >>> =3D >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of=20 >>> submission until the htmlized version and diff are available at too= ls.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_int= ern >>> et-2Ddrafts_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG= 0r2 >>> g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=3DZOq0I6yZGiy_RDG_M= Up- >>> vzuBiBQrTPd5q48MABiOxBY&e=3D >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ail >>> man_listinfo_stir&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmp= w7I >>> tG0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=3DZen9oBkuiFcB= cM1 >>> Mms4FKeVZxxohlxvrDzJ4Dz0HCxw&e=3D >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_stir&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG= 0r2g&m=3DrPMGq7kv2BGudfdZh7O0Klj1GlIEi4S4U6ZcvMDUXd0&s=3DZen9oBkuiFcBcM1Mms4FKeV= ZxxohlxvrDzJ4Dz0HCxw&e=3D >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_stir&d=3DDwICAg&c=3DMOptNlVtIETeDALC_lULrw&r=3DdQ51tLfoGuuFjanmfe= KC0weXHNMl9xZnnsIiwRd6IgY&m=3DFvQYCnbfElq6VfDsf3xVLotfF0L2gOarO0sdc1yJTrg&s=3D5m= zFytkW9fVT82kLOUsOxdwMvqQEiTpBYJTlVFVd6nI&e=3D >>=20 >>=20 > _______________________________________________ > 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 =20 From nobody Wed Nov 28 20:45:54 2018 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 BDBAC130E06; Wed, 28 Nov 2018 20:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 35mnF7UwnT0Q; Wed, 28 Nov 2018 20:45:44 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 D867412426A; Wed, 28 Nov 2018 20:45:43 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id 83-v6so492863ljf.10; Wed, 28 Nov 2018 20:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bQU7C6MDHQfM3fAlgs1NtPmrfEw65KUJlT08kKnYtiI=; b=Yti4SIL4hacNHvGrG3h6euxITqAP4tBJv/V13yidT6jtQZhuJ/bY9Cj6yA0GeyYBs7 d2TpwV7tS4nyq2ttkRPWx2beNq5wXLW5FC1fWaOzpQVwU9ywu59An0dUyg3WJWKPc9JB bG3hW6nVtJQb8f61NoX9jgWHoPCF7Ximo4jmI+8W7Yx9zWUr2KdqpxadWtxD0FtJooAR cGxrUkubfAQkoGdLx7sO7veZH6oti8gbQx09AOiNhohVWlrXosi0XIFiub4kN+OOpydO mD3R9fgo1g3bq1WFXhDHceS5TXw+vtqMKypT6W7jEX6hhj3aapGJiqdGiTCfjuSotA+6 J/aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bQU7C6MDHQfM3fAlgs1NtPmrfEw65KUJlT08kKnYtiI=; b=NLNGRuZQ7x8gbwVyUL9nsxAqsoSKSAykroIfc0Va4M7AyxS6WvPNTeo6DpQVFK7bRt uo/mcqbMzWqCs8sEty+dK7GU+aBtIVbz21Nizo1k6tiG6dIK4OLI27QFaT87AX9hmTAe JSmNqHgtCMpIptFu+un7zlxZKRkThqCqWAxF6wGAv/4/AWcB5g8oct7RsP9uzqsn7wNq OXWKIEk7tm9PIqczjsKvsRDgwn5pGHolOBELaMUMBrjL/rNeNNvXMbGHrItUx6k5pdBv VpGpTT5RnoTf2yj9rrnp61iLysHMKxKWensm+S+OKnRIHdagOA3KXh12EVD0Fi37rXV1 KMqA== X-Gm-Message-State: AA+aEWbu8bb90RPaLsAsIFrikL0ElC/AwyQMwU78VLfF3N6hUQC7iohd DfV8yrAV3LpK0s2tVU4rbkBmINDzoB1Z0edWgZgIgw== X-Google-Smtp-Source: AFSGD/UXUfLl17jMAQPxa89QXy6gpKXCIgacCmBe68mrIf8Q9zaR7vLFrAoHPI9OLi98x9jdONTe5Tj1z//CAq/90Zk= X-Received: by 2002:a2e:9dcb:: with SMTP id x11-v6mr18272ljj.158.1543466741941; Wed, 28 Nov 2018 20:45:41 -0800 (PST) MIME-Version: 1.0 References: <154276845865.29769.15487419915492003928.idtracker@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 28 Nov 2018 22:45:29 -0600 Message-ID: To: chris-ietf@chriswendt.net Cc: IESG , draft-ietf-stir-passport-shaken@ietf.org, Robert Sparks , stir-chairs@ietf.org, stir@ietf.org Content-Type: multipart/alternative; boundary="000000000000e0497b057bc65ae3" Archived-At: Subject: Re: [stir] Spencer Dawkins' Yes on draft-ietf-stir-passport-shaken-05: (with COMMENT) 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: Thu, 29 Nov 2018 04:45:47 -0000 --000000000000e0497b057bc65ae3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Chris, On Mon, Nov 26, 2018 at 10:32 AM Chris Wendt wrote: > Hi Spencer, > > I definitely wouldn=E2=80=99t say it=E2=80=99s a dumb comment, but the re= asons behind the > different levels of attestations is due to some of the realities of the > current telephone network. Going forward, we do not want to make more > levels of attestation, rather we want all calls to essentially be =E2=80= =9CA=E2=80=9D level > full attestation, which is essentially pure STIR where the party signing > the call does have the ownership of the telephone number and has control = of > the credentials to sign the call. In the telephone network there is many > cases where the party that owns the telephone number doesn=E2=80=99t have= any > relationship with the party that either places the call or originates the > call on to the telephone network. (think a call center that uses the > enterprise phone number as the outgoing calling identity for a customer > service agent, or a snow delay robocall that uses the school district > number) > > So bottomline, the number of attestation levels should not increase, but > rather B and C should hopefully become less common as time goes on and > SHAKEN/STIR is more widely deployed into these enterprise and call center > environments. > That's a perfectly lovely theory. Thanks for helping me understand the thinking behind it. Spencer > > -Chris > > > On Nov 20, 2018, at 9:47 PM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-stir-passport-shaken-05: Yes > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I echo Ben's "Yes assuming the Discusses can be resolved". It's about > time we > > provided this capability! > > > > I did have a couple of comments you might want to consider, along with > anything > > else that pops up during IESG Evaluation. > > > > "SHAKEN" isn't spelled out in either the title or Abstract - that would > > probably help almost all the readers of this document ... > > > > I did find it odd that > > > > This indicator allows for both identifying the service provider that > > is vouching for the call as well as clearly indicating what > > information the service provider is attesting to. The 'attest' claim > > can be one of the following three values: 'A', 'B', or 'C' as defined > > in [ATIS-1000074]. > > > > used "A", "B", and "C", instead of something like "F"(ull), "P"(artial)= , > and > > "G"(ateway), because if you discover a need for a fourth value, it's no= t > clear > > whether anyone would be assuming "A" < "B" < "C" ordering in their code= , > that > > would break if the fourth value was naturally between "A" and "B". If > you're > > sure no one but Spencer would be so dumb, that's a fine response ... > > > > > > --000000000000e0497b057bc65ae3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Chris,=C2=A0
On Mon, Nov 26, 2018 at 10:32 AM Chris Wendt <chris-ietf@chriswendt.net> wrote:
=
Hi Spencer,

I definitely wouldn=E2=80=99t say it=E2=80=99s a dumb comment, but the reas= ons behind the different levels of attestations is due to some of the reali= ties of the current telephone network.=C2=A0 Going forward, we do not want = to make more levels of attestation, rather we want all calls to essentially= be =E2=80=9CA=E2=80=9D level full attestation, which is essentially pure S= TIR where the party signing the call does have the ownership of the telepho= ne number and has control of the credentials to sign the call.=C2=A0 In the= telephone network there is many cases where the party that owns the teleph= one number doesn=E2=80=99t have any relationship with the party that either= places the call or originates the call on to the telephone network. (think= a call center that uses the enterprise phone number as the outgoing callin= g identity for a customer service agent, or a snow delay robocall that uses= the school district number)

So bottomline, the number of attestation levels should not increase, but ra= ther B and C should hopefully become less common as time goes on and SHAKEN= /STIR is more widely deployed into these enterprise and call center environ= ments.

That's a perfectly lovely th= eory. Thanks for helping me understand the thinking behind it.
Spencer
=C2=A0

-Chris

> On Nov 20, 2018, at 9:47 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com= > wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-stir-passport-shaken-05: Yes
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/d= oc/draft-ietf-stir-passport-shaken/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I echo Ben's "Yes assuming the Discusses can be resolved"= ;. It's about time we
> provided this capability!
>
> I did have a couple of comments you might want to consider, along with= anything
> else that pops up during IESG Evaluation.
>
> "SHAKEN" isn't spelled out in either the title or Abstra= ct - that would
> probably help almost all the readers of this document ...
>
> I did find it odd that
>
>=C2=A0 This indicator allows for both identifying the service provider = that
>=C2=A0 =C2=A0is vouching for the call as well as clearly indicating wha= t
>=C2=A0 =C2=A0information the service provider is attesting to.=C2=A0 Th= e 'attest' claim
>=C2=A0 =C2=A0can be one of the following three values: 'A', = 9;B', or 'C' as defined
>=C2=A0 =C2=A0in [ATIS-1000074].
>
> used "A", "B", and "C", instead of somet= hing like "F"(ull), "P"(artial), and
> "G"(ateway), because if you discover a need for a fourth val= ue, it's not clear
> whether anyone would be assuming "A" < "B" <= "C" ordering in their code, that
> would break if the fourth value was naturally between "A" an= d "B".=C2=A0 If you're
> sure no one but Spencer would be so dumb, that's a fine response .= ..
>
>

--000000000000e0497b057bc65ae3-- From nobody Thu Nov 29 12:01:56 2018 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 9AD3B130EBF for ; Thu, 29 Nov 2018 12:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 dlB95zQTuMAV for ; Thu, 29 Nov 2018 12:01:49 -0800 (PST) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710137.outbound.protection.outlook.com [40.107.71.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4776130F03 for ; Thu, 29 Nov 2018 12:01:38 -0800 (PST) Received: from DM5PR05MB3290.namprd05.prod.outlook.com (10.174.191.29) by DM5PR05MB3193.namprd05.prod.outlook.com (10.173.219.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.14; Thu, 29 Nov 2018 20:01:36 +0000 Received: from DM5PR05MB3290.namprd05.prod.outlook.com ([fe80::1473:7621:2a31:63eb]) by DM5PR05MB3290.namprd05.prod.outlook.com ([fe80::1473:7621:2a31:63eb%5]) with mapi id 15.20.1382.017; Thu, 29 Nov 2018 20:01:36 +0000 From: "Gorman, Pierce A [CTO]" To: Richard Shockey , Chris Wendt , Martin C Dolly CC: "Peterson, Jon" , Robert Sparks , "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt Thread-Index: AQHUh4vBwQ4BuKWgi02b1Gjvlc8LcqVnKjQw Date: Thu, 29 Nov 2018 20:01:36 +0000 Message-ID: References: <154025330720.13787.14022156083126853868@ietfa.amsl.com> <66b6b8d3-2d1b-135a-580a-5c0e06d25452@nostrum.com> <9D4258CD-6D8E-489E-BE99-A27353F8B069@chriswendt.net> <4250EED5-6EF1-4472-8A17-7F89158F3439@shockey.us> In-Reply-To: <4250EED5-6EF1-4472-8A17-7F89158F3439@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.230.82.246] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3193; 6:brtN12iXroZ13GahBRh4TL8am3ruFKqu5sQS/LFTuSMXpPIS7Cb3wqcSh+FrJacFF78prpTMa7etXf3v0TKzDGKBx3/lC++PARF16/nIuKzQcx6neCGanCePOKeS8FfuDhW8/QiL8O9Sv27LWLAkAbBKbHmRN8bQ7pcbGD5VVZ/E4CG++kZz0aGMK8wJqWzO8/bJtI3aiEwbzgl5Ym/PDZ1QTLXOoSbDjARyfqA3/SDSJZOc7h63uIPl7L9o3Ib04qzBD3NcZL9+k8mTKsImuWjowhypnMYYTsQDI9ZZFWIVs0+Z27XmSsgW/IKzj15OkmWLOX7kG4P8iCYFj7lgZrpl0MIxU4ebMZGVZgS/W6YQEep+swUcs8MHR5UQpFEPCfrr4lLkvNH9ZuaPcvjHAGEnc0K7n+xNgWCvhxJKqm+I2VGDAuyN/gSAJaQUJIoREVhtHVlHhmc+hOugZSAIyw==; 5:aCisiHw/TVEWonlaB0aHyMsn3mEF5JB3RzgmcH36Jg9VsyhOAGuMo4BV+hZpdZ8iCHfemEZn7bcBTeuUVIpRrd7ZcG3bwtzip/M+xEG3ofyaC3IPG/eGlOSot4p1RCliAok2sEKCrUv9wTCmncF9BxK5kfdEfppNHpwMP2jc9aQ=; 7:LP2HZ6C8NjDzsCYENEKan/5u5w/k8cxr1h0DaJp7yqm18E2ZEzCQ4j3Z4IADNXIbWvJLyw5/dhmu+BqoHpjhqQYeIaX2x1e3ASNfceev0YQQ720wFxvxGgwFDnEJ/P3UwfmrE9xAGHKr6AO9ZOiWdw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0f481976-90cb-4fc3-a1ee-08d656357807 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM5PR05MB3193; x-ms-traffictypediagnostic: DM5PR05MB3193: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Pierce.Gorman@sprint.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231453)(999002)(944501449)(52105112)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:DM5PR05MB3193; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3193; x-forefront-prvs: 0871917CDA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(136003)(396003)(39860400002)(51744003)(13464003)(252514010)(199004)(189003)(325944009)(478600001)(97736004)(8936002)(15974865002)(229853002)(4326008)(11346002)(446003)(7736002)(6116002)(9686003)(6306002)(305945005)(53946003)(81166006)(345774005)(74316002)(6436002)(4001150100001)(33656002)(68736007)(3846002)(55016002)(6246003)(54906003)(106356001)(26005)(71200400001)(71190400001)(53546011)(25786009)(186003)(2906002)(53936002)(316002)(110136005)(19627235002)(966005)(7696005)(256004)(476003)(102836004)(14444005)(86362001)(4744004)(66066001)(72206003)(45080400002)(5660300001)(76176011)(486006)(14454004)(99286004)(105586002)(6506007)(575784001)(93886005)(8676002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3193; H:DM5PR05MB3290.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: sprint.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: qGocb5uV0Scn96et63KYeJWGNHEKUCSqHD2tNCDzkLtgu3J4kiqPbJuJOKDeP/+NJf7V9cdjTYU2+0X3UiKMFVzIBFqb+JCNNcCZZEs9aTPBgxS/lmIW5/TCkYvZ31bsO1iSSRTSOZEX9tfwpVi17OXpfDo203a/7EB04ddNGGAbThS2k8BqDdlWXH6P+DAFTZrNbEqvrqJXHqqeHcAFYLhI4E0sQ29ICaGQd50hGQWcDhs+xTxQFLRbjzl8VRVcRRp1vC8rOWDsWoNcXcY/tUiF+6OUqYDDEZs8Jp899CqCPBDNTjVGuPnwCNCIT735D27wMZYvZJMifTMzSCTE6MmnxdoLJCozvveZgW1nIIY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f481976-90cb-4fc3-a1ee-08d656357807 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2018 20:01:36.4624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3193 Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-divert-04.txt 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: Thu, 29 Nov 2018 20:01:54 -0000 KzEgb24gbm90IHJlcXVpcmluZyBuZXN0aW5nLg0KDQpOb3Qgc3VyZSB3aGF0IHRvIHRoaW5rIGFi b3V0IGxlZ2lzbGF0aW9uIHRoYXQgInByZXZlbnRzIiAiaW5hZHZlcnRlbnQiIGFsdGVyYXRpb25z LiAgSXMgdGhhdCBwb3NzaWJsZT8gIA0KDQpGV0lXLCBnaXZlbiB0aGUgZXh0ZW5kZWQgZGlzY3Vz c2lvbiBvbiB0aGUgSVAtTk5JIGNhbGwgeWVzdGVyZGF5IGFib3V0IGtub3duIGFuZCBhbnRpY2lw YXRlZCBTSEFLRU4gdmVyaWZpY2F0aW9uIGZhaWx1cmUgc2NlbmFyaW9zIGZvciAiY29ybmVyIGNh c2UiIGNhbGwgZmxvd3Mgd2l0aCBubyBwcm9wb3NlZCBvciBzdGFuZGFyZCBzb2x1dGlvbiBvdGhl ciB0aGFuIGEgYmVzdCBwcmFjdGljZSBvZiB0cmVhdGluZyB0aGUgY2FsbCBhcyAibm90IHZlcmlm aWVkIiwgcGVyaGFwcyBpdCBtaWdodCBiZSBwcnVkZW50IHRvIGdldCBzb21lIHJlYWwtd29ybGQg b3BlcmF0aW9uYWwgZXhwZXJpZW5jZSB0byBoZWxwIGNyYWZ0IGRldGFpbHMgb2Ygc3VwcG9ydGlu ZyBsZWdpc2xhdGlvbi4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmlj aGFyZCBTaG9ja2V5IFttYWlsdG86cmljaGFyZEBzaG9ja2V5LnVzXSANClNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgMjgsIDIwMTggODoyNyBQTQ0KVG86IENocmlzIFdlbmR0IDxjaHJpcy1pZXRm QGNocmlzd2VuZHQubmV0PjsgTWFydGluIEMgRG9sbHkgPG1kMzEzNUBhdHQuY29tPg0KQ2M6IFBl dGVyc29uLCBKb24gPGpvbi5wZXRlcnNvbkB0ZWFtLm5ldXN0YXI+OyBSb2JlcnQgU3BhcmtzIDxy anNwYXJrc0Bub3N0cnVtLmNvbT47IHN0aXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3Rpcl0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0LWRpdmVydC0wNC50eHQNCg0KDQor MSAgIEkgdG90YWxseSBzdXBwb3J0IHRoZSBwb3NpdGlvbiB0aGF0IE1hcnRpbiBhbmQgQ2hyaXMg YXJlIGFkdm9jYXRpbmcuICANCg0KSSBtaWdodCBhZGQgdGhhdCBzb21lIG9mIHVzIGFyZSBsb29r aW5nIGF0IGZvcm1hbCBsZWdhbCBwcm90ZWN0aW9uIGZvciBtZXRob2RzIGZvciBDYWxsIEF1dGhl bnRpY2F0aW9uIGFrYSBTVElSL1NIQUtFTiBoZWFkZXJzIHRvIHByZXZlbnQgZWl0aGVyIGluYWR2 ZXJ0ZW50IG9yIG1hbGljaW91cyBhbHRlcmF0aW9uLiAgU29tZSBvZiB5b3UgdmVuZG9ycyBzaG91 bGQgdGFrZSBub3RlLiANCg0KV2UgYXJlIGxvb2tpbmcgYXQgZXh0ZW5kaW5nIHNlY3Rpb25zIG9m IFVTIDQ3IENGUiA2NC4xNjAxLiAgQ0ZSIGlzIHRoZSBDb2RlIG9mIEZlZGVyYWwgUmVndWxhdGlv bnMuICANCg0KT3RoZXIgbmF0aW9uYWwganVyaXNkaWN0aW9ucyBtYXkgd2FudCB0byB0YWtlIGEg bG9vayBhdCB0aGlzLiAgRmlsbSBhdCAxMS4gIA0KDQoNCsKnNjQuMTYwMSAgIERlbGl2ZXJ5IHJl cXVpcmVtZW50cyBhbmQgcHJpdmFjeSByZXN0cmljdGlvbnMuDQooYSkgRGVsaXZlcnkuIEV4Y2Vw dCBhcyBwcm92aWRlZCBpbiBwYXJhZ3JhcGhzIChkKSBhbmQgKGUpIG9mIHRoaXMgc2VjdGlvbjoN CiANCigxKSBUZWxlY29tbXVuaWNhdGlvbnMgY2FycmllcnMgYW5kIHByb3ZpZGVycyBvZiBpbnRl cmNvbm5lY3RlZCBWb2ljZSBvdmVyIEludGVybmV0IFByb3RvY29sIChWb0lQKSBzZXJ2aWNlcywg aW4gb3JpZ2luYXRpbmcgaW50ZXJzdGF0ZSBvciBpbnRyYXN0YXRlIHRyYWZmaWMgb24gdGhlIHB1 YmxpYyBzd2l0Y2hlZCB0ZWxlcGhvbmUgbmV0d29yayAoUFNUTikgb3Igb3JpZ2luYXRpbmcgaW50 ZXJzdGF0ZSBvciBpbnRyYXN0YXRlIHRyYWZmaWMgdGhhdCBpcyBkZXN0aW5lZCBmb3IgdGhlIFBT VE4gKGNvbGxlY3RpdmVseSDigJxQU1ROIFRyYWZmaWPigJ0pLCBhcmUgcmVxdWlyZWQgdG8gdHJh bnNtaXQgZm9yIGFsbCBQU1ROIFRyYWZmaWMgdGhlIHRlbGVwaG9uZSBudW1iZXIgcmVjZWl2ZWQg ZnJvbSBvciBhc3NpZ25lZCB0byBvciBvdGhlcndpc2UgYXNzb2NpYXRlZCB3aXRoIHRoZSBjYWxs aW5nIHBhcnR5IHRvIHRoZSBuZXh0IHByb3ZpZGVyIGluIHRoZSBwYXRoIGZyb20gdGhlIG9yaWdp bmF0aW5nIHByb3ZpZGVyIHRvIHRoZSB0ZXJtaW5hdGluZyBwcm92aWRlci4gVGhpcyBwcm92aXNp b24gYXBwbGllcyByZWdhcmRsZXNzIG9mIHRoZSB2b2ljZSBjYWxsIHNpZ25hbGluZyBhbmQgdHJh bnNtaXNzaW9uIHRlY2hub2xvZ3kgdXNlZCBieSB0aGUgY2FycmllciBvciBWb0lQIHByb3ZpZGVy LiBFbnRpdGllcyBzdWJqZWN0IHRvIHRoaXMgcHJvdmlzaW9uIHRoYXQgdXNlIFNpZ25hbGluZyBT eXN0ZW0gNyAoU1M3KSBhcmUgcmVxdWlyZWQgdG8gdHJhbnNtaXQgdGhlIGNhbGxpbmcgcGFydHkg bnVtYmVyIChDUE4pIGFzc29jaWF0ZWQgd2l0aCBhbGwgUFNUTiBUcmFmZmljIGluIHRoZSBTUzcg SVNVUCAoSVNETiBVc2VyIFBhcnQpIENQTiBmaWVsZCB0byBpbnRlcmNvbm5lY3RpbmcgcHJvdmlk ZXJzLCBhbmQgYXJlIHJlcXVpcmVkIHRvIHRyYW5zbWl0IHRoZSBjYWxsaW5nIHBhcnR5J3MgY2hh cmdlIG51bWJlciAoQ04pIGluIHRoZSBTUzcgSVNVUCBDTiBmaWVsZCB0byBpbnRlcmNvbm5lY3Rp bmcgcHJvdmlkZXJzIGZvciBhbnkgUFNUTiBUcmFmZmljIHdoZXJlIENOIGRpZmZlcnMgZnJvbSBD UE4uIEVudGl0aWVzIHN1YmplY3QgdG8gdGhpcyBwcm92aXNpb24gd2hvIHVzZSBtdWx0aS1mcmVx dWVuY3kgKE1GKSBzaWduYWxpbmcgYXJlIHJlcXVpcmVkIHRvIHRyYW5zbWl0IENQTiwgb3IgQ04g aWYgaXQgZGlmZmVycyBmcm9tIENQTiwgYXNzb2NpYXRlZCB3aXRoIGFsbCBQU1ROIFRyYWZmaWMg aW4gdGhlIE1GIHNpZ25hbGluZyBhdXRvbWF0aWMgbnVtYmVyaW5nIGluZm9ybWF0aW9uIChBTkkp IGZpZWxkLg0KIA0KKDIpIEludGVybWVkaWF0ZSBwcm92aWRlcnMgd2l0aGluIGFuIGludGVyc3Rh dGUgb3IgaW50cmFzdGF0ZSBjYWxsIHBhdGggdGhhdCBvcmlnaW5hdGVzIGFuZC9vciB0ZXJtaW5h dGVzIG9uIHRoZSBQU1ROIG11c3QgcGFzcyB1bmFsdGVyZWQgdG8gc3Vic2VxdWVudCBwcm92aWRl cnMgaW4gdGhlIGNhbGwgcGF0aCBzaWduYWxpbmcgaW5mb3JtYXRpb24gaWRlbnRpZnlpbmcgdGhl IHRlbGVwaG9uZSBudW1iZXIsIG9yIGJpbGxpbmcgbnVtYmVyLCBpZiBkaWZmZXJlbnQsIG9mIHRo ZSBjYWxsaW5nIHBhcnR5IHRoYXQgaXMgcmVjZWl2ZWQgd2l0aCBhIGNhbGwuIFRoaXMgcmVxdWly ZW1lbnQgYXBwbGllcyB0byBTUzcgaW5mb3JtYXRpb24gaW5jbHVkaW5nIGJ1dCBub3QgbGltaXRl ZCB0byBDUE4gYW5kIENOLCBhbmQgYWxzbyBhcHBsaWVzIHRvIE1GIHNpZ25hbGluZyBpbmZvcm1h dGlvbiBvciBvdGhlciBzaWduYWxpbmcgaW5mb3JtYXRpb24gaW50ZXJtZWRpYXRlIHByb3ZpZGVy cyByZWNlaXZlIHdpdGggYSBjYWxsLiBUaGlzIHJlcXVpcmVtZW50IGFsc28gYXBwbGllcyB0byBW b0lQIHNpZ25hbGluZyBtZXNzYWdlcywgc3VjaCBhcyBjYWxsaW5nIHBhcnR5IGFuZCBjaGFyZ2Ug aW5mb3JtYXRpb24gaWRlbnRpZmllcnMgY29udGFpbmVkIGluIFNlc3Npb24gSW5pdGlhdGlvbiBQ cm90b2NvbCAoU0lQKSBoZWFkZXIgZmllbGRzLCBhbmQgdG8gZXF1aXZhbGVudCBpZGVudGlmeWlu ZyBpbmZvcm1hdGlvbiBhcyB1c2VkIGluIG90aGVyIFZvSVAgc2lnbmFsaW5nIHRlY2hub2xvZ2ll cywgcmVnYXJkbGVzcyBvZiB0aGUgdm9pY2UgY2FsbCBzaWduYWxpbmcgYW5kIHRyYW5zbWlzc2lv biB0ZWNobm9sb2d5IHVzZWQgYnkgdGhlIGNhcnJpZXIgb3IgVm9JUCBwcm92aWRlci4NCiANCihi KSBQcml2YWN5LiBFeGNlcHQgYXMgcHJvdmlkZWQgaW4gcGFyYWdyYXBoIChkKSBvZiB0aGlzIHNl Y3Rpb24sIG9yaWdpbmF0aW5nIGNhcnJpZXJzIHVzaW5nIFNpZ25hbGluZyBTeXN0ZW0gNyBhbmQg b2ZmZXJpbmcgb3Igc3Vic2NyaWJpbmcgdG8gYW55IHNlcnZpY2UgYmFzZWQgb24gU2lnbmFsaW5n IFN5c3RlbSA3IGZ1bmN0aW9uYWxpdHkgd2lsbCByZWNvZ25pemUgKjY3IGRpYWxlZCBhcyB0aGUg Zmlyc3QgdGhyZWUgZGlnaXRzIG9mIGEgY2FsbCAob3IgMTE2NyBmb3Igcm90YXJ5IG9yIHB1bHNl IGRpYWxpbmcgcGhvbmVzKSBhcyBhIGNhbGxlcidzIHJlcXVlc3QgdGhhdCB0aGUgQ1BOIG5vdCBi ZSBwYXNzZWQgb24gYW4gaW50ZXJzdGF0ZSBjYWxsLiBTdWNoIGNhcnJpZXJzIHByb3ZpZGluZyBs aW5lIGJsb2NraW5nIHNlcnZpY2VzIHdpbGwgcmVjb2duaXplICo4MiBhcyBhIGNhbGxlcidzIHJl cXVlc3QgdGhhdCB0aGUgQ1BOIGJlIHBhc3NlZCBvbiBhbiBpbnRlcnN0YXRlIGNhbGwuIE5vIGNv bW1vbiBjYXJyaWVyIHN1YnNjcmliaW5nIHRvIG9yIG9mZmVyaW5nIGFueSBzZXJ2aWNlIHRoYXQg ZGVsaXZlcnMgQ1BOIG1heSBvdmVycmlkZSB0aGUgcHJpdmFjeSBpbmRpY2F0b3IgYXNzb2NpYXRl ZCB3aXRoIGFuIGludGVyc3RhdGUgY2FsbC4gQ2FycmllcnMgbXVzdCBhcnJhbmdlIHRoZWlyIENQ Ti1iYXNlZCBzZXJ2aWNlcywgYW5kIGJpbGxpbmcgcHJhY3RpY2VzLCBpbiBzdWNoIGEgbWFubmVy IHRoYXQgd2hlbiBhIGNhbGxlciByZXF1ZXN0cyB0aGF0IHRoZSBDUE4gbm90IGJlIHBhc3NlZCwg YSBjYXJyaWVyIG1heSBub3QgcmV2ZWFsIHRoYXQgY2FsbGVyJ3MgbnVtYmVyIG9yIG5hbWUsIG5v ciBtYXkgdGhlIGNhcnJpZXIgdXNlIHRoZSBudW1iZXIgb3IgbmFtZSB0byBhbGxvdyB0aGUgY2Fs bGVkIHBhcnR5IHRvIGNvbnRhY3QgdGhlIGNhbGxpbmcgcGFydHkuIFRoZSB0ZXJtaW5hdGluZyBj YXJyaWVyIG11c3QgYWN0IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgcHJpdmFjeSBpbmRpY2F0b3Ig dW5sZXNzIHRoZSBjYWxsIGlzIG1hZGUgdG8gYSBjYWxsZWQgcGFydHkgdGhhdCBzdWJzY3JpYmVz IHRvIGFuIEFOSSBvciBjaGFyZ2UgbnVtYmVyIGJhc2VkIHNlcnZpY2UgYW5kIHRoZSBjYWxsIGlz IHBhaWQgZm9yIGJ5IHRoZSBjYWxsZWQgcGFydHkuDQogDQooYykgQ2hhcmdlcy4gTm8gY29tbW9u IGNhcnJpZXIgc3Vic2NyaWJpbmcgdG8gb3Igb2ZmZXJpbmcgYW55IHNlcnZpY2UgdGhhdCBkZWxp dmVycyBjYWxsaW5nIHBhcnR5IG51bWJlciBtYXkNCiANCigxKSBJbXBvc2Ugb24gdGhlIGNhbGxp bmcgcGFydHkgY2hhcmdlcyBhc3NvY2lhdGVkIHdpdGggcGVyIGNhbGwgYmxvY2tpbmcgb2YgdGhl IGNhbGxpbmcgcGFydHkncyB0ZWxlcGhvbmUgbnVtYmVyLCBvcg0KIA0KKDIpIEltcG9zZSBjaGFy Z2VzIHVwb24gY29ubmVjdGluZyBjYXJyaWVycyBmb3IgdGhlIGRlbGl2ZXJ5IG9mIHRoZSBjYWxs aW5nIHBhcnR5IG51bWJlciBwYXJhbWV0ZXIgb3IgaXRzIGFzc29jaWF0ZWQgcHJpdmFjeSBpbmRp Y2F0b3IuDQogDQooZCkgRXhlbXB0aW9ucy4gU2VjdGlvbiA2NC4xNjAxKGEpIGFuZCAoYikgc2hh bGwgbm90IGFwcGx5IHdoZW46DQogDQooMSkgQSBjYWxsIG9yaWdpbmF0ZXMgZnJvbSBhIHBheXBo b25lLg0KIA0KKDIpIEEgbG9jYWwgZXhjaGFuZ2UgY2FycmllciB3aXRoIFNpZ25hbGluZyBTeXN0 ZW0gNyBjYXBhYmlsaXR5IGRvZXMgbm90IGhhdmUgdGhlIHNvZnR3YXJlIHRvIHByb3ZpZGUgKjY3 IG9yICo4MiBmdW5jdGlvbmFsaXRpZXMuIFN1Y2ggY2FycmllcnMgYXJlIHByb2hpYml0ZWQgZnJv bSBwYXNzaW5nIENQTi4NCiANCigzKSBBIFByaXZhdGUgQnJhbmNoIEV4Y2hhbmdlIG9yIENlbnRy ZXggc3lzdGVtIGRvZXMgbm90IHBhc3MgZW5kIHVzZXIgQ1BOLiBDZW50cmV4IHN5c3RlbXMgdGhh dCByZWx5IG9uICo2IG9yICo4IGZvciBhIGZ1bmN0aW9uIG90aGVyIHRoYW4gQ1BOIGJsb2NraW5n IG9yIHVuYmxvY2tpbmcsIHJlc3BlY3RpdmVseSwgYXJlIGFsc28gZXhlbXB0IGlmIHRoZXkgZW1w bG95IGFsdGVybmF0aXZlIG1lYW5zIG9mIGJsb2NraW5nIG9yIHVuYmxvY2tpbmcuDQogDQooNCkg Q1BOIGRlbGl2ZXJ54oCUDQogDQooaSkgSXMgdXNlZCBzb2xlbHkgaW4gY29ubmVjdGlvbiB3aXRo IGNhbGxzIHdpdGhpbiB0aGUgc2FtZSBsaW1pdGVkIHN5c3RlbSwgaW5jbHVkaW5nIChidXQgbm90 IGxpbWl0ZWQgdG8pIGEgQ2VudHJleCBzeXN0ZW0sIHZpcnR1YWwgcHJpdmF0ZSBuZXR3b3JrLCBv ciBQcml2YXRlIEJyYW5jaCBFeGNoYW5nZTsNCiANCihpaSkgSXMgdXNlZCBvbiBhIHB1YmxpYyBh Z2VuY3kncyBlbWVyZ2VuY3kgdGVsZXBob25lIGxpbmUgb3IgaW4gY29uanVuY3Rpb24gd2l0aCA5 MTEgZW1lcmdlbmN5IHNlcnZpY2VzLCBvbiBhIHRlbGVwaG9uZSBsaW5lIHRvIGNvbnRhY3Qgbm9u LXB1YmxpYyBlbWVyZ2VuY3kgc2VydmljZXMgbGljZW5zZWQgYnkgdGhlIHN0YXRlIG9yIG11bmlj aXBhbGl0eSwgb3Igb24gYW55IGVudGl0eSdzIGVtZXJnZW5jeSBhc3Npc3RhbmNlIHBvaXNvbiBj b250cm9sIHRlbGVwaG9uZSBsaW5lOyBvcg0KIA0KKGlpaSkgSXMgcHJvdmlkZWQgaW4gY29ubmVj dGlvbiB3aXRoIGxlZ2FsbHkgYXV0aG9yaXplZCBjYWxsIHRyYWNpbmcgb3IgdHJhcHBpbmcgcHJv Y2VkdXJlcyBzcGVjaWZpY2FsbHkgcmVxdWVzdGVkIGJ5IGEgbGF3IGVuZm9yY2VtZW50IGFnZW5j eS4NCiANCihlKSBBbnkgcGVyc29uIG9yIGVudGl0eSB0aGF0IGVuZ2FnZXMgaW4gdGVsZW1hcmtl dGluZywgYXMgZGVmaW5lZCBpbiBzZWN0aW9uIDY0LjEyMDAoZikoMTApIG11c3QgdHJhbnNtaXQg Y2FsbGVyIGlkZW50aWZpY2F0aW9uIGluZm9ybWF0aW9uLg0KIA0KKDEpIEZvciBwdXJwb3NlcyBv ZiB0aGlzIHBhcmFncmFwaCwgY2FsbGVyIGlkZW50aWZpY2F0aW9uIGluZm9ybWF0aW9uIG11c3Qg aW5jbHVkZSBlaXRoZXIgQ1BOIG9yIEFOSSwgYW5kLCB3aGVuIGF2YWlsYWJsZSBieSB0aGUgdGVs ZW1hcmtldGVyJ3MgY2FycmllciwgdGhlIG5hbWUgb2YgdGhlIHRlbGVtYXJrZXRlci4gSXQgc2hh bGwgbm90IGJlIGEgdmlvbGF0aW9uIG9mIHRoaXMgcGFyYWdyYXBoIHRvIHN1YnN0aXR1dGUgKGZv ciB0aGUgbmFtZSBhbmQgcGhvbmUgbnVtYmVyIHVzZWQgaW4sIG9yIGJpbGxlZCBmb3IsIG1ha2lu ZyB0aGUgY2FsbCkgdGhlIG5hbWUgb2YgdGhlIHNlbGxlciBvbiBiZWhhbGYgb2Ygd2hpY2ggdGhl IHRlbGVtYXJrZXRpbmcgY2FsbCBpcyBwbGFjZWQgYW5kIHRoZSBzZWxsZXIncyBjdXN0b21lciBz ZXJ2aWNlIHRlbGVwaG9uZSBudW1iZXIuIFRoZSB0ZWxlcGhvbmUgbnVtYmVyIHNvIHByb3ZpZGVk IG11c3QgcGVybWl0IGFueSBpbmRpdmlkdWFsIHRvIG1ha2UgYSBkby1ub3QtY2FsbCByZXF1ZXN0 IGR1cmluZyByZWd1bGFyIGJ1c2luZXNzIGhvdXJzLg0KIA0KKDIpIEFueSBwZXJzb24gb3IgZW50 aXR5IHRoYXQgZW5nYWdlcyBpbiB0ZWxlbWFya2V0aW5nIGlzIHByb2hpYml0ZWQgZnJvbSBibG9j a2luZyB0aGUgdHJhbnNtaXNzaW9uIG9mIGNhbGxlciBpZGVudGlmaWNhdGlvbiBpbmZvcm1hdGlv bi4NCiANCigzKSBUYXgtZXhlbXB0IG5vbnByb2ZpdCBvcmdhbml6YXRpb25zIGFyZSBub3QgcmVx dWlyZWQgdG8gY29tcGx5IHdpdGggdGhpcyBwYXJhZ3JhcGguDQogDQooZikgUGFyYWdyYXBoIChi KSBvZiB0aGlzIHNlY3Rpb24gc2hhbGwgbm90IGFwcGx5IHdoZW4gQ1BOIGRlbGl2ZXJ5IGlzIG1h ZGUgaW4gY29ubmVjdGlvbiB3aXRoIGEgdGhyZWF0ZW5pbmcgY2FsbC4gVXBvbiByZXBvcnQgb2Yg c3VjaCBhIHRocmVhdGVuaW5nIGNhbGwgYnkgbGF3IGVuZm9yY2VtZW50IG9uIGJlaGFsZiBvZiB0 aGUgdGhyZWF0ZW5lZCBwYXJ0eSwgdGhlIGNhcnJpZXIgd2lsbCBwcm92aWRlIGFueSBDUE4gb2Yg dGhlIGNhbGxpbmcgcGFydHkgdG8gbGF3IGVuZm9yY2VtZW50IGFuZCwgYXMgZGlyZWN0ZWQgYnkg bGF3IGVuZm9yY2VtZW50LCB0byBzZWN1cml0eSBwZXJzb25uZWwgZm9yIHRoZSBjYWxsZWQgcGFy dHkgZm9yIHRoZSBwdXJwb3NlIG9mIGlkZW50aWZ5aW5nIHRoZSBwYXJ0eSByZXNwb25zaWJsZSBm b3IgdGhlIHRocmVhdGVuaW5nIGNhbGwuDQogDQooZykgRm9yIGxhdyBlbmZvcmNlbWVudCBvciBz ZWN1cml0eSBwZXJzb25uZWwgb2YgdGhlIGNhbGxlZCBwYXJ0eSBpbnZlc3RpZ2F0aW5nIHRoZSB0 aHJlYXQ6DQogDQooMSkgVGhlIENQTiBvbiBpbmNvbWluZyByZXN0cmljdGVkIGNhbGxzIG1heSBu b3QgYmUgcGFzc2VkIG9uIHRvIHRoZSBsaW5lIGNhbGxlZDsNCiANCigyKSBBbnkgc3lzdGVtIHVz ZWQgdG8gcmVjb3JkIENQTiBtdXN0IGJlIG9wZXJhdGVkIGluIGEgc2VjdXJlIHdheSwgbGltaXRp bmcgYWNjZXNzIHRvIGRlc2lnbmF0ZWQgdGVsZWNvbW11bmljYXRpb25zIGFuZCBzZWN1cml0eSBw ZXJzb25uZWwsIGFzIGRpcmVjdGVkIGJ5IGxhdyBlbmZvcmNlbWVudDsNCiANCigzKSBUZWxlY29t bXVuaWNhdGlvbnMgYW5kIHNlY3VyaXR5IHBlcnNvbm5lbCwgYXMgZGlyZWN0ZWQgYnkgbGF3IGVu Zm9yY2VtZW50LCBtYXkgYWNjZXNzIHJlc3RyaWN0ZWQgQ1BOIGRhdGEgb25seSB3aGVuIGludmVz dGlnYXRpbmcgcGhvbmUgY2FsbHMgb2YgYSB0aHJlYXRlbmluZyBhbmQgc2VyaW91cyBuYXR1cmUs IGFuZCBzaGFsbCBkb2N1bWVudCB0aGF0IGFjY2VzcyBhcyBwYXJ0IG9mIHRoZSBpbnZlc3RpZ2F0 aXZlIHJlcG9ydDsNCiANCig0KSBDYXJyaWVycyB0cmFuc21pdHRpbmcgcmVzdHJpY3RlZCBDUE4g aW5mb3JtYXRpb24gbXVzdCB0YWtlIHJlYXNvbmFibGUgbWVhc3VyZXMgdG8gZW5zdXJlIHNlY3Vy aXR5IG9mIHN1Y2ggY29tbXVuaWNhdGlvbnM7DQogDQooNSkgQ1BOIGluZm9ybWF0aW9uIG11c3Qg YmUgZGVzdHJveWVkIGluIGEgc2VjdXJlIG1hbm5lciBhZnRlciBhIHJlYXNvbmFibGUgcmV0ZW50 aW9uIHBlcmlvZDsgYW5kDQogDQooNikgQW55IHZpb2xhdGlvbiBvZiB0aGVzZSBjb25kaXRpb25z IG11c3QgYmUgcmVwb3J0ZWQgcHJvbXB0bHkgdG8gdGhlIENvbW1pc3Npb24uDQogDQpbNjAgRlIg Mjk0OTAsIEp1bmUgNSwgMTk5NTsgNjAgRlIgNTQ0NDksIE9jdC4gMjQsIDE5OTUsIGFzIGFtZW5k ZWQgYXQgNjIgRlIgMzQwMTUsIEp1bmUgMjQsIDE5OTc7IDY4IEZSIDQ0MTc5LCBKdWx5IDI1LCAy MDAzOyA3MSBGUiA3NTEyMiwgRGVjLiAxNCwgMjAwNjsgNzYgRlIgNzM4ODIsIE5vdi4gMjksIDIw MTE7IDgyIEZSIDU2OTE3LCBEZWMuIDEsIDIwMTddDQogDQpFZmZlY3RpdmUgRGF0ZSBOb3RlOiBB dCA4MiBGUiA1NjkxNywgRGVjLiAxLCAyMDE3LCDCpzY0LjE2MDEgd2FzIGFtZW5kZWQgYnkgcmV2 aXNpbmcgcGFyYWdyYXBocyAoZCkoNCkoaWkpIGFuZCBhZGRpbmcgcGFyYWdyYXBoIChmKS4gVGhl c2UgcGFyYWdyYXBocyBjb250YWluIGluZm9ybWF0aW9uIGNvbGxlY3Rpb24gYW5kIHJlY29yZGtl ZXBpbmcgcmVxdWlyZW1lbnRzIGFuZCB3aWxsIG5vdCBiZWNvbWUgZWZmZWN0aXZlIHVudGlsIGFw cHJvdmFsIGhhcyBiZWVuIGdpdmVuIGJ5IHRoZSBPZmZpY2Ugb2YgTWFuYWdlbWVudCBhbmQgQnVk Z2V0Lg0KDQoNCuKAlCANClJpY2hhcmQgU2hvY2tleQ0KDQpTaG9ja2V5IENvbnN1bHRpbmcgTExD DQoNCkNoYWlybWFuIG9mIHRoZSBCb2FyZCBTSVAgRm9ydW0NCg0Kd3d3LnNob2NrZXkudXMNCg0K d3d3LnNpcGZvcnVtLm9yZw0KDQpyaWNoYXJkPGF0PnNob2NrZXkudXMNCg0KU2t5cGUtTGlua2Vk aW4tRmFjZWJvb2sg4oCTVHdpdHRlciAgcnNob2NrZXkxMDENCg0KUFNUTiArMSA3MDMtNTkzLTI2 ODMNCg0KIA0KDQrvu79PbiAxMS8yOC8xOCwgNzo0NSBQTSwgInN0aXIgb24gYmVoYWxmIG9mIENo cmlzIFdlbmR0IiA8c3Rpci1ib3VuY2VzQGlldGYuLm9yZyBvbiBiZWhhbGYgb2YgY2hyaXMtaWV0 ZkBjaHJpc3dlbmR0Lm5ldD4gd3JvdGU6DQoNCiAgICBXZSBhbHNvIGhhdmUgZXF1aXBtZW50IGlu IHRoZSBuZXR3b3JrIHRoYXQgYWxzbyBoYXMgc2FtZSBiZWhhdmlvci4gSWYgdGhlIGVxdWlwbWVu dCBqdXN0IHRydW5jYXRlZCBvciBqdXN0IHBhc3NlZCB0aGUgSU5WSVRFIHRocm91Z2gsIGl0IHdv dWxkIGJlIGZpbmUsIGJ1dCBnaXZlbiB0aGVyZSBpcyBlcXVpcG1lbnQgdGhhdCBiYXNpY2FsbHkg anVzdCBkcm9wcyBjYWxscywgYW5kIHdyb25nIG9yIHJpZ2h0LCBpdCBkb2VzIHNlZW0gdG8gYmUg YSBwcmV2YWxlbnQgYmVoYXZpb3IsIGtlZXBpbmcgdGhlIG11bHRpcGxlIGlkZW50aXR5IGhlYWRl ciBvcHRpb24gZm9yIGRpdiB3b3VsZCBiZSB0aGUgb25seSBwcmFnbWF0aWMgb3B0aW9uLiANCiAg ICANCiAgICAtQ2hyaXMNCiAgICANCiAgICA+IE9uIE5vdiAyOCwgMjAxOCwgYXQgNzoxOCBQTSwg RE9MTFksIE1BUlRJTiBDIDxtZDMxMzVAYXR0LmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IEpv bg0KICAgID4gDQogICAgPiBGaXJzdCwgdGhhbmtzIGZvciB1bmRlcnN0YW5kaW5nIA0KICAgID4g DQogICAgPiBUbyB5b3VyIHF1ZXN0aW9uLCBhcyBsb3cgYXMgODAwLCB3aXRoIHRoZSBtYWpvciBp c3N1ZSBhdCAxMDAwIG9jdGV0cw0KICAgID4gDQogICAgPiBCcmVhayBOREEgc2F5aW5nIG1vcmUN CiAgICA+IA0KICAgID4gUmVnYXJkcw0KICAgID4gDQogICAgPiBNYXJ0aW4gQyBEb2xseQ0KICAg ID4gQVQmVA0KICAgID4gTGVhZCBNZW1iZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQogICAgPiBHb3Zl cm5tZW50ICYgU2VydmljZXMgU3RhbmRhcmRzDQogICAgPiArMSA2MDkgOTAzIDMzNjANCiAgICA+ IA0KICAgID4+IE9uIE5vdiAyOCwgMjAxOCwgYXQgNzoxMCBQTSwgUGV0ZXJzb24sIEpvbiA8am9u LnBldGVyc29uQHRlYW0ubmV1c3Rhcj4gd3JvdGU6DQogICAgPj4gDQogICAgPj4gDQogICAgPj4g UGVyc29uYWxseSwgSSdtIGZpbmUgd2l0aCBwdXR0aW5nIHRoZSBvcHRpb24gZm9yIGluZGl2aWR1 YWwgSWRlbnRpdHkgaGVhZGVycyBiYWNrIGluLiBJJ3ZlIGJlZW4gdHJ5aW5nIHRvIGRvIHNvbWUg cmV3cml0ZXMgZm9yIGNsYXJpdHkgYWJvdXQgYXV0aGVudGljYXRpb24gc2VydmljZSBhbmQgdmVy aWZpY2F0aW9uIHNlcnZpY2UgYmVoYXZpb3IgZm9yICJkaXYiIGJhc2VkIG9uIHNvbWUgZWFybHkg Y29tbWVudHMsIGFuZCBJJ20gc3VyZSB0aGUgb3JpZ2luYWwgdGV4dCBhYm91dCBuZXN0aW5nIGFu ZCBub24tbmVzdGluZyB3b3VsZCBoYXZlIG5lZWRlZCBhIHNpbWlsYXIgcGF0Y2hpbmcgYW55d2F5 Lg0KICAgID4+IA0KICAgID4+IElkZWFsbHksIGlmIHRoZXJlJ3MgYW55IGZpcm1lciBkYXRhIGZy b20gb3BlcmF0b3IgbmV0d29ya3MgYWJvdXQgd2hhdCB0aGUgc2NhbGUgb2YgdGhlIHByb2JsZW0g aXMgLSBsaWtlIHdoYXQgc2l6ZSBoZWFkZXJzIGFyZSByZWFsbHkgYSBwcm9ibGVtIC0gdGhhdCB3 b3VsZCBiZSBuaWNlIHRvIGtub3cuDQogICAgPj4gDQogICAgPj4gSm9uIFBldGVyc29uDQogICAg Pj4gTmV1c3RhciwgSW5jLg0KICAgID4+IA0KICAgID4+IO+7v09uIDExLzI4LzE4LCAxOjE3IFBN LCAic3RpciBvbiBiZWhhbGYgb2YgRE9MTFksIE1BUlRJTiBDIiA8c3Rpci1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBtZDMxMzVAYXR0LmNvbT4gd3JvdGU6DQogICAgPj4gDQogICAgPj4g ICBHcmVldGluZ3MsDQogICAgPj4gDQogICAgPj4gICBXZSBoYWQgYW4gQVRJUy0gU0lQIEZvcnVt IElQTk5JIG1lZXRpbmcgdG9kYXkuIA0KICAgID4+ICAgU2V2ZXJhbCBvcGVyYXRvcnMgcGVyZm9y bWVkIGxhYiB0ZXN0aW5nIHdpdGggbGFyZ2UgU0lQIGhlYWRlcnMuIEl0IHdhcyBmb3VuZCB0aGF0 IHNvbWUgZGVwbG95ZWQgdmVuZG9yIGVxdWlwbWVudCB3aWxsIGRyb3AgdGhlIFNJUCBJTlZJVEUg aWYgYSBzaW5nbGUgaGVhZGVyIGV4Y2VlZHMgYSBjZXJ0YWluIGxlbmd0aC4NCiAgICA+PiANCiAg ICA+PiAgIFRoZSBJUE5OSSByZXF1ZXN0cyB0aGF0IHRoZSBvcHRpb24gZm9yIHN1cHBvcnQgb2Yg aW5kaXZpZHVhbCBJZGVudGl0eSBoZWFkZXJzIGJlIGFkZGVkIGJhY2sgaW50byBkcmFmdC1pZXRm LXN0aXItcGFzc3BvcnQtZGl2ZXJ0LCBhcyBuZXN0aW5nIG1heSByZXN1bHQgaW4gZmFpbHVyZXMu DQogICAgPj4gDQogICAgPj4gICBUaGFuayB5b3UgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4NCiAg ICA+PiANCiAgICA+PiAgIFJlZ2FyZHMsDQogICAgPj4gDQogICAgPj4gICBNYXJ0aW4gQy4gRG9s bHkNCiAgICA+PiAgIExlYWQgTWVtYmVyIG9mIFRlY2huaWNhbCBTdGFmZg0KICAgID4+ICAgR292 ZXJubWVudCAmIFNlcnZpY2VzIFN0YW5kYXJkcw0KICAgID4+ICAgQVQmVA0KICAgID4+ICAgQ2Vs bDogKzEuNjA5LjkwMy4zMzYwDQogICAgPj4gICBFbWFpbDogbWQzMTM1QGF0dC5jb20NCiAgICA+ PiANCiAgICA+PiANCiAgICA+PiANCiAgICA+PiAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQogICAgPj4gICBGcm9tOiBzdGlyIDxzdGlyLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBP ZiBSb2JlcnQgU3BhcmtzDQogICAgPj4gICBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIzLCAyMDE4 IDI6NTggUE0NCiAgICA+PiAgIFRvOiBzdGlyQGlldGYub3JnDQogICAgPj4gICBTdWJqZWN0OiBS ZTogW3N0aXJdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc3Rpci1wYXNzcG9ydC1kaXZlcnQtMDQu LnR4dA0KICAgID4+IA0KICAgID4+ICAgV2UgcGxhbiB0byBXR0xDIHRoaXMgZG9jdW1lbnQgc2hv cnRseSBhZnRlciB0aGUgQmFuZ2tvayBtZWV0aW5nLCBidXQgaWYgYW55b25lIGhhcyBhbnkgbWFq b3IgaXNzdWVzIHdpdGggaXQsIHBsZWFzZSBicmluZyB0aGVtIHVwIG5vdyBzbyB3ZSBjYW4gd29y ayB0aGVtIG91dCBkdXJpbmcgdGhhdCBtZWV0aW5nLg0KICAgID4+IA0KICAgID4+ICAgUmpTDQog ICAgPj4gDQogICAgPj4gDQogICAgPj4+ICAgT24gMTAvMjIvMTggNzowOCBQTSwgaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KICAgID4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQog ICAgPj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNlY3VyZSBUZWxlcGhvbmUg SWRlbnRpdHkgUmV2aXNpdGVkIFdHIG9mIHRoZSBJRVRGLg0KICAgID4+PiANCiAgICA+Pj4gICAg ICAgIFRpdGxlICAgICAgICAgICA6IFBBU1Nwb3JUIEV4dGVuc2lvbiBmb3IgRGl2ZXJ0ZWQgQ2Fs bHMNCiAgICA+Pj4gICAgICAgIEF1dGhvciAgICAgICAgICA6IEpvbiBQZXRlcnNvbg0KICAgID4+ PiAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc3Rpci1wYXNzcG9ydC1kaXZlcnQtMDQu dHh0DQogICAgPj4+ICAgUGFnZXMgICAgICAgICAgIDogMTINCiAgICA+Pj4gICBEYXRlICAgICAg ICAgICAgOiAyMDE4LTEwLTIyDQogICAgPj4+IA0KICAgID4+PiBBYnN0cmFjdDoNCiAgICA+Pj4g ICBUaGlzIGRvY3VtZW50IGV4dGVuZHMgUEFTU3BvclQsIHdoaWNoIGNvbnZleXMgY3J5cHRvZ3Jh cGhpY2FsbHktDQogICAgPj4+ICAgc2lnbmVkIGluZm9ybWF0aW9uIGFib3V0IHRoZSBwZW9wbGUg aW52b2x2ZWQgaW4gcGVyc29uYWwNCiAgICA+Pj4gICBjb21tdW5pY2F0aW9ucywgdG8gaW5jbHVk ZSBhbiBpbmRpY2F0aW9uIHRoYXQgYSBjYWxsIGhhcyBiZWVuDQogICAgPj4+ICAgZGl2ZXJ0ZWQg ZnJvbSBpdHMgb3JpZ2luYWwgZGVzdGluYXRpb24gdG8gYSBuZXcgb25lLiAgVGhpcw0KICAgID4+ PiAgIGluZm9ybWF0aW9uIGNhbiBncmVhdGx5IGltcHJvdmUgdGhlIGRlY2lzaW9ucyBtYWRlIGJ5 IHZlcmlmaWNhdGlvbg0KICAgID4+PiAgIHNlcnZpY2VzIGluIGNhbGwgZm9yd2FyZGluZyBzY2Vu YXJpb3MuICBBbHNvIHNwZWNpZmllZCBoZXJlIGlzIGFuDQogICAgPj4+ICAgZW5jYXBzdWxhdGlv biBtZWNoYW5pc20gZm9yIG5lc3RpbmcgYSBQQVNTcG9yVCB3aXRoaW4gYW5vdGhlcg0KICAgID4+ PiAgIFBBU1Nwb3JUIHRoYXQgYXNzaXN0cyByZWx5aW5nIHBhcnRpZXMgaW4gc29tZSBkaXZlcnNp b24gc2NlbmFyaW9zLi4NCiAgICA+Pj4gDQogICAgPj4+IA0KICAgID4+PiBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICA+Pj4gaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5p ZXRmLg0KICAgID4+PiBvcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRHN0aXItMkRwYXNzcG9ydC0yRGRp dmVydF8mZD1Ed0lDQWcmYz1MRllaLW85X0hVDQogICAgPj4+IE1lTVRTUWljdmpJZyZyPUc5djh1 Q1NTUWhDbXB3N0l0RzByMmcmbT1yUE1HcTdrdjJCR3VkZmRaaDdPMEtsajFHbElFaTQNCiAgICA+ Pj4gUzRVNlpjdk1EVVhkMCZzPWtkMll6NEdDZ0RLT1N5bXYyYUxZVUFEempSNkFXZmZtblBTWGp1 WVNHWjAmZT0NCiAgICA+Pj4gDQogICAgPj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNp b25zIGF2YWlsYWJsZSBhdDoNCiAgICA+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odA0KICAgID4+PiBtbF9kcmFm dC0yRGlldGYtMkRzdGlyLTJEcGFzc3BvcnQtMkRkaXZlcnQtMkQwNCZkPUR3SUNBZyZjPUxGWVot bzlfSFVNDQogICAgPj4+IGVNVFNRaWN2aklnJnI9Rzl2OHVDU1NRaENtcHc3SXRHMHIyZyZtPXJQ TUdxN2t2MkJHdWRmZFpoN08wS2xqMUdsSUVpNFMNCiAgICA+Pj4gNFU2WmN2TURVWGQwJnM9QlRv UFFJSWtNQ1V6VXJCOFhoaVZDTUZOajdTSkloNDlBSW1kTWNDUnA5YyZlPQ0KICAgID4+PiBodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFj a2VyLmlldGYuDQogICAgPj4+IG9yZ19kb2NfaHRtbF9kcmFmdC0yRGlldGYtMkRzdGlyLTJEcGFz c3BvcnQtMkRkaXZlcnQtMkQwNCZkPUR3SUNBZyZjPUwNCiAgICA+Pj4gRllaLW85X0hVTWVNVFNR aWN2aklnJnI9Rzl2OHVDU1NRaENtcHc3SXRHMHIyZyZtPXJQTUdxN2t2MkJHdWRmZFpoN08wSw0K ICAgID4+PiBsajFHbElFaTRTNFU2WmN2TURVWGQwJnM9UWdPU3VuTUlQNGxONDlGTjc1dzJoTEky UVpNaWw3amFXLVE0aXJZQlhWQSZlDQogICAgPj4+ID0NCiAgICA+Pj4gDQogICAgPj4+IEEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAgICA+Pj4gaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfcmZjZA0KICAgID4+PiBpZmYtM0Z1cmwyLTNEZHJhZnQtMkRpZXRmLTJEc3Rpci0yRHBh c3Nwb3J0LTJEZGl2ZXJ0LTJEMDQmZD1Ed0lDQWcmYz1MDQogICAgPj4+IEZZWi1vOV9IVU1lTVRT UWljdmpJZyZyPUc5djh1Q1NTUWhDbXB3N0l0RzByMmcmbT1yUE1HcTdrdjJCR3VkZmRaaDdPMEsN CiAgICA+Pj4gbGoxR2xJRWk0UzRVNlpjdk1EVVhkMCZzPTU3djlqSGVnQzB5S1FqdGhrcHRMZ3h4 aksyT2dLRm1QWEVoSkZVNURmcG8mZQ0KICAgID4+PiA9DQogICAgPj4+IA0KICAgID4+PiANCiAg ICA+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YgDQogICAgPj4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICA+Pj4g DQogICAgPj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUCBhdDoNCiAgICA+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWZ0cC0zQV9fZnRwLmlldGYub3JnX2ludGVybg0KICAgID4+PiBldC0yRGRyYWZ0c18mZD1E d0lDQWcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9Rzl2OHVDU1NRaENtcHc3SXRHMHIyDQog ICAgPj4+IGcmbT1yUE1HcTdrdjJCR3VkZmRaaDdPMEtsajFHbElFaTRTNFU2WmN2TURVWGQwJnM9 Wk9xMEk2eVpHaXlfUkRHX01VcC0NCiAgICA+Pj4gdnp1QmlCUXJUUGQ1cTQ4TUFCaU94QlkmZT0N CiAgICA+Pj4gDQogICAgPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgPj4+IHN0aXIgbWFpbGluZyBsaXN0DQogICAgPj4+IHN0aXJAaWV0Zi5v cmcNCiAgICA+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbA0KICAgID4+PiBtYW5fbGlzdGluZm9fc3RpciZkPUR3 SUNBZyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1HOXY4dUNTU1FoQ21wdzdJDQogICAgPj4+ IHRHMHIyZyZtPXJQTUdxN2t2MkJHdWRmZFpoN08wS2xqMUdsSUVpNFM0VTZaY3ZNRFVYZDAmcz1a ZW45b0JrdWlGY0JjTTENCiAgICA+Pj4gTW1zNEZLZVZaeHhvaGx4dnJEeko0RHowSEN4dyZlPQ0K ICAgID4+IA0KICAgID4+ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCiAgICA+PiAgIHN0aXIgbWFpbGluZyBsaXN0DQogICAgPj4gICBzdGlyQGlldGYu b3JnDQogICAgPj4gICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3N0aXImZD1Ed0lDQWcmYz1M RllaLW85X0hVTWVNVFNRaWN2aklnJnI9Rzl2OHVDU1NRaENtcHc3SXRHMHIyZyZtPXJQTUdxN2t2 MkJHdWRmZFpoN08wS2xqMUdsSUVpNFM0VTZaY3ZNRFVYZDAmcz1aZW45b0JrdWlGY0JjTTFNbXM0 RktlVlp4eG9obHh2ckR6SjREejBIQ3h3JmU9DQogICAgPj4gDQogICAgPj4gICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+ICAgc3RpciBtYWls aW5nIGxpc3QNCiAgICA+PiAgIHN0aXJAaWV0Zi5vcmcNCiAgICA+PiAgIGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9fc3RpciZkPUR3SUNBZyZjPU1PcHRObFZ0SUVUZURBTENfbFVMcncmcj1kUTUx dExmb0d1dUZqYW5tZmVLQzB3ZVhITk1sOXhabm5zSWl3UmQ2SWdZJm09RnZRWUNuYmZFbHE2VmZE c2YzeFZMb3RmRjBMMmdPYXJPMHNkYzF5SlRyZyZzPTVtekZ5dGtXOWZWVDgya0xPVXNPeGR3TXZx UUVpVHBCWUpUbFZGVmQ2bkkmZT0NCiAgICA+PiANCiAgICA+PiANCiAgICA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBzdGlyIG1haWxpbmcg bGlzdA0KICAgID4gc3RpckBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zdGlyDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICBzdGlyIG1haWxpbmcgbGlzdA0KICAgIHN0aXJAaWV0 Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCiAg ICANCg0KDQoNCg==