From nobody Mon Jul 6 11:51:29 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0371B301E; Mon, 6 Jul 2015 11:51:28 -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] autolearn=ham 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 G2AgJ8qUEzh8; Mon, 6 Jul 2015 11:51:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 837101A8A46; Mon, 6 Jul 2015 11:51:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706185127.15459.61894.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 11:51:27 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-certificates-02.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:51:28 -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 Working Group of the IETF. Title : Secure Telephone Identity Credentials: Certificates Authors : Jon Peterson Sean Turner Filename : draft-ietf-stir-certificates-02.txt Pages : 15 Date : 2015-07-06 Abstract: In order to prove ownership of telephone numbers on the Internet, some kind of public infrastructure needs to exist that binds cryptographic keys to authority over telephone numbers. This document describes a certificate-based credential system for telephone numbers, which could be used as a part of a broader architecture for managing telephone numbers as identities in protocols like SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-certificates-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-certificates-02 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 Mon Jul 6 11:57:33 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DB21B303F; Mon, 6 Jul 2015 11:57:31 -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] autolearn=ham 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 YcuOhGBUbuMX; Mon, 6 Jul 2015 11:57:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F071B3035; Mon, 6 Jul 2015 11:57:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706185730.1582.71207.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 11:57:30 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-rfc4474bis-04.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:57:32 -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 Working Group of the IETF. Title : Authenticated Identity Management in the Session Initiation Protocol (SIP) Authors : Jon Peterson Cullen Jennings Eric Rescorla Filename : draft-ietf-stir-rfc4474bis-04.txt Pages : 34 Date : 2015-07-06 Abstract: The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining new SIP header fields for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the signer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-rfc4474bis-04 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 Mon Jul 6 12:01:41 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4262C1B3037 for ; Mon, 6 Jul 2015 12:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5I0YvZPeZ0-8 for ; Mon, 6 Jul 2015 12:01:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482E91B3047 for ; Mon, 6 Jul 2015 12:01:16 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t66J1FsF036672 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Mon, 6 Jul 2015 14:01:15 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <559AD077.4020009@nostrum.com> Date: Mon, 06 Jul 2015 14:01:11 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: stir@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] Draft agenda STIR IETF93 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:01:39 -0000 Secure Telephone Identity Revistited (STIR) IETF 93 - Monday 1520 Agenda: 10m Administrative - Chairs 50m draft-ietf-stir-rfc4474bis-04 - Jon Peterson 60m draft-ietf-stir-certificates-02 - Jon Peterson From nobody Tue Jul 7 00:35:06 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01641A03E1 for ; Tue, 7 Jul 2015 00:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 8yPdF88wBadg for ; Tue, 7 Jul 2015 00:35:02 -0700 (PDT) Received: from COL004-OMC2S11.hotmail.com (col004-omc2s11.hotmail.com [65.55.34.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999B31A0191 for ; Tue, 7 Jul 2015 00:35:02 -0700 (PDT) Received: from COL125-W23 ([65.55.34.72]) by COL004-OMC2S11.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 7 Jul 2015 00:35:01 -0700 X-TMN: [wr9sIUJrys7136K4TOmIwfkvgloWdOLJ2eKdua2md5g=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_f859b830-c2a7-4524-b7f0-3b4fef440c96_" From: Hui Deng To: "stir@ietf.org" , "zhangchen@cmdi.chinamobile.com" Date: Tue, 7 Jul 2015 15:35:01 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jul 2015 07:35:01.0873 (UTC) FILETIME=[6F27F610:01D0B887] Archived-At: Subject: [stir] FW: New Version Notification for draft-zhang-stir-scenario-issue-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 07:35:04 -0000 --_f859b830-c2a7-4524-b7f0-3b4fef440c96_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsDQogDQpQbGVhc2UgZmVlbCBmcmVlIHRvIGxldCB1cyBrbm93IGlmIHlvdSBoYXZl IGFueSBjb21tZW50IG9uIGl0LA0KIA0KdGhhbmtzIGEgbG90DQogDQpERU5HIEh1aQ0KIA0KCgoN CiAKCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoYW5nLXN0aXItc2NlbmFyaW8taXNz dWUtMDAudHh0CgoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSHVpCkRlbmcg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5LgoKDQogCgoNCk5hbWU6ICAgICAgICAg ICAgICAgZHJhZnQtemhhbmctc3Rpci1zY2VuYXJpby1pc3N1ZQoKDQpSZXZpc2lvbjogIDAwCgoN ClRpdGxlOiAgICAgICAgICAgICAgICAgIElzc3VlCndpdGggY3VycmVudCBTVElSIHNjZW5hcmlv CgoNCkRvY3VtZW50IGRhdGU6ICAgICAgIDIwMTUtMDctMDYKCg0KR3JvdXA6ICAgICAgICAgICAg ICAgSW5kaXZpZHVhbApTdWJtaXNzaW9uCgoNClBhZ2VzOiAgICAgICAgICAgICAgIDUKCg0KVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16 aGFuZy1zdGlyLXNjZW5hcmlvLWlzc3VlLTAwLnR4dFN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1zdGlyLXNjZW5hcmlvLWlzc3VlL0h0 bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc3Rp ci1zY2VuYXJpby1pc3N1ZS0wMAoKDQpBYnN0cmFjdDoKCg0KICAKVGhpcyBkb2N1bWVudCBpbnRy b2R1Y2VzIGNvdXBsZSBvZiBzY2VuYXJpb3MgaGF2ZSBiZWVuIGlkZW50aWZpZWQgdG8gIApmaW5k IG91dCB0aGF0IGNlcnRpZmljYXRlIGJhc2VkIHNvbHV0aW9uIGhhcyBzb21lIGxpbWl0YXRpb24u CgoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YKbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlCmF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4KCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQKDQogCQkgCSAgIAkJICA= --_f859b830-c2a7-4524-b7f0-3b4fef440c96_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsPEJSPiZuYnNwOzxCUj5QbGVhc2UgZmVl bCBmcmVlIHRvIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50IG9uIGl0LDxCUj4m bmJzcDs8QlI+dGhhbmtzIGEgbG90PEJSPiZuYnNwOzxCUj5ERU5HIEh1aTxCUj4mbmJzcDs8QlI+ PGZvbnQgZmFjZT0iy87M5SI+Cgo8L2ZvbnQ+PEJSPjxwIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MHB0OyIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjw/eG1sOm5hbWVz cGFjZSBwcmVmaXggPSBvIG5zID0gInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9m ZmljZSIgLz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGZvbnQgZmFjZT0iy87M5SI+Cgo8 L2ZvbnQ+PEJSPjxwIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyIgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGFu Zy1zdGlyLXNjZW5hcmlvLWlzc3VlLTAwLnR4dDwvc3Bhbj48L3A+PGZvbnQgZmFjZT0iy87M5SI+ Cgo8L2ZvbnQ+PEJSPjxwIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyIgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgSHVpCkRlbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljwvc3Bhbj48 L3A+PGZvbnQgZmFjZT0iy87M5SI+Cgo8L2ZvbnQ+PEJSPjxwIHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMHB0OyIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48Zm9udCBmYWNlPSLLzszlIj4KCjwvZm9udD48QlI+PHAgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IiBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+TmFtZTo8c3BhbiBzdHlsZT0ibXNvLXRhYi1jb3VudDogMjsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ZHJhZnQtemhhbmctc3Rpci1zY2VuYXJpby1pc3N1ZTwv c3Bhbj48L3A+PGZvbnQgZmFjZT0iy87M5SI+Cgo8L2ZvbnQ+PEJSPjxwIHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMHB0OyIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJl dmlzaW9uOjxzcGFuIHN0eWxlPSJtc28tdGFiLWNvdW50OiAxOyI+Jm5ic3A7IDwvc3Bhbj4wMDwv c3Bhbj48L3A+PGZvbnQgZmFjZT0iy87M5SI+Cgo8L2ZvbnQ+PEJSPjxwIHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMHB0OyIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRp dGxlOjxzcGFuIHN0eWxlPSJtc28tdGFiLWNvdW50OiAyOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5Jc3N1ZQp3aXRoIGN1cnJlbnQgU1RJUiBz Y2VuYXJpbzwvc3Bhbj48L3A+PGZvbnQgZmFjZT0iy87M5SI+Cgo8L2ZvbnQ+PEJSPjxwIHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMHB0OyIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPkRvY3VtZW50IGRhdGU6PHNwYW4gc3R5bGU9Im1zby10YWItY291bnQ6IDE7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjIwMTUtMDctMDY8L3NwYW4+ PC9wPjxmb250IGZhY2U9IsvOzOUiPgoKPC9mb250PjxCUj48cCBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDBwdDsiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Hcm91cDo8 c3BhbiBzdHlsZT0ibXNvLXRhYi1jb3VudDogMjsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+SW5kaXZpZHVhbApTdWJtaXNzaW9uPC9zcGFuPjwvcD48Zm9udCBmYWNlPSLLzszl Ij4KCjwvZm9udD48QlI+PHAgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IiBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+UGFnZXM6PHNwYW4gc3R5bGU9Im1zby10YWIt Y291bnQ6IDI7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjU8L3NwYW4+PC9w Pjxmb250IGZhY2U9IsvOzOUiPgoKPC9mb250PjxCUj48cCBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDBwdDsiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5VUkw6PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctc3Rpci1zY2VuYXJp by1pc3N1ZS0wMC50eHQiPjxmb250IGNvbG9yPSIjMDAwMGZmIj5odHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctc3Rpci1zY2VuYXJpby1pc3N1ZS0wMC50eHQ8 L2ZvbnQ+PC9hPjwvc3Bhbj48L3A+PHAgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IiBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+U3RhdHVzOjxzcGFuIHN0eWxlPSJt c28tc3BhY2VydW46IHllczsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtemhhbmctc3Rpci1zY2VuYXJpby1pc3N1ZS8iPjxmb250IGNvbG9yPSIjMDAwMGZm Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1zdGlyLXNjZW5h cmlvLWlzc3VlLzwvZm9udD48L2E+PC9zcGFuPjwvcD48cCBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDBwdDsiIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IdG1saXplZDo8 c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXM7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16aGFuZy1zdGlyLXNjZW5hcmlvLWlzc3VlLTAwIj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXN0aXItc2NlbmFyaW8taXNz dWUtMDA8L2ZvbnQ+PC9hPjwvc3Bhbj48L3A+PGZvbnQgZmFjZT0iy87M5SI+Cgo8L2ZvbnQ+PEJS PjxwIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPkFic3RyYWN0Ojwvc3Bhbj48L3A+PGZvbnQgZmFjZT0iy87M5SI+Cgo8 L2ZvbnQ+PEJSPjxwIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyIgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllczsi PiZuYnNwOyZuYnNwOwo8L3NwYW4+VGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGNvdXBsZSBvZiBz Y2VuYXJpb3MgaGF2ZSBiZWVuIGlkZW50aWZpZWQgdG88L3NwYW4+PC9wPjxwIHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMHB0OyIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllczsiPiZuYnNwOyZuYnNwOwo8L3NwYW4+Zmlu ZCBvdXQgdGhhdCBjZXJ0aWZpY2F0ZSBiYXNlZCBzb2x1dGlvbiBoYXMgc29tZSBsaW1pdGF0aW9u Ljwvc3Bhbj48L3A+PGZvbnQgZmFjZT0iy87M5SI+Cgo8L2ZvbnQ+PEJSPjxwIHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMHB0OyIgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YKbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlCmF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48L3NwYW4+PC9wPjxmb250IGZhY2U9IsvO zOUiPgoKPC9mb250PjxCUj48cCBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsiIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgSUVURiBTZWNyZXRhcmlhdDwvc3Bh bj48L3A+PGZvbnQgZmFjZT0iy87M5SI+CjwvZm9udD48QlI+IAkJIAkgICAJCSAgPC9kaXY+PC9i b2R5Pg0KPC9odG1sPg== --_f859b830-c2a7-4524-b7f0-3b4fef440c96_-- From nobody Tue Jul 7 06:22:41 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769C61A8871 for ; Tue, 7 Jul 2015 06:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=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 YGQmekcmzbTn for ; Tue, 7 Jul 2015 06:22:36 -0700 (PDT) Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) (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 5AA3B1A882A for ; Tue, 7 Jul 2015 06:22:36 -0700 (PDT) Received: by qkbp125 with SMTP id p125so139174119qkb.2 for ; Tue, 07 Jul 2015 06:22:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=O8DHrNkon2OpSD9mxdnSGol+tx7Ogjl8C201j94Rivg=; b=VJqR3YU+U5F7rlPpmKhmCipIYYfDdSxDpSSa0Bv+69rgrYx9Jk6xUda8/k1aamrRLN nW2Qw12S99YQowvUxmpVjlcYvav89CyHGV0/OdKGrnRrB/yGHLquQqntKAr9TCciTUa3 aHCsu9zrlUed7qzoP0eC1TbAw+giToQJ3LRMp71gi469kUSMYvYBOu6/xHc6QWgp1H+A 6MOeWZV6uwf/k9gYSL1YtLYeM3vjTCUIjmUwg8dxt1sXVZjTpXH9CBhFLq1JI67YUy+D eUdrRcTv8AwqJfnP8rv1GStMYqUEIck96byudzvyVEo84t+Fz6hH9Px4Y2pLMwVHSVzV mDzQ== X-Gm-Message-State: ALoCoQmTWzi0wBbvZOcz8NeVx5y7YB5CJc6h5A/i2KeA/JhnwQxhz6JIL1f1jMmdvD3gNOPj7LLC X-Received: by 10.55.19.225 with SMTP id 94mr6582129qkt.37.1436275355627; Tue, 07 Jul 2015 06:22:35 -0700 (PDT) Received: from [10.33.193.32] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id z135sm11079906qhd.29.2015.07.07.06.22.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jul 2015 06:22:35 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_69569638-B98B-4A06-A497-870FD0C517F7" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Brian Rosen In-Reply-To: Date: Tue, 7 Jul 2015 09:22:32 -0400 Message-Id: <4BB93CEE-8E67-4CC9-BAA8-BC4C2A6D33DF@brianrosen.net> References: To: Hui Deng X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "stir@ietf.org" , "zhangchen@cmdi.chinamobile.com" Subject: Re: [stir] FW: New Version Notification for draft-zhang-stir-scenario-issue-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 13:22:38 -0000 --Apple-Mail=_69569638-B98B-4A06-A497-870FD0C517F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The canonicalization of the telephone number that is required to = generate the signature would result in both scenarios failing. Even if = the terminal does not send the country code or prefix (area code), it is = part if the calculation of the canonical number that is signed. I = believe this addresses all the scenarios raised in your draft: In Figure 1=E2=80=99s call, I=E2=80=99m confused about who signs. If = it=E2=80=99s the IPBX, then it would have to have the private key for = the canonicalized 10086, which you said was a service number. If it=E2=80= =99s the MSC that is signing, and 10086 is a service number, first of = all, it should not accept a call from the IPBX with a service number as = a calling party number, but even if it did, it would add the country = code to it before it was signed. Any attempt to verify a signature with = a different prefix would fail. In Figure 2, the MSC creates the signature for the original telephone = number,1335678432. When the VoLTE AS changes it, the validation will = fail. =20 In 2., the original number would be canonicalized - any leading zero = removed, country code added. When that is signed, it cannot be used to = validate a call that appears to be from a service number from a = different country, because the canonicalization of that number is = different, and thus the signature check would fail. In 3, the original call with a hidden number has to be sent as an = anonymous call, which is handled in the text. There is no signature on = such a call. I am not sure how IMS handles anonymous calls, but the = scenario you describe, where calling elements are adding prefixes and = country codes to a blank number is surely not what anyone envisions for = anonymous calls.=20 Brian > On Jul 7, 2015, at 3:35 AM, Hui Deng wrote: >=20 > Hello all > =20 > Please feel free to let us know if you have any comment on it, > =20 > thanks a lot > =20 > DENG Hui > =20 >=20 > =20 >=20 > A new version of I-D, draft-zhang-stir-scenario-issue-00.txt >=20 > has been successfully submitted by Hui Deng and posted to the IETF = repository. >=20 > =20 >=20 > Name: draft-zhang-stir-scenario-issue >=20 > Revision: 00 >=20 > Title: Issue with current STIR scenario >=20 > Document date: 2015-07-06 >=20 > Group: Individual Submission >=20 > Pages: 5 >=20 > URL: = https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-issue-00.tx= t = > Status: = https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issue/ = > Htmlized: = https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00 = > Abstract: >=20 > This document introduces couple of scenarios have been identified = to > find out that certificate based solution has some limitation. >=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 > The IETF Secretariat >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_69569638-B98B-4A06-A497-870FD0C517F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The canonicalization of the telephone number that is required = to generate the signature would result in both scenarios failing. =  Even if the terminal does not send the country code or prefix = (area code), it is part if the calculation of the canonical number that = is signed.  I believe this addresses all the scenarios raised in = your draft:

In = Figure 1=E2=80=99s call, I=E2=80=99m confused about who signs.  If = it=E2=80=99s the IPBX, then it would have to have the private key for = the canonicalized 10086, which you said was a service number.  If = it=E2=80=99s the MSC that is signing, and 10086 is a service number, = first of all, it should not accept a call from the IPBX with a service = number as a calling party number, but even if it did, it would add the = country code to it before it was signed.  Any attempt to verify a = signature with a different prefix would fail.

In Figure 2, the MSC creates the = signature for the original telephone number,1335678432.  When = the VoLTE AS changes it, the validation will fail.  

In 2., the original = number would be canonicalized - any leading zero removed, country code = added.  When that is signed, it cannot be used to validate a call = that appears to be from a service number from a different country, = because the canonicalization of that number is different, and thus the = signature check would fail.

In 3, the original call with a hidden number has to be sent = as an anonymous call, which is handled in the text.  There is no = signature on such a call.  I am not sure how IMS handles anonymous = calls, but the scenario you describe, where calling elements are adding = prefixes and country codes to a blank number is surely not what anyone = envisions for anonymous calls. 

Brian


On = Jul 7, 2015, at 3:35 AM, Hui Deng <denghui02@hotmail.com> wrote:

Hello all
 
Please feel free to let us know if you = have any comment on it,
 
thanks a = lot
 
DENG Hui
 

 

A new version of I-D, = draft-zhang-stir-scenario-issue-00.txt

has = been successfully submitted by Hui Deng and posted to the IETF = repository.

 

Name:          &nb= sp;    draft-zhang-stir-scena= rio-issue

Revision:  00

Title:          &nb= sp;       Issue with current = STIR scenario

Document = date:       2015-07-06
Group:          &nb= sp;    Individual = Submission

Pages:          &nb= sp;    5

URL:          &nb= sp; https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-= issue-00.txt
Status:         https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issu= e/
Htmlized:       https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00<= /font>

Abstract:

   This document = introduces couple of scenarios have been identified to
   find out that = certificate based solution has some limitation.

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.

The IETF = Secretariat

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

= --Apple-Mail=_69569638-B98B-4A06-A497-870FD0C517F7-- From nobody Tue Jul 7 20:53:46 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7051B2E32 for ; Tue, 7 Jul 2015 20:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.221 X-Spam-Level: * X-Spam-Status: No, score=1.221 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ZWAdmbh5ImOG for ; Tue, 7 Jul 2015 20:53:36 -0700 (PDT) Received: from COL004-OMC2S3.hotmail.com (col004-omc2s3.hotmail.com [65.55.34.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10AAD1B2E2D for ; Tue, 7 Jul 2015 20:53:36 -0700 (PDT) Received: from COL125-W41 ([65.55.34.71]) by COL004-OMC2S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 7 Jul 2015 20:53:35 -0700 X-TMN: [xzlnDJO3ClcmvkXyahgYP5IFWr3GWMkMQXNazDLxMNQ=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_1aa34a79-0f13-4d3a-9b29-408d4a48809d_" From: Hui Deng To: Brian Rosen Date: Wed, 8 Jul 2015 11:53:35 +0800 Importance: Normal In-Reply-To: <4BB93CEE-8E67-4CC9-BAA8-BC4C2A6D33DF@brianrosen.net> References: , <4BB93CEE-8E67-4CC9-BAA8-BC4C2A6D33DF@brianrosen.net> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jul 2015 03:53:35.0176 (UTC) FILETIME=[AA14A480:01D0B931] Archived-At: Cc: "stir@ietf.org" , "zhangchen@cmdi.chinamobile.com" Subject: Re: [stir] FW: New Version Notification for draft-zhang-stir-scenario-issue-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 03:53:44 -0000 --_1aa34a79-0f13-4d3a-9b29-408d4a48809d_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQogSGkgQnJpYW4sDQogDQpUaGlzIGRvY3VtZW50IGlzIG1vc3RseSB0YWxraW5nIGFib3V0IGxv dHMgb2YgQWZyaWNhbi9Tb3V0aCBBbWVyaWNhbi8gU291dGggZWFzdCBBc2lhbi8gQ291bnRyaWVz LCB0aGV5IGRvbid0IHNpZ24gdGhlaXIgbnVtYmVyLCB0aGF0IGNhdXNlIHNvbWUgaXNzdWVzLg0K aW5saW5lID09ID4gcGxlYXNlDQpGcm9tOiBickBicmlhbnJvc2VuLm5ldA0KRGF0ZTogVHVlLCA3 IEp1bCAyMDE1IDA5OjIyOjMyIC0wNDAwDQpUbzogZGVuZ2h1aTAyQGhvdG1haWwuY29tDQpDQzog c3RpckBpZXRmLm9yZzsgemhhbmdjaGVuQGNtZGkuY2hpbmFtb2JpbGUuY29tDQpTdWJqZWN0OiBS ZTogW3N0aXJdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpoYW5nLXN0 aXItc2NlbmFyaW8taXNzdWUtMDAudHh0DQoNClRoZSBjYW5vbmljYWxpemF0aW9uIG9mIHRoZSB0 ZWxlcGhvbmUgbnVtYmVyIHRoYXQgaXMgcmVxdWlyZWQgdG8gZ2VuZXJhdGUgdGhlIHNpZ25hdHVy ZSB3b3VsZCByZXN1bHQgaW4gYm90aCBzY2VuYXJpb3MgZmFpbGluZy4gIEV2ZW4gaWYgdGhlIHRl cm1pbmFsIGRvZXMgbm90IHNlbmQgdGhlIGNvdW50cnkgY29kZSBvciBwcmVmaXggKGFyZWEgY29k ZSksIGl0IGlzIHBhcnQgaWYgdGhlIGNhbGN1bGF0aW9uIG9mIHRoZSBjYW5vbmljYWwgbnVtYmVy IHRoYXQgaXMgc2lnbmVkLiAgSSBiZWxpZXZlIHRoaXMgYWRkcmVzc2VzIGFsbCB0aGUgc2NlbmFy aW9zIHJhaXNlZCBpbiB5b3VyIGRyYWZ0Oj09ID4gYXMgd2Ugc2FpZCwgdGhleSBkb24ndCBzaWdu LCBzbyB3aGF0ZXZlciBjb3VudHJ5IGNvZGUgb3IgcHJlZml4IHdlIGFkZC4NCkluIEZpZ3VyZSAx oa9zIGNhbGwsIEmhr20gY29uZnVzZWQgYWJvdXQgd2hvIHNpZ25zLiAgSWYgaXShr3MgdGhlIElQ QlgsIHRoZW4gaXQgd291bGQgaGF2ZSB0byBoYXZlIHRoZSBwcml2YXRlIGtleSBmb3IgdGhlIGNh bm9uaWNhbGl6ZWQgMTAwODYsIHdoaWNoIHlvdSBzYWlkIHdhcyBhIHNlcnZpY2UgbnVtYmVyLiAg SWYgaXShr3MgdGhlIE1TQyB0aGF0IGlzIHNpZ25pbmcsIGFuZCAxMDA4NiBpcyBhIHNlcnZpY2Ug bnVtYmVyLCBmaXJzdCBvZiBhbGwsIGl0IHNob3VsZCBub3QgYWNjZXB0IGEgY2FsbCBmcm9tIHRo ZSBJUEJYIHdpdGggYSBzZXJ2aWNlIG51bWJlciBhcyBhIGNhbGxpbmcgcGFydHkgbnVtYmVyLCBi dXQgZXZlbiBpZiBpdCBkaWQsIGl0IHdvdWxkIGFkZCB0aGUgY291bnRyeSBjb2RlIHRvIGl0IGJl Zm9yZSBpdCB3YXMgc2lnbmVkLiAgQW55IGF0dGVtcHQgdG8gdmVyaWZ5IGEgc2lnbmF0dXJlIHdp dGggYSBkaWZmZXJlbnQgcHJlZml4IHdvdWxkIGZhaWwuPT0gPiBzYW1lIGhlcmUsIHRoZXkgZG9u JyBzaWduIHRoZWlyIG51bWJlciBpbiB0aGVpciBjb3VudHJ5Lg0KSW4gRmlndXJlIDIsIHRoZSBN U0MgY3JlYXRlcyB0aGUgc2lnbmF0dXJlIGZvciB0aGUgb3JpZ2luYWwgdGVsZXBob25lIG51bWJl ciwxMzM1Njc4NDMyLiAgV2hlbiB0aGUgVm9MVEUgQVMgY2hhbmdlcyBpdCwgdGhlIHZhbGlkYXRp b24gd2lsbCBmYWlsLiAgPT0gPiBpZiB0aGV5IGRvbid0ICwgd2hhdCB3ZSBjYW4gZG8/DQpJbiAy LiwgdGhlIG9yaWdpbmFsIG51bWJlciB3b3VsZCBiZSBjYW5vbmljYWxpemVkIC0gYW55IGxlYWRp bmcgemVybyByZW1vdmVkLCBjb3VudHJ5IGNvZGUgYWRkZWQuICBXaGVuIHRoYXQgaXMgc2lnbmVk LCBpdCBjYW5ub3QgYmUgdXNlZCB0byB2YWxpZGF0ZSBhIGNhbGwgdGhhdCBhcHBlYXJzIHRvIGJl IGZyb20gYSBzZXJ2aWNlIG51bWJlciBmcm9tIGEgZGlmZmVyZW50IGNvdW50cnksIGJlY2F1c2Ug dGhlIGNhbm9uaWNhbGl6YXRpb24gb2YgdGhhdCBudW1iZXIgaXMgZGlmZmVyZW50LCBhbmQgdGh1 cyB0aGUgc2lnbmF0dXJlIGNoZWNrIHdvdWxkIGZhaWwuPT0gPiBzYW1lIGhlcmUuDQpJbiAzLCB0 aGUgb3JpZ2luYWwgY2FsbCB3aXRoIGEgaGlkZGVuIG51bWJlciBoYXMgdG8gYmUgc2VudCBhcyBh biBhbm9ueW1vdXMgY2FsbCwgd2hpY2ggaXMgaGFuZGxlZCBpbiB0aGUgdGV4dC4gIFRoZXJlIGlz IG5vIHNpZ25hdHVyZSBvbiBzdWNoIGEgY2FsbC4gIEkgYW0gbm90IHN1cmUgaG93IElNUyBoYW5k bGVzIGFub255bW91cyBjYWxscywgYnV0IHRoZSBzY2VuYXJpbyB5b3UgZGVzY3JpYmUsIHdoZXJl IGNhbGxpbmcgZWxlbWVudHMgYXJlIGFkZGluZyBwcmVmaXhlcyBhbmQgY291bnRyeSBjb2RlcyB0 byBhIGJsYW5rIG51bWJlciBpcyBzdXJlbHkgbm90IHdoYXQgYW55b25lIGVudmlzaW9ucyBmb3Ig YW5vbnltb3VzIGNhbGxzLiA9PSA+IHRvZGF5IG9wZXJhdG9ycyB3b3VsZCBsaWtlIGdldCBhcyBt dWNoIGFzIGludGVybmF0aW9uYWwgcm9hbWluZyB3aXRob3V0IGNoZWNraW5nIHRoZWlyIHNpZ24s IHRoYXQncyB0aGUgc2l0dWF0aW9uIGZvciByZWFsIGNvbW1lcmljYWwgZGVwbG95bWVudC4gQnJp YW4NCj09ID4gdGhhbmtzIGEgIGZvciB5b3IgY29tbWVudHMuIEJlc3QgcmVnYXJkcywgREVORyBI dWkNCg0KDQpPbiBKdWwgNywgMjAxNSwgYXQgMzozNSBBTSwgSHVpIERlbmcgPGRlbmdodWkwMkBo b3RtYWlsLmNvbT4gd3JvdGU6SGVsbG8gYWxsDQogDQpQbGVhc2UgZmVlbCBmcmVlIHRvIGxldCB1 cyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50IG9uIGl0LA0KIA0KdGhhbmtzIGEgbG90DQog DQpERU5HIEh1aQ0KIA0KDQogDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtemhhbmctc3Rp ci1zY2VuYXJpby1pc3N1ZS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgSHVpIERlbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KIA0KTmFtZTog ICAgICAgICAgICAgICBkcmFmdC16aGFuZy1zdGlyLXNjZW5hcmlvLWlzc3VlDQpSZXZpc2lvbjog IDAwDQpUaXRsZTogICAgICAgICAgICAgICAgICBJc3N1ZSB3aXRoIGN1cnJlbnQgU1RJUiBzY2Vu YXJpbw0KRG9jdW1lbnQgZGF0ZTogICAgICAgMjAxNS0wNy0wNg0KR3JvdXA6ICAgICAgICAgICAg ICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgICAgICA1DQpVUkw6ICAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpoYW5n LXN0aXItc2NlbmFyaW8taXNzdWUtMDAudHh0U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLXN0aXItc2NlbmFyaW8taXNzdWUvSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zdGlyLXNj ZW5hcmlvLWlzc3VlLTAwDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBj b3VwbGUgb2Ygc2NlbmFyaW9zIGhhdmUgYmVlbiBpZGVudGlmaWVkIHRvICAgZmluZCBvdXQgdGhh dCBjZXJ0aWZpY2F0ZSBiYXNlZCBzb2x1dGlvbiBoYXMgc29tZSBsaW1pdGF0aW9uLg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fc3RpciBtYWlsaW5nIGxpc3Rz dGlyQGlldGYub3JnaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnN0aXIgbWFp bGluZyBsaXN0CnN0aXJAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zdGlyIAkJIAkgICAJCSAg --_1aa34a79-0f13-4d3a-9b29-408d4a48809d_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+PGJyPiZuYnNwO0hpIEJyaWFuLDxCUj4mbmJzcDs8QlI+ VGhpcyBkb2N1bWVudCBpcyBtb3N0bHkgdGFsa2luZyBhYm91dCBsb3RzIG9mIEFmcmljYW4vU291 dGggQW1lcmljYW4vIFNvdXRoIGVhc3QgQXNpYW4vIENvdW50cmllcywgdGhleSBkb24ndCBzaWdu IHRoZWlyIG51bWJlciwgdGhhdCBjYXVzZSBzb21lIGlzc3Vlcy48QlI+aW5saW5lID09ICZndDsm bmJzcDtwbGVhc2U8QlI+PGRpdj48aHIgaWQ9InN0b3BTcGVsbGluZyI+RnJvbTogYnJAYnJpYW5y b3Nlbi5uZXQ8YnI+RGF0ZTogVHVlLCA3IEp1bCAyMDE1IDA5OjIyOjMyIC0wNDAwPGJyPlRvOiBk ZW5naHVpMDJAaG90bWFpbC5jb208YnI+Q0M6IHN0aXJAaWV0Zi5vcmc7IHpoYW5nY2hlbkBjbWRp LmNoaW5hbW9iaWxlLmNvbTxicj5TdWJqZWN0OiBSZTogW3N0aXJdIEZXOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXpoYW5nLXN0aXItc2NlbmFyaW8taXNzdWUtMDAudHh0PGJy Pjxicj5UaGUgY2Fub25pY2FsaXphdGlvbiBvZiB0aGUgdGVsZXBob25lIG51bWJlciB0aGF0IGlz IHJlcXVpcmVkIHRvIGdlbmVyYXRlIHRoZSBzaWduYXR1cmUgd291bGQgcmVzdWx0IGluIGJvdGgg c2NlbmFyaW9zIGZhaWxpbmcuICZuYnNwO0V2ZW4gaWYgdGhlIHRlcm1pbmFsIGRvZXMgbm90IHNl bmQgdGhlIGNvdW50cnkgY29kZSBvciBwcmVmaXggKGFyZWEgY29kZSksIGl0IGlzIHBhcnQgaWYg dGhlIGNhbGN1bGF0aW9uIG9mIHRoZSBjYW5vbmljYWwgbnVtYmVyIHRoYXQgaXMgc2lnbmVkLiAm bmJzcDtJIGJlbGlldmUgdGhpcyBhZGRyZXNzZXMgYWxsIHRoZSBzY2VuYXJpb3MgcmFpc2VkIGlu IHlvdXIgZHJhZnQ6PGRpdj49PSAmZ3Q7IGFzIHdlIHNhaWQsIHRoZXkgZG9uJ3Qgc2lnbiwgc28g d2hhdGV2ZXIgY291bnRyeSBjb2RlIG9yIHByZWZpeCB3ZSBhZGQuPGJyPjwvZGl2PjxkaXY+SW4g RmlndXJlIDGhr3MgY2FsbCwgSaGvbSBjb25mdXNlZCBhYm91dCB3aG8gc2lnbnMuICZuYnNwO0lm IGl0oa9zIHRoZSBJUEJYLCB0aGVuIGl0IHdvdWxkIGhhdmUgdG8gaGF2ZSB0aGUgcHJpdmF0ZSBr ZXkgZm9yIHRoZSBjYW5vbmljYWxpemVkIDEwMDg2LCB3aGljaCB5b3Ugc2FpZCB3YXMgYSBzZXJ2 aWNlIG51bWJlci4gJm5ic3A7SWYgaXShr3MgdGhlIE1TQyB0aGF0IGlzIHNpZ25pbmcsIGFuZCAx MDA4NiBpcyBhIHNlcnZpY2UgbnVtYmVyLCBmaXJzdCBvZiBhbGwsIGl0IHNob3VsZCBub3QgYWNj ZXB0IGEgY2FsbCBmcm9tIHRoZSBJUEJYIHdpdGggYSBzZXJ2aWNlIG51bWJlciBhcyBhIGNhbGxp bmcgcGFydHkgbnVtYmVyLCBidXQgZXZlbiBpZiBpdCBkaWQsIGl0IHdvdWxkIGFkZCB0aGUgY291 bnRyeSBjb2RlIHRvIGl0IGJlZm9yZSBpdCB3YXMgc2lnbmVkLiAmbmJzcDtBbnkgYXR0ZW1wdCB0 byB2ZXJpZnkgYSBzaWduYXR1cmUgd2l0aCBhIGRpZmZlcmVudCBwcmVmaXggd291bGQgZmFpbC48 L2Rpdj48ZGl2Pj09ICZndDsgc2FtZSBoZXJlLCB0aGV5IGRvbicgc2lnbiB0aGVpciBudW1iZXIg aW4gdGhlaXIgY291bnRyeS48YnI+PC9kaXY+PGRpdj5JbiBGaWd1cmUgMiwgdGhlIE1TQyBjcmVh dGVzIHRoZSBzaWduYXR1cmUgZm9yIHRoZSBvcmlnaW5hbCB0ZWxlcGhvbmUgbnVtYmVyLDxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEzLjMzcHg7IHdpZG93czogMTsiPjEzMzU2Nzg0MzI8L3NwYW4+ LiAmbmJzcDtXaGVuIHRoZSBWb0xURSBBUyBjaGFuZ2VzIGl0LCB0aGUgdmFsaWRhdGlvbiB3aWxs IGZhaWwuICZuYnNwOzwvZGl2PjxkaXY+PT0mbmJzcDsmZ3Q7IGlmIHRoZXkgZG9uJ3QgLCB3aGF0 IHdlIGNhbiBkbz88YnI+PC9kaXY+PGRpdj5JbiAyLiwgdGhlIG9yaWdpbmFsIG51bWJlciB3b3Vs ZCBiZSBjYW5vbmljYWxpemVkIC0gYW55IGxlYWRpbmcgemVybyByZW1vdmVkLCBjb3VudHJ5IGNv ZGUgYWRkZWQuICZuYnNwO1doZW4gdGhhdCBpcyBzaWduZWQsIGl0IGNhbm5vdCBiZSB1c2VkIHRv IHZhbGlkYXRlIGEgY2FsbCB0aGF0IGFwcGVhcnMgdG8gYmUgZnJvbSBhIHNlcnZpY2UgbnVtYmVy IGZyb20gYSBkaWZmZXJlbnQgY291bnRyeSwgYmVjYXVzZSB0aGUgY2Fub25pY2FsaXphdGlvbiBv ZiB0aGF0IG51bWJlciBpcyBkaWZmZXJlbnQsIGFuZCB0aHVzIHRoZSBzaWduYXR1cmUgY2hlY2sg d291bGQgZmFpbC48L2Rpdj48ZGl2Pj09ICZndDsgc2FtZSBoZXJlLjxicj48L2Rpdj48ZGl2Pklu IDMsIHRoZSBvcmlnaW5hbCBjYWxsIHdpdGggYSBoaWRkZW4gbnVtYmVyIGhhcyB0byBiZSBzZW50 IGFzIGFuIGFub255bW91cyBjYWxsLCB3aGljaCBpcyBoYW5kbGVkIGluIHRoZSB0ZXh0LiAmbmJz cDtUaGVyZSBpcyBubyBzaWduYXR1cmUgb24gc3VjaCBhIGNhbGwuICZuYnNwO0kgYW0gbm90IHN1 cmUgaG93IElNUyBoYW5kbGVzIGFub255bW91cyBjYWxscywgYnV0IHRoZSBzY2VuYXJpbyB5b3Ug ZGVzY3JpYmUsIHdoZXJlIGNhbGxpbmcgZWxlbWVudHMgYXJlIGFkZGluZyBwcmVmaXhlcyBhbmQg Y291bnRyeSBjb2RlcyB0byBhIGJsYW5rIG51bWJlciBpcyBzdXJlbHkgbm90IHdoYXQgYW55b25l IGVudmlzaW9ucyBmb3IgYW5vbnltb3VzIGNhbGxzLiZuYnNwOzwvZGl2PjxkaXY+PGRpdj49PSAm Z3Q7IHRvZGF5IG9wZXJhdG9ycyB3b3VsZCBsaWtlIGdldCBhcyBtdWNoIGFzIGludGVybmF0aW9u YWwgcm9hbWluZyB3aXRob3V0IGNoZWNraW5nIHRoZWlyIHNpZ24sIHRoYXQncyB0aGUgc2l0dWF0 aW9uIGZvciByZWFsIGNvbW1lcmljYWwgZGVwbG95bWVudC48L2Rpdj48ZGl2PiZuYnNwOzwvZGl2 PjxkaXY+QnJpYW48YnI+PC9kaXY+PGRpdj48ZGl2Pj09ICZndDsgPGRpdj50aGFua3MgYSAgZm9y IHlvciBjb21tZW50cy48L2Rpdj48ZGl2PiA8L2Rpdj48ZGl2PkJlc3QgcmVnYXJkcyw8L2Rpdj48 ZGl2PiA8L2Rpdj48ZGl2PkRFTkcgSHVpPGJyPjxicj48L2Rpdj48L2Rpdj48ZGl2Pjxicj48ZGl2 PjxibG9ja3F1b3RlPjxkaXY+T24gSnVsIDcsIDIwMTUsIGF0IDM6MzUgQU0sIEh1aSBEZW5nICZs dDs8YSBocmVmPSJtYWlsdG86ZGVuZ2h1aTAyQGhvdG1haWwuY29tIj5kZW5naHVpMDJAaG90bWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9ImVjeEFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPjxkaXY+PGRpdiBzdHlsZT0iZm9udDogMTZweC9ub3JtYWwgQ2FsaWJyaTsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyIgZGlyPSJsdHIiPkhl bGxvIGFsbDxicj4mbmJzcDs8YnI+UGxlYXNlIGZlZWwgZnJlZSB0byBsZXQgdXMga25vdyBpZiB5 b3UgaGF2ZSBhbnkgY29tbWVudCBvbiBpdCw8YnI+Jm5ic3A7PGJyPnRoYW5rcyBhIGxvdDxicj4m bmJzcDs8YnI+REVORyBIdWk8YnI+Jm5ic3A7PGJyPjxmb250IGZhY2U9IsvOzOUiPjwvZm9udD48 YnI+PGRpdiBzdHlsZT0icGFkZGluZzogMHB4OyI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48L2Rpdj48Zm9udCBmYWNlPSLLzszlIj48L2ZvbnQ+PGJyPjxkaXYgc3R5bGU9InBhZGRp bmc6IDBweDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt emhhbmctc3Rpci1zY2VuYXJpby1pc3N1ZS0wMC50eHQ8L3NwYW4+PC9kaXY+PGZvbnQgZmFjZT0i y87M5SI+PC9mb250Pjxicj48ZGl2IHN0eWxlPSJwYWRkaW5nOiAwcHg7Ij48c3BhbiBsYW5nPSJF Ti1VUyI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBIdWkgRGVuZyBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPC9zcGFuPjwvZGl2Pjxmb250IGZhY2U9IsvOzOUi PjwvZm9udD48YnI+PGRpdiBzdHlsZT0icGFkZGluZzogMHB4OyI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48L2Rpdj48Zm9udCBmYWNlPSLLzszlIj48L2ZvbnQ+PGJyPjxkaXYgc3R5 bGU9InBhZGRpbmc6IDBweDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5OYW1lOjxzcGFuPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJlY3hBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+ZHJhZnQtemhhbmctc3Rpci1zY2VuYXJpby1pc3N1ZTwvc3Bh bj48L2Rpdj48Zm9udCBmYWNlPSLLzszlIj48L2ZvbnQ+PGJyPjxkaXYgc3R5bGU9InBhZGRpbmc6 IDBweDsiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXZpc2lvbjo8c3Bhbj4mbmJzcDs8c3BhbiBjbGFz cz0iZWN4QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjAwPC9zcGFu PjwvZGl2Pjxmb250IGZhY2U9IsvOzOUiPjwvZm9udD48YnI+PGRpdiBzdHlsZT0icGFkZGluZzog MHB4OyI+PHNwYW4gbGFuZz0iRU4tVVMiPlRpdGxlOjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJlY3hBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+SXNzdWUgd2l0aCBjdXJyZW50IFNUSVIgc2NlbmFy aW88L3NwYW4+PC9kaXY+PGZvbnQgZmFjZT0iy87M5SI+PC9mb250Pjxicj48ZGl2IHN0eWxlPSJw YWRkaW5nOiAwcHg7Ij48c3BhbiBsYW5nPSJFTi1VUyI+RG9jdW1lbnQgZGF0ZTo8c3Bhbj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZWN4QXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjIwMTUtMDctMDY8L3NwYW4+PC9kaXY+ PGZvbnQgZmFjZT0iy87M5SI+PC9mb250Pjxicj48ZGl2IHN0eWxlPSJwYWRkaW5nOiAwcHg7Ij48 c3BhbiBsYW5nPSJFTi1VUyI+R3JvdXA6PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImVjeEFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj5JbmRpdmlkdWFsIFN1Ym1pc3Npb248L3NwYW4+PC9kaXY+PGZvbnQgZmFjZT0iy87M5SI+PC9m b250Pjxicj48ZGl2IHN0eWxlPSJwYWRkaW5nOiAwcHg7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UGFn ZXM6PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImVjeEFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj41PC9zcGFuPjwvZGl2Pjxmb250 IGZhY2U9IsvOzOUiPjwvZm9udD48YnI+PGRpdiBzdHlsZT0icGFkZGluZzogMHB4OyI+PHNwYW4g bGFuZz0iRU4tVVMiPlVSTDo8c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZWN4QXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGFuZy1zdGlyLXNjZW5hcmlvLWlzc3VlLTAw LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPjxmb250IGNvbG9yPSIjMDAwMGZmIj5odHRwczovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctc3Rpci1zY2VuYXJpby1pc3N1ZS0w MC50eHQ8L2ZvbnQ+PC9hPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJwYWRkaW5nOiAwcHg7Ij48 c3BhbiBsYW5nPSJFTi1VUyI+U3RhdHVzOjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJlY3hBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtemhhbmctc3Rpci1zY2VuYXJpby1pc3N1ZS8iIHRhcmdldD0iX2JsYW5r Ij48Zm9udCBjb2xvcj0iIzAwMDBmZiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtemhhbmctc3Rpci1zY2VuYXJpby1pc3N1ZS88L2ZvbnQ+PC9hPjwvc3Bhbj48L2Rpdj48 ZGl2IHN0eWxlPSJwYWRkaW5nOiAwcHg7Ij48c3BhbiBsYW5nPSJFTi1VUyI+SHRtbGl6ZWQ6PHNw YW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImVjeEFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc3Rpci1zY2VuYXJpby1pc3N1ZS0wMCIg dGFyZ2V0PSJfYmxhbmsiPjxmb250IGNvbG9yPSIjMDAwMGZmIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtemhhbmctc3Rpci1zY2VuYXJpby1pc3N1ZS0wMDwvZm9udD48L2E+PC9z cGFuPjwvZGl2Pjxmb250IGZhY2U9IsvOzOUiPjwvZm9udD48YnI+PGRpdiBzdHlsZT0icGFkZGlu ZzogMHB4OyI+PHNwYW4gbGFuZz0iRU4tVVMiPkFic3RyYWN0Ojwvc3Bhbj48L2Rpdj48Zm9udCBm YWNlPSLLzszlIj48L2ZvbnQ+PGJyPjxkaXYgc3R5bGU9InBhZGRpbmc6IDBweDsiPjxzcGFuIGxh bmc9IkVOLVVTIj48c3Bhbj4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iZWN4QXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPlRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBj b3VwbGUgb2Ygc2NlbmFyaW9zIGhhdmUgYmVlbiBpZGVudGlmaWVkIHRvPC9zcGFuPjwvZGl2Pjxk aXYgc3R5bGU9InBhZGRpbmc6IDBweDsiPjxzcGFuIGxhbmc9IkVOLVVTIj48c3Bhbj4mbmJzcDsm bmJzcDs8c3BhbiBjbGFzcz0iZWN4QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPmZpbmQgb3V0IHRoYXQgY2VydGlmaWNhdGUgYmFzZWQgc29sdXRpb24gaGFzIHNvbWUg bGltaXRhdGlvbi48L3NwYW4+PC9kaXY+PGZvbnQgZmFjZT0iy87M5SI+PC9mb250Pjxicj48ZGl2 IHN0eWxlPSJwYWRkaW5nOiAwcHg7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 PHNwYW4gY2xhc3M9ImVjeEFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy8iIHRhcmdldD0iX2JsYW5rIj50b29scy5pZXRmLm9y ZzwvYT4uPC9zcGFuPjwvZGl2Pjxmb250IGZhY2U9IsvOzOUiPjwvZm9udD48YnI+PGRpdiBzdHls ZT0icGFkZGluZzogMHB4OyI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBJRVRGIFNlY3JldGFyaWF0 PC9zcGFuPjwvZGl2Pjxmb250IGZhY2U9IsvOzOUiPjwvZm9udD48YnI+PC9kaXY+PHNwYW4gc3R5 bGU9ImZvbnQ6IDE2cHgvbm9ybWFsIENhbGlicmk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0 LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg ZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IHdoaXRlLXNwYWNlOiBub3JtYWw7Ij5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQ6IDE2cHgvbm9ybWFsIENhbGlicmk7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWlu ZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hp dGUtc3BhY2U6IG5vcm1hbDsiPjxzcGFuIHN0eWxlPSJmb250OiAxNnB4L25vcm1hbCBDYWxpYnJp OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyI+c3RpciBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJm b250OiAxNnB4L25vcm1hbCBDYWxpYnJpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRl bnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRl LXNwYWNlOiBub3JtYWw7Ij48YSBzdHlsZT0iZm9udDogMTZweC9ub3JtYWwgQ2FsaWJyaTsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyIgaHJlZj0ibWFpbHRv OnN0aXJAaWV0Zi5vcmciPnN0aXJAaWV0Zi5vcmc8L2E+PGJyIHN0eWxlPSJmb250OiAxNnB4L25v cm1hbCBDYWxpYnJpOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3Jt YWw7Ij48YSBzdHlsZT0iZm9udDogMTZweC9ub3JtYWwgQ2FsaWJyaTsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zdGlyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyPC9hPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48 YnI+PC9kaXY+PC9kaXY+PC9kaXY+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCnN0aXIgbWFpbGluZyBsaXN0CnN0aXJAaWV0Zi5vcmcKaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyPC9kaXY+IAkJIAkgICAJCSAgPC9kaXY+ PC9ib2R5Pg0KPC9odG1sPg== --_1aa34a79-0f13-4d3a-9b29-408d4a48809d_-- From nobody Wed Jul 8 06:54:38 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE591B3648 for ; Wed, 8 Jul 2015 06:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=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 lodYDgIfv2Im for ; Wed, 8 Jul 2015 06:54:34 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (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 40D071B3645 for ; Wed, 8 Jul 2015 06:54:34 -0700 (PDT) Received: by qgeg89 with SMTP id g89so99936372qge.3 for ; Wed, 08 Jul 2015 06:54:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=AAEdI5ptO1CeXC+jIv5BQth/5FVBVFFsjbYNNLsutw8=; b=V0+GDqUIAlzXHdK09eNkGtBg/HUsJmLyxoKSdRaPP+nNXqZW8/SD/Z0CcBRlE0Nkk4 nsd0u2/nnWe3S8ZG/pfcVI6Be1bc/Z7SRxNoVSvB/q6ayT7W5QcpKjS5OFIBwI3cV4ia siiT9SALbokILrANp/LLYpE0jU9RaNeDqrzt2vJ2G83VNqzVfCJnHoqZNwM77WsP29z/ iMDNmqCWW5kl/IChm2Hg6oW7AXy13QplZZx+QAiVGFY2l2VrRFfGx8vfJ3bvGAX3WkN6 sILxDLudPIP3Nsu7B8ET3GY2NPsuEUO4vzcrxHoQTz2U57XJU7YVzsLs/fO+6KPt69L1 kUDg== X-Gm-Message-State: ALoCoQm4Y1CvDDx3pDz+tme4Uh44ZP+7LanvmEGLjIDDGwk9COHPnMrbooHkcDh5txWnzNrgd92E X-Received: by 10.55.23.218 with SMTP id 87mr15928797qkx.36.1436363673474; Wed, 08 Jul 2015 06:54:33 -0700 (PDT) Received: from [10.33.193.32] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id e10sm1091935qka.40.2015.07.08.06.54.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jul 2015 06:54:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_899B07EB-6D8A-4238-8C0C-BB3C250F0CA9" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Brian Rosen In-Reply-To: Date: Wed, 8 Jul 2015 09:54:30 -0400 Message-Id: <7AFA9319-BA1F-47E4-9114-F1B0198BCF08@brianrosen.net> References: <4BB93CEE-8E67-4CC9-BAA8-BC4C2A6D33DF@brianrosen.net> To: Hui Deng X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "stir@ietf.org" , "zhangchen@cmdi.chinamobile.com" Subject: Re: [stir] FW: New Version Notification for draft-zhang-stir-scenario-issue-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 13:54:37 -0000 --Apple-Mail=_899B07EB-6D8A-4238-8C0C-BB3C250F0CA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is a new mechanism. It won=E2=80=99t work unless it=E2=80=99s = deployed. If the sender doesn=E2=80=99t sign the signaling, the call = will not be able to be validated.=20 In our discussions with a small number of regulators from smaller = countries, there is interest in requiring their carriers to deploy this = mechanism because they understand that allowing bad actors operating in = their country to defraud others is not good for their national = interests. No one signs the signaling today. Our hope is that they = will as the manufacturers offer the capability. The stir mechanism is not a magic bullet. It will only work where it is = deployed. One thing that will assist deployment is when customers stop accepting = unsigned calls. Then legitimate callers will need to arrange to have = their signaling signed in order to get their calls to be accepted. Brian > On Jul 7, 2015, at 11:53 PM, Hui Deng wrote: >=20 >=20 > Hi Brian, > =20 > This document is mostly talking about lots of African/South American/ = South east Asian/ Countries, they don't sign their number, that cause = some issues. > inline =3D=3D > please > From: br@brianrosen.net > Date: Tue, 7 Jul 2015 09:22:32 -0400 > To: denghui02@hotmail.com > CC: stir@ietf.org ; = zhangchen@cmdi.chinamobile.com > Subject: Re: [stir] FW: New Version Notification for = draft-zhang-stir-scenario-issue-00.txt >=20 > The canonicalization of the telephone number that is required to = generate the signature would result in both scenarios failing. Even if = the terminal does not send the country code or prefix (area code), it is = part if the calculation of the canonical number that is signed. I = believe this addresses all the scenarios raised in your draft: > =3D=3D > as we said, they don't sign, so whatever country code or = prefix we add. > In Figure 1=E2=80=99s call, I=E2=80=99m confused about who signs. If = it=E2=80=99s the IPBX, then it would have to have the private key for = the canonicalized 10086, which you said was a service number. If it=E2=80= =99s the MSC that is signing, and 10086 is a service number, first of = all, it should not accept a call from the IPBX with a service number as = a calling party number, but even if it did, it would add the country = code to it before it was signed. Any attempt to verify a signature with = a different prefix would fail. > =3D=3D > same here, they don' sign their number in their country. > In Figure 2, the MSC creates the signature for the original telephone = number,1335678432. When the VoLTE AS changes it, the validation will = fail. =20 > =3D=3D > if they don't , what we can do? > In 2., the original number would be canonicalized - any leading zero = removed, country code added. When that is signed, it cannot be used to = validate a call that appears to be from a service number from a = different country, because the canonicalization of that number is = different, and thus the signature check would fail. > =3D=3D > same here. > In 3, the original call with a hidden number has to be sent as an = anonymous call, which is handled in the text. There is no signature on = such a call. I am not sure how IMS handles anonymous calls, but the = scenario you describe, where calling elements are adding prefixes and = country codes to a blank number is surely not what anyone envisions for = anonymous calls.=20 > =3D=3D > today operators would like get as much as international = roaming without checking their sign, that's the situation for real = commerical deployment. > =20 > Brian > =3D=3D >=20 > thanks a for yor comments. > Best regards, > DENG Hui >=20 >=20 > On Jul 7, 2015, at 3:35 AM, Hui Deng > wrote: >=20 > Hello all > =20 > Please feel free to let us know if you have any comment on it, > =20 > thanks a lot > =20 > DENG Hui > =20 >=20 > =20 >=20 > A new version of I-D, draft-zhang-stir-scenario-issue-00.txt >=20 > has been successfully submitted by Hui Deng and posted to the IETF = repository. >=20 > =20 >=20 > Name: draft-zhang-stir-scenario-issue >=20 > Revision: 00 >=20 > Title: Issue with current STIR scenario >=20 > Document date: 2015-07-06 >=20 > Group: Individual Submission >=20 > Pages: 5 >=20 > URL: = https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-issue-00.tx= t = > Status: = https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issue/ = > Htmlized: = https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00 = > Abstract: >=20 > This document introduces couple of scenarios have been identified = to > find out that certificate based solution has some limitation. >=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 > The IETF Secretariat >=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 = --Apple-Mail=_899B07EB-6D8A-4238-8C0C-BB3C250F0CA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This is a new mechanism.  It won=E2=80=99t work unless = it=E2=80=99s deployed.  If the sender doesn=E2=80=99t sign the = signaling, the call will not be able to be validated. 
In our discussions with a small number of regulators from = smaller countries, there is interest in requiring their carriers to = deploy this mechanism because they understand that allowing bad actors = operating in their country to defraud others is not good for their = national interests.  No one signs the signaling today.  Our = hope is that they will as the manufacturers offer the = capability.

The = stir mechanism is not a magic bullet.  It will only work where it = is deployed.

One= thing that will assist deployment is when customers stop accepting = unsigned calls.  Then legitimate callers will need to arrange to = have their signaling signed in order to get their calls to be = accepted.

Brian

On = Jul 7, 2015, at 11:53 PM, Hui Deng <denghui02@hotmail.com> wrote:


 Hi = Brian,
 
This document is mostly = talking about lots of African/South American/ South east Asian/ = Countries, they don't sign their number, that cause some issues.
inline =3D=3D > please
From: br@brianrosen.net
Date: Tue, 7 Jul 2015 09:22:32 -0400
To: denghui02@hotmail.com
CC: stir@ietf.org; zhangchen@cmdi.chinamobile.com
Subject: Re: = [stir] FW: New Version Notification for = draft-zhang-stir-scenario-issue-00.txt

The = canonicalization of the telephone number that is required to generate = the signature would result in both scenarios failing.  Even if the = terminal does not send the country code or prefix (area code), it is = part if the calculation of the canonical number that is signed.  I = believe this addresses all the scenarios raised in your draft:
=3D=3D > as we said, they don't sign, so whatever country = code or prefix we add.
In Figure = 1=E2=80=99s call, I=E2=80=99m confused about who signs.  If it=E2=80=99= s the IPBX, then it would have to have the private key for the = canonicalized 10086, which you said was a service number.  If = it=E2=80=99s the MSC that is signing, and 10086 is a service number, = first of all, it should not accept a call from the IPBX with a service = number as a calling party number, but even if it did, it would add the = country code to it before it was signed.  Any attempt to verify a = signature with a different prefix would fail.
=3D=3D = > same here, they don' sign their number in their country.
In Figure 2, the MSC creates the = signature for the original telephone number,1335678432.  When the VoLTE = AS changes it, the validation will fail.  
=3D=3D > if they don't , what we can do?
In 2., the original number would be = canonicalized - any leading zero removed, country code added.  When = that is signed, it cannot be used to validate a call that appears to be = from a service number from a different country, because the = canonicalization of that number is different, and thus the signature = check would fail.
=3D=3D > same here.
In 3, the original call with a hidden = number has to be sent as an anonymous call, which is handled in the = text.  There is no signature on such a call.  I am not sure = how IMS handles anonymous calls, but the scenario you describe, where = calling elements are adding prefixes and country codes to a blank number = is surely not what anyone envisions for anonymous calls. 
=3D=3D > today operators would like get as = much as international roaming without checking their sign, that's the = situation for real commerical deployment.
 
Brian
=3D=3D > 
thanks a = for yor comments.
Best = regards,
DENG Hui


On Jul 7, 2015, at = 3:35 AM, Hui Deng <denghui02@hotmail.com> wrote:

Hello all
 
Please feel free to let us know if you = have any comment on it,
 
thanks a = lot
 
DENG Hui
 

 

A new version of I-D, = draft-zhang-stir-scenario-issue-00.txt

has been successfully = submitted by Hui Deng and posted to the IETF = repository.

 

Name:          &nb= sp;    draft-zhang-stir-sc= enario-issue

Revision:  00

Title:          &nb= sp;       Issue with = current STIR scenario

Document date:       2015-07-06
Group:          &nb= sp;    Individual = Submission

Pages:          &nb= sp;    5

URL:          &nb= sp; https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-= issue-00.txt
Htmlized:       https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00<= /font>

Abstract:

   This document = introduces couple of scenarios have been identified to
   find out that = certificate based solution has some limitation.

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.

The IETF = Secretariat

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


_______________________________________________ stir mailing = list stir@ietf.orghttps://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_899B07EB-6D8A-4238-8C0C-BB3C250F0CA9-- From nobody Wed Jul 8 07:34:51 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55831B36E3 for ; Wed, 8 Jul 2015 07:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.515 X-Spam-Level: * X-Spam-Status: No, score=1.515 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_SOMA2=2.199, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 sLuHM40sKpTo for ; Wed, 8 Jul 2015 07:34:41 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 023081B3469 for ; Wed, 8 Jul 2015 07:34:39 -0700 (PDT) Received: (qmail 16717 invoked by uid 0); 8 Jul 2015 14:34:34 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 8 Jul 2015 14:34:34 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id pq6s1q00o1MNPNq01q6v0L; Wed, 08 Jul 2015 08:06:59 -0600 X-Authority-Analysis: v=2.1 cv=ItWNLtPg c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=IYETQKA4aJkA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=1a-BD-wmpaMA:10 a=zOBTXjUuO1YA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=48vgC7mUAAAA:8 a=HLLxP2VMAAAA:8 a=69EAbJreAAAA:8 a=R5C9hjxsAAAA:8 a=MgIu-8eKtfG8fQVkiyEA:9 a=7Sf6KuNcCBPGVlQu:21 a=tp7k-P60q4jeDfWJ:21 a=wPNLvfGTeEIA:10 a=_tYMmFSoaXyobyyMPcgA:9 a=l5VzDn0twTTV7QQX:21 a=8JNtCZC937h3zw1G:21 a=gRRt1sdAoQbkVEiV:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=EUcIh9XE7q31sBkbnKQkIdnvNHFB7mwPnhAIKqA1WwI=; b=CRGZAtJS7jhN4TRtQ37nqzRSpxDhYTynBu0Y8gZC7ZnVxDFKGWmBEtail6bvhiHZxfDM7Q2mJ6B6iHsOR+1oFZhhSFn2VuzqHfDnQB68GMtB/FNt2e+KmwBPI6ZIQrL3; Received: from [38.98.234.2] (port=50701 helo=[10.0.80.119]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZCq7H-00050s-Qj; Wed, 08 Jul 2015 08:14:28 -0600 User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Wed, 08 Jul 2015 10:14:23 -0400 From: Richard Shockey To: Brian Rosen , Hui Deng Message-ID: Thread-Topic: [stir] FW: New Version Notification for draft-zhang-stir-scenario-issue-00.txt References: <4BB93CEE-8E67-4CC9-BAA8-BC4C2A6D33DF@brianrosen.net> <7AFA9319-BA1F-47E4-9114-F1B0198BCF08@brianrosen.net> In-Reply-To: <7AFA9319-BA1F-47E4-9114-F1B0198BCF08@brianrosen.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3519195267_159742" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 38.98.234.2 authed with richard+shockey.us} Archived-At: Cc: "stir@ietf.org" , "zhangchen@cmdi.chinamobile.com" Subject: Re: [stir] FW: New Version Notification for draft-zhang-stir-scenario-issue-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 14:34:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3519195267_159742 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable From: stir on behalf of Brian Rosen Date: Wednesday, July 8, 2015 at 9:54 AM To: Hui Deng Cc: "stir@ietf.org" , "zhangchen@cmdi.chinamobile.com" Subject: Re: [stir] FW: New Version Notification for draft-zhang-stir-scenario-issue-00.txt This is a new mechanism. It won=B9t work unless it=B9s deployed. If the sende= r doesn=B9t sign the signaling, the call will not be able to be validated. In our discussions with a small number of regulators from smaller countries= , there is interest in requiring their carriers to deploy this mechanism because they understand that allowing bad actors operating in their country to defraud others is not good for their national interests. No one signs the signaling today. Our hope is that they will as the manufacturers offer the capability. The stir mechanism is not a magic bullet. It will only work where it is deployed. One thing that will assist deployment is when customers stop accepting unsigned calls. Then legitimate callers will need to arrange to have their signaling signed in order to get their calls to be accepted. RS So Mr Wizard how will the IMS TAS actually process the terminating validation at the SBC in order to deliver validation data to the CUA and where will the validation data be inserted? I suggest someone needs to tal= k to 3GPP. Brian > On Jul 7, 2015, at 11:53 PM, Hui Deng wrote: >=20 >=20 > Hi Brian, > =20 > This document is mostly talking about lots of African/South American/ Sou= th > east Asian/ Countries, they don't sign their number, that cause some issu= es. > inline =3D=3D > please >=20 > From: br@brianrosen.net > Date: Tue, 7 Jul 2015 09:22:32 -0400 > To: denghui02@hotmail.com > CC: stir@ietf.org; zhangchen@cmdi.chinamobile.com > Subject: Re: [stir] FW: New Version Notification for > draft-zhang-stir-scenario-issue-00.txt >=20 > The canonicalization of the telephone number that is required to generate= the > signature would result in both scenarios failing. Even if the terminal d= oes > not send the country code or prefix (area code), it is part if the calcul= ation > of the canonical number that is signed. I believe this addresses all the > scenarios raised in your draft: > =3D=3D > as we said, they don't sign, so whatever country code or prefix we a= dd. > In Figure 1=B9s call, I=B9m confused about who signs. If it=B9s the IPBX, then= it > would have to have the private key for the canonicalized 10086, which you= said > was a service number. If it=B9s the MSC that is signing, and 10086 is a se= rvice > number, first of all, it should not accept a call from the IPBX with a se= rvice > number as a calling party number, but even if it did, it would add the co= untry > code to it before it was signed. Any attempt to verify a signature with = a > different prefix would fail. > =3D=3D > same here, they don' sign their number in their country. > In Figure 2, the MSC creates the signature for the original telephone > number,1335678432. When the VoLTE AS changes it, the validation will fai= l. > =3D=3D > if they don't , what we can do? > In 2., the original number would be canonicalized - any leading zero remo= ved, > country code added. When that is signed, it cannot be used to validate a= call > that appears to be from a service number from a different country, becaus= e the > canonicalization of that number is different, and thus the signature chec= k > would fail. > =3D=3D > same here. > In 3, the original call with a hidden number has to be sent as an anonymo= us > call, which is handled in the text. There is no signature on such a call= . I > am not sure how IMS handles anonymous calls, but the scenario you describ= e, > where calling elements are adding prefixes and country codes to a blank n= umber > is surely not what anyone envisions for anonymous calls. > =3D=3D > today operators would like get as much as international roaming with= out > checking their sign, that's the situation for real commerical deployment. > =20 > Brian > =3D=3D >=20 > thanks a for yor comments. > Best regards, > DENG Hui >=20 >=20 >> On Jul 7, 2015, at 3:35 AM, Hui Deng wrote: >>=20 >> Hello all >> =20 >> Please feel free to let us know if you have any comment on it, >> =20 >> thanks a lot >> =20 >> DENG Hui >> =20 >>=20 >> =20 >>=20 >> A new version of I-D, draft-zhang-stir-scenario-issue-00.txt >>=20 >> has been successfully submitted by Hui Deng and posted to the IETF >> repository. >>=20 >> =20 >>=20 >> Name: draft-zhang-stir-scenario-issue >>=20 >> Revision: 00 >>=20 >> Title: Issue with current STIR scenario >>=20 >> Document date: 2015-07-06 >>=20 >> Group: Individual Submission >>=20 >> Pages: 5 >>=20 >> URL: =20 >> https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-issue-00.= txt >> >> Status: =20 >> https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issue/ >> >> Htmlized: =20 >> https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00 >> >>=20 >> Abstract: >>=20 >> This document introduces couple of scenarios have been identified to >> find out that certificate based solution has some limitation. >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org >> . >>=20 >> The IETF Secretariat >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=20 > _______________________________________________ stir mailing list > stir@ietf.orghttps://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --B_3519195267_159742 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable


=

From: s= tir <stir-bounces@ietf.org>= on behalf of Brian Rosen <br@brianros= en.net>
Date: Wednesday, Ju= ly 8, 2015 at 9:54 AM
To: Hui Deng= <denghui02@hotmail.com>Cc: "= stir@ietf.org" <stir@ietf.org>,= "zhangchen@cmdi.chinamobile= .com" <zhangchen@cmdi= .chinamobile.com>
Subject: = Re: [stir] FW: New Version Notification for draft-zhang-stir-scenario-issue-= 00.txt

This is a new me= chanism.  It won’t work unless it’s deployed.  If the = sender doesn’t sign the signaling, the call will not be able to be val= idated. 
In our discussions with a small number of regulat= ors from smaller countries, there is interest in requiring their carriers to= deploy this mechanism because they understand that allowing bad actors oper= ating in their country to defraud others is not good for their national inte= rests.  No one signs the signaling today.  Our hope is that they w= ill as the manufacturers offer the capability.

The stir mechanism is not a magic bullet.  It wi= ll only work where it is deployed.

One thing that will assist deployment is when customers stop acce= pting unsigned calls.  Then legitimate callers will need to arrange to = have their signaling signed in order to get their calls to be accepted.


RS So Mr Wizard how w= ill the IMS TAS actually process the terminating validation at the SBC in or= der to deliver validation data to the CUA and where will the validation data= be inserted?  I suggest someone needs to talk to 3GPP.

<= /div>



Brian

On Jul 7, 2015, at 11:53 PM, Hui Deng <= ;denghui02@hotmail.com&g= t; wrote:


 Hi Brian,
 This document is mostly talking about lots of African/South Americ= an/ South east Asian/ Countries, they don't sign their number, that cause so= me issues.
inline =3D=3D > please
=
From:&nbs= p;br@brianrosen.netDate: Tue, 7 Jul 2015 09:22:32 -0400
To: denghui02@hotmail.com
CC: stir@ietf.org<= /a>; zhangchen@cmdi.chinamobile.com
Subject: Re: [stir] FW: New Version Notification for draft-zhang-stir-s= cenario-issue-00.txt

The canonicalization of the te= lephone number that is required to generate the signature would result in bo= th scenarios failing.  Even if the terminal does not send the country c= ode or prefix (area code), it is part if the calculation of the canonical nu= mber that is signed.  I believe this addresses all the scenarios raised= in your draft:
=3D=3D > as we said, they don't sign, so whateve= r country code or prefix we add.
In Figure 1= ’s call, I’m confused about who signs.  If it’s the I= PBX, then it would have to have the private key for the canonicalized 10086,= which you said was a service number.  If it’s the MSC that is si= gning, and 10086 is a service number, first of all, it should not accept a c= all from the IPBX with a service number as a calling party number, but even = if it did, it would add the country code to it before it was signed.  A= ny attempt to verify a signature with a different prefix would fail.
=3D=3D > same here, they don' sign their number in their country.=
In Figure 2, the MSC creates the signature = for the original telephone number,1335678432.  When the VoLTE AS changes it, the valid= ation will fail.  
=3D=3D > if they don't , what= we can do?
In 2., the original number would= be canonicalized - any leading zero removed, country code added.  When= that is signed, it cannot be used to validate a call that appears to be fro= m a service number from a different country, because the canonicalization of= that number is different, and thus the signature check would fail.
=3D=3D > same here.
In 3, the orig= inal call with a hidden number has to be sent as an anonymous call, which is= handled in the text.  There is no signature on such a call.  I am= not sure how IMS handles anonymous calls, but the scenario you describe, wh= ere calling elements are adding prefixes and country codes to a blank number= is surely not what anyone envisions for anonymous calls. 
=3D=3D > today operators would like get as much as inter= national roaming without checking their sign, that's the situation for real = commerical deployment.
 
Brian
=3D=3D > 
thanks a for yor comments.
Best regards,
DENG Hui


On Jul 7, 2015, at 3:35 A= M, Hui Deng <denghui02@ho= tmail.com> wrote:

Hello all
 
Please feel free to let us know if you have any comment on it,
 
thanks a lot
 
DENG Hui<= br class=3D""> 

=
 

A new version of I-D, draft-zhang-st= ir-scenario-issue-00.txt

has be= en successfully submitted by Hui Deng and posted to the IETF repository.

 

Name:      &n= bsp;        draft-zhang-stir-scenario-issue

Revision:  00

Title:      &nbs= p;           Issue with current STIR scenari= o

Document date:=       &= nbsp;2015-07-06
G= roup:         &n= bsp;     Individual Submission

Pages:         = ;      = 5

URL:            https://www.ietf.org/internet-dra= fts/draft-zhang-stir-scenario-issue-00.txt
Status:=          https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issue/=
Htmlized:       https://tools.ietf.org/html/draft-zhang-stir= -scenario-issue-00
A= bstract:

 &= nbsp; This documen= t introduces couple of scenarios have been identified to
&nbs= p;  find out = that certificate based solution has some limitation.

Please note that it may take a couple of minutes from = the time of submission until the htmlized version and diff are available at<= span class=3D"ecxApple-converted-space"> tools.ietf.org.

The IETF Secretariat

_______________________________________________
stir mailing list=
stir@ietf= .org
https://www.ietf.org/mailman/listinfo/s= tir


= _______________________________________________ stir mailing list stir@ietf.orghttps://www.ietf.org/mailman/listinfo/stir

_________________________________= ______________ stir mailing list stir@ietf.org https://www.ietf.org/m= ailman/listinfo/stir --B_3519195267_159742-- From nobody Wed Jul 8 07:50:42 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051651B3728 for ; Wed, 8 Jul 2015 07:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.36 X-Spam-Level: * X-Spam-Status: No, score=1.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_SOMA2=2.199, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=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 OzOMZwbrvGuX for ; Wed, 8 Jul 2015 07:50:36 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (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 1FE361B36ED for ; Wed, 8 Jul 2015 07:50:36 -0700 (PDT) Received: by iecuq6 with SMTP id uq6so157067759iec.2 for ; Wed, 08 Jul 2015 07:50:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=fBqbmhe6LQRqQ0uFKndTDVptdzsBH3+wZUrCkuoHGLM=; b=Va0P+MaI3pDw5JfvGXhD08Jn9nytqPcKirhgKSgO/g//WQWr5KRMYTVsG2gr7YQS/T MfHPpu1o9Y8gfaMWE49yGuTKd7X9wleeeJ0N3Co6LsNs8RPam7L31Yd8pJs5DqdMC3rn Js5iHvt/gJ97cDi8GT3hB6VNWL3Lcpk5Y9Xe3R9Qt08ADI0DGvDo0AEFm4NgCwNZWF62 RmD1McgcuSD0KS7kCDJlpKlZU61M7JI1GOFLwWtwJKfjmbYWMJLDaBdpucznYWry1V8b hGNHtx+4NPhQANcZST+vbKgEx3MJbuiaAS08ymSvh5jSl7la0SS5N+0Uh4fdHbusRsr0 hS6g== X-Gm-Message-State: ALoCoQl28cmRx6QzgEP+1Unyii/Q3l1cWElaoj/mnBslsUs7E9LEk+cNKU2Mj+oLx9unkf1nb7Rj X-Received: by 10.50.64.147 with SMTP id o19mr59355744igs.15.1436367035454; Wed, 08 Jul 2015 07:50:35 -0700 (PDT) Received: from [10.33.193.32] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id m193sm1961395iom.19.2015.07.08.07.50.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jul 2015 07:50:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A3B40603-D9A9-4BFF-90A7-CE2AB0F3C7DD" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Brian Rosen In-Reply-To: Date: Wed, 8 Jul 2015 10:50:31 -0400 Message-Id: <3A01AFC1-0D2B-48B2-ABA3-3979635C02E9@brianrosen.net> References: <4BB93CEE-8E67-4CC9-BAA8-BC4C2A6D33DF@brianrosen.net> <7AFA9319-BA1F-47E4-9114-F1B0198BCF08@brianrosen.net> To: Richard Shockey X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "stir@ietf.org" , Hui Deng , "zhangchen@cmdi.chinamobile.com" Subject: Re: [stir] New Version Notification for draft-zhang-stir-scenario-issue-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 14:50:39 -0000 --Apple-Mail=_A3B40603-D9A9-4BFF-90A7-CE2AB0F3C7DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes, 3GPP work will be needed to deploy stir in IMS systems. So? As with lots of other implementations, I expect the operator will = generate and check for a while, until the devices do it themselves. Some of his examples have non-IMS actors, and those need either an SP or = devices to implement in order for the mechanism to work. Brian > On Jul 8, 2015, at 10:14 AM, Richard Shockey = wrote: >=20 >=20 >=20 >=20 > From: stir > on = behalf of Brian Rosen > > Date: Wednesday, July 8, 2015 at 9:54 AM > To: Hui Deng > > Cc: "stir@ietf.org " >, "zhangchen@cmdi.chinamobile.com = " > > Subject: Re: [stir] FW: New Version Notification for = draft-zhang-stir-scenario-issue-00.txt >=20 > This is a new mechanism. It won=92t work unless it=92s deployed. If = the sender doesn=92t sign the signaling, the call will not be able to be = validated.=20 > In our discussions with a small number of regulators from smaller = countries, there is interest in requiring their carriers to deploy this = mechanism because they understand that allowing bad actors operating in = their country to defraud others is not good for their national = interests. No one signs the signaling today. Our hope is that they = will as the manufacturers offer the capability. >=20 > The stir mechanism is not a magic bullet. It will only work where it = is deployed. >=20 > One thing that will assist deployment is when customers stop accepting = unsigned calls. Then legitimate callers will need to arrange to have = their signaling signed in order to get their calls to be accepted. >=20 >=20 > RS So Mr Wizard how will the IMS TAS actually process the terminating = validation at the SBC in order to deliver validation data to the CUA and = where will the validation data be inserted? I suggest someone needs to = talk to 3GPP. >=20 >=20 >=20 >=20 > Brian >=20 >> On Jul 7, 2015, at 11:53 PM, Hui Deng > wrote: >>=20 >>=20 >> Hi Brian, >> =20 >> This document is mostly talking about lots of African/South American/ = South east Asian/ Countries, they don't sign their number, that cause = some issues. >> inline =3D=3D > please >> From: br@brianrosen.net >> Date: Tue, 7 Jul 2015 09:22:32 -0400 >> To: denghui02@hotmail.com >> CC: stir@ietf.org ; = zhangchen@cmdi.chinamobile.com >> Subject: Re: [stir] FW: New Version Notification for = draft-zhang-stir-scenario-issue-00.txt >>=20 >> The canonicalization of the telephone number that is required to = generate the signature would result in both scenarios failing. Even if = the terminal does not send the country code or prefix (area code), it is = part if the calculation of the canonical number that is signed. I = believe this addresses all the scenarios raised in your draft: >> =3D=3D > as we said, they don't sign, so whatever country code or = prefix we add. >> In Figure 1=92s call, I=92m confused about who signs. If it=92s the = IPBX, then it would have to have the private key for the canonicalized = 10086, which you said was a service number. If it=92s the MSC that is = signing, and 10086 is a service number, first of all, it should not = accept a call from the IPBX with a service number as a calling party = number, but even if it did, it would add the country code to it before = it was signed. Any attempt to verify a signature with a different = prefix would fail. >> =3D=3D > same here, they don' sign their number in their country. >> In Figure 2, the MSC creates the signature for the original telephone = number,1335678432. When the VoLTE AS changes it, the validation will = fail. =20 >> =3D=3D > if they don't , what we can do? >> In 2., the original number would be canonicalized - any leading zero = removed, country code added. When that is signed, it cannot be used to = validate a call that appears to be from a service number from a = different country, because the canonicalization of that number is = different, and thus the signature check would fail. >> =3D=3D > same here. >> In 3, the original call with a hidden number has to be sent as an = anonymous call, which is handled in the text. There is no signature on = such a call. I am not sure how IMS handles anonymous calls, but the = scenario you describe, where calling elements are adding prefixes and = country codes to a blank number is surely not what anyone envisions for = anonymous calls.=20 >> =3D=3D > today operators would like get as much as international = roaming without checking their sign, that's the situation for real = commerical deployment. >> =20 >> Brian >> =3D=3D >=20 >> thanks a for yor comments. >> Best regards, >> DENG Hui >>=20 >>=20 >>> On Jul 7, 2015, at 3:35 AM, Hui Deng > wrote: >>>=20 >>> Hello all >>> =20 >>> Please feel free to let us know if you have any comment on it, >>> =20 >>> thanks a lot >>> =20 >>> DENG Hui >>> =20 >>>=20 >>> =20 >>>=20 >>> A new version of I-D, draft-zhang-stir-scenario-issue-00.txt >>>=20 >>> has been successfully submitted by Hui Deng and posted to the IETF = repository. >>>=20 >>> =20 >>>=20 >>> Name: draft-zhang-stir-scenario-issue >>>=20 >>> Revision: 00 >>>=20 >>> Title: Issue with current STIR scenario >>>=20 >>> Document date: 2015-07-06 >>>=20 >>> Group: Individual Submission >>>=20 >>> Pages: 5 >>>=20 >>> URL: = https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-issue-00.tx= t = >>> Status: = https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issue/ = >>> Htmlized: = https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00 = >>> Abstract: >>>=20 >>> This document introduces couple of scenarios have been identified = to >>> find out that certificate based solution has some limitation. >>>=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 >>> The IETF Secretariat >>>=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 = > _______________________________________________ stir mailing list = stir@ietf.org = https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_A3B40603-D9A9-4BFF-90A7-CE2AB0F3C7DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes, 3GPP work will be needed to deploy stir in IMS = systems.

So?

As with lots of other = implementations, I expect the operator will generate and check for a = while, until the devices do it themselves.
Some of = his examples have non-IMS actors, and those need either an SP or devices = to implement in order for the mechanism to work.

Brian

On = Jul 8, 2015, at 10:14 AM, Richard Shockey <richard@shockey.us> = wrote:




From: stir <stir-bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Date: Wednesday, July 8, = 2015 at 9:54 AM
To: Hui Deng <denghui02@hotmail.com>
Cc: "stir@ietf.org" <stir@ietf.org>, "zhangchen@cmdi.chinamobile.com" <zhangchen@cmdi.chinamobile.com>
Subject: Re: [stir] FW: New = Version Notification for draft-zhang-stir-scenario-issue-00.txt

This is a new mechanism. =  It won=92t work unless it=92s deployed.  If the sender = doesn=92t sign the signaling, the call will not be able to be = validated. 
In our discussions with a small number = of regulators from smaller countries, there is interest in requiring = their carriers to deploy this mechanism because they understand that = allowing bad actors operating in their country to defraud others is not = good for their national interests.  No one signs the signaling = today.  Our hope is that they will as the manufacturers offer the = capability.

The = stir mechanism is not a magic bullet.  It will only work where it = is deployed.

One= thing that will assist deployment is when customers stop accepting = unsigned calls.  Then legitimate callers will need to arrange to = have their signaling signed in order to get their calls to be = accepted.


RS So Mr Wizard how will the IMS TAS actually process = the terminating validation at the SBC in order to deliver validation = data to the CUA and where will the validation data be inserted?  I = suggest someone needs to talk to 3GPP.




Brian

On Jul = 7, 2015, at 11:53 PM, Hui Deng <denghui02@hotmail.com> wrote:


 Hi Brian,
 
This = document is mostly talking about lots of African/South American/ South = east Asian/ Countries, they don't sign their number, that cause some = issues.
inline =3D=3D > please
From: br@brianrosen.net
Date: Tue, 7 Jul 2015 09:22:32 -0400
To: denghui02@hotmail.com
CC: stir@ietf.org; zhangchen@cmdi.chinamobile.com
Subject: Re: = [stir] FW: New Version Notification for = draft-zhang-stir-scenario-issue-00.txt

The = canonicalization of the telephone number that is required to generate = the signature would result in both scenarios failing.  Even if the = terminal does not send the country code or prefix (area code), it is = part if the calculation of the canonical number that is signed.  I = believe this addresses all the scenarios raised in your draft:
=3D=3D > as we said, they don't sign, so whatever country = code or prefix we add.
In Figure 1=92s= call, I=92m confused about who signs.  If it=92s the IPBX, then it = would have to have the private key for the canonicalized 10086, which = you said was a service number.  If it=92s the MSC that is signing, = and 10086 is a service number, first of all, it should not accept a call = from the IPBX with a service number as a calling party number, but even = if it did, it would add the country code to it before it was signed. =  Any attempt to verify a signature with a different prefix would = fail.
=3D=3D > same here, they don' sign their = number in their country.
In Figure = 2, the MSC creates the signature for the original telephone number,1335678432. =  When the VoLTE AS changes it, the validation will fail. =  
=3D=3D > if they don't , what we can = do?
In 2., the original number would = be canonicalized - any leading zero removed, country code added. =  When that is signed, it cannot be used to validate a call that = appears to be from a service number from a different country, because = the canonicalization of that number is different, and thus the signature = check would fail.
=3D=3D > same here.
In 3, the original call with a hidden = number has to be sent as an anonymous call, which is handled in the = text.  There is no signature on such a call.  I am not sure = how IMS handles anonymous calls, but the scenario you describe, where = calling elements are adding prefixes and country codes to a blank number = is surely not what anyone envisions for anonymous calls. 
=3D=3D > today operators would like get as = much as international roaming without checking their sign, that's the = situation for real commerical deployment.
 
Brian
=3D=3D > 
thanks a = for yor comments.
Best = regards,
DENG Hui


On Jul = 7, 2015, at 3:35 AM, Hui Deng <denghui02@hotmail.com> wrote:

Hello all
 Please feel free to let us know if you have any comment on = it,
 
thanks a lot
 
DENG Hui
 

 

A new version of I-D, = draft-zhang-stir-scenario-issue-00.txt

has been successfully submitted by = Hui Deng and posted to the IETF repository.

 

Name:          &nb= sp;    draft-zhang-stir-sc= enario-issue

Revision:  00

Title:          &nb= sp;       Issue with = current STIR scenario

Document date:       2015-07-06
Group:          &nb= sp;    Individual = Submission

Pages:          &nb= sp;    5

URL:          &nb= sp; https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-= issue-00.txt
Status:         https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issu= e/
Htmlized:       https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00<= /font>

Abstract:

   This document = introduces couple of scenarios have been identified to
   find out that = certificate based solution has some limitation.

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.

The IETF = Secretariat

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


_______________________________________________ stir mailing = list stir@ietf.orghttps://www.ietf.org/mailman/listinfo/stir

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

= --Apple-Mail=_A3B40603-D9A9-4BFF-90A7-CE2AB0F3C7DD-- From nobody Sun Jul 19 17:38:58 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8DD1B2EBA for ; Sun, 19 Jul 2015 17:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 CqQXjRE35tTs for ; Sun, 19 Jul 2015 17:38:56 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B114E1B2EB8 for ; Sun, 19 Jul 2015 17:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From; bh=nAFWvwrA5mL7HsDk8VpobALq6rY9fPnYRtny+kXSZbc=; b=jFFr1YG2REs9Zv3ob97PiIfFi1H1zRBEY7F/u6ypZ62VV9PoRV89nUWBe3fDwKuOgBf2s2cchY0ejX8Giq8GZDUnsLwWDtA2btt5ug414DV0KotLV2mdSM8x4qP0Ouvs+LwMbZ7ZY84HgDi9TwmXqeYOmCw/LSQFERkDmcz0iAc=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:55999 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZGz6Z-0000Nr-8F for stir@ietf.org; Sun, 19 Jul 2015 17:38:53 -0700 From: Eric Burger X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_99DF196D-6826-4922-8C36-F36B1952DCE0"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Sun, 19 Jul 2015 20:38:51 -0400 Message-Id: <9410E673-B964-4747-9FB2-91694817C8FA@standardstrack.com> To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-0.4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [stir] Policy/Architecture versus Protocol X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 00:38:57 -0000 --Apple-Mail=_99DF196D-6826-4922-8C36-F36B1952DCE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We (the IETF) are good at protocols. We are not quite as good at = architectures. We suck at policy. High-level: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A major weakness of the current 4474bis-04 draft is rather than focus on = the protocol extension, it has a lot of focus on the architecture. = Moreover, sometimes it makes policy suggestions, other times it makes = policy decisions. This draft could be made much clearer by taking out the architecture and = policy stuff and moving that to a different document. I would offer that = fits into the current charter, because the charter wisely says "Submit = in-band mechanism for Proposed Standard,=E2=80=9D not =E2=80=9Cupdate = 4474.=E2=80=9D Yes, I will volunteer to put together that document. Details: =3D=3D=3D=3D=3D=3D=3D=3D The draft speaks of an authentication service and a validation service. = It then goes on to specify an architecture, where the authentication = service is literally a service, most likely in or near an outbound proxy = or B2BUA (explicit in the draft) and the validation service is literally = a service, most likely in a P-CSCF or SBC (not by name in the draft, but = certainly by implication). It would be much cleaner if the draft focused on the behavior of the SIP = UAC that implements an authentication function and a SIP UAS that = implements a validation function. We (the IETF) are good at that. That = means we can take out all of the confusing language about unenforceable = and outside the scope of the IETF restrictions on the authentication = function. For example, show me where in SIP one can enforce that an = intermediary MUST authenticate SIP users (Section 4.1)? We manage to leave the interaction of an IP PBX to a phone alone. For = example, we do not specify that an IP PBX *MUST* be a SIP Proxy that can = only help a SIP phone route calls. It might be that, it might be a SIP = B2BUA, or, for that matter, the protocol between the phone and the IP = PBX could be Skinny (SCCP) ;-) Likewise, we should leave the interaction between an outbound proxy that = happens to do the authentication *function* and the phone as a local = matter. Yes, we can help implementors, which would be the different = document I mentioned above. --Apple-Mail=_99DF196D-6826-4922-8C36-F36B1952DCE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrEMcAAoJEORoZaSQsc1I1WoP/0Hw99pyG59D8XbDw+2q+7Sg /TVXdLRFnL36wb99RGnQ/TtTrjOCoZh/w8HB0nWXIOAWUaT0pakdfBIfU0Flv7AG cH2fsrI/q6qVs94NB4xph2KWlKR8n6WnFncQOMlxncI+C2GfUXIdEIIRh9rWXdXv zNAdMcEH17u3G8lA3NI8gX3K0nBQFIkrbV3E9YovGfi3YmexYpDv9tOUREIlkUQc eN9/cJsof4gqQC2S5+ZuzzFj5vDrV5qYlL3crzcbUXfQgyM9KbHq9ohpGZnCLfDn 6NzYz1C+LLED1DmiLdUdAevg69ysOpfkYTRhS+DOvabozD1zbKhV/d7JiKIdw2el fYyZ2JeXevshrJE8Tzt6DDcvjODzaj/ouwespsDsGnYm6o0MJm1LAdMxTXVDMGGu 6BzzPREYobg2Jw15FB9RDvSAgU36JPyjplJuNpRuHzndRtVmHipWxVj5c5QoFmGv uBrEBz3GOWi99xGgR5meXeU1usn5j5+P+OoYOV34sQn4mkqQhCaE94GKxu3yeuw+ Nw0lNqi2AZishXnU9zcfEU7Fa4gu72YK1EC+B3uC3jcSrclYTRDAildkyN4CqTEO ydYJ7KP+p6G+HjtxtD6ZYrcii4fhU9M2zMbVTTOyU3zR+ogWePT7jicq9jkKFHTM Uyd8pfwmGPEnK0a5xBMi =fHFf -----END PGP SIGNATURE----- --Apple-Mail=_99DF196D-6826-4922-8C36-F36B1952DCE0-- From nobody Sun Jul 19 17:39:07 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBAA1B2EC4 for ; Sun, 19 Jul 2015 17:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 daWli-qu7bdO for ; Sun, 19 Jul 2015 17:39:03 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE09F1B2EC2 for ; Sun, 19 Jul 2015 17:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From; bh=9i8OqbFCKqrALNZyor4JUCIQkmz3VkJV8wTeYZDcxy0=; b=gI0FT2mb42+WMYQlqGQJqkfHqP/wSxBGC12uTZOEQIyTbe8yqQKVt44a10EKqLzCuSCxzoETR8sOekaxY3l9sU5Es9QCFKtiZb5IDl/gU/YSF3K6COcNNyBOS+ipJ8q67Gfb+djtlNztNUGPG96xqBoSue1B56xFY9P5Lx0llg8=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:55999 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZGz6j-0000Nr-05 for stir@ietf.org; Sun, 19 Jul 2015 17:39:02 -0700 From: Eric Burger X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_14F69F58-77DC-4DCE-8C45-3E140B906208"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Sun, 19 Jul 2015 20:38:57 -0400 Message-Id: <15459DB2-A599-4BA3-81CF-7536719612B8@standardstrack.com> To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [stir] In-line certificate checking X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 00:39:04 -0000 --Apple-Mail=_14F69F58-77DC-4DCE-8C45-3E140B906208 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The threat model for revoked certificates is beyond wrong and results in = putting a burden of 100,000+ tps during busy hour on exemplary networks, = such as AT&T and Verizon in the U.S. Note that not only are they making = that magnitude of queries, but they are also responding to more than = that magnitude of queries. The fundamental error is that the threat model presumes that a number = port will break the certificate. Well, that is correct. If you port your = number from AT&T to Verizon, AT&T should not be able to sign for your = CLID. However, it does not matter. You ported the number, which means = you are the number, which means that it does not matter whether AT&T or = Verizon signs for it, the number still points to you. So, the = fundamental error is in thinking who vouched for the end user matters. = It does not. The other cases that one might think could matter also do not matter. = Specifically, if a fallow number gets reassigned, the old subscriber = could then start reusing their old number. This does not matter because = the protocol can simply specify that the certificate lifetime MUST be = shorter than the service provider=E2=80=99s fallow period. Since = certificates will have a lifetime of at most days, this is not a problem = in the real world. The other possibility is a fallow number gets ported = (I don=E2=80=99t see how that could happen, but let=E2=80=99s say it = might). Again, the solution to the general fallow number scenario = applies here. Also, if someone did manage to use an old certificate on what is now = someone else=E2=80=99s number, the carrier has the certificate and date, = which means they can figure out who had the certificate, which means = they can use legal means to rectify the situation. Diginotar was brought up as a potential reason to check each and every = call=E2=80=99s certificate chain. Again, this is a non-issue in the real = world. Specifically, I doubt there will be 300+ root certificates in the = trusted root store. There might be one or two in the validation = function. These certificates will certainly be pinned. Moreover, they = are likely to have proprietary update mechanisms. Because the draft gets the threat model wrong, it asserts that CRL = distribution is not an answer and that verifiers MUST do in-call dips to = check the validity of the certificate before they validate the call = against the certificate. Well, the draft does propose an optimization: = the authorizer can assert that it is authorized to do the authorization. = That is insane. The vulnerability is precisely that the authorizer is = lying. Relying on a lying element say it is not lying is not a good = policy. I would also offer that we already have an out of band mechanism that is = already established in North America (and similar systems in the UK, = India, much of South America, etc.): carriers already get push = notifications when a number gets ported. One can envision mechanisms, = outside of an IETF protocol, that can let carriers know when certificate = owners might not be the right ones for a particular number. Moreover, = those existing mechanisms blow up the =E2=80=9CCRL=E2=80=99s could not = possibly be used because of volume,=E2=80=9D because a similar process = has been done for close to 20 years at a precisely similar rate of = transactions. --Apple-Mail=_14F69F58-77DC-4DCE-8C45-3E140B906208 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrEMhAAoJEORoZaSQsc1IMcQQAK/Uah3o4aZLbhnqHydDDRcl GFkmz08fQf7ZRTFyXE3aSyvdB1wonFlw2GLeZKgiVB7TtqoDYT9i5sdQ/lW05jam Eo1VUfAJG8NRAxEm7Zli673FWWTN189HN/vT4Oe5ZjjdOmk3E1lg+kbiYnj1clPx Ks0DabPwMyGLgNMLLbthUcDKgHbzJElfETfDwA6E547bIuPmfDDljvsYHvdVcgA9 iqWqZGIHEjKJhRS67P1hN0SovSeXt/1aiE1Im6LxmrXWkk43+Ho4pm2Hx64Xqy51 Vp7kEKGFwvTzP5kh+vEWyETu8RGKyMZr1M5qQpZBxa7Hr1bf/zthfi5//iPQYS4f 3f4Dl3MyMUkvu1Qwnfvanv9Lu0w8a2w6Tx5Dn3Gczc9JWGzGyIlgQqQjedaQYWn/ NNkx4HIN52mt0FzDjaf4W/RNGDsskhGpQPCU15glxYNxEnJdLOalISKIOgElZGIu jUypeoWaauAkDk0EwwTrfeSV/FFIALfy0it3HLdNWyvQZCIEWb41NrCbgS7ZQ4pu 0a+gc9mnCDkgnYir7xqUzm+IGwt1J8rXTkfbB1yCwATkkjQCmDpMCFA7Ax/QloaE qpo+9ci8mGs23QcxV6kkoTCsuDPnjbk7RhPNqYMdb1GsV3nznY2w4++UEX/E3mcv hw3JlfCeV7TDvzWU/TmT =43Wu -----END PGP SIGNATURE----- --Apple-Mail=_14F69F58-77DC-4DCE-8C45-3E140B906208-- From nobody Sun Jul 19 17:39:08 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E145A1B2EC2 for ; Sun, 19 Jul 2015 17:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 sTM5iZQemhfp for ; Sun, 19 Jul 2015 17:39:04 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153FC1B2EC3 for ; Sun, 19 Jul 2015 17:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From; bh=C9Ctj/d+YTXJK0eMd8OrzWu2wMk+HaEdPT9BdEClWWI=; b=tp8T5NuoKCSYzyOJknLQTLlEV+hXikyCdTTjJxhvsvzKOOeNl6iqqmk7kwCCy8iOMpUbSRNwadSwQ0158IZqmusKAwbAQspGNpFGJLM/2VG3eeb0TLztgbRROXazdD2SWdyxWLk+0Bk6PmARKJpwIhUecs1T2c7bPMOKCtvzuW4=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:55999 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZGz6l-0000Nr-3O for stir@ietf.org; Sun, 19 Jul 2015 17:39:03 -0700 From: Eric Burger X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_B3B009DD-2100-4131-B7B7-0EC3AFEE83A1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Sun, 19 Jul 2015 20:38:58 -0400 Message-Id: <27F6ABA7-E475-4EB9-9FEE-93539D78EC8B@standardstrack.com> To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [stir] MIME (Certs draft) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 00:39:05 -0000 --Apple-Mail=_B3B009DD-2100-4131-B7B7-0EC3AFEE83A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello! We are specifying new SIP UA behavior. If we are specifying new = SIP UA behavior, it means that developers will be changing the behavior = (a.k.a. code) of conforming SIP UA=E2=80=99s. Stating that we do not = want to use MIME in the Certificates draft (p. 5) is kind of silly. If = we are telling someone to write a whole bunch of code to do remote = resolution of URI=E2=80=99s, enter into possibly multiple = SUBSCRIBE/NOTIFY dialogs, and (finally!) implement X.509 certificates, I = think we can mandate MIME support. --Apple-Mail=_B3B009DD-2100-4131-B7B7-0EC3AFEE83A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrEMiAAoJEORoZaSQsc1ImnMQALmZVJFPaOeemHu4k2ZOtJXr H/LIHEkKp7PO1fRDMnhMnsTYKU/OT84rAqm45XPePVSpMOoSeFKr6ol7GncWLbS6 KFcnyg3/5CA4j6/dx9CscyHru/ZGkRorGddrCrzfF3IzrAdClA+gRjcXz2G0QJo7 Ms23wj2WmitDQONft0jrjre7L4XKfjlQU2mIkiKLYyJmBy6z/SniXmf0/QIHvysW qGgJhaeNY2jm/c09a7EOlr+aZDYlye8J2zOiFmYj9oj7JoDl+hnBE70ae/g8ZniD 3GQkuE9stChc1oHlxYoRxUyUgGQjghDwhoRY1F7hlUx1/V+nOobmzQPFPz6he23b a5S1l+9a0J+8TtCFLoCaUfHxZkyvSLWFDP4Otp15juqQQOLe5mzG6ZSZ8QTl+U2w TWrV/gbPyd58QGqwNso4lR4p4idILEIqm1Nn7djQYFqGfbK9l6g9XSIl4LELjIqY 1N+GcMYoZtig+mUgxNhJfjXPrZaNR8vHBAIkwnuwVnT/BFg+c9jUDLIzIwRSLdqd N3NdovdVJRktF2eT13ixczCTnU/Bg5WY1l1PWOsGB7CgP+ky4BGs3ddtM4GWph2O cVAT6WGKqWjvipLHpDMAZ1cHRX4ZPIN5cd6xG86q26QaWLeg7VQ0V4ZbZt6zTZsN O8G7bsAKsVz3g4Bi4/7c =Rxqk -----END PGP SIGNATURE----- --Apple-Mail=_B3B009DD-2100-4131-B7B7-0EC3AFEE83A1-- From nobody Sun Jul 19 17:39:10 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE07B1B2EC2 for ; Sun, 19 Jul 2015 17:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.887 X-Spam-Level: X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 aV-YUvQTyIop for ; Sun, 19 Jul 2015 17:39:06 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659F41B2EC3 for ; Sun, 19 Jul 2015 17:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From; bh=gGSjt43A+UwarMrc41v8FN4ngYesVjEtdWkWNJG3irU=; b=Gpa5w8ZVN2AfnJcMLCIejo7eqMVmt+HL9S4H8lHr6+gKFL3pbVJ4ZCS1P0hm/2cZiIK8uqJB0suRPHqQJngWNkvYQilXR6M8SbuBopHRE4YLvJ/q+Z9WW6g8rmUc2Y2pqV+FzunWwDHdUiMdjjWMD4Qot+XNsKxRMod2ZTJYmiQ=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:55999 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZGz6m-0000Nr-6b for stir@ietf.org; Sun, 19 Jul 2015 17:39:05 -0700 From: Eric Burger X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_9B93066B-E784-413A-8C0F-D75DF090DFE0"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Sun, 19 Jul 2015 20:39:01 -0400 Message-Id: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 00:39:07 -0000 --Apple-Mail=_9B93066B-E784-413A-8C0F-D75DF090DFE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The certificates draft points out that one cannot do a rooted signature = over =E2=80=9Canonymous.invalid=E2=80=9D. That is the suggested domain = for anonymous calls per RFC 3261. That is nice, and one could argue that = 4474bis does not eliminate anonymous calling. However, 4474bis gets into = the policy world by stating first of all the service provider should = sign, stating something like =E2=80=9Canonymous@example.net=E2=80=9D. = However, that already leaks what could be significantly revealing = information (think of =E2=80=9Cfbi.gov=E2=80=9D). The draft is close. I would offer the draft is more explicit in Section = 4.2 to state that it is recommended that UAS behavior is to not reject = unsigned requests if the request has an obviously anonymous =46rom = header. For interoperability, it would be good to update 3261 to mandate = =E2=80=9Canonymous@anonymous.invalid=E2=80=9D (I am not tied to the = string, so long as it is one and only one string) to indicate a = universally anonymous identity. This is as opposed to = anonymous@example.net, which would always work because it is just a = user. Anyway, it leaves anonymous@lizardsquad.xxx available, which might = be a real user or group of users. --Apple-Mail=_9B93066B-E784-413A-8C0F-D75DF090DFE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrEMlAAoJEORoZaSQsc1Ii6MP/2bj8ikZwGi9XkOeR/5MrlDp CiIcaXpeb0fXsBcrRXZ9ZdJ3QXsoiAJLsEOGd+5GZbzaBfy7IPZ0hvhc44h2M8x/ RWNvdI72+zMDZ0Rw1xAyA3laXlkyCNIL7g8CFh2NLk/0NEn3igeRoHCVLhXG1Eo2 r77JFEj9y5AuOHpSnlk/0w8CO8XZTzv/jr0cLVS0f4iAYiq6DOoJhzhZk1ufeVYV 16hXbnIm4+2Kgohevo0/hKZ7X5B2dUuDzQpxMAhWM6FM2ETGFF6KVbZflGPamKQW Ya+4jNAAySYBRVzCjycGJbzDi5V1S+tbADNSgzbazQisgDPdZaoJj9opwRUa2cdk 9wFqpGxUqtagATg922d2xNlr3queS9uqYlagVcxYtBzgX2iMktsP7okRkyGyNQxS MV90VNEAavBAklzhqI2uG9QYpVlaii4En3FwjG2qBEP2R4P3VgIyHWYHcM6edCCu uC0bUqXzp726Qs5zZzsKPjUuRGbK9FnQmwFAyznAHvxgqCXHyxJFmDoJxc50NXEa 7hEilTpnbWSo2v5E6uUt+ir76MAmX/wGP6ysuK0bn1g1UokSolVWnZz3feqh2zfP FGZtsE4wZsDRQqEnceXralYLeLBSIZsk9w06oBjxQYPZhJMXkxMI9oNAVF2P/ag1 Esk7rlz6KTwr9mk6z2t/ =g5nJ -----END PGP SIGNATURE----- --Apple-Mail=_9B93066B-E784-413A-8C0F-D75DF090DFE0-- From nobody Mon Jul 20 00:38:36 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D881A0174 for ; Mon, 20 Jul 2015 00:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 E8bd2pEFHUQd for ; Mon, 20 Jul 2015 00:38:33 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2581A0173 for ; Mon, 20 Jul 2015 00:38:33 -0700 (PDT) From: Henning Schulzrinne To: Eric Burger , "stir@ietf.org" Thread-Topic: [stir] MIME (Certs draft) Thread-Index: AQHQwoSCQhpvc1MXJECgzT58xfJVY53j9ags Date: Mon, 20 Jul 2015 07:38:30 +0000 Message-ID: References: <27F6ABA7-E475-4EB9-9FEE-93539D78EC8B@standardstrack.com> In-Reply-To: <27F6ABA7-E475-4EB9-9FEE-93539D78EC8B@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: standardstrack.com; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 5:GBUyRZG1r1ldFVMKGXS0G1DNhR5KYtVEXZjkMJCYyNL6A+N0dEcxxgkVEsEA0Iix15Lnlm189klbTeNHiDcSVBeC2cCfO7xGvuwtQ+m54TeQ0hOZe4OQcg6hCIiN201ETgMQ0ZJfgGjKTwwNd//mgg==; 24:BzdVDXKHU7BE+/AYn1uPbkJwwzrnldJomWBYWKtrTRxYwNIJHcWDyNiLfAzq4XfYy+FQyG73F29Li7JDhkjl/NVIBELOF+RV3StAtfIRKJI=; 20:RgH9dU/6A82jLVnUFJR/Wp97efL8ZN8vqLJFhTDebFLKEpQYi59jNd3bKv2V3H3yGLUgTkM7VQQRwIuKcgFwdg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0633; cy1pr09mb0633: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0643BDA83C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(2656002)(87936001)(122556002)(86362001)(33656002)(189998001)(76576001)(99286002)(40100003)(77156002)(62966003)(2501003)(106116001)(74316001)(50986999)(76176999)(46102003)(19580395003)(19580405001)(2900100001)(2950100001)(5001960100002)(107886002)(5002640100001)(5001920100001)(54356999)(102836002)(5003600100002)(5001770100001)(77096005)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2015 07:38:30.3650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [stir] MIME (Certs draft) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 07:38:34 -0000 Eric, MIME has been a huge implementation hurdle in practice, for two reasons: (1) Many UAs use standard SIP libraries and don't touch the actual SIP head= er (or body). It's a lot easier to add external header processing in that c= ase since this can be layered on top, without mucking with the SIP library.= This is also true for server-based libraries (JAIN SIP, SIP servlets, e.g.= , in Mobicents). (2) Many UAs and SBCs choke on multipart. This makes people reluctant to de= ploy new things since even entities that don't need or want to use the new = feature need to be upgraded or they break things. I've seen multiple instances of this, e.g., in the VRS context. Since we want to get 4474bis deployed incrementally and with dispatch, this= would argue for having a "we really can't do this any other way" justifica= tion for using multi-part. Henning ________________________________________ From: stir on behalf of Eric Burger Sent: Sunday, July 19, 2015 8:38 PM To: stir@ietf.org Subject: [stir] MIME (Certs draft) Hello! We are specifying new SIP UA behavior. If we are specifying new SIP = UA behavior, it means that developers will be changing the behavior (a.k.a.= code) of conforming SIP UA=92s. Stating that we do not want to use MIME in= the Certificates draft (p. 5) is kind of silly. If we are telling someone = to write a whole bunch of code to do remote resolution of URI=92s, enter in= to possibly multiple SUBSCRIBE/NOTIFY dialogs, and (finally!) implement X.5= 09 certificates, I think we can mandate MIME support. From nobody Mon Jul 20 00:49:51 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9EA1A0119 for ; Mon, 20 Jul 2015 00:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 CDUaZWgNACTl for ; Mon, 20 Jul 2015 00:49:46 -0700 (PDT) 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 E8A071A0273 for ; Mon, 20 Jul 2015 00:49:44 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.15.0.59/8.14.7) with SMTP id t6K7iP6u014091; Mon, 20 Jul 2015 03:49:43 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1vr697t4rr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 03:49:43 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 20 Jul 2015 03:49:42 -0400 From: "Peterson, Jon" To: Henning Schulzrinne Thread-Topic: [stir] MIME (Certs draft) Thread-Index: AQHQwoSAWmnIKGIRTkup6eP2J1bfM53kPCoA///AEz8= Date: Mon, 20 Jul 2015 07:49:42 +0000 Message-ID: <811BF5D7-A284-4C62-83E5-F56ABC70EF4D@neustar.biz> References: <27F6ABA7-E475-4EB9-9FEE-93539D78EC8B@standardstrack.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-20_01:2015-07-17,2015-07-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507200125 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] MIME (Certs draft) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 07:49:50 -0000 Moreover, the certs draft does not say "don't use MIME." It says that multi= part/MIME is one way to convey certificates, but that it has known problems= (as Henning observes) and that there are other ways. Suggesting that the c= erts draft discourages that SIP implementations from using MIME or what hav= e you is just bizarre. The certs draft actually allows MIME as a transport = for certs.=20 Jon Peterson Neustar, Inc, Sent from my iPad > On Jul 20, 2015, at 9:38 AM, Henning Schulzrinne wrote: >=20 > Eric, >=20 > MIME has been a huge implementation hurdle in practice, for two reasons: >=20 > (1) Many UAs use standard SIP libraries and don't touch the actual SIP he= ader (or body). It's a lot easier to add external header processing in that= case since this can be layered on top, without mucking with the SIP librar= y. This is also true for server-based libraries (JAIN SIP, SIP servlets, e.= g., in Mobicents). >=20 > (2) Many UAs and SBCs choke on multipart. This makes people reluctant to = deploy new things since even entities that don't need or want to use the ne= w feature need to be upgraded or they break things. >=20 > I've seen multiple instances of this, e.g., in the VRS context. >=20 > Since we want to get 4474bis deployed incrementally and with dispatch, th= is would argue for having a "we really can't do this any other way" justifi= cation for using multi-part. >=20 > Henning >=20 > ________________________________________ > From: stir on behalf of Eric Burger > Sent: Sunday, July 19, 2015 8:38 PM > To: stir@ietf.org > Subject: [stir] MIME (Certs draft) >=20 > Hello! We are specifying new SIP UA behavior. If we are specifying new SI= P UA behavior, it means that developers will be changing the behavior (a.k.= a. code) of conforming SIP UA=92s. Stating that we do not want to use MIME = in the Certificates draft (p. 5) is kind of silly. If we are telling someon= e to write a whole bunch of code to do remote resolution of URI=92s, enter = into possibly multiple SUBSCRIBE/NOTIFY dialogs, and (finally!) implement X= .509 certificates, I think we can mandate MIME support. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Jul 20 00:59:44 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBF41A01C6 for ; Mon, 20 Jul 2015 00:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.266 X-Spam-Level: X-Spam-Status: No, score=-102.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 0pVEEV7yv_px for ; Mon, 20 Jul 2015 00:59:40 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 F35F01A0242 for ; Mon, 20 Jul 2015 00:59:39 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6K7tWiR027702; Mon, 20 Jul 2015 03:59:39 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vr40jt8w4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 03:59:39 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 20 Jul 2015 03:59:37 -0400 From: "Peterson, Jon" To: Eric Burger Thread-Topic: [stir] In-line certificate checking Thread-Index: AQHQwoSAnl43mN82gU+fE3HwAq+WaZ3j/wI9 Date: Mon, 20 Jul 2015 07:59:37 +0000 Message-ID: <821056A8-BB85-4C84-8B4E-50D74F8BDE25@neustar.biz> References: <15459DB2-A599-4BA3-81CF-7536719612B8@standardstrack.com> In-Reply-To: <15459DB2-A599-4BA3-81CF-7536719612B8@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_821056A8BB854C848B4E50D74F8BDE25neustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-20_01:2015-07-17,2015-07-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507200126 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] In-line certificate checking X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 07:59:42 -0000 --_000_821056A8BB854C848B4E50D74F8BDE25neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Because the draft gets the threat model wrong, it asserts that CRL distribu= tion is not an answer and that verifiers MUST do in-call dips to check the = validity of the certificate before they validate the call against the certi= ficate. No, it doesn't. Not only does it not stipulate that verifiers MUST do OCSP,= it only lists it as a SHOULD that certs contain a link to an OCSP service = at all. It discusses numerous alternatives for establishing current cert sc= ope: for example, future work on subscription-based approaches. Number portability is not part of the "threat model," the threat model is a= bout impersonation - robocalling, voicemail hacking, and all that. To defea= t those threats, you need a means to determine if a particular number is wi= thin the scope of the credential. This is the part of the STIR work that is= fairly novel - it isn't baseline X.509 behavior to have a TNAuthList dicta= te credential scope. It is not clear that the TNAuthList will actually appe= ar in every cert, even - we want to be able to include it by reference. The= se are the sorts of practicalities that motivated the OCSP TNQuery extensio= n and the new AIA accessMethod proposed in the draft. But they are not mand= atory, and number portability is only one example of how the scope of these= certs might be dynamic. We know that there will be high volume environments for STIR, and we do exp= ect optimizations will be required for these environments - like potentiall= y a push model for cert scope changes. But let's crawl before we walk. Jon Peterson Neustar, Inc, Sent from my iPad On Jul 20, 2015, at 2:39 AM, Eric Burger > wrote: The threat model for revoked certificates is beyond wrong and results in pu= tting a burden of 100,000+ tps during busy hour on exemplary networks, such= as AT&T and Verizon in the U.S. Note that not only are they making that ma= gnitude of queries, but they are also responding to more than that magnitud= e of queries. The fundamental error is that the threat model presumes that a number port = will break the certificate. Well, that is correct. If you port your number = from AT&T to Verizon, AT&T should not be able to sign for your CLID. Howeve= r, it does not matter. You ported the number, which means you are the numbe= r, which means that it does not matter whether AT&T or Verizon signs for it= , the number still points to you. So, the fundamental error is in thinking = who vouched for the end user matters. It does not. The other cases that one might think could matter also do not matter. Speci= fically, if a fallow number gets reassigned, the old subscriber could then = start reusing their old number. This does not matter because the protocol c= an simply specify that the certificate lifetime MUST be shorter than the se= rvice provider=92s fallow period. Since certificates will have a lifetime o= f at most days, this is not a problem in the real world. The other possibil= ity is a fallow number gets ported (I don=92t see how that could happen, bu= t let=92s say it might). Again, the solution to the general fallow number s= cenario applies here. Also, if someone did manage to use an old certificate on what is now someon= e else=92s number, the carrier has the certificate and date, which means th= ey can figure out who had the certificate, which means they can use legal m= eans to rectify the situation. Diginotar was brought up as a potential reason to check each and every call= =92s certificate chain. Again, this is a non-issue in the real world. Speci= fically, I doubt there will be 300+ root certificates in the trusted root s= tore. There might be one or two in the validation function. These certifica= tes will certainly be pinned. Moreover, they are likely to have proprietary= update mechanisms. Because the draft gets the threat model wrong, it asserts that CRL distribu= tion is not an answer and that verifiers MUST do in-call dips to check the = validity of the certificate before they validate the call against the certi= ficate. Well, the draft does propose an optimization: the authorizer can as= sert that it is authorized to do the authorization. That is insane. The vul= nerability is precisely that the authorizer is lying. Relying on a lying el= ement say it is not lying is not a good policy. I would also offer that we already have an out of band mechanism that is al= ready established in North America (and similar systems in the UK, India, m= uch of South America, etc.): carriers already get push notifications when a= number gets ported. One can envision mechanisms, outside of an IETF protoc= ol, that can let carriers know when certificate owners might not be the rig= ht ones for a particular number. Moreover, those existing mechanisms blow u= p the =93CRL=92s could not possibly be used because of volume,=94 because a= similar process has been done for close to 20 years at a precisely similar= rate of transactions. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_821056A8BB854C848B4E50D74F8BDE25neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Because the draft gets the threat model wr= ong, it asserts that CRL distribution is not an answer and that verifiers M= UST do in-call dips to check the validity of the certificate before they validate the call against the certificate.<= /span>

No, it doesn't. Not only does it not stipulate that verifiers MUST do = OCSP, it only lists it as a SHOULD that certs contain a link to an OCSP ser= vice at all. It discusses numerous alternatives for establishing current ce= rt scope: for example, future work on subscription-based approaches. 

Number portability is not part of the "threat model," the th= reat model is about impersonation - robocalling, voicemail hacking, and all= that. To defeat those threats, you need a means to determine if a particul= ar number is within the scope of the credential. This is the part of the STIR work that is fairly novel - it isn't baseline= X.509 behavior to have a TNAuthList dictate credential scope. It is not cl= ear that the TNAuthList will actually appear in every cert, even - we want = to be able to include it by reference. These are the sorts of practicalities that motivated the OCSP TNQuery exte= nsion and the new AIA accessMethod proposed in the draft. But they are not = mandatory, and number portability is only one example of how the scope of t= hese certs might be dynamic. 

We know that there will be high volume environments for STIR, and we d= o expect optimizations will be required for these environments - like poten= tially a push model for cert scope changes. But let's crawl before we walk.=

Jon Peterson
Neustar, Inc, 

Sent from my iPad

On Jul 20, 2015, at 2:39 AM, Eric Burger <eburger@standardstrack.com> wrote:

The threat model for revoked certificates is beyond wrong and re= sults in putting a burden of 100,000+ tps during busy hour on exemplary= networks, such as AT&T and Verizon in the U.S. Note that not only are = they making that magnitude of queries, but they are also responding to more than that magnitude of queries.
The fundamental error is that the threat model presumes that a number= port will break the certificate. Well, that is correct. If you port your n= umber from AT&T to Verizon, AT&T should not be able to sign for you= r CLID. However, it does not matter. You ported the number, which means you are the number, which means that it doe= s not matter whether AT&T or Verizon signs for it, the number still poi= nts to you. So, the fundamental error is in thinking who vouched for the en= d user matters. It does not.

The other cases that one might think could matter also do not matter.= Specifically, if a fallow number gets reassigned, the old subscriber could= then start reusing their old number. This does not matter because the prot= ocol can simply specify that the certificate lifetime MUST be shorter than the service provider=92s fallow = period. Since certificates will have a lifetime of at most days, this is no= t a problem in the real world. The other possibility is a fallow number get= s ported (I don=92t see how that could happen, but let=92s say it might). Again, the solution to the general fall= ow number scenario applies here.

Also, if someone did manage to use an old certificate on what is now = someone else=92s number, the carrier has the certificate and date, which me= ans they can figure out who had the certificate, which means they can use l= egal means to rectify the situation.

Diginotar was brought up as a potential reason to check each and ever= y call=92s certificate chain. Again, this is a non-issue in the real world.= Specifically, I doubt there will be 300+ root certificates in the trus= ted root store. There might be one or two in the validation function. These certificates will certainly be pinne= d. Moreover, they are likely to have proprietary update mechanisms.<= br>
Because the draft gets the threat model wrong, it asserts that CRL di= stribution is not an answer and that verifiers MUST do in-call dips to chec= k the validity of the certificate before they validate the call against the= certificate. Well, the draft does propose an optimization: the authorizer can assert that it is authorized t= o do the authorization. That is insane. The vulnerability is precisely that= the authorizer is lying. Relying on a lying element say it is not lying is= not a good policy.

I would also offer that we already have an out of band mechanism that= is already established in North America (and similar systems in the UK, In= dia, much of South America, etc.): carriers already get push notifications = when a number gets ported. One can envision mechanisms, outside of an IETF protocol, that can let carriers kn= ow when certificate owners might not be the right ones for a particular num= ber. Moreover, those existing mechanisms blow up the =93CRL=92s could not p= ossibly be used because of volume,=94 because a similar process has been done for close to 20 years at a precise= ly similar rate of transactions.
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ie= tf.org/mailman/listinfo/stir
--_000_821056A8BB854C848B4E50D74F8BDE25neustarbiz_-- From nobody Mon Jul 20 01:07:21 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6301A038D for ; Mon, 20 Jul 2015 01:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 DBsOT0tdYWuj for ; Mon, 20 Jul 2015 01:07:19 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 1EA7C1A038B for ; Mon, 20 Jul 2015 01:07:19 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6K86dF8008114; Mon, 20 Jul 2015 04:07:18 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vrt8j07tf-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 04:07:18 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 20 Jul 2015 04:07:16 -0400 From: "Peterson, Jon" To: Eric Burger Thread-Topic: [stir] Anonymous Calling Thread-Index: AQHQwoSDGWiLBfrzXkujhpdlfQ0qT53kASW/ Date: Mon, 20 Jul 2015 08:07:15 +0000 Message-ID: References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> In-Reply-To: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-20_01:2015-07-17,2015-07-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507200129 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 08:07:20 -0000 Actually, the certificates draft doesn't talk about anonymity at all. I ass= ume you mean rfc4474bis.=20 The text in Section 9 (2nd and 3rd paragraph) that seems to be confusing yo= u here talks about both the recommendations in RFC3323 and RFC3261. If you = are using an RFC3323 anonymization service, you will have a URI with a vali= d host portion (which could theoretically be signed). If you are using anon= ymous.invalid as a host, as RFC3261 used, then obviously no service can or = should sign it. But rfc4474bis in no way endorses one approach or the other= , or in some other way veers into this nebulous realm of "policy." It merel= y explains how the signature mechanism would interact with either of this c= hoices.=20 Rereading that text, I don't think there any need to make that clearer.=20 Jon Peterson Neustar, Inc, Sent from my iPad > On Jul 20, 2015, at 2:39 AM, Eric Burger wro= te: >=20 > The certificates draft points out that one cannot do a rooted signature o= ver =93anonymous.invalid=94. That is the suggested domain for anonymous cal= ls per RFC 3261. That is nice, and one could argue that 4474bis does not el= iminate anonymous calling. However, 4474bis gets into the policy world by s= tating first of all the service provider should sign, stating something lik= e =93anonymous@example.net=94. However, that already leaks what could be si= gnificantly revealing information (think of =93fbi.gov=94). >=20 > The draft is close. I would offer the draft is more explicit in Section 4= .2 to state that it is recommended that UAS behavior is to not reject unsig= ned requests if the request has an obviously anonymous From header. >=20 > For interoperability, it would be good to update 3261 to mandate =93anony= mous@anonymous.invalid=94 (I am not tied to the string, so long as it is on= e and only one string) to indicate a universally anonymous identity. This i= s as opposed to anonymous@example.net, which would always work because it i= s just a user. Anyway, it leaves anonymous@lizardsquad.xxx available, which= might be a real user or group of users. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Jul 20 01:13:56 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766C71A038B for ; Mon, 20 Jul 2015 01:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 m_xnt2EjQX8R for ; Mon, 20 Jul 2015 01:13:52 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4D41A0AF1 for ; Mon, 20 Jul 2015 01:13:49 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id dbdaca55.0.5807952.00-2273.16396756.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 20 Jul 2015 08:13:50 +0000 (UTC) X-MXL-Hash: 55acadbe557ef58d-959821bde330a15227ac9ca148ebdf64faf9d1e4 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 t6K8Dm2m002727; Mon, 20 Jul 2015 04:13:49 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6K8Di51002660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jul 2015 04:13:45 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 20 Jul 2015 08:13:37 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.130]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0224.002; Mon, 20 Jul 2015 04:13:36 -0400 From: "DOLLY, MARTIN C" To: "Peterson, Jon" Thread-Topic: [stir] Anonymous Calling Thread-Index: AQHQwoSCsKCgN2TvS0SKjO0sK+vacJ3kRDKAgAABt4A= Date: Mon, 20 Jul 2015 08:13:36 +0000 Message-ID: References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.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-ID: <73D74747BAE95D48AB92CFED661B94C1@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=IsOphsDg c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=zOBTXjUuO1YA:10 a=hGBaWAWWAAAA:8 a=bfLui] X-AnalysisOut: [RfvAAAA:8 a=OK-8mIdLAAAA:8 a=48vgC7mUAAAA:8 a=JK-CxkLotH_T] X-AnalysisOut: [V89MpWQA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 08:13:54 -0000 VGhlcmUgYXJlIGNhc2VzIHdoZXJlIGFub255bW91cyBzaG91bGQgYmUgc2lnbmVkDQoNClNlbnQg ZnJvbSBteSBpUGhvbmUNCg0KPiBPbiBKdWwgMjAsIDIwMTUsIGF0IDQ6MDcgQU0sIFBldGVyc29u LCBKb24gPGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpej4gd3JvdGU6DQo+IA0KPiANCj4gQWN0dWFs bHksIHRoZSBjZXJ0aWZpY2F0ZXMgZHJhZnQgZG9lc24ndCB0YWxrIGFib3V0IGFub255bWl0eSBh dCBhbGwuIEkgYXNzdW1lIHlvdSBtZWFuIHJmYzQ0NzRiaXMuIA0KPiANCj4gVGhlIHRleHQgaW4g U2VjdGlvbiA5ICgybmQgYW5kIDNyZCBwYXJhZ3JhcGgpIHRoYXQgc2VlbXMgdG8gYmUgY29uZnVz aW5nIHlvdSBoZXJlIHRhbGtzIGFib3V0IGJvdGggdGhlIHJlY29tbWVuZGF0aW9ucyBpbiBSRkMz MzIzIGFuZCBSRkMzMjYxLiBJZiB5b3UgYXJlIHVzaW5nIGFuIFJGQzMzMjMgYW5vbnltaXphdGlv biBzZXJ2aWNlLCB5b3Ugd2lsbCBoYXZlIGEgVVJJIHdpdGggYSB2YWxpZCBob3N0IHBvcnRpb24g KHdoaWNoIGNvdWxkIHRoZW9yZXRpY2FsbHkgYmUgc2lnbmVkKS4gSWYgeW91IGFyZSB1c2luZyBh bm9ueW1vdXMuaW52YWxpZCBhcyBhIGhvc3QsIGFzIFJGQzMyNjEgdXNlZCwgdGhlbiBvYnZpb3Vz bHkgbm8gc2VydmljZSBjYW4gb3Igc2hvdWxkIHNpZ24gaXQuIEJ1dCByZmM0NDc0YmlzIGluIG5v IHdheSBlbmRvcnNlcyBvbmUgYXBwcm9hY2ggb3IgdGhlIG90aGVyLCBvciBpbiBzb21lIG90aGVy IHdheSB2ZWVycyBpbnRvIHRoaXMgbmVidWxvdXMgcmVhbG0gb2YgInBvbGljeS4iIEl0IG1lcmVs eSBleHBsYWlucyBob3cgdGhlIHNpZ25hdHVyZSBtZWNoYW5pc20gd291bGQgaW50ZXJhY3Qgd2l0 aCBlaXRoZXIgb2YgdGhpcyBjaG9pY2VzLiANCj4gDQo+IFJlcmVhZGluZyB0aGF0IHRleHQsIEkg ZG9uJ3QgdGhpbmsgdGhlcmUgYW55IG5lZWQgdG8gbWFrZSB0aGF0IGNsZWFyZXIuIA0KPiANCj4g Sm9uIFBldGVyc29uDQo+IE5ldXN0YXIsIEluYywNCj4gDQo+IFNlbnQgZnJvbSBteSBpUGFkDQo+ IA0KPj4gT24gSnVsIDIwLCAyMDE1LCBhdCAyOjM5IEFNLCBFcmljIEJ1cmdlciA8ZWJ1cmdlckBz dGFuZGFyZHN0cmFjay5jb20+IHdyb3RlOg0KPj4gDQo+PiBUaGUgY2VydGlmaWNhdGVzIGRyYWZ0 IHBvaW50cyBvdXQgdGhhdCBvbmUgY2Fubm90IGRvIGEgcm9vdGVkIHNpZ25hdHVyZSBvdmVyIOKA nGFub255bW91cy5pbnZhbGlk4oCdLiBUaGF0IGlzIHRoZSBzdWdnZXN0ZWQgZG9tYWluIGZvciBh bm9ueW1vdXMgY2FsbHMgcGVyIFJGQyAzMjYxLiBUaGF0IGlzIG5pY2UsIGFuZCBvbmUgY291bGQg YXJndWUgdGhhdCA0NDc0YmlzIGRvZXMgbm90IGVsaW1pbmF0ZSBhbm9ueW1vdXMgY2FsbGluZy4g SG93ZXZlciwgNDQ3NGJpcyBnZXRzIGludG8gdGhlIHBvbGljeSB3b3JsZCBieSBzdGF0aW5nIGZp cnN0IG9mIGFsbCB0aGUgc2VydmljZSBwcm92aWRlciBzaG91bGQgc2lnbiwgc3RhdGluZyBzb21l dGhpbmcgbGlrZSDigJxhbm9ueW1vdXNAZXhhbXBsZS5uZXTigJ0uIEhvd2V2ZXIsIHRoYXQgYWxy ZWFkeSBsZWFrcyB3aGF0IGNvdWxkIGJlIHNpZ25pZmljYW50bHkgcmV2ZWFsaW5nIGluZm9ybWF0 aW9uICh0aGluayBvZiDigJxmYmkuZ2924oCdKS4NCj4+IA0KPj4gVGhlIGRyYWZ0IGlzIGNsb3Nl LiBJIHdvdWxkIG9mZmVyIHRoZSBkcmFmdCBpcyBtb3JlIGV4cGxpY2l0IGluIFNlY3Rpb24gNC4y IHRvIHN0YXRlIHRoYXQgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCBVQVMgYmVoYXZpb3IgaXMgdG8g bm90IHJlamVjdCB1bnNpZ25lZCByZXF1ZXN0cyBpZiB0aGUgcmVxdWVzdCBoYXMgYW4gb2J2aW91 c2x5IGFub255bW91cyBGcm9tIGhlYWRlci4NCj4+IA0KPj4gRm9yIGludGVyb3BlcmFiaWxpdHks IGl0IHdvdWxkIGJlIGdvb2QgdG8gdXBkYXRlIDMyNjEgdG8gbWFuZGF0ZSDigJxhbm9ueW1vdXNA YW5vbnltb3VzLmludmFsaWTigJ0gKEkgYW0gbm90IHRpZWQgdG8gdGhlIHN0cmluZywgc28gbG9u ZyBhcyBpdCBpcyBvbmUgYW5kIG9ubHkgb25lIHN0cmluZykgdG8gaW5kaWNhdGUgYSB1bml2ZXJz YWxseSBhbm9ueW1vdXMgaWRlbnRpdHkuIFRoaXMgaXMgYXMgb3Bwb3NlZCB0byBhbm9ueW1vdXNA ZXhhbXBsZS5uZXQsIHdoaWNoIHdvdWxkIGFsd2F5cyB3b3JrIGJlY2F1c2UgaXQgaXMganVzdCBh IHVzZXIuIEFueXdheSwgaXQgbGVhdmVzIGFub255bW91c0BsaXphcmRzcXVhZC54eHggYXZhaWxh YmxlLCB3aGljaCBtaWdodCBiZSBhIHJlYWwgdXNlciBvciBncm91cCBvZiB1c2Vycy4NCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzdGlyIG1h aWxpbmcgbGlzdA0KPj4gc3RpckBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zdGlyDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBzdGlyIG1haWxpbmcgbGlzdA0KPiBzdGlyQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0K From nobody Mon Jul 20 01:24:43 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921F81A07BD for ; Mon, 20 Jul 2015 01:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 S27fEEcWwD82 for ; Mon, 20 Jul 2015 01:24:40 -0700 (PDT) Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) (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 A25721A06E9 for ; Mon, 20 Jul 2015 01:24:40 -0700 (PDT) Received: by qkdv3 with SMTP id v3so107769792qkd.3 for ; Mon, 20 Jul 2015 01:24:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HEg5HsR5CsjwcJAjpmQRefCgEbKtUJ+K2izaT/6A1Co=; b=a8AVFdiI1NuSxfNYJ1UR7nFSFoHyws11xp+NQyOYYxQZ6KEzi0WoCBPj0Ealo6NBRK JiCmZHxUGv3pCACdhPG00q6VtXKokbDzJ3qPGPgKimf64Bb9VA0EyF09J35edWSOfs4+ EQ11r3Eva5SRJr2UhCz697QdUqniAxsJhLKeC2fpRw1mEQ/5EX5RmT11D/s0gHxMfZXE bI6P90rM3R20uSPaNX+NB/n2eE6pjELcxnoS/SeASqDsAQRmd01XG21dy4hra9VAvenL LreXMn3bFpqVDItlDdRkL9g8YgvtsfDJwLrXS18viu9g0nFh0kIa8E0FQDAObSnQgpyD HEsQ== X-Gm-Message-State: ALoCoQl1hcofGxgoduddsS4ifvntLnKrRo3d3XDsKB57PTPcZhTdva798c/VP6zIpP9r0rjuCp5R X-Received: by 10.55.21.41 with SMTP id f41mr45568725qkh.48.1437380679929; Mon, 20 Jul 2015 01:24:39 -0700 (PDT) Received: from mrichards3-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id z81sm10575379qkg.44.2015.07.20.01.24.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Jul 2015 01:24:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Brian Rosen In-Reply-To: Date: Mon, 20 Jul 2015 10:24:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "stir@ietf.org" , Jon Peterson Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 08:24:42 -0000 Who is signing, and what are they attesting? stir is supposed to be about making sure that the identifier in the =46rom= is delegated to the entity placing the call. It is not =E2=80=9Cthis = is a call from a trusted party" That would preclude anyone signing a call from anonymous.invalid because = there is no delegation to anonymous.invalid Brian > On Jul 20, 2015, at 10:13 AM, DOLLY, MARTIN C wrote: >=20 > There are cases where anonymous should be signed >=20 > Sent from my iPhone >=20 >> On Jul 20, 2015, at 4:07 AM, Peterson, Jon = wrote: >>=20 >>=20 >> Actually, the certificates draft doesn't talk about anonymity at all. = I assume you mean rfc4474bis.=20 >>=20 >> The text in Section 9 (2nd and 3rd paragraph) that seems to be = confusing you here talks about both the recommendations in RFC3323 and = RFC3261. If you are using an RFC3323 anonymization service, you will = have a URI with a valid host portion (which could theoretically be = signed). If you are using anonymous.invalid as a host, as RFC3261 used, = then obviously no service can or should sign it. But rfc4474bis in no = way endorses one approach or the other, or in some other way veers into = this nebulous realm of "policy." It merely explains how the signature = mechanism would interact with either of this choices.=20 >>=20 >> Rereading that text, I don't think there any need to make that = clearer.=20 >>=20 >> Jon Peterson >> Neustar, Inc, >>=20 >> Sent from my iPad >>=20 >>> On Jul 20, 2015, at 2:39 AM, Eric Burger = wrote: >>>=20 >>> The certificates draft points out that one cannot do a rooted = signature over =E2=80=9Canonymous.invalid=E2=80=9D. That is the = suggested domain for anonymous calls per RFC 3261. That is nice, and one = could argue that 4474bis does not eliminate anonymous calling. However, = 4474bis gets into the policy world by stating first of all the service = provider should sign, stating something like = =E2=80=9Canonymous@example.net=E2=80=9D. However, that already leaks = what could be significantly revealing information (think of = =E2=80=9Cfbi.gov=E2=80=9D). >>>=20 >>> The draft is close. I would offer the draft is more explicit in = Section 4.2 to state that it is recommended that UAS behavior is to not = reject unsigned requests if the request has an obviously anonymous =46rom = header. >>>=20 >>> For interoperability, it would be good to update 3261 to mandate = =E2=80=9Canonymous@anonymous.invalid=E2=80=9D (I am not tied to the = string, so long as it is one and only one string) to indicate a = universally anonymous identity. This is as opposed to = anonymous@example.net, which would always work because it is just a = user. Anyway, it leaves anonymous@lizardsquad.xxx available, which might = be a real user or group of users. >>> _______________________________________________ >>> 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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Jul 20 01:26:38 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF841A0334 for ; Mon, 20 Jul 2015 01:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 662NijDBWElE for ; Mon, 20 Jul 2015 01:26:34 -0700 (PDT) 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 E6C7E1A0199 for ; Mon, 20 Jul 2015 01:26:33 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6K8P5EE028933; Mon, 20 Jul 2015 04:26:33 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1vqdxmvasx-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 04:26:32 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 20 Jul 2015 04:26:32 -0400 From: "Peterson, Jon" To: Eric Burger Thread-Topic: [stir] Policy/Architecture versus Protocol Thread-Index: AQHQwoR6H/TcSYTeCUePSo6//QMatp3kBoeM Date: Mon, 20 Jul 2015 08:26:32 +0000 Message-ID: <00D491C8-508C-4CFB-9A00-753964A05F71@neustar.biz> References: <9410E673-B964-4747-9FB2-91694817C8FA@standardstrack.com> In-Reply-To: <9410E673-B964-4747-9FB2-91694817C8FA@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-20_01:2015-07-17,2015-07-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507200136 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Policy/Architecture versus Protocol X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 08:26:36 -0000 Perhaps unsurprisingly, I don't see the need to break this draft into separ= ate protocol and policy documents - largely because I don't think there's m= uch by way of policy lurking in the pages of rfc4474bis.=20 The term "authentication service" follows the RFC3261 usage of "location se= rvice" as a logical function that might be instantiated by either an endpoi= nt or an intermediary. There is considerable text in rfc4474bis (almost all= of it retained from RFC4474) that explains how an authentication service c= an be an endpoint, for example.=20 And the notion that an authentication service MUST authenticate the entity = whose identity it is attesting seems to me not so much a statement of polic= y as a tautology. It is by definition what the service does. The text in 4.= 1 makes it very clear that it is entirely a matter of local policy how an a= uthentication service authenticates users, and even gives an example of an = endpoint considering a user authenticated simply by virtue to having access= to the endpoint device. A reading of that sentence in 4.1 as requiring tha= t an intermediary MUST challenge a SIP request with a 407 or something woul= d I think be quickly clarified by glancing at any of the surrounding text. = It would indeed be unhelpful and unenforceable, so I'm glad the spec doesn'= t say that.=20 Taking a step back, I do think there could be some benefit in a document th= at talks about authorization policy and practices - especially when and if = we have some operational experience with these mechanisms. But rfc4474 has = been careful not stray into those questions.=20 Jon Peterson Neustar, Inc. Sent from my iPad > On Jul 20, 2015, at 2:39 AM, Eric Burger wro= te: >=20 > We (the IETF) are good at protocols. We are not quite as good at architec= tures. We suck at policy. >=20 > High-level: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > A major weakness of the current 4474bis-04 draft is rather than focus on = the protocol extension, it has a lot of focus on the architecture. Moreover= , sometimes it makes policy suggestions, other times it makes policy decisi= ons. >=20 > This draft could be made much clearer by taking out the architecture and = policy stuff and moving that to a different document. I would offer that fi= ts into the current charter, because the charter wisely says "Submit in-ban= d mechanism for Proposed Standard,=94 not =93update 4474.=94 Yes, I will v= olunteer to put together that document. >=20 >=20 > Details: > =3D=3D=3D=3D=3D=3D=3D=3D > The draft speaks of an authentication service and a validation service. I= t then goes on to specify an architecture, where the authentication service= is literally a service, most likely in or near an outbound proxy or B2BUA = (explicit in the draft) and the validation service is literally a service, = most likely in a P-CSCF or SBC (not by name in the draft, but certainly by = implication). >=20 > It would be much cleaner if the draft focused on the behavior of the SIP = UAC that implements an authentication function and a SIP UAS that implement= s a validation function. We (the IETF) are good at that. That means we can = take out all of the confusing language about unenforceable and outside the = scope of the IETF restrictions on the authentication function. For example,= show me where in SIP one can enforce that an intermediary MUST authenticat= e SIP users (Section 4.1)? >=20 > We manage to leave the interaction of an IP PBX to a phone alone. For exa= mple, we do not specify that an IP PBX *MUST* be a SIP Proxy that can only = help a SIP phone route calls. It might be that, it might be a SIP B2BUA, or= , for that matter, the protocol between the phone and the IP PBX could be S= kinny (SCCP) ;-) >=20 > Likewise, we should leave the interaction between an outbound proxy that = happens to do the authentication *function* and the phone as a local matter= . Yes, we can help implementors, which would be the different document I me= ntioned above. >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Jul 20 01:30:57 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8621A1A34 for ; Mon, 20 Jul 2015 01:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 pIMvl4at5bI1 for ; Mon, 20 Jul 2015 01:30:52 -0700 (PDT) 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 C7F851A1A2C for ; Mon, 20 Jul 2015 01:30:52 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.15.0.59/8.14.7) with SMTP id t6K8OIQM008603; Mon, 20 Jul 2015 04:30:50 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1vr697t6jd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 04:30:50 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Mon, 20 Jul 2015 04:30:49 -0400 From: "Peterson, Jon" To: "DOLLY, MARTIN C" Thread-Topic: [stir] Anonymous Calling Thread-Index: AQHQwoSDGWiLBfrzXkujhpdlfQ0qT53kASW/gABE0wD//8HC3Q== Date: Mon, 20 Jul 2015 08:30:49 +0000 Message-ID: <54A21AF9-91E5-4F97-9B4B-4AC27AD5A0C6@neustar.biz> References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-20_01:2015-07-17,2015-07-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507200136 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 08:30:54 -0000 Agreed, those are RFC3323 cases, where there is a signable domain. 4474bis = allows that. Jon Peterson Neustar, Inc. Sent from my iPad > On Jul 20, 2015, at 10:13 AM, DOLLY, MARTIN C wrote: >=20 > There are cases where anonymous should be signed >=20 > Sent from my iPhone >=20 >> On Jul 20, 2015, at 4:07 AM, Peterson, Jon wr= ote: >>=20 >>=20 >> Actually, the certificates draft doesn't talk about anonymity at all. I = assume you mean rfc4474bis.=20 >>=20 >> The text in Section 9 (2nd and 3rd paragraph) that seems to be confusing= you here talks about both the recommendations in RFC3323 and RFC3261. If y= ou are using an RFC3323 anonymization service, you will have a URI with a v= alid host portion (which could theoretically be signed). If you are using a= nonymous.invalid as a host, as RFC3261 used, then obviously no service can = or should sign it. But rfc4474bis in no way endorses one approach or the ot= her, or in some other way veers into this nebulous realm of "policy." It me= rely explains how the signature mechanism would interact with either of thi= s choices.=20 >>=20 >> Rereading that text, I don't think there any need to make that clearer.= =20 >>=20 >> Jon Peterson >> Neustar, Inc, >>=20 >> Sent from my iPad >>=20 >>> On Jul 20, 2015, at 2:39 AM, Eric Burger w= rote: >>>=20 >>> The certificates draft points out that one cannot do a rooted signature= over =93anonymous.invalid=94. That is the suggested domain for anonymous c= alls per RFC 3261. That is nice, and one could argue that 4474bis does not = eliminate anonymous calling. However, 4474bis gets into the policy world by= stating first of all the service provider should sign, stating something l= ike =93anonymous@example.net=94. However, that already leaks what could be = significantly revealing information (think of =93fbi.gov=94). >>>=20 >>> The draft is close. I would offer the draft is more explicit in Section= 4.2 to state that it is recommended that UAS behavior is to not reject uns= igned requests if the request has an obviously anonymous From header. >>>=20 >>> For interoperability, it would be good to update 3261 to mandate =93ano= nymous@anonymous.invalid=94 (I am not tied to the string, so long as it is = one and only one string) to indicate a universally anonymous identity. This= is as opposed to anonymous@example.net, which would always work because it= is just a user. Anyway, it leaves anonymous@lizardsquad.xxx available, whi= ch might be a real user or group of users. >>> _______________________________________________ >>> 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 From nobody Mon Jul 20 02:05:11 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BC81A1A87 for ; Mon, 20 Jul 2015 02:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 P9USZOiZ4UJC for ; Mon, 20 Jul 2015 02:05:07 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469911A1A80 for ; Mon, 20 Jul 2015 02:05:05 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail31.telekom.de with ESMTP; 20 Jul 2015 11:05:02 +0200 X-IronPort-AV: E=Sophos;i="5.15,507,1432591200"; d="scan'208";a="709132681" Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 20 Jul 2015 11:05:01 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 20 Jul 2015 11:05:01 +0200 From: To: , Date: Mon, 20 Jul 2015 11:05:00 +0200 Thread-Topic: [stir] Anonymous Calling Thread-Index: AdDCxYoWW+UYhxoFSHG32h3tYZ8oMAAA7Xyg Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01EF89806D8E@HE113667.emea1.cds.t-internal.com> References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> In-Reply-To: <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: stir@ietf.org, jon.peterson@neustar.biz Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 09:05:10 -0000 SGksDQpJIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlLg0KDQpJZiB5b3Uga25vdyB0 aGUgZW50aXR5IHBsYWNpbmcgdGhlIEZyb20uIElzbid0IHRoaXMgbm90IGFsc28gYSBraW5kIG9m IHRydXN0IHJlbGF0aW9uc2hpcD8gDQoNCkJlc3QgUmVnYXJkcw0KDQpSb2xhbmQNCg0KDQotLS0t LVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IHN0aXIgW21haWx0bzpzdGlyLWJv dW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIEJyaWFuIFJvc2VuDQpHZXNlbmRldDogTW9u dGFnLCAyMC4gSnVsaSAyMDE1IDEwOjI1DQpBbjogRE9MTFksIE1BUlRJTiBDDQpDYzogc3RpckBp ZXRmLm9yZzsgSm9uIFBldGVyc29uDQpCZXRyZWZmOiBSZTogW3N0aXJdIEFub255bW91cyBDYWxs aW5nDQoNCldobyBpcyBzaWduaW5nLCBhbmQgd2hhdCBhcmUgdGhleSBhdHRlc3Rpbmc/DQoNCnN0 aXIgaXMgc3VwcG9zZWQgdG8gYmUgYWJvdXQgbWFraW5nIHN1cmUgdGhhdCB0aGUgaWRlbnRpZmll ciBpbiB0aGUgRnJvbSBpcyBkZWxlZ2F0ZWQgdG8gdGhlIGVudGl0eSBwbGFjaW5nIHRoZSBjYWxs LiAgSXQgaXMgbm90IOKAnHRoaXMgaXMgYSBjYWxsIGZyb20gYSB0cnVzdGVkIHBhcnR5Ig0KDQpU aGF0IHdvdWxkIHByZWNsdWRlIGFueW9uZSBzaWduaW5nIGEgY2FsbCBmcm9tIGFub255bW91cy5p bnZhbGlkIGJlY2F1c2UgdGhlcmUgaXMgbm8gZGVsZWdhdGlvbiB0byBhbm9ueW1vdXMuaW52YWxp ZA0KDQpCcmlhbg0KDQoNCj4gT24gSnVsIDIwLCAyMDE1LCBhdCAxMDoxMyBBTSwgRE9MTFksIE1B UlRJTiBDIDxtZDMxMzVAYXR0LmNvbT4gd3JvdGU6DQo+IA0KPiBUaGVyZSBhcmUgY2FzZXMgd2hl cmUgYW5vbnltb3VzIHNob3VsZCBiZSBzaWduZWQNCj4gDQo+IFNlbnQgZnJvbSBteSBpUGhvbmUN Cj4gDQo+PiBPbiBKdWwgMjAsIDIwMTUsIGF0IDQ6MDcgQU0sIFBldGVyc29uLCBKb24gPGpvbi5w ZXRlcnNvbkBuZXVzdGFyLmJpej4gd3JvdGU6DQo+PiANCj4+IA0KPj4gQWN0dWFsbHksIHRoZSBj ZXJ0aWZpY2F0ZXMgZHJhZnQgZG9lc24ndCB0YWxrIGFib3V0IGFub255bWl0eSBhdCBhbGwuIEkg YXNzdW1lIHlvdSBtZWFuIHJmYzQ0NzRiaXMuIA0KPj4gDQo+PiBUaGUgdGV4dCBpbiBTZWN0aW9u IDkgKDJuZCBhbmQgM3JkIHBhcmFncmFwaCkgdGhhdCBzZWVtcyB0byBiZSBjb25mdXNpbmcgeW91 IGhlcmUgdGFsa3MgYWJvdXQgYm90aCB0aGUgcmVjb21tZW5kYXRpb25zIGluIFJGQzMzMjMgYW5k IFJGQzMyNjEuIElmIHlvdSBhcmUgdXNpbmcgYW4gUkZDMzMyMyBhbm9ueW1pemF0aW9uIHNlcnZp Y2UsIHlvdSB3aWxsIGhhdmUgYSBVUkkgd2l0aCBhIHZhbGlkIGhvc3QgcG9ydGlvbiAod2hpY2gg Y291bGQgdGhlb3JldGljYWxseSBiZSBzaWduZWQpLiBJZiB5b3UgYXJlIHVzaW5nIGFub255bW91 cy5pbnZhbGlkIGFzIGEgaG9zdCwgYXMgUkZDMzI2MSB1c2VkLCB0aGVuIG9idmlvdXNseSBubyBz ZXJ2aWNlIGNhbiBvciBzaG91bGQgc2lnbiBpdC4gQnV0IHJmYzQ0NzRiaXMgaW4gbm8gd2F5IGVu ZG9yc2VzIG9uZSBhcHByb2FjaCBvciB0aGUgb3RoZXIsIG9yIGluIHNvbWUgb3RoZXIgd2F5IHZl ZXJzIGludG8gdGhpcyBuZWJ1bG91cyByZWFsbSBvZiAicG9saWN5LiIgSXQgbWVyZWx5IGV4cGxh aW5zIGhvdyB0aGUgc2lnbmF0dXJlIG1lY2hhbmlzbSB3b3VsZCBpbnRlcmFjdCB3aXRoIGVpdGhl ciBvZiB0aGlzIGNob2ljZXMuIA0KPj4gDQo+PiBSZXJlYWRpbmcgdGhhdCB0ZXh0LCBJIGRvbid0 IHRoaW5rIHRoZXJlIGFueSBuZWVkIHRvIG1ha2UgdGhhdCBjbGVhcmVyLiANCj4+IA0KPj4gSm9u IFBldGVyc29uDQo+PiBOZXVzdGFyLCBJbmMsDQo+PiANCj4+IFNlbnQgZnJvbSBteSBpUGFkDQo+ PiANCj4+PiBPbiBKdWwgMjAsIDIwMTUsIGF0IDI6MzkgQU0sIEVyaWMgQnVyZ2VyIDxlYnVyZ2Vy QHN0YW5kYXJkc3RyYWNrLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gVGhlIGNlcnRpZmljYXRlcyBk cmFmdCBwb2ludHMgb3V0IHRoYXQgb25lIGNhbm5vdCBkbyBhIHJvb3RlZCBzaWduYXR1cmUgb3Zl ciDigJxhbm9ueW1vdXMuaW52YWxpZOKAnS4gVGhhdCBpcyB0aGUgc3VnZ2VzdGVkIGRvbWFpbiBm b3IgYW5vbnltb3VzIGNhbGxzIHBlciBSRkMgMzI2MS4gVGhhdCBpcyBuaWNlLCBhbmQgb25lIGNv dWxkIGFyZ3VlIHRoYXQgNDQ3NGJpcyBkb2VzIG5vdCBlbGltaW5hdGUgYW5vbnltb3VzIGNhbGxp bmcuIEhvd2V2ZXIsIDQ0NzRiaXMgZ2V0cyBpbnRvIHRoZSBwb2xpY3kgd29ybGQgYnkgc3RhdGlu ZyBmaXJzdCBvZiBhbGwgdGhlIHNlcnZpY2UgcHJvdmlkZXIgc2hvdWxkIHNpZ24sIHN0YXRpbmcg c29tZXRoaW5nIGxpa2Ug4oCcYW5vbnltb3VzQGV4YW1wbGUubmV04oCdLiBIb3dldmVyLCB0aGF0 IGFscmVhZHkgbGVha3Mgd2hhdCBjb3VsZCBiZSBzaWduaWZpY2FudGx5IHJldmVhbGluZyBpbmZv cm1hdGlvbiAodGhpbmsgb2Yg4oCcZmJpLmdvduKAnSkuDQo+Pj4gDQo+Pj4gVGhlIGRyYWZ0IGlz IGNsb3NlLiBJIHdvdWxkIG9mZmVyIHRoZSBkcmFmdCBpcyBtb3JlIGV4cGxpY2l0IGluIFNlY3Rp b24gNC4yIHRvIHN0YXRlIHRoYXQgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCBVQVMgYmVoYXZpb3Ig aXMgdG8gbm90IHJlamVjdCB1bnNpZ25lZCByZXF1ZXN0cyBpZiB0aGUgcmVxdWVzdCBoYXMgYW4g b2J2aW91c2x5IGFub255bW91cyBGcm9tIGhlYWRlci4NCj4+PiANCj4+PiBGb3IgaW50ZXJvcGVy YWJpbGl0eSwgaXQgd291bGQgYmUgZ29vZCB0byB1cGRhdGUgMzI2MSB0byBtYW5kYXRlIOKAnGFu b255bW91c0Bhbm9ueW1vdXMuaW52YWxpZOKAnSAoSSBhbSBub3QgdGllZCB0byB0aGUgc3RyaW5n LCBzbyBsb25nIGFzIGl0IGlzIG9uZSBhbmQgb25seSBvbmUgc3RyaW5nKSB0byBpbmRpY2F0ZSBh IHVuaXZlcnNhbGx5IGFub255bW91cyBpZGVudGl0eS4gVGhpcyBpcyBhcyBvcHBvc2VkIHRvIGFu b255bW91c0BleGFtcGxlLm5ldCwgd2hpY2ggd291bGQgYWx3YXlzIHdvcmsgYmVjYXVzZSBpdCBp cyBqdXN0IGEgdXNlci4gQW55d2F5LCBpdCBsZWF2ZXMgYW5vbnltb3VzQGxpemFyZHNxdWFkLnh4 eCBhdmFpbGFibGUsIHdoaWNoIG1pZ2h0IGJlIGEgcmVhbCB1c2VyIG9yIGdyb3VwIG9mIHVzZXJz Lg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+PiBzdGlyQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo+PiANCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzdGlyIG1haWxpbmcgbGlzdA0KPj4g c3RpckBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z dGlyDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHN0aXIgbWFpbGluZyBsaXN0DQo+IHN0aXJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzdGlyIG1haWxpbmcgbGlzdA0Kc3RpckBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo= From nobody Mon Jul 20 02:14:09 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02DB1A014C for ; Mon, 20 Jul 2015 02:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 Urt3WljvZYIn for ; Mon, 20 Jul 2015 02:14:04 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (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 1BCB81A0123 for ; Mon, 20 Jul 2015 02:14:03 -0700 (PDT) Received: by wgkl9 with SMTP id l9so125289164wgk.1 for ; Mon, 20 Jul 2015 02:14:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9Xkageph4rNr4HjHKSR3R7QX2WvTJdUGEFBGEVXhVMA=; b=FyaLXTlflPLFl3FvZqZaIl8UIz2sP72e8P60y6DqlebVNJWG5C3X03dDSkC2wY3PRw Uz3j25719zxAwf2+kx53sMT6Ftvhyar6ak87Fq0K3tbNQXoXcCa8NHvXLdVUNK+oUdmd KbdeHouYEE0NIhUWNy7yT4Ua0t0URsG2zkXxC45ecyvlPUy4+NOBOR2u5XK8NrCnyTZh XQRTmcDdOT+NBPHFWosWmF3hRyGf6daKNz0StNduOOOuraoYDw3/ASCcN2uxG+04F16m JLHEKwl9yggo99xKVxZIbBNLehcyJVzOCKIspDIBhANZgeoPxn3Y1zloWmc/LfcE9YHM X47A== X-Gm-Message-State: ALoCoQmA3oliIWeFKLyXJdwIUEoy2RZh+iCGuSursRWG2cuZ3oMe9cm2hGsoeE0jgG2SBRQUflig X-Received: by 10.180.23.33 with SMTP id j1mr18921037wif.44.1437383641850; Mon, 20 Jul 2015 02:14:01 -0700 (PDT) Received: from dhcp-b0a6.meeting.ietf.org (dhcp-b0a6.meeting.ietf.org. [31.133.176.166]) by smtp.gmail.com with ESMTPSA id gb16sm10834848wic.5.2015.07.20.02.13.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Jul 2015 02:14:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Brian Rosen In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01EF89806D8E@HE113667.emea1.cds.t-internal.com> Date: Mon, 20 Jul 2015 11:13:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> <058CE00BD4D6B94FAD033A2439EA1E4B01EF89806D8E@HE113667.emea1.cds.t-internal.com> To: R.Jesske@telekom.de X-Mailer: Apple Mail (2.2102) Archived-At: Cc: stir@ietf.org, md3135@att.com, Jon Peterson Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 09:14:07 -0000 It might be, but it=E2=80=99s not the trust relationship stir discusses. If there is a domain delegated to the sender, and it can sign, then it = works. Any privacy service could do this, for example. 3323 shows a = few other cases. But not from anonymous.invalid, no one has that delegated to them. Brian > On Jul 20, 2015, at 11:05 AM, = wrote: >=20 > Hi, > I do not understand the difference. >=20 > If you know the entity placing the From. Isn't this not also a kind of = trust relationship?=20 >=20 > Best Regards >=20 > Roland >=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: stir [mailto:stir-bounces@ietf.org] Im Auftrag von Brian Rosen > Gesendet: Montag, 20. Juli 2015 10:25 > An: DOLLY, MARTIN C > Cc: stir@ietf.org; Jon Peterson > Betreff: Re: [stir] Anonymous Calling >=20 > Who is signing, and what are they attesting? >=20 > stir is supposed to be about making sure that the identifier in the = =46rom is delegated to the entity placing the call. It is not =E2=80=9Cth= is is a call from a trusted party" >=20 > That would preclude anyone signing a call from anonymous.invalid = because there is no delegation to anonymous.invalid >=20 > Brian >=20 >=20 >> On Jul 20, 2015, at 10:13 AM, DOLLY, MARTIN C wrote: >>=20 >> There are cases where anonymous should be signed >>=20 >> Sent from my iPhone >>=20 >>> On Jul 20, 2015, at 4:07 AM, Peterson, Jon = wrote: >>>=20 >>>=20 >>> Actually, the certificates draft doesn't talk about anonymity at = all. I assume you mean rfc4474bis.=20 >>>=20 >>> The text in Section 9 (2nd and 3rd paragraph) that seems to be = confusing you here talks about both the recommendations in RFC3323 and = RFC3261. If you are using an RFC3323 anonymization service, you will = have a URI with a valid host portion (which could theoretically be = signed). If you are using anonymous.invalid as a host, as RFC3261 used, = then obviously no service can or should sign it. But rfc4474bis in no = way endorses one approach or the other, or in some other way veers into = this nebulous realm of "policy." It merely explains how the signature = mechanism would interact with either of this choices.=20 >>>=20 >>> Rereading that text, I don't think there any need to make that = clearer.=20 >>>=20 >>> Jon Peterson >>> Neustar, Inc, >>>=20 >>> Sent from my iPad >>>=20 >>>> On Jul 20, 2015, at 2:39 AM, Eric Burger = wrote: >>>>=20 >>>> The certificates draft points out that one cannot do a rooted = signature over =E2=80=9Canonymous.invalid=E2=80=9D. That is the = suggested domain for anonymous calls per RFC 3261. That is nice, and one = could argue that 4474bis does not eliminate anonymous calling. However, = 4474bis gets into the policy world by stating first of all the service = provider should sign, stating something like = =E2=80=9Canonymous@example.net=E2=80=9D. However, that already leaks = what could be significantly revealing information (think of = =E2=80=9Cfbi.gov=E2=80=9D). >>>>=20 >>>> The draft is close. I would offer the draft is more explicit in = Section 4.2 to state that it is recommended that UAS behavior is to not = reject unsigned requests if the request has an obviously anonymous =46rom = header. >>>>=20 >>>> For interoperability, it would be good to update 3261 to mandate = =E2=80=9Canonymous@anonymous.invalid=E2=80=9D (I am not tied to the = string, so long as it is one and only one string) to indicate a = universally anonymous identity. This is as opposed to = anonymous@example.net, which would always work because it is just a = user. Anyway, it leaves anonymous@lizardsquad.xxx available, which might = be a real user or group of users. >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 From nobody Mon Jul 20 02:21:32 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8711A1AB6 for ; Mon, 20 Jul 2015 02:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PUNgfV0Ngb2Y for ; Mon, 20 Jul 2015 02:21:28 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B291A1ABE for ; Mon, 20 Jul 2015 02:20:44 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id c6dbca55.2b77c9e22940.5822944.00-2457.16437111.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 20 Jul 2015 09:20:44 +0000 (UTC) X-MXL-Hash: 55acbd6c711e4d67-4b10e5b32dc55975020413519a40a1117804b1ae Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id a6dbca55.0.5822940.00-2230.16437094.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 20 Jul 2015 09:20:44 +0000 (UTC) X-MXL-Hash: 55acbd6c28453084-924b911e9383ce5592b0ee3cbe63d0ec2bd8999d 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 t6K9KgBO016234; Mon, 20 Jul 2015 05:20:42 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6K9KW88016150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jul 2015 05:20:35 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 20 Jul 2015 09:20:26 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.130]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0224.002; Mon, 20 Jul 2015 05:20:26 -0400 From: "DOLLY, MARTIN C" To: Brian Rosen , "R.Jesske@telekom.de" Thread-Topic: [stir] Anonymous Calling Thread-Index: AQHQwoSCsKCgN2TvS0SKjO0sK+vacJ3kRDKAgAABt4CAAAMhgIAAC0sAgAACfwD//76h8A== Date: Mon, 20 Jul 2015 09:20:26 +0000 Message-ID: References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> <058CE00BD4D6B94FAD033A2439EA1E4B01EF89806D8E@HE113667.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.125.196] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=IsOphsDg c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=r4kQLkroO3wA:10 a=zOBTX] X-AnalysisOut: [jUuO1YA:10 a=HLLxP2VMAAAA:8 a=48vgC7mUAAAA:8 a=hGBaWAWWAAA] X-AnalysisOut: [A:8 a=bfLuiRfvAAAA:8 a=OK-8mIdLAAAA:8 a=hZllq1VyqgFO-F9uQ9] X-AnalysisOut: [oA:9 a=QEXdDO2ut3YA:10 a=DrN0Ynp0MyGNt-Wd:21 a=CP-dwnbeVP4] X-AnalysisOut: [J7wGK:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "stir@ietf.org" , Jon Peterson Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 09:21:30 -0000 VGhlbiBtYXkgYmUgU1RJUiBpcyBicm9rZW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXRdIA0KU2VudDogTW9u ZGF5LCBKdWx5IDIwLCAyMDE1IDU6MTQgQU0NClRvOiBSLkplc3NrZUB0ZWxla29tLmRlDQpDYzog RE9MTFksIE1BUlRJTiBDOyBzdGlyQGlldGYub3JnOyBKb24gUGV0ZXJzb24NClN1YmplY3Q6IFJl OiBbc3Rpcl0gQW5vbnltb3VzIENhbGxpbmcNCg0KSXQgbWlnaHQgYmUsIGJ1dCBpdOKAmXMgbm90 IHRoZSB0cnVzdCByZWxhdGlvbnNoaXAgc3RpciBkaXNjdXNzZXMuDQoNCklmIHRoZXJlIGlzIGEg ZG9tYWluIGRlbGVnYXRlZCB0byB0aGUgc2VuZGVyLCBhbmQgaXQgY2FuIHNpZ24sIHRoZW4gaXQg d29ya3MuICBBbnkgcHJpdmFjeSBzZXJ2aWNlIGNvdWxkIGRvIHRoaXMsIGZvciBleGFtcGxlLiAg MzMyMyBzaG93cyBhIGZldyBvdGhlciBjYXNlcy4NCg0KQnV0IG5vdCBmcm9tIGFub255bW91cy5p bnZhbGlkLCBubyBvbmUgaGFzIHRoYXQgZGVsZWdhdGVkIHRvIHRoZW0uDQoNCkJyaWFuDQoNCj4g T24gSnVsIDIwLCAyMDE1LCBhdCAxMTowNSBBTSwgPFIuSmVzc2tlQHRlbGVrb20uZGU+IDxSLkpl c3NrZUB0ZWxla29tLmRlPiB3cm90ZToNCj4gDQo+IEhpLA0KPiBJIGRvIG5vdCB1bmRlcnN0YW5k IHRoZSBkaWZmZXJlbmNlLg0KPiANCj4gSWYgeW91IGtub3cgdGhlIGVudGl0eSBwbGFjaW5nIHRo ZSBGcm9tLiBJc24ndCB0aGlzIG5vdCBhbHNvIGEga2luZCBvZiB0cnVzdCByZWxhdGlvbnNoaXA/ IA0KPiANCj4gQmVzdCBSZWdhcmRzDQo+IA0KPiBSb2xhbmQNCj4gDQo+IA0KPiAtLS0tLVVyc3By w7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogc3RpciBbbWFpbHRvOnN0aXItYm91bmNl c0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gQnJpYW4gUm9zZW4NCj4gR2VzZW5kZXQ6IE1vbnRh ZywgMjAuIEp1bGkgMjAxNSAxMDoyNQ0KPiBBbjogRE9MTFksIE1BUlRJTiBDDQo+IENjOiBzdGly QGlldGYub3JnOyBKb24gUGV0ZXJzb24NCj4gQmV0cmVmZjogUmU6IFtzdGlyXSBBbm9ueW1vdXMg Q2FsbGluZw0KPiANCj4gV2hvIGlzIHNpZ25pbmcsIGFuZCB3aGF0IGFyZSB0aGV5IGF0dGVzdGlu Zz8NCj4gDQo+IHN0aXIgaXMgc3VwcG9zZWQgdG8gYmUgYWJvdXQgbWFraW5nIHN1cmUgdGhhdCB0 aGUgaWRlbnRpZmllciBpbiB0aGUgRnJvbSBpcyBkZWxlZ2F0ZWQgdG8gdGhlIGVudGl0eSBwbGFj aW5nIHRoZSBjYWxsLiAgSXQgaXMgbm90IOKAnHRoaXMgaXMgYSBjYWxsIGZyb20gYSB0cnVzdGVk IHBhcnR5Ig0KPiANCj4gVGhhdCB3b3VsZCBwcmVjbHVkZSBhbnlvbmUgc2lnbmluZyBhIGNhbGwg ZnJvbSBhbm9ueW1vdXMuaW52YWxpZCBiZWNhdXNlIHRoZXJlIGlzIG5vIGRlbGVnYXRpb24gdG8g YW5vbnltb3VzLmludmFsaWQNCj4gDQo+IEJyaWFuDQo+IA0KPiANCj4+IE9uIEp1bCAyMCwgMjAx NSwgYXQgMTA6MTMgQU0sIERPTExZLCBNQVJUSU4gQyA8bWQzMTM1QGF0dC5jb20+IHdyb3RlOg0K Pj4gDQo+PiBUaGVyZSBhcmUgY2FzZXMgd2hlcmUgYW5vbnltb3VzIHNob3VsZCBiZSBzaWduZWQN Cj4+IA0KPj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPj4gDQo+Pj4gT24gSnVsIDIwLCAyMDE1LCBh dCA0OjA3IEFNLCBQZXRlcnNvbiwgSm9uIDxqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXo+IHdyb3Rl Og0KPj4+IA0KPj4+IA0KPj4+IEFjdHVhbGx5LCB0aGUgY2VydGlmaWNhdGVzIGRyYWZ0IGRvZXNu J3QgdGFsayBhYm91dCBhbm9ueW1pdHkgYXQgYWxsLiBJIGFzc3VtZSB5b3UgbWVhbiByZmM0NDc0 YmlzLiANCj4+PiANCj4+PiBUaGUgdGV4dCBpbiBTZWN0aW9uIDkgKDJuZCBhbmQgM3JkIHBhcmFn cmFwaCkgdGhhdCBzZWVtcyB0byBiZSBjb25mdXNpbmcgeW91IGhlcmUgdGFsa3MgYWJvdXQgYm90 aCB0aGUgcmVjb21tZW5kYXRpb25zIGluIFJGQzMzMjMgYW5kIFJGQzMyNjEuIElmIHlvdSBhcmUg dXNpbmcgYW4gUkZDMzMyMyBhbm9ueW1pemF0aW9uIHNlcnZpY2UsIHlvdSB3aWxsIGhhdmUgYSBV Ukkgd2l0aCBhIHZhbGlkIGhvc3QgcG9ydGlvbiAod2hpY2ggY291bGQgdGhlb3JldGljYWxseSBi ZSBzaWduZWQpLiBJZiB5b3UgYXJlIHVzaW5nIGFub255bW91cy5pbnZhbGlkIGFzIGEgaG9zdCwg YXMgUkZDMzI2MSB1c2VkLCB0aGVuIG9idmlvdXNseSBubyBzZXJ2aWNlIGNhbiBvciBzaG91bGQg c2lnbiBpdC4gQnV0IHJmYzQ0NzRiaXMgaW4gbm8gd2F5IGVuZG9yc2VzIG9uZSBhcHByb2FjaCBv ciB0aGUgb3RoZXIsIG9yIGluIHNvbWUgb3RoZXIgd2F5IHZlZXJzIGludG8gdGhpcyBuZWJ1bG91 cyByZWFsbSBvZiAicG9saWN5LiIgSXQgbWVyZWx5IGV4cGxhaW5zIGhvdyB0aGUgc2lnbmF0dXJl IG1lY2hhbmlzbSB3b3VsZCBpbnRlcmFjdCB3aXRoIGVpdGhlciBvZiB0aGlzIGNob2ljZXMuIA0K Pj4+IA0KPj4+IFJlcmVhZGluZyB0aGF0IHRleHQsIEkgZG9uJ3QgdGhpbmsgdGhlcmUgYW55IG5l ZWQgdG8gbWFrZSB0aGF0IGNsZWFyZXIuIA0KPj4+IA0KPj4+IEpvbiBQZXRlcnNvbg0KPj4+IE5l dXN0YXIsIEluYywNCj4+PiANCj4+PiBTZW50IGZyb20gbXkgaVBhZA0KPj4+IA0KPj4+PiBPbiBK dWwgMjAsIDIwMTUsIGF0IDI6MzkgQU0sIEVyaWMgQnVyZ2VyIDxlYnVyZ2VyQHN0YW5kYXJkc3Ry YWNrLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBUaGUgY2VydGlmaWNhdGVzIGRyYWZ0IHBvaW50 cyBvdXQgdGhhdCBvbmUgY2Fubm90IGRvIGEgcm9vdGVkIHNpZ25hdHVyZSBvdmVyIOKAnGFub255 bW91cy5pbnZhbGlk4oCdLiBUaGF0IGlzIHRoZSBzdWdnZXN0ZWQgZG9tYWluIGZvciBhbm9ueW1v dXMgY2FsbHMgcGVyIFJGQyAzMjYxLiBUaGF0IGlzIG5pY2UsIGFuZCBvbmUgY291bGQgYXJndWUg dGhhdCA0NDc0YmlzIGRvZXMgbm90IGVsaW1pbmF0ZSBhbm9ueW1vdXMgY2FsbGluZy4gSG93ZXZl ciwgNDQ3NGJpcyBnZXRzIGludG8gdGhlIHBvbGljeSB3b3JsZCBieSBzdGF0aW5nIGZpcnN0IG9m IGFsbCB0aGUgc2VydmljZSBwcm92aWRlciBzaG91bGQgc2lnbiwgc3RhdGluZyBzb21ldGhpbmcg bGlrZSDigJxhbm9ueW1vdXNAZXhhbXBsZS5uZXTigJ0uIEhvd2V2ZXIsIHRoYXQgYWxyZWFkeSBs ZWFrcyB3aGF0IGNvdWxkIGJlIHNpZ25pZmljYW50bHkgcmV2ZWFsaW5nIGluZm9ybWF0aW9uICh0 aGluayBvZiDigJxmYmkuZ2924oCdKS4NCj4+Pj4gDQo+Pj4+IFRoZSBkcmFmdCBpcyBjbG9zZS4g SSB3b3VsZCBvZmZlciB0aGUgZHJhZnQgaXMgbW9yZSBleHBsaWNpdCBpbiBTZWN0aW9uIDQuMiB0 byBzdGF0ZSB0aGF0IGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgVUFTIGJlaGF2aW9yIGlzIHRvIG5v dCByZWplY3QgdW5zaWduZWQgcmVxdWVzdHMgaWYgdGhlIHJlcXVlc3QgaGFzIGFuIG9idmlvdXNs eSBhbm9ueW1vdXMgRnJvbSBoZWFkZXIuDQo+Pj4+IA0KPj4+PiBGb3IgaW50ZXJvcGVyYWJpbGl0 eSwgaXQgd291bGQgYmUgZ29vZCB0byB1cGRhdGUgMzI2MSB0byBtYW5kYXRlIOKAnGFub255bW91 c0Bhbm9ueW1vdXMuaW52YWxpZOKAnSAoSSBhbSBub3QgdGllZCB0byB0aGUgc3RyaW5nLCBzbyBs b25nIGFzIGl0IGlzIG9uZSBhbmQgb25seSBvbmUgc3RyaW5nKSB0byBpbmRpY2F0ZSBhIHVuaXZl cnNhbGx5IGFub255bW91cyBpZGVudGl0eS4gVGhpcyBpcyBhcyBvcHBvc2VkIHRvIGFub255bW91 c0BleGFtcGxlLm5ldCwgd2hpY2ggd291bGQgYWx3YXlzIHdvcmsgYmVjYXVzZSBpdCBpcyBqdXN0 IGEgdXNlci4gQW55d2F5LCBpdCBsZWF2ZXMgYW5vbnltb3VzQGxpemFyZHNxdWFkLnh4eCBhdmFp bGFibGUsIHdoaWNoIG1pZ2h0IGJlIGEgcmVhbCB1c2VyIG9yIGdyb3VwIG9mIHVzZXJzLg0KPj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBz dGlyIG1haWxpbmcgbGlzdA0KPj4+PiBzdGlyQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+ PiBzdGlyQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zdGlyDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+IHN0aXJAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc3RpciBtYWlsaW5nIGxpc3QNCj4gc3Rp ckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXIN Cg0K From nobody Mon Jul 20 03:02:59 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289B21A1AC6 for ; Mon, 20 Jul 2015 03:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 OZqvrnHNEk3j for ; Mon, 20 Jul 2015 03:02:57 -0700 (PDT) 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 37A361A1AC2 for ; Mon, 20 Jul 2015 03:02:57 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6KA0REC027864; Mon, 20 Jul 2015 06:02:53 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1vqdxmvdvh-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 06:02:53 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Mon, 20 Jul 2015 06:02:52 -0400 From: "Peterson, Jon" To: "DOLLY, MARTIN C" Thread-Topic: [stir] Anonymous Calling Thread-Index: AQHQwoSDGWiLBfrzXkujhpdlfQ0qT53kASW/gABE0wCAAAMSgIAAC0sAgAACfwCAAAHRAP//yMzB Date: Mon, 20 Jul 2015 10:02:51 +0000 Message-ID: <8687402E-AB51-4FEA-A38C-A03BA916F1A3@neustar.biz> References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> <058CE00BD4D6B94FAD033A2439EA1E4B01EF89806D8E@HE113667.emea1.cds.t-internal.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-20_01:2015-07-20,2015-07-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507200158 Archived-At: Cc: "stir@ietf.org" , "R.Jesske@telekom.de" , Brian Rosen Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 10:02:59 -0000 In baseline SIP, you can either claim an identity, or a pseudonym, or you c= an be anonymous in one of a few ways. STIR doesn't change that, it just exp= lains how it interacts with those modes in SIP. So at worst, STIR is only a= s confused as SIP about all this.=20 Jon Peterson Neustar, Inc. Sent from my iPad > On Jul 20, 2015, at 11:20 AM, DOLLY, MARTIN C wrote: >=20 > Then may be STIR is broken >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, July 20, 2015 5:14 AM > To: R.Jesske@telekom.de > Cc: DOLLY, MARTIN C; stir@ietf.org; Jon Peterson > Subject: Re: [stir] Anonymous Calling >=20 > It might be, but it=92s not the trust relationship stir discusses. >=20 > If there is a domain delegated to the sender, and it can sign, then it wo= rks. Any privacy service could do this, for example. 3323 shows a few oth= er cases. >=20 > But not from anonymous.invalid, no one has that delegated to them. >=20 > Brian >=20 >> On Jul 20, 2015, at 11:05 AM, wrote: >>=20 >> Hi, >> I do not understand the difference. >>=20 >> If you know the entity placing the From. Isn't this not also a kind of t= rust relationship?=20 >>=20 >> Best Regards >>=20 >> Roland >>=20 >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: stir [mailto:stir-bounces@ietf.org] Im Auftrag von Brian Rosen >> Gesendet: Montag, 20. Juli 2015 10:25 >> An: DOLLY, MARTIN C >> Cc: stir@ietf.org; Jon Peterson >> Betreff: Re: [stir] Anonymous Calling >>=20 >> Who is signing, and what are they attesting? >>=20 >> stir is supposed to be about making sure that the identifier in the From= is delegated to the entity placing the call. It is not =93this is a call = from a trusted party" >>=20 >> That would preclude anyone signing a call from anonymous.invalid because= there is no delegation to anonymous.invalid >>=20 >> Brian >>=20 >>=20 >>> On Jul 20, 2015, at 10:13 AM, DOLLY, MARTIN C wrote: >>>=20 >>> There are cases where anonymous should be signed >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Jul 20, 2015, at 4:07 AM, Peterson, Jon = wrote: >>>>=20 >>>>=20 >>>> Actually, the certificates draft doesn't talk about anonymity at all. = I assume you mean rfc4474bis.=20 >>>>=20 >>>> The text in Section 9 (2nd and 3rd paragraph) that seems to be confusi= ng you here talks about both the recommendations in RFC3323 and RFC3261. If= you are using an RFC3323 anonymization service, you will have a URI with a= valid host portion (which could theoretically be signed). If you are using= anonymous.invalid as a host, as RFC3261 used, then obviously no service ca= n or should sign it. But rfc4474bis in no way endorses one approach or the = other, or in some other way veers into this nebulous realm of "policy." It = merely explains how the signature mechanism would interact with either of t= his choices.=20 >>>>=20 >>>> Rereading that text, I don't think there any need to make that clearer= .=20 >>>>=20 >>>> Jon Peterson >>>> Neustar, Inc, >>>>=20 >>>> Sent from my iPad >>>>=20 >>>>> On Jul 20, 2015, at 2:39 AM, Eric Burger = wrote: >>>>>=20 >>>>> The certificates draft points out that one cannot do a rooted signatu= re over =93anonymous.invalid=94. That is the suggested domain for anonymous= calls per RFC 3261. That is nice, and one could argue that 4474bis does no= t eliminate anonymous calling. However, 4474bis gets into the policy world = by stating first of all the service provider should sign, stating something= like =93anonymous@example.net=94. However, that already leaks what could b= e significantly revealing information (think of =93fbi.gov=94). >>>>>=20 >>>>> The draft is close. I would offer the draft is more explicit in Secti= on 4.2 to state that it is recommended that UAS behavior is to not reject u= nsigned requests if the request has an obviously anonymous From header. >>>>>=20 >>>>> For interoperability, it would be good to update 3261 to mandate =93a= nonymous@anonymous.invalid=94 (I am not tied to the string, so long as it i= s one and only one string) to indicate a universally anonymous identity. Th= is is as opposed to anonymous@example.net, which would always work because = it is just a user. Anyway, it leaves anonymous@lizardsquad.xxx available, w= hich might be a real user or group of users. >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 Mon Jul 20 03:27:10 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656461A1B78 for ; Mon, 20 Jul 2015 03:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 MyB-xsBxkKWN for ; Mon, 20 Jul 2015 03:27:06 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A211A1B2A for ; Mon, 20 Jul 2015 03:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=4VlpISNob8pbfRcDDqdLtEiq3zrx7hFnvrgxsxAd/DE=; b=szGO7mRUz6d5/h9sPLSjIb9Q8a9k3oE/LlCykjqXNtwPubJjRYmzM1tsvTjSVXHyV6vwjZf18VW4mAs1srTNXyoNDqayxauTy90DWZdkbw0ldFlWN1Wr0AWeP3ZCx5myM5N5R6TGOLuueqgaQdLL3/tMyooWwbf9rhoC2dO7OOU=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:60826 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZH8FJ-0006fs-Qd for stir@ietf.org; Mon, 20 Jul 2015 03:24:31 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_6610CF07-05CB-4A3A-B9D6-6CA635E91B8C"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Pgp-Agent: GPGMail 2.5 From: Eric Burger In-Reply-To: <811BF5D7-A284-4C62-83E5-F56ABC70EF4D@neustar.biz> Date: Mon, 20 Jul 2015 06:24:27 -0400 Message-Id: <32BC5314-4404-4C73-92F5-448DD0BF4F65@standardstrack.com> References: <27F6ABA7-E475-4EB9-9FEE-93539D78EC8B@standardstrack.com> <811BF5D7-A284-4C62-83E5-F56ABC70EF4D@neustar.biz> To: "stir@ietf.org" X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [stir] MIME (Certs draft) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 10:27:10 -0000 --Apple-Mail=_6610CF07-05CB-4A3A-B9D6-6CA635E91B8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I can buy the argument. Sounds like an opportunity to add to the open = source resources. > On Jul 20, 2015, at 3:49 AM, Peterson, Jon = wrote: >=20 > Moreover, the certs draft does not say "don't use MIME." It says that = multipart/MIME is one way to convey certificates, but that it has known = problems (as Henning observes) and that there are other ways. Suggesting = that the certs draft discourages that SIP implementations from using = MIME or what have you is just bizarre. The certs draft actually allows = MIME as a transport for certs. >=20 > Jon Peterson > Neustar, Inc, >=20 > Sent from my iPad >=20 >> On Jul 20, 2015, at 9:38 AM, Henning Schulzrinne = wrote: >>=20 >> Eric, >>=20 >> MIME has been a huge implementation hurdle in practice, for two = reasons: >>=20 >> (1) Many UAs use standard SIP libraries and don't touch the actual = SIP header (or body). It's a lot easier to add external header = processing in that case since this can be layered on top, without = mucking with the SIP library. This is also true for server-based = libraries (JAIN SIP, SIP servlets, e.g., in Mobicents). >>=20 >> (2) Many UAs and SBCs choke on multipart. This makes people reluctant = to deploy new things since even entities that don't need or want to use = the new feature need to be upgraded or they break things. >>=20 >> I've seen multiple instances of this, e.g., in the VRS context. >>=20 >> Since we want to get 4474bis deployed incrementally and with = dispatch, this would argue for having a "we really can't do this any = other way" justification for using multi-part. >>=20 >> Henning >>=20 >> ________________________________________ >> From: stir on behalf of Eric Burger = >> Sent: Sunday, July 19, 2015 8:38 PM >> To: stir@ietf.org >> Subject: [stir] MIME (Certs draft) >>=20 >> Hello! We are specifying new SIP UA behavior. If we are specifying = new SIP UA behavior, it means that developers will be changing the = behavior (a.k.a. code) of conforming SIP UA=92s. Stating that we do not = want to use MIME in the Certificates draft (p. 5) is kind of silly. If = we are telling someone to write a whole bunch of code to do remote = resolution of URI=92s, enter into possibly multiple SUBSCRIBE/NOTIFY = dialogs, and (finally!) implement X.509 certificates, I think we can = mandate MIME support. >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_6610CF07-05CB-4A3A-B9D6-6CA635E91B8C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrMxcAAoJEORoZaSQsc1IHEsP+QGdXXxThFQYRiUnhE94FjIw k73sKPZzn8sbqH1IrzTBnf3h5yQhLoc0JdwUu6HWEw5+XekE3CT+9d7B0BCWsFdo bG3AMiQF24GOpScS/8rZ14O9PpfR7O/fWWg1eTUCvlJI2tm1hmYrBFV0lMC3tibw iN7dtZonYQ4spkLXkaawc/do1V/AoYSw30z/iaL1eSQfMumxdorUZFdW/VZS1vVG 3OvYMd6HYegcTUiBhX1o98UO715G0c5/NJ0uffpdQ1ezq8/ycFdxjWjJo3xhUSvp 9BfUL1/TxaPzQaOPGfo/4kPb62HzmU5x3lw83wVl4PyMlStjVwm9SKEPX2Bm2Nxd ZWCCYesArYFvlKbOgs2YS9ewboFHKhqDvbgXnVbshQ96Ad1Jpba+6cQ0ZqDdeb1s DdigTqTWQ4nb0x92hM8cOnw8BPVLsXupuH/tLiNubfOBaXGbIrak9soGC++Hc85q eeAeCAsv3fqXoz7GZelMDMnDsENeY0YUeRXbI6bcM5qVEOuTge2AkflM3992Sx7B WIaf0Wt65XxKtXP7y5pYurPnhEGMft1RBXThrmWxRWp/U6Ujcl5Pzr8YdFhpqI5W tGcDKADjd+xS3Z9+jMYa1l9RMNGeMncFZFGnL1O0ZmAUGUCWwoq8PbButOOrG1+3 gWiI5bxnMXIonQ+wFYYN =a+BR -----END PGP SIGNATURE----- --Apple-Mail=_6610CF07-05CB-4A3A-B9D6-6CA635E91B8C-- From nobody Mon Jul 20 03:37:54 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44341A1B8C for ; Mon, 20 Jul 2015 03:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 wGHtoZDh8Km4 for ; Mon, 20 Jul 2015 03:37:50 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF34C1A1B92 for ; Mon, 20 Jul 2015 03:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=UplH75jUVDgpHOY4WpS0ZYehNWiBCsMo5hAZszJWgF8=; b=q07log8ZWAgjz0bY9QJtF45IdhVwuEsBuZal0TAQ9L5qdcIGyeRiezEfU5d3tQPSdvMzY2iN4WHPo0LZPTYFM+gYRP7/NmD+lBUf+Ejpkb4nwddgukioRPFI1HogUYCpi4Wp17HFBILcMB6n7qaDHJTl+IlgvhrZb8BzPPf6ksg=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:60926 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZH8Lg-0001JP-Ey for stir@ietf.org; Mon, 20 Jul 2015 03:31:07 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_53FBB92A-2BDA-46B7-A762-E682875B6AF0"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Pgp-Agent: GPGMail 2.5 From: Eric Burger In-Reply-To: <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> Date: Mon, 20 Jul 2015 06:31:03 -0400 Message-Id: <5836D3BF-CE59-470F-845A-E03A35E689E2@standardstrack.com> References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> To: "stir@ietf.org" X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 10:37:53 -0000 --Apple-Mail=_53FBB92A-2BDA-46B7-A762-E682875B6AF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Brian: there is no need for anyone to say, =E2=80=9CThis is = *really* an anonymous call.=E2=80=9D I do not think anyone will be upset = if their Caller ID displays =E2=80=9CI think this is Anonymous=E2=80=9D = instead of =E2=80=9CThis is Really Anonymous=E2=80=9D. Unless of course = it is Anonymous calling, in which case that is a CNAM issue, not a STIR = issue. No one who wants to lie about their identity is going to =E2=80=98forge=E2= =80=99 Anonymous. This is one of those times when public policy does the = right thing. We say we value letting people make anonymous calls. = That=E2=80=99s *67 in the U.S. There is no need for anyone to attest the = =E2=80=98identity=E2=80=99 in this case. Moreover, signing Anonymous leaks the service provider (geography) or = enterprise (which makes extracting identity even easier). > On Jul 20, 2015, at 4:24 AM, Brian Rosen wrote: >=20 > Who is signing, and what are they attesting? >=20 > stir is supposed to be about making sure that the identifier in the = =46rom is delegated to the entity placing the call. It is not =E2=80=9Cth= is is a call from a trusted party" >=20 > That would preclude anyone signing a call from anonymous.invalid = because there is no delegation to anonymous.invalid >=20 > Brian >=20 >=20 >> On Jul 20, 2015, at 10:13 AM, DOLLY, MARTIN C wrote: >>=20 >> There are cases where anonymous should be signed >>=20 >> Sent from my iPhone >>=20 >>> On Jul 20, 2015, at 4:07 AM, Peterson, Jon = wrote: >>>=20 >>>=20 >>> Actually, the certificates draft doesn't talk about anonymity at = all. I assume you mean rfc4474bis. >>>=20 >>> The text in Section 9 (2nd and 3rd paragraph) that seems to be = confusing you here talks about both the recommendations in RFC3323 and = RFC3261. If you are using an RFC3323 anonymization service, you will = have a URI with a valid host portion (which could theoretically be = signed). If you are using anonymous.invalid as a host, as RFC3261 used, = then obviously no service can or should sign it. But rfc4474bis in no = way endorses one approach or the other, or in some other way veers into = this nebulous realm of "policy." It merely explains how the signature = mechanism would interact with either of this choices. >>>=20 >>> Rereading that text, I don't think there any need to make that = clearer. >>>=20 >>> Jon Peterson >>> Neustar, Inc, >>>=20 >>> Sent from my iPad >>>=20 >>>> On Jul 20, 2015, at 2:39 AM, Eric Burger = wrote: >>>>=20 >>>> The certificates draft points out that one cannot do a rooted = signature over =E2=80=9Canonymous.invalid=E2=80=9D. That is the = suggested domain for anonymous calls per RFC 3261. That is nice, and one = could argue that 4474bis does not eliminate anonymous calling. However, = 4474bis gets into the policy world by stating first of all the service = provider should sign, stating something like = =E2=80=9Canonymous@example.net=E2=80=9D. However, that already leaks = what could be significantly revealing information (think of = =E2=80=9Cfbi.gov=E2=80=9D). >>>>=20 >>>> The draft is close. I would offer the draft is more explicit in = Section 4.2 to state that it is recommended that UAS behavior is to not = reject unsigned requests if the request has an obviously anonymous =46rom = header. >>>>=20 >>>> For interoperability, it would be good to update 3261 to mandate = =E2=80=9Canonymous@anonymous.invalid=E2=80=9D (I am not tied to the = string, so long as it is one and only one string) to indicate a = universally anonymous identity. This is as opposed to = anonymous@example.net, which would always work because it is just a = user. Anyway, it leaves anonymous@lizardsquad.xxx available, which might = be a real user or group of users. >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_53FBB92A-2BDA-46B7-A762-E682875B6AF0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrM3nAAoJEORoZaSQsc1Ila8P/A9Llg/tcTnIz3vur0uPLWCw OXfpI2W9mSzO3mvaig//JIeHGOrRl8ZuodbCnrDWgd7NF4qG6aBsbegDw3eN65Ms gfbx6LcbRwlvfXnSabvhGNn9HzHtaKTNIMQvM7Cl+Z3zKTTrGiDquxF6Ca1QzmTS 3fBHqhmDutdhbD42Emkt/N+6z44g/JKbJitWgu6D7I6YLx1InwdJaI6ZzhdDd+Z8 k08kEYt0Tk4PMblXRe23lmWywTym2fSMFB5l0/x/zdExx6gcMMriE6Cb9Gwod6vB RTWn6rXFRKWMa06w8K8jkDsQvx569ITZEX6/hrBzQJ2YvuIijyzRxWHA3jr0mAXA QWkJ6OQxTsrMXUN7uqADtGtUDT5ZaFUMh2QD+gUePRAO9zjB2A62CGTvh+Yfkn+M DmAxSaGqWUiAEzzbU8cJ3zJ2zH0D8bw6l+VrJ+xH2v66Uxa+oXeOwYiTj05Mcbiv e4tCGQwuX3OTMOd+exYyUlkmZ5PvJkx21yFM+BHMhhqQjmOVuvVKRxuqq14FjoO1 T/o6dJQlqIy8EcmPyjAUL0FcktL1vkMAx/Bxa2uagqeIguPuF1xkHiOgvij4WUMa 3ghEFdYPWYJfCyc//lh3RGycNLKWcfd4hrxCoz2pID9IXR9tNHbGkffDrzyVYKUU Nc0vSo8di/wL8Ka0agAr =66wB -----END PGP SIGNATURE----- --Apple-Mail=_53FBB92A-2BDA-46B7-A762-E682875B6AF0-- From nobody Mon Jul 20 04:04:53 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4951A1BB3 for ; Mon, 20 Jul 2015 04:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 Hf-qjA9peobe for ; Mon, 20 Jul 2015 04:04:50 -0700 (PDT) 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 A9B7B1A1BAA for ; Mon, 20 Jul 2015 04:04:50 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6KB3HVh006699; Mon, 20 Jul 2015 07:04:50 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1vryadr1c1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 07:04:49 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 20 Jul 2015 07:04:49 -0400 From: "Peterson, Jon" To: Eric Burger Thread-Topic: [stir] Anonymous Calling Thread-Index: AQHQwoSDGWiLBfrzXkujhpdlfQ0qT53kASW/gABE0wCAAAMSgIAAI1aA///GYH0= Date: Mon, 20 Jul 2015 11:04:48 +0000 Message-ID: <436B3DEB-88BF-46EF-A3BC-AE0D9DCB7A52@neustar.biz> References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net>, <5836D3BF-CE59-470F-845A-E03A35E689E2@standardstrack.com> In-Reply-To: <5836D3BF-CE59-470F-845A-E03A35E689E2@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-20_01:2015-07-20,2015-07-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507200180 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:04:52 -0000 At the risk of reiterating the overall purpose of a privacy service as defi= ned in RFC3323, let's point out that there are fields other than the From h= eader field that can leak information about a user's location or identity -= Via headers, Contacts, even elements of the SDP. Changing your From header= to anonymous.invalid won't help protect you from those forms of leakage. C= onsequently, users may want to rely on services to provide some protections= . Those services may in turn provide valid pseudonymous domains in the From= header field values they generate. Is there a ton of value in those servic= es signing for those domains? Perhaps not in most cases. Perhaps anonymous@= att.com would have a different significance to verifiers (depending entirel= y on local policy) if it were signed than not. rfc4474 is not passing judgm= ent on these questions - it is just saying that you can sign, as a privacy = service. It's not forcing anyone to do so, or recommending this as superior= to some other option. Jon Peterson Neustar, Inc, Sent from my iPad > On Jul 20, 2015, at 12:38 PM, Eric Burger wr= ote: >=20 > I agree with Brian: there is no need for anyone to say, =93This is *reall= y* an anonymous call.=94 I do not think anyone will be upset if their Calle= r ID displays =93I think this is Anonymous=94 instead of =93This is Really = Anonymous=94. Unless of course it is Anonymous calling, in which case that = is a CNAM issue, not a STIR issue. >=20 > No one who wants to lie about their identity is going to =91forge=92 Anon= ymous. This is one of those times when public policy does the right thing. = We say we value letting people make anonymous calls. That=92s *67 in the U.= S. There is no need for anyone to attest the =91identity=92 in this case. >=20 > Moreover, signing Anonymous leaks the service provider (geography) or ent= erprise (which makes extracting identity even easier). >=20 >> On Jul 20, 2015, at 4:24 AM, Brian Rosen wrote: >>=20 >> Who is signing, and what are they attesting? >>=20 >> stir is supposed to be about making sure that the identifier in the From= is delegated to the entity placing the call. It is not =93this is a call = from a trusted party" >>=20 >> That would preclude anyone signing a call from anonymous.invalid because= there is no delegation to anonymous.invalid >>=20 >> Brian >>=20 >>=20 >>> On Jul 20, 2015, at 10:13 AM, DOLLY, MARTIN C wrote: >>>=20 >>> There are cases where anonymous should be signed >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Jul 20, 2015, at 4:07 AM, Peterson, Jon = wrote: >>>>=20 >>>>=20 >>>> Actually, the certificates draft doesn't talk about anonymity at all. = I assume you mean rfc4474bis. >>>>=20 >>>> The text in Section 9 (2nd and 3rd paragraph) that seems to be confusi= ng you here talks about both the recommendations in RFC3323 and RFC3261. If= you are using an RFC3323 anonymization service, you will have a URI with a= valid host portion (which could theoretically be signed). If you are using= anonymous.invalid as a host, as RFC3261 used, then obviously no service ca= n or should sign it. But rfc4474bis in no way endorses one approach or the = other, or in some other way veers into this nebulous realm of "policy." It = merely explains how the signature mechanism would interact with either of t= his choices. >>>>=20 >>>> Rereading that text, I don't think there any need to make that clearer= . >>>>=20 >>>> Jon Peterson >>>> Neustar, Inc, >>>>=20 >>>> Sent from my iPad >>>>=20 >>>>> On Jul 20, 2015, at 2:39 AM, Eric Burger = wrote: >>>>>=20 >>>>> The certificates draft points out that one cannot do a rooted signatu= re over =93anonymous.invalid=94. That is the suggested domain for anonymous= calls per RFC 3261. That is nice, and one could argue that 4474bis does no= t eliminate anonymous calling. However, 4474bis gets into the policy world = by stating first of all the service provider should sign, stating something= like =93anonymous@example.net=94. However, that already leaks what could b= e significantly revealing information (think of =93fbi.gov=94). >>>>>=20 >>>>> The draft is close. I would offer the draft is more explicit in Secti= on 4.2 to state that it is recommended that UAS behavior is to not reject u= nsigned requests if the request has an obviously anonymous From header. >>>>>=20 >>>>> For interoperability, it would be good to update 3261 to mandate =93a= nonymous@anonymous.invalid=94 (I am not tied to the string, so long as it i= s one and only one string) to indicate a universally anonymous identity. Th= is is as opposed to anonymous@example.net, which would always work because = it is just a user. Anyway, it leaves anonymous@lizardsquad.xxx available, w= hich might be a real user or group of users. >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Jul 20 04:07:56 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEAE1A1BBB for ; Mon, 20 Jul 2015 04:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 RoiAjLngag3H for ; Mon, 20 Jul 2015 04:07:53 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B041A1BB3 for ; Mon, 20 Jul 2015 04:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=QUdzdHjtHZgVvWM3/quxvrbdW9Xqrhv4XbkqfqUvumI=; b=d3ec7lgpsEXcAh7pHdFwVTMNpPyad7eSCVTuJZpFit3eyUV4lHOe9EJPj6UbhyMVfCTr23J0Pwan/0VlYj1a61WwQfIbP+h29CC98ZtU5vGGkM4bvn4iRqfZpDxqaxQQRl2h+Bb4K3S4/PWqwYsq29b/V2JjpEZPsTMWn2j929U=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:61794 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZH8vE-00018l-CD for stir@ietf.org; Mon, 20 Jul 2015 04:07:53 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_D6AFEA0B-BD3C-4EAF-AA4D-5D4B33BA4766"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Pgp-Agent: GPGMail 2.5 From: Eric Burger In-Reply-To: <436B3DEB-88BF-46EF-A3BC-AE0D9DCB7A52@neustar.biz> Date: Mon, 20 Jul 2015 07:07:46 -0400 Message-Id: <329F5CBD-FFEE-4B0F-B53F-CBBCED2E4945@standardstrack.com> References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> <5836D3BF-CE59-470F-845A-E03A35E689E2@standardstrack.com> <436B3DEB-88BF-46EF-A3BC-AE0D9DCB7A52@neustar.biz> To: "stir@ietf.org" X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:07:55 -0000 --Apple-Mail=_D6AFEA0B-BD3C-4EAF-AA4D-5D4B33BA4766 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We are in agreement, and you have a good point here. Unless you have = S/MIME encrypted your SDP (you do do that, don=92t you? :-), an = eavesdropper will notice your SDP happens to have an IP address in = AT&T=92s address range, which might be a hint you are on AT&T=92s = network. Nothing in the draft prohibits signing anonymous@att.com > On Jul 20, 2015, at 7:04 AM, Peterson, Jon = wrote: >=20 >=20 > At the risk of reiterating the overall purpose of a privacy service as = defined in RFC3323, let's point out that there are fields other than the = =46rom header field that can leak information about a user's location or = identity - Via headers, Contacts, even elements of the SDP. Changing = your =46rom header to anonymous.invalid won't help protect you from = those forms of leakage. Consequently, users may want to rely on services = to provide some protections. Those services may in turn provide valid = pseudonymous domains in the =46rom header field values they generate. Is = there a ton of value in those services signing for those domains? = Perhaps not in most cases. Perhaps anonymous@att.com would have a = different significance to verifiers (depending entirely on local policy) = if it were signed than not. rfc4474 is not passing judgment on these = questions - it is just saying that you can sign, as a privacy service. = It's not forcing anyone to do so, or recommending this as superior to = some other option. >=20 > Jon Peterson > Neustar, Inc, >=20 > Sent from my iPad >=20 >> On Jul 20, 2015, at 12:38 PM, Eric Burger = wrote: >>=20 >> I agree with Brian: there is no need for anyone to say, =93This is = *really* an anonymous call.=94 I do not think anyone will be upset if = their Caller ID displays =93I think this is Anonymous=94 instead of = =93This is Really Anonymous=94. Unless of course it is Anonymous = calling, in which case that is a CNAM issue, not a STIR issue. >>=20 >> No one who wants to lie about their identity is going to =91forge=92 = Anonymous. This is one of those times when public policy does the right = thing. We say we value letting people make anonymous calls. That=92s *67 = in the U.S. There is no need for anyone to attest the =91identity=92 in = this case. >>=20 >> Moreover, signing Anonymous leaks the service provider (geography) or = enterprise (which makes extracting identity even easier). >>=20 >>> On Jul 20, 2015, at 4:24 AM, Brian Rosen wrote: >>>=20 >>> Who is signing, and what are they attesting? >>>=20 >>> stir is supposed to be about making sure that the identifier in the = =46rom is delegated to the entity placing the call. It is not =93this = is a call from a trusted party" >>>=20 >>> That would preclude anyone signing a call from anonymous.invalid = because there is no delegation to anonymous.invalid >>>=20 >>> Brian >>>=20 >>>=20 >>>> On Jul 20, 2015, at 10:13 AM, DOLLY, MARTIN C = wrote: >>>>=20 >>>> There are cases where anonymous should be signed >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>> On Jul 20, 2015, at 4:07 AM, Peterson, Jon = wrote: >>>>>=20 >>>>>=20 >>>>> Actually, the certificates draft doesn't talk about anonymity at = all. I assume you mean rfc4474bis. >>>>>=20 >>>>> The text in Section 9 (2nd and 3rd paragraph) that seems to be = confusing you here talks about both the recommendations in RFC3323 and = RFC3261. If you are using an RFC3323 anonymization service, you will = have a URI with a valid host portion (which could theoretically be = signed). If you are using anonymous.invalid as a host, as RFC3261 used, = then obviously no service can or should sign it. But rfc4474bis in no = way endorses one approach or the other, or in some other way veers into = this nebulous realm of "policy." It merely explains how the signature = mechanism would interact with either of this choices. >>>>>=20 >>>>> Rereading that text, I don't think there any need to make that = clearer. >>>>>=20 >>>>> Jon Peterson >>>>> Neustar, Inc, >>>>>=20 >>>>> Sent from my iPad >>>>>=20 >>>>>> On Jul 20, 2015, at 2:39 AM, Eric Burger = wrote: >>>>>>=20 >>>>>> The certificates draft points out that one cannot do a rooted = signature over =93anonymous.invalid=94. That is the suggested domain for = anonymous calls per RFC 3261. That is nice, and one could argue that = 4474bis does not eliminate anonymous calling. However, 4474bis gets into = the policy world by stating first of all the service provider should = sign, stating something like =93anonymous@example.net=94. However, that = already leaks what could be significantly revealing information (think = of =93fbi.gov=94). >>>>>>=20 >>>>>> The draft is close. I would offer the draft is more explicit in = Section 4.2 to state that it is recommended that UAS behavior is to not = reject unsigned requests if the request has an obviously anonymous =46rom = header. >>>>>>=20 >>>>>> For interoperability, it would be good to update 3261 to mandate = =93anonymous@anonymous.invalid=94 (I am not tied to the string, so long = as it is one and only one string) to indicate a universally anonymous = identity. This is as opposed to anonymous@example.net, which would = always work because it is just a user. Anyway, it leaves = anonymous@lizardsquad.xxx available, which might be a real user or group = of users. >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_D6AFEA0B-BD3C-4EAF-AA4D-5D4B33BA4766 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrNaCAAoJEORoZaSQsc1I1vwQAIWSSm1XjxxabQIEIBvyVmVX kJFniJu3LHfJuaSJPuwgzA8RhvyyHRXgi3O5Za2SJmTyQQta2CuJ6Z3Ly0iJvxv2 dyptWTdXlhGS7xNe50F7y9tQYugUJtheNRancWQmQ5rIrDi1JIuWQh98xo6Wu2SM ZD9wfx0bO8TIKWiKI4aKnl9egn+3Fk75MXDOue7MATI7FVAkw39cI/lJUzTJdq2n atygVlyrzKWGb4bSV/wbnoS3xLoR69sbGRTE0Zb8S+/MXXCO4oardX1rRytQbEaw I2KlGn1j8RU0Hj9KDsZs16lsf73M36VMPeEBv9dl6ISe9d9+XDrUW7EcRtCK47Ge Hpp4KLajnAAomvfbSHGRnQgJgQV9IuYksxjfuRXLubsUcNlUWf54fWriyaLh/SYx tJAidBR2AyeHUK3hDXqU7HV3jDPrKrlTJpJgOw5s82uHZrC70k7HmG3fE61WMRKU MefZLp8EsTuJqP0ZGgkEGnzBoXlPTVnUYc0uW5oT78cMjj43md72wTLORJXjebvr dn+X4vqLDmPWfDBTEHfq0li57gu5TSTNKyVJjj26ghBKICyu/aT9hyNGp28iMekT j8/K4Iy/+kl3x6DpwUdP10rMEhhrxua177+FwQhYzOyFKDRVMtCnFoicrgxWr1YC bxv091uEoOyyQgDlkKQS =BfEe -----END PGP SIGNATURE----- --Apple-Mail=_D6AFEA0B-BD3C-4EAF-AA4D-5D4B33BA4766-- From nobody Mon Jul 20 04:31:50 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9F11A1A90 for ; Mon, 20 Jul 2015 04:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8aIp6FGLWQw7 for ; Mon, 20 Jul 2015 04:31:47 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id D8C701A1ADB for ; Mon, 20 Jul 2015 04:31:46 -0700 (PDT) From: Henning Schulzrinne To: "R.Jesske@telekom.de" , "br@brianrosen.net" , "md3135@att.com" Thread-Topic: [stir] Anonymous Calling Thread-Index: AQHQwoSDqwWBQf6kQk69x+HpofrA7p3kASSAgAABxgCAAAMSgIAAC0sAgAAArn8= Date: Mon, 20 Jul 2015 11:31:44 +0000 Message-ID: References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net>, <058CE00BD4D6B94FAD033A2439EA1E4B01EF89806D8E@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01EF89806D8E@HE113667.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 5:bN86LrPAH7B/Tnm1eXcNuiZx7bdcXftVFf5zAkIAKgx5QByy8Nb3sAgn4gxstRSlpjEO1XXEQIE4+mYsBtYD/Sp/J4DppRhg6R/xT7WhGpQt/Xpf8MV/2sHYJ6eZLwF3cheIHRqwikitGKijakSgUg==; 24:UTtBXzHlss9hBm8kIuX53vZUsUGUW0smswXVhVRw3cVVQUOy4Prn+Vd0wAAZq8Xt3FVQU7USuFtA84LmkbSy9yKTbEzznkDjwMk2pI8tsE0=; 20:3gXQY8cxkkdXsHDwiuc9lc4D1Ti5ZejIQ9ewI/OUtX5+w8hq+tk9VcKhVCbmQdPzHc6KlsIIbg5vM975rIix2g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636; cy1pr09mb0636: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 0643BDA83C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52314003)(377454003)(24454002)(5002640100001)(54356999)(76176999)(5001960100002)(33656002)(189998001)(2201001)(2656002)(50986999)(5003600100002)(76576001)(5003630100001)(102836002)(77096005)(87936001)(86362001)(2950100001)(2900100001)(46102003)(19580395003)(122556002)(99286002)(5001920100001)(40100003)(92566002)(62966003)(77156002)(74316001)(2501003)(106116001)(19580405001)(93886004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2015 11:31:44.2259 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" , "jon.peterson@neustar.biz" Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:31:48 -0000 Part of the problem may be that we're talking about two kinds of anonymity: (1) anonymous only to the called party (which is largely the PSTN behavior = today) (2) anonymous to the destination and intermediate carriers An important use case is #1, where people would be more likely to accept an= onymous calls if they were known not to be on a blacklist of nuisance calle= rs (and, conversely, that the caller's anonymity may be breached by court o= rder if the call turns out to be harassing, threatening or otherwise illega= l). As far as I can tell, the STIR mechanism supports version #1, but maybe the= description can be clarified since the commonly-understood caller ID conte= xt of "anonymous" is not anonymous.invalid, but closer to the first case. Henning ________________________________________ From: stir on behalf of R.Jesske@telekom.de Sent: Monday, July 20, 2015 5:05 AM To: br@brianrosen.net; md3135@att.com Cc: stir@ietf.org; jon.peterson@neustar.biz Subject: Re: [stir] Anonymous Calling Hi, I do not understand the difference. If you know the entity placing the From. Isn't this not also a kind of trus= t relationship? Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: stir [mailto:stir-bounces@ietf.org] Im Auftrag von Brian Rosen Gesendet: Montag, 20. Juli 2015 10:25 An: DOLLY, MARTIN C Cc: stir@ietf.org; Jon Peterson Betreff: Re: [stir] Anonymous Calling Who is signing, and what are they attesting? stir is supposed to be about making sure that the identifier in the From is= delegated to the entity placing the call. It is not =93this is a call fro= m a trusted party" That would preclude anyone signing a call from anonymous.invalid because th= ere is no delegation to anonymous.invalid Brian > >> On Jul 20, 2015, at 4:07 AM, Peterson, Jon wr= ote: >> >> >> Actually, the certificates draft doesn't talk about anonymity at all. I = assume you mean rfc4474bis. >> >> The text in Section 9 (2nd and 3rd paragraph) that seems to be confusing= you here talks about both the recommendations in RFC3323 and RFC3261. If y= ou are using an RFC3323 anonymization service, you will have a URI with a v= alid host portion (which could theoretically be signed). If you are using a= nonymous.invalid as a host, as RFC3261 used, then obviously no service can = or should sign it. But rfc4474bis in no way endorses one approach or the ot= her, or in some other way veers into this nebulous realm of "policy." It me= rely explains how the signature mechanism would interact with either of thi= s choices. >> >> Rereading that text, I don't think there any need to make that clearer. >> >> Jon Peterson >> Neustar, Inc, >> >> Sent from my iPad >> >>> On Jul 20, 2015, at 2:39 AM, Eric Burger w= rote: >>> >>> The certificates draft points out that one cannot do a rooted signature= over =93anonymous.invalid=94. That is the suggested domain for anonymous c= alls per RFC 3261. That is nice, and one could argue that 4474bis does not = eliminate anonymous calling. However, 4474bis gets into the policy world by= stating first of all the service provider should sign, stating something l= ike =93anonymous@example.net=94. However, that already leaks what could be = significantly revealing information (think of =93fbi.gov=94). >>> >>> The draft is close. I would offer the draft is more explicit in Section= 4.2 to state that it is recommended that UAS behavior is to not reject uns= igned requests if the request has an obviously anonymous From header. >>> >>> For interoperability, it would be good to update 3261 to mandate =93ano= nymous@anonymous.invalid=94 (I am not tied to the string, so long as it is = one and only one string) to indicate a universally anonymous identity. This= is as opposed to anonymous@example.net, which would always work because it= is just a user. Anyway, it leaves anonymous@lizardsquad.xxx available, whi= ch might be a real user or group of users. >>> _______________________________________________ From nobody Mon Jul 20 04:39:54 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928781A1DBC for ; Mon, 20 Jul 2015 04:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 W3srE9fqKSSD for ; Mon, 20 Jul 2015 04:39:36 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (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 40B6F1A21B9 for ; Mon, 20 Jul 2015 04:39:32 -0700 (PDT) Received: by qgii95 with SMTP id i95so39780306qgi.2 for ; Mon, 20 Jul 2015 04:39:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=DUwu8lR1n6+737deKbyJnFGnHaJ8647oDLFV46J+Co8=; b=HzetHNEnZ4EzNbRpjyfjuecx5AbWD8ggDp6WfYWhrFUy5oGZlSp749omJHxbVUknqe DCaOnUavcwn4gl7xYI3FUKAFBnn8Tjo41nHWV/p7p0WA0oUlpjxPFMLb3IPlx9tfCHYa b41lxHZf9W9fRuwSG7BnUS4H3kW5f8gufwYvqm+NR60gDJex6U9lGlpvXdP6mbuKgC+u JDwC1aFnYGctdWDmsATme8k3DnVZxaimN+tVr3WjdhmTsn2S13rspIruTNfKs68OtzGr GYC3/AdL3AuEuDp39tsNv8/5viD0gtqIi6PNXPjr+kwn8An/uc8y3380LX4POA1nFSsq Nr/A== X-Gm-Message-State: ALoCoQn96S4i2gHuW1ibuVbiCeuseVfYVx2lYCgdlNpEFfnIGU7f5Ab1pE3nM9Pbi8Jfml6Xg6qq X-Received: by 10.140.238.8 with SMTP id j8mr40396990qhc.78.1437392371545; Mon, 20 Jul 2015 04:39:31 -0700 (PDT) Received: from mrichards3-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id o64sm1367989qkh.25.2015.07.20.04.39.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Jul 2015 04:39:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0E7B14B1-B42F-4EC4-BD43-6454AF83D4EB" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Brian Rosen In-Reply-To: Date: Mon, 20 Jul 2015 13:39:25 +0200 Message-Id: <05DDD2DE-AA7D-4E31-AA9C-7A5AFDE8DFE6@brianrosen.net> References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> <058CE00BD4D6B94FAD033A2439EA1E4B01EF89806D8E@HE113667.emea1.cds.t-internal.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Jon Peterson , "stir@ietf.org" , "md3135@att.com" , "R.Jesske@telekom.de" Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:39:42 -0000 --Apple-Mail=_0E7B14B1-B42F-4EC4-BD43-6454AF83D4EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Perhaps I=92m confused. Are you saying that the call is placed with the = actual identity in From, marked as private, and then the terminating = service provider substitutes the identity with something else? With = respect to stir, as long as the termination service provider does the = check of the signature before it does that, sure. But I didn=92t think it worked that way (public calling using SIP = signaling) today. Brian > On Jul 20, 2015, at 1:31 PM, Henning Schulzrinne = wrote: >=20 > Part of the problem may be that we're talking about two kinds of = anonymity: >=20 > (1) anonymous only to the called party (which is largely the PSTN = behavior today) >=20 > (2) anonymous to the destination and intermediate carriers >=20 > An important use case is #1, where people would be more likely to = accept anonymous calls if they were known not to be on a blacklist of = nuisance callers (and, conversely, that the caller's anonymity may be = breached by court order if the call turns out to be harassing, = threatening or otherwise illegal). >=20 > As far as I can tell, the STIR mechanism supports version #1, but = maybe the description can be clarified since the commonly-understood = caller ID context of "anonymous" is not anonymous.invalid, but closer to = the first case. >=20 > Henning > ________________________________________ > From: stir > on = behalf of R.Jesske@telekom.de = > > Sent: Monday, July 20, 2015 5:05 AM > To: br@brianrosen.net ; md3135@att.com = > Cc: stir@ietf.org ; jon.peterson@neustar.biz = > Subject: Re: [stir] Anonymous Calling >=20 > Hi, > I do not understand the difference. >=20 > If you know the entity placing the From. Isn't this not also a kind of = trust relationship? >=20 > Best Regards >=20 > Roland >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: stir [mailto:stir-bounces@ietf.org] Im Auftrag von Brian Rosen > Gesendet: Montag, 20. Juli 2015 10:25 > An: DOLLY, MARTIN C > Cc: stir@ietf.org; Jon Peterson > Betreff: Re: [stir] Anonymous Calling >=20 > Who is signing, and what are they attesting? >=20 > stir is supposed to be about making sure that the identifier in the = =46rom is delegated to the entity placing the call. It is not =93this = is a call from a trusted party" >=20 > That would preclude anyone signing a call from anonymous.invalid = because there is no delegation to anonymous.invalid >=20 > Brian >=20 >=20 >=20 >>=20 >>> On Jul 20, 2015, at 4:07 AM, Peterson, Jon > wrote: >>>=20 >>>=20 >>> Actually, the certificates draft doesn't talk about anonymity at = all. I assume you mean rfc4474bis. >>>=20 >>> The text in Section 9 (2nd and 3rd paragraph) that seems to be = confusing you here talks about both the recommendations in RFC3323 and = RFC3261. If you are using an RFC3323 anonymization service, you will = have a URI with a valid host portion (which could theoretically be = signed). If you are using anonymous.invalid as a host, as RFC3261 used, = then obviously no service can or should sign it. But rfc4474bis in no = way endorses one approach or the other, or in some other way veers into = this nebulous realm of "policy." It merely explains how the signature = mechanism would interact with either of this choices. >>>=20 >>> Rereading that text, I don't think there any need to make that = clearer. >>>=20 >>> Jon Peterson >>> Neustar, Inc, >>>=20 >>> Sent from my iPad >>>=20 >>>> On Jul 20, 2015, at 2:39 AM, Eric Burger = > wrote: >>>>=20 >>>> The certificates draft points out that one cannot do a rooted = signature over =93anonymous.invalid=94. That is the suggested domain for = anonymous calls per RFC 3261. That is nice, and one could argue that = 4474bis does not eliminate anonymous calling. However, 4474bis gets into = the policy world by stating first of all the service provider should = sign, stating something like =93anonymous@example.net = =94. However, that already leaks what = could be significantly revealing information (think of =93fbi.gov = =94). >>>>=20 >>>> The draft is close. I would offer the draft is more explicit in = Section 4.2 to state that it is recommended that UAS behavior is to not = reject unsigned requests if the request has an obviously anonymous =46rom = header. >>>>=20 >>>> For interoperability, it would be good to update 3261 to mandate = =93anonymous@anonymous.invalid =94 = (I am not tied to the string, so long as it is one and only one string) = to indicate a universally anonymous identity. This is as opposed to = anonymous@example.net , which would always = work because it is just a user. Anyway, it leaves = anonymous@lizardsquad.xxx available, = which might be a real user or group of users. >>>> _______________________________________________ --Apple-Mail=_0E7B14B1-B42F-4EC4-BD43-6454AF83D4EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Perhaps I=92m confused.  Are you saying that the call is = placed with the actual identity in From, marked as private, and then the = terminating service provider substitutes the identity with something = else?  With respect to stir, as long as the termination service = provider does the check of the signature before it does that, sure.

But I didn=92t think it = worked that way (public calling using SIP signaling) today.

Brian

On Jul 20, 2015, at 1:31 PM, = Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Part of the problem may be that we're talking = about two kinds of anonymity:

(1) anonymous only to the = called party (which is largely the PSTN behavior today)

(2) anonymous to the destination and = intermediate carriers

An important use case is = #1, where people would be more likely to accept anonymous calls if they = were known not to be on a blacklist of nuisance callers (and, = conversely, that the caller's anonymity may be breached by court order = if the call turns out to be harassing, threatening or otherwise = illegal).

As far as I can tell, the = STIR mechanism supports version #1, but maybe the description can be = clarified since the commonly-understood caller ID context of "anonymous" = is not anonymous.invalid, but closer to the first case.

Henning
________________________________________From: stir <stir-bounces@ietf.org> on behalf of R.Jesske@telekom.de <R.Jesske@telekom.de>
Sent: Monday, July 20, = 2015 5:05 AM
To: br@brianrosen.net; md3135@att.com
Cc: stir@ietf.org; jon.peterson@neustar.biz
Subject: Re: [stir] Anonymous Calling

Hi,
I do not understand the = difference.

If you know the entity = placing the From. Isn't this not also a kind of trust = relationship?

Best Regards

Roland


-----Urspr=FCngliche Nachricht-----
Von: stir [mailto:stir-bounces@ietf.org] Im Auftrag von Brian = Rosen
Gesendet: Montag, 20. Juli = 2015 10:25
An: DOLLY, MARTIN = C
Cc: stir@ietf.org; Jon = Peterson
Betreff: Re: [stir] = Anonymous Calling

Who is signing, and what = are they attesting?

stir is supposed to be = about making sure that the identifier in the =46rom is delegated to the = entity placing the call.  It is not =93this is a call from a = trusted party"

That would preclude anyone = signing a call from anonymous.invalid because there is no delegation to = anonymous.invalid

Brian




On Jul 20, 2015, at 4:07 = AM, Peterson, Jon <jon.peterson@neustar.biz> wrote:


Actually, the certificates draft doesn't talk = about anonymity at all. I assume you mean rfc4474bis.

The text in Section 9 (2nd and 3rd paragraph) that seems to = be confusing you here talks about both the recommendations in RFC3323 = and RFC3261. If you are using an RFC3323 anonymization service, you will = have a URI with a valid host portion (which could theoretically be = signed). If you are using anonymous.invalid as a host, as RFC3261 used, = then obviously no service can or should sign it. But rfc4474bis in no = way endorses one approach or the other, or in some other way veers into = this nebulous realm of "policy." It merely explains how the signature = mechanism would interact with either of this choices.

Rereading that text, I don't think there any need to make = that clearer.

Jon Peterson
Neustar, Inc,

Sent from my = iPad

On = Jul 20, 2015, at 2:39 AM, Eric Burger <eburger@standardstrack.com> wrote:

The certificates draft points out that one cannot do a rooted = signature over =93anonymous.invalid=94. That is the suggested domain for = anonymous calls per RFC 3261. That is nice, and one could argue that = 4474bis does not eliminate anonymous calling. However, 4474bis gets into = the policy world by stating first of all the service provider should = sign, stating something like =93anonymous@example.net=94. However, that already leaks = what could be significantly revealing information (think of =93fbi.gov=94).

The draft is close. I would offer the draft is more explicit = in Section 4.2 to state that it is recommended that UAS behavior is to = not reject unsigned requests if the request has an obviously anonymous = =46rom header.

For interoperability, it = would be good to update 3261 to mandate =93anonymous@anonymous.invalid=94 (I am not tied to the = string, so long as it is one and only one string) to indicate a = universally anonymous identity. This is as opposed to anonymous@example.net, which would always work because it = is just a user. Anyway, it leaves anonymous@lizardsquad.xxx available, which might be a = real user or group of users.
_______________________________________________

= --Apple-Mail=_0E7B14B1-B42F-4EC4-BD43-6454AF83D4EB-- From nobody Mon Jul 20 04:47:54 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411C71A6F2F for ; Mon, 20 Jul 2015 04:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 aOrfmXJfruUf for ; Mon, 20 Jul 2015 04:47:42 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA5C1A1EF1 for ; Mon, 20 Jul 2015 04:47:39 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-08v.sys.comcast.net with comcast id ubmB1q0052TL4Rh01bney7; Mon, 20 Jul 2015 11:47:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-17v.sys.comcast.net with comcast id ubne1q0023Ge9ey01bnejQ; Mon, 20 Jul 2015 11:47:38 +0000 Message-ID: <55ACDFD9.6020809@alum.mit.edu> Date: Mon, 20 Jul 2015 07:47:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: stir@ietf.org References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> <058CE00BD4D6B94FAD033A2439EA1E4B01EF89806D8E@HE113667.emea1.cds.t-internal.com> <05DDD2DE-AA7D-4E31-AA9C-7A5AFDE8DFE6@brianrosen.net> In-Reply-To: <05DDD2DE-AA7D-4E31-AA9C-7A5AFDE8DFE6@brianrosen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437392858; bh=ngjipdfYQCrccWWNoLG+5eV2DzdSieI8grvVX1YfeOQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aebJYreamm5s+k0+TpEGfAaPpUcHWmhqEYMXiKvZU8/015RS8L8YbrsABAIJsFDZC agLJewa7TXN4nSM3gJPZAkNmZc7PczhzhL9y3DZFLw1uRTOEkkXahLczqXiUYEWoeS 4CwBbq4PDlyzo3xrl7ZtN3MQSej9lbqcz1/WFZuV1XhDi/JFgSQNKAbkNFJPKjzEZj IuN+MnsK8sSMp6o7+sM7Gc+WVwA6RsrRTgNNJPcC7vGJEHadfssae+Tt6kSt840z4S 0MSI/R5V53TfJvfSTiAkv466ks6xJW4q6tIZInisfYOJIwCPyUXYj/uLEzq8YV7kNq wy4AygwSZ+LPw== Archived-At: Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:47:44 -0000 On 7/20/15 7:39 AM, Brian Rosen wrote: > Perhaps I’m confused. Are you saying that the call is placed with the > actual identity in From, marked as private, and then the terminating > service provider substitutes the identity with something else? With > respect to stir, as long as the termination service provider does the > check of the signature before it does that, sure. > > But I didn’t think it worked that way (public calling using SIP > signaling) today. I thought that for this the call is made with anonymous in From and the actual id in P-Preferred/P-Asserted-ID. In that case I think it is the P-Asserted-ID that will be signed. And then before reaching the callee the P-Asserted-ID is removed. Presumably the signature will also be removed at that time. Thanks, Paul > Brian > >> On Jul 20, 2015, at 1:31 PM, Henning Schulzrinne >> > wrote: >> >> Part of the problem may be that we're talking about two kinds of >> anonymity: >> >> (1) anonymous only to the called party (which is largely the PSTN >> behavior today) >> >> (2) anonymous to the destination and intermediate carriers >> >> An important use case is #1, where people would be more likely to >> accept anonymous calls if they were known not to be on a blacklist of >> nuisance callers (and, conversely, that the caller's anonymity may be >> breached by court order if the call turns out to be harassing, >> threatening or otherwise illegal). >> >> As far as I can tell, the STIR mechanism supports version #1, but >> maybe the description can be clarified since the commonly-understood >> caller ID context of "anonymous" is not anonymous.invalid, but closer >> to the first case. >> >> Henning >> ________________________________________ >> From: stir > on >> behalf ofR.Jesske@telekom.de >> > > >> Sent: Monday, July 20, 2015 5:05 AM >> To:br@brianrosen.net ;md3135@att.com >> >> Cc:stir@ietf.org ;jon.peterson@neustar.biz >> >> Subject: Re: [stir] Anonymous Calling >> >> Hi, >> I do not understand the difference. >> >> If you know the entity placing the From. Isn't this not also a kind of >> trust relationship? >> >> Best Regards >> >> Roland >> >> >> -----Ursprüngliche Nachricht----- >> Von: stir [mailto:stir-bounces@ietf.org] Im Auftrag von Brian Rosen >> Gesendet: Montag, 20. Juli 2015 10:25 >> An: DOLLY, MARTIN C >> Cc: stir@ietf.org ; Jon Peterson >> Betreff: Re: [stir] Anonymous Calling >> >> Who is signing, and what are they attesting? >> >> stir is supposed to be about making sure that the identifier in the >> From is delegated to the entity placing the call. It is not “this is >> a call from a trusted party" >> >> That would preclude anyone signing a call from anonymous.invalid >> because there is no delegation to anonymous.invalid >> >> Brian >> >> >> >>> >>>> On Jul 20, 2015, at 4:07 AM, Peterson, Jon >>> > wrote: >>>> >>>> >>>> Actually, the certificates draft doesn't talk about anonymity at >>>> all. I assume you mean rfc4474bis. >>>> >>>> The text in Section 9 (2nd and 3rd paragraph) that seems to be >>>> confusing you here talks about both the recommendations in RFC3323 >>>> and RFC3261. If you are using an RFC3323 anonymization service, you >>>> will have a URI with a valid host portion (which could theoretically >>>> be signed). If you are using anonymous.invalid as a host, as RFC3261 >>>> used, then obviously no service can or should sign it. But >>>> rfc4474bis in no way endorses one approach or the other, or in some >>>> other way veers into this nebulous realm of "policy." It merely >>>> explains how the signature mechanism would interact with either of >>>> this choices. >>>> >>>> Rereading that text, I don't think there any need to make that clearer. >>>> >>>> Jon Peterson >>>> Neustar, Inc, >>>> >>>> Sent from my iPad >>>> >>>>> On Jul 20, 2015, at 2:39 AM, Eric Burger >>>>> > wrote: >>>>> >>>>> The certificates draft points out that one cannot do a rooted >>>>> signature over “anonymous.invalid”. That is the suggested domain >>>>> for anonymous calls per RFC 3261. That is nice, and one could argue >>>>> that 4474bis does not eliminate anonymous calling. However, 4474bis >>>>> gets into the policy world by stating first of all the service >>>>> provider should sign, stating something like “anonymous@example.net >>>>> ”. However, that already leaks what >>>>> could be significantly revealing information (think of “fbi.gov >>>>> ”). >>>>> >>>>> The draft is close. I would offer the draft is more explicit in >>>>> Section 4.2 to state that it is recommended that UAS behavior is to >>>>> not reject unsigned requests if the request has an obviously >>>>> anonymous From header. >>>>> >>>>> For interoperability, it would be good to update 3261 to mandate >>>>> “anonymous@anonymous.invalid ” >>>>> (I am not tied to the string, so long as it is one and only one >>>>> string) to indicate a universally anonymous identity. This is as >>>>> opposed toanonymous@example.net , >>>>> which would always work because it is just a user. Anyway, it >>>>> leavesanonymous@lizardsquad.xxx >>>>> available, which might be a real >>>>> user or group of users. >>>>> _______________________________________________ > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From nobody Mon Jul 20 04:59:48 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3BC1A6F7A for ; Mon, 20 Jul 2015 04:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4IFEtHpJ6Q5m for ; Mon, 20 Jul 2015 04:59:43 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0091A6FF7 for ; Mon, 20 Jul 2015 04:59:42 -0700 (PDT) From: Henning Schulzrinne To: Brian Rosen Thread-Topic: [stir] Anonymous Calling Thread-Index: AQHQwoSDqwWBQf6kQk69x+HpofrA7p3kASSAgAABxgCAAAMSgIAAC0sAgAAArn+AACp2gIAAAPzt Date: Mon, 20 Jul 2015 11:59:39 +0000 Message-ID: References: <560C2665-7E51-4A72-9A48-50A4EB665974@standardstrack.com> <1F8BB335-63DC-4817-9CAF-6527FD8A8843@brianrosen.net> <058CE00BD4D6B94FAD033A2439EA1E4B01EF89806D8E@HE113667.emea1.cds.t-internal.com> , <05DDD2DE-AA7D-4E31-AA9C-7A5AFDE8DFE6@brianrosen.net> In-Reply-To: <05DDD2DE-AA7D-4E31-AA9C-7A5AFDE8DFE6@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 5:33BmkPomGg6VvhOXyKzzD2NdFnzwT5JkrXkViJT7N4NdSIGY9fYOy2INXSlnRz51tUyytgoCD7Z0jUl95+JwIAV/lJh8+y2kNf9+HIddqjZ3RMLRzlY61WELYdq+J1dqYaGemia8zfMJcnQO96P9tw==; 24:w6gdhjSvcKunMW3RDMU7+mrQ2S4xf99CqslOKTZSWktsUbdWWPAHvrLUz7kMr4u/M4Us8BgQQ6iI/MeP+PZ/mF4fEVqOw4kPIO3H0FPojYc=; 20:/TkpsXMZJ8kZrRpOqhKsrNbrOqwJy0ADDxRLg7J6p5MJrMBlisSJxqR7AiSa4epSYOu9YuKuTqiWDfasZs7XLg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0634; cy1pr09mb0634: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 0643BDA83C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(52314003)(377454003)(24454002)(76176999)(86362001)(189998001)(5003600100002)(50986999)(5003630100001)(54356999)(19617315012)(19580405001)(99286002)(19627405001)(93886004)(106116001)(102836002)(15975445007)(77096005)(62966003)(77156002)(76576001)(2656002)(40100003)(19625215002)(15395725005)(122556002)(2900100001)(87936001)(2950100001)(92566002)(74316001)(33656002)(5002640100001)(46102003)(5001960100002)(110136002)(19580395003)(16236675004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634C60BE288E067D4ED728EEA850CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2015 11:59:39.2381 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Anonymous Calling X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:59:46 -0000 --_000_CY1PR09MB0634C60BE288E067D4ED728EEA850CY1PR09MB0634namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes. I believe we need to support that mode as otherwise "anonymous" callin= g essentially becomes "do not accept this call unless you love talking to f= raudsters". This is already, largely, true for traditional caller ID where = this is standard consumer advice. Many of the commercial robocall blocking = services, whether hardware or Android apps, have anonymous call blocking as= the default setting. Interestingly, the Nomorobo filtering service does a version of this. They = rely on simultaneous ringing (aka forking) and fork to an 800#, which deliv= ers the calling number to the filtering service even if the caller has pres= sed *67. I don't know how widely Privacy: header is implemented in SIP space. ________________________________ From: Brian Rosen Sent: Monday, July 20, 2015 7:39 AM To: Henning Schulzrinne Cc: R.Jesske@telekom.de; md3135@att.com; stir@ietf.org; Jon Peterson Subject: Re: [stir] Anonymous Calling Perhaps I=92m confused. Are you saying that the call is placed with the ac= tual identity in From, marked as private, and then the terminating service = provider substitutes the identity with something else? With respect to sti= r, as long as the termination service provider does the check of the signat= ure before it does that, sure. But I didn=92t think it worked that way (public calling using SIP signaling= ) today. Brian On Jul 20, 2015, at 1:31 PM, Henning Schulzrinne > wrote: Part of the problem may be that we're talking about two kinds of anonymity: (1) anonymous only to the called party (which is largely the PSTN behavior = today) (2) anonymous to the destination and intermediate carriers An important use case is #1, where people would be more likely to accept an= onymous calls if they were known not to be on a blacklist of nuisance calle= rs (and, conversely, that the caller's anonymity may be breached by court o= rder if the call turns out to be harassing, threatening or otherwise illega= l). As far as I can tell, the STIR mechanism supports version #1, but maybe the= description can be clarified since the commonly-understood caller ID conte= xt of "anonymous" is not anonymous.invalid, but closer to the first case. Henning ________________________________________ From: stir > on behalf = of R.Jesske@telekom.de > Sent: Monday, July 20, 2015 5:05 AM To: br@brianrosen.net; md3135@att.com Cc: stir@ietf.org; jon.peterson@neustar.biz Subject: Re: [stir] Anonymous Calling Hi, I do not understand the difference. If you know the entity placing the From. Isn't this not also a kind of trus= t relationship? Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: stir [mailto:stir-bounces@ietf.org] Im Auftrag von Brian Rosen Gesendet: Montag, 20. Juli 2015 10:25 An: DOLLY, MARTIN C Cc: stir@ietf.org; Jon Peterson Betreff: Re: [stir] Anonymous Calling Who is signing, and what are they attesting? stir is supposed to be about making sure that the identifier in the From is= delegated to the entity placing the call. It is not =93this is a call fro= m a trusted party" That would preclude anyone signing a call from anonymous.invalid because th= ere is no delegation to anonymous.invalid Brian On Jul 20, 2015, at 4:07 AM, Peterson, Jon > wrote: Actually, the certificates draft doesn't talk about anonymity at all. I ass= ume you mean rfc4474bis. The text in Section 9 (2nd and 3rd paragraph) that seems to be confusing yo= u here talks about both the recommendations in RFC3323 and RFC3261. If you = are using an RFC3323 anonymization service, you will have a URI with a vali= d host portion (which could theoretically be signed). If you are using anon= ymous.invalid as a host, as RFC3261 used, then obviously no service can or = should sign it. But rfc4474bis in no way endorses one approach or the other= , or in some other way veers into this nebulous realm of "policy." It merel= y explains how the signature mechanism would interact with either of this c= hoices. Rereading that text, I don't think there any need to make that clearer. Jon Peterson Neustar, Inc, Sent from my iPad On Jul 20, 2015, at 2:39 AM, Eric Burger > wrote: The certificates draft points out that one cannot do a rooted signature ove= r =93anonymous.invalid=94. That is the suggested domain for anonymous calls= per RFC 3261. That is nice, and one could argue that 4474bis does not elim= inate anonymous calling. However, 4474bis gets into the policy world by sta= ting first of all the service provider should sign, stating something like = =93anonymous@example.net=94. However, that al= ready leaks what could be significantly revealing information (think of =93= fbi.gov=94). The draft is close. I would offer the draft is more explicit in Section 4.2= to state that it is recommended that UAS behavior is to not reject unsigne= d requests if the request has an obviously anonymous From header. For interoperability, it would be good to update 3261 to mandate =93anonymo= us@anonymous.invalid=94 (I am not tied = to the string, so long as it is one and only one string) to indicate a univ= ersally anonymous identity. This is as opposed to anonymous@example.net, which would always work because it is just a us= er. Anyway, it leaves anonymous@lizardsquad.xxx available, which might be a real user or group of users. _______________________________________________ --_000_CY1PR09MB0634C60BE288E067D4ED728EEA850CY1PR09MB0634namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Yes. I believe we need to support that mode as otherwise "anonymous= " calling essentially becomes "do not accept this call unless you= love talking to fraudsters". This is already, largely, true for tradi= tional caller ID where this is standard consumer advice. Many of the commercial robocall blocking services, whether hardware or And= roid apps, have anonymous call blocking as the default setting.


Interestingly, the Nomorobo filtering service does a version of this. Th= ey rely on simultaneous ringing (aka forking) and fork to an 800#, which de= livers the calling number to the filtering service even if the caller has p= ressed *67.


I don't know how widely


Privacy: header


is implemented in SIP space.


From: Brian Rosen <br@br= ianrosen.net>
Sent: Monday, July 20, 2015 7:39 AM
To: Henning Schulzrinne
Cc: R.Jesske@telekom.de; md3135@att.com; stir@ietf.org; Jon Peterson=
Subject: Re: [stir] Anonymous Calling
 
Perhaps I=92m confused.  Are you saying that the call is placed w= ith the actual identity in From, marked as private, and then the terminatin= g service provider substitutes the identity with something else?  With= respect to stir, as long as the termination service provider does the check of the signature before it does that, sure= .

But I didn=92t think it worked that way (public calling usi= ng SIP signaling) today.

Brian

On Jul 20, 2015, at 1:31 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc= .gov> wrote:

Part of the problem may be that we're talking about two kinds of anonymity:

(1) anonymous only to the called party (which is largely the PSTN behavior tod= ay)

(2) anonymous to the destination and intermediate carriers

An important use case is #1, where people would be more likely to accept anon= ymous calls if they were known not to be on a blacklist of nuisance callers= (and, conversely, that the caller's anonymity may be breached by court ord= er if the call turns out to be harassing, threatening or otherwise illegal).

As far as I can tell, the STIR mechanism supports version #1, but maybe the d= escription can be clarified since the commonly-understood caller ID context= of "anonymous" is not anonymous.invalid, but closer to the first= case.

Henning
________________________________________<= br class=3D"" style=3D"font-family:Helvetica; font-size:12px; font-style:no= rmal; font-variant:normal; font-weight:normal; letter-spacing:normal; line-= height:normal; orphans:auto; text-align:start; text-indent:0px; text-transf= orm:none; white-space:normal; widows:auto; word-spacing:0px"> From: stir <stir-bounces@ietf.org> on behalf of R.Jesske@telekom.de <>
Sent: Monday, July 20, 2015 5:05 AM
To: <= /span>br@brianrosen.net; md3135@att.com
Cc: <= /span>stir@ietf.org;<= span class=3D"Apple-converted-space"> jon.peterson@neustar.biz
Subject: Re: [stir] Anonymous Calling

Hi,
I do not understand the difference.

If you know the entity placing the From. Isn't this not also a kind of trust = relationship?

Best Regards
Roland


-----Urspr=FCngliche Nachricht-----
Von: stir [mailto:stir-boun= ces@ietf.org] Im Auftrag von Brian Rosen
Gesendet: Montag, 20. Juli 2015 10:25
An: DOLLY, MARTIN C
Cc: stir@ietf.org; Jon Peterson=
Betreff: Re: [stir] Anonymous Calling

Who is signing, and what are they attesting?

stir is supposed to be about making sure that the identifier in the From is del= egated to the entity placing the call.  It is not =93this is a call fr= om a trusted party"

That would preclude anyone signing a call from anonymous.invalid because there = is no delegation to anonymous.invalid

Brian




On Jul 20, 2015, at 4:07 AM, Peterson,= Jon <jon.peterso= n@neustar.biz> wrote:


Actually, the certificates draft doesn't talk about anonymity at all. I ass= ume you mean rfc4474bis.

The text in Section 9 (2nd and 3rd paragraph) that seems to be confusing yo= u here talks about both the recommendations in RFC3323 and RFC3261. If you = are using an RFC3323 anonymization service, you will have a URI with a vali= d host portion (which could theoretically be signed). If you are using anonymous.invalid as a host, as RFC3261 used,= then obviously no service can or should sign it. But rfc4474bis in no way = endorses one approach or the other, or in some other way veers into this ne= bulous realm of "policy." It merely explains how the signature mechanism would interact with either of this ch= oices.

Rereading that text, I don't think there any need to make that clearer.

Jon Peterson
Neustar, Inc,

Sent from my iPad

On Jul 20, 2015, at 2:39 AM, Eric Burg= er <eburger@sta= ndardstrack.com> wrote:

The certificates draft points out that one cannot do a rooted signature ove= r =93anonymous.invalid=94. That is the suggested domain for anonymous calls= per RFC 3261. That is nice, and one could argue that 4474bis does not elim= inate anonymous calling. However, 4474bis gets into the policy world by stating first of all the service provider sh= ould sign, stating something like =93anonymous@example.net=94. However, that already leaks wha= t could be significantly revealing information (think of =93fbi.gov=94).

The draft is close. I would offer the draft is more explicit in Section 4.2= to state that it is recommended that UAS behavior is to not reject unsigne= d requests if the request has an obviously anonymous From header.

For interoperability, it would be good to update 3261 to mandate =93anonymous@anonymous.inva= lid=94 (I am not tied to the string, so long as it is one and only one = string) to indicate a universally anonymous identity. This is as opposed to = ;anonymous@examp= le.net, which would always work because it is just a user. Anyway, it l= eaves anonymous@lizardsquad.xxx available, which might be a real user or group of users.
_______________________________________________

--_000_CY1PR09MB0634C60BE288E067D4ED728EEA850CY1PR09MB0634namp_-- From nobody Mon Jul 20 05:18:00 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635041A6FFD for ; Mon, 20 Jul 2015 05:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 2grIQe2Edjk2 for ; Mon, 20 Jul 2015 05:17:57 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 85C631A3BA4 for ; Mon, 20 Jul 2015 05:17:57 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6KCFnRD030359 for ; Mon, 20 Jul 2015 08:17:57 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vrt8j0m73-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 20 Jul 2015 08:17:57 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.249]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Mon, 20 Jul 2015 08:17:55 -0400 From: "Rosen, Brian" To: IETF STIR Mail List Thread-Topic: "*" or no "*"? Thread-Index: AQHQwuYb1wsrgAIhcUq4eaANCWjfdg== Date: Mon, 20 Jul 2015 12:17:55 +0000 Message-ID: <48B4B767-A941-4AD4-AB5E-0502485DF9D5@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.132.13] 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.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-20_02:2015-07-20,2015-07-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [stir] "*" or no "*"? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 12:17:58 -0000 SSB0aGluayB0aGUgdGV4dCBpbiA0NDc0LWJpcyBpcyB1bmNsZWFyIGlmIHRoZSDigJwq4oCdIGlz IHBhcnQgb2YgdGhlIGNhbm9uaWNhbGl6YXRpb24gb3Igbm90LiAgSXQgdGFsa3MgYWJvdXQgYWRk aW5nIGEgY291bnRyeSBjb2RlLCBidXQgbm90IHRoZSAqLCBhbmQgaXQgc2F5cyB0aGUg4oCcKiIg aXMgcGFydCBvZiB0aGUgQUJORi4gIEl0IHNob3VsZCBiZSBjcnlzdGFsIGNsZWFyIGlmIHRoZSAq IGlzIHBhcnQgb2YgY2Fub25pY2FsaXphdGlvbiBvciBub3QuDQoNCkkgYWxzbyB3b3VsZCBsaWtl IHRvIHNlZSBtb3JlIHRleHQgb24g4oCcI+KAnS4gIFdoZW4gZG8gd2UgZXhwZWN0IHRvIHNlZSBp dD8gIEFnYWluLCBteSBnb2FsIGlzIGludGVyb3BlcmFiaWxpdHksIHNvIEkgdGhpbmsgc3BlbGxp bmcgb3V0IHdoZW4gaXQgc2hvdWxkIGJlIHVzZWQuDQoNCkJyaWFu From nobody Mon Jul 20 23:08:26 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B921B2A43 for ; Mon, 20 Jul 2015 11:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0-Yd-VahBich for ; Mon, 20 Jul 2015 11:02:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234D01B2A63 for ; Mon, 20 Jul 2015 11:02:23 -0700 (PDT) Received: from dhcp-8996.meeting.ietf.org ([IPv6:2001:67c:370:136:98ca:35e8:ab3b:4ecb]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6KI2JU9034563 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 20 Jul 2015 13:02:21 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [IPv6:2001:67c:370:136:98ca:35e8:ab3b:4ecb] claimed to be dhcp-8996.meeting.ietf.org To: stir@ietf.org From: "A. Jean Mahoney" Message-ID: <55AD37AA.1050205@nostrum.com> Date: Mon, 20 Jul 2015 20:02:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 20 Jul 2015 23:08:24 -0700 Subject: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 18:02:52 -0000 Hi all, My notes from the meeting below. Ellipses (...) mark places where I didn't catch what was said. Feel free to fill in. Thanks, Jean Secure Telephone Identity Revisited (STIR) IETF 93 Session 2015-07-20 1520-1720: Karlin III 10m Administrative - Chairs Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-stir-2.pdf Presenters: Robert Sparks, Russ Housley Jabber scribe: Pete Resnick Jabber archive: http://www.ietf.org/jabber/logs/stir/2015-07-20.html Note taker: Jean Mahoney Slides presented. Note Well noted, no changes to the agenda. 50m draft-ietf-stir-rfc4474bis-04 Document: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-stir-0.pdf Presenter: Jon Peterson slide 1: Title slide 2: What we did since -03 slide 3: Open Issues: Signing PAI "canon" is an optimization, it captures how the signer saw it. Helpful for debugging. Can assume that everyone within a Trust domain can do the canonicalization. PAI is stripped when leaving the trust domain, but what about 'canon' - maybe the gateway wouldn't remove it. This is noted in the draft text. What's the value of the signature in a closed, trusted network? Martin Dolly: Not quite true that PAI only originate in a TD. We receive them over other interfaces. Having a verification mechanism and sign it... Enterprises today will send a PAI to the carrier. We process on customer subscriber ID, we don't look at it. For a North Am deployment that the enterprise could use that number, and the basis for the carrier signing it. Jon: Do we need to revisit 3325? Kill me if we do. It's the edge element's responsibility to ... and promulgate it through the trust domain. I'm skeptical that's the motivation. Brian Rosen: It /might/ be acceptable to write text that the PAI is there... If the person doesn't put in the right From, the call will fail. Jon: ... I'm not going to recommend it - there are problems Brian: Even if they don't put the canon in, if it doesn't match what is in the From, it's ok. The originator didn't do it right, or a middle box didn't do it right, and it will fail. Jon: and that's ok. Henning: Schulzrinne: PAI does cross boundaries across the carriers - SIP Forum/ATIS document. Jon: This is what Mark Watson was imagining when he wrote RFC3324. The SIP networks would behave like the PSTN. Martin: If you look at spoof and robocalling, they're typically from smaller carriers. ATT doesn't trust those carriers like it trusts Verizon, but we have to interwork with them. It was said on the list a few times - we cannot just drop calls, we are legally obligated. Brian: Ok, verification might fail. I didn't say drop. Jon: how do verify... Martin: If we are going to deploy on signing certain parts of the messages that are validated at the end. To address reality - you have to sign PAI. Jon: It lets you sign PAI today. Henning: The brief privacy discussion we had earlier on the list today. Anonymity is really pseudo-anonymity. The carrier knows, but not the recipient. The current model - use the standard anonymity in the From header and keep the PAI. We need to distinguish because they are different services. Particularly, if you have anonymous calls, you should sign. Needs to be default behavior. Jon: we can add motivating text to explain when you want to make the tradeoff. There's privacy leakage. Implementations have to be mindful, and shouldn't hurt anybody. Robin Wilton: There's another use case - I have a portable, 3rd party number and I give it to other people. It breaks for a couple reasons, like because the receiver won't accept tariff uplift. It might break here. Jon: I think we have a story for this. NNI use cases that use PAI, would be good to know. slide 4: Signing anything else Jon: CNIT - how to implement? I swore I wouldn't do it, but I've defined a blank-check extension header for future proofing - Identity-Extension. Need to have strict IANA controls on it - standards action and enough review. Henning: We have 2 mechanisms - Identity-Extension and identity-reliance mechanisms. Getting cozy with each other. These are exceptional mechanisms and will be widely deployed. The more we unify these concepts. Take URI, make it part of the signature. One can fail, one can succeed. Part of the motivating design - organized and single way. Concern about current draft - multiple signing authorities - enterprises and carrier. We need to look at the permutations. Jon: valid concerns. I allow 1 extension per request. Becomes a LOA, and the decisions become more complex. Henning: It should not be a kitchen sink. Don't object to raising the bar. What's the operational model? How do you fingerprint it? How to canonicalize it? Do you expect hard or soft failure? There's enough stuff to be specified... I prefer a single, extensible mechanism rather than three. Identity-Extension is not a good sign. Jon: It can be done. We have 3 things that are one-off mechanisms, may or may not be in the signing. Secure RTP - not always present. Identity-Reliance - can sign the entire message. Henning is saying that I should just generalize, and it will look like DKIM. I can live with that, but I swore I would not do DKIM. I want it to be clear - is it trustable? Henning: From the code perspective: it doesn't matter. I think we're close enough to convergence. It's easier to separate out things that ATIS will worry about immediately versus long term. Pete Resnick: Make sure the Identity-Extension is signed. Jon: The Identity header ensures the it's signed. Make all the options a Identity-Extension, and a path to extend it. Henning: Need to be aware of 2 models - single entity doing a lot of sigs. We want to downgrade attacks. You have 2 entities that are doing the signing. Depending on the ordering, may happen before CNAM signing. For instance, Carrier signs it, hands it to Dunn & Bradstreet, who verifies that it's from this bank and signs it. The signature is always the last one. Need to be aware of it. The master signer is the one that adds the Identity header. Jon: I was going to argue that the CNIT was the .. Signed by.. I want the trust to be end-to-end. To get the property - have its own signer. being argued in CNIT. Robert Sparks: as you make the changes, what pitfalls do we need to avoid its looking DKIM-y? Jon: standards action. Robert: anyone object? Alyssa Cooper: You could make it more burdensome - have to address how it will interact with what is already there. Jon: we can create a template - what you have to do. I'm good. slide 5: Eric's Comments Robin: The authentication service must authenticate - why did Eric make that comment? Jon: Eric thinks that an authentication service is a intermediary. But there is no bar, the auth service could be in the endpoint. Robin: conflation of ... if you hand out credentials, but if you haven't authenticated. We can help disambiguate. Eric Burger (in the jabber room, relayed via Pete): the difference is what we know versus a non-IETF implementor. I'm sure the people who wrote the PATRIOT Act had no idea it would be used to spy on Americans, for example. Yes, the draft has a sentence about the service can be in the SIP UA. It then has paragraphs on a separate service. If you did not listen to this discussion (and who does), what would you think if you were an implementor? I think we should explicitly describe the three major deployment models: In the SIP UAC, By the service provider (P-CSCF/SBC) or Enterprise (IP PBX), and a third-party service bureau (as Henning *just* said). Jon: I'm content to say "end points" and "intermediaries", and these elements understand their logical roles. Henning: I agree. SIP forum and ATIS can explain how to use it in their environments as long as the models aren't being excluded. These extensions are presented in the draft like characters in a novel. Can cover the extensions in the overview. That would address the functional flexibility. Eric: Agree Jon: Good suggestion. slide 6: Next Steps? Jon: As identified here - Identity-Extension to subsume the fingerprint and reliance mechanisms. Brian: I raised the issue about # and *. Robert: When will this get done? There are environmental pressures to finish. Will there be spin and talk in Yokohama, or a LC before late September? Jon: Let's try to do it by September. Henning: People can send text to help out. Jon: definitely. There's going to be surgery on this draft. 4:06 60m draft-ietf-stir-certificates-02 - Jon Peterson Document: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates slide 1: Title slide 2: What we did since -01 Martin: I don't see where this is needed. Authorities assign TNs to companies that they can punish. If you sign this, it's traceable. If you didn't do it correctly, you can be punished. I don't think this mandatory. Jon: We're trying to detect threats. The certs could be delegated, maybe to small enterprises or end users. They can sign from their own end points. Henning: I don't understand the difference between sign it and - signed by number allocated, then signed by ATT, delegated down to a PBX company - Jon: that's one model. For ATT it isn't useful to list numbers. ATT and Verizon trust each other. Henning: They could create a custom cert for each number. Jon: Or they can have 1 cert for every number they own. Paul Kyzivat from Jabber room via Pete: For UAS to be able to authenticate, the cert and TNAuthList must be accessible to any UAS. Any plan to require that? Jon: if it is present, it's part of the cert. They have this TNAuthList. slide 3: Why OCSP? (Refresher) Eric: Even if we agree to the presentation today, and I will be the first to say that I may have *totally* misunderstood the Certs draft, but if someone with just half a clue can totally misunderstand the draft (and I don't think I did), then someone with a quarter clue will be totally lost. And, I agree with others, I still do not see the merits of knowing whether or not someone is authorized to sign for a number. Jon: Can we pull up the charter - the point is to know if someone is authenticated to use the number. Martin: ATT authenticates and validates that the phone can use that phone number, ATT doesn't know if its actually _you_. ATT says this phone can use this number. Jon: That's exactly the mechanism. Brian: and it they want to, they can have just one cert for every number. Chairs pulled up the charter: The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. Martin: The solution doesn't need to include TNs in the cert. You need to validate the cert. Jon: If I can get to the slide that describes this. slide 4: In-band STIR Logical Architecture Henning: Every student in computer science knows that any problem can be solved by adding another level of indirection. We're trying to avoid a per-number cert. Jon: But we will allow it. Henning: The number of network transits Jon: have whole slide. From an efficiency perspective. OCSP is not required. Henning: The more mechanisms we add, on the validation side, you have to support all of them. I'm worried that the more mechanisms, the higher the burden on the receiver. We've just added complexity without adding value. Jon: I think we should go the slides Richard Barnes: you should do OCSP anyway - then 0 cost. Jon: can download via URL. Eric: I do not want to let the statement "The charter says we MUST have a cert mechanism to carry TNs" go unchallenged. That is factually incorrect. Paul: if I get a cert not from ATT, but from acme-telco.net signing a number, if I can't get evidence that it is entitled to sign for the number, then why would I trust it? Pete, to Eric: Nobody is saying that the cert has to carry the TN AFAICT. Who did? Eric: The alternative in the draft is you poll at a transaction rate of 100,000 tps for a typical U.S. busy hour to ask someone else if the cert covers the TN. Not a realistic model. So it is not the issue of carrying the TN, but that anyone cares about the TN at all. (TN in the or covered by the cert. Of course, the whole point is validating the TN) Jon: I think we should take the discussion to the list. At a high level, it won't matter to you. But it's to support use cases, that the cert is associated to TN. This charter is not of use for you. Brian: 100k/hour or minute is no big deal. We can do that. slide 5: RFC5019 vs RFC6960 Richard: This thing shouldn't impact scalability of RFC5019 Paul: if the usage model becomes one of recipients trusting certain signers, then users will be forced to get their numbers from a widely trusted provider. Jon: Don't think so - there will be a proper chain of delegation Robin: There's a level of confusion - who is trusting what, how is it exchanged? TN vs not-TN, what's it mean? Jon: we say what goes on the wire, you make the decision of what to do. If there's interest in specifying the policy decisions. As the bis draft becomes more DKIM-like. slide 6: Our Extension: TNQuery Jon: Sean and I talked this over. Seemed OK. Russ? Russ is not barfing. Don't want an "unknown" response, it has hard edges. Richard: the optimization that 5019 gives you is based on "unknown". If a cert is expired, you don't have to keep it. It lets you pre-generate responses. Russ: There's also a serial number that hasn't been issued. Richard: The only thing you say yes on - are things that are valid. Things expired or not issued - it's unknown. The cert is "unknown". Jon: I don't trust it. Why have even have "unknown"? Henning: One reason - for caching. If you receive a no, the cert won't get more valid with time. If you get an "unknown" - you might try again. I have a question about the mechanism - a validator would separate into - carriers will sell you a cert and say OCSP. Jon: You have to check the OCSP - see the chain. Russ Housley: OCSP responses - good, bad, unknown - the only one you are interested in is good. We are adding - does it apply to the number? If the cert is good, you get yes or no on that question. Pete: I'm checking with the chair - go with a whitelist? Brian: in every formal system, there are always informal systems. Jon: Premise is false - the carriers don't know each other's numbers. And get upset if another carrier finds out. Jon: what do we do with "unknown"? Russ: treat it as "no" ???: treat it as "no" Jon: done Robert: RTFM slide 7: TNQuery (2): Open Questions Richard: it doesn't seem critical, you get the ... Allow multiple TNs in the request, it has a privacy benefit. Don't put it in the response. Like fuzzing in geopriv. Robert: you can't say yes for some. Jon: you can glom OCSP into one request. Richard: check the RFC. Robert: Since i haven't read the RFCs in quite some time, can you include more numbers in the response than in the request? Richard: yes. you can cache by chunk. Jon: yes slide 8: TNQuery (3): Why do you ask? Jon: would like to tie the request to a call. To avoid impersonators and spidering. Richard: the attacker can't ask for any number. Has to be in the scope of the cert. They can segment the space. Jon: But if Martin wants to be lazy, I don't want to prevent that. It's only fair, what he gives me on the list. Henning: you have to have a small number - a cert for an area code doesn't help a whole lot. I don't think dividing the space will help. Martin: if you allow for one cert per carrier. ok. Jon: do we think this is a problem? We can work on it. slide 9: Fancy Measures Robert (from floor): reacting or overreacting to this in real time - I'll restate what I heard. CA gives a secret to the caller. The hash is included in the request and the hash has Jon: TN is part of it with the nonce. Robert: why restrict it to the TN? OCSP server digests the hash. Could you bury the ranges in the hash? Richard: (off mic) Russ: it certainly interferes with this. Robert: this is getting weedy. Jon: ... Richard: The entire point to add numbers was to provide chaff. Jon: This is the only promising path. Richard: not very promising. Pete: anyone want to do this? Martin: No! Pete: Suggestion - let's not do this, and see who yelps. There are other ways of doing this. Richard: I think the answer is no. To put one more knife in this, don't you need the signer online to do this nonce-y thing? Jon: this is an idea that Sean and I had at the bar yesterday. Russ: I want to see that napkin. Jon: This is not in the draft, and if people don't want to work on this, that's ok. slide 10: Acquiring TNAuthList By Reference Henning: who would return? Jon: Cisco PBX with 1k numbers. Henning: a carrier that owns 50M numbers. These numbers are going to be onsies and twosies because of ports. If the cert says I'm a carrier. If I have to ask the LNPA, that changes by the minute and will be outdated when I get it. Jon: 2 cases - root of trust issues every cert. ATT goes to that authority to ask on behalf of the entity. The root give it to the entity. Or ATT can delegate. All these certs exist still. The chain will say if that part of the chain had authority. Jon: issued by ATT for a larger share. Henning: list of 50M random numbers. Jon: all that matters - what's been delegated is a part of the ATT list. Henning: if I'm a validator, and I don't know the small carrier, and I go to the OCSP server. Jonathan Lennox: Say I'm mafia telecom, and I control the OCSP server. It has to be who delegated to mafia telecom. Jon: 2 ways - go to LNPA or go to the carrier. There's always the guy above you. You didn't self-sign the cert. Lennox: what about multiple delegated chains? I have to validate every step in chain. Jon: yes. Sean Turner: you have to go up the path, but you can cache. You can send more than one request per query. Richard: I'll throw out a idea in realtime - live OCSP to resolve - prefer not to do this for web. OCSP stapling. In addition to cert you get a signed blob. Jon: you put the burden on the sender. Richard: need to take the idea to the list. Jon: the signer choses what the validation is. The validator can't ask about random numbers. The way to spider is one call per number. The stapling occurs during call. Robin: this heading in a direction of a problem in the web PKI world, where there are multiple chains of authority Jon: there's a single for each country. Robin: good. Martin: needs to be simple. Are you still going to have spoof calls? Yes. Circuit calls will continue, and they won't be validated. If you are going to make it better, but not solved. Chris Wendt: A while ago I advocated a grouping model. I'm moving to a one cert per number model. Henning: We have 3 mechanisms - caching, OCSP, and this mechanism. What I'm missing is an estimate on real scenarios - typical interaction. Deployability is the biggest concern. How would OCSP work? If something got invalidated 10 seconds ago? Who needs to talk to whom? Jon: We are designing tools, we're not designing architecture. This is the first time we're discussing this. Henning: a set of roughly common test cases. Long before ATIS gets it. We need to have a common understanding about who does what to whom. Trying to make it efficient. Jon: this is new stuff. OCSP changes everything. We're still looking at design space. Eric: And then we are back to the entity issuing the cert attesting they are authorized to issue the cert. In the real world, that is good enough because as Martin says, they can be punished. It also highlights why no one will care whether or not someone is allowed to sign for a particular TN, or block of TNs. Punishment is good enough. And then the Mafia goes to jail. Bad for a day, but then the problem gets fixed for at least 10 years. (10 years when they are in jail) Jon: no comment Pete: Joe Blow telecom gets a query regarding a call. Joe Blow telecom lies about owning the number. As a validator, I received a response from ATT about the number, but I won't get the answer that joe blow telecom is nonsense. Jon: you won't get to the OCSP server if Joe is self-signing Lennox: What's the difference between stapled response and a ... Jon: ... Lennox: why would I want multiple? Richard: tiny response and answer, versus big answer. Lennox: what's the benefit of big certs? It seems better to be per TN. Jon: I suspect that carriers want certs for blocks. Sean: we bring DOS up. But there are other things to worry about. Brian: create a couple of use cases and work it out. Chris: Good suggestion. Jon: the big certs are for big carriers. Robert: We are out of time. Jon: I got a lot of good feedback. Robert: there are lot of comfy couches and hallways here. Have conversations. Russ: Take it to the list. Rest of slides skipped: slide 11: Future Work: Subscriptions slide 12: Other Open Issues slide 13: Eric's Comments slide 14: Next Steps From nobody Tue Jul 21 02:31:51 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942341B2C1A for ; Tue, 21 Jul 2015 02:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 AbIpSo1U3ZE6 for ; Tue, 21 Jul 2015 02:31:44 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281541B2C62 for ; Tue, 21 Jul 2015 02:31:43 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id c711ea55.0.6435889.00-2314.18181601.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 21 Jul 2015 09:31:43 +0000 (UTC) X-MXL-Hash: 55ae117f16eb5f08-3182bcc4d723d76b182e207bd3a5160aaf2a9b0d 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 t6L9VdkN021827; Tue, 21 Jul 2015 05:31:40 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6L9VYl0021807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jul 2015 05:31:35 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 21 Jul 2015 09:31:24 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.130]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0224.002; Tue, 21 Jul 2015 05:31:24 -0400 From: "DOLLY, MARTIN C" To: "A. Jean Mahoney" , "stir@ietf.org" Thread-Topic: [stir] stir 93 meeting minutes Thread-Index: AQHQw3utZWugsKph9UihtC3XUQWLZp3lpzgg Date: Tue, 21 Jul 2015 09:31:24 +0000 Message-ID: References: <55AD37AA.1050205@nostrum.com> In-Reply-To: <55AD37AA.1050205@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.209.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=IsOphsDg c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=KWRL4Bq8hUMA:10 a=zOBTX] X-AnalysisOut: [jUuO1YA:10 a=48vgC7mUAAAA:8 a=7dcmwuz6AAAA:8 a=PMOaC1mfSaa] X-AnalysisOut: [qS5YRf38A:9 a=CjuIK1q_8ugA:10 a=8oo38lL-w6UA:10 a=_EbcOWAT] X-AnalysisOut: [SgHDGM-r:21 a=N-c4f3cE-koTGdIc:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 09:31:48 -0000 Edits inline -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of A. Jean Mahoney Sent: Monday, July 20, 2015 2:02 PM To: stir@ietf.org Subject: [stir] stir 93 meeting minutes Hi all, My notes from the meeting below. Ellipses (...) mark places where I didn't = catch what was said. Feel free to fill in. Thanks, Jean Secure Telephone Identity Revisited (STIR) IETF 93 Session 2015-07-20 1520-= 1720: Karlin III 10m Administrative - Chairs Presentation:=20 https://www.ietf.org/proceedings/93/slides/slides-93-stir-2.pdf Presenters: Robert Sparks, Russ Housley Jabber scribe: Pete Resnick Jabber archive: http://www.ietf.org/jabber/logs/stir/2015-07-20.html Note taker: Jean Mahoney Slides presented. Note Well noted, no changes to the agenda. 50m draft-ietf-stir-rfc4474bis-04 Document: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis Presentation:=20 https://www.ietf.org/proceedings/93/slides/slides-93-stir-0.pdf Presenter: Jon Peterson slide 1: Title slide 2: What we did since -03 slide 3: Open Issues: Signing PAI "canon" is an optimization, it captures how the signer saw it. Helpful for = debugging. Can assume that everyone within a Trust domain can do the canonicalization.= PAI is stripped when leaving the trust domain, but what about 'canon' - ma= ybe the gateway wouldn't remove it. This is noted in the draft text. What's= the value of the signature in a closed, trusted network? Martin Dolly: Not quite true that PAI only originate in a TD. We receive th= em over other interfaces. Having a verification mechanism and sign it... En= terprises today will send a PAI to the carrier. We process on customer subs= criber ID, we don't look at it. For a North Am deployment that the enterpri= se could use that number, and the basis for the carrier signing it. >>mcd begin .... having a verification mechanism and signing the PAI is the only way t= o guarantee verification. ...... For a North American deployment, the carri= er could validate that the enterprise is allowed to use the number in the P= AI (network verification in ISUP/ISDN terms) and sign it. >>>mcd end Jon: Do we need to revisit 3325? Kill me if we do. It's the edge element's = responsibility to ... and promulgate it through the trust domain. I'm skep= tical that's the motivation. Brian Rosen: It /might/ be acceptable to write text that the PAI is there..= . If the person doesn't put in the right From, the call will fail. Jon: ... I'm not going to recommend it - there are problems Brian: Even if they don't put the canon in, if it doesn't match what is in = the From, it's ok. The originator didn't do it right, or a middle box didn'= t do it right, and it will fail. Jon: and that's ok. Henning: Schulzrinne: PAI does cross boundaries across the carriers - SIP F= orum/ATIS document. Jon: This is what Mark Watson was imagining when he wrote RFC3324. The SIP = networks would behave like the PSTN. Martin: If you look at spoof and robocalling, they're typically from smalle= r carriers. ATT doesn't trust those carriers like it trusts Verizon, but we= have to interwork with them. It was said on the list a few times - we cann= ot just drop calls, we are legally obligated. >Mcd begin: ....we are legally obligated to complete them. >MCD end Brian: Ok, verification might fail. I didn't say drop. Jon: how do verify... Martin: If we are going to deploy on signing certain parts of the messages = that are validated at the end. To address reality - you have to sign PAI. Jon: It lets you sign PAI today. Henning: The brief privacy discussion we had earlier on the list today.=20 Anonymity is really pseudo-anonymity. The carrier knows, but not the recipi= ent. The current model - use the standard anonymity in the From header and = keep the PAI. We need to distinguish because they are different services. P= articularly, if you have anonymous calls, you should sign. Needs to be defa= ult behavior. Jon: we can add motivating text to explain when you want to make the tradeo= ff. There's privacy leakage. Implementations have to be mindful, and should= n't hurt anybody. Robin Wilton: There's another use case - I have a portable, 3rd party numbe= r and I give it to other people. It breaks for a couple reasons, like becau= se the receiver won't accept tariff uplift. It might break here. Jon: I think we have a story for this. NNI use cases that use PAI, would be= good to know. slide 4: Signing anything else Jon: CNIT - how to implement? I swore I wouldn't do it, but I've defined a = blank-check extension header for future proofing - Identity-Extension.=20 Need to have strict IANA controls on it - standards action and enough revie= w. Henning: We have 2 mechanisms - Identity-Extension and identity-reliance me= chanisms. Getting cozy with each other. These are exceptional mechanisms an= d will be widely deployed. The more we unify these concepts. Take URI, make= it part of the signature. One can fail, one can succeed. Part of the motiv= ating design - organized and single way.=20 Concern about current draft - multiple signing authorities - enterprises an= d carrier. We need to look at the permutations. Jon: valid concerns. I allow 1 extension per request. Becomes a LOA, and th= e decisions become more complex. Henning: It should not be a kitchen sink. Don't object to raising the bar. = What's the operational model? How do you fingerprint it? How to canonicaliz= e it? Do you expect hard or soft failure? There's enough stuff to be specif= ied... I prefer a single, extensible mechanism rather than three. Identity-= Extension is not a good sign. Jon: It can be done. We have 3 things that are one-off mechanisms, may or m= ay not be in the signing. Secure RTP - not always present.=20 Identity-Reliance - can sign the entire message. Henning is saying that I s= hould just generalize, and it will look like DKIM. I can live with that, bu= t I swore I would not do DKIM. I want it to be clear - is it trustable? Henning: From the code perspective: it doesn't matter. I think we're close = enough to convergence. It's easier to separate out things that ATIS will wo= rry about immediately versus long term. Pete Resnick: Make sure the Identity-Extension is signed. Jon: The Identity header ensures the it's signed. Make all the options a Id= entity-Extension, and a path to extend it. Henning: Need to be aware of 2 models - single entity doing a lot of sigs. = We want to downgrade attacks. You have 2 entities that are doing the signin= g. Depending on the ordering, may happen before CNAM signing.=20 For instance, Carrier signs it, hands it to Dunn & Bradstreet, who verifies= that it's from this bank and signs it. The signature is always the last on= e. Need to be aware of it. The master signer is the one that adds the Ident= ity header. Jon: I was going to argue that the CNIT was the .. Signed by.. I want the t= rust to be end-to-end. To get the property - have its own signer.=20 being argued in CNIT. Robert Sparks: as you make the changes, what pitfalls do we need to avoid i= ts looking DKIM-y? Jon: standards action. Robert: anyone object? Alyssa Cooper: You could make it more burdensome - have to address how it w= ill interact with what is already there. Jon: we can create a template - what you have to do. I'm good. slide 5: Eric's Comments Robin: The authentication service must authenticate - why did Eric make tha= t comment? Jon: Eric thinks that an authentication service is a intermediary. But ther= e is no bar, the auth service could be in the endpoint. Robin: conflation of ... if you hand out credentials, but if you haven't au= thenticated. We can help disambiguate. Eric Burger (in the jabber room, relayed via Pete): the difference is what = we know versus a non-IETF implementor. I'm sure the people who wrote the PA= TRIOT Act had no idea it would be used to spy on Americans, for example. Ye= s, the draft has a sentence about the service can be in the SIP UA. It then= has paragraphs on a separate service. If you did not listen to this discus= sion (and who does), what would you think if you were an implementor? I th= ink we should explicitly describe the three major deployment models: In th= e SIP UAC, By the service provider (P-CSCF/SBC) or Enterprise (IP PBX), and a third-party service bureau (as H= enning *just* said). Jon: I'm content to say "end points" and "intermediaries", and these elemen= ts understand their logical roles. Henning: I agree. SIP forum and ATIS can explain how to use it in their env= ironments as long as the models aren't being excluded. These extensions are= presented in the draft like characters in a novel. Can cover the extension= s in the overview. That would address the functional flexibility. Eric: Agree Jon: Good suggestion. slide 6: Next Steps? Jon: As identified here - Identity-Extension to subsume the fingerprint and= reliance mechanisms. Brian: I raised the issue about # and *. Robert: When will this get done? There are environmental pressures to finis= h. Will there be spin and talk in Yokohama, or a LC before late September? Jon: Let's try to do it by September. Henning: People can send text to help out. Jon: definitely. There's going to be surgery on this draft. 4:06 60m draft-ietf-stir-certificates-02 - Jon Peterson Document: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates slide 1: Title slide 2: What we did since -01 Martin: I don't see where this is needed. Authorities assign TNs to compani= es that they can punish. If you sign this, it's traceable. If you didn't do= it correctly, you can be punished. I don't think this mandatory. Jon: We're trying to detect threats. The certs could be delegated, maybe to= small enterprises or end users. They can sign from their own end points. Henning: I don't understand the difference between sign it and - signed by = number allocated, then signed by ATT, delegated down to a PBX company - Jon: that's one model. For ATT it isn't useful to list numbers. ATT and Ver= izon trust each other. Henning: They could create a custom cert for each number. Jon: Or they can have 1 cert for every number they own. Paul Kyzivat from Jabber room via Pete: For UAS to be able to authenticate,= the cert and TNAuthList must be accessible to any UAS. Any plan to require= that? Jon: if it is present, it's part of the cert. They have this TNAuthList. slide 3: Why OCSP? (Refresher) Eric: Even if we agree to the presentation today, and I will be the first t= o say that I may have *totally* misunderstood the Certs draft, but if someo= ne with just half a clue can totally misunderstand the draft (and I don't t= hink I did), then someone with a quarter clue will be totally lost. And, I = agree with others, I still do not see the merits of knowing whether or not = someone is authorized to sign for a number. Jon: Can we pull up the charter - the point is to know if someone is authen= ticated to use the number. Martin: ATT authenticates and validates that the phone can use that phone n= umber, ATT doesn't know if its actually _you_. ATT says this phone can use = this number. Jon: That's exactly the mechanism. Brian: and it they want to, they can have just one cert for every number. Chairs pulled up the charter: The STIR working group will specify Internet-= based mechanisms that allow verification of the calling party's authorizati= on to use a particular telephone number for an incoming call. Martin: The solution doesn't need to include TNs in the cert. You need to v= alidate the cert. Jon: If I can get to the slide that describes this. slide 4: In-band STIR Logical Architecture Henning: Every student in computer science knows that any problem can be so= lved by adding another level of indirection. We're trying to avoid a per-nu= mber cert. Jon: But we will allow it. Henning: The number of network transits Jon: have whole slide. From an efficiency perspective. OCSP is not required= . Henning: The more mechanisms we add, on the validation side, you have to su= pport all of them. I'm worried that the more mechanisms, the higher the bur= den on the receiver. We've just added complexity without adding value. Jon: I think we should go the slides Richard Barnes: you should do OCSP anyway - then 0 cost. Jon: can download via URL. Eric: I do not want to let the statement "The charter says we MUST have a c= ert mechanism to carry TNs" go unchallenged. That is factually incorrect. Paul: if I get a cert not from ATT, but from acme-telco.net signing a numbe= r, if I can't get evidence that it is entitled to sign for the number, then= why would I trust it? Pete, to Eric: Nobody is saying that the cert has to carry the TN AFAICT. W= ho did? Eric: The alternative in the draft is you poll at a transaction rate of 100,000 tps for a typical U.S. busy hour to ask someone else if the cert co= vers the TN. Not a realistic model. So it is not the issue of carrying the = TN, but that anyone cares about the TN at all. (TN in the or covered by the= cert. Of course, the whole point is validating the TN) Jon: I think we should take the discussion to the list. At a high level, it= won't matter to you. But it's to support use cases, that the cert is assoc= iated to TN. This charter is not of use for you. Brian: 100k/hour or minute is no big deal. We can do that. slide 5: RFC5019 vs RFC6960 Richard: This thing shouldn't impact scalability of RFC5019 Paul: if the usage model becomes one of recipients trusting certain signer= s, then users will be forced to get their numbers from a widely trusted pro= vider. Jon: Don't think so - there will be a proper chain of delegation Robin: There's a level of confusion - who is trusting what, how is it excha= nged? TN vs not-TN, what's it mean? Jon: we say what goes on the wire, you make the decision of what to do.=20 If there's interest in specifying the policy decisions. As the bis draft be= comes more DKIM-like. slide 6: Our Extension: TNQuery Jon: Sean and I talked this over. Seemed OK. Russ? Russ is not barfing.=20 Don't want an "unknown" response, it has hard edges. Richard: the optimization that 5019 gives you is based on "unknown". If=20 a cert is expired, you don't have to keep it. It lets you pre-generate=20 responses. Russ: There's also a serial number that hasn't been issued. Richard: The only thing you say yes on - are things that are valid.=20 Things expired or not issued - it's unknown. The cert is "unknown". Jon: I don't trust it. Why have even have "unknown"? Henning: One reason - for caching. If you receive a no, the cert won't=20 get more valid with time. If you get an "unknown" - you might try again.=20 I have a question about the mechanism - a validator would separate into=20 - carriers will sell you a cert and say OCSP. Jon: You have to check the OCSP - see the chain. Russ Housley: OCSP responses - good, bad, unknown - the only one you are=20 interested in is good. We are adding - does it apply to the number? If=20 the cert is good, you get yes or no on that question. Pete: I'm checking with the chair - go with a whitelist? Brian: in every formal system, there are always informal systems. Jon: Premise is false - the carriers don't know each other's numbers.=20 And get upset if another carrier finds out. Jon: what do we do with "unknown"? Russ: treat it as "no" ???: treat it as "no" Jon: done Robert: RTFM slide 7: TNQuery (2): Open Questions Richard: it doesn't seem critical, you get the ... Allow multiple TNs in=20 the request, it has a privacy benefit. Don't put it in the response.=20 Like fuzzing in geopriv. Robert: you can't say yes for some. Jon: you can glom OCSP into one request. Richard: check the RFC. Robert: Since i haven't read the RFCs in quite some time, can you=20 include more numbers in the response than in the request? Richard: yes. you can cache by chunk. Jon: yes slide 8: TNQuery (3): Why do you ask? Jon: would like to tie the request to a call. To avoid impersonators and=20 spidering. Richard: the attacker can't ask for any number. Has to be in the scope=20 of the cert. They can segment the space. Jon: But if Martin wants to be lazy, I don't want to prevent that. It's=20 only fair, what he gives me on the list. Henning: you have to have a small number - a cert for an area code=20 doesn't help a whole lot. I don't think dividing the space will help. Martin: if you allow for one cert per carrier. ok. Jon: do we think this is a problem? We can work on it. slide 9: Fancy Measures Robert (from floor): reacting or overreacting to this in real time -=20 I'll restate what I heard. CA gives a secret to the caller. The hash is=20 included in the request and the hash has Jon: TN is part of it with the nonce. Robert: why restrict it to the TN? OCSP server digests the hash. Could=20 you bury the ranges in the hash? Richard: (off mic) Russ: it certainly interferes with this. Robert: this is getting weedy. Jon: ... Richard: The entire point to add numbers was to provide chaff. Jon: This is the only promising path. Richard: not very promising. Pete: anyone want to do this? Martin: No! Pete: Suggestion - let's not do this, and see who yelps. There are other=20 ways of doing this. Richard: I think the answer is no. To put one more knife in this, don't=20 you need the signer online to do this nonce-y thing? Jon: this is an idea that Sean and I had at the bar yesterday. Russ: I want to see that napkin. Jon: This is not in the draft, and if people don't want to work on this,=20 that's ok. slide 10: Acquiring TNAuthList By Reference Henning: who would return? Jon: Cisco PBX with 1k numbers. Henning: a carrier that owns 50M numbers. These numbers are going to be=20 onsies and twosies because of ports. If the cert says I'm a carrier. If=20 I have to ask the LNPA, that changes by the minute and will be outdated=20 when I get it. Jon: 2 cases - root of trust issues every cert. ATT goes to that=20 authority to ask on behalf of the entity. The root give it to the=20 entity. Or ATT can delegate. All these certs exist still. The chain will=20 say if that part of the chain had authority. Jon: issued by ATT for a larger share. Henning: list of 50M random numbers. Jon: all that matters - what's been delegated is a part of the ATT list. Henning: if I'm a validator, and I don't know the small carrier, and I=20 go to the OCSP server. Jonathan Lennox: Say I'm mafia telecom, and I control the OCSP server.=20 It has to be who delegated to mafia telecom. Jon: 2 ways - go to LNPA or go to the carrier. There's always the guy=20 above you. You didn't self-sign the cert. Lennox: what about multiple delegated chains? I have to validate every=20 step in chain. Jon: yes. Sean Turner: you have to go up the path, but you can cache. You can send=20 more than one request per query. Richard: I'll throw out a idea in realtime - live OCSP to resolve -=20 prefer not to do this for web. OCSP stapling. In addition to cert you=20 get a signed blob. Jon: you put the burden on the sender. Richard: need to take the idea to the list. Jon: the signer choses what the validation is. The validator can't ask=20 about random numbers. The way to spider is one call per number. The=20 stapling occurs during call. Robin: this heading in a direction of a problem in the web PKI world,=20 where there are multiple chains of authority Jon: there's a single for each country. Robin: good. Martin: needs to be simple. Are you still going to have spoof calls?=20 Yes. Circuit calls will continue, and they won't be validated. If you=20 are going to make it better, but not solved. Chris Wendt: A while ago I advocated a grouping model. I'm moving to a=20 one cert per number model. Henning: We have 3 mechanisms - caching, OCSP, and this mechanism. What=20 I'm missing is an estimate on real scenarios - typical interaction.=20 Deployability is the biggest concern. How would OCSP work? If something=20 got invalidated 10 seconds ago? Who needs to talk to whom? Jon: We are designing tools, we're not designing architecture. This is=20 the first time we're discussing this. Henning: a set of roughly common test cases. Long before ATIS gets it.=20 We need to have a common understanding about who does what to whom.=20 Trying to make it efficient. Jon: this is new stuff. OCSP changes everything. We're still looking at=20 design space. Eric: And then we are back to the entity issuing the cert attesting they=20 are authorized to issue the cert. In the real world, that is good enough=20 because as Martin says, they can be punished. It also highlights why no=20 one will care whether or not someone is allowed to sign for a particular=20 TN, or block of TNs. Punishment is good enough. And then the Mafia goes=20 to jail. Bad for a day, but then the problem gets fixed for at least 10=20 years. (10 years when they are in jail) Jon: no comment Pete: Joe Blow telecom gets a query regarding a call. Joe Blow telecom=20 lies about owning the number. As a validator, I received a response from=20 ATT about the number, but I won't get the answer that joe blow telecom=20 is nonsense. Jon: you won't get to the OCSP server if Joe is self-signing Lennox: What's the difference between stapled response and a ... Jon: ... Lennox: why would I want multiple? Richard: tiny response and answer, versus big answer. Lennox: what's the benefit of big certs? It seems better to be per TN. Jon: I suspect that carriers want certs for blocks. Sean: we bring DOS up. But there are other things to worry about. Brian: create a couple of use cases and work it out. Chris: Good suggestion. Jon: the big certs are for big carriers. Robert: We are out of time. Jon: I got a lot of good feedback. Robert: there are lot of comfy couches and hallways here. Have=20 conversations. Russ: Take it to the list. Rest of slides skipped: slide 11: Future Work: Subscriptions slide 12: Other Open Issues slide 13: Eric's Comments slide 14: Next Steps _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 21 04:05:30 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC531A00B9 for ; Tue, 21 Jul 2015 04:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 l1lFceUsHhU5 for ; Tue, 21 Jul 2015 04:05:26 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B371A0078 for ; Tue, 21 Jul 2015 04:05:22 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-11v.sys.comcast.net with comcast id uz5L1q0032GyhjZ01z5NKj; Tue, 21 Jul 2015 11:05:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-09v.sys.comcast.net with comcast id uz5M1q00Q3Ge9ey01z5NPL; Tue, 21 Jul 2015 11:05:22 +0000 Message-ID: <55AE2770.9020101@alum.mit.edu> Date: Tue, 21 Jul 2015 07:05:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437476722; bh=WYkHeJJKP/CRxUCQdv5I+rGaIPt6RMFd8vF7OsqY1lw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=frJwrEPk22r8vIqoyOvev2rAjz671Hvr7uvycRn20m3keOzErdjBwXYquJUJeiNBA VEWUn0PQwPtOhCfnXyD3SnUXrbtqzD4SZJZkK98XMao9+XXHIhiQMle9cgUyIyb+oA V6lTp7+vT/Xx/PfQ5dPf/TRspoIiicODK5NgzCfk0i3C4JUlAYFy8CEmot1XBRHsDG LfheatKKd+dAb0vzbF+8mmFjokiw2C9jZnL8GXob0ZIFxFkvx2liqFd8+c7jjfQgla EQZcw1LNG6ZnrKbmvZeiPKwmElsCsDPKvzGy63s31C0CXi68UzMe5lk1FPokEJQXn6 mCX+p2ubcBS4A== Archived-At: Subject: [stir] the role of trust in stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 11:05:28 -0000 I couldn't make myself clear via jabber during the discussion, so I'll try again. This is similar to a point that Henning made. There seem to be a few models for how verifier determines whether a cert actually covers the number it signs: - the message contains the cert - the message contains a ref to the cert And then, regardless of how the cert is obtained: - the cert contains the TN. - the cert contains a reference to a list of covered TNs. - the cert has neither (is that a real possibility?) This then leads to several possible cases for the verifier: 1) there is no signature 2) there is a signature, but the cert can't be obtained 3) cert has been obtained, no attempt is made to determine formal coverage of the TN (because policy doesn't require it). 4) cert has been obtained, but coverage of TN by cert can't be determined 5) cert has been obtained, and it explicitly does NOT cover the TN. 6) cert has been obtained, and coverage of TN has been verified I think all of those cases are possible regardless of policy. It then becomes a matter of policy how to treat calls in each case: allow or not, display calling TN or not, indicate warning or not. But if certain policies become widely used they could have the effect of making other policies unusable. And that can have the effect of encouraging oligopolies. In particular, if a common verifier policy is to just whitelist certain signers without checking coverage, and block the id from everybody else, then anybody who gets service from a provider who isn't on the whitelist runs the risk of not having their calls answered. Also, when providers know most verifiers follow that policy, then they can also sign calls from favored peers not on the whitelist. (IOW, they can *lie*, assuming the lie won't be checked, instead reinstituting a transitive trust model.) That will allow them to further extend their business lock in and discriminate against whoever they want. It seems especially bad to enable an environment where signatures can be made by signers who don't have authority over the signed TN. I would like to see a system where verification doesn't depend on whitelists. (However blacklists could be used to reduce verification cost for bad actors.) (I guess ultimately whitelists must exist at some level, but better be only at the very top of the delegation chain.) Thanks, Paul From nobody Tue Jul 21 05:15:01 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027191A0217 for ; Tue, 21 Jul 2015 05:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 haGlqPEWhqLK for ; Tue, 21 Jul 2015 05:14:58 -0700 (PDT) Received: from extmail1.yaanatech.com (extmail1.yaanatech.com [63.128.177.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6811A00DB for ; Tue, 21 Jul 2015 05:14:57 -0700 (PDT) Received: from [192.168.1.51] (pool-70-106-196-128.clppva.fios.verizon.net [70.106.196.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by extmail1.yaanatech.com (Postfix) with ESMTP id 3D47858110; Tue, 21 Jul 2015 12:20:52 +0000 (UTC) References: <55AD37AA.1050205@nostrum.com> To: "DOLLY, MARTIN C" , "A. Jean Mahoney" , "stir@ietf.org" From: Tony Rutkowski Organization: Yaana Technologies Message-ID: <55AE37C0.4050307@yaanatech.com> Date: Tue, 21 Jul 2015 08:14:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tony@yaanatech.com List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:15:00 -0000 Hi Martin, It might be worth assessing the "obligation" assertion in light of the Commission's recently released TCPA Omnibus Declaratory Ruling and Order. See https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order See esp. at para. 152 et. seq. The FCC Ruling and Order is arguably a game changer, and the basis for implementing STIR or equivalent platforms. If you get the customer's approval, you can drop - unless there is some additional inter carrier contract obligation. Although even if there is, the Commission's Order arguably prevails. --tony On 2015-07-21 5:31 AM, DOLLY, MARTIN C wrote: > Martin: If you look at spoof and robocalling, they're typically from sm= aller carriers. ATT doesn't trust those carriers like it trusts Verizon, = but we have to interwork with them. It was said on the list a few times -= we cannot just drop calls, we are legally obligated. >> > From nobody Tue Jul 21 05:23:07 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12441A1AB3 for ; Tue, 21 Jul 2015 05:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1qXE4jFlMVdN for ; Tue, 21 Jul 2015 05:22:54 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457951A01E2 for ; Tue, 21 Jul 2015 05:22:45 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 4993ea55.0.2226600.00-2017.6261008.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 21 Jul 2015 12:22:45 +0000 (UTC) X-MXL-Hash: 55ae39957b2acc05-2abb6332d48c8d8fd1728a73d0648ebb2e893283 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 t6LCMiaq026159; Tue, 21 Jul 2015 08:22:44 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6LCMcXH026083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jul 2015 08:22:40 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 21 Jul 2015 12:22:27 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.130]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0224.002; Tue, 21 Jul 2015 08:22:27 -0400 From: "DOLLY, MARTIN C" To: "tony@yaanatech.com" , "A. Jean Mahoney" , "stir@ietf.org" Thread-Topic: [stir] stir 93 meeting minutes Thread-Index: AQHQw3utZWugsKph9UihtC3XUQWLZp3lpzgggABylAD//73U8A== Date: Tue, 21 Jul 2015 12:22:27 +0000 Message-ID: References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> In-Reply-To: <55AE37C0.4050307@yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.141.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=JfoLWz2V c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=epUacWqvclgA:10 a=zOBTX] X-AnalysisOut: [jUuO1YA:10 a=scBmumm3AAAA:8 a=48vgC7mUAAAA:8 a=doUQZJtgAAA] X-AnalysisOut: [A:8 a=qLRhDz4ce641yErdXFoA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:23:00 -0000 Tony, Yes, of course we can take action, like dropping the call, with the consume= rs consent. WTS, what is the criteria? If not the same for all, if not it would be unma= nageable. Also, black lists are not a one size fits all solution. I believe the best model is to deliver the call with an indication that the= calling party has been "validated by", and let the consumer to decide to a= ccept or not. Regards, Martin -----Original Message----- From: Tony Rutkowski [mailto:tony@yaanatech.com]=20 Sent: Tuesday, July 21, 2015 8:15 AM To: DOLLY, MARTIN C; A. Jean Mahoney; stir@ietf.org Subject: Re: [stir] stir 93 meeting minutes Hi Martin, It might be worth assessing the "obligation" assertion in light of the Comm= ission's recently released TCPA Omnibus Declaratory Ruling and Order. See = https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order See esp. at para. 152 et. seq. The FCC Ruling and Order is arguably a game changer, and the basis for impl= ementing STIR or equivalent platforms. If you get the customer's approval,= you can drop - unless there is some additional inter carrier contract obli= gation. Although even if there is, the Commission's Order arguably prevails. --tony On 2015-07-21 5:31 AM, DOLLY, MARTIN C wrote: > Martin: If you look at spoof and robocalling, they're typically from smal= ler carriers. ATT doesn't trust those carriers like it trusts Verizon, but = we have to interwork with them. It was said on the list a few times - we ca= nnot just drop calls, we are legally obligated. >> > From nobody Tue Jul 21 05:32:30 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402F21A1B39 for ; Tue, 21 Jul 2015 05:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 kGM1NsvhSJhl for ; Tue, 21 Jul 2015 05:32:27 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 DBEFE1A1AB3 for ; Tue, 21 Jul 2015 05:32:26 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t6LCWNkQ016716 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jul 2015 12:32:24 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t6LCWNlI011040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Jul 2015 12:32:23 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t6LCWNl1020383; Tue, 21 Jul 2015 12:32:23 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-152-107.vpn.oracle.com (/10.154.152.107) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Jul 2015 05:32:22 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_58FB2BDD-0F42-49F4-BB8E-DAE3978CDC62" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Travis Russell In-Reply-To: Date: Tue, 21 Jul 2015 08:32:24 -0400 Message-Id: <20B6299A-8D90-4F28-A476-600475B54F2F@oracle.com> References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.2102) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "stir@ietf.org" , "A. Jean Mahoney" , "tony@yaanatech.com" Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:32:29 -0000 --Apple-Mail=_58FB2BDD-0F42-49F4-BB8E-DAE3978CDC62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There is some potential for =E2=80=9Cprofiling=E2=80=9D some of these = calls. For example, looking at the characteristics of a group of calls = to find commonalities that match the profile of a robocall (something = being done today). Its not perfect, but until the problem of spoofed = identities gets resolved, its the best means for identifying possible = nuisance calls. As these profiles are developed, they can be used in the = network core to determine call treatment (block, route, etc). This is = the approach that many are taking today.=20 Having a =E2=80=9Ccert=E2=80=9D for a caller identity would add to the = subscribers confidence that an incoming call from an unrecognized number = is legitimate.=20 Travis Russell | Director, Product Marketing, Service Provider Networks = |=20 +1919.205.6857 (o) | +1919.412.1167 (c) 5200 Paramount Pkwy Morrisville, NC 27560 USA Oracle is committed to developing practices and products that help = protect the environment > On Jul 21, 2015, at 8:22 AM, DOLLY, MARTIN C wrote: >=20 > Tony, >=20 > Yes, of course we can take action, like dropping the call, with the = consumers consent. > WTS, what is the criteria? If not the same for all, if not it would be = unmanageable. Also, black lists are not a one size fits all solution. >=20 > I believe the best model is to deliver the call with an indication = that the calling party has been "validated by", and let the consumer to = decide to accept or not. >=20 > Regards, >=20 > Martin >=20 > -----Original Message----- > From: Tony Rutkowski [mailto:tony@yaanatech.com]=20 > Sent: Tuesday, July 21, 2015 8:15 AM > To: DOLLY, MARTIN C; A. Jean Mahoney; stir@ietf.org > Subject: Re: [stir] stir 93 meeting minutes >=20 > Hi Martin, >=20 > It might be worth assessing the "obligation" assertion in light of the = Commission's recently released TCPA Omnibus Declaratory Ruling and = Order. See = https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order > See esp. at para. 152 et. seq. >=20 > The FCC Ruling and Order is arguably a game changer, and the basis for = implementing STIR or equivalent platforms. If you get the customer's = approval, you can drop - unless there is some additional inter carrier = contract obligation. > Although even if there is, the Commission's Order arguably prevails. >=20 > --tony >=20 >=20 > On 2015-07-21 5:31 AM, DOLLY, MARTIN C wrote: >> Martin: If you look at spoof and robocalling, they're typically from = smaller carriers. ATT doesn't trust those carriers like it trusts = Verizon, but we have to interwork with them. It was said on the list a = few times - we cannot just drop calls, we are legally obligated. >>>>=20 >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_58FB2BDD-0F42-49F4-BB8E-DAE3978CDC62 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_E43B280A-8D70-47EC-B66D-F06936567049" --Apple-Mail=_E43B280A-8D70-47EC-B66D-F06936567049 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There is some potential for =E2=80=9Cprofiling=E2=80=9D some = of these calls. For example, looking at the characteristics of a group = of calls to find commonalities that match the profile of a robocall = (something being done today). Its not perfect, but until the problem of = spoofed identities gets resolved, its the best means for identifying = possible nuisance calls. As these profiles are developed, they can be = used in the network core to determine call treatment (block, route, = etc). This is the approach that many are taking today. 

Having a =E2=80=9Ccert=E2=80= =9D for a caller identity would add to the subscribers confidence that = an incoming call from an unrecognized number is legitimate. 



Travis Russell | Director, = Product Marketing, Service Provider Networks | 
+1919.205.6857 (o) = | +1919.412.1167 = (c)

5200 Paramount Pkwy
Morrisville, NC 27560
USA



Oracle is committed to developing = practices and products that help protect the environment



On Jul 21, 2015, at 8:22 AM, DOLLY, MARTIN C <md3135@att.com> = wrote:

Tony,

Yes, of course we can take = action, like dropping the call, with the consumers consent.
WTS, what is the criteria? If not the same for all, if not it = would be unmanageable. Also, black lists are not a one size fits all = solution.

I believe the best model is to = deliver the call with an indication that the calling party has been = "validated by", and let the consumer to decide to accept or not.

Regards,

Martin

-----Original Message-----
From: = Tony Rutkowski [mailto:tony@yaanatech.com]
Sent: Tuesday, = July 21, 2015 8:15 AM
To: DOLLY, MARTIN C; A. Jean = Mahoney; stir@ietf.org
Subject: Re: [stir] stir 93 meeting minutes

Hi Martin,

It might be worth = assessing the "obligation" assertion in light of the Commission's = recently released TCPA Omnibus Declaratory Ruling and Order.  See = https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-an= d-order
See esp. at para. 152 et. seq.
The FCC Ruling and Order is arguably a game changer, and the = basis for implementing STIR or equivalent platforms.  If you get = the customer's approval, you can drop - unless there is some additional = inter carrier contract obligation.
Although even if there = is, the Commission's Order arguably prevails.

--tony


On = 2015-07-21 5:31 AM, DOLLY, MARTIN C wrote:
Martin: If you look at spoof and robocalling, = they're typically from smaller carriers. ATT doesn't trust those = carriers like it trusts Verizon, but we have to interwork with them. It = was said on the list a few times - we cannot just drop calls, we are = legally obligated.




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

= --Apple-Mail=_E43B280A-8D70-47EC-B66D-F06936567049 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=oracle-email-sig-198324.gif Content-Type: image/gif; name="oracle-email-sig-198324.gif" Content-Id: R0lGODlhcgAaAMQAAP8QEP/w8P/Q0P/g4P8wMP9gYP8gIP+goP9QUP+QkP+wsP9wcP+AgP9AQP/A wP8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAByABoAAAX/ICSOZGmeaKqubOu+cCzPdC0GCqPvvBKUDp5wp1gFdIPVIDfcOQa6A8yR aO4gweQoUHh4v2Bw4SdihM9egyBF8ALIpkEXDR44vA2XwkD/IgYGAAZbbX1nBGRmhl8AWiUJYicC AIsPDFh4LXOGjQ4NAAhrEIUPBQcOqKmoB5sEZV4JqqoHhQVxlGAOJQG4AAunsqg/dw95KwdfBgzB qKIEBMaQDwCiKpOwEIq6KANuJg14igZwEHPULMTGKbxetjF8D1ItxK7aKl8lCl8DAfALW1+2rUi3 QtqgGN2mwYCXzYvAON624LoEQZ9DEfRcEFSBIE2DjyBDfnyIqRgMcA8a/z5AZQWXOxEdHxwUgfIg sX/zMqlAWclVCQFefLpAqdJBAFJn3owgtpJEQkslEWjUmYLnomokcDlS4s0eFzQNqvXDEyzmAwFP yaXYmGJBuxlzELWIacueiE0AFGyF4HbaNTquUEpFRxUFUC9YXQzARYAkEJSNipKQ9kDu0i9SKKNZ 9iXswMIoYgI4oJYFskpgzkkmcdrviELqmPVt1HpRAaaLqCE1lBgjvEpqRtgl8Tevygd7TcCuiKvP m8OVEkAIYLYPThSsRIpEQJr1x94QBIT09FH6QJC6AiRAoB1kEb7tRb4MvyB+AwSlbejfz7+///8A BijggAQWaOCBCCao4A+CDDbo4IMQRijhhBQKGAIAOw== --Apple-Mail=_E43B280A-8D70-47EC-B66D-F06936567049 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green-sig-275518.gif Content-Type: image/gif; name="green-sig-275518.gif" Content-Id: <9205649A-F045-4CC3-93C6-49AB1FCCB58E@us.oracle.com> R0lGODlhLAAcAMQAAP///0x9RHmec9Pf0aa+oleFULHGrmKNW+nv6I+uivT39N7n3W6VZ7zPuZu2 lsjXxYSmfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAsABwAQAXhICCOZGmeaDoaReC+sKAMR7GopIA6boIvLgPAVSAgALxjSYdrOp/Q6NPg YqIEPkTBV2taTwgGbEw+PAZo3FfKbqMQQfeJ8DoY0Hg0wxhAKBgHCl5XLgMqDwFCAAIFPIYDgidr OUQGkSh0cQMJAQyXOXKhoqOkpaanI2aoIwMErq+uCY0BMlANKpxkYwQGBH82TpMicD0pAgQACToD AchqhAG3KQ4HIlQNnErG0IYqB9EAiEQvwEsozC43hy0CAeXMwsLDLS8MAvf497ruCZ+gOA0gfNt3 AIK0J/JWKVzIsEQIADs= --Apple-Mail=_E43B280A-8D70-47EC-B66D-F06936567049-- --Apple-Mail=_58FB2BDD-0F42-49F4-BB8E-DAE3978CDC62-- From nobody Tue Jul 21 05:37:24 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF431A1B46 for ; Tue, 21 Jul 2015 05:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 sj9KgAePsuHf for ; Tue, 21 Jul 2015 05:37:13 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (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 9E2611A1B6A for ; Tue, 21 Jul 2015 05:37:11 -0700 (PDT) Received: by qgeu79 with SMTP id u79so30925363qge.1 for ; Tue, 21 Jul 2015 05:37:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=8EtNl6mqI4ic79S0O66RDX/bI1XXekygAMlJidCfwo4=; b=kNvkkfiUeV36FYWeqcGc/nQsCVbqkYE/a/KuTdMcKhhzgSyMbf6CZf4vIO5bNfZwH8 J2SoreXgKTKmKdeFuctjMc3v93tTlKsZO/wTWUlGvnK7rPG5EcfDteFHgJVBY8gcoVmq JqIg64AqEDObdYVhFoDZ+xZg4cadng7sVQqpmo0CgGdI1bzlZmMoVph+6Z7aTQpOVhOb DWLaeGDrRYYWNPESK8mv2mNTIs0sxyT5U3h+4bJ8tlFkEXFNEYjJW44M/KK8xxZcqDQm 2G4/9+Liok9vXtPo9RnNlQX5owEA2R0PbZCJCIm2fAlfMfX3s8iF/F6opQXJ7f+1RYvL 6Xnw== X-Gm-Message-State: ALoCoQntUodBbXjlVD//7VzNrQJypZ6UOv4x+srCptXy0arjMwCuj2BxSFtUrmHaDKI+41TY84s+ X-Received: by 10.140.92.241 with SMTP id b104mr5773380qge.55.1437482230898; Tue, 21 Jul 2015 05:37:10 -0700 (PDT) Received: from mrichards3-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id g19sm12684492qkh.18.2015.07.21.05.37.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Jul 2015 05:37:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Brian Rosen In-Reply-To: Date: Tue, 21 Jul 2015 14:37:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8CF673E0-EA3D-4932-81AE-8B22564E05BC@brianrosen.net> References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "stir@ietf.org" , "tony@yaanatech.com" Subject: [stir] What to do on a verification failure, was Re: stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:37:22 -0000 If you are passing on the responsibility to decide what to do to the = endpoint, then you might as well have the endpoint do the validation and = decide what to do. Otherwise, the endpoint has to decide how much it trusts whomever it is = currently connected to (roaming, etc) before deciding how to proceed. = After all, an unscrupulous or careless service provider could say = =E2=80=9Cvalidated by someone else=E2=80=9D and not bother doing any = checking at all. We=E2=80=99ve long agreed that the options when validation was completed = by the terminating service provider were accept/drop/forward (possibly = to voicemail) or label, and that labeling was likely a popular choice. = But I think labeling is the called party ID, =E2=80=9Cmissing=E2=80=9D = or =E2=80=9Cinvalid=E2=80=9D and the SP that is passing the labeling is = the source, at least in my opinion. Brian > On Jul 21, 2015, at 2:22 PM, DOLLY, MARTIN C wrote: >=20 > Tony, >=20 > Yes, of course we can take action, like dropping the call, with the = consumers consent. > WTS, what is the criteria? If not the same for all, if not it would be = unmanageable. Also, black lists are not a one size fits all solution. >=20 > I believe the best model is to deliver the call with an indication = that the calling party has been "validated by", and let the consumer to = decide to accept or not. >=20 > Regards, >=20 > Martin >=20 > -----Original Message----- > From: Tony Rutkowski [mailto:tony@yaanatech.com]=20 > Sent: Tuesday, July 21, 2015 8:15 AM > To: DOLLY, MARTIN C; A. Jean Mahoney; stir@ietf.org > Subject: Re: [stir] stir 93 meeting minutes >=20 > Hi Martin, >=20 > It might be worth assessing the "obligation" assertion in light of the = Commission's recently released TCPA Omnibus Declaratory Ruling and = Order. See = https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order > See esp. at para. 152 et. seq. >=20 > The FCC Ruling and Order is arguably a game changer, and the basis for = implementing STIR or equivalent platforms. If you get the customer's = approval, you can drop - unless there is some additional inter carrier = contract obligation. > Although even if there is, the Commission's Order arguably prevails. >=20 > --tony >=20 >=20 > On 2015-07-21 5:31 AM, DOLLY, MARTIN C wrote: >> Martin: If you look at spoof and robocalling, they're typically from = smaller carriers. ATT doesn't trust those carriers like it trusts = Verizon, but we have to interwork with them. It was said on the list a = few times - we cannot just drop calls, we are legally obligated. >>>>=20 >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 21 05:40:40 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCA01A0191 for ; Tue, 21 Jul 2015 05:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EiJoe7-omF7E for ; Tue, 21 Jul 2015 05:40:37 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6A41A00F9 for ; Tue, 21 Jul 2015 05:40:36 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 3cd3ea55.0.2486230.00-2206.7004635.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 21 Jul 2015 12:40:36 +0000 (UTC) X-MXL-Hash: 55ae3dc47d50b264-d89588f0e9607aac204713275f69122c07a61598 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 t6LCeZvj013879; Tue, 21 Jul 2015 08:40:35 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6LCeSjh013769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jul 2015 08:40:30 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 21 Jul 2015 12:40:14 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.71]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0224.002; Tue, 21 Jul 2015 08:40:14 -0400 From: "PFAUTZ, PENN L" To: Travis Russell , "DOLLY, MARTIN C" Thread-Topic: [stir] stir 93 meeting minutes Thread-Index: AQHQw3utMZgnFTQLh06HBTqnCHUU9p3l7BwAgAAtsACAAAIagIAAAsgA//+9/FA= Date: Tue, 21 Jul 2015 12:40:14 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D605853050@MISOUT7MSGUSRDD.ITServices.sbc.com> References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <20B6299A-8D90-4F28-A476-600475B54F2F@oracle.com> In-Reply-To: <20B6299A-8D90-4F28-A476-600475B54F2F@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.69] Content-Type: multipart/related; boundary="_005_38726EDA2109264987B45E29E758C4D605853050MISOUT7MSGUSRDD_"; type="multipart/alternative" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=fcMaPTsF c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=_Je7GUglaHMA:10 a=zOBTX] X-AnalysisOut: [jUuO1YA:10 a=48vgC7mUAAAA:8 a=scBmumm3AAAA:8 a=doUQZJtgAAA] X-AnalysisOut: [A:8 a=z8rW4IgcXWFp5_4KWX4A:9 a=QEXdDO2ut3YA:10 a=5hD8oB5Y4] X-AnalysisOut: [iIA:10 a=gdPDuDx2HKcA:10 a=zXdCyoILPxyrBV3R:21 a=puGJ7KxqY] X-AnalysisOut: [xCTR5kz:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVk] X-AnalysisOut: [A:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-AnalysisOut: [ a=Ff40MY1zf0kb5IEv:21 a=BhwMeNMmUEo7tE5X:21 a=3YRHXNM5vKw] X-AnalysisOut: [eL-5LeO8A:9 a=1Vq_FK4TplAA:10 a=C5A0JFpL4Nh3HFLM:18 a=TlLY] X-AnalysisOut: [x5JQVSE4ltBw37IA:9 a=VmXgTDnjS6QA:10 a=9nbHvumyiLdfXSqt:18] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "stir@ietf.org" , "A. Jean Mahoney" , "tony@yaanatech.com" Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:40:39 -0000 --_005_38726EDA2109264987B45E29E758C4D605853050MISOUT7MSGUSRDD_ Content-Type: multipart/alternative; boundary="_000_38726EDA2109264987B45E29E758C4D605853050MISOUT7MSGUSRDD_" --_000_38726EDA2109264987B45E29E758C4D605853050MISOUT7MSGUSRDD_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByb2JsZW1zIHdpdGggcHJvZmlsZXMgYXJlIDEpIHRoZXkgY2hhbmdlIHNvIHlvdSBhcmUg YWx3YXlzIHBsYXlpbmcgd2hhY2stYS1tb2xlIGFuZCAyKSB0aGV5IGNhbiBpbXBhY3QgbGVnaXQg Y2FsbHMgcHJpb3IgdG8gdGhlIHN0aXIgc29sdXRpb24uDQpJIGhhZCBteSBvZmZpY2UgbnVtYmVy IHNwb29mZWQgd2hpY2ggZm9ydHVuYXRlbHkgaXMgYSBudW1iZXIgbmV2ZXIgYWN0dWFsbHkgc2Vu dCBhcyBjYWxsZXIgSUQgKG9sZCBQQlggdGhhdCBzZW5kcyBhIG1haW4gbnVtYmVyKS4gSWYgYSBu dW1iZXIgaXMgc3Bvb2ZlZCBhbmQgdGhlbiBhIG5ldHdvcmssIGFzIG9wcG9zZWQgdG8gYW4gZW5k IHVzZXIsIGJsb2NrcyBhIGxlZ2l0aW1hdGUgY2FsbCBmb3JtIHRoZSBudW1iZXIgb3duZXIsIG1p Z2h0IHRoZSBjYWxsZXIgc3VlIHRoZSBuZXR3b3JrPyBZb3UgYmV0Y2hhDQoNCkZyb206IHN0aXIg W21haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUcmF2aXMgUnVzc2Vs bA0KU2VudDogVHVlc2RheSwgSnVseSAyMSwgMjAxNSA4OjMyIEFNDQpUbzogRE9MTFksIE1BUlRJ TiBDDQpDYzogc3RpckBpZXRmLm9yZzsgQS4gSmVhbiBNYWhvbmV5OyB0b255QHlhYW5hdGVjaC5j b20NClN1YmplY3Q6IFJlOiBbc3Rpcl0gc3RpciA5MyBtZWV0aW5nIG1pbnV0ZXMNCg0KVGhlcmUg aXMgc29tZSBwb3RlbnRpYWwgZm9yIOKAnHByb2ZpbGluZ+KAnSBzb21lIG9mIHRoZXNlIGNhbGxz LiBGb3IgZXhhbXBsZSwgbG9va2luZyBhdCB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIGEgZ3JvdXAg b2YgY2FsbHMgdG8gZmluZCBjb21tb25hbGl0aWVzIHRoYXQgbWF0Y2ggdGhlIHByb2ZpbGUgb2Yg YSByb2JvY2FsbCAoc29tZXRoaW5nIGJlaW5nIGRvbmUgdG9kYXkpLiBJdHMgbm90IHBlcmZlY3Qs IGJ1dCB1bnRpbCB0aGUgcHJvYmxlbSBvZiBzcG9vZmVkIGlkZW50aXRpZXMgZ2V0cyByZXNvbHZl ZCwgaXRzIHRoZSBiZXN0IG1lYW5zIGZvciBpZGVudGlmeWluZyBwb3NzaWJsZSBudWlzYW5jZSBj YWxscy4gQXMgdGhlc2UgcHJvZmlsZXMgYXJlIGRldmVsb3BlZCwgdGhleSBjYW4gYmUgdXNlZCBp biB0aGUgbmV0d29yayBjb3JlIHRvIGRldGVybWluZSBjYWxsIHRyZWF0bWVudCAoYmxvY2ssIHJv dXRlLCBldGMpLiBUaGlzIGlzIHRoZSBhcHByb2FjaCB0aGF0IG1hbnkgYXJlIHRha2luZyB0b2Rh eS4NCg0KSGF2aW5nIGEg4oCcY2VydOKAnSBmb3IgYSBjYWxsZXIgaWRlbnRpdHkgd291bGQgYWRk IHRvIHRoZSBzdWJzY3JpYmVycyBjb25maWRlbmNlIHRoYXQgYW4gaW5jb21pbmcgY2FsbCBmcm9t IGFuIHVucmVjb2duaXplZCBudW1iZXIgaXMgbGVnaXRpbWF0ZS4NCg0KW2NpZDppbWFnZTAwMS5n aWZAMDFEMEMzOTAuOTM3MzdBMzBdDQoNClRyYXZpcyBSdXNzZWxsIHwgRGlyZWN0b3IsIFByb2R1 Y3QgTWFya2V0aW5nLCBTZXJ2aWNlIFByb3ZpZGVyIE5ldHdvcmtzIHwNCisxOTE5LjIwNS42ODU3 IChvKSB8ICsxOTE5LjQxMi4xMTY3IChjKQ0KDQo1MjAwIFBhcmFtb3VudCBQa3d5DQpNb3JyaXN2 aWxsZSwgTkMgMjc1NjANClVTQQ0KDQpbY2lkOmltYWdlMDAyLmdpZkAwMUQwQzM5MC45MzczN0Ez MF0NCg0KT3JhY2xlIGlzIGNvbW1pdHRlZCB0byBkZXZlbG9waW5nIHByYWN0aWNlcyBhbmQgcHJv ZHVjdHMgdGhhdCBoZWxwIHByb3RlY3QgdGhlIGVudmlyb25tZW50DQoNCg0KDQoNCg0KT24gSnVs IDIxLCAyMDE1LCBhdCA4OjIyIEFNLCBET0xMWSwgTUFSVElOIEMgPG1kMzEzNUBhdHQuY29tPG1h aWx0bzptZDMxMzVAYXR0LmNvbT4+IHdyb3RlOg0KDQpUb255LA0KDQpZZXMsIG9mIGNvdXJzZSB3 ZSBjYW4gdGFrZSBhY3Rpb24sIGxpa2UgZHJvcHBpbmcgdGhlIGNhbGwsIHdpdGggdGhlIGNvbnN1 bWVycyBjb25zZW50Lg0KV1RTLCB3aGF0IGlzIHRoZSBjcml0ZXJpYT8gSWYgbm90IHRoZSBzYW1l IGZvciBhbGwsIGlmIG5vdCBpdCB3b3VsZCBiZSB1bm1hbmFnZWFibGUuIEFsc28sIGJsYWNrIGxp c3RzIGFyZSBub3QgYSBvbmUgc2l6ZSBmaXRzIGFsbCBzb2x1dGlvbi4NCg0KSSBiZWxpZXZlIHRo ZSBiZXN0IG1vZGVsIGlzIHRvIGRlbGl2ZXIgdGhlIGNhbGwgd2l0aCBhbiBpbmRpY2F0aW9uIHRo YXQgdGhlIGNhbGxpbmcgcGFydHkgaGFzIGJlZW4gInZhbGlkYXRlZCBieSIsIGFuZCBsZXQgdGhl IGNvbnN1bWVyIHRvIGRlY2lkZSB0byBhY2NlcHQgb3Igbm90Lg0KDQpSZWdhcmRzLA0KDQpNYXJ0 aW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRvbnkgUnV0a293c2tpIFtt YWlsdG86dG9ueUB5YWFuYXRlY2guY29tXQ0KU2VudDogVHVlc2RheSwgSnVseSAyMSwgMjAxNSA4 OjE1IEFNDQpUbzogRE9MTFksIE1BUlRJTiBDOyBBLiBKZWFuIE1haG9uZXk7IHN0aXJAaWV0Zi5v cmc8bWFpbHRvOnN0aXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3N0aXJdIHN0aXIgOTMgbWVl dGluZyBtaW51dGVzDQoNCkhpIE1hcnRpbiwNCg0KSXQgbWlnaHQgYmUgd29ydGggYXNzZXNzaW5n IHRoZSAib2JsaWdhdGlvbiIgYXNzZXJ0aW9uIGluIGxpZ2h0IG9mIHRoZSBDb21taXNzaW9uJ3Mg cmVjZW50bHkgcmVsZWFzZWQgVENQQSBPbW5pYnVzIERlY2xhcmF0b3J5IFJ1bGluZyBhbmQgT3Jk ZXIuICBTZWUgaHR0cHM6Ly93d3cuZmNjLmdvdi9kb2N1bWVudC90Y3BhLW9tbmlidXMtZGVjbGFy YXRvcnktcnVsaW5nLWFuZC1vcmRlcg0KU2VlIGVzcC4gYXQgcGFyYS4gMTUyIGV0LiBzZXEuDQoN ClRoZSBGQ0MgUnVsaW5nIGFuZCBPcmRlciBpcyBhcmd1YWJseSBhIGdhbWUgY2hhbmdlciwgYW5k IHRoZSBiYXNpcyBmb3IgaW1wbGVtZW50aW5nIFNUSVIgb3IgZXF1aXZhbGVudCBwbGF0Zm9ybXMu ICBJZiB5b3UgZ2V0IHRoZSBjdXN0b21lcidzIGFwcHJvdmFsLCB5b3UgY2FuIGRyb3AgLSB1bmxl c3MgdGhlcmUgaXMgc29tZSBhZGRpdGlvbmFsIGludGVyIGNhcnJpZXIgY29udHJhY3Qgb2JsaWdh dGlvbi4NCkFsdGhvdWdoIGV2ZW4gaWYgdGhlcmUgaXMsIHRoZSBDb21taXNzaW9uJ3MgT3JkZXIg YXJndWFibHkgcHJldmFpbHMuDQoNCi0tdG9ueQ0KDQoNCk9uIDIwMTUtMDctMjEgNTozMSBBTSwg RE9MTFksIE1BUlRJTiBDIHdyb3RlOg0KDQpNYXJ0aW46IElmIHlvdSBsb29rIGF0IHNwb29mIGFu ZCByb2JvY2FsbGluZywgdGhleSdyZSB0eXBpY2FsbHkgZnJvbSBzbWFsbGVyIGNhcnJpZXJzLiBB VFQgZG9lc24ndCB0cnVzdCB0aG9zZSBjYXJyaWVycyBsaWtlIGl0IHRydXN0cyBWZXJpem9uLCBi dXQgd2UgaGF2ZSB0byBpbnRlcndvcmsgd2l0aCB0aGVtLiBJdCB3YXMgc2FpZCBvbiB0aGUgbGlz dCBhIGZldyB0aW1lcyAtIHdlIGNhbm5vdCBqdXN0IGRyb3AgY2FsbHMsIHdlIGFyZSBsZWdhbGx5 IG9ibGlnYXRlZC4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kc3RpciBtYWlsaW5nIGxpc3QNCnN0aXJAaWV0Zi5vcmc8bWFpbHRvOnN0 aXJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXIN Cg0K --_000_38726EDA2109264987B45E29E758C4D605853050MISOUT7MSGUSRDD_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBwcm9ibGVt cyB3aXRoIHByb2ZpbGVzIGFyZSAxKSB0aGV5IGNoYW5nZSBzbyB5b3UgYXJlIGFsd2F5cyBwbGF5 aW5nIHdoYWNrLWEtbW9sZSBhbmQgMikgdGhleSBjYW4gaW1wYWN0IGxlZ2l0IGNhbGxzIHByaW9y IHRvIHRoZSBzdGlyIHNvbHV0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgaGFkIG15IG9mZmlj ZSBudW1iZXIgc3Bvb2ZlZCB3aGljaCBmb3J0dW5hdGVseSBpcyBhIG51bWJlciBuZXZlciBhY3R1 YWxseSBzZW50IGFzIGNhbGxlciBJRCAob2xkIFBCWCB0aGF0IHNlbmRzIGEgbWFpbiBudW1iZXIp LiBJZiBhIG51bWJlciBpcyBzcG9vZmVkIGFuZCB0aGVuDQogYSBuZXR3b3JrLCBhcyBvcHBvc2Vk IHRvIGFuIGVuZCB1c2VyLCBibG9ja3MgYSBsZWdpdGltYXRlIGNhbGwgZm9ybSB0aGUgbnVtYmVy IG93bmVyLCBtaWdodCB0aGUgY2FsbGVyIHN1ZSB0aGUgbmV0d29yaz8gWW91IGJldGNoYTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gc3RpciBbbWFpbHRvOnN0aXIt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VHJhdmlzIFJ1c3NlbGw8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyMSwgMjAxNSA4OjMyIEFNPGJyPg0KPGI+VG86 PC9iPiBET0xMWSwgTUFSVElOIEM8YnI+DQo8Yj5DYzo8L2I+IHN0aXJAaWV0Zi5vcmc7IEEuIEpl YW4gTWFob25leTsgdG9ueUB5YWFuYXRlY2guY29tPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb c3Rpcl0gc3RpciA5MyBtZWV0aW5nIG1pbnV0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBzb21lIHBvdGVudGlhbCBmb3Ig4oCccHJvZmls aW5n4oCdIHNvbWUgb2YgdGhlc2UgY2FsbHMuIEZvciBleGFtcGxlLCBsb29raW5nIGF0IHRoZSBj aGFyYWN0ZXJpc3RpY3Mgb2YgYSBncm91cCBvZiBjYWxscyB0byBmaW5kIGNvbW1vbmFsaXRpZXMg dGhhdCBtYXRjaCB0aGUgcHJvZmlsZSBvZiBhIHJvYm9jYWxsIChzb21ldGhpbmcgYmVpbmcgZG9u ZSB0b2RheSkuIEl0cyBub3QgcGVyZmVjdCwgYnV0IHVudGlsDQogdGhlIHByb2JsZW0gb2Ygc3Bv b2ZlZCBpZGVudGl0aWVzIGdldHMgcmVzb2x2ZWQsIGl0cyB0aGUgYmVzdCBtZWFucyBmb3IgaWRl bnRpZnlpbmcgcG9zc2libGUgbnVpc2FuY2UgY2FsbHMuIEFzIHRoZXNlIHByb2ZpbGVzIGFyZSBk ZXZlbG9wZWQsIHRoZXkgY2FuIGJlIHVzZWQgaW4gdGhlIG5ldHdvcmsgY29yZSB0byBkZXRlcm1p bmUgY2FsbCB0cmVhdG1lbnQgKGJsb2NrLCByb3V0ZSwgZXRjKS4gVGhpcyBpcyB0aGUgYXBwcm9h Y2ggdGhhdCBtYW55DQogYXJlIHRha2luZyB0b2RheS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhdmluZyBhIOKAnGNlcnTigJ0gZm9yIGEgY2Fs bGVyIGlkZW50aXR5IHdvdWxkIGFkZCB0byB0aGUgc3Vic2NyaWJlcnMgY29uZmlkZW5jZSB0aGF0 IGFuIGluY29taW5nIGNhbGwgZnJvbSBhbiB1bnJlY29nbml6ZWQgbnVtYmVyIGlzIGxlZ2l0aW1h dGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxp bWcgd2lkdGg9IjExNCIgaGVpZ2h0PSIyNiIgaWQ9Il94MDAzN18xOTE4MEZCLTgwNkItNDExMy1C NDlFLUYzMjcyQzkyREIxOCIgc3JjPSJjaWQ6aW1hZ2UwMDEuZ2lmQDAxRDBDMzkwLjkzNzM3QTMw IiBhbHQ9ImNpZDppbWFnZTAwMS5naWZAMDFEMEMzOTAuOTM3MzdBMzAiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NClRyYXZpcyBSdXNzZWxsIHwgRGlyZWN0b3IsIFBy b2R1Y3QmbmJzcDtNYXJrZXRpbmcsIFNlcnZpY2UgUHJvdmlkZXImbmJzcDtOZXR3b3JrcyZuYnNw O3wmbmJzcDs8YnI+DQomIzQzOzE5MTkuMjA1LjY4NTcgKG8pIHwmbmJzcDsmIzQzOzE5MTkuNDEy LjExNjcgKGMpPGJyPg0KPGJyPg0KNTIwMCBQYXJhbW91bnQgUGt3eTxicj4NCk1vcnJpc3ZpbGxl LCBOQyAyNzU2MDxicj4NClVTQTxicj4NCjxicj4NCjxpbWcgd2lkdGg9IjQ0IiBoZWlnaHQ9IjI4 IiBpZD0iQzg4MzREOEYtMjFGNC00QURFLThDM0YtOTg0RUEyNEVCOTVEIiBzcmM9ImNpZDppbWFn ZTAwMi5naWZAMDFEMEMzOTAuOTM3MzdBMzAiIGFsdD0iY2lkOmltYWdlMDAyLmdpZkAwMUQwQzM5 MC45MzczN0EzMCI+PGJyPg0KPGJyPg0KT3JhY2xlIGlzIGNvbW1pdHRlZCB0byBkZXZlbG9waW5n IHByYWN0aWNlcyZuYnNwO2FuZCBwcm9kdWN0cyB0aGF0IGhlbHAgcHJvdGVjdCB0aGUmbmJzcDtl bnZpcm9ubWVudDxicj4NCjxicj4NCjxicj4NCjxiciBzdHlsZT0ib3JwaGFuczogYXV0bzt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAyMSwgMjAxNSwgYXQgODoyMiBBTSwgRE9M TFksIE1BUlRJTiBDICZsdDs8YSBocmVmPSJtYWlsdG86bWQzMTM1QGF0dC5jb20iPm1kMzEzNUBh dHQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRvbnksPGJyPg0KPGJyPg0KWWVzLCBvZiBjb3Vyc2Ugd2UgY2FuIHRha2UgYWN0aW9uLCBs aWtlIGRyb3BwaW5nIHRoZSBjYWxsLCB3aXRoIHRoZSBjb25zdW1lcnMgY29uc2VudC48YnI+DQpX VFMsIHdoYXQgaXMgdGhlIGNyaXRlcmlhPyBJZiBub3QgdGhlIHNhbWUgZm9yIGFsbCwgaWYgbm90 IGl0IHdvdWxkIGJlIHVubWFuYWdlYWJsZS4gQWxzbywgYmxhY2sgbGlzdHMgYXJlIG5vdCBhIG9u ZSBzaXplIGZpdHMgYWxsIHNvbHV0aW9uLjxicj4NCjxicj4NCkkgYmVsaWV2ZSB0aGUgYmVzdCBt b2RlbCBpcyB0byBkZWxpdmVyIHRoZSBjYWxsIHdpdGggYW4gaW5kaWNhdGlvbiB0aGF0IHRoZSBj YWxsaW5nIHBhcnR5IGhhcyBiZWVuICZxdW90O3ZhbGlkYXRlZCBieSZxdW90OywgYW5kIGxldCB0 aGUgY29uc3VtZXIgdG8gZGVjaWRlIHRvIGFjY2VwdCBvciBub3QuPGJyPg0KPGJyPg0KUmVnYXJk cyw8YnI+DQo8YnI+DQpNYXJ0aW48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IFRvbnkgUnV0a293c2tpIFs8YSBocmVmPSJtYWlsdG86dG9ueUB5YWFuYXRl Y2guY29tIj5tYWlsdG86dG9ueUB5YWFuYXRlY2guY29tPC9hPl0NCjxicj4NClNlbnQ6IFR1ZXNk YXksIEp1bHkgMjEsIDIwMTUgODoxNSBBTTxicj4NClRvOiBET0xMWSwgTUFSVElOIEM7IEEuIEpl YW4gTWFob25leTsgPGEgaHJlZj0ibWFpbHRvOnN0aXJAaWV0Zi5vcmciPnN0aXJAaWV0Zi5vcmc8 L2E+PGJyPg0KU3ViamVjdDogUmU6IFtzdGlyXSBzdGlyIDkzIG1lZXRpbmcgbWludXRlczxicj4N Cjxicj4NCkhpIE1hcnRpbiw8YnI+DQo8YnI+DQpJdCBtaWdodCBiZSB3b3J0aCBhc3Nlc3Npbmcg dGhlICZxdW90O29ibGlnYXRpb24mcXVvdDsgYXNzZXJ0aW9uIGluIGxpZ2h0IG9mIHRoZSBDb21t aXNzaW9uJ3MgcmVjZW50bHkgcmVsZWFzZWQgVENQQSBPbW5pYnVzIERlY2xhcmF0b3J5IFJ1bGlu ZyBhbmQgT3JkZXIuICZuYnNwO1NlZQ0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuZmNjLmdvdi9kb2N1 bWVudC90Y3BhLW9tbmlidXMtZGVjbGFyYXRvcnktcnVsaW5nLWFuZC1vcmRlciI+DQpodHRwczov L3d3dy5mY2MuZ292L2RvY3VtZW50L3RjcGEtb21uaWJ1cy1kZWNsYXJhdG9yeS1ydWxpbmctYW5k LW9yZGVyPC9hPjxicj4NClNlZSBlc3AuIGF0IHBhcmEuIDE1MiBldC4gc2VxLjxicj4NCjxicj4N ClRoZSBGQ0MgUnVsaW5nIGFuZCBPcmRlciBpcyBhcmd1YWJseSBhIGdhbWUgY2hhbmdlciwgYW5k IHRoZSBiYXNpcyBmb3IgaW1wbGVtZW50aW5nIFNUSVIgb3IgZXF1aXZhbGVudCBwbGF0Zm9ybXMu ICZuYnNwO0lmIHlvdSBnZXQgdGhlIGN1c3RvbWVyJ3MgYXBwcm92YWwsIHlvdSBjYW4gZHJvcCAt IHVubGVzcyB0aGVyZSBpcyBzb21lIGFkZGl0aW9uYWwgaW50ZXIgY2FycmllciBjb250cmFjdCBv YmxpZ2F0aW9uLjxicj4NCkFsdGhvdWdoIGV2ZW4gaWYgdGhlcmUgaXMsIHRoZSBDb21taXNzaW9u J3MgT3JkZXIgYXJndWFibHkgcHJldmFpbHMuPGJyPg0KPGJyPg0KLS10b255PGJyPg0KPGJyPg0K PGJyPg0KT24gMjAxNS0wNy0yMSA1OjMxIEFNLCBET0xMWSwgTUFSVElOIEMgd3JvdGU6PGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcnRpbjogSWYg eW91IGxvb2sgYXQgc3Bvb2YgYW5kIHJvYm9jYWxsaW5nLCB0aGV5J3JlIHR5cGljYWxseSBmcm9t IHNtYWxsZXIgY2FycmllcnMuIEFUVCBkb2Vzbid0IHRydXN0IHRob3NlIGNhcnJpZXJzIGxpa2Ug aXQgdHJ1c3RzIFZlcml6b24sIGJ1dCB3ZSBoYXZlIHRvIGludGVyd29yayB3aXRoIHRoZW0uIEl0 IHdhcyBzYWlkIG9uIHRoZSBsaXN0IGEgZmV3IHRpbWVzIC0gd2UgY2Fubm90IGp1c3QgZHJvcA0K IGNhbGxzLCB3ZSBhcmUgbGVnYWxseSBvYmxpZ2F0ZWQuPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCnN0aXIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OnN0aXJAaWV0Zi5vcmciPnN0aXJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3N0aXI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_38726EDA2109264987B45E29E758C4D605853050MISOUT7MSGUSRDD_-- --_005_38726EDA2109264987B45E29E758C4D605853050MISOUT7MSGUSRDD_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=658; creation-date="Tue, 21 Jul 2015 12:40:13 GMT"; modification-date="Tue, 21 Jul 2015 12:40:13 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgAaAMQAAP8QEP/w8P/Q0P/g4P8wMP9gYP8gIP+goP9QUP+QkP+wsP9wcP+AgP9AQP/A wP8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAByABoAAAX/ICSOZGmeaKqubOu+cCzPdC0GCqPvvBKUDp5wp1gFdIPVIDfcOQa6A8yR aO4gweQoUHh4v2Bw4SdihM9egyBF8ALIpkEXDR44vA2XwkD/IgYGAAZbbX1nBGRmhl8AWiUJYicC AIsPDFh4LXOGjQ4NAAhrEIUPBQcOqKmoB5sEZV4JqqoHhQVxlGAOJQG4AAunsqg/dw95KwdfBgzB qKIEBMaQDwCiKpOwEIq6KANuJg14igZwEHPULMTGKbxetjF8D1ItxK7aKl8lCl8DAfALW1+2rUi3 QtqgGN2mwYCXzYvAON624LoEQZ9DEfRcEFSBIE2DjyBDfnyIqRgMcA8a/z5AZQWXOxEdHxwUgfIg sX/zMqlAWclVCQFefLpAqdJBAFJn3owgtpJEQkslEWjUmYLnomokcDlS4s0eFzQNqvXDEyzmAwFP yaXYmGJBuxlzELWIacueiE0AFGyF4HbaNTquUEpFRxUFUC9YXQzARYAkEJSNipKQ9kDu0i9SKKNZ 9iXswMIoYgI4oJYFskpgzkkmcdrviELqmPVt1HpRAaaLqCE1lBgjvEpqRtgl8Tevygd7TcCuiKvP m8OVEkAIYLYPThSsRIpEQJr1x94QBIT09FH6QJC6AiRAoB1kEb7tRb4MvyB+AwSlbejfz7+///8A BijggAQWaOCBCCao4A+CDDbo4IMQRijhhBQKGAIAOw== --_005_38726EDA2109264987B45E29E758C4D605853050MISOUT7MSGUSRDD_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=356; creation-date="Tue, 21 Jul 2015 12:40:13 GMT"; modification-date="Tue, 21 Jul 2015 12:40:13 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhLAAcAMQAAP///0x9RHmec9Pf0aa+oleFULHGrmKNW+nv6I+uivT39N7n3W6VZ7zPuZu2 lsjXxYSmfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAsABwAQAXhICCOZGmeaDoaReC+sKAMR7GopIA6boIvLgPAVSAgALxjSYdrOp/Q6NPg YqIEPkTBV2taTwgGbEw+PAZo3FfKbqMQQfeJ8DoY0Hg0wxhAKBgHCl5XLgMqDwFCAAIFPIYDgidr OUQGkSh0cQMJAQyXOXKhoqOkpaanI2aoIwMErq+uCY0BMlANKpxkYwQGBH82TpMicD0pAgQACToD AchqhAG3KQ4HIlQNnErG0IYqB9EAiEQvwEsozC43hy0CAeXMwsLDLS8MAvf497ruCZ+gOA0gfNt3 AIK0J/JWKVzIsEQIADs= --_005_38726EDA2109264987B45E29E758C4D605853050MISOUT7MSGUSRDD_-- From nobody Tue Jul 21 05:43:59 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B030F1A00F9 for ; Tue, 21 Jul 2015 05:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 APT4ew4iuFwP for ; Tue, 21 Jul 2015 05:43:54 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 D566F1A1B92 for ; Tue, 21 Jul 2015 05:43:52 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id DB8BF94351E24; Tue, 21 Jul 2015 12:43:48 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6LCho5P025736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 14:43:51 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 14:43:50 +0200 From: "DRAGE, Keith (Keith)" To: "DOLLY, MARTIN C" , "tony@yaanatech.com" , "A. Jean Mahoney" , "stir@ietf.org" Thread-Topic: [stir] stir 93 meeting minutes Thread-Index: AQHQw3uqjkqRWgwj1UCIqZaGwdMW/53l1s9P///ggoCAACZQ4A== Date: Tue, 21 Jul 2015 12:43:49 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69747E3A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:43:57 -0000 In terms of recipient handling, surely all the considerations that currentl= y apply to handling anonymous calls also apply to calls where the identity = cannot be validated. Many networks already offer features where the called user can elect to aut= omatically reject anonymous calls (as opposed to calls where the identity c= ould not be passed for interoperability reasons). Keith > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C > Sent: 21 July 2015 13:22 > To: tony@yaanatech.com; A. Jean Mahoney; stir@ietf.org > Subject: Re: [stir] stir 93 meeting minutes >=20 > Tony, >=20 > Yes, of course we can take action, like dropping the call,=20 > with the consumers consent. > WTS, what is the criteria? If not the same for all, if not it=20 > would be unmanageable. Also, black lists are not a one size=20 > fits all solution. >=20 > I believe the best model is to deliver the call with an=20 > indication that the calling party has been "validated by",=20 > and let the consumer to decide to accept or not. >=20 > Regards, >=20 > Martin >=20 > -----Original Message----- > From: Tony Rutkowski [mailto:tony@yaanatech.com] > Sent: Tuesday, July 21, 2015 8:15 AM > To: DOLLY, MARTIN C; A. Jean Mahoney; stir@ietf.org > Subject: Re: [stir] stir 93 meeting minutes >=20 > Hi Martin, >=20 > It might be worth assessing the "obligation" assertion in=20 > light of the Commission's recently released TCPA Omnibus=20 > Declaratory Ruling and Order. See=20 > https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order > See esp. at para. 152 et. seq. >=20 > The FCC Ruling and Order is arguably a game changer, and the=20 > basis for implementing STIR or equivalent platforms. If you=20 > get the customer's approval, you can drop - unless there is=20 > some additional inter carrier contract obligation. > Although even if there is, the Commission's Order arguably prevails. >=20 > --tony >=20 >=20 > On 2015-07-21 5:31 AM, DOLLY, MARTIN C wrote: > > Martin: If you look at spoof and robocalling, they're=20 > typically from smaller carriers. ATT doesn't trust those=20 > carriers like it trusts Verizon, but we have to interwork=20 > with them. It was said on the list a few times - we cannot=20 > just drop calls, we are legally obligated. > >> > >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > = From nobody Tue Jul 21 05:44:41 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242C21A00F9 for ; Tue, 21 Jul 2015 05:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 pv8TBu4BkmJl for ; Tue, 21 Jul 2015 05:44:28 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 513C31A1B92 for ; Tue, 21 Jul 2015 05:44:28 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t6LCiPX1027076 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jul 2015 12:44:25 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t6LCiOk2011342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Jul 2015 12:44:24 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t6LCiOOP029187; Tue, 21 Jul 2015 12:44:24 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-152-107.vpn.oracle.com (/10.154.152.107) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Jul 2015 05:44:24 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_622DF7F8-572E-4401-9BB6-50339FCBF14E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Travis Russell In-Reply-To: <38726EDA2109264987B45E29E758C4D605853050@MISOUT7MSGUSRDD.ITServices.sbc.com> Date: Tue, 21 Jul 2015 08:44:25 -0400 Message-Id: References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <20B6299A-8D90-4F28-A476-600475B54F2F@oracle.com> <38726EDA2109264987B45E29E758C4D605853050@MISOUT7MSGUSRDD.ITServices.sbc.com> To: "PFAUTZ, PENN L" X-Mailer: Apple Mail (2.2102) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "stir@ietf.org" , "tony@yaanatech.com" , "DOLLY, MARTIN C" , "A. Jean Mahoney" Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:44:31 -0000 --Apple-Mail=_622DF7F8-572E-4401-9BB6-50339FCBF14E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes you are absolutely correct. Profiling therefore cannot take into = account the calling party number. Instead, other characteristics have to = be considered. For example, one variation of a robocall is an automated = call that rings once and hangs up (hoping the subscriber calls back the = missed call). Looking at the signaling one can find: Short duration calls Released by calling party Possibly calling party originated a number of other calls in a range or = randomly Volume of calls from calling party exceeds a certain threshold etc. This is the technique being used today in fraud departments to identify = suspect calls, where again, the calling party number cannot be the key. Travis Russell | Director, Product Marketing, Service Provider Networks = |=20 +1919.205.6857 (o) | +1919.412.1167 (c) 5200 Paramount Pkwy Morrisville, NC 27560 USA Oracle is committed to developing practices and products that help = protect the environment > On Jul 21, 2015, at 8:40 AM, PFAUTZ, PENN L wrote: >=20 > The problems with profiles are 1) they change so you are always = playing whack-a-mole and 2) they can impact legit calls prior to the = stir solution. > I had my office number spoofed which fortunately is a number never = actually sent as caller ID (old PBX that sends a main number). If a = number is spoofed and then a network, as opposed to an end user, blocks = a legitimate call form the number owner, might the caller sue the = network? You betcha > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Travis Russell > Sent: Tuesday, July 21, 2015 8:32 AM > To: DOLLY, MARTIN C > Cc: stir@ietf.org; A. Jean Mahoney; tony@yaanatech.com > Subject: Re: [stir] stir 93 meeting minutes > =20 > There is some potential for =E2=80=9Cprofiling=E2=80=9D some of these = calls. For example, looking at the characteristics of a group of calls = to find commonalities that match the profile of a robocall (something = being done today). Its not perfect, but until the problem of spoofed = identities gets resolved, its the best means for identifying possible = nuisance calls. As these profiles are developed, they can be used in the = network core to determine call treatment (block, route, etc). This is = the approach that many are taking today.=20 > =20 > Having a =E2=80=9Ccert=E2=80=9D for a caller identity would add to the = subscribers confidence that an incoming call from an unrecognized number = is legitimate.=20 > =20 > >=20 > Travis Russell | Director, Product Marketing, Service Provider = Networks |=20 > +1919.205.6857 (o) | +1919.412.1167 (c) >=20 > 5200 Paramount Pkwy > Morrisville, NC 27560 > USA >=20 > >=20 > Oracle is committed to developing practices and products that help = protect the environment >=20 >=20 >=20 >=20 > =20 > On Jul 21, 2015, at 8:22 AM, DOLLY, MARTIN C > wrote: > =20 > Tony, >=20 > Yes, of course we can take action, like dropping the call, with the = consumers consent. > WTS, what is the criteria? If not the same for all, if not it would be = unmanageable. Also, black lists are not a one size fits all solution. >=20 > I believe the best model is to deliver the call with an indication = that the calling party has been "validated by", and let the consumer to = decide to accept or not. >=20 > Regards, >=20 > Martin >=20 > -----Original Message----- > From: Tony Rutkowski [mailto:tony@yaanatech.com = ]=20 > Sent: Tuesday, July 21, 2015 8:15 AM > To: DOLLY, MARTIN C; A. Jean Mahoney; stir@ietf.org = > Subject: Re: [stir] stir 93 meeting minutes >=20 > Hi Martin, >=20 > It might be worth assessing the "obligation" assertion in light of the = Commission's recently released TCPA Omnibus Declaratory Ruling and = Order. = Seehttps://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order = > See esp. at para. 152 et. seq. >=20 > The FCC Ruling and Order is arguably a game changer, and the basis for = implementing STIR or equivalent platforms. If you get the customer's = approval, you can drop - unless there is some additional inter carrier = contract obligation. > Although even if there is, the Commission's Order arguably prevails. >=20 > --tony >=20 >=20 > On 2015-07-21 5:31 AM, DOLLY, MARTIN C wrote: >=20 > Martin: If you look at spoof and robocalling, they're typically from = smaller carriers. ATT doesn't trust those carriers like it trusts = Verizon, but we have to interwork with them. It was said on the list a = few times - we cannot just drop calls, we are legally obligated. >=20 > =20 >=20 >=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 --Apple-Mail=_622DF7F8-572E-4401-9BB6-50339FCBF14E Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_F77972BD-354D-4112-80A8-9E607EC37AE2" --Apple-Mail=_F77972BD-354D-4112-80A8-9E607EC37AE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes you are absolutely correct. Profiling therefore cannot = take into account the calling party number. Instead, other = characteristics have to be considered. For example, one variation of a = robocall is an automated call that rings once and hangs up (hoping the = subscriber calls back the missed call). Looking at the signaling one can = find:
  • Short = duration calls
  • Released by calling party
  • Possibly calling party originated a number of other calls in = a range or randomly
  • Volume of calls from calling = party exceeds a certain threshold
  • etc.

This is the technique = being used today in fraud departments to identify suspect calls, where = again, the calling party number cannot be the key.



Travis Russell | Director, = Product Marketing, Service Provider Networks | 
+1919.205.6857 (o) = | +1919.412.1167 = (c)

5200 Paramount Pkwy
Morrisville, NC 27560
USA



Oracle is committed to developing = practices and products that help protect the environment



On Jul 21, 2015, at 8:40 AM, PFAUTZ, PENN L <pp3129@att.com> = wrote:

The problems with profiles are 1) they change so = you are always playing whack-a-mole and 2) they can impact legit calls = prior to the stir solution.

I had my office number spoofed which fortunately is = a number never actually sent as caller ID (old PBX that sends a main = number). If a number is spoofed and then a network, as opposed to an end user, blocks a legitimate call form the = number owner, might the caller sue the network? You betcha

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Travis Russell
Sent: Tuesday, July 21, 2015 8:32 AM
To: DOLLY, MARTIN C
Cc: stir@ietf.org; A. Jean Mahoney; tony@yaanatech.com
Subject: Re: [stir] stir 93 meeting minutes

 

There is some potential for =E2=80=9Cprofiling=E2=80=9D= some of these calls. For example, looking at the characteristics of a = group of calls to find commonalities that match the profile of a = robocall (something being done today). Its not perfect, but until the problem of spoofed identities gets resolved, its the best means for = identifying possible nuisance calls. As these profiles are developed, = they can be used in the network core to determine call treatment (block, = route, etc). This is the approach that many are taking today. 

 

Having a =E2=80=9Ccert=E2=80=9D = for a caller identity would add to the subscribers confidence that an = incoming call from an unrecognized number is legitimate. 

 

<image001.gif>

Travis Russell | Director, Product Marketing, Service = Provider Networks | 
+1919.205.6857 (o) | +1919.412.1167 (c)

5200 Paramount Pkwy
Morrisville, NC 27560
USA

<image002.gif>

Oracle is committed to developing practices and products that help = protect the environment




 

On Jul 21, 2015, at 8:22 AM, = DOLLY, MARTIN C <md3135@att.com> wrote:

 

Tony,

Yes, of course we can take action, like dropping the call, with the = consumers consent.
WTS, what is the criteria? If not the same for all, if not it would be = unmanageable. Also, black lists are not a one size fits all solution.

I believe the best model is to deliver the call with an indication that = the calling party has been "validated by", and let the consumer to = decide to accept or not.

Regards,

Martin

-----Original Message-----
From: Tony Rutkowski [mailto:tony@yaanatech.com]
Sent: Tuesday, July 21, 2015 8:15 AM
To: DOLLY, MARTIN C; A. Jean Mahoney; stir@ietf.org
Subject: Re: [stir] stir 93 meeting minutes

Hi Martin,

It might be worth assessing the "obligation" assertion in light of the = Commission's recently released TCPA Omnibus Declaratory Ruling and = Order.  See = https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order=
See esp. at para. 152 et. seq.

The FCC Ruling and Order is arguably a game changer, and the basis for = implementing STIR or equivalent platforms.  If you get the = customer's approval, you can drop - unless there is some additional = inter carrier contract obligation.
Although even if there is, the Commission's Order arguably prevails.

--tony


On 2015-07-21 5:31 AM, DOLLY, MARTIN C wrote:

Martin: If you look at spoof and robocalling, = they're typically from smaller carriers. ATT doesn't trust those = carriers like it trusts Verizon, but we have to interwork with them. It = was said on the list a few times - we cannot just drop calls, we are legally obligated.

 




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

 

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

= --Apple-Mail=_F77972BD-354D-4112-80A8-9E607EC37AE2 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=oracle-email-sig-198324.gif Content-Type: image/gif; name="oracle-email-sig-198324.gif" Content-Id: R0lGODlhcgAaAMQAAP8QEP/w8P/Q0P/g4P8wMP9gYP8gIP+goP9QUP+QkP+wsP9wcP+AgP9AQP/A wP8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAByABoAAAX/ICSOZGmeaKqubOu+cCzPdC0GCqPvvBKUDp5wp1gFdIPVIDfcOQa6A8yR aO4gweQoUHh4v2Bw4SdihM9egyBF8ALIpkEXDR44vA2XwkD/IgYGAAZbbX1nBGRmhl8AWiUJYicC AIsPDFh4LXOGjQ4NAAhrEIUPBQcOqKmoB5sEZV4JqqoHhQVxlGAOJQG4AAunsqg/dw95KwdfBgzB qKIEBMaQDwCiKpOwEIq6KANuJg14igZwEHPULMTGKbxetjF8D1ItxK7aKl8lCl8DAfALW1+2rUi3 QtqgGN2mwYCXzYvAON624LoEQZ9DEfRcEFSBIE2DjyBDfnyIqRgMcA8a/z5AZQWXOxEdHxwUgfIg sX/zMqlAWclVCQFefLpAqdJBAFJn3owgtpJEQkslEWjUmYLnomokcDlS4s0eFzQNqvXDEyzmAwFP yaXYmGJBuxlzELWIacueiE0AFGyF4HbaNTquUEpFRxUFUC9YXQzARYAkEJSNipKQ9kDu0i9SKKNZ 9iXswMIoYgI4oJYFskpgzkkmcdrviELqmPVt1HpRAaaLqCE1lBgjvEpqRtgl8Tevygd7TcCuiKvP m8OVEkAIYLYPThSsRIpEQJr1x94QBIT09FH6QJC6AiRAoB1kEb7tRb4MvyB+AwSlbejfz7+///8A BijggAQWaOCBCCao4A+CDDbo4IMQRijhhBQKGAIAOw== --Apple-Mail=_F77972BD-354D-4112-80A8-9E607EC37AE2 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green-sig-275518.gif Content-Type: image/gif; name="green-sig-275518.gif" Content-Id: <9205649A-F045-4CC3-93C6-49AB1FCCB58E@us.oracle.com> R0lGODlhLAAcAMQAAP///0x9RHmec9Pf0aa+oleFULHGrmKNW+nv6I+uivT39N7n3W6VZ7zPuZu2 lsjXxYSmfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAsABwAQAXhICCOZGmeaDoaReC+sKAMR7GopIA6boIvLgPAVSAgALxjSYdrOp/Q6NPg YqIEPkTBV2taTwgGbEw+PAZo3FfKbqMQQfeJ8DoY0Hg0wxhAKBgHCl5XLgMqDwFCAAIFPIYDgidr OUQGkSh0cQMJAQyXOXKhoqOkpaanI2aoIwMErq+uCY0BMlANKpxkYwQGBH82TpMicD0pAgQACToD AchqhAG3KQ4HIlQNnErG0IYqB9EAiEQvwEsozC43hy0CAeXMwsLDLS8MAvf497ruCZ+gOA0gfNt3 AIK0J/JWKVzIsEQIADs= --Apple-Mail=_F77972BD-354D-4112-80A8-9E607EC37AE2-- --Apple-Mail=_622DF7F8-572E-4401-9BB6-50339FCBF14E-- From nobody Tue Jul 21 05:47:33 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B2F1A1BFE for ; Tue, 21 Jul 2015 05:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7Met_RFIQxW9 for ; Tue, 21 Jul 2015 05:47:28 -0700 (PDT) Received: from extmail1.yaanatech.com (extmail1.yaanatech.com [63.128.177.51]) by ietfa.amsl.com (Postfix) with ESMTP id 25A671A1BF3 for ; Tue, 21 Jul 2015 05:47:28 -0700 (PDT) Received: from [192.168.1.51] (pool-70-106-196-128.clppva.fios.verizon.net [70.106.196.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by extmail1.yaanatech.com (Postfix) with ESMTP id 958AB58110; Tue, 21 Jul 2015 12:53:22 +0000 (UTC) References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> To: "DOLLY, MARTIN C" , "A. Jean Mahoney" , "stir@ietf.org" From: Tony Rutkowski Organization: Yaana Technologies Message-ID: <55AE3F5E.3010802@yaanatech.com> Date: Tue, 21 Jul 2015 08:47:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tony@yaanatech.com List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:47:30 -0000 Agreed. However, it appears as if the Order encourages a robust marketplace of protocols and platforms. It might help if the relevant ATIS committees engaged in an open standards making process with publicly available materials. :-) --tony On 2015-07-21 8:22 AM, DOLLY, MARTIN C wrote: > I believe the best model is to deliver the call with an indication that the calling party has been "validated by", and let the consumer to decide to accept or not. From nobody Tue Jul 21 05:54:05 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E357F1A6EF2 for ; Tue, 21 Jul 2015 05:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 sU5AeCi-mQly for ; Tue, 21 Jul 2015 05:54:02 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60AF1A702D for ; Tue, 21 Jul 2015 05:53:25 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 5c04ea55.2b77c4419940.6499457.00-2440.18360836.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 21 Jul 2015 12:53:25 +0000 (UTC) X-MXL-Hash: 55ae40c54b86a9a9-2a04c760c8226ba6f8ba04e20dbfe8ede53a9235 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 4c04ea55.0.6499445.00-2346.18360803.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 21 Jul 2015 12:53:24 +0000 (UTC) X-MXL-Hash: 55ae40c46b6c67ac-d32a5724ab58914fc88482d15a334e1dec3d13f3 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 t6LCrNFO027388; Tue, 21 Jul 2015 08:53:23 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6LCrHF2027349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jul 2015 08:53:19 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 21 Jul 2015 12:53:05 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.130]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0224.002; Tue, 21 Jul 2015 08:53:05 -0400 From: "DOLLY, MARTIN C" To: "DRAGE, Keith (Keith)" , "tony@yaanatech.com" , "A. Jean Mahoney" , "stir@ietf.org" Thread-Topic: [stir] stir 93 meeting minutes Thread-Index: AQHQw3utZWugsKph9UihtC3XUQWLZp3lpzgggABylAD//73U8IAASj6A//+/ZDA= Date: Tue, 21 Jul 2015 12:53:04 +0000 Message-ID: References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <949EF20990823C4C85C18D59AA11AD8B69747E3A@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69747E3A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.141.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=IsOphsDg c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=epUacWqvclgA:10 a=zOBTX] X-AnalysisOut: [jUuO1YA:10 a=gxZvrgisAAAA:8 a=scBmumm3AAAA:8 a=48vgC7mUAAA] X-AnalysisOut: [A:8 a=doUQZJtgAAAA:8 a=D8HtIjsieOFLeBumWbwA:9 a=CjuIK1q_8u] X-AnalysisOut: [gA:10 a=vobkdoqC-nCygYsW:21 a=7QIgTDh3LVbDvRe2:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:54:04 -0000 Agreed, but this is simple manageable criteria -----Original Message----- From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Sent: Tuesday, July 21, 2015 8:44 AM To: DOLLY, MARTIN C; tony@yaanatech.com; A. Jean Mahoney; stir@ietf.org Subject: RE: [stir] stir 93 meeting minutes In terms of recipient handling, surely all the considerations that currentl= y apply to handling anonymous calls also apply to calls where the identity = cannot be validated. Many networks already offer features where the called user can elect to aut= omatically reject anonymous calls (as opposed to calls where the identity c= ould not be passed for interoperability reasons). Keith > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C > Sent: 21 July 2015 13:22 > To: tony@yaanatech.com; A. Jean Mahoney; stir@ietf.org > Subject: Re: [stir] stir 93 meeting minutes >=20 > Tony, >=20 > Yes, of course we can take action, like dropping the call, with the=20 > consumers consent. > WTS, what is the criteria? If not the same for all, if not it would be=20 > unmanageable. Also, black lists are not a one size fits all solution. >=20 > I believe the best model is to deliver the call with an indication=20 > that the calling party has been "validated by", and let the consumer=20 > to decide to accept or not. >=20 > Regards, >=20 > Martin >=20 > -----Original Message----- > From: Tony Rutkowski [mailto:tony@yaanatech.com] > Sent: Tuesday, July 21, 2015 8:15 AM > To: DOLLY, MARTIN C; A. Jean Mahoney; stir@ietf.org > Subject: Re: [stir] stir 93 meeting minutes >=20 > Hi Martin, >=20 > It might be worth assessing the "obligation" assertion in light of the=20 > Commission's recently released TCPA Omnibus Declaratory Ruling and=20 > Order. See=20 > https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order > See esp. at para. 152 et. seq. >=20 > The FCC Ruling and Order is arguably a game changer, and the basis for=20 > implementing STIR or equivalent platforms. If you get the customer's=20 > approval, you can drop - unless there is some additional inter carrier=20 > contract obligation. > Although even if there is, the Commission's Order arguably prevails. >=20 > --tony >=20 >=20 > On 2015-07-21 5:31 AM, DOLLY, MARTIN C wrote: > > Martin: If you look at spoof and robocalling, they're > typically from smaller carriers. ATT doesn't trust those carriers like=20 > it trusts Verizon, but we have to interwork with them. It was said on=20 > the list a few times - we cannot just drop calls, we are legally=20 > obligated. > >> > >=20 >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 From nobody Tue Jul 21 05:59:55 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFB41A1B4B for ; Tue, 21 Jul 2015 05:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Ks35qZKl73FZ for ; Tue, 21 Jul 2015 05:59:52 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC7D1A90CD for ; Tue, 21 Jul 2015 05:59:52 -0700 (PDT) From: Henning Schulzrinne To: "DOLLY, MARTIN C" , "DRAGE, Keith (Keith)" , "tony@yaanatech.com" , "A. Jean Mahoney" , "stir@ietf.org" Thread-Topic: [stir] stir 93 meeting minutes Thread-Index: AQHQw3u0XXMm2zvrm0C2zd20F7Gbf53lqQ0AgAAtsQCAAAIagIAABfiAgAAClgCAAAB9EA== Date: Tue, 21 Jul 2015 12:59:46 +0000 Message-ID: References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <949EF20990823C4C85C18D59AA11AD8B69747E3A@FR712WXCHMBA11.zeu.alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: att.com; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 5:Xb7oeQrUJr6VE4RCP3SeqsTqOQJnuSvruNRP4wrdkrDxqgF8NtOrDZmKybkHgGCHgkoRFWilquWsf0mIq/p6TnXhFHzDfBYltvjrMCKojIPwWMFfT5y2NkP+GPJo37DCjngar4JGDT2cqjp3eYw/iw==; 24:EJLk6D6JSOlk5rDHnxwnS1QtUUguR/1EaIimxcDF8psRtD1UzdS6XCmXkNn6CYc5sYNsj2qk7EyHI0V++KH04NMVcJE1LtMT024MFiGxr0s=; 20:O9grS6lXynOky0BHPPdJmnkUO4Tf1vwXawESNfi6nI/WSvPlB0gbrTl7pj76pAKBQnrezHnAoTPaljKISLn7Ow== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636; cy1pr09mb0636: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 0644578634 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(2501003)(54356999)(33656002)(76176999)(5001960100002)(107886002)(5002640100001)(189998001)(102836002)(2656002)(5003600100002)(76576001)(87936001)(77096005)(2900100001)(2950100001)(86362001)(50986999)(122556002)(5001770100001)(46102003)(40100003)(19580395003)(92566002)(5001920100001)(99286002)(74316001)(62966003)(77156002)(93886004)(19580405001)(106116001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2015 12:59:46.3497 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:59:54 -0000 I suppose the carrier could mark the From (user parameter?) as "verified", = "invalid" or "unverified". This obviously only works if the carrier strips = any "verified" parameters that it sees on incoming calls. This is conceptua= lly similar to how email MTAs add spam metric and SPF validation headers fo= r incoming email. In general, we'll need diagnostic headers for call filtering and validation= . ________________________________________ From: stir on behalf of DOLLY, MARTIN C Sent: Tuesday, July 21, 2015 8:53 AM To: DRAGE, Keith (Keith); tony@yaanatech.com; A. Jean Mahoney; stir@ietf.or= g Subject: Re: [stir] stir 93 meeting minutes Agreed, but this is simple manageable criteria From nobody Tue Jul 21 07:03:29 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B651B2E2D for ; Tue, 21 Jul 2015 07:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RdY_-CDvMJa8 for ; Tue, 21 Jul 2015 07:03:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F611B2E3E for ; Tue, 21 Jul 2015 07:03:17 -0700 (PDT) Received: from dhcp-b260.meeting.ietf.org (dhcp-b260.meeting.ietf.org [31.133.178.96]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6LE3F6Z046450 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 21 Jul 2015 09:03:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <55AE5122.4040604@nostrum.com> Date: Tue, 21 Jul 2015 16:03:14 +0200 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: stir@ietf.org References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <949EF20990823C4C85C18D59AA11AD8B69747E3A@FR712WXCHMBA11.zeu.alcatel-lucent.com>, In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] Please be careful with Subject lines (was Re: stir 93 meeting minutes) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:03:26 -0000 Folks - When you change the topic of a thread, please change the Subject. The conversation started from the raw minutes will be hard to find searching for it later, and it will be in the way when preparing the final minutes. RjS From nobody Tue Jul 21 07:21:08 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D461B2E6B for ; Tue, 21 Jul 2015 07:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 4BM1UASapyeF for ; Tue, 21 Jul 2015 07:21:02 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 4BB3E1A885E for ; Tue, 21 Jul 2015 07:20:54 -0700 (PDT) Received: (qmail 2113 invoked by uid 0); 21 Jul 2015 14:20:54 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy2.mail.unifiedlayer.com with SMTP; 21 Jul 2015 14:20:54 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id v20n1q01F1MNPNq0120qw0; Tue, 21 Jul 2015 08:00:54 -0600 X-Authority-Analysis: v=2.1 cv=BucOn+n5 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=scBmumm3AAAA:8 a=doUQZJtgAAAA:8 a=JomdIEWPoXChnZQDVkcA:9 a=1k4SbJc-P1oGrK3d:21 a=lXSvP-S7liwfNUgO:21 a=wPNLvfGTeEIA:10 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:To:From:Subject:Date; bh=CfVuQp1FLx2gE4WYzal7/qaLCDBfKe23q+BSkVumuOE=; b=LgSVORne4P4KhL55F15f4Rzoy/F5BNr0gJf2NwnHI/b8vMABUDFzGJYGoKqYsVOx/rxU2glqcpPqBLvNvPK6DsQVB64FpdMFL/A6lrWeKktx06nPrUGvbR/cDY5eXGIN; Received: from [100.36.26.202] (port=49950 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZHY6B-0001TZ-Bl; Tue, 21 Jul 2015 08:00:47 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Tue, 21 Jul 2015 10:00:42 -0400 From: Richard Shockey To: "DOLLY, MARTIN C" , "tony@yaanatech.com" , "A. Jean Mahoney" , "stir@ietf.org" Message-ID: Thread-Topic: [stir] stir 93 meeting minutes References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:21:04 -0000 Both of you are correct. The =B3Safe Harbor=B2 provision in the FCC Order provides the underpinning to block in the case where the consumer or enterprise has granted consent. Martin is also right to point out the entire STIR system is somewhat useless unless the consumer enterprise is given some indication of who is calling and the level of trust the network has in that data. That will require two parts. First how is the data passed in the INVITE and B how does the CUA display it. 3GPP will have to get involved with this at some point. Third if the call is blocked then the originating party should have some indication that the call was blocked and why. That will require some modifications of the REASON headers. And yes blacklists suck. Whitelists are not much better since they create the balloon problem Where you think you solve the problem but the bad guys just start using allocated numbers and the problem gets even worse. On 7/21/15, 8:22 AM, "stir on behalf of DOLLY, MARTIN C" wrote: >Tony, > >Yes, of course we can take action, like dropping the call, with the >consumers consent. >WTS, what is the criteria? If not the same for all, if not it would be >unmanageable. Also, black lists are not a one size fits all solution. > >I believe the best model is to deliver the call with an indication that >the calling party has been "validated by", and let the consumer to decide >to accept or not. > >Regards, > >Martin > >-----Original Message----- >From: Tony Rutkowski [mailto:tony@yaanatech.com] >Sent: Tuesday, July 21, 2015 8:15 AM >To: DOLLY, MARTIN C; A. Jean Mahoney; stir@ietf.org >Subject: Re: [stir] stir 93 meeting minutes > >Hi Martin, > >It might be worth assessing the "obligation" assertion in light of the >Commission's recently released TCPA Omnibus Declaratory Ruling and Order. > See=20 >https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order >See esp. at para. 152 et. seq. > >The FCC Ruling and Order is arguably a game changer, and the basis for >implementing STIR or equivalent platforms. If you get the customer's >approval, you can drop - unless there is some additional inter carrier >contract obligation. >Although even if there is, the Commission's Order arguably prevails. > >--tony > > >On 2015-07-21 5:31 AM, DOLLY, MARTIN C wrote: >> Martin: If you look at spoof and robocalling, they're typically from >>smaller carriers. ATT doesn't trust those carriers like it trusts >>Verizon, but we have to interwork with them. It was said on the list a >>few times - we cannot just drop calls, we are legally obligated. >>> > > > > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 21 07:23:05 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EC81B2E6E for ; Tue, 21 Jul 2015 07:22:58 -0700 (PDT) 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 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 JPmVN70N8Ct0 for ; Tue, 21 Jul 2015 07:22:55 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32851B2E49 for ; Tue, 21 Jul 2015 07:22:55 -0700 (PDT) X-AuditID: c6180641-f794d6d000001dfb-ed-55adedc014f9 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8B.E9.07675.0CDEDA55; Tue, 21 Jul 2015 08:59:12 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Tue, 21 Jul 2015 10:22:54 -0400 From: Hala Mowafy To: "DRAGE, Keith (Keith)" Thread-Topic: [stir] stir 93 meeting minutes Thread-Index: AQHQw8C7p2HAunoEyEmuxET1q6rE7Q== Date: Tue, 21 Jul 2015 14:22:53 +0000 Message-ID: <7312A153-5093-43C7-A786-040C7715D8DF@ericsson.com> References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> , <949EF20990823C4C85C18D59AA11AD8B69747E3A@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69747E3A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXSPn+6Bt2tDDS5OkrZ42niW0aKhcyWr xaEHT9ktlq/dxmSxp62H0YHVo/XZXlaPl/1zGD2WLPnJ5DFr5xMWj+sHexgDWKO4bFJSczLL Uov07RK4Mrbu72Mv+Cpf8WPxQdYGxu+SXYycHBICJhIvPy5hg7DFJC7cWw9kc3EICRxllFj1 pZkJwlnOKHHk8xZmkCo2AR2JOX8/gtkiAtYSrx5vAetgFpjPKLF7yjxWkIQwUNHZj9sZIYp0 JQ4t2A7VoCex/ORWJhCbRUBVYt32TSwgNq+AvcSpf61Q2/YxSew79AKsgVMgVmLlxJlgDYxA 930/tQbMZhYQl7j1ZD4TxN0CEkv2nGeGsEUlXj7+xwpRoyOxYPcnNghbW2LZwtfMEMsEJU7O fMIygVF0FpJRs5C0zELSMgtJywJGllWMHKXFqWW56UaGmxiB8XRMgs1xB+OCT5aHGAU4GJV4 eBXM14YKsSaWFVfmHmKU5mBREueV9ssLFRJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAYXXLs n8FtoUTdq5V3mOe8/uxTbeZf/yjtrODk3hCjJZOFb3zIuSR6On9R/IEq3u4FFSvfWlarFZ6P ETQ3/BYf5sSVwRetzyKhm2ySVX1VasO9hv7KO9zvKmLesHe0SwkURYv9n5VxmDfz2XqhN6rx Rr3y4ucvfNS8ox/JuGn65s9b7nGbGSixFGckGmoxFxUnAgBcQCSCiAIAAA== Archived-At: Cc: "stir@ietf.org" , "A. Jean Mahoney" , "DOLLY, MARTIN C" , "tony@yaanatech.com" Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:22:58 -0000 Keith, I agree in principle that could be one possible treatment for non-validated= calls. It may be easier to offer it as a service (just like Anonymous Call= Rejection: ACR) and educate the consumer that they may miss some important= calls. This way, if you subscribe, it is your choice, your responsibility= .=20 Keep in mind that ACR gives the "anonymous" caller an announcement that if = they wish to reach this called party they need to change their status to "p= ublic" and re-dial. And that is easy with the star codes.=20 Similarly, for non-verified calls, the caller should be informed of the out= come. I imagine if you are a legitimate caller, you are more likely to hav= e other means of contacting the recipient; e.g., email or text. =20 But other options need to be thought out.=20 Allowing callers to leave a VM will be just as annoying as it is today with= getting 50 robo call VMs a day. However, if it is a doctor calling for th= e first time, has no other contact info for you, how does he get the messag= e across without a VM? I also imagine if a legit caller encounters this treatment frequently, he m= ay contact his SP or eventually change his SP! =20 BR/ Hala Sent from my iPhone > On Jul 21, 2015, at 2:44 PM, DRAGE, Keith (Keith) wrote: >=20 > In terms of recipient handling, surely all the considerations that curren= tly apply to handling anonymous calls also apply to calls where the identit= y cannot be validated. >=20 > Many networks already offer features where the called user can elect to a= utomatically reject anonymous calls (as opposed to calls where the identity= could not be passed for interoperability reasons). >=20 >=20 > Keith >=20 >=20 >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C >> Sent: 21 July 2015 13:22 >> To: tony@yaanatech.com; A. Jean Mahoney; stir@ietf.org >> Subject: Re: [stir] stir 93 meeting minutes >>=20 >> Tony, >>=20 >> Yes, of course we can take action, like dropping the call,=20 >> with the consumers consent. >> WTS, what is the criteria? If not the same for all, if not it=20 >> would be unmanageable. Also, black lists are not a one size=20 >> fits all solution. >>=20 >> I believe the best model is to deliver the call with an=20 >> indication that the calling party has been "validated by",=20 >> and let the consumer to decide to accept or not. >>=20 >> Regards, >>=20 >> Martin >>=20 >> -----Original Message----- >> From: Tony Rutkowski [mailto:tony@yaanatech.com] >> Sent: Tuesday, July 21, 2015 8:15 AM >> To: DOLLY, MARTIN C; A. Jean Mahoney; stir@ietf.org >> Subject: Re: [stir] stir 93 meeting minutes >>=20 >> Hi Martin, >>=20 >> It might be worth assessing the "obligation" assertion in=20 >> light of the Commission's recently released TCPA Omnibus=20 >> Declaratory Ruling and Order. See=20 >> https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order >> See esp. at para. 152 et. seq. >>=20 >> The FCC Ruling and Order is arguably a game changer, and the=20 >> basis for implementing STIR or equivalent platforms. If you=20 >> get the customer's approval, you can drop - unless there is=20 >> some additional inter carrier contract obligation. >> Although even if there is, the Commission's Order arguably prevails. >>=20 >> --tony >>=20 >>=20 >>> On 2015-07-21 5:31 AM, DOLLY, MARTIN C wrote: >>> Martin: If you look at spoof and robocalling, they're >> typically from smaller carriers. ATT doesn't trust those=20 >> carriers like it trusts Verizon, but we have to interwork=20 >> with them. It was said on the list a few times - we cannot=20 >> just drop calls, we are legally obligated. >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 From nobody Tue Jul 21 07:28:01 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736CB1B2E55 for ; Tue, 21 Jul 2015 07:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_BASE64_BLANKS=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 HZOgdA7FOSgn for ; Tue, 21 Jul 2015 07:27:59 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 5A1B21A8847 for ; Tue, 21 Jul 2015 07:27:59 -0700 (PDT) Received: (qmail 25050 invoked by uid 0); 21 Jul 2015 14:27:59 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy5.mail.unifiedlayer.com with SMTP; 21 Jul 2015 14:27:59 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id v27v1q01V1MNPNq0127yNf; Tue, 21 Jul 2015 08:07:58 -0600 X-Authority-Analysis: v=2.1 cv=BucOn+n5 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=PeFO9FbFhS32YxYntvkA:9 a=iycWLhIX580A:10 a=48vgC7mUAAAA:8 a=scBmumm3AAAA:8 a=M0OflfRGAAAA:8 a=6miudsW-4qzmnwU9d0YA:9 a=eVD4_d5ekzQFkxjd:21 a=TspcUlk716ljJVpb:21 a=wPNLvfGTeEIA:10 a=rQ1xVbxds2k3_WObHBgA:9 a=IKIoO-ieCDEA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=QIWr9syEXu7CnU9j2zvShNHJgxIKG0lVEz5+AN3eGgI=; b=UHTd60UjBLNoxTqh8J7pDtdLfO7W6T9VhPT4gSRjzV+O+v9nsBfgs+1OAKgv4lRpAPgRi60S82RbPLN4w3iOPOMBn5O50NB9b1RTwW41LC2B98qGsieai3fBh4qq9nMU; Received: from [100.36.26.202] (port=49975 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZHYD5-0006iZ-8e; Tue, 21 Jul 2015 08:07:55 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Tue, 21 Jul 2015 10:07:49 -0400 From: Richard Shockey To: , "DOLLY, MARTIN C" , "A. Jean Mahoney" , "stir@ietf.org" Message-ID: Thread-Topic: [stir] stir 93 meeting minutes References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <55AE3F5E.3010802@yaanatech.com> In-Reply-To: <55AE3F5E.3010802@yaanatech.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3520318075_140541" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:28:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3520318075_140541 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 7/21/15, 8:47 AM, "stir on behalf of Tony Rutkowski" wrote: >Agreed. > >However, it appears as if the Order encourages >a robust marketplace of protocols and platforms. > >It might help if the relevant ATIS committees >engaged in an open standards making process >with publicly available materials. :-) Oh you mean like this=8Ayes the documents are free. ATIS and SIPForum Complete New IP-Based Network to Network Interface (NNI) Technical Specification Joint task force delivers major milestone with the publication of the first standardized, industry-based, consensus-driven specification designed to achieve IP-based interconnection of service provider networks. =20 http://www.sipforum.org/content/view/431/171/ > >--tony > >On 2015-07-21 8:22 AM, DOLLY, MARTIN C wrote: >> I believe the best model is to deliver the call with an indication that >>the calling party has been "validated by", and let the consumer to >>decide to accept or not. > > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir --B_3520318075_140541 Content-type: application/xml; name="default.xml" Content-disposition: attachment; filename="default.xml" Content-transfer-encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rD MBBF94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHt MSbnqdKrvNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwH JKm0Po7Aco2dCWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBm qpqzuohDuiDcU/OLLlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5t ncXG290o68hn48XsTwCr/4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2 AQAACwAAAF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb 69tPxwYKuwiEpO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8 UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6P qMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQA BgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzM TQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0u iLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtH V+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAw3UMpqAYAAKQbAAAWAAAAdGhl bWUvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbY UKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4f qavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJg fSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/Q UJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7Rx dQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLN Rn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5m t7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2K tRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3 r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1 ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSU OMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZ eThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6 gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4o HFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8 gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9 MxEVvrxOuBO/gykbY2JKDRR1p1bHNPm7ws0oVG7L4eIKN5TKF18/rpD7bS3Zm7B7VeXM9olC vQh3sjx3uQjo21+dt/Ak2SOQEPNb1Lvi/K44e//54rwony++JM+qMBRo3YvYRtu03fHCrntM GRuoKSM3pGm8Jew9QR8G9Tpz4iTFKSyN4FFnMjBwcKHAZg0SXH1EVTSIcApNe93TREKZkQ4l SrmEw6IZrqSt8dD4K3vUbOpDiK0cEqtdHtjhFT2cnzUKMkaq0Bxoc0YrmsBZma1cyYiCbq/D rK6FOjO3uhHNFEWHW6GyNrE5lIPJC9VgsLAmNDUIWiGw8iqc+TVrOOxgRgJtd+uj3C3GCxfp IhnhgGQ+0nrP+6hunJTHypwiWg8bDPrgeIrVStxamuwbcDuLk8rsGgvY5d57Ey/lETzzElA7 mY4sKScnS9BR22s1l5se8nHa9sZwTobHOAWvS91HYhbCZZOvhA37U5PZZPnMm61cMTcJ6nD1 Ye0+p7BTB1Ih1RaWkQ0NM5WFAEs0Jyv/chPMelEKVFSjs0mxsgbB8K9JAXZ0XUvGY+KrsrNL I9p29jUrpXyiiBhEwREasYnYx+B+HaqgT0AlXHeYiqBf4G5OW9tMucU5S7ryjZjB2XHM0ghn 5VanaJ7JFm4KUiGDeSuJB7pVym6UO78qJuUvSJVyGP/PVNH7Cdw+rATaAz5cDQuMdKa0PS5U xKEKpRH1+wIaB1M7IFrgfhemIajggtr8F+RQ/7c5Z2mYtIZDpNqnIRIU9iMVCUL2oCyZ6DuF WD3buyxJlhEyEVUSV6ZW7BE5JGyoa+Cq3ts9FEGom2qSlQGDOxl/7nuWQaNQNznlfHMqWbH3 2hz4pzsfm8yglFuHTUOT278QsWgPZruqXW+W53tvWRE9MWuzGnlWALPSVtDK0v41RTjnVmsr 1pzGy81cOPDivMYwWDREKdwhIf0H9j8qfGa/dugNdcj3obYi+HihiUHYQFRfso0H0gXSDo6g cbKDNpg0KWvarHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5uXiRxs4s7Njaji00NXj2ZIrC 0Dg/yBjHmM9k5S9ZfHQPHL0F3wwmTEkTTPCdSmDooQcmDyD5LUezdOMvAAAA//8DAFBLAwQU AAYACAAAACEADdGQn7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdl ci54bWwucmVsc4SPTQrCMBSE94J3CG9v07oQkSbdiNCt1AOE5DUNNj8kUeztDa4sCC6HYb6Z abuXnckTYzLeMWiqGgg66ZVxmsFtuOyOQFIWTonZO2SwYIKObzftFWeRSyhNJiRSKC4xmHIO J0qTnNCKVPmArjijj1bkIqOmQci70Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/TgaiWcvHxZd /lFBc9mFBSiixszgI5uqTATKW7q6xN8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAJvocE/8AAAA HAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAAtAQAAX3JlbHMvLnJlbHNQSwECLQAUAAYA CAAAACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAWAgAAdGhlbWUvdGhlbWUvdGhlbWVN YW5hZ2VyLnhtbFBLAQItABQABgAIAAAAIQAw3UMpqAYAAKQbAAAWAAAAAAAAAAAAAAAAANMC AAB0aGVtZS90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcA AAAAAAAAAAAAAAAArwkAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVs c1BLBQYAAAAABQAFAF0BAACqCgAAAAA= --B_3520318075_140541-- From nobody Tue Jul 21 07:29:57 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFC11B2E98 for ; Tue, 21 Jul 2015 07:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 wqktTw41D8hg for ; Tue, 21 Jul 2015 07:29:54 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 01A191B2E97 for ; Tue, 21 Jul 2015 07:29:52 -0700 (PDT) Received: (qmail 17319 invoked by uid 0); 21 Jul 2015 14:29:52 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy2.mail.unifiedlayer.com with SMTP; 21 Jul 2015 14:29:52 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id v29n1q01R1MNPNq0129qEw; Tue, 21 Jul 2015 08:09:52 -0600 X-Authority-Analysis: v=2.1 cv=NJxGpSKg c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=5-QDLPJQAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=oyy03FgqIQNu0_KTlakA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=BpWyxxjQ9I4A:10 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; bh=KLv1ipcEya0EdJsCB0EfwbhOEWrrzBdwaucL4tkpiuU=; b=Fn4jF29UrIuy42dbo4+HXyK7GDXkOEtWt6zG+lvQGUR4KNkmsaLFmIuKNZ+l74XQi1JwivrbNc6/Q2DNfwbi3oQnkR3lZQJw9hUD7yXDxz4JP9gyaqCHqcHTXc1R1Xoc; Received: from [100.36.26.202] (port=50029 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZHYEu-0008EV-2F for stir@ietf.org; Tue, 21 Jul 2015 08:09:48 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Tue, 21 Jul 2015 10:09:44 -0400 From: Richard Shockey To: Message-ID: Thread-Topic: Speaking of open documents. Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: [stir] Speaking of open documents. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:29:55 -0000 Something from yours truly and Scott Marcus the former FCC CTO. http://stakeholders.ofcom.org.uk/market-data-research/other/technology-rese arch/2015-reports/rpki/ =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From nobody Tue Jul 21 07:40:40 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF48B1A88C0 for ; Tue, 21 Jul 2015 07:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 xw4i4or3Y-C4 for ; Tue, 21 Jul 2015 07:40:37 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.161]) (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 B36FA1A1A8D for ; Tue, 21 Jul 2015 07:40:36 -0700 (PDT) Received: from [85.158.137.67] by server-1.bemta-3.messagelabs.com id 1E/2C-10437-3E95EA55; Tue, 21 Jul 2015 14:40:35 +0000 X-Env-Sender: Patrick.Tarpey@ofcom.org.uk X-Msg-Ref: server-8.tower-139.messagelabs.com!1437489634!45958647!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28205 invoked from network); 21 Jul 2015 14:40:34 -0000 Received: from unknown (HELO mail1.ofcom.org.uk) (194.33.160.65) by server-8.tower-139.messagelabs.com with AES128-SHA encrypted SMTP; 21 Jul 2015 14:40:34 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by mail2.ofcom.org.uk (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 21 Jul 2015 15:40:34 +0100 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%13]) with mapi id 14.03.0224.002; Tue, 21 Jul 2015 15:40:19 +0100 From: Patrick Tarpey To: "'richard@shockey.us'" , "'stir@ietf.org'" Thread-Topic: [stir] Speaking of open documents. Thread-Index: AQHQw8GzFEj1TKo+uk+KapkxNBe2TJ3l/tH3 Date: Tue, 21 Jul 2015 14:40:18 +0000 Message-ID: <2FD4C4C86AF9F24AB55FEEA59BCD435E012EDA4BBA@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [stir] Speaking of open documents. X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:40:39 -0000 aHR0cDovL3N0YWtlaG9sZGVycy5vZmNvbS5vcmcudWsvYmluYXJpZXMvbWFya2V0LWRhdGEtcmVz ZWFyY2gvT2Zjb21fVm9JUF9SUEtJX1JlcG9ydC5wZGYNCg0KRGlyZWN0IGxpbmsgdG8gdGhlIHJl cG9ydC4uLg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBSaWNoYXJkIFNo b2NrZXkgW21haWx0bzpyaWNoYXJkQHNob2NrZXkudXNdDQpTZW50OiBUdWVzZGF5LCBKdWx5IDIx LCAyMDE1IDA0OjA5IFBNDQpUbzogc3RpckBpZXRmLm9yZyA8c3RpckBpZXRmLm9yZz4NClN1Ympl Y3Q6IFtzdGlyXSBTcGVha2luZyBvZiBvcGVuIGRvY3VtZW50cy4NCg0KDQpTb21ldGhpbmcgZnJv bSB5b3VycyB0cnVseSBhbmQgU2NvdHQgTWFyY3VzIHRoZSBmb3JtZXIgRkNDIENUTy4NCg0KaHR0 cDovL3N0YWtlaG9sZGVycy5vZmNvbS5vcmcudWsvbWFya2V0LWRhdGEtcmVzZWFyY2gvb3RoZXIv dGVjaG5vbG9neS1yZXNlDQphcmNoLzIwMTUtcmVwb3J0cy9ycGtpLw0KDQoNCg0K4oC5DQpSaWNo YXJkIFNob2NrZXkNClNob2NrZXkgQ29uc3VsdGluZyBMTEMNCkNoYWlybWFuIG9mIHRoZSBCb2Fy ZCBTSVAgRm9ydW0NCnd3dy5zaG9ja2V5LnVzDQp3d3cuc2lwZm9ydW0ub3JnDQpyaWNoYXJkPGF0 PnNob2NrZXkudXMNClNreXBlLUxpbmtlZGluLUZhY2Vib29rIHJzaG9ja2V5MTAxDQpQU1ROICsx IDcwMy01OTMtMjY4Mw0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kc3RpciBtYWlsaW5nIGxpc3QNCnN0aXJAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCkZvciBtb3JlIGluZm9ybWF0aW9uIHZpc2l0IHd3dy5vZmNvbS5v cmcudWsNCg0KVGhpcyBlbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZCBmb3IgdGhlIHVzZSBvZiB0aGUgYWRkcmVzc2VlIG9ubHkuDQoNCklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZiB0aGUgbWVzc2FnZSBhbmQgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uDQoN ClRoaXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9w ZW4gYW55IGF0dGFjaG1lbnRzIGF0IHlvdXIgb3duIHJpc2suDQoNCkFueSB2aWV3cyBleHByZXNz ZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIgYW5k IGRvIG5vdCByZXByZXNlbnQgdGhlIHZpZXdzIG9yIG9waW5pb25zIG9mIE9mY29tIHVubGVzcyBl eHByZXNzbHkgc3RhdGVkIG90aGVyd2lzZS4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K From nobody Tue Jul 21 07:48:52 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052051B2D03 for ; Tue, 21 Jul 2015 07:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 rdxW70thWGid for ; Tue, 21 Jul 2015 07:48:49 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCFE51A88F1 for ; Tue, 21 Jul 2015 07:48:49 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-09v.sys.comcast.net with comcast id v2oT1q0022Udklx012op12; Tue, 21 Jul 2015 14:48:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id v2oo1q00S3Ge9ey012ooUN; Tue, 21 Jul 2015 14:48:49 +0000 Message-ID: <55AE5BCF.8080304@alum.mit.edu> Date: Tue, 21 Jul 2015 10:48:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: stir@ietf.org References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437490129; bh=KLqcKUahy+96QIis/3jy23YrDDPAyZ3Wj1FiHTg5W54=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=b3T9L9rQStwxE2D5WW1bNs3COhK3btmE94pKNVHPKMiwWR0vPAs84PYD7ZLxxS/KS 9ZRCA2HNWNqoRGSmkYmXOm9rq914yjzp7ZXlyhP12jxME4ljSAG1qOQcWuTAlQS9mh +/0kH+5uYflGa8AxwkO1jI+1m1g/h3827Ygya5DDx/jrH8ClrjDNx5aPEJcU4Z7JkQ yQzAh87dSmP0/rAvMyv7b/yNg/tdvx7/wPOUdfrGUZyT1VGHm9OjuaGMkYNOzLMuN8 4Yu5PWY6MYWKriV3HomHeMu9cOjitGjuFAUj1vUl/SFQ8gN+GJUNbo/+b2APWc+SAm vpcvvtF9r72qA== Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:48:51 -0000 On 7/21/15 10:00 AM, Richard Shockey wrote: > Third if the call is blocked then the originating party should have some > indication that the call was blocked and why. That will require some > modifications of the REASON headers. IMO "should" is too strong here. Telling the calling party they have been blocked is one policy that might work for some callees. So having additional mechanisms to communicate reason to them are fine. But some may want to use another policy. E.g. - allow the call to appear to the caller as "ringing" until the caller decides to hang up. (But without bothering the callee at all.) - route the call to a special voice mailbox and record the message for future analysis. - route the call to what appears to be a voice mailbox, but that doesn't bother to record the media at all. All of these could be accompanied by keeping a log of such calls. My point is that this ought to be a policy decision by the *callee*. Thanks, Paul From nobody Tue Jul 21 07:57:04 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05DB1A8908 for ; Tue, 21 Jul 2015 07:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 L6p8kIo9cCtg for ; Tue, 21 Jul 2015 07:56:59 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1169D1A905F for ; Tue, 21 Jul 2015 07:56:59 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id bbd5ea55.2ab3ad401940.2572933.00-2400.7255593.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 21 Jul 2015 14:56:59 +0000 (UTC) X-MXL-Hash: 55ae5dbb37048d1a-26ad39bafa14e9a34855683fdc88c4a63cc3e6ae Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 7bd5ea55.0.2572893.00-2172.7255471.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 21 Jul 2015 14:56:56 +0000 (UTC) X-MXL-Hash: 55ae5db847abc2be-86bb16a911ee70960a5216c99f31bb5f63f82a94 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 t6LEutCU012253; Tue, 21 Jul 2015 10:56:55 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6LEugU8011920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jul 2015 10:56:52 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 21 Jul 2015 14:56:27 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.71]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0224.002; Tue, 21 Jul 2015 10:56:27 -0400 From: "PFAUTZ, PENN L" To: Paul Kyzivat , "stir@ietf.org" Thread-Topic: [stir] stir 93 meeting minutes Thread-Index: AQHQw3utMZgnFTQLh06HBTqnCHUU9p3l7BwAgAAtsACAAAIagIAAG3MAgAANcID//70uMA== Date: Tue, 21 Jul 2015 14:56:27 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D60585352B@MISOUT7MSGUSRDD.ITServices.sbc.com> References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <55AE5BCF.8080304@alum.mit.edu> In-Reply-To: <55AE5BCF.8080304@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=fcMaPTsF c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=_Je7GUglaHMA:10 a=zOBTX] X-AnalysisOut: [jUuO1YA:10 a=48vgC7mUAAAA:8 a=eBNnRO06GNoEwKbWFVQA:9 a=Cju] X-AnalysisOut: [IK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:57:03 -0000 Paul, I have some concerns about approaches that mislead the caller about what is= happening: 1. In the US, carriers are now required to report on rural versus non-rural= call completion and non-answered call disposition. What you propose might = skew these statistics 2. Although the FCC has said that carriers may block calls at customer requ= est, it is not clear that this extends to sending back what is essentially = false signaling - explicitly prohibited in the order. 3. When calls are failing without explanation, calling customers including = legitimate telemarketers - unwanted as they may be - may complain to their = carrier resulting in wasted network investigations. Some blocking services = already this this result. I'd be interested in Henning's take on this... Penn Pfautz AT&T Global Connection Management=20 -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, July 21, 2015 10:49 AM To: stir@ietf.org Subject: Re: [stir] stir 93 meeting minutes On 7/21/15 10:00 AM, Richard Shockey wrote: > Third if the call is blocked then the originating party should have some > indication that the call was blocked and why. That will require some > modifications of the REASON headers. IMO "should" is too strong here. Telling the calling party they have=20 been blocked is one policy that might work for some callees. So having=20 additional mechanisms to communicate reason to them are fine. But some=20 may want to use another policy. E.g. - allow the call to appear to the caller as "ringing" until the caller=20 decides to hang up. (But without bothering the callee at all.) - route the call to a special voice mailbox and record the message for=20 future analysis. - route the call to what appears to be a voice mailbox, but that doesn't=20 bother to record the media at all. All of these could be accompanied by keeping a log of such calls. My point is that this ought to be a policy decision by the *callee*. Thanks, Paul _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 21 08:11:02 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8A31B2F1D for ; Tue, 21 Jul 2015 08:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 qOSgawlaYXh4 for ; Tue, 21 Jul 2015 08:10:45 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0F51B2E96 for ; Tue, 21 Jul 2015 08:10:24 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-01v.sys.comcast.net with comcast id v38A1q0012D5gil013APRS; Tue, 21 Jul 2015 15:10:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-06v.sys.comcast.net with comcast id v3AN1q00d3Ge9ey013APz8; Tue, 21 Jul 2015 15:10:23 +0000 Message-ID: <55AE60DD.5000700@alum.mit.edu> Date: Tue, 21 Jul 2015 11:10:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "PFAUTZ, PENN L" , "stir@ietf.org" References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <55AE5BCF.8080304@alum.mit.edu> <38726EDA2109264987B45E29E758C4D60585352B@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D60585352B@MISOUT7MSGUSRDD.ITServices.sbc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437491423; bh=prD7JM6lJc1folq4mj1NfJwU6sZPAUB9HRqSfOyy4vw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tD4MJdNe2WsidglvzEm1El1kHFnzeTQzLht+/K3cDx6AHwO8r1Xdbd0N7OxpnK/HP Hw5B32qx4KPhYw/9H6MqWEdE/Y+ruvXUuGudDdU+IVw5vPJTN/09uP/eURbbycCQ3f Xr3tlHx43eKjGynVFsntHEu3Gy0NX+MNU69Tx8K+5Mpo193zJP2y0APqY6hEjPwoCH ADdsE8LGWR3RCSSfZs34iCWb/hIHiHZRtvU9gdUtit6kCDfbWvQmzAE4OwkYPpXGxC 1NTVshDIyo/DEWS6NkVS8VwNPI9F/lDJHRtR4canwdOHtgMtUuPlhdBH1UTSW2cgla Lp0/38hBEMcmA== Archived-At: Subject: [stir] Responses to unauthenticaed / misauthenticated calls X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 15:10:47 -0000 On 7/21/15 10:56 AM, PFAUTZ, PENN L wrote: > Paul, > I have some concerns about approaches that mislead the caller about what is happening: > 1. In the US, carriers are now required to report on rural versus non-rural call completion and non-answered call disposition. What you propose might skew these statistics > 2. Although the FCC has said that carriers may block calls at customer request, it is not clear that this extends to sending back what is essentially false signaling - explicitly prohibited in the order. > 3. When calls are failing without explanation, calling customers including legitimate telemarketers - unwanted as they may be - may complain to their carrier resulting in wasted network investigations. Some blocking services already this this result. > > I'd be interested in Henning's take on this... (I changed the subject line this time.) Well... The approaches I mentioned can be achieved by the callee's UA. AFAIK that is not subject to FCC rules. I would think it reasonable that any behavior legal for an end user should be able to be delegated to a provider without it becoming forbidden. (But I realize that being reasonable doesn't always apply to telecom regulations.) Still, I think such behaviors ought to be considered possibilities, even if they may not be used in some contexts. Thanks, Paul > Penn Pfautz > AT&T Global Connection Management > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, July 21, 2015 10:49 AM > To: stir@ietf.org > Subject: Re: [stir] stir 93 meeting minutes > > On 7/21/15 10:00 AM, Richard Shockey wrote: > >> Third if the call is blocked then the originating party should have some >> indication that the call was blocked and why. That will require some >> modifications of the REASON headers. > > IMO "should" is too strong here. Telling the calling party they have > been blocked is one policy that might work for some callees. So having > additional mechanisms to communicate reason to them are fine. But some > may want to use another policy. E.g. > > - allow the call to appear to the caller as "ringing" until the caller > decides to hang up. (But without bothering the callee at all.) > > - route the call to a special voice mailbox and record the message for > future analysis. > > - route the call to what appears to be a voice mailbox, but that doesn't > bother to record the media at all. > > All of these could be accompanied by keeping a log of such calls. > > My point is that this ought to be a policy decision by the *callee*. > > Thanks, > Paul > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > From nobody Tue Jul 21 08:25:25 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC16D1A8900 for ; Tue, 21 Jul 2015 08:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9rqCE-OD3L8s for ; Tue, 21 Jul 2015 08:25:21 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 110ED1B2F77 for ; Tue, 21 Jul 2015 08:23:33 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 91E24DC6BAF78; Tue, 21 Jul 2015 15:23:28 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6LFNTfJ022896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 17:23:30 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 17:23:30 +0200 From: "DRAGE, Keith (Keith)" To: "PFAUTZ, PENN L" , Paul Kyzivat , "stir@ietf.org" Thread-Topic: [stir] stir 93 meeting minutes Thread-Index: AQHQw3uqjkqRWgwj1UCIqZaGwdMW/53mAevz///gbYCAACQmoA== Date: Tue, 21 Jul 2015 15:23:29 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69748483@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <55AE5BCF.8080304@alum.mit.edu> <38726EDA2109264987B45E29E758C4D60585352B@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D60585352B@MISOUT7MSGUSRDD.ITServices.sbc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 15:25:23 -0000 I'd note that when anonymous call rejection was defined in European documen= ts, the caller was notified that the call was rejected specifically for thi= s reason. Remember also that the calling user is generally paying for this call, and = has a contract with the telecommunications provider to provide service. The= re is a balancing of rights here between the calling user, the called user,= and one or more network operators. While forcing a spoof caller to incur a= dditional costs may seem justified to the called user, it might not necessa= rily be justified when a complete analysis of all parties rights is perform= ed. Some of these actions also have legal implications in some jurisdictions, s= o for example recording a call without giving notice that the call is being= recorded.=20 Regards Keith > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L > Sent: 21 July 2015 15:56 > To: Paul Kyzivat; stir@ietf.org > Subject: Re: [stir] stir 93 meeting minutes >=20 > Paul, > I have some concerns about approaches that mislead the caller=20 > about what is happening: > 1. In the US, carriers are now required to report on rural=20 > versus non-rural call completion and non-answered call=20 > disposition. What you propose might skew these statistics 2.=20 > Although the FCC has said that carriers may block calls at=20 > customer request, it is not clear that this extends to=20 > sending back what is essentially false signaling - explicitly=20 > prohibited in the order. > 3. When calls are failing without explanation, calling=20 > customers including legitimate telemarketers - unwanted as=20 > they may be - may complain to their carrier resulting in=20 > wasted network investigations. Some blocking services already=20 > this this result. >=20 > I'd be interested in Henning's take on this... >=20 > Penn Pfautz > AT&T Global Connection Management=20 >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, July 21, 2015 10:49 AM > To: stir@ietf.org > Subject: Re: [stir] stir 93 meeting minutes >=20 > On 7/21/15 10:00 AM, Richard Shockey wrote: >=20 > > Third if the call is blocked then the originating party should have=20 > > some indication that the call was blocked and why. That=20 > will require=20 > > some modifications of the REASON headers. >=20 > IMO "should" is too strong here. Telling the calling party=20 > they have been blocked is one policy that might work for some=20 > callees. So having additional mechanisms to communicate=20 > reason to them are fine. But some may want to use another policy. E.g. >=20 > - allow the call to appear to the caller as "ringing" until=20 > the caller decides to hang up. (But without bothering the=20 > callee at all.) >=20 > - route the call to a special voice mailbox and record the=20 > message for future analysis. >=20 > - route the call to what appears to be a voice mailbox, but=20 > that doesn't bother to record the media at all. >=20 > All of these could be accompanied by keeping a log of such calls. >=20 > My point is that this ought to be a policy decision by the *callee*. >=20 > Thanks, > Paul >=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 > = From nobody Tue Jul 21 08:47:46 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB1D1B2F50 for ; Tue, 21 Jul 2015 08:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Ja9Cj-zfsCa3 for ; Tue, 21 Jul 2015 08:47:44 -0700 (PDT) Received: from extmail1.yaanatech.com (extmail1.yaanatech.com [63.128.177.51]) by ietfa.amsl.com (Postfix) with ESMTP id 920D61B2F51 for ; Tue, 21 Jul 2015 08:47:36 -0700 (PDT) Received: from [192.168.1.51] (pool-70-106-196-128.clppva.fios.verizon.net [70.106.196.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by extmail1.yaanatech.com (Postfix) with ESMTP id 1670558113; Tue, 21 Jul 2015 15:53:30 +0000 (UTC) References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> To: Richard Shockey , "DOLLY, MARTIN C" , "A. Jean Mahoney" , "stir@ietf.org" From: Tony Rutkowski Organization: Yaana Technologies Message-ID: <55AE6996.5020402@yaanatech.com> Date: Tue, 21 Jul 2015 11:47:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [stir] stir 93 meeting minutes X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tony@yaanatech.com List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 15:47:45 -0000 On 2015-07-21 10:00 AM, Richard Shockey wrote: > does the CUA display it. 3GPP will have to get involved with this at some > point. Hi Richard, 3GPP SA3 is already involved. Below is the draft report text from the last meeting in April. The next SA3 meeting is coming up in August. Also GSMA plays a major role here, and has has initiatives over the past few years. > 8.4 IMS Enhanced Spoofed Call Prevention and Detection > S3-151307 FS_ESCAPADES: Previous spoofed call detection solutions > TR 33.832 v.. > Source: NEC > Abstract: This document introduces previous spoofed call detection > solutions to TR 33.832. > Discussion: Nokia Networks supported the document. > Decision: The document was approved. > > S3-151295 Spoofed call actor definitions > TR 33.832 v.. > Source: Sprint > Abstract: - > Decision: The document was approved. > > S3-151296 Valid and invalid (spoofed) call scenarios > TR 33.832 v.. > Source: Sprint > Abstract: - > Decision: The document was approved. > > S3-151309 Summary of IETF STIR group active drafts on spoofed call > detection > TR 33.832 v.. > Source: Alcatel-Lucent > Abstract: summary of IETF STIR group active drafts on spoofed call > detection > Decision: The document was approved. > > S3-151308 FS_ESCAPADES: Consideration on verifier behaviour against > detected spoofed call > TR 33.832 v.. > Source: NEC > Abstract: This document identifies a consideration regarding the > verifier behaviour against detected spoofed call and then proposes a > corresponding contribution to sub clause 8.1 of TR 33.832. > Decision: The document was revised to S3-151533. > > S3-151533 FS_ESCAPADES: Consideration on verifier behaviour against > detected spoofed call > TR 33.832 v.. > Source: NEC > (Replaces S3-151308) > Decision: The document was approved. > > S3-151534 TR 33.832 > Source: Rapporteur > Decision: The document was left for email approval. From nobody Wed Jul 22 08:10:29 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9301A01CB for ; Wed, 22 Jul 2015 08:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] autolearn=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 3pnfWBfdry2k for ; Wed, 22 Jul 2015 08:10:25 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id D3EB91A0123 for ; Wed, 22 Jul 2015 08:10:03 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vTA21q00x2NEPrz01TA3NF; Wed, 22 Jul 2015 17:10:03 +0200 Date: Wed, 22 Jul 2015 17:10:03 +0200 (CEST) From: Meetecho Team To: stir@ietf.org Message-ID: <1612687302.5.1437577803932.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4_1984541037.1437577803929" Archived-At: Subject: [stir] Meetecho recordings of STIR WG session X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:10:25 -0000 ------=_Part_4_1984541037.1437577803929 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the STIR WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#STIR In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_4_1984541037.1437577803929-- From nobody Thu Jul 23 18:12:42 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B52A1B2D63 for ; Thu, 23 Jul 2015 18:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.389 X-Spam-Level: X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, LOTS_OF_MONEY=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 NcR8WJgaierW for ; Thu, 23 Jul 2015 18:12:40 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECEB1B2D61 for ; Thu, 23 Jul 2015 18:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=P2MiftkN5XZKRm0hPJ3/VYJwCnPWCce6E16lODvMGkI=; b=uDRaoe7ybaIyCzIv65NEJJ+hsCb6OZdd6GSHRPrGYY6gyOKflfastHXI2U+f3DsuNA6umWBjbMwIwsPgme0YBsdkKmHs69OVnFpf06xQfhSnN87wTwuHYLG+RTYugZVZ1qUqjSaXRrqcfzGNYnB4J7F5gkGHylDaKi3evg5Fq7w=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:51992 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZIRXM-00076N-3r for stir@ietf.org; Thu, 23 Jul 2015 18:12:36 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Eric Burger In-Reply-To: <55AE2770.9020101@alum.mit.edu> Date: Thu, 23 Jul 2015 21:12:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <685A28B0-A6F3-4A8F-BA18-F367BE04597B@standardstrack.com> References: <55AE2770.9020101@alum.mit.edu> To: stir@ietf.org X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [stir] the role of trust in stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 01:12:41 -0000 I agree. The trust model is key to what we need to do. If the model is anyone can manage a TN, then we already have a system in = place. It=E2=80=99s called X.509 certificates. If one only allows for = rooted certificate chains, then one can presumably track down who is = making a call, and you can whack them if they are bad. No need to have = convoluted, trusted third-party verification of TN ownership (whether a = Neustar/iconectiv/OFCOM model or a distributed model). If the model is, in Martin=E2=80=99s words, only people who can be = punished can manage TNs, then the mere presence of a signed message is = good enough. If a carrier lies, they get fined $10,000 per occurrence, = or some such regime that ensures they do not lie. I could see a hypothetical regime where anyone can manage a TN but they = go directly to their government with a credit card or e-Residency card = to sign for it. In that case, you already have a trusted third-party: = the government itself. If the certificate is not signed by the = government, you know it=E2=80=99s bad. Again, no need to look at the TN = itself, because the government presumably did some identity verification = to generate the certificate. So, I still do not see the need for per-call or even per-certificate = verification. The chain of trust in the certificate itself should be = sufficient. > On Jul 21, 2015, at 7:05 AM, Paul Kyzivat = wrote: >=20 > I couldn't make myself clear via jabber during the discussion, so I'll = try again. This is similar to a point that Henning made. >=20 > There seem to be a few models for how verifier determines whether a = cert actually covers the number it signs: >=20 > - the message contains the cert >=20 > - the message contains a ref to the cert >=20 > And then, regardless of how the cert is obtained: >=20 > - the cert contains the TN. >=20 > - the cert contains a reference to a list of covered TNs. >=20 > - the cert has neither (is that a real possibility?) >=20 > This then leads to several possible cases for the verifier: >=20 > 1) there is no signature >=20 > 2) there is a signature, but the cert can't be obtained >=20 > 3) cert has been obtained, no attempt is made to determine formal = coverage of the TN (because policy doesn't require it). >=20 > 4) cert has been obtained, but coverage of TN by cert can't be = determined >=20 > 5) cert has been obtained, and it explicitly does NOT cover the TN. >=20 > 6) cert has been obtained, and coverage of TN has been verified >=20 > I think all of those cases are possible regardless of policy. It then = becomes a matter of policy how to treat calls in each case: allow or = not, display calling TN or not, indicate warning or not. >=20 > But if certain policies become widely used they could have the effect = of making other policies unusable. And that can have the effect of = encouraging oligopolies. >=20 > In particular, if a common verifier policy is to just whitelist = certain signers without checking coverage, and block the id from = everybody else, then anybody who gets service from a provider who isn't = on the whitelist runs the risk of not having their calls answered. >=20 > Also, when providers know most verifiers follow that policy, then they = can also sign calls from favored peers not on the whitelist. (IOW, they = can *lie*, assuming the lie won't be checked, instead reinstituting a = transitive trust model.) That will allow them to further extend their = business lock in and discriminate against whoever they want. >=20 > It seems especially bad to enable an environment where signatures can = be made by signers who don't have authority over the signed TN. >=20 > I would like to see a system where verification doesn't depend on = whitelists. (However blacklists could be used to reduce verification = cost for bad actors.) >=20 > (I guess ultimately whitelists must exist at some level, but better be = only at the very top of the delegation chain.) >=20 > Thanks, > Paul >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Jul 23 18:12:56 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244EF1B2D6D for ; Thu, 23 Jul 2015 18:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.887 X-Spam-Level: X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 bTqgfscpVgH2 for ; Thu, 23 Jul 2015 18:12:47 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605371B2D67 for ; Thu, 23 Jul 2015 18:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=70mSndEalEQFHlBzW8hiMPnAQ0kmWIWp5FrrlezTfdU=; b=kS1U9kd21Z11M1HQVr3cZtrEz1wgFcY0SqM2FnR0qoL6RaQz39kRhEXQr3+H9TGTJlxJRX1GDpyTI5s5j8OdhPNDvS7RoqHIhcWb73tFuZNBsJanOC/P5N7L0yub2diRQNNQayYCJhXq1UeS8kcStOIHROZ8z114ynsdPmWFSuQ=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:51992 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZIRXX-00076N-8U for stir@ietf.org; Thu, 23 Jul 2015 18:12:47 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Eric Burger In-Reply-To: <55AD37AA.1050205@nostrum.com> Date: Thu, 23 Jul 2015 21:12:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55AD37AA.1050205@nostrum.com> To: stir@ietf.org X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [stir] Transaction Rates (meeting minutes) X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 01:12:48 -0000 Just a clarification. As reported in the minutes, I stated that if STIR = ended up making OCSP or other per-call queries, that would put a = transaction rate of 100k transactions PER SECOND. 100k per hour is old school. 100k per minute is challenging. 100k per second is stupid. > On Jul 20, 2015, at 2:02 PM, A. Jean Mahoney = wrote: > Eric: The alternative in the draft is you poll at a transaction rate = of 100,000 tps for a typical U.S. busy hour to ask someone else if the = cert covers the TN. Not a realistic model. So it is not the issue of = carrying the TN, but that anyone cares about the TN at all. (TN in the = or covered by the cert. Of course, the whole point is validating the TN) >=20 > Jon: I think we should take the discussion to the list. At a high = level, it won't matter to you. But it's to support use cases, that the = cert is associated to TN. This charter is not of use for you. >=20 > Brian: 100k/hour or minute is no big deal. We can do that. From nobody Thu Jul 23 18:12:57 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463871B2D61 for ; Thu, 23 Jul 2015 18:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 V9M_4i5vIXKG for ; Thu, 23 Jul 2015 18:12:50 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7ED91B2D67 for ; Thu, 23 Jul 2015 18:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=/giqCATPUzHlAg0kvUAfIWH574KONjpK+kt2boQL02w=; b=l/15HRgFYj+U6WTX6Fi3H90WefstwgTPZYfHlXDGcWRzBt6DK/b+dpCrEA9oKKTdSbYj8zs5Cw2ONT/sljz1xzvmR8rYueqihTvZZ7w2J8d8f8P4G1he5ek0btCz1LnUxU5qyis8XgD92Lz9D9FmPbQ4pNNMtbAeGfY4S3sdHbA=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:51992 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZIRXb-00076N-H9 for stir@ietf.org; Thu, 23 Jul 2015 18:12:49 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Eric Burger In-Reply-To: Date: Thu, 23 Jul 2015 21:12:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C9C27A4-2D34-4308-82D6-BD1B25FEA217@standardstrack.com> References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <55AE5BCF.8080304@alum.mit.edu> To: stir@ietf.org X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [stir] Policy Revisited X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 01:12:51 -0000 On the one hand, I 1,000% agree with Paul. On the other hand, NONE of = this is in scope for STIR. All we do is provide the marking. If in = Country A the service provider is barred from blocking calls, fine, the = customer=E2=80=99s UAS can deal with it. If in Country B the service = provider offers a premium service to block such calls, great, the = service provider can block them. If in Country C there is a robust free = market of services providers offering CPL scripts to Joe Sixpack so he = can program his own enhanced service, great, Joe can have at it. The point is NONE of this is anything we should be saying anything about = in a protocol document. It would be great in a Gee Whiz Look At How Cool = STIR Is document. > On Jul 21, 2015, at 10:48 AM, Paul Kyzivat = wrote: >=20 > On 7/21/15 10:00 AM, Richard Shockey wrote: >=20 >> Third if the call is blocked then the originating party should have = some >> indication that the call was blocked and why. That will require some >> modifications of the REASON headers. >=20 > IMO "should" is too strong here. Telling the calling party they have = been blocked is one policy that might work for some callees. So having = additional mechanisms to communicate reason to them are fine. But some = may want to use another policy. E.g. >=20 > - allow the call to appear to the caller as "ringing" until the caller = decides to hang up. (But without bothering the callee at all.) >=20 > - route the call to a special voice mailbox and record the message for = future analysis. >=20 > - route the call to what appears to be a voice mailbox, but that = doesn't bother to record the media at all. >=20 > All of these could be accompanied by keeping a log of such calls. >=20 > My point is that this ought to be a policy decision by the *callee*. >=20 > Thanks, > Paul >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Jul 23 18:12:58 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBE41B2D6C for ; Thu, 23 Jul 2015 18:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 EcThufadd_Gu for ; Thu, 23 Jul 2015 18:12:52 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E80C1B2D67 for ; Thu, 23 Jul 2015 18:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=MjIAcrJCR7ewffGu/rAZ8Rj//EVG3pggfOhCLeVRY3w=; b=FgGGy5PfwO66P87FslVjouFnAYCmW3z2aNtK0eb/A+dNO001GNOFELGW9k3A9aLyfIxWWGppuPIb9UGaKE99O2k1f4BhTiZkKYMHFMciVSzr76Nag+MMGcrEpR68XSPXLK+ITMeHN79QU/7YMNNZOSvAUTJXD5R3ZAic3DSKCSo=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:51992 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZIRXe-00076N-Nr for stir@ietf.org; Thu, 23 Jul 2015 18:12:51 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Eric Burger In-Reply-To: <38726EDA2109264987B45E29E758C4D60585352B@MISOUT7MSGUSRDD.ITServices.sbc.com> Date: Thu, 23 Jul 2015 21:12:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <143B2973-22E7-4C4D-8A7C-8C95FA6FB832@standardstrack.com> References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <55AE5BCF.8080304@alum.mit.edu> <38726EDA2109264987B45E29E758C4D60585352B@MISOUT7MSGUSRDD.ITServices.sbc.com> To: "stir@ietf.org" X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: [stir] Policy revisited again X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 01:12:53 -0000 Like the subject says, this is a policy issue, not a STIR issue. = Carriers and subscriber=E2=80=99s UAS=E2=80=99 and service bureaux will = do whatever STIR enables. We absolutely cannot be in the business of = setting policy! Now, the point that we may need new status codes is correct. More = especially with PSTN-IP interworking, we may need to prepare a liaison = with ITU-T to add some SS7 ISUP cause codes. > On Jul 21, 2015, at 10:56 AM, PFAUTZ, PENN L wrote: >=20 > Paul, > I have some concerns about approaches that mislead the caller about = what is happening: > 1. In the US, carriers are now required to report on rural versus = non-rural call completion and non-answered call disposition. What you = propose might skew these statistics > 2. Although the FCC has said that carriers may block calls at customer = request, it is not clear that this extends to sending back what is = essentially false signaling - explicitly prohibited in the order. > 3. When calls are failing without explanation, calling customers = including legitimate telemarketers - unwanted as they may be - may = complain to their carrier resulting in wasted network investigations. = Some blocking services already this this result. >=20 > I'd be interested in Henning's take on this... >=20 > Penn Pfautz > AT&T Global Connection Management=20 >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, July 21, 2015 10:49 AM > To: stir@ietf.org > Subject: Re: [stir] stir 93 meeting minutes >=20 > On 7/21/15 10:00 AM, Richard Shockey wrote: >=20 >> Third if the call is blocked then the originating party should have = some >> indication that the call was blocked and why. That will require some >> modifications of the REASON headers. >=20 > IMO "should" is too strong here. Telling the calling party they have=20= > been blocked is one policy that might work for some callees. So having=20= > additional mechanisms to communicate reason to them are fine. But some=20= > may want to use another policy. E.g. >=20 > - allow the call to appear to the caller as "ringing" until the caller=20= > decides to hang up. (But without bothering the callee at all.) >=20 > - route the call to a special voice mailbox and record the message for=20= > future analysis. >=20 > - route the call to what appears to be a voice mailbox, but that = doesn't=20 > bother to record the media at all. >=20 > All of these could be accompanied by keeping a log of such calls. >=20 > My point is that this ought to be a policy decision by the *callee*. >=20 > Thanks, > Paul >=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 From nobody Thu Jul 23 18:45:26 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925BD1ACD02 for ; Thu, 23 Jul 2015 18:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 vbamj3la7ASm for ; Thu, 23 Jul 2015 18:45:24 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id EDCDB1A0363 for ; Thu, 23 Jul 2015 18:45:23 -0700 (PDT) Received: (qmail 28764 invoked by uid 0); 24 Jul 2015 01:45:16 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 24 Jul 2015 01:45:16 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id w7RA1q0031MNPNq017RDRM; Fri, 24 Jul 2015 01:25:16 -0600 X-Authority-Analysis: v=2.1 cv=Qc314Krv c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=bfLuiRfvAAAA:8 a=gdd6rViaMD1pyygYYMQA:9 a=Xv8ogJDteiW7jWXQ:21 a=hq6inmelKMQEWFHv:21 a=wPNLvfGTeEIA:10 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:To:From:Subject:Date; bh=XX+7lEeDtZZfKaX7KagZyvmrfzLAp6pJfMyHXEaVVM8=; b=B4G+Azwx9jGEF4Itz0gULvL5QypzLYTOdhGjZgnD1J6FNe5i3yQDNCctSvf99Gzx1DlzKkLiXmYpeUbx82cFKcdEDpA+ja4xuiBBs56LRYo0/Jp3dS7JfIuI73Nu7c79; Received: from [100.36.26.202] (port=57827 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZIRja-0003aw-JB; Thu, 23 Jul 2015 19:25:10 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Thu, 23 Jul 2015 21:25:06 -0400 From: Richard Shockey To: Eric Burger , "stir@ietf.org" Message-ID: Thread-Topic: [stir] Policy revisited again References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <55AE5BCF.8080304@alum.mit.edu> <38726EDA2109264987B45E29E758C4D60585352B@MISOUT7MSGUSRDD.ITServices.sbc.com> <143B2973-22E7-4C4D-8A7C-8C95FA6FB832@standardstrack.com> In-Reply-To: <143B2973-22E7-4C4D-8A7C-8C95FA6FB832@standardstrack.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: Re: [stir] Policy revisited again X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 01:45:25 -0000 On 7/23/15, 9:12 PM, "stir on behalf of Eric Burger" wrote: >Like the subject says, this is a policy issue, not a STIR issue. Carriers >and subscriber=B9s UAS=B9 and service bureaux will do whatever STIR enables. >We absolutely cannot be in the business of setting policy! > >Now, the point that we may need new status codes is correct. More >especially with PSTN-IP interworking, we may need to prepare a liaison >with ITU-T to add some SS7 ISUP cause codes. LOL .. Oh that=B9s funny Eric modify ISUP cause codes ..that is the funniest thing I=B9ve heard all day other than the latest Donald Trump quote. > From nobody Thu Jul 23 18:50:36 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5221B29C7 for ; Thu, 23 Jul 2015 18:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=ham 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 x1RlB2RfxD5D for ; Thu, 23 Jul 2015 18:50:34 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 00C381B29C3 for ; Thu, 23 Jul 2015 18:50:33 -0700 (PDT) Received: (qmail 22914 invoked by uid 0); 24 Jul 2015 01:50:32 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy1.mail.unifiedlayer.com with SMTP; 24 Jul 2015 01:50:32 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id w1WU1q00W1MNPNq011WXmV; Thu, 23 Jul 2015 19:30:32 -0600 X-Authority-Analysis: v=2.1 cv=NJxGpSKg c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=bfLuiRfvAAAA:8 a=DqnqxliYpsdpYAqDW5UA:9 a=BjppReCRDDGCTvj_:21 a=ovfW7UpBLWIO8uTU:21 a=wPNLvfGTeEIA:10 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:To:From:Subject:Date; bh=gzo/hKMeqXHCvzIAwX9DbHz3NMswFkSjTchPUnDX5sQ=; b=gdhk8QGBjeVfx+uSTY91iAA6Z8iZA1Pe7z31TIQPzuPLJoN3yumexXIU9yNvQmgJDaxuBGdZ/wfncynxMgNm1dknONnszhOVnNtOl6OWCug+fsbLyfh1Gx50U/bdfwNq; Received: from [100.36.26.202] (port=57850 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZIRoi-0006UP-OE; Thu, 23 Jul 2015 19:30:29 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Thu, 23 Jul 2015 21:30:24 -0400 From: Richard Shockey To: Eric Burger , Message-ID: Thread-Topic: [stir] Policy Revisited References: <55AD37AA.1050205@nostrum.com> <55AE37C0.4050307@yaanatech.com> <55AE5BCF.8080304@alum.mit.edu> <8C9C27A4-2D34-4308-82D6-BD1B25FEA217@standardstrack.com> In-Reply-To: <8C9C27A4-2D34-4308-82D6-BD1B25FEA217@standardstrack.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: Re: [stir] Policy Revisited X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 01:50:35 -0000 Exactly finish 4474bis and then we are done. On 7/23/15, 9:12 PM, "stir on behalf of Eric Burger" wrote: >On the one hand, I 1,000% agree with Paul. On the other hand, NONE of >this is in scope for STIR. All we do is provide the marking. If in >Country A the service provider is barred from blocking calls, fine, the >customer=B9s UAS can deal with it. If in Country B the service provider >offers a premium service to block such calls, great, the service provider >can block them. If in Country C there is a robust free market of services >providers offering CPL scripts to Joe Sixpack so he can program his own >enhanced service, great, Joe can have at it. > >The point is NONE of this is anything we should be saying anything about >in a protocol document. It would be great in a Gee Whiz Look At How Cool >STIR Is document. > >> On Jul 21, 2015, at 10:48 AM, Paul Kyzivat >>wrote: >>=20 >> On 7/21/15 10:00 AM, Richard Shockey wrote: >>=20 >>> Third if the call is blocked then the originating party should have >>>some >>> indication that the call was blocked and why. That will require some >>> modifications of the REASON headers. >>=20 >> IMO "should" is too strong here. Telling the calling party they have >>been blocked is one policy that might work for some callees. So having >>additional mechanisms to communicate reason to them are fine. But some >>may want to use another policy. E.g. >>=20 >> - allow the call to appear to the caller as "ringing" until the caller >>decides to hang up. (But without bothering the callee at all.) >>=20 >> - route the call to a special voice mailbox and record the message for >>future analysis. >>=20 >> - route the call to what appears to be a voice mailbox, but that >>doesn't bother to record the media at all. >>=20 >> All of these could be accompanied by keeping a log of such calls. >>=20 >> My point is that this ought to be a policy decision by the *callee*. >>=20 >> Thanks, >> Paul >>=20 >>=20 >> _______________________________________________ >> 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 From nobody Fri Jul 24 09:50:47 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC091A1EFE for ; Fri, 24 Jul 2015 09:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=ham 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 JFjRLHV2ExHS for ; Fri, 24 Jul 2015 09:50:43 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 668B01A19F2 for ; Fri, 24 Jul 2015 09:50:43 -0700 (PDT) Received: (qmail 24829 invoked by uid 0); 24 Jul 2015 16:50:41 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy4.mail.unifiedlayer.com with SMTP; 24 Jul 2015 16:50:41 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id wGWX1q00T1MNPNq01GWagE; Fri, 24 Jul 2015 10:30:39 -0600 X-Authority-Analysis: v=2.1 cv=O9qq4nNW c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=UG6zi0Y7LArFwzsnx1cA:9 a=EUFgBh6xLkcO7EYg:21 a=Htg-76pu0iZppsab:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=jM_x9b4JT8QA:10 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:Message-ID:To:From:Subject:Date; bh=cZLc/EKZumyvOEEjMguHQrBtYzBn9m7js8mvoa7aREY=; b=EEJSnu8FN9oSaW918Db6X/RyVD0H0dUENe6zO2tofQOLAZw2d+bbPwWhsHoR3lVICGdD7rcj4+yKzzAXUgaybG170mEc758RLsxIV8lJRYfvIAYAzA1ExKpOdsFcVK35; Received: from [100.36.26.202] (port=51728 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZIfrk-0005fS-Rf for stir@ietf.org; Fri, 24 Jul 2015 10:30:33 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Fri, 24 Jul 2015 12:30:28 -0400 From: Richard Shockey To: Message-ID: Thread-Topic: I-D Action: draft-ietf-sidr-rfc6485bis-03.txt In-Reply-To: <20150724133255.23566.85626.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Subject: [stir] FW: I-D Action: draft-ietf-sidr-rfc6485bis-03.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 16:50:45 -0000 FYI .. Something to keep in mind. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 7/24/15, 9:32 AM, "i-d-announce-bounces@ietf.org on behalf of 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 Inter-Domain Routing Working >Group of the IETF. > > Title : The Profile for Algorithms and Key Sizes for >use in the Resource Public Key Infrastructure > Authors : Geoff Huston > George Michaelson > Filename : draft-ietf-sidr-rfc6485bis-03.txt > Pages : 9 > Date : 2015-07-24 > >Abstract: > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size, and signature format for > the Resource Public Key Infrastructure (RPKI) subscribers that > generate digital signatures on certificates, Certificate Revocation > Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and > certification requests as well as for the relying parties (RPs) that > verify these digital signatures. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-03 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rfc6485bis-03 > > >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/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sat Jul 25 16:12:49 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2A91A8842 for ; Sat, 25 Jul 2015 16:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.532 X-Spam-Level: X-Spam-Status: No, score=-96.532 tagged_above=-999 required=5 tests=[BAYES_80=2, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 l4-bUWydS1xK for ; Sat, 25 Jul 2015 16:12:46 -0700 (PDT) Received: from msk-mail-app01.ti.ru (msk-mail-app01.ti.ru [89.20.149.130]) by ietfa.amsl.com (Postfix) with ESMTP id CE4B71A8841 for ; Sat, 25 Jul 2015 16:12:44 -0700 (PDT) Received: from [151.252.69.42] (account fas_vm@surguttel.ru HELO surguttel.ru) by msk-mail-app01.ti.ru (CommuniGate Pro SMTP 5.2.20) with ESMTPA id 13069743 for stir@ietf.org; Sun, 26 Jul 2015 02:12:41 +0300 From: "Anton Tveretin" To: stir@ietf.org Date: Sun, 26 Jul 2015 04:12:15 +0500 MIME-Version: 1.0 Message-ID: <55B417CF.9646.1136FA86@fas_vm.surguttel.ru> Priority: normal X-mailer: Pegasus Mail for Windows (4.70) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Antivirus: avast! (VPS 150725-1, 25.07.2015), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [stir] Small Carriers? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 23:12:47 -0000 Hello All, Just few thoughts. In Russia, SMS spammers are licensed as carriers. (At least they advertise as "licensed"). So they get SS7 links. Maybe I am completely wrong, I do not know the situation. So, we must track carriers, not just trust them. Thus, hop-by-hop authentication is required, possibly in addition to other mechanisms. But this is more a matter of policy, not protocol. For instance, the network must validate each SIP message coming from a user equipment (UE). The network already authenticates the user somehow (not each message). This is an "asserted identity", even though it never appers in the PAI. Checking of From-URI in a request or To-URI in a response results in: 1. From-URI or To-URI matches the asserted identity. 2. From-URI or To-URI matches another AoR of the asserted user. (E.g. an alias.) 3. From-URI or To-URI is trusted (see "the doctor problem"). From-URI is trustor, the asserted identity is trustee. 4. From-URI or To-URI is anonymous. It could be considered as a sub-case of (3). 5. Anything else means an attempt to spoof. Best regards, Anton. From nobody Mon Jul 27 15:13:48 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D35B1B34D9 for ; Mon, 27 Jul 2015 15:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 8kX4YAwuKceG for ; Mon, 27 Jul 2015 15:13:45 -0700 (PDT) Received: from mail-vn0-f41.google.com (mail-vn0-f41.google.com [209.85.216.41]) (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 C76A61B34D8 for ; Mon, 27 Jul 2015 15:13:44 -0700 (PDT) Received: by vnk197 with SMTP id 197so36304933vnk.3 for ; Mon, 27 Jul 2015 15:13:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=84VOBIwjqx/thuPn/EobSGU9wBXrH3XoEqvHhgQeILc=; b=KBTW9T7xLOL7owXKpyrPMBGGsC9PNjrKW0jNvbo6k4voH3bl86lbLpYeaTjAENH5aC qOIbK3ArZWuQ1zK5fXQEWj8d2joZJceBp4O13fTzuWiF1WVu1IiDdQ2wQxrakrRTMiTu j+8NwzP9dtGo16+bl8zwZo/7EltRLUyUpQ11p0iLzVe9c2m7h8V6fqoENXPdjyCaBW4J DlkApHPEm0bNnwkFWh1bOssH/V5ZFhk/UEGjCgFf8Gcp8Hc4TZ0PuGS9orI9o6hDiaKe tgIF4QpR0rytRTze0/b7fCaKZnXYPIyiDOLKKH1Cf85vJe8CBDoXsLVLLRl5uvE27trt 760w== X-Gm-Message-State: ALoCoQnX8B31s6B4vB5S4loxmhxqlTaj9yXUIviBvXADeEPEqbZYgYjLR7KL0HAr09QOKomqrAiA MIME-Version: 1.0 X-Received: by 10.52.69.241 with SMTP id h17mr38891910vdu.68.1438035224057; Mon, 27 Jul 2015 15:13:44 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Mon, 27 Jul 2015 15:13:43 -0700 (PDT) Date: Mon, 27 Jul 2015 18:13:43 -0400 Message-ID: From: Richard Barnes To: "stir@ietf.org" Content-Type: multipart/mixed; boundary=20cf307cfd3cb48ef8051be2aa55 Archived-At: Subject: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 22:13:47 -0000 --20cf307cfd3cb48ef8051be2aa55 Content-Type: text/plain; charset=UTF-8 After the STIR meeting in Prague, Henning and I spent a few minutes talking through options for revocation checking and certificate scoping, and I think we have a better idea of what the optimal solution looks like. Some notes are below, and some slides with pictures attached. tl;dr: We should: * Keep TNs in certificates and not bother with any OCSP extensions * Require Identity-Info to include OCSP responses for all certs in the chain # Background: Revocation in the web PKI In an HTTPS transaction, the HTTPS server provides the client with a certificate, and it can optionally include an OCSP response ("staple" it to the transaction). A certificate contains a validity interval, a key, and some names/TNs. An OCSP responses contains a validity interval, a certificate ID (i.e., a hash), and a status (good/revoked/unknown). In the web PKI, certificates are required to be no more than 39 months long, and OCSP responses no more than 10 days. Ideally, a client only considers a certificate valid if it is accompanied by an OCSP response. In practice, this is not always possible; because OCSP queries fail around 3% of the time, browsers can't require OCSP. This operational fact will be important below, but we will continue to have scoping cert lifetimes as an objective. In the web PKI, there are basically three revocation checking modalities: 1. Live OCSP checking [RFC6069] 2. OCSP stapling / must_staple [RFC6066, draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP lifetime) (The last of these is relatively novel, and has not been deployed. Neither has must-staple. But they're both pretty trivial, and could be folded into a STIR architecture pretty easily.) Right now, about 90% of TLS transactions use live OCSP, and about 10%. CAs and browsers dearly want the world to move toward stapled OCSP or short-lived certs, because these reduces latency and improve the quality of revocation information. Revocation for CA certificates is currently done by having browsers download a list from a centralized server, since there's no way to staple more than one OCSP response. That solution works OK for the web, but if I were designing something de novo, I would probably use multi-stapling as well. # Applying this experience to STIR Most of the below appear to be desired properties by the WG: * Verifier neeeds to know that a cert is valid for a specific number * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if issued longer) * Caller privacy: Don't report what calls someone receives to a central server * Carrier privacy: Don't allow a third party to figure out all the numbers a carrier holds * Minimize the rate at which the CA has to sign things * Tolerate outages at the CA I'm going to assume for now that we will not do live OCSP. It violates the caller privacy requirement, and as discussed above, it just sucks operationally. So STIR should require OCSP to be sent in "stapled" form, which probably means sending it in Identity-Info. And while we're at it, we should also do "multi-stapling" -- send an OCSP response for CA certs as well. So if we consider a server with 50k TNs / blocks, that leaves us with basically 3 options: 1. 50k short-lived certs (no OCSP) 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 long-lived cert not scoped to TN (or a few loosely scoped) + OCSP with TN info (As I didn't quite get to say in the meeting, regardless of the approach, you have to have 50k of *something*.) Of these, it seems like the preference order is 2 > 1 > 3. Option 3 is bad from several perspectives: * Putting TN info in the OCSP response enables someone to trawl for numbers unless you access-control the OCSP server, so you inherit a requirement to do that. * With the rate of churn in number assignments, you're probably going to have to update the long-lived cert pretty frequently anyway. * Putting TN-specific stuff in certs is better than putting it in OCSP. As bad as X.509 libraries can be, OCSP libraries are much worse. Option 1 is mainly bad from the perspective of CA load and outages. With Option 2, if the CA goes down, client can continue to use the long-lived cert and just not bother doing OCSP (vs. tolerating an expired cert). Slightly cleaner. Plus, there's a lot more experience caching OCSP than new certs. OCSP signing can also be delegated, so you can have the recurring operation done by a lower-risk key. Option 2 should be pretty easy to automate. You can probably re-use tooling for OCSP stapling that has already been developed for use with HTTPS. If you're a big box signing for a bunch of numbers, you do need to select the right cert and OCSP response for a given call, but that's a pretty simple lookup table. --20cf307cfd3cb48ef8051be2aa55 Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="STIR.pptx" Content-Disposition: attachment; filename="STIR.pptx" Content-Transfer-Encoding: base64 X-Attachment-Id: f_icmh1i5p0 UEsDBBQABgAIAAAAIQB2RcsbAAIAAE8PAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM l91u00AQhe+ReAdrb1G8SYHSVnGqqsAV0EotD7C1J8nC/ml3Epq3Z2yH1ERpXce2khtbm/XM+WZs nc2MLx+1ipbgg7QmYaN4yCIwqc2kmSXs5/3XwRmLAgqTCWUNJGwFgV1O3r4Z368chIiiTUjYHNFd cB7SOWgRYuvA0M7Uei2Qln7GnUh/ixnwk+HwlKfWIBgcYJ6DTcafYSoWCqMvj/RzSULhLLoun8ul EiacUzIVSKA83+U74345mG0FSp0LFxu7Yx6k2Qqpai1NtlXQwE6nMoXMpgtNZcTOQ6B7gaYVLSWV 5+8AkboYngH1oEIzVVe2MKbIQirMpQvv1q24oXfoZQbRrfD4Q2hqGHcOeZUtfrmpexT6VHeshTR1 MEER4XcRqDuBVxajrskquV/FtKbph6MJwUkvnWhC8P7gBB8OTvDxIASp1bmdXC1wbn3oGuH/7HVf RG4bt966zjE2iesIlhL+9EKwSVxHgHSYAS+u7Y2hSFOrKB4U3OFKQed9x6fUdRSFeX4TK7vAtS+W i/ZNqB5GdFBWhPZl6scvy3r3ZerHQdsx9eOp7Zj6cdl2TKdd224H3/inI2Q6O0Km8yNkGg2PEepQ Tk4TU3Gk0wDooXlj/g1AefTA0b8T8CjhxRFoo0gTXXPBrTkP8vE0g2yHNi/G4clfAAAA//8DAFBL AwQUAAYACAAAACEAo+yCJg0BAADiAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySwU7DMAyG70i8 Q+T7mm4ghNDSXRDSbgiVBzCJ2wbaJEo8tL09YYeVSqOaBMfY8Z/vz+/1Zj/04pNist4pWBYlCHLa G+taBa/10+IeRGJ0BnvvSMGBEmyq66v1C/XIeSh1NiSRVVxS0DGHBymT7mjAVPhALncaHwfkfIyt DKg/sCW5Kss7GX9qQDXRFFujIG7NDYj6EPLLf9GWAzEaZJTaR1qEmMki2+xF1BhbYgXG6+dcTscb RaYGeR7o9nIg3zRW06PXu4Ecn/Esac/kDJl5JAxhjmj5n0RT5vF/QmAZIqVs5Jj7HNDqcqDf92HM jLvd8ObQ9iPNKa1Tr3gP1H5nJiebWX0BAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAg AAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9C IJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJ w0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/OENKCucg0qojmgSOpU1V9qrRlQLtjiqvV kK62BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQcnvnrahleR9U26jd3PYPAAD//wMA UEsDBBQABgAIAAAAIQAUazuFvwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIueG1s LnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFi F7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRen DWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLq KGuQcn7nudjK8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAFGs7hb8AAAA3AQAAIAAAAHBw dC9zbGlkZXMvX3JlbHMvc2xpZGU0LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJ tm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFf acBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp /s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyvI+qKZWX3ObDwAAAP//AwBQSwMEFAAG AAgAAAAhAILFtG9bAQAAGAcAAB8ACAFwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzIKIE ASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvNXNbsIwDADg+6S9Q5X7GsrffkRBk6ZJ HCZNAx4gtKaN1iZRYth4+3lsg1JBdok42lHtT67ijCafdRVtwDqpVcqSuMMiUJnOpSpStpg/39yx yKFQuai0gpRtwbHJ+Ppq9AaVQPrIldK4iKool7IS0Txw7rISauFibUDRyUrbWiCFtuBGZO+iAN7t dIbcNmuw8VHNaJqnzE7zJGHRfGuo9f/F9WolM3jS2boGhSd6cCQYUEFhC8CU7cKfZBKTlPEziG5Q hFhWMMNtRbM8UA5JryQkxFUyhxfhEOwB0kg63gi8Awo6n13TFuiX4kX0gs/mNKLr+0H9CyF6PsTg Qoi+DzG8EGLgQ9yGRBgrFd2VGSDSfmxc3tYBb8VJvJTq3G6hBRtuv2W6/l59j2sstW0Aj/O+gd2H 5BgL7tVq05DsUz5EQs9QuKFsJHy0FPvUn4IfvWfjLwAAAP//AwBQSwMEFAAGAAgAAAAhABRrO4W/ AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc4SPwQrCMBBE74L/EPZu Uj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO 6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQ fDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MryPqimVl9zmw8A AAD//wMAUEsDBBQABgAIAAAAIQAUazuFvwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlk ZTMueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59 eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0 IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TB KTxzwWLqKGuQcn7nudjK8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEA14kgKnQCAAAxDQAA FAAAAHBwdC9wcmVzZW50YXRpb24ueG1s7JfhatswEMe/D/YOQl9H59hxbNfEKayjUOggLO0DqPal MZVlIylZ0qffnaI2WsKgD+Bvku/ur9PPfyvK/GbfSbYDbdpeVTz+PuEMVN03rXqp+NPj3VXBmbFC NUL2Cip+AMNvFl+/zIdy0GBAWWGxlKGMMqWo+MbaoYwiU2+gE+Z7P4DC2LrXnbA41S9Ro8UflO9k lEwmWdSJVnFfrz9T36/XbQ0/+3rb4fJHEQ3S9WE27WDe1YbPqIW7+LclI3aw2j4bsHe9sgbpcCa2 tr/tOyoyy7a2WxxUfMIXyMPI5pcwFvR982Ds2RPWNhVP4jRPi2mWIlRd0hPMjXm0mEf/KQ+l7puj yCwLqhOqdsUf4VB8ehnOg+r0MnwdhGcX4Qz98dF5RuFj52GfqzdW7yt+HafpZIL59aHiWTEr3MQe BnSRqTWASve+PdVbML7sI5PK3jXcHhtYi620j7C3K3uQsJiLEp8tl9qPfi81k4KMC+rqaeW6C1Pk TsYD5nRCP9BLY0K+oOklZyjzKJ5XbxVPZzm6EjdppUsB8aB+6Ff38sliyk8xZYNLoY+XW1Vbigdd GFSKccOcvYKm74o0KW562TZ3rZRuQt8I3ErNdgJXs/ujFc6y3KqMuK1Fjey+depKWtqcKEGcBUAc A7U5C9TmhAM54XsTpedBQjhMTmjeIYx8CIrnMz3xOdpy9M9OEhTPJz3xiad5nJH7RwMRFQ9oFgAq ksIdDyMgouIBZSdASVKggUYH4blMVDygPACUp1P3QzU6iKh4QMUJENHB+8d4Bu0kUfGArgNA2Swf D2l39SEq7iZ7ecXE6234D2HxFwAA//8DAFBLAwQUAAYACAAAACEAROmA1zgGAACAHAAAFQAAAHBw dC9zbGlkZXMvc2xpZGUyLnhtbOxZbW/bNhD+PmD/gdCnDoNr690y4hSx2hQFujRI0h/ASHSsVSIF inZsDPvvu6NE+SWKU7tN0w0DAkWWeMe703PH58iTN8siJwsmq0zwsWW/HliE8USkGb8bW59vzntD i1SK8pTmgrOxtWKV9eb0119OylGVpwSkeTWiY2umVDnq96tkxgpavRYl4/BuKmRBFfyUd/1U0nvQ WuR9ZzAI+gXNuNXIy6+RF9NplrC3IpkXjKtaiWQ5VWB5NcvKymgrv0ZbKVkFarT0lkmn4Flynaf4 vypvJGN4xxfvZXldXkr9+mJxKUmWQrwswmkBYbH6zYtmmP7JYRjc9HfE74wmOlpOZXF6QkfgG1mO LQj+Cq8gREdsqUhSP0zWT5PZp46xyexdx+i+mQAsaCdFr2qPHrrjGHduMpUzYrde1UMpiH4UyZeK cAF+ovu1e8nFwihDn1F9OSNqVUJkFKpqxtUvdTzM+ApiqoOllhORrtDxW/ivH9JRXqlrtcqZDgiY TUegHC4Q/pwiQhnvfb62SJpJpWNEqkLFOaOA5SaM6jRmUpHfyaf4+vIEQqLgizR6GE8vqaRXj6pD 9+gIJgabjYFwW0fw8Ti6Jo5XYs5TlpIrlkAO3UFMna2Yas83YbIZFvR0ByB26Hi+52mY2EEYhv4O WOzh0HYdwBFCxrG9Ifzp4K9VlbJS75koCN6MLYkmon0WzkcXHyvVeN2M087jZ8LPWuHXwIE5v2JT yAEAqK0ldeazOJdkQfOxRZME0qsGSDMaxaZZnreC7tOCzXgUZdMpWNkKO08LtxJ6ZsHXwkXGhexS kLcmT+vxtfe112sMGJASqfJYgLsQccqTmYBKliiJEe8CLwSR0PwOwNkOkjhyD56ZBJU6jIhcvgPg r5TuygqhJgzKM9vR+GRK7Oqq80MnCVx+KgfPporJF/ZPI0GdljtmPPXhOsrY/DbPEvKFrXZU/fAv 1mEbLoL9m4tX1W+HGtfUmkMrLJTAeuF9WGHdb6qwnu+HQ8f/11RY7S3koK7Hus5tVtg9RdIIPl5h 99R1I3xEhU2/mEXh56qwu3UNy20CzOHD20MhvavpWytkV74JRW4flu9nmok+qKPPMBE0GWpeHRrr I8sH5HddPm6AZU/EknhbRYMg19PMBvQje1/z+KcIWjC0Bz60BUC/vIEbhI5OlTWbt31nECKDQ4IW eIHrmnQwVG+Xn+2lZnTExTlkPMYBeWnN0gxVbWnKvaRA1zl0cNYGZcFyUZVncwUqGtJXc+/vxl46 oItsfOsrPwOWXlXZHQfafbsiW1Md1z6cfd9FLVny66YDi/F2t6eEhrvGZjyXC3AiFpwDBoQkYQvS VhA+oIIfuhmFrkPzcYM4npo3ALeGqdc4gX6t1bAN743HNZjWfUPTo7rBwB8GdQvihL49dHTurBEe +XYUQAYgwG0nHOgOBT7yI/hOtJetk3VPoNsQROFd2gSDpn+CzmmRw14DNBjEd6OhWYWa0QiktmfB FREVzBhN3/G0aUaplOK+ZueKZnnHC1CCghvJ1NXy7FlXTTp3L8iDrqZju1c6akE2sx6xIKulEe5Y kCEOicHr4/2uDe1Pg9lczFMStUBFeB9cQ4eBH3iAZqyhkQe3uoVdI8wObC+MohpikTcIIw3BPRhD q3Tk/+9v93zsl+hvO1YISO8s3anbtwc2TICFRgSLwJ7+umN+u+eSFaPyR5ERu91FjHX2QDbplGl2 1Q5Nn80Opjt9ogj2kJo9ohdNH1PAu2vlniJrBI+qlUb4iFr50zUvHfB96fQJe/aApHT1w9InMIuP IfO2v5VAx7N5zw08JwwfZ/OOEwVhYFLJcV33CbYj/2NsHjfVCRyllHAGs72ViGwMa299OXxfsAPZ G7Q+PiNAiLcWiWeYUHunewlJ5rCRL0n8XZsBzTLNERN0orD3jv0mnvzMZTa2/ppMosCJh5PexPbO e97bKOydnQd+79x3PS+eDM9i993fQGxK2xslkunTrA/mVA4ePjgJK7JEikpM1etEFP36SK1finsm S5HpUzV70BzN6W38wAlsOFCw9bEFmAumaXJsjEV+2ByWJbn8g5afFnqlhjNA2HuF0wB4VMKpX9N3 rIeg63DI9g8AAAD//wMAUEsDBBQABgAIAAAAIQAitWCFegIAAPIFAAAVAAAAcHB0L3NsaWRlcy9z bGlkZTEueG1stJTbThsxEIbvK/UdLN+HzQkIq2wQG0hbiQZEwgMY74S16rUt2wlJq757Z71rUEOo uKA3e7BnxvN/npnx+baSZAPWCa0y2jvqUgKK60Kox4zeL2edESXOM1UwqRVkdAeOnk8+fxqb1MmC oLdyKcto6b1Jk8TxEirmjrQBhXsrbSvm8dc+JoVlTxi1kkm/2z1JKiYUbf3te/z1aiU4XGq+rkD5 JogFyTxm7kphXIxm3hPNWHAYJnj/ldIElfGFLOq3M0sLUH+pzRdrFubWhu355tYSUSAvShSrEAtN 2o3WLPwqNMOPZM/9MUZi6XZlq8mYpaiNbDOK8Hf1E51YCltPeLPIX1Z5eXPAlpdXB6yTeABm8Hxo rapR9FpOP8pZCi+B9J5VNaYMXa81/+GI0qizlt/I4/NNDFZrrsObkvidQTLc2xCtNW32A5Lo4hBr 4OW3uS52tfYHfIdFlkrnF34nITDBzFmK8fGBNyBZXaSgOvcLLNLKTyUwLOKWn58s54SD9QLrhnlw Y+Th8TraCKCKW2bZ3X6gQlgfeaMtHonZxtTws8H3NsRBhLhYP/jAsf8RHN36oeGIhYdVEdH/N57P GA6RvRO8ZLYgObNqD2yDLHB766r+GforKIVjgix4uZY/rVAKPvDiwv3FpsYOu3ZYESb02tqKjP7K 87OT/nSUd/LecNYZXp6ddi5mJ8ed2fFgOJzmo4vp4Oo3RZ/eMOUWwvz4FucgLr6aPZXgVju98kdc V0kzxBKjn8AaLcIc63XbYbhhMqNnw9P+YNTrj9qGwSRDBcZkUUEcT1za78zcbEJD4NT1YKdhySDA tjNfTGrpONb+AAAA//8DAFBLAwQUAAYACAAAACEAJtOMJ1UFAAAfGAAAFQAAAHBwdC9zbGlkZXMv c2xpZGU0LnhtbNxYbW/iOBD+ftL9ByufWmlTyAsQuLYrCKVaabetSvcHmGQg1iVxzjZQbrX//cZO AiztVq0KPbVfiGM845nHz4wnc/r5PkvJAoRkPD+znJOmRSCPeMzy2Zn1/W5kBxaRiuYxTXkOZ9YK pPX5/M8/ToueTGOC0rns0TMrUaroNRoySiCj8oQXkON/Uy4yqvBVzBqxoEvUmqUNt9lsNzLKcquS F8+R59Mpi2DIo3kGuSqVCEipQstlwgpZayueo60QIFGNkf7FpHP0LBqnsX7K4k4A6FG+uBTFuLgR 5u+rxY0gLEa8LJLTDGGxGtUf1TLzmuMyHDR2xGe1Jtq7n4rs/JT20Ddyf2Yh+Cv9i0K0B/eKROVk tJmNkutH1kbJxSOrG/UGaMF6U+1V6dFDd9zanTumUiDO2qtyKUXRrzz6W5Kco5/a/dK96GpRK9M+ a/VFQtSqQGSUVlWtK/80eNTrJWJqwFL3Ax6vtOMTfJpJ2kulGqtVCgYQNJv2UDn+IPwp1QyF3P4+ tkjMhDIYEZmpMAWKXK5gVOe38M+cCdCskaeIicIjqRRBHt9QQW9/q0/7R3u4MxpdW4jDEsKZoEXC opFACpSQXm7N7HLFW4NLJwiuuwZ3V4jiYW0U/w7wXSlNsnJLJM5XiU4WhkJzwc6sH0Pf7bud4cAe DD3H9gdBaAde37FH7YuLcOT6vuc6Py2UcfxexuMvdWTj+4NoylgkuORTdRLxrFGGZaPgSxAFZyYy nWYV3guaIkv8Ztt3va5nXEb00EADaG2oIYS23QweOrYTJS0vCFq+CRXHDTqub2i4CZhOtxX4OEl0 2Hhd320GhguovdZUAay5VA2HVFFisHpxJlP6PBE7ZNYkrR5IqCkTUt3ypckSE8yg1dis0CKG2V/i 8x/tbtNxL8Kh3XJGoe07I8fu94Oh7QxcP/DCYbvtXfw0zN0WMxOTVONmdr4UDJOWdojFIU8Jbuw2 PafV6Wqm/TLf6rrtoF0exy+ySpAEMes0A79ZehQZ7W8Rm8YfE27GoxeEJrqwNlBFZc7FudL0Aztw cV9gJjLXyCEc0OmqPOC3PpkbwRY0Wh3CqfXZrE9t3yn/LmEi3jHdwPjg5phQCSnTlQ1evk9eI6Sg QjGQ5AhOZiefyHU4vjkmMuFzrINyrsgEiMnsihM+kSAWQJYJJxFNU4hJDFKxkignO5bther/H1Nu QbKUYdUIh/Dr8GTRB7lj+au5wueKzmCbHXQ6hQgrOmQDSfA2QNLNyBHLo3Sui22CVyWLTR45/ovQ VHIiIJ5HyDeqlKCRLnMJn5LXWAoCK228GB8pkobXY7TiNcofUWpi5IOxfYwn+BCpvYTw21B9m5Q5 wN7TJKa/Z9HoyWQrEWVMn0wlz9L1gixuAnDBU/yK/GDMvOL7xuo1+p7INbJgMYh3G0SmuDDVwGo7 ljbX/2tgeyyLxqBAZFikmHoioZJINsuxplgmVJG7K/nBiBz2942gTifvlm9X82wCQt/9+tjRDYLd NVH2vWoCIvlkhqXFJ7KpKFQCJF/LhuNbSZQmzIGSPppQCI4Fi4T4oxGSZwXijd/sO8R8J9f+N5az jP0LeP74jZLxea40nXJYkgiEsk0bdf+VALaR9ZYV5ZB9XH8jLQVTCnJyJMCeSyB3X8dErzw+JGn0 15FuzuBzq+Gz/Y5j3SXdNN7MxKYDXDertrtqg0G37YYBdtUcf2T7w27H7o/aLXvU8nw/HAT9EBs3 VtlViwSYkN1vay1wglbX6/hVg/WRzlrdy45S8Y0W1wvzaYMterxSQjNVYEbRbU5se2+W4Bu298// AwAA//8DAFBLAwQUAAYACAAAACEAWXs7aDMGAAAyMwAAFQAAAHBwdC9zbGlkZXMvc2xpZGU1Lnht bOxb227bNhi+H7B3EHS1YVBtyfIRsQsfiwJZYsTpA9ASbXOlRI1knKRFL3vXR1hfrk+yn78k23Od NE7r5jD5wqKon4f/038kqaOXVxG3llQqJuK27b4o2xaNAxGyeN6235yPnIZtKU3ikHAR07Z9TZX9 svPrL0dJS/HQgtaxapG2vdA6aZVKKljQiKgXIqExPJsJGRENt3JeCiW5hF4jXvLK5VopIiy2s/by Lu3FbMYCOhDBRURjnXYiKScaZq4WLFF5b8ldekskVdANtv7PlDrAWTDhobmq5FxSakrx8pVMJslY 4uOT5VhaLAS8bCsmEcBil7IHGRnexkAGhdJW83neE2ldzWTUOSIt4M26atsA/rX5h0akRa+0FaSV wbo2WJzuoA0Wwx3UpXwAmMFqUMNVytHX7Hg5O+dMc2q5K65SUgJNj0XwVlmxAD4N+yl7wcky78zw bLpPFpa+TgAZbbrK6NKHiEdOrwBTBEtf9UR4bRifwhUrSYsrPdHXnCIgMG3Sgs7hD+DnxEgojZ03 E9sKmdSIkaUi3eeUgCxnMOrOaYIiYoEQW5L+fcEkNRKkjgAfDa8n65TG4ZhIcnZj34ZX0oJZAAP5 bKGYwjmXJFmwYCRBHFJ4X23UbMtNZQU0mQLQ3gro7UYEXty645vA325lBC4dEoToWAGTCYrThWRt +/3A97pefdBzeoOK6/i9Rt9pVLquM6oNh/2R5/sVz/1gQxvXb0UifJ1rOdx/pVkRC6RQYqZfBCIq pSpaSsQllYlgqKVuOVP1JeFtu1mrVF2v6TcziYD5IZ75PFE2zNSx8DVfWwrjV+tgTFBr3EqzXoYy igp0h7rT8LxmzRAYDaoAiV/JR857yvA1YpUVB0QTC6Ha26hp8zoBOhCsKc8uIE8zJpU+E5doMKYg h1kZKUwTFPLXYed9te95Vd/vOvXhsOb4Fd9zemW/4TSqvUG/ORq4/Ur3AwruZjOsmHKDG478SjKw X4YhFvYFt8zANb/a9DJ4Dltv1GrK8zloaS0A+3q54ZdTZAKc5d3UfQ+lhFFXfeogtbxQl462z5iI 4p4mpj8Zg20h3NEsovg60FhgV0+EB7UQUjucLWm4xcBuQKZEUc5MTAD6dasBtgIqv8fcPuSbhahn fkBQrD9MdJVwGlqnIENbwD8RyVljhG8aeArFZcwFCS0w+uyHixNnSh8CKWO4UNa/z2btVpdbNWQs 2ZIE14dgamUCV8bx1vgKwjGL8DnET4GWqTPdzY96B06lYXzrbs6MkVcC3v6IcXSFCfjAPpdGJNr2 lJPgLcYAW1Qmno8xdJyRAGxLNwHlAB8m5DASf7GsCVhndCKdL58/FaC19gXtn48FaE8XtIjIY3S6 UDjDAotDSGiwuNZdK6SzczKdgJ7mYbLUoHqgsZQcxz35FsPRmYh1FxWeXGhhQ14FCpg9BtIFpFmQ tY8v4gAGcG2jdjyeJBhQqSQYBzrVaBeC7zT8BjO6SdGjM7QFQKtVSothKJBB+/XT7gxSAazbRZc9 nV6ACTm/wiB/ejF5tyqOgI3VzQksVSAJxOOQ/mAR0IDUDoowLubxN+WSj8Sw7a+j27mvYRTZvSku BoIH8ndnVDHOYKHpMcTKhcu7R5L01EDbX50yU3GrBj3z4KoAzXi7PSPSw4D2cLZ6EkAOF8+LiHFv SShyk0ejPoWh3tooOZB3K3KTIje5y77cI85NToS15et2L4Ctl72ohA1s2AresfeoEhZSWbhPXDbY M5Aq3GfhPs2C0OEXkQ8Tsj/zmOMw6vlweU6/a6ki1ck2ax5H0nsPDSoC0P9DAPr5091itPVa/h1O K+Duw8GdjYW/3/qTs9+3wsxv7vZvB5jfDKLvoT/r/SPcNdkd+q5hXQfBm8Hvz0HyS+G27xEgPju3 LaIEEgs4RLevOh1oCaTQoMLs/JzFtkLSnrmkHdRWm0zLHFKG68bB5817KJsPB9bnz7Fi/VFEfmh7 83B5r9esef0GHC53/ZHjD5p1pzuqVZ1RteL7/V6j268M88PlAZyYNUfzf+gJc7fuVSvlml/Do2I4 NZx2PllgKf+8I+DyT5KcLjHIga9WNJVwugSqEliwM94BSNckcAdfvHT+BQAA//8DAFBLAwQUAAYA CAAAACEA8zHE+I0JAADfLwAAFQAAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbOxa23LbOBJ936r9BxSf MrvriPeLKs5UpMSzqcqtbGdr9hEmIYkViuSAkGzv1v77HgAEJcqS5YucSc3YD7YsogF0sw/6dKNf /Xw1L8iS8SavymPLeWlbhJVpleXl9Nj6en5yFFukEbTMaFGV7Ni6Zo318+u//uVVPWyKjEC6bIb0 2JoJUQ8HgyadsTltXlY1K/FsUvE5FfiXTwcZp5eYdV4MXNsOB3Oal1Yrz+8iX00mecreVulizkqh J+GsoAI7b2Z53ZjZ6rvMVnPWYBol3dvSa2iWnhWZ/NvU55wx+alc/sLrs/oLV48/Lb9wkmewl0VK OodZrEH7oB2m/i0xDB8GG+JTMxMdXk34/PUrOoRu5OrYgvGv5W8I0SG7EiTVX6arb9PZ5y1j09m7 LaMHZgHsoFtUaqU1uqmOa9Q5z0XBiNNppYdSiH6o0m8NKSvoKdXX6qWflmYyqbOcvp4RcV3DMkJO 1Y7TD5U9zPgGNlXGElejKruWil/gr/qSDotGnInrgimDYNt0iMnxC+YvqPRQVh59PbNIlnOhbESa uRgXjMKXWzOK12fn708J5eksFywVC85ewTAC76WdjZXZF8rp6c5JpZJ0iOWxc7NNfNR23G1N31jz tFqUGcvIKZbHrmFZr2dZpf+6s6wbR+q74SahF9uxA9+Dyl4SOJ4XyvlWLuMEYRSFkUWk4zhuHESB WrFzCGjDG/ELq+ZEfji2uNyi3J8l56HLD41otW7HKeXly5Ivt5HvRA4sylM2ARLgpo6SVPhn44KT JS2OLZqmAJl2k3a0FJvkRdEJevsF2/FKxckEu+yE3f3CzEiolatyJTzPy4pvm6DotjzR47X2WuuV DxhXJVwU4wrqAr+0TGcVzrNUcP1ObrowjEhoMYWLdoO43Nv9vLphHMd2z5W1kypPxa+DrPLi65uz f8BHqqvrn556LXhMnlFR9ZWCVz8RPgODz89YmfiPgqTj+bEbJQqSvu0mkRdtQNJJnMD2Wkg6oe05 eyDJigJBjSn/PDAgXbk3eIuC7w1A3oIpI7gbkLccA0b4AYDMvpkz5McFZFrkOOueGiQA5PjJkZjS otg4W54OhqGB4Uc6LZnIU/I2b76R4FF49JLYReBTeHTiwHbdZAOPtudHLtZWIdKJgiTZg8dJUV2O Z5QLs0+5zadApwrmD0GnEXwQOo3wHxSdn8dnX3rYfKxDp1flWUukx/LjZmoA39OpwZngNJ/OBHnD eXVJxlVZgsFUnKgIgWTj07KbAAxb4B+VW8A3FbFSx6barXmCwKWeKIYLIro+g8w1VllHN7Fkq3KH mkuSCULLPw1na5MPJ/F9RCUFGdf3Yhfo6LFK1wbvTAyrDBDPwEF1IDEEdYNVNq3qnc46OmyNZjIa kctjS7FVwHJeI79qyqlCWFOBGpyANUoNtnLMUI0rFvOPVaa5Z2Djp91fJ6LCXm82ueW3tJlpIfVI qz1jNHtXZm0aQ+XL0w8EzYstDxRi99LkW4KrMeb2qGxrQ8j8ehe/fhDuzaoPwL24MsJborL0SwOR 7kO5cnXltuCoMo0Gb9qDlViavu/p61hBqtUmIdpjy2wTK/p468/wcKy4gZdEMdJl5Fd+kPiuJnNA aZuGe7HvgAa24SUIY2OpAyIliMAo748UjcF1pEQSKvuR0geE4LnKZbdhYv3ZMywm69njfWDhdPWY nTFEn8Drbq1wcq8YoKLBvzaiQWAjhXG1h2+PBo4fwcmNhzue4xgfOqCP3yEa8OlFV29IRqNRoJge 3O62Y/66kWe+9t2+Xz8f9DdD7J0P+t3FMKfLts9xRo6qK+L0M24iK2uqjnTDgw25Wqcwkgi0xMXz Qz8KMT8O48CPgihWjrg6jN0QPxEImeT6Xph4nklFd3gqf0wh7JYI35a6ZjRj+zjKdhJwS3Ztspfd JOAWBmGEH0AC7lsru+QUleMSlwnWWt1M8br6zUJUJ3lbedRlYPngZglNMdn71cu+nn54kTIuyN+J zAXIC9xq1AXLfupn049NC25BQJfodgjo57iPQEDkuV6iqbtkI4GmG2sIcNwglBB5RsCO/OFPgoAG xWlxVORLXEdINHw350faqCl+5/yKkSvmIs/3Rzh/6CIv1VdnILIBqLeO64aLu6jNhnabtz4f/1sS yD+J8/eOf8SD73f0d8WgzvtXxZ/HeX+QRK4vnRvUxg2RaCYb5MfxYzt02kz08d5PhyVCdFGApKkr UF32Mrei3Y3Y7xXla8aPZPWa/LZg/PqgBb9bIntXv+he76pe8bjXm8iTC8RBvt0IPNfeLGOjCpfg ywMF9h/87U6ZICW71AROovk7vWBc2/WDl8ofDhC7/MCPI1fHLl/+2Kba29aRfFSOPFS3fm/e1iYe T5K5mNLYgzIXI/wHzlzO3h/25mL3QSbrPdrRT9D3JJu3iKsM3Ln6fXNzF2VQZOf6AEtAzcKNSwUv ce3IbTMTx01A4DbLSOlCt6rIVNBcHdDhNEOPivxqmrV7TnGz0qDH51fgaTIv0JT2twFxgshGOwy5 JGYlqLBF6N/rQjaZkbW9bBn+K5Ktbg2cwZG7f4V1EcdOkiAI9q+DN9Kt02qwf6V1IdyCJugQ6q+E 6lhnPzrTzT5U1utbm+ITOlnQX6VrBnXVyPa0dQMjIJl/YTrJBpS8tO0eYZ2mdsIGwJC6g7AuSHbC po6jhPUOWg1kCYegJaewCNqbBGoNaHKyyMWxdaGzg5oKqbhcU36UV0/GQ8hMdk1pV5TP59WSnVdq pJB2aH1KObXRfTUmXVzk6Yj9Z10i9PwkRhSB1Xzf9bSLY2E13ZFn206MGI6ncexHuhZvnirnUs9a nzHG7i2zbVE/9vCjRT3HBxJbzdWqnbJYtfWROzyWNl5bGP9K46m33xlUjVlB9s7Xegcu5KoSkwL7 84Vd2453ax33KfradrRuSSgVCu69Gn13S6uLo6vd9kb1L2yztowPp5Mz4s9qTe2W+L1STeUsqoVx dxPsTbZ3KLq3XqlGLMQdizr91up0buihdeVQfO8Hp/OqDlsvmhmKUZc5zmCZuR2Q0quXbTq4UQ1S x32t7mgXPD+2/jsaJaE7jkdHI8c/OfLfJtHRm5MwODoJPN8fj+I3Y+/d/3DvXjv+MOVMNYu/N03v +PJGo/k8T3nVVBPxMq3mA9xPoGN9UFeXjNdVrprWHbvtfFf9sZ7rOurIV4e62ppyV7NZaGB60dOC f6T156UqfaPFXjCOay98VaOpXsZfDF0Nkaqjh/3/AAAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4A AAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc4SP wQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB 3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOv Ipo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33ku alneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhALJN8J3hBwAA0y4AACEAAABwcHQvc2xpZGVN YXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsWl1u40YSfl9g70BwHwONxH9KGDmwZCsZwJkYsXOAFtmy GLdIbrOl2AkCzB1yg73F7r7tUeYkW1XdpChbmsiwHNiBMAOJ7G4Wu+v76td6//XdQlgrLqusyIe2 865nWzxPijTLb4b2j9eTTmxblWJ5ykSR86F9zyv765O//+19OahE+h2rFJcWyMirARvac6XKQbdb JXO+YNW7ouQ5zM0KuWAKbuVNN5XsZ5C9EF231wu7C5bltnle7vN8MZtlCT8rkuWC50oLkVwwBfuv 5llZ1dLKfaSVklcghp7e2NIJnC+5Eil+T2/05w98ZmXpHWip13Psk/dsQOfkYyGtFRNDe3rj2N2T 9118BBabK3y4Kq8l53iVr76R5VV5KfEm+bi6lCATRNpWzhagXxRAE2YZ3eawTAveePymlsQGdzO5 wB2BeizYIaB4j5/wEBvwO2UlejBZjybz77esTebnW1Z36xfA0ZqX4qn0iR4fx62Pc50pwa1LwRI+ L0QKXCEV0Qn1Y6DF8qJIbisrL+DMqAp9VFBOLRjPj68q55a6L0FLCsWadXoSdpY36yvSb73pRit+ EAHpSDVu5IdevKmf2HX7Ic6jlhzH93pwg3tZCyplpb7hxcLCi6EteaKICGx1USm9tF5C6OuNlAN1 NyrSewRjCt+AOVgcPD8v5C+2JT7k1dDuO74P71Z0Qzu1LdmemW7MKDEugHLwBMsTkDO0EyVpLzlY 2+lSFbPM7Ei/El8uKnWl7gUnWgB4bABqhQ/YkGBo8Dzv/HgFBr9QY8EZOARDIXUyFllya6nC4mmm LGP3BAO4BxCJWlKkKxLJ8/SSSfbDA8lGRaSbWieAnCbSbjp5DZ2Qy202uQjQc9mECrKNaT+HVA6w BwlG6q2tboNVfuAG/dB7/axCWjyJSGBxllgRI+n4zyQWao94VW0QC0hGtNUf9SvJYzyBy1c8KfLU EnzFxR7iiWNPEH89z+T+0okMT5A+KZZSzffevK/ZuDcck2y2VTqEkYOatF+b9BlTmwGCFPJck04V eLFfwMMyMTOmTTBSmMBg8sR4EXoB/H9g2q7jeU3A8MLAcYPXb9kb8YJMtY4KFCFWwkFTZuIGvL+w cSzlM/TjqE4H3RuOVYXI0kkmBN1gurdOg9Sdzo5UliudGEXBOpQ2ORMFi5YcsG39JpoAX4Ib0dcm bOG7yPJnIqWs6ddxz4u8UXzWGcWTs85p6AedUW8Sdlx34rpn55Nz57z3GwRVShpSYJrKFnyS3Swl /36pQ/c+wS/qulHXCda+AjaAmzmsSQS1SUyKArPqdpwjM36uUcwgQyAY/7lkEt5gDEOHI8yf9jUM z3H9OpPabhlxP/hLW0adbL0+2zgsJ8Oak1dg79z6uFxMHzCTXN5zmQmlJIjeRk4i/pO8dhgE3pfJ +Vd327oOeH3UbNz26Hwchuixw5Hrd6AWAwd+7p123Lg36ru+H/iTUeO2K2ReDuxAj7uPt/786d// +PzpPwfw1lSa1JU7pKRQ5GG1gcnpUmZD+9fRqB+643jUGTn+pOOf9aPO6SQMOpPA8/3xKD4de+e/ wcZLxx8kklOf4UNq+h0w+KhHscgSWVTFTL1LikVXNzu6ZfEzl2UB4RT6HU7PNE2o5eA78M/vxybz oL1RclPvFo5Q9zESIb9jpQVdCojsCjoOEKiHdnoLV9MbF8egbFd3cJXewhVLEmiNwApzUY/AvB5p 1nj1CNRpegoOZi7qkaAegSinp8J6BHzMXGT5LSgDv2xrVohv9UB9hWkVNZwu2H2xVB9SgwT4jXqE EgLX8SM/9kK/D8XzABsr8kNqOg671kJWt15r6smda0FXjVyTqO5cC/pp1pr4vXMtaK5ZazzqzrWQ Ojdrw0ea2dBDANpu1kZ/sBZwaNZSa2RD45tyo9ba/h/IhQ5iI9ehFPoLgjeAq1tBLVUY4NUdNTIq pAV1IegWPYRJHE0Gi3HaAk94zaZXkL/WHSCpdO+Es4t8JIF5gCv2EHNzC5SYQ0MEGpWXyzyBTo3p 95XJCPt62LNKLhOT3dKRIHuFMTM7XX6EZikl1y0vDP0dkHvLJTZa902kQQiKbqfbtFHKaWfQVhva Xy1+6giFIEBGyh5McKYnkurBRFLhxK6ke1Or0NCEFskjFS+YvBjanu/28WBZDm4aVNWpB+oa4qX1 D6rUTZcHGEwKqD8w9ddqOpUZE1oZ0+V4zqSVwMfQ/vzpX3q0BZVOIF4CqnwXVHlnB1R554tQEeNd rNk0HBHAgS6tgcONA6i/wOuaku7Vw/H7IzggL3ghyzkgHIiBcUDeGo66j9zCw42pNHozeDw2D/fF PNkB8UAQDB5+Cw/To33DeGyxD3SALxJZDogHgmDwCNZ4uL0gIjat/dXbso///fexu3oLcCAGBo6w BUfg+OSd3ioc26I5Jgiv3jwQBINH1MKjHzkU/I547JMIH9BdIQgGj3iNh85tgU1HPP5kPBAEg0e/ hUcch9TsO+LxJ+OBIMArN0rDclCoOZdNoQgV1aVGzdRW7V8ZNNWnWVIX7rqMARM7fILcqvC0V32T FV7dxDjqZ3vJRb+kOfIH7GlHCeRF+EuVo4GtxPaaxIndmJKuo4XtqBKoRDsyCExsR9oe+bqFeGTQ jjwakjYq+48K2pHYhkF0dNLU3G4yzXZyCYnn+m9A+Hfa+sfoJ/8HAAD//wMAUEsDBBQABgAIAAAA IQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDYueG1s LnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMS u+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44 XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6 yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDUueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6 EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3 OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaL KU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD/ /wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDcueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+b YwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXi WcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxj Ip9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQA0zbnO HwEAAMcHAAAsAAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJlbHPE 1d1qwyAYBuDzwe5BvvPFmLbpDzU9GYPCjkZ3ARK//LBEg9qx3P2kMEhgcxQCnggafH3yHujx9NV3 5BONbbXiwJIUCKpSy1bVHN4vL087INYJJUWnFXIY0cKpeHw4vmEnnN9km3awxKcoy6FxbjhQassG e2ETPaDyXypteuH81NR0EOWHqJFmaZpTM82AYpZJzpKDOUvGgFzGwR/9f7iuqrbEZ11ee1TulzOo 7VqJr2LUV+djhanRcUiS6bqdThhL/A8A/cOWLWlzvjScqW4r9DaGHUsy7q4o1NCiBd0ry0KyVczO ViHZOqZsHZJtYso2IVkeU5aHZNuYsm1I5m/2eBfrLiTbx5TtQzLm38d4pbH0x0Znz2/xDQAA//8D AFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQxLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MF wePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnD kHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKf f1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4A AAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzhI/B CsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHe BOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68i mjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5q Wd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF 9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBv l4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE 9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQU AAYACAAAACEALqv66RgEAACtDAAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54 bWy0V9uO2zYQfS/QfyDUZ60ulmRZWDuwbKsosNldxE7eGYleC6FElqIdO0WA/Fb7OfmSDinRm/W6 qLbrvsiWNHM4c87MkLp+s68o2hHRlKweW96VayFS56wo64ex9X6V2bGFGonrAlNWk7F1II31ZvLz T9c8aWhxgw9sKxFg1E2Cx9ZGSp44TpNvSIWbK8ZJDe/WTFRYwq14cAqBPwN2RR3fdSOnwmVtdf6i jz9br8uczFm+rUgtWxBBKJYQf7MpeWPQeB80LkgDMNr7aUjywCFbIEauSknJtC5Wewtpe7GDN541 AQryJS1QjSt48AFMyxxTpO0RMIZWZC+1WcNXghDlUO9+FXzJ74X2vt3dC1QWCq1DsZzuRWemb2sw gz/OifuDQcLJfi2qyTVOgB20H1sg4kFdwQknEATK24f549N8c3fGNt8szlg7ZgGI4Lgo6M/bjJ6n 45t0Tkjxjum1Phgwblj+qUE1g4QVD22e+e3OoKrk1Tp8g1pNpNLDQkyUoFwrUefVmmqajHejqTbx HwmKIn8UuC1N/jCIBvFTrnw3HOr3irEwDr3QD/UiBgkWaaF5IvcpKw6K6Y/wC4KqohlbBKvkW1ja yKU8UKL1ANZwAinBBYwpVo1Gavv9EhqtkjNKMDRip52czGiZf0KSIVKUEr3FjSQCaQqgLQHyGsSR UBsdJKmLeyzwuxNkxSpOYGWI28SrU1DM/rOOg+c6qmq6pzgnG0YLCMVXGUIjGMH+k6SKuBNFoS2g Zk099Fc2CIcwWHT9nxM2cr1RrN7/X8JCvSG6o0cFXym0olvr3DwRuhVTKwoXs6Rm6wW1tSQ5gzFF yY7QHvBa6hfArzal6I8+aFulN18Z2wq56R188FL4cn0WHebpRVssMC02x5I86SxNyGs7q5AwVb7A Vojp2up6Ss8WPSXVZNV/fhyXup/NkDBDTU+u52NsDduf2r/+mLmD4SCN53YaZ3N7GgWhnbpZZPt+ 5vvzRbbwFu5Xq5vgBaQqy4pk5cNWkLut2iT7TcOh4w8dL3wsVghA+V5Wk9BokjGmxu2P807X0WtV WUvRyvL7FgtYwSjzL+PuJcpclpHIMLKkZUHQ7bb6eMKL3h5fywucKAH6LDV6+Fy4aNPFLIpUvUap H9iwXUD5LgZT24/ddOQHQRhk6bFoG5V5DdH1rdXv3/785fu3vy5Qq3qnNidI2BFuGtjxuT7YbUUJ 3Zemo8ifxamdekFmB/PR0J5mUWhn4SAIZmk8nQ0WXyFw7gVJLog+7v5WdMduePjsqFyVuWANW8ur nFVOe+Z2OPtMBGelPnZ7bnd232HY7AaBF/nxcGRUgiD1ZDHBQgbqqKxPClS8xfxuB6MHJ/CRAOU/ 0484fBZAhSvTRxOVuvnMmPwNAAD//wMAUEsDBBQABgAIAAAAIQDApFg5ygMAAM0LAAAiAAAAcHB0 L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEwLnhtbKxW227bOBB9X6D/QKjPii6WZUeIXUS2tVgg TYK1u+8sRcVEKVFL0q7dokB/a/dz+iU7pMR0nbqA0/hFtqiZw5kzw8O5erOrOdpSqZhoJl50EXqI NkSUrHmYeO9WhT/2kNK4KTEXDZ14e6q8N9NXv121meLlDd6LjUaA0agMT7y11m0WBIqsaY3VhWhp A98qIWus4VU+BKXEHwG75kEchmlQY9Z4vb88xV9UFSN0Lsimpo3uQCTlWEP8as1a5dDaU9BaSRXA WO/DkPS+hWyBGL3aecjayS2sRN4UUidLXqIG17CwYppTBAShv8CYEczRiu60NVPtSlJqHJrt77Jd tvfSet9u7yVipUHrUbyg/9Cb2dcGzOBP8MT9wSHhbFfJenqFM2AF7SYeFG9vnuCEMwgCkW6RfF8l 67sjtmS9OGIduA0ggsdNoe5tl9GP6cQunY6U6DGrzhSD640gHxRqBORp0u/SI7dbB2ZyNvDtGnUl 0Ibf3q77aPlw9go4tWTpXS7KvUn8PfzaRZxxpZd6z6klBMLGGYDDA+jn2HQ4bfx3S+jwWs84xXAC evL0dMYZ+YC0QLRkGr3FSlOJbDBwHgDyCtjRUJwekjblPZb4zyfIJj+cwc4QtIsQ/nYU/pzIgSPy oKfQPceErgUvIZT4HOQaqjwkJIND0HW7B30JTeMq8xzGjYwACsUmaBPdMf6hXIhv+SPRL6yHaXJb DnVQj45zSzw83JY2qWe0wJISAeea0y3lJ8DbijwDfrVm8nT0QcfoyXwVYiP1+uTgk+fCs+ooOujO WU9C4k7CHGt6cAAsISDFTjt+SV1KDYf/E1wVmFeu9a0EWJExUvQitangmjA6/3kWDkaDfDz383Ex 96/TZOjnYZH6cVzE8XxRLKJF+MXrJa+EVDWracEeNpLebcxlcppojYJ4FETD780KARjf89Zk6GpS CGFU8f+yZPvopVWptOzK8vcGS9jBVeZXVOknOnReRlLHyJKzkqLbTf3+CS/Dc8g1TFwAfZQaKz5n btp8MUtT069pHid+PEqgfReDaz8eh/llnCTDpMgfm1aZzBuI7tRe/fb1n9ffvv57hl61F6qbtOBG uFFwMbd2ANpIBqcvzy/TeDbO/TxKCj+ZX4786yId+sVwkCSzfHw9Gyy+QOBtlGREUjsO/lH2Yyks /jBK1oxIoUSlL4iog24mDVrxkcpWMDuWRmE/224xXHZpmEbDcThy0gJBWmVxwUIGZqQ0URMu3+L2 bgvSgzMYoqH9Z3aphbHZjBMHJiZ1N4ZP/wMAAP//AwBQSwMEFAAGAAgAAAAhAE7bGm21AwAAlwsA ACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWysVlFu4zYQ/S/QOxDqtyJbkmVH iL2IZKsokE2COnsAhqIidilRJWmv3WKBvVZ7nD1Jh5SYbbIu4NT+kS1q5nHmzfBxrt7tGo62VCom 2rk3vhh5iLZElKx9mnsfHgp/5iGlcVtiLlo69/ZUee8WP/5w1aWKlzd4LzYaAUarUjz3aq27NAgU qWmD1YXoaAvfKiEbrOFVPgWlxJ8Au+FBOBolQYNZ6w3+8hh/UVWM0KUgm4a2ugeRlGMN8auadcqh dcegdZIqgLHeL0PS+w6yFY+/ecgayS28jr0F5E3WvEQtbmDhgWlOEbCDctFqQLIGqnuQlBrTdvuz 7NbdvbR+t9t7iVhpcAZ/Lxg+DGb2tQUz+BO8cn9ySDjdVbJZXOEUyEC7uQc125snOOGU7jQi/SL5 tkrquwO2pF4dsA7cBhDB86ZQ7q7P6Pt0QpdOT8f4OaveFIPrjSAfFWoF5GnS79Mjt1sHZnI28F2N eua1YXaw6z9aPpy9Ak4tWXqXiXJvEn+EX7uIU670Wu85tYRA2DgFcHgA/Rybxqat/2ENjd3onFMM jT+Qpxc5Z+Qj0gLRkmn0HitNJbLBwDEAyCtgR0NxBkjalvdY4l9fIZv8cAo7Q9AuQvjbU/jfREaO yKGb0D3HhNaClxBEeBqtrISmcMyfgVEoAOJb/kzdiQybtrUEqxcM9yxaKuHhtrRpvKGoa0oEnFFO t5QfAW+ZfgP8Q83k8eiRqeMb0Auxkbo+Ovj4rfCsOogOSnLW3o5dby+xpi8a2xICsurU4H/pRanh OP8Bmo955YHImma3h9rKhhGXk/SjAsk3yv1nPoqmUTZb+tmsWPrXSTzxs1GR+GFYhOFyVazGq9Fn bxCxElLVrKEFe9pIercx1wNU/pVYHJKhaRBOg/HkW7NCAMb3vDWZuJoUQhid+7fc2D46tSqVln1Z ft9gCTu4ypxRh87LSOIYWXNWUnS7aR5f8TI5TYb72w1GJ4A+SI0VnzM3bbbKk8T0a5KFsR9OY2jf VXTth7NRdhnG8SQusuemVSbzFqI7tle/fvnrp69f/j5Dr9or0s1OcCPcKLhqOzvSbCSD05dll0mY zzI/G8eFHy8vp/51kUz8YhLFcZ7NrvNo9RkC78ZxSiS1c90v5TBfwuJ3M2HDiBRKVPqCiCboh8ug E5+o7ASz8+V4NAypWwyXXZQk01kYxZE9HhAvRGmlxUULS2Y+NGETLt/j7m4L2oNTGIeh/3O71MEA bCaEFyYmdzdQL/4BAAD//wMAUEsDBBQABgAIAAAAIQDAwn4LngQAAAYRAAAhAAAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDEueG1szFhdbuM2EH4v0DsI6rNWEkX9REiyiGyrKJBNgjp7AEai Y2Gpn1K0126xwF6rPc6epDOUaDvZFDUKo/CLTVHD4TfzzZAzuny/qYW15rKv2ubK9t95tsWboi2r 5vnK/viYO4lt9Yo1JRNtw6/sLe/t99c//nDZpb0ob9m2XSkLdDR9yq7spVJd6rp9seQ169+1HW/g 3aKVNVPwKJ/dUrLPoLsWLvG8yK1Z1djjennM+naxqAo+bYtVzRs1KJFcMAX4+2XV9UZbd4y2TvIe 1OjVLyGpbQfWqkoJbltaTK5hwrevwfJiLkqrYTVMPKKENRdVyfWrvnuUnKNQs/5ZdvPuQeoVd+sH aVUlahhX2u74YhTTjw2IwcB9tfzZaGLpZiHr60uWgiOszZUNfG3xFxaxlG+UVQyTxX62WN6/IVss Z29Iu2YDQLDbFKjuBou+N4cYcwZH+DurBlEGS2/b4lNvNS3YieYP5hV3a6MMbUb13dIavF4oqbWN osN77RKzpNduNVh3zoiSMPEGjxA/8CgJX/oljmNCUQC949PY8waJQ6sH1V2qNllbbtGrT/CvWWGp 6NVcbQXX3gafsBSQww9wKxhmDG+cj3PImFpNBGeQUSMz6noiquKTpVqLl5WyPrBecWkpHT09qrwE EAqYH1Xypnxgkv36SjM6j6WwM7jDIIThwM8/sxQYluarp2FPcgqi+tXTQBRENoSd4fZ4wvwg9qOR sSBJIjgTXjIWAV2aUs1YHBKUHpwwJII2fogf4483GUOaxFr4EDhWzeStzpyqKSH79ZCJZ2ALIg+y GBSs7uC00yyXfAEk4GTfQpbnlRD6AY84PhHSWjMBB8UGTwZgsGrUMBOH3g6qPg9RWLN3oAe4NPph OOJDPTAke6g0jNEz1vnhRZAj3mCP98KnOs3ODy+CHPHSPd5dGJ4fYEQ5Ag4PACck0WlxfoAR5Qg4 2gMmJIHMPcsQRpQj4PgAcEyDM805RDkCTvaAEe2ZJh2iHAFfHACOwlif/ecXw4hSH9Xmvkf0J7ju 4b78v258am78KVPcehCs4MtWlFBzBKe4+UsFRc7vUGIzsYB7Sd/+w8WMlav2Hg7m2pFYn+gCal+z vHlH76uqBdTXWCz/MfGCOMiSqZMl+dS5iWjoZF4eOYTkhExn+cyfeV/ssW4swVRV1TyvnleS36+U jbwdU5zFLoldP9zXYAAA1562CgsNJ3nbYvV3yAo9BSsLKF80Lb+tmIQdDDP/UpiB349m5rQeiYxH dANl3a3qp1d+0RU8dFymXfhPDQV0qqD6TdfoOlj3FqcL2mw2iSKM1ygj1CExhfCdBTcOSbzsglAa 0jzbBW2PrWMD6I6N1W9f//zp29e/ThCrunY27Sr0jrc9NCCd7iJXsoLsy7KLiEySzMl8mjt0ehE7 N3kUOnkYUDrJkptJMPsCwDufpoXkuo3+pRzbeZj8rgWvq0K2fbtQ74q2dode3u3az1x2LVTO0M77 3vhNQJfV1IsC6sckNBEMKHXvY9CCCdiMI+xCyA+su1/Dyc1S+PoA8Q8VN0x18L0BW4YXImi7+X5x /TcAAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9f cmVscy9zbGlkZUxheW91dDgueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbb JGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS 4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3bo OmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAA IQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDkueG1s LnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMS u+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44 XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6 yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7S ehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDij tzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2 iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA //8DAFBLAwQUAAYACAAAACEASwXcO+sEAABaEQAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQzLnhtbMxY227jNhB9L9B/ENRnRRJ1tRB7EdlWWyCbBHX2AxiJjoWlLqVor91igf2t9nP2 SzpDibaTTVE3GwR5SWRehmdmzpCHPH+3rbixYaIrm3psumeOabA6b4qyvh+bH24zKzaNTtK6oLyp 2djcsc58N/nxh/M26XhxSXfNWhpgo+4SOjZXUraJbXf5ilW0O2taVkPfshEVlfBT3NuFoJ/AdsVt 4jihXdGyNof54pT5zXJZ5mzW5OuK1bI3IhinEvB3q7LttLX2FGutYB2YUbMfQpK7FrztWP4Lo4Vp qIFiA02uOQHf8wUvjJpW0LBgOS5u4EAmVG/X3grGcFy9+Vm0i/ZGqElXmxthlAUaGSab9tAxDFM/ axgGH/aj6ffaEk22S1FNzmkC0TC2YxOStsO/MIkmbCuNvG/MD6356vqJsflq/sRoWy8ACPaLQr7b 3qNv3SHandtScma4e6/6oRSmXjb5x86oG/AT3e/dy6822hj6jObbldGHXqKpYVzfqeKhx3cqphro PhIRIZ7rqXD4vhOOnEdBiaKI+NBoYGhcLyROFKhFtCVYpDfdJnKbNsUOQ3oH/yFztM5XDbBU4gya 8E4u5I5DnuF7w11AZFB+D2XEgQU0KdjyN2jq/hibsCSseacSn1OIAOV8WHaYCel+aBGCTRMICfwB I5xiPbLa+rCAeqzklDMKCw3eycmUl/lHQzYGK0ppvKedZMJQIYTqBYxoXao1lElWFzdUUIR3bBmz QhNYGaKgvVcBwcz8e/oh3n0p3CL3bjjN2arhUAwGQSehWnSen8UEjL4JZQOc1sR5FiHIyAkjIIdK nq6Sh4QIHMeNoyEzfZGdQoi73uZThKiouFQFWtYF7DT4iTm9W1/BdqqQHNEEtsS+u2t4WWQl5zhW 7aZsyoWxoRzYt8UtCNJZ1rJviQC2YgIkbz9YpfLIDvT1K6mOPesUdQlSt0fqBxGggHCfANeNXxEu YkS3Abl3gDtyocxPhRu+IlzEOMD1D3BdL3IRxWnhRc8UAV6BDQhywBsc4Y1JjEl+e3gR5IA3POAl JIbwvkW8CHLAGx3hjXzv9HJ7TT4gyAFvfMCLYE+vt9fEiyAHvKMjvGEQvc16Q5D9TnykItSZj+hh k9sf7sqt52sAPOiUBOgeaIDnnPO+PudnVLIH57w6VL/3nC8kSBsQSyvKl/q87481FMIqXPixUJHr ZZpSF1qpaJ2mTlV9FqsfKq5LUOyovf+cOl7kpfHMSuNsZl2EfmClThZahGSEzObZ3J07n81Bhhbg qiwrlpX3a8Gu19JElp2Sjsgmke0Gh6gDAJz7stor0DnJmgY137H68l9CfS2l6NPy+5oKWEFn5j+k 2P/JzMtGJNQRWYCGYsbVurp7FBel+L+XrXD7BdNPhkapXtCNL0nadD4NQ+RrmBLfIpEP9J17FxaJ nXREfD/ws3RP2g49rwHdqVz9+uWvn75++fsFuKrksr79wt5z2cG1o1WX0rUoofrSdBSSaZxaqetn lj8bRdZFFgZWFni+P03ji6k3/wzAW9dPcsHU1fzXYngigMZvrvVVmYuma5byLG8qu38fsNvmExNt AxIZnghcZ3hnUPqZxFEceiSKYqXzFTZ149FowQW83quLCxfvaXu9UXswvGgA/0GHQ1MLbxhAcRx6 GIK+6zeRyT8AAAD//wMAUEsDBBQABgAIAAAAIQCJS2JtewQAAGkSAAAhAAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDQueG1s7FhdbuM2EH4v0DsQ6rOiH0uyI8RZRLZVFMgmwdp7AEaiYnUp USVpx95igb1We5w9SYeU6CSOs7abPObFlqiPw5lvfjjk2YdVRdGScFGyemh5J66FSJ2xvKzvhtbn WWoPLCQkrnNMWU2G1poI68P5r7+cNbGg+SVes4VEIKMWMR5acymb2HFENicVFiesITV8KxivsIRX fufkHN+D7Io6vutGToXL2urm80Pms6IoMzJm2aIitWyFcEKxBP3FvGyEkdYcIq3hRIAYPfupSnLd gLXynl3f/mkhjeNLGPGsczA9m9Ic1biCgdk9QyNWSxCjP4lmxglRoHr5O2+mzQ3XM66WNxyVuZLQ zbSc7kMH0681wODB2Zp+ZyTheFXw6vwMx8AEWg0tcNha/cIkHJOVRFk7mD2MZvPrHdhsPtmBdswC oMFmUfB101r03BzfmDMrJSXI21jVQjFMvWTZF4FqBnYq81vzsqulEaZsVuKbOepoV6I6XPtR82Hw AjjVZMlVwvK1MvwW/vUgjqmQU7mmRBMCauMYhMMP0E+ximpS25+nENWVHFGCIeo78uT5iJbZFyQZ Inkp0UcsJOFIaruEEnkG7EhwTieS1PkN5vjTlmRlH45hZVDaaAiPLYUvE9kzRHbRhG4ozsic0RyU 8F9Hq/gK2YBpYUEEQngYH7zAraJrK8qCsA/5qkPNi1xXPWt+TcAFbm8A4xZSYReEfnga9bQDjSRN QOtmw8lOr6m16ZJ6Om1wnJNC0av09wftosDtIwA8+juwwWOsAQC2twPrPsYaAGCD51jviQ4GANhw H9YAABvtwxoAYPv7sAYA2ME+rAEA9nQftgUorrt0Uo7R2QQzEUjYpM0rs0tFkE4u8SS72gzaXlIH 7hEJPSUZq3NEyZLQA8TrLDtC/Gxe8sOl64Q4QnrKFlzOD1Y+aDPyYHekZbFTOuwib1rXgp/VNc0J 7KdmMzhyu9iqa9p/eqtQlUY/PN4zdtW1KBi8FzbYEd4LW/xe2DaN0HthO6BhC01hG2NJnnRruhT/ /6rWNsG5hB51q2/TDnq5wB3TFBdwglHHkb9Hbq/fSwZjOxmkY/siCkI7cdPI9v3U98eTdOJN3G9W 15nnYKosK5KWdwtOrhfqzANb2lYHvKu37jt+3/HCh10YFFBz33aziYxPUsZU8/64hw5f10O3Xikk b93y1wJzWMF01Hta6mM887aM9A0jU1rmBF0tqtstXqK34AUuA0D0Tmr27MrHULMJ2mQyiiIVr1Hi B7bfDyB8J70LGw4JyakfBGGQJpugFcryGrQ7NFZ/fP/ntx/f/32DWNVlxFwIQKt7KeD82Ohz+oKX kH1Jchr5o0FiJ16Q2sH4tG9fpFFop2EvCEbJ4GLUm3wDxRsviDNO9E3FH3l3YwKDz245qjLjTLBC nmSsctrrEqdh94Q3rNQ3Jp7bXbssMXTxvgsHN9/v+e15TeumeyejLZigrjuU2hnlH3FzvYTmCsdw wQPxP9JDDVzpgB8V9AGibDdXROf/AQAA//8DAFBLAwQUAAYACAAAACEARZ+eHdcFAAA4HAAAIQAA AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbOxZ3W7iRhS+r9R3sNxrFv/boJBVTKCq lE2ihn2AiT0Ed22POx4ItFppX6t9nH2SnjP2gPnbdQgXKzU3YMznz+f38/HMxftllmoLysuE5QPd fGfoGs0jFif500D/OBl3Al0rBcljkrKcDvQVLfX3lz//dFH0yzS+ISs2Fxpw5GWfDPSZEEW/2y2j Gc1I+Y4VNIf/poxnRMBP/tSNOXkG7iztWobhdTOS5Hp9PW9zPZtOk4hes2ie0VxUJJymRID95Swp SsVWtGErOC2BRl69bZJYFeCteGaT5eSZ3T3+oWsSzBdw2tQvwf/oIY21nGRwYsiygvCkZLn8pywm nFLE5ItfefFQ3HN5we3inmtJjAT1hXq3/qOGyZ85wOCgu3P5k2Ii/eWUZ5cXpA/R0JYDHZK2wk+4 iPTpUmhRdTLanI1mdwew0Wx0AN1VNwAL1jeFfBeVR/vuWMqdSSJSqplrryoogUtvWPSp1HIGfqL7 lXvR7UKRoc9IX8y0OvRIVeOqP2U8FL6EmMpgiWXI4hU6/gjf8iTpp6V4EKsUUgDHi9SUCSD9mE5/ r0LbOA3eNuHgJOmDKfAByUoJ9gHNOx8foA8yMUwpgT6pQy0uh2kSfdIE02icCO0DKQXlmpBRKNGA C2AXkMqakubxPeEEjNhixmiQPtwZXFT+wGEV8ONht9dhx5zfpySiM5bGYIF1jgxgPHUoV6gllbAj icBo7ZSk4/rQ4LIuTdd2TdNGkzbV6RiOYQYgLlijnt3zPWkzhKEiku5XJaEiojKskTyaMVCLx4qy mb062VpG+I3siySPocHxEO/+OL8FFZOGVLWglX8NdMtBSx+Vm43akIcWVE9NqLxqxWrssyIV2gFm 2hvWnulIC9qwmsE+K1LVrM6G1bR900NwK1qJ3A4BctW0boM2sAJpw6m0yFXTehtaywrAhFdYi1w1 rd+g9R1b1uGp1iJXTRtsaJGzfcoOxBa5atpeg9Zz/VelDLmkljR7Qioa3gSqbi1d8u6nKxwKjhS4 ckvhTlExR6nYkOUCenVLyKRqwKNWPShe+CjB7p6RdFrLWCUx+FiVYcKD5vMEE3JcxizTdwLf/YaM 2T3XhOZARBsdkzLUTNTek2qjThVlAwCHSkyaSoYttMYqAGCVRDSwUknWWAUArOr7Jharco1VAMCq Zj6KVQDAqg49ilUAwKq2O4pVAMCqXjqKVQDAVg2iJgEZXymSa99+jA6SwwB8qKaVz98XjCUPNGJ5 rKV0QdMDDbpLL/viBfSTWcLbs9dP/taKM2ZzLmatjXeqjmxPn0wPssNsctbpzFW6NtmdzqTFp4ta NR9X0xkK3J9zwmHsrDVORluOyq01znNcwwJzYRI7NquZPijf26w20N9mNZiX32a1gW7/H2c1T2na oVlNjkany9q+lEmdPFnKjs1rGyl7m9cw5tvzz9u8dmRN55tvPLsD1du8hkto1dvgbmx+1HnNV9p2 TQTdegn1cMI8XdiqeS0WsIC4/TpqVu9UR99H5V13V7/g5GbBUv6Q7/dTWIvGleW/h4bt22Fw3QmD 8XXnCma7TmiMvY5ljS3rejQemSPjs14vssbgqkgyOk6e5pzezYWO7G2WBfyu5XdNd/NyAQbgteed oWF9sFpgHzOGK6vNNU7/HFmZCpib95885ncWPF+SmfNGpKci8pAmMdVu59njTlzk+sNrqxX2doD6 YGi+s4jyktCsizYcDT0P69ULLadj+Q6U78i+6liBEfYsx3Gdcbgu2hI9z8G6trX69cs/v3z98u8Z alWuSqu9HXgi3JSwuF/ILZc5T6D7wrDnWcMg7ISmM+441z2/czX23M7YtR1nGAZXQ3v0GQwvTKcf cSo3nn6L6w0wOLm3aZUlEWclm4p3Ecu61e5Xt2DPlBcskRtgplHvoi0ILO9ZPde3HTNwVJrASrmv oKwFF3DjSgpayj+Q4m4BUk36sF8HHTaUpwrYoYM8InQDQd/Vjt/lfwAAAP//AwBQSwMEFAAGAAgA AAAhAFeDQKETBQAAMhIAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OS54bWysWNtu 4zYQfS/QfyDUZ0XWXRbiLCJfigLZJKizH8BIdCysbqVox95igf2t9nP2SzpDibaVOF3Hq5fEpoeH cz0z5OWHTZ6RNeN1WhYjzbwYaIQVcZmkxdNI+/Qw0wON1IIWCc3Kgo20Lau1D1e//nJZhXWW3NBt uRIEMIo6pCNtKUQVGkYdL1lO64uyYgX8tih5TgV85U9GwukzYOeZYQ0GnpHTtNDa/fyU/eVikcZs UsarnBWiAeEsowL0r5dpVSu06hS0irMaYOTurkpiW4G1VRo/bDQixfgaFkztCiyP51lCCprDwn0a ixVn5DkVSzKmFeohZerqgTOG0sX6d17Nq3sut96u7zlJE4RqITSj/aEVk18LEIMPxovtTwqJhpsF z68uaQgeIZuRBoHb4l/YREO2ESRuFuP9ary8OyIbL6dHpA11AGiwOxRiXjUWvTbHUuY8pCJjxNxZ 1YhS2HpTxp9rUpRgJ5rfmBffrhUY2ozw1ZI07hcI1co1P0p/KPla+lQpuvOE6Q8tK4C8BcudALJs 8MIrrhN4DiwS9I3reb4dyEMUEhzSQFeh2ERlskWXPsJ/iBwt4mUJmfqIO2iY1WIuthnEGT6vMxM0 IjR7glLKIAtomLDFn7BUfxlpkO9w5KOyfCcPQe7igItpCI6AP7A1o1iJrNA/zaESczHOGAX41iRx Nc7S+DMRJWFJKshHWgvGiXQc1C1ohuhCniEhWZHcU05RqUNkjAUN4WSwXdks3YDxeDvotgq6KoP7 jMZsWWYJKGGhi6BYVIDPSgGoQA3KBXJZJcx5ieCZlu+7TdBUdXTywDFNTJZTE+HN6OeU38hqTIsE qAU/YigfV7fAn3LXQU7YkBTtiW32oCx8tDCRGijH9VGKnIJn7S1oQVo8e483NB2Z/CfhoWSTG4CH IC2es8czbd/EEjtNQSyCHSCitIDuAWAA1XseIKK0gN4eENgAFDxLQ0RpAf0DQN+RkTvDZERpAYM9 IKKdHpSODxGlBRweAHquf2ZQEOU4J/XLHY7ijgesx0PisDFDfpY4kK+BMIF4lzRbtBwiKUn2EGkj Nte5NFcxvmoBR5uJa0OraHrFvsV2SCQYQGtpDlFI/9NMJBsc6yDv4hCzU6PYgdp0OJNDzA4nIUiL dyaHmJ107YFDhj1TSAevBwbp4PVAIB28Hvijg9cDfXTw3mYPSCQCTWQ3usi0On/CQdKQA07dmXDO mWJcxUQTKliHiZw+mCgRr3jIbJog8s9RIpL8p+YwNXt26EJ+kZPiAu4ieJ/4ezywfTsKJnoUzCb6 tee4ejSYebplzSxrMp1Nzengq9aO1gmYKtKczdInuL7crYSGVX5KOHzD8g3T3XsdFMC9/XYHT8Vk VpY40R72BznG/Wx/WAjehOWvFeVwgpoyfzBmvicy/XrEVx6ZZ2nCyO0qf3zhF6+PbIVbPUAfdc0P uud7XLNL2mg69jzMVy+yHN3yHUjfqX2twyQbDS3HcZ1ZtEvaGi0vQLtTc/X7t39++/7t3x5yVbZx daMH7rmp4VJVyYv2iqdQfVE09KxxEOmR6cx0ZzL09euZ5+oz13accRRcj+3pV1C8Mp0w5kw+OfyR tE8fsPjquSJPY17W5UJcxGVuNO8eRlU+M16VqXz6MAft+8maAq3atmO5A8sMfDlgS93kfU5pCybg w4UcrTL+kVZ3a8nB8FID+T+WSxW8zUAcUXQvgrart56r/wAAAP//AwBQSwMEFAAGAAgAAAAhAF9C 6KNVBQAAwxIAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54bWzMWN1y4jYUvu9M 30HjXjtY/ocJ2YkJ7nQmm2QK+wDCFsFd23JlQaCdndnXah9nn6RHskWAsItJctEbMOLTp/N/jnX5 YV3kaEV5nbFyaOALy0C0TFialY9D49M0NkMD1YKUKclZSYfGhtbGh6uff7qsBnWe3pINWwoEHGU9 IENjIUQ16PXqZEELUl+wipbw35zxggj4yR97KSdPwF3kPduy/F5BstJo9/Mu+9l8niX0hiXLgpai IeE0JwLkrxdZVWu2qgtbxWkNNGr3vkhiU4G2bPbHdG0gBeMrWMDGFWieTPIUlaSAhRErBTCgp0ws 0IhUUg6Fqaspp1Siy9WvvJpUD1xtvVs9cJSlkqqlMHrtHy1M/SwBBg+9g+2PmokM1nNeXF2SAVgE rYcGOG4jP2ETGdC1QEmzmDyvJov7I9hkMT6C7ukDQILtoeDzqtHopTq2VmeaiZwivNWqgRLYesuS zzUqGegp1W/US+5WmkzqLOmrBWrMLyRVi2v+VPbQ+FrZVAu6tYTrBRBbyhx24FjegU0cywod7BhI WgZj324Ruxo3zNVArCOWbqRFZ/ANjiNlsmAQqLPGznktJmKTg5vJIF/lGARCJH+ETMohCMggpfPf Yan+a2iASCDTTCu+xYOP4XmHByxMBmAH+ICtOZGJSEvz0wQSsRCjnBKgb3USV6M8Sz4jwRBNM4E+ klpQjpTdIG1BMsku1BmKkpbpA+FECrXLLF1BBnAy2FfrDI+Nt7/vczDifhY85CShC5anIIT9tgjI UohfHSTdne94gScdKpPhmPc9jDEgGu97oedgCIVG/SahlNpNHGpLaO+r1Np1VevyA087Mvoayh0A PNptvO5GRbiL1QDAOkew7i5WAwDrHsHKaNvKoAGA9U5hNQCw/imsBgA2OIXVAMCGp7AaANj+KWwD OJZDsBMBwzZZ3phTsqaqlKr3cqrJG5U88KGPVIF7RhpPaMLKFOV0RfMO9Cq3zqCfLjLenV0lxBns MVty6H5dhXdlYJ5Dn82PskObe9dq5upqNpWu3i1lyiDQ9nWrelUzkx0ESji0ggXJ5wbMAFDglCNV U5MlRz1MVMTL4iuXftTdsOt4uMnz55a/195cv48t/80FDhWE36oRIytTmHbkoxRttryDoVB5c6em 4b06JXuixEImyvLWUuke3Ylvr54e1MiWr49deSrqxLdXGw/qaMuHnQD7XQn7P6i1mi+0Q1nqOwm4 x3dQj1s+2w5BvNfwHdRszRe4qm2dL99BXW/5JFlnh+zpe1D7NZ/vBa/zx/+jP0Bm62lCDRhyzP3+ XOXpSnRDBN2rRKp2vrUSpeJFHcLNtCDfNo4WIsjxZw2OzkOqCqjZdQ4vR/IF5++R5QROFN6YURjf mNe+65mRFfumbce2fTOOx3hsfTHaWT8FVUVW0Dh7XHJ6vxSqwnQZgYOeHfSw99w2QQBZcd63O/ja JzFjcsbe7Q+e7Ghv9cpc8MYtfy4JhxPaDoFPzMDneOZ9LRJoi0zyLKXoblnMDuziv4dd4JoBqI+a 5kT3PMc026CNxiPfl/HqR7Zr2oEL4Tt2rk07tKK+7bqeG0fboK2l5iVIJ+OtS6x++/rPL9++/vsO sarKiL5igIHltobXvEq9+S95BtkXRX3fHoWRGWE3Nt2bfmBex75nxp7juqMovB454y8geIXdQcKp ugP5LW3vYmDxxf1JkSWc1WwuLhJW9JqLmF7FniivWKbuYrDVXuisCIzdjhuE2HH7VjN/KNnUjKOl BRXkTYpKnZx/JNX9So0KcHUE8T9SSxVcFoEfJfQZInXXl09X/wEAAP//AwBQSwMEFAAGAAgAAAAh ALZT4uMOAwAAZwcAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWysVf9u2jAQ /n/S3iHK/k7zgxAgAqoGyDSpa9FoH8B1HIjq2J5tGGyq1NfaHqdPsrOTtFvbSZXGP5Bc7s73fd/5 bny6r6mzI1JVnE3c8CRwHcIwLyq2nrjXV7k3dB2lESsQ5YxM3ANR7un0/buxSBUtztGBb7UDOZhK 0cTdaC1S31d4Q2qkTrggDL6VXNZIw6tc+4VE3yB3Tf0oCBK/RhVz23j5lnhelhUmc463NWG6SSIJ RRrqV5tKqC6beEs2IYmCNDb675L0QQDaG4rYretYN7kDQ+hOATle0cJhqAZDZj2MUYkrSYh5YruP UqzEUlrfi91SOlVhYtsY128/tG72lYEbPPjPwtddJpTuS1lPxygFCpz9xAWlDuYXglBK9trBjRE/ WfHm8hVfvFm84u13B0AFj4caVA2il3CiDs4caeIsKcJkw2lBpBM+AmyiEGQ55/hWOYwDZMNEgxRf 7Lq8Br45SWychvpCQ+N9BxERLV3gD8CFFqxlyDjbhy5eAd2WR73PeHEwnNzAvzWilCq90gdKLFeA CKUlKGhE+TELeoNeNpx72TCfe2dJ3PeyIE+8KMqjaL7IF+EiuHO7ogCqrmqSV+utJJdbDe2AUgkC QxvAhSHMu15B3bWeUYLgQrXy6OnAjwZ+2B8DzRpKtwVY4VixRBJ9eZbC8INSqBRAdojgsVHj35r0 Ok1yzjUo8acq0TFUKbVsZPm6RRJO6JTpFG1k/C9lyFEZiTtGVrQqiHOxrW+e8dI7Bi8wCyH1q9RY 3i0jx2vabDFLEtOvSRbFXjSIoX0XvTMvGgbZKIrjfpxnj02rDHIG1b21Vx/uf354uP91hF61LduN RZhR5wqaX9hptZUV3L4sGyXRbJh5WRjnXjwfDbyzPOl7eb8Xx7NseDbrLe6gcBHGKZbEDupPRbsw wPhiyNcVllzxUp9gXvvNtvAF/0ak4JVdGGHQbp0dohM3HvWTIOlFtgugXCjSXrquWDCZaW+qxlR+ RuJyB6MHpbDeoP1n1iRgobUD7cnFQO8W5PQ3AAAA//8DAFBLAwQUAAYACAAAACEAg3Xm9D4DAAC6 CAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ2LnhtbKxWWW7bMBD9L9A7EOq3osXy JtgOItsqCmRDnRyAoehYCEWyJO3aLQLkWu1xcpIOKSlJkxQwUP/Y0nBmOO/NI0ej423F0IYqXQo+ 9qKj0EOUE1GU/HbsXV/l/sBD2mBeYCY4HXs7qr3jyccPI5lqVpzinVgbBDm4TvHYWxkj0yDQZEUr rI+EpBzWlkJV2MCrug0Khb9D7ooFcRj2ggqX3Gvi1T7xYrksCZ0Jsq4oN3USRRk2UL9elVK32eQ+ 2aSiGtK46L9LMjsJaE1pGL3gbOch56o2YIy8CaAnC1YgjiswXFkv5NzsipZXilL7xDeflVzIS+UC zjeXCpWFTdAEekGz0Li5Vw5u8BC8Cr9tM+F0u1TVZIRT4AJtxx60bGd/IQindGsQqY3k2UpWF+/4 ktX8He+g3QAqeNrUoqoRvYUTt3BqHqInVLUrhtBTQe404gJwWvg1PHK+aZNZzDa9XKEXxDd+9aLj o/XXwKkjy2wzUews8Bv4d0acMm0WZseoIwTKxikkhx+gn2Gra8r96wXoujJTRjHoviHPTKasJHfI CESL0qAzrA1VyKkATgGkHAE7BprTpKS8uMQKf32V2eLDKewMRbcVwmNN4b+J7LREzrCh6JJhQleC FVBBfAhOCwOQf8CxwGzpgRBBJZED7qi1DfgvjpdwHqy6f07DTr+TDWZ+Nshn/kkv6fpZmPf8OM7j eDbP59E8vPeaRhcA1ZQVzcvbtaIXa+Pt26p+EPeDqPvcESjAxh62J0nbk1wIq4WXXekcoitLo+q2 fFtjBTu0nWlPyQHUf1hGui0jC1YWFJ2vq5tXvCSH4AWmC6R+lxp3Gg4s2mw+7fWsXntZnPhxPwH5 zjsnfjwIs2GcJN0kz55Eqy1yDtXtq9XHh1+fHh9+H0Cr7hpp5wtc9qcariPprv21KuH0ZdmwF08H mZ9FSe4ns2HfP8l7XT/vdpJkmg1Opp35PRQuoyQlirrR96VoRjAY34zNqiRKaLE0R0RUQT1/Aym+ UyVF6UZwFDZzfIPZ2OuE/W4chd1he7dAle5qaasFCHZ42rIJU2dYXmzg7sEpfDGA/qfOJOEboZkS zy4We/vNMfkDAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5 b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0 A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+X i+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1 HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQA BgAIAAAAIQAtOrBg4QAAAHgBAAAWAAAAcHB0L2NvbW1lbnRBdXRob3JzLnhtbIyQwUoDMRCG74Lv EOZus/Ygsmy2VEpB8CT6AEOSbQLJJMykWt/eUBXsrbcZhv9j/m/anHJSH54lFjJwvxpAebLFRToY eH/b3z2CkobkMBXyBr68wGa+vZnqaPP22ELhF2mqU0hGNBBaq6PWYoPPKKtSPfXbUjhj6ysftGP8 7PSc9HoYHnTGSPCb52vyZVmi9btij9lT+4GwT9h6Awmxyh+tXkOr7KVjzumLl+Z/DVV0BroZwtwV vEYbkJ16QqZuQ0WKLWISA6ASSnt2JwNrUDbxeRxAz5O+8DV/AwAA//8DAFBLAwQUAAYACAAAACEA kwptdRMHAADnHQAAFAAAAHBwdC90aGVtZS90aGVtZTEueG1s7FnNbxtFFL8j8T+M9t7GTpw0iepU sWO30KaNYreox/Hu2DvN7M5qZpzEN9QekZAQBXFB4sYBAZVaiUv5awJFUKT+C7yZ2V3vxOPGKeFD 0Bxa7+zvvXnv9z7mY69eO04YOiRCUp42g/rlWoBIGvKIpqNmcLffvbQeIKlwGmHGU9IMJkQG17be fecq3lQxSQgC+VRu4mYQK5VtLi3JEIaxvMwzksK7IRcJVvAoRkuRwEegN2FLy7Xa2lKCaRqgFCeg 9s5wSEOC+lplsFUo7zB4TJXUAyETPa2aOBIGGx3UNUJOZJsJdIhZM4B5In7UJ8cqQAxLBS+aQc38 BUtbV5fwZi7E1BzZilzX/OVyuUB0sGzmFKNBOWm929i4slPqNwCmZnGdTqfdqZf6DACHIXhqbanq bHTX661CZwVkf87qbtdWaw0XX9G/MmPzRqvVWt3IbbFKDcj+bMzg12trje1lB29AFr86g2+0ttvt NQdvQBa/NoPvXtlYa7h4A4oZTQ9m0Dqg3W6uvYQMObvhha8DfL2Ww6coyIYyu/QUQ56qebmW4Adc dAGggQwrmiI1ycgQh5DFbczoQFA9Ad4kuPLGDoVyZkjPhWQoaKaawfsZhoqY6nv1/NtXz5+iV8+f nDx8dvLwh5NHj04efm91OYI3cDqqCr78+pPfv/wQ/fb0q5ePP/PjZRX/83cf/fTjp34gVNDUohef P/nl2ZMXX3z86zePPfBtgQdVeJ8mRKLb5Ajt8wR8M8S4lpOBOJ9EP8a0KrGdjiROsZ7Fo7+jYgd9 e4IZ9uBaxGXwnoAO4gNeHz9wDO7FYqzykDue3YwTB7jLOWtx4WXhpp6rQnN/nI78k4txFbeP8aFv 7jZOnfh2xhm0TupT2Y6JY+Yew6nCI5IShfQ7fkCIh6/7lDq87tJQcMmHCt2nqIWpl5I+HTjZNBW6 QROIy8RnIMTb4Wb3Hmpx5vN6hxy6SKgKzDzG9wlzaLyOxwonPpV9nLAq4bewin1G9iYirOI6UkGk R4Rx1ImIlD6ZOwL8rQT9JnQPf9h32SRxkULRA5/OW5jzKnKHH7RjnGQ+bI+mcRX7njyAFMVojysf fJe7FaKfIQ44nRvue5Q44T67G9ylI8ekaYLoN2PhieV1wp387U3YEBPTaqCvO+06oenb3r1w794W 1Fs8N0517Hm40326zUVE//1tegeP0z0ClTG7Vr3t0m+7dPCf79Lz6vnie/O0HUOn1nsnu+k2W/Bk 7g58SBnrqQkjt6TZhEtYhKIuDGo5c/ok5Yksi+GnrmSYwMGNBDYySHD1AVVxL8YZbODrgVYykrnq kUQZl3BwNMNe3RoPhwBlj52r+kBiO4fEapdHdnhFDxfnjlKNsWpkDrfFRCtawaKTrVzJlYJvbzJZ XRu18Gx1Y5ppis5spcuaYnNAB8pL12CwZBN2Nwj2RMDyGpz/9dRw8MGMRJp3G6MiLCYKf02Icq+t IzGOiA2RM1xhs25iV6TQjH/aPZsj52OzZA1IO9sIkxbz82dBkgsFU5JB8HQ1sbRaWyxFR81gY3V5 NUAhzprBEI688DPJIGhS7wcxG8G9UaiEzdoza9EU6dTjDX9W1eEWY07BOGWcCal2sIxtDM2rPFQs 1TNZ+5dXGzrZLsYBTzNZzIqVdUiRf8wKCLUbWjIcklBVg10Z0dzZx7wT8rEiohdHR2jAxmIfQ/iB U+1PRCXcXJiC1g9wzabZNq/c3pp3murllsHZccyyGOfdUl/TFBVn4aaflDaYp4p54JvXduPc+V3R FX9RrlTT+H/mil4O4BZhJdIRCOGWV2CkK6UZcKFiDl0oi2nYFbDum94B2QJXtfAayIe7ZvO/IIf6 f1tzVocpazgMqn06QoLCcqJiQcgetCWTfWcoq+dLj1XJckUmoyrmysyaPSCHhPV1D1zTPThAMaS6 6SZ5GzC40/nnPucVNBjpPUq13pxOVi6dtgb+7o2LLWZw6tReQudvwX9pYrm6T1c/K2/EizWy6oh+ Md0lNYqqcBa/jY18qjc0YZEFuLLW2o414/HyamEcRHHWYxgs9zMZ3AUh/Q+sf1SEzH640Atqn+9D b0XwHcLyhyCrL+muBhmkG6T9NYB9jx20yaRVWWrznY9mrVisL3ijWs57imxt2SLxPifZ5SbKnc6p xYskO2fY4dqOzaUaInu6RGFoWJxDTGDMF6/qRyk+eACB3oHr/zGzn6lkBk+mDrI9YbJrwKNJ/pNJ u+DarNNnGI1k6T4ZIhodF+ePkglbQvZTSbFFNmgtphOtFFzxHRpcwRyvRe1qWQovny1cSpiZoWWX wuZSzacAPpTljVsf7QBvm6z1WhdXwRRL/wxlCxjvp8x78lmUMntQfG2g3oAydfx6ynKmgLzZxINP nQLD0atn+i8sOjbTTcpu/QEAAP//AwBQSwMECgAAAAAAAAAhAAjNJLsaJAAAGiQAABcAAABkb2NQ cm9wcy90aHVtYm5haWwuanBlZ//Y/+AAEEpGSUYAAQEBAEgASAAA/+EAdEV4aWYAAE1NACoAAAAI AAQBGgAFAAAAAQAAAD4BGwAFAAAAAQAAAEYBKAADAAAAAQACAACHaQAEAAAAAQAAAE4AAAAAAAAA SAAAAAEAAABIAAAAAQACoAIABAAAAAEAAAEAoAMABAAAAAEAAADAAAAAAP/tADhQaG90b3Nob3Ag My4wADhCSU0EBAAAAAAAADhCSU0EJQAAAAAAENQdjNmPALIE6YAJmOz4Qn7/4ge4SUNDX1BST0ZJ TEUAAQEAAAeoYXBwbAIgAABtbnRyUkdCIFhZWiAH2QACABkACwAaAAthY3NwQVBQTAAAAABhcHBs AAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtkZXNjAAABCAAAAG9kc2NtAAABeAAABWxjcHJ0AAAG5AAA ADh3dHB0AAAHHAAAABRyWFlaAAAHMAAAABRnWFlaAAAHRAAAABRiWFlaAAAHWAAAABRyVFJDAAAH bAAAAA5jaGFkAAAHfAAAACxiVFJDAAAHbAAAAA5nVFJDAAAHbAAAAA5kZXNjAAAAAAAAABRHZW5l cmljIFJHQiBQcm9maWxlAAAAAAAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbWx1YwAAAAAAAAAeAAAADHNr U0sAAAAoAAABeGhySFIAAAAoAAABoGNhRVMAAAAkAAAByHB0QlIAAAAmAAAB7HVrVUEAAAAqAAAC EmZyRlUAAAAoAAACPHpoVFcAAAAWAAACZGl0SVQAAAAoAAACem5iTk8AAAAmAAAComtvS1IAAAAW AAACyGNzQ1oAAAAiAAAC3mhlSUwAAAAeAAADAGRlREUAAAAsAAADHmh1SFUAAAAoAAADSnN2U0UA AAAmAAAConpoQ04AAAAWAAADcmphSlAAAAAaAAADiHJvUk8AAAAkAAADomVsR1IAAAAiAAADxnB0 UE8AAAAmAAAD6G5sTkwAAAAoAAAEDmVzRVMAAAAmAAAD6HRoVEgAAAAkAAAENnRyVFIAAAAiAAAE WmZpRkkAAAAoAAAEfHBsUEwAAAAsAAAEpHJ1UlUAAAAiAAAE0GFyRUcAAAAmAAAE8mVuVVMAAAAm AAAFGGRhREsAAAAuAAAFPgBWAWEAZQBvAGIAZQBjAG4A/QAgAFIARwBCACAAcAByAG8AZgBpAGwA RwBlAG4AZQByAGkBDQBrAGkAIABSAEcAQgAgAHAAcgBvAGYAaQBsAFAAZQByAGYAaQBsACAAUgBH AEIAIABnAGUAbgDoAHIAaQBjAFAAZQByAGYAaQBsACAAUgBHAEIAIABHAGUAbgDpAHIAaQBjAG8E FwQwBDMEMAQ7BEwEPQQ4BDkAIAQ/BEAEPgREBDAEOQQ7ACAAUgBHAEIAUAByAG8AZgBpAGwAIABn AOkAbgDpAHIAaQBxAHUAZQAgAFIAVgBCkBp1KAAgAFIARwBCACCCcl9pY8+P8ABQAHIAbwBmAGkA bABvACAAUgBHAEIAIABnAGUAbgBlAHIAaQBjAG8ARwBlAG4AZQByAGkAcwBrACAAUgBHAEIALQBw AHIAbwBmAGkAbMd8vBgAIABSAEcAQgAg1QS4XNMMx3wATwBiAGUAYwBuAP0AIABSAEcAQgAgAHAA cgBvAGYAaQBsBeQF6AXVBeQF2QXcACAAUgBHAEIAIAXbBdwF3AXZAEEAbABsAGcAZQBtAGUAaQBu AGUAcwAgAFIARwBCAC0AUAByAG8AZgBpAGwAwQBsAHQAYQBsAOEAbgBvAHMAIABSAEcAQgAgAHAA cgBvAGYAaQBsZm6QGgAgAFIARwBCACBjz4/wZYdO9k4AgiwAIABSAEcAQgAgMNcw7TDVMKEwpDDr AFAAcgBvAGYAaQBsACAAUgBHAEIAIABnAGUAbgBlAHIAaQBjA5MDtQO9A7kDugPMACADwAPBA78D xgOvA7sAIABSAEcAQgBQAGUAcgBmAGkAbAAgAFIARwBCACAAZwBlAG4A6QByAGkAYwBvAEEAbABn AGUAbQBlAGUAbgAgAFIARwBCAC0AcAByAG8AZgBpAGUAbA5CDhsOIw5EDh8OJQ5MACAAUgBHAEIA IA4XDjEOSA4nDkQOGwBHAGUAbgBlAGwAIABSAEcAQgAgAFAAcgBvAGYAaQBsAGkAWQBsAGUAaQBu AGUAbgAgAFIARwBCAC0AcAByAG8AZgBpAGkAbABpAFUAbgBpAHcAZQByAHMAYQBsAG4AeQAgAHAA cgBvAGYAaQBsACAAUgBHAEIEHgQxBEkEOAQ5ACAEPwRABD4ERAQ4BDsETAAgAFIARwBCBkUGRAZB ACAGKgY5BjEGSgZBACAAUgBHAEIAIAYnBkQGOQYnBkUARwBlAG4AZQByAGkAYwAgAFIARwBCACAA UAByAG8AZgBpAGwAZQBHAGUAbgBlAHIAZQBsACAAUgBHAEIALQBiAGUAcwBrAHIAaQB2AGUAbABz AGV0ZXh0AAAAAENvcHlyaWdodCAyMDA3IEFwcGxlIEluYy4sIGFsbCByaWdodHMgcmVzZXJ2ZWQu AFhZWiAAAAAAAADzUgABAAAAARbPWFlaIAAAAAAAAHRNAAA97gAAA9BYWVogAAAAAAAAWnUAAKxz AAAXNFhZWiAAAAAAAAAoGgAAFZ8AALg2Y3VydgAAAAAAAAABAc0AAHNmMzIAAAAAAAEMQgAABd7/ //MmAAAHkgAA/ZH///ui///9owAAA9wAAMBs/8AAEQgAwAEAAwERAAIRAQMRAf/EAB8AAAEFAQEB AQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNR YQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldY WVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TF xsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAAB AgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGx wQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpz dHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW 19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/dAAQAIP/aAAwD AQACEQMRAD8A/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKAP/Q/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKAP/R/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKAP/S/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKAP/T/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKAP/U/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKAP/V/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAP/W/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAP/X/v4oAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAP/Q/v4oAKACgAoAKACgAoAKACgAoA/P H9rX/goVa/sg+L/CXhrxT+yJ+118UNE8feOPhx8L/BPxG+EGjfs96p4G8TfE34q6kdG8H+ArFvHn 7Rfw88XW2uXer7dOubrVfCWneH7WeRJDrb2pM6gFGD/gpv8ABXSf2kv2b/2TPiv8OPjj8Bfjh+1B 4A1zxz4E8OfFfw74Dj0nQLzS9Z8b6XpHw88deLfAPxK8feF9F+Ivjmy+HXizxD4F0XTdW1vTdf0v ThYHW7TxTc2/hxgD6q+Cv7QPgj48ah8b9N8GWfiK0uPgD8cvE37P3jVvEFjYWUV5438KeGPBfizU 7zw61lqepNfeHZNN8daNFaX1+mmX8t5DfxS6ZDDDb3FwAes2viPw9fazqXhyy17RrzxDo0Nrc6vo VrqljcazpVtejdZXGpaXFO97Yw3igtay3UMSTgZiLCgCCx8W+FdTttZvNN8TeH9Qs/Dtxd2viC7s da027ttCutPjM1/bazPBcyRaZcWUQMt3DevDJbRgvMqICaAPG/H/AO1Z+zz8MPGPwr8A+Nviv4T0 fxV8Z/iB4g+F3gHThfDUI73xx4W+G/ir4ta7outX+nLdaf4Saw8C+Dta1V7zxVdaPYy3J0nR4LiT V9d0ayvQD50/aD/4KFeGfgZ8Ltc8eRfC3xF4i12+/aZ+H/7K/wAGfDGp+PPhT4b0j44+NfiPqfgT StE8c+G/G+n+MPF+l+GPhLp9x40vn8R+IfGVho/izQ4PBfiae68CGB/D0uuAH0r8Hfji3xP0bxzq 3iDwPqXw2t/h9q2k6Jq2t6v4u+HvibwR4huZ/h74R8beIdY8E+LfB/inWBf+E/C2peJr/wAGXur+ LNI8Eapc614X1i9i8PJosmnahegHpt54/wDAmneH9P8AFmoeNfCVj4W1Z7WPSvEt54k0e18P6nJf bvsUen6zNeJp1495sf7KlvcSm42N5QfaTQB57rv7R/wU8M/HTwV+zZr3j7SNM+M/xD+H3i/4o+EP B10t3HJq/g3wP4m8A+D9evl1b7P/AGJbX/8AwkHxN8IWWkaDd6jDrniBby+u9D0/ULTRtYmsAD1a PxH4em1258Lw69o0viWzsYtTu/DseqWL67a6bO4jg1C50lZzqEFjNIQkV3LbpBI5CpIzHFADdN8S +HNav9Z0rR/EGiatqnh24is/EGm6bqthf3+hXc6NJBa6zZ2s8txpdxNGjvFBexwSSIjMiFVJoA26 ACgAoAKACgAoAKACgAoAKAP/0f7+KACgAoAKACgAoAKACgAoAKAPza/4KWeBfG3jvw3+xhB4H8H+ KfGU3hb/AIKS/sS+OvE8PhbQNV8QS+HfBPhT4rW+oeKPGGux6TaXb6T4X8N2AN9r2v34t9K0izBu dQu7eEb2APmb9sr9ivX/ANrv9uD4o+H7iw8YeB9J1D/gnT4Fi+Dn7Rmm+HdTOl/CL9qb4a/tX618 UvhF4q8N+K/sg0seOfh/4j03w54zufDNvqMWqap4V+3afew/2Hrl154B2X/BF9P2jtQ+Ev7Wvjf9 qv4H+KfgB8ZviT+3N8UfF3inwR4j0XU9J0u+1S1+E3wK8F+IvFnw5vdSghHiv4U+IvGfhDxRcfDz xjpsl5pniHw5Ha3dveSuJlQA/OD9n34G6pZ/sH/H34C+Af2Svi54A/4LIS/s0/traF8Qv2qNf/Zn 8ZeAr/xX8d/iC3i0XXi3Tf24tf8ACug+B/iXZ/HHxBJ4av8A4WTeDvip45utEsLDwzda1p/hmHwK 8mlAGL8Jv2XdCm+B37cPin4LeGPjP4e8fa5/wSU+P37O+q/s4+H/APglp8av2HfDviDxfeeDFuPh 5pfiDUPE+lS6D+0L8ffBt/F4g8DeC5vh7qfja/v9C8b+JLm313VtL1bw9cXoB7h8f/2Ev2ZfgX8N v+CRXjyf9gnRfGHw2+EPxqt9X/aw0LwH+yLqX7QHxPuLX4lfsOfGv4e33jL4tfD3wh8PfHfxc+J9 3dfHO8+Fd18Qtd1vQvFniFfFen+HPE/iVpr/AEK3v7AA848RfsDaJe6T8QfAi/sV6Vc/DrTP+DhP 4K/EPwR4KP7OVnJ4N039mrWfhp+yvpXxI8beF/DLeDW0Wx+COqP4e1zTfHPiDSrKLwLePoerWXiC 6lbS72K3AI/ix+yLqXgOz/a68NaP+yV4tk/Y00z/AILW/sz/ABn+LX7P3wl+A+p3nhz4wfsiaF+w 1+zjoviu/wDAPwO8H+GDF8bvhtoX7Rdp4d8TfEHwf4A8K+LB4ll+Hvj7Sxoms6/pWqaagB7B+0l/ wqDXdK/Zj8NfA7/gnTo3g79l7xZbftX6nbeNfiX/AMEkPjB+0BrHgfx1qmrfDKODwb4L/ZB0LTPh 34v+AcX7UMlz4o8T3Hxe+L3hnwd4Xvofh6bHXtHspPGVv4itwDxP9kL9nM/DLx7/AMEOPir+1N+y H478SeI9F/4J7eNf2afFXjDWv2WPF3xa8a/Bv9pbSPih+yHqn7Os/wAY7nR/AvjDxR8IG8GeGfBv xLt/BvxY8dTaR4a+GdvD4hkn8Y+HbC+vb26AMr9kH9lHxXbftK/Cc/tBTfFnwF+1z8Kf25vj38af EXjbwp/wTb+LM+q/FfRvEvjr4uCG78S/8FJ9Mh1X4WeJv2ffit8HfE+gaS/hXXvFVg3h+w07wZ8M W8HaNr3gHQLK0APtD/gkx4LPwl+NfxT+FXw3+DPiPU/gBpfwvk8S6N+078av2IviR+yD+1Fpfjrx L8Vtc1bUf2bvjL43+JfhHwc/7Wmoafa6jfeOG+MngzRrOysrqAx+Mr3xRrvijTfEl2AfvjQAUAFA BQAUAFABQAUAFABQB//S/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKAP/T/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKAP/U/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKAP/V/v4oAKACgAoAKACgAoAKACgAoAKAPJfjj401j4ffDPW/ FWgNbpqtnqXhDT7eW50XUfEaQR+IfGfh7w5eXEegaRNb6nrN1b2WrXE9lplhKLq8vI7eCFJXk8pw DxHwx+0jf22iQ6/42339hBp3xyv7T/hH/CF1oGpeKrH4X+L/AAN4T04XHhjxJ4il1zwR4uudX8S3 OgSeFddZZJtRSS91dvCsaRaaoBveNvjn4z8EeI9Gu9X+HHiNNDtvhP8AFXx54v8ADFlqXge91PTL bwHrfgDGvxaofEEVvfQx6JrOsRWuj2Nwb6/1C6giuLSKC3GoRAG34w/aW8J+C/EHiLQtQ02S9bQ/ CXi3xVG2k+IfCWo6ldp4P8Gf8J1e2d34dt9bk13QP7R0NJjo91rlnZJdXEBE8VpbXOn3V6Ac78R/ j74o0nw9qtvoHw+8SaZ4p0vQPB3ijXnvbzwbeQ+C9F8b+NdU8NeGZdUi/t2aDVr3VLXw5rl7qVjo f9pvoVskTSyXFzLawygFb9oT42eOfhl4kSy8Kx2c9pp/w21zx3dWc/gLxR4uj1G50nxBpOnNa6xr fh7VLG38C+Ho9Ouru51DxXq0NzZ6SsbX80F7FavYXAB1fjD9pbwl4M8QeItCvrA6j/YfhLxb4rhm 0TxL4P1a9v4vB/gz/hO7y1m0Ky12bWdFTU9CSZtEvtYtLSG9mhzLHa2t1p13egDtU/aDl0K8NprP ww8ZWP2Dw94Q8XeJ5f7S8HXC+FfDnjfxj4i8IaNcaikHiJnvtRjbw/JrGoadog1P7NpzXUaXM1/a wWV+AZp/am8Iyap4y07T/DXifW4/Cdr8Q3SbQ/7G1a71O/8AhhrP9geJdOfR7PVZNV0VrjUor06B ea1a2VnrFjpl/fCW1i+wLqAB7z4N8TWvjLwxo/ieyNkbTWLZrmBtN1nS/EGnyIs0sIls9Z0a4utN 1C2lMRkhnt5s7GCXEVtcpLbxAHTUAFABQAUAFABQAUAFABQAUAFAH//W/v4oAKACgAoAKACgAoAK ACgAoAKAMPxF4b0XxZpbaLr9l9v0x77R9Sa2+0XVrm90HWLHXtJm86znt5x9l1bTLK68sSiKfyPI uUmtpJYXAOJ1D4K/DHVbvxDfah4XiuZ/FMHiu31wPqetpb3Ufjiy8H2HikwWcepraabNqsXgPwtc PcaZb2dxa6pp02s2Mlrq+q6ve34A8/B3wFLY3FhfWGt6zHeeE/Fvge7uvEPjPxp4h1W68L+OZdMl 8T6Xca1rev3+rSrfto2mLDdNe/bdKhtEt9IubGBpI3AMjUP2f/hRqt7rN9qHh7ULhtfg8Q2+pWR8 X+NI9GceK/C7eDPElxaaDF4hj0XTb7WfDbtp99qGnWFrfSOft63K6mXvWANbxZ8Gvh3431JdW8R6 Pf3V5/Zek6LdCx8UeK9Ds9W0rQNUuta0Gy17TdC1vTtP8Qw6Fq17fajow1y1v20u7vr2axaF7q48 0Ak8bfCHwF8Q9Qi1PxVp+sXV3Hod/wCGZv7M8Y+M/DNpqXhzVLiG51LQtc0/wzr2kaf4h0i+lt4/ tWna5bajaTRGW3khME8ySgGNqP7P/wAKNWvtav7/AMOXsp1+HxDBqOnx+K/GFroWPFnhd/BniOWw 8OWuvwaBpF1q/hp2067vNK02yuif9NjmTUc3jAHW6x8N/Bevza3cavo32uXxFoHh7wvrD/2hqsH2 zQvCuq6vregWO22voVt/sGqa7qt19ptRBeXX2ryby5nt4LeKIAzoPhN4Os7nX7nTj4s0keJZ9WvN TstG+IfxA0fSI9Q1/Uv7Y1vVdJ0XTPE1rpOgatqmrGXU73U9DstPvZr+71K7MwuNX1V70A6jwt4W 0PwZolv4e8O2stpplvc6pfBLm/1DVLu41DXNVvtd1nUb7U9Vur7UtR1HVtZ1K/1TUb6/u7i6u727 nnmld3JoA6GgAoAKACgAoAKACgAoAKACgAoA/9f+/igAoAKACgAoAKACgAoAKACgD5H1H9oXWrPV dd8PLouotqVh+0R4K+F9nqaeCvFEvhRfCviDxN4F0y/e98VRodAi8QCx8Q6otqZNRhVb46fG1hK7 LBcAFnTv2t/B2sWOpajo/hfxLrFrEPDM2g/2Vd+GLybxDa+KfiDofw605SP7dig8O6pLqniLStUt 9I8UXOj3Nxol2LgvFeWmr2OlgGxe/tHpawx28Pw08Y3/AIit7f4pXGueHbTUfCCzaGnwju/DEXiN 5tRu/ENrpt9FqNr4r0u70A6fczy3bXEFtfQaWxu3sACZfj2j6tc6fofh3XvGt1rfjzSfCPhTS9Pi 0DQjEuofA/RfjF9pvdS1rXra3l08aVcXcs91Mlrfw3c39mW2mXotoLi9AM/T/wBqXwvrfiL4c+Ht C8N6ze3PxD0v4f6zDFdan4b03VdIsPiFp2uatZXEugS6vJq+qwaDp/hzVX8TXujW15p2nzxxQ297 ehNQk08A1/GvxP8AEHgn4pWdh4q1Cy8HfC6fStKfR9euvBmreILDxVr8w16TXfDt74t07Xba08E6 3awWWkP4as9Y0VrfX5Li5t9Nvdb1KdNH00AxtU+NXjm7j+DOsaF8NPEtna/EPxbeW0Hhu/1HwMNV 8Q+Gbr4U+M/GOk3b3jeIZLPw5LZ3ulabeavbXF0l9ClvLY2Y1N53t2AOi0z9onwrq+iQ6/Z6Nr4s 7jQ/gXryRXEenxXaW/x48Uy+FNAtpolvpIo7vQr6F5deVJ5IREpGnTXrBQwBieCfjbrlzdeGNB1v w5f67e+J/EPxtRde0q40O3t9H0H4a/EDxtogutT0c3Nvfpp+nWGmeE9Cl1WOCRLrW/EmjwsZLi5u ZEAKCftJgaL4c8aX/gzxVpejeIvhjqnxF0jws6eGLzXtY0g698MtL0S/W+t/E5sNNvLxPHiCDQ7x 4yyebNqd9pc1rFaTgG/J+0FMJ10S2+GPi+88aR+JPFPhe/8ACkWp+D0k06/8L+FtB8bSzzazP4hi 0iax1Dwz4m0a6spbS5uJxe3Y0+e1iaOa4QAp6Z+1L4E1zxN4W8P6Lpus38PiaHwE329ZdGiutMn+ JPh+y8TeGUufDzaodfubWLStV0aXX9UsLK707Rm1e1Z57iC11q40gA+mKACgAoAKACgAoAKACgAo AKAP/9D+/igAoAKACgAoAKACgAoAKACgDiJfhx4MmgvraTRt0GpeN9K+I96n9oaqPO8Z6JqWjatp ms7hfB4/s2oeH9In/s+Jo9Km+yeVcWMsE9zFOAYdl8GPh9p9nPpltp+t/wBjTaro2tQ6BP408a3f h3S9Q8PeKbHxpo76F4fuvEEujaBb2HiTTbK+hsdFsbCy8iEaS1s2js9iwBo/8Kr8Bf2lf6v/AGF/ xMNTg8aW19cf2nrH7+H4h/8ACO/8Jgnlf2h5Mf8Aa/8AwimgfNFEjWH2D/iWGz+1XpuABul/CjwD ouoafqmmaD9mv9L1m18QWE/9qazN5Gr2Xw+g+Fltd+VPqMsMvl+BLWDQvImje2fy/wC05IX1hn1B wDyK2/ZsTQ/HWk+JPBvjO98I+HNITwBZ2/h3Tf8AhLv7Qj0PwGkMS+GTqcXj+18OaxoviC0t/sGt SeMvA/i3XTY3l5FZa3azQ6BcaAAeva78LfBnifxBa+I/EFnq+rXNncWd5DpN74s8WS+D2v8ATo3j sNRuPAh1r/hCrvUbMP5kF9daBNcpcxWt55pu7KyntQCr4c+EHgPwqvh1NJsdbdPCOovqfhdNZ8Ze M/EiaBMfDmo+EkttKXxFr+qLZ6Vb+HdX1DTrTRIQuj2i3BurexivUjuEAMWT9nz4TO/h0jw7qEMX hbTfBekaVZ2vi7xpZ6dLYfDnWpfEPgaLWtMtPEUFh4lk8L61cXOoaTceJLbVrmCe4nJlZJWSgC/p 3wR+HOkeIh4q0rTNc07WPs2pWcpsvHHju20u7tNX8ReJ/FuoW2o+H4vEqaBqcM/iLxj4i1QJqGl3 IhmvokgEUGn6ZDaAFy4+D3w5utN0HR5/Dvmad4Z8Hw+AtEt/7W1xPsXhOC+8MalFpXmpqaT3Oy98 G+G5vt13LPqTf2d5bXhivL5LoA1Ivhv4Lh8Q3PiuPRtuv3mr6nrtxf8A9oaqfM1XWPDOg+DtSuvs rXxsl+0+HPDGh6d5KW4tovsX2uCGO/uby6nAMfQ/g34B8MXujX3hyw1vQX0LR/Dmg2tppHjPxpp+ lXum+EtMj0bw7Hr+jW2vx6V4muNN0mGDTlvvEVnqt/dWVva219dXEVnapEAeoUAFABQAUAFABQAU AFABQAUAf//R/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKAP/S/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKAP/T/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKAP/U/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKAP/V/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKAP/W/v4oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKAP/ZUEsDBBQABgAIAAAAIQB13P0GXAMAAKsSAAATAAAA cHB0L3RhYmxlU3R5bGVzLnhtbNxYXW/aMBR9n7T/EOU9zQeBplVDBQG0Sd0eOrb3fDgQ1bFR4hWq qf999s2XoYSyQdSqLzSh1+feY1/fc8TN7SbFyiPK8oQSVzUvDFVBJKRRQhau+nM+0xxVyZlPIh9T glz1CeXq7fDzpxv/mgX4B3vC6C5nCkch+bXvqkvGVte6nodLlPr5BV0hwv8X0yz1GX/NFnqU+WuO nmLdMoyBnvoJUZUIxa76p+9ZVt+2R9rldDrQ7J5taWPDdjSnP554V7OJ6fVGz+pQys1r4xV8jfji wZVhWlNvovXNmafZ5szURiNnopljy3Z63mQw6E2fBRm+4Lufci53yWLJFOCgWIqmjMIQEaaYkGG9 pBjNAwzZwvkGwsRLTAm7R7GSRBtXTRNCM4jPw2wReDhTMlflm8h3j38G4lMf3uj1MoEAm4NE7KOP XZVtzDKGyXlYWKdk4TjKxEqMYgZ/SV1BUe0OpA9MKlgsoqGIan0mmJ8CVAMwujoFp1weUMZoegpQ g5CQPInQlwJMfBI6SzAuTgET2Acppnj8dUQ4j+HnWJ9FzEF34YvvIKo8PP4sd1LAb5IJte073ve2 mQ3dHUoNDXiC3dtHqOo36MDixrxpvx4mBDQEIetjECpoYD9nHt2eY2IwUSKmjmjo7TlTXJT6W75l EkKcZKeiyRAC+Z6uizLKGXuoNgisJo6ydtW+4Rh8zobpiktAFOBiFFOcROLOi/CDkzFvIgXPYjjA LWztFKlkYNJSvkh9dqUIFtVIP6gUcKxiFP2LSJTx5YxrpldDUmxJKflwDuWzJMHH6bcswd9QlPxO z6XBK9GclawG2A8fXhXf6OGoLRWEm2EmOs+0LpvOy8ni1c7DrMq0t+sq9FpZMekiTQ1fa00XWfbI ehdpWkS/i1RtjqG7XC12Q2qe1uEG1zPhVhb8JbfZvFOLsV5PQ7jnEha/3CeYl3riiMwS6pEV2qdU uO1FrL3m6qWmgcxDbLuDeXNWrxiSFlawStLsWitKZRVn1CJN/zFAm7FW54H2e+kqqg47rkMKclIv tXWoxFS2FnU1H5O1TFWyJO+CNZy/7NJ6jnlWrdxxaB02VunuGhMk/PK2UX2T6ySSNupXWIVz73KF 31jhjja62d0tiym98J+Yhn8BAAD//wMAUEsDBBQABgAIAAAAIQCQgA4prAEAAH8DAAARAAAAcHB0 L3ZpZXdQcm9wcy54bWyMUk1P4zAQvSPxHyzfIWnFpm3UlAuCC9IiNXA3zjQ1cmzL45aWX884Ttvd 0gM3z9eb9954fr/rNNuCR2VNxUe3OWdgpG2UaSv+Wj/eTDnDIEwjtDVQ8T0gv19cX81duVXw+eIZ ARgsRcXXIbgyy1CuoRN4ax0Yqq2s70Sg0LdZ48UnAXc6G+d5kXVCGT7M+9/M29VKSXiwctOBCQnE gxaByONaOTygud+gOQ9IMP30/5S0wPBG6iqOuqnXm+7dCKVjhi9IuImS+vDFx5hwgvXQPMMqMPwi G/8U45xn/9Zq6/rS7K4o+lL2Ewe1aiBuSbByqZsUMTTC1fbJq6bidKEU/n3/ABmQ1vWs5NC7FX4p haZbpTzGYDEXJe4YnbiYcEYoo7xnQdn9zyxxG6Zcab1qlWG7it+MZpOCsz29ZkVUR23D0qi03RD7 ZwzHN6NR8pdOYf0XZ84S1fEoqR/ah+R0erDkBBLBjwb0u87sMTYA1rDrLzU4djLvTHWUe0H2Wfqy bpokzQeGR8XUfIFCSzdaOiHpmzNJpk3oJxCAJIT0TL5t05W/AQAA//8DAFBLAwQUAAYACAAAACEA XJxHFE4BAACJAgAAEQAAAHBwdC9wcmVzUHJvcHMueG1stJDNasMwEITvhb6D0V2RZDt2bGIHO3ah 0EMO7QMIW04E1g+S8lNK373CcUtDL7n0tssys9/MenMRY3BixnIlC0AWGARMdqrncl+At9cnuAKB dVT2dFSSFeCdWbApHx/WOteGWSYddV66M4E3kjanBTg4p3OEbHdggtqF0kz626CMoM6vZo96Q8/+ gRhRiHGCBOUSzHpzj14NA+9Yo7qj8ABXE8PGicQeuLbfbvoet985bpBKH5Jd3It18xQcDS/AR5sm 2zaLK5jgaAtjEoewztoaJg2JUowJrsL0E3gNifOe246a/lnQPWt77hrq6BzVn//gCd4ZZdXgFp0S 6JoTaXVmRis+RSV47utExwJggMo1mjBvGZuIVDgJK5hmqwrGUZjBqm4aWNfVapkkIV4S/MPIBnoc 3cTYaP5feFfMqU0//m59Z8ovAAAA//8DAFBLAwQUAAYACAAAACEAfPqKzEsCAAAKBQAAEAAIAWRv Y1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcVG1v2jAQ /j5p/8HKp00TBBhjFTKuplRVJ40SNaH77DoXYs2xM9vQ0l+/S9LQMNikLZ/u5cm9PHdnevlUKrID 66TRi2A8HAUEtDCZ1JtFsE6vBxcBcZ7rjCujYRHswQWX7O0bGltTgfUSHMEQ2i2CwvtqHoZOFFBy N0S3Rk9ubMk9qnYTmjyXAq6M2JagfTgZjWYhPHnQGWSD6hAwaCPOd/5/g2ZG1PW5+3RfYcGMpsZz lcoS2GxKw1eNfjc2c2zyeULDVqRfqkpJwT0SwpZSWONM7smSC6m9cQWJzSPY2KBGwz4WGQGHbTV/ Xjdds5UeOGEBNEkK80jeTecf39PwDJDG3PKN5VXh2AVW2FNpomQGjn2i4YtEb41Hw4iGrUBvZJaB fvGi+Uiny2WkZNXgO5EmgiuIkCKWc+UAQx8M9AZ4Pf6YS+sY3fn5DoQ3ljj5jAswDcgDd1ATuwh2 3EquPRJcw1qlkVXlvGUpbgLGRl+rN2If1pfllI0bAAp/Bbaxmm5JKr0C9w8pkEUs5yRFbWzbxNzH BLQpVjmOxJ/hY9bnoymtZaOtctVsPDkh4kBJektEfUZ4GByH2u/kgIkQQD6QVZTEZ/1J+vWOcCsK 6XFSW3tE+SHKHfzcSosD0f58mlVV77wjeOzE/gF8xNNvzESmrLjes8iobfkgOVlr2bwsfk/Dzkm/ Sf3DravUXGG/3fYdG2lScAsZvhOd/9VAb3DxrKqDRAXXG8g6zKmjPuX79mlj4+lwhF9zsp2tvsTu EWO/AAAA//8DAFBLAwQUAAYACAAAACEA6ORJ0e4DAACzJAAAKAAAAHBwdC9wcmludGVyU2V0dGlu Z3MvcHJpbnRlclNldHRpbmdzMS5iaW7kWc1y2jAQprnBG/TmcgeRhIa045ChEKbMkMQToDM9ZRRb oU6M5bFFU/pIfb/eu7ItI/wX2kNqO4fMOEJa7e+3q92DWq32Bv5+va3V1PMfK0v5TlzPpPZZ87Dd aSrE1qlh2suz5mI+bp02z/sN9d3oejj/ql0ojmV6TNEWn6aTodJsITRwHIsgNJqPFG06mc0VoIHQ xVVTaX5jzPmI0NPTUxvzXW2drvhGD2kudYjLNlMg1oIDbYMZTbgmoL7DDqwaps76jbr6SDZ9IBES c1zTZm0NL8mYuisMn5efqWv+pDbD1g3xVMT3w7HwePp5ZuqPhLV1l2BGXXGmrnoMyC+l6x7oXbBX ReFvjXouSZOR1cB18WZLFPN/gSU4KJjKoPG8WJwIMG31e0cq8j843VyOPIYZGVt4GXEE+0GJZEnc fkdF4tNnEAkOVSTYVsXa85a4dk0CdmDgVeKySOTU02WwQ4pQXONCbYe7GiyKKWY6tsCVq2OGmEBR IID+CxcHXwDlTDBApfAoRajICIVEI8FwzHPKj0gZgkXWKEhIeOu7eZBnHQx5/9a07+ltgPjpsKRd atpI43uH1CBXeEXEPilz/k0e2Teh54J2MqPXVZEbucqNoE6Bz4BMjhR8S1hGTAljBCqPbVUhzsdr nUBj7bQ0vs1CsTxej5I23BhlcmnV16LP6dzFtmf5OXvmVz++AUqt/D1EkiyxmCnFMMbcpEtccu1n yCCp28YtqwC+H4+yndJ7YDysPUYMvnhDdFZGGPo3AbmhJHCD/0SdG0eY/J+CN8pxVy7O4IS//L53 srMsAdTLY+CeaoKcVHFHiEuY9ATfeK3D0x3jhTbNWO710j3gw+5ywTwAVDGBWgVaC6VG46Rr5wlW Boje8r+wcSUxei8Jk6H56kA6XU+wWh2U3k/EpC+8Oph2HKO6UJ0lnATXRXi9xHNN+GgdaBNoVvAp w7aEDl+8nU77CGrK7fs372HPNo7UCwjPxO/0kzVP3HO/6yDRjl7DeXckeRVv9TireVRkTsX5JKNi ehHnVDCqIn8m0m8cwMTmd6MCE5sR1dcrGA4EEkO8zhxKrWCGI3wjaqXkKbhoM5t9BJOClY/EoDXM RyTIMe4lJ+Wb0mZdYSil9X+yHmfCjYBi1PyJ1lIv0fhYbQbvcpgZeGCdIXXMsg/TckXi2hZVU4FG OEmeN0NqQXsugr9SBkmKe8Xl4gZh7pogf1JaoFAYm67HeCeo1DAVt0BCqnIExBRX0BZxoWRTHB12 e93T45Nurzhz5hhI+V1SbFcsQBJScavIrdHM9LFNLNnGi9Iyp/rfsn5YWrxg5Su7zrPF7x8AAAD/ /wMAUEsDBBQABgAIAAAAIQDY8jz9dgEAALICAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMklFPwjAUhd9N/A9L37d2A4U0rCRoiA9ijM5o fGvaCzRu3dIWJv562wETog8+tufcb+eebjL9rMpoC8aqWucoTQiKQItaKr3K0Usxj8coso5rycta Q452YNGUXV5MRENFbeDR1A0Yp8BGnqQtFU2O1s41FGMr1lBxm3iH9uKyNhV3/mhWuOHig68AZ4Rc 4wocl9xxHIBx0xPRASlFj2w2puwAUmAooQLtLE6TFP94HZjK/jnQKSfOSrld43c6xD1lS7EXe/en Vb2xbdukHXQxfP4Uvy3un7tVY6VDVwIQm0hBnXIlsOIhEqGhpRLcgZ3gXgkeYYC72rA70Np3HnnQ pvwySmvonEc99F1y6xb+aZYK5GzHnpRYcyOjGTc6cH87wpCBrQqPy0adoz/6j3d97BOAjPyGdN/H UXkd3NwWc8Qykl7FZBRnpEhHdDimhLyHcGfzYeP9RXWI+B/iqMhSOiA0HZ4QjwDWJT7/y9g3AAAA //8DAFBLAQItABQABgAIAAAAIQB2RcsbAAIAAE8PAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVu dF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKPsgiYNAQAA4gIAAAsAAAAAAAAAAAAAAAAAOQQA AF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAAAAAAAAAAAAAAAAdwcA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhABRrO4W/AAAA NwEAACAAAAAAAAAAAAAAAAAAdggAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhABRrO4W/AAAANwEAACAAAAAAAAAAAAAAAAAAcwkAAHBwdC9zbGlkZXMvX3Jl bHMvc2xpZGU0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAILFtG9bAQAAGAcAAB8AAAAAAAAAAAAA AAAAcAoAAHBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHNQSwECLQAUAAYACAAAACEAFGs7 hb8AAAA3AQAAIAAAAAAAAAAAAAAAAAAQDQAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJl bHNQSwECLQAUAAYACAAAACEAFGs7hb8AAAA3AQAAIAAAAAAAAAAAAAAAAAANDgAAcHB0L3NsaWRl cy9fcmVscy9zbGlkZTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEA14kgKnQCAAAxDQAAFAAAAAAA AAAAAAAAAAAKDwAAcHB0L3ByZXNlbnRhdGlvbi54bWxQSwECLQAUAAYACAAAACEAROmA1zgGAACA HAAAFQAAAAAAAAAAAAAAAACwEQAAcHB0L3NsaWRlcy9zbGlkZTIueG1sUEsBAi0AFAAGAAgAAAAh ACK1YIV6AgAA8gUAABUAAAAAAAAAAAAAAAAAGxgAAHBwdC9zbGlkZXMvc2xpZGUxLnhtbFBLAQIt ABQABgAIAAAAIQAm04wnVQUAAB8YAAAVAAAAAAAAAAAAAAAAAMgaAABwcHQvc2xpZGVzL3NsaWRl NC54bWxQSwECLQAUAAYACAAAACEAWXs7aDMGAAAyMwAAFQAAAAAAAAAAAAAAAABQIAAAcHB0L3Ns aWRlcy9zbGlkZTUueG1sUEsBAi0AFAAGAAgAAAAhAPMxxPiNCQAA3y8AABUAAAAAAAAAAAAAAAAA tiYAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbFBLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAA AAAAAAAAAAAAAHYwAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJl bHNQSwECLQAUAAYACAAAACEAsk3wneEHAADTLgAAIQAAAAAAAAAAAAAAAAB/MQAAcHB0L3NsaWRl TWFzdGVycy9zbGlkZU1hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAA AAAAAAAAAAAAnzkAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAApzoAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAA NwEAACwAAAAAAAAAAAAAAAAArzsAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3 LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhADTNuc4fAQAAxwcAACwAAAAAAAAAAAAAAAAAtzwAAHBw dC9zbGlkZU1hc3RlcnMvX3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh ANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAID4AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAA AAAAKD8AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAMEAAAHBwdC9zbGlkZUxheW91dHMv X3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAC6r+ukYBAAArQwAACIA AAAAAAAAAAAAAAAAOEEAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWxQSwECLQAU AAYACAAAACEAwKRYOcoDAADNCwAAIgAAAAAAAAAAAAAAAACQRQAAcHB0L3NsaWRlTGF5b3V0cy9z bGlkZUxheW91dDEwLnhtbFBLAQItABQABgAIAAAAIQBO2xpttQMAAJcLAAAhAAAAAAAAAAAAAAAA AJpJAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWxQSwECLQAUAAYACAAAACEAwMJ+ C54EAAAGEQAAIQAAAAAAAAAAAAAAAACOTQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEu eG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAa1IAAHBwdC9zbGlk ZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+ AAAANwEAACwAAAAAAAAAAAAAAAAAc1MAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlv dXQ5LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAAe1QA AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc1BLAQItABQABgAI AAAAIQBLBdw76wQAAFoRAAAhAAAAAAAAAAAAAAAAAIRVAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl TGF5b3V0My54bWxQSwECLQAUAAYACAAAACEAiUtibXsEAABpEgAAIQAAAAAAAAAAAAAAAACuWgAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAhAEWfnh3XBQAA OBwAACEAAAAAAAAAAAAAAAAAaF8AAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbFBL AQItABQABgAIAAAAIQBXg0ChEwUAADISAAAhAAAAAAAAAAAAAAAAAH5lAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0OS54bWxQSwECLQAUAAYACAAAACEAX0Loo1UFAADDEgAAIQAAAAAAAAAA AAAAAADQagAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDgueG1sUEsBAi0AFAAGAAgAAAAh ALZT4uMOAwAAZwcAACEAAAAAAAAAAAAAAAAAZHAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQ3LnhtbFBLAQItABQABgAIAAAAIQCDdeb0PgMAALoIAAAhAAAAAAAAAAAAAAAAALFzAABwcHQv c2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWxQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAA LAAAAAAAAAAAAAAAAAAudwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1s LnJlbHNQSwECLQAUAAYACAAAACEALTqwYOEAAAB4AQAAFgAAAAAAAAAAAAAAAAA2eAAAcHB0L2Nv bW1lbnRBdXRob3JzLnhtbFBLAQItABQABgAIAAAAIQCTCm11EwcAAOcdAAAUAAAAAAAAAAAAAAAA AEt5AABwcHQvdGhlbWUvdGhlbWUxLnhtbFBLAQItAAoAAAAAAAAAIQAIzSS7GiQAABokAAAXAAAA AAAAAAAAAAAAAJCAAABkb2NQcm9wcy90aHVtYm5haWwuanBlZ1BLAQItABQABgAIAAAAIQB13P0G XAMAAKsSAAATAAAAAAAAAAAAAAAAAN+kAABwcHQvdGFibGVTdHlsZXMueG1sUEsBAi0AFAAGAAgA AAAhAJCADimsAQAAfwMAABEAAAAAAAAAAAAAAAAAbKgAAHBwdC92aWV3UHJvcHMueG1sUEsBAi0A FAAGAAgAAAAhAFycRxROAQAAiQIAABEAAAAAAAAAAAAAAAAAR6oAAHBwdC9wcmVzUHJvcHMueG1s UEsBAi0AFAAGAAgAAAAhAHz6isxLAgAACgUAABAAAAAAAAAAAAAAAAAAxKsAAGRvY1Byb3BzL2Fw cC54bWxQSwECLQAUAAYACAAAACEA6ORJ0e4DAACzJAAAKAAAAAAAAAAAAAAAAABFrwAAcHB0L3By aW50ZXJTZXR0aW5ncy9wcmludGVyU2V0dGluZ3MxLmJpblBLAQItABQABgAIAAAAIQDY8jz9dgEA ALICAAARAAAAAAAAAAAAAAAAAHmzAABkb2NQcm9wcy9jb3JlLnhtbFBLBQYAAAAALwAvACsOAAAm tgAAAAA= --20cf307cfd3cb48ef8051be2aa55-- From nobody Mon Jul 27 19:40:09 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0891A7D83 for ; Mon, 27 Jul 2015 19:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 YAIzPAAiX55d for ; Mon, 27 Jul 2015 19:40:05 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (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 269541A70FD for ; Mon, 27 Jul 2015 19:40:05 -0700 (PDT) Received: by qgeu79 with SMTP id u79so66341252qge.1 for ; Mon, 27 Jul 2015 19:40:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ewCeBF18E8wNIAKP1ev0+7t+1uj+WxX9Rh+FX3J7mME=; b=lNKAf2ur26fh3sYt1I4l4lxkIllU/Jbc2Ohs/Db2ZqroeP29Sta+NSX9g/rUaf1QR9 bHUUNg3PU1CjFz0X01n7Of3nVBDV9J0kxAuYxMGvpItpHpPkJRLi4RHCitrsHD97jYbP n/mjZv8m/aeWPTz/7ahyRreY7YwKu+eeF9nYQizPLtu08eyOcuPPWR5rqsCcbuGyQ5ZR PDxrAQPflE5Bx5oKpr9iFZp016nTgnAKzcMUKS99Gnlcpsfknw2f/FJmQyKEShTJh6cH APTjbj7MNfM3V08a3LRhvUmTVuf8/E8OhXou9wHMWAltDmwG5G2nqsjSFeiVF1qRpj+I NiHQ== X-Gm-Message-State: ALoCoQkqrWM3KNX0w0bTaGLsqU4uhMIknpudyYFfAChtSL7sHJjjLYO0e5O+n+6kcbA/QQhGz/uA X-Received: by 10.140.40.168 with SMTP id x37mr45426302qgx.24.1438051204370; Mon, 27 Jul 2015 19:40:04 -0700 (PDT) Received: from nrosebro-ltw7.cis.neustar.com (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id n6sm10355829qhb.16.2015.07.27.19.40.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jul 2015 19:40:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Brian Rosen In-Reply-To: Date: Mon, 27 Jul 2015 22:39:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Barnes X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 02:40:07 -0000 What this means in practice is that it=E2=80=99s TN per cert. I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier to = maintain dozens of copies of millions of private keys securely, but = it=E2=80=99s hard. You need multiple copies because you have multiple = elements that can initiate a call, and you don=E2=80=99t want to depend = on a centralized resource to do something as basic as create a call. I think it=E2=80=99s hard enough that REQUIRING cert per TN is not = acceptable. Folks with more intimate knowledge of carrier SIP infrastructure might = have more insight than I do. It may be acceptable to have a centralized = resource to manage millions of keys. Brian > On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >=20 > After the STIR meeting in Prague, Henning and I spent a few minutes > talking through options for revocation checking and certificate > scoping, and I think we have a better idea of what the optimal > solution looks like. Some notes are below, and some slides with > pictures attached. >=20 > tl;dr: We should: > * Keep TNs in certificates and not bother with any OCSP extensions > * Require Identity-Info to include OCSP responses for all certs in the = chain >=20 >=20 > # Background: Revocation in the web PKI >=20 > In an HTTPS transaction, the HTTPS server provides the client with a > certificate, and it can optionally include an OCSP response ("staple" > it to the transaction). >=20 > A certificate contains a validity interval, a key, and some names/TNs. > An OCSP responses contains a validity interval, a certificate ID > (i.e., a hash), and a status (good/revoked/unknown). In the web PKI, > certificates are required to be no more than 39 months long, and OCSP > responses no more than 10 days. >=20 > Ideally, a client only considers a certificate valid if it is > accompanied by an OCSP response. In practice, this is not always > possible; because OCSP queries fail around 3% of the time, browsers > can't require OCSP. This operational fact will be important below, > but we will continue to have scoping cert lifetimes as an objective. >=20 > In the web PKI, there are basically three revocation checking = modalities: >=20 > 1. Live OCSP checking [RFC6069] > 2. OCSP stapling / must_staple [RFC6066, draft-hallambaker-tlsfeature] > 3. Short-lived certificates (~OCSP lifetime) >=20 > (The last of these is relatively novel, and has not been deployed. > Neither has must-staple. But they're both pretty trivial, and could > be folded into a STIR architecture pretty easily.) >=20 > Right now, about 90% of TLS transactions use live OCSP, and about 10%. > CAs and browsers dearly want the world to move toward stapled OCSP or > short-lived certs, because these reduces latency and improve the > quality of revocation information. >=20 > Revocation for CA certificates is currently done by having browsers > download a list from a centralized server, since there's no way to > staple more than one OCSP response. That solution works OK for the > web, but if I were designing something de novo, I would probably use > multi-stapling as well. >=20 >=20 > # Applying this experience to STIR >=20 > Most of the below appear to be desired properties by the WG: >=20 > * Verifier neeeds to know that a cert is valid for a specific number > * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if > issued longer) > * Caller privacy: Don't report what calls someone receives to a = central server > * Carrier privacy: Don't allow a third party to figure out all the > numbers a carrier holds > * Minimize the rate at which the CA has to sign things > * Tolerate outages at the CA >=20 > I'm going to assume for now that we will not do live OCSP. It > violates the caller privacy requirement, and as discussed above, it > just sucks operationally. So STIR should require OCSP to be sent in > "stapled" form, which probably means sending it in Identity-Info. And > while we're at it, we should also do "multi-stapling" -- send an OCSP > response for CA certs as well. >=20 > So if we consider a server with 50k TNs / blocks, that leaves us with > basically 3 options: >=20 > 1. 50k short-lived certs (no OCSP) > 2. 50k long-lived certs scoped to TNs + generic OCSP > 3. 1 long-lived cert not scoped to TN (or a few loosely scoped) + OCSP > with TN info >=20 > (As I didn't quite get to say in the meeting, regardless of the > approach, you have to have 50k of *something*.) Of these, it seems > like the preference order is 2 > 1 > 3. >=20 > Option 3 is bad from several perspectives: > * Putting TN info in the OCSP response enables someone to trawl for > numbers unless you access-control the OCSP server, so you inherit a > requirement to do that. > * With the rate of churn in number assignments, you're probably going > to have to update the long-lived cert pretty frequently anyway. > * Putting TN-specific stuff in certs is better than putting it in > OCSP. As bad as X.509 libraries can be, OCSP libraries are much > worse. >=20 > Option 1 is mainly bad from the perspective of CA load and outages. > With Option 2, if the CA goes down, client can continue to use the > long-lived cert and just not bother doing OCSP (vs. tolerating an > expired cert). Slightly cleaner. Plus, there's a lot more experience > caching OCSP than new certs. OCSP signing can also be delegated, so > you can have the recurring operation done by a lower-risk key. >=20 > Option 2 should be pretty easy to automate. You can probably re-use > tooling for OCSP stapling that has already been developed for use with > HTTPS. If you're a big box signing for a bunch of numbers, you do > need to select the right cert and OCSP response for a given call, but > that's a pretty simple lookup table. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Jul 27 21:36:36 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879711A1A5D for ; Mon, 27 Jul 2015 21:36:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 gNyfz7BZIFUy for ; Mon, 27 Jul 2015 21:36:33 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F0A1A1A7C for ; Mon, 27 Jul 2015 21:36:29 -0700 (PDT) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-06v.sys.comcast.net with comcast id xgcF1q0044zp9eg01gcVc4; Tue, 28 Jul 2015 04:36:29 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by resomta-po-07v.sys.comcast.net with comcast id xgcU1q0094EJ4tY01gcUBo; Tue, 28 Jul 2015 04:36:29 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Mon, 27 Jul 2015 21:34:07 -0700 From: Alex Bobotek To: Brian Rosen , Richard Barnes Date: Mon, 27 Jul 2015 21:36:26 -0700 Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AdDI3mU96U9k6B2MQ3KT/lhHF7pLiAACCV1g Message-ID: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1438058189; bh=lh+ECmUXHL78/7u2yaL1CFNDyHvH/bYxaX/ujK5Le00=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=aWCmghQ2UwLQAlkZIaizJ2D6wUa6iF3VqwPQoU5FdEO15rCoV/gtS4sj/Ge0aoQKa QOAERRQBqSy7LeF15mXs/Ce9ajg1uLS5jLIANWoTActmGLU+3SGzehXryiT56xfpxB OSAJjPRc/f0WkiaEeS681m3gXNwn8d7w2MJH/v4/eU4LiW/uyBMiieDzWIxqu8TfKo U1zqHENrJLEr3MCwDbG23E3CF5FRY2IUSum2DXSwCqPFNpjnzGEyQZY/2pVGEI4i8h WSa8bChBF0bTPbvHqgd7YVs92cC7uGgN0w3/VlO7EJFc0fKAfXuVBBJJUrc1hK8LKx dL0Zij6jJalew== Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 04:36:35 -0000 V2hhdCBtb3RpdmF0aW9uIHdvdWxkIGEgY2FycmllciBoYXZlIHRvIGNob29zZSBhbnkgbW9kZWwg b3RoZXIgdGhhbiBjYXJyaWVyIHNpZ25pbmcgdXNpbmcgb25lIG9mIGEgdmVyeSBsaW1pdGVkIHNl dCBvZiBjYXJyaWVyLW93bmVkIGtleXM/ICBMYXJnZSBzY2FsZSBjZXJ0aWZpY2F0ZSBtYW5hZ2Vt ZW50IGlzIGV4cGVuc2l2ZSwgYW5kIFROLXNwZWNpZmljIGNlcnRpZmljYXRlcyBhcmUgdW5uZWVk ZWQgZm9yIHNlY3VyaW5nIGNhbGxzIHBsYWNlZCBieSBwYXJ0aWVzIHdobyBjaG9vc2UgdG8gcGxh Y2UgY2FsbHMgdGhyb3VnaCBhIHNpbmdsZSByZXB1dGFibGUgdGVsZXBob25lIHNlcnZpY2UgcHJv dmlkZXIuICBBbnlvbmUgY2FuIGdldCBtYW55IGNlcnRpZmljYXRlcywgZXZlbiBhIGZyZWUgb25l cyBhbm9ueW1vdXNseSBmcm9tIHNvbWUgaXNzdWVycy4gIEl0IGlzIHR5cGljYWxseSBhIGNvbWJp bmF0aW9uIG9mIHRoZSBzdHJlbmd0aCBvZiB0aGUgZW5kLXVzZXIgYXV0aGVudGljYXRpb24gcGVy Zm9ybWVkIGJ5IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIChvciBjZXJ0aWZpY2F0ZSBpc3N1ZXIgaW4g YSBwcm92aWRlci1hZ25vc3RpYyBtb2RlbCkgYW5kIHRoZSBpZGVudGl0eSdzIGhpc3RvcnkgdGhh dCBhcmUgbW9zdCB1c2VmdWwgaW4gc2VjdXJpdHkuICANCg0KSWYgd2UncmUgdHJ5aW5nIHRvIHNl Y3VyZSB0aGUgY3VycmVudCB0ZWxlcGhvbmUgc3lzdGVtLCBETlMtbGlrZSBrZXkgcmVwb3NpdG9y aWVzIGEgbGEgREtJTSBvciBwZXJoYXBzIGEgc21hbGwgbnVtYmVyIChjb21wYXJlZCB0byB0aGUg bnVtYmVyIG9mIFROcykgb2YgY2VydGlmaWNhdGVzIGFyZSBmYXIgbW9yZSBwcmFjdGljYWwuICAN Cg0KUmVnYXJkcywNCg0KQWxleA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IHN0aXIgW21haWx0bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlh biBSb3Nlbg0KPiBTZW50OiBNb25kYXksIEp1bHkgMjcsIDIwMTUgNzo0MCBQTQ0KPiBUbzogUmlj aGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+DQo+IENjOiBzdGlyQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBhbmQgUHJpdmFjeQ0KPiANCj4gV2hhdCB0aGlzIG1l YW5zIGluIHByYWN0aWNlIGlzIHRoYXQgaXTigJlzIFROIHBlciBjZXJ0Lg0KPiANCj4gSSB3b3Vs ZG7igJl0IHNheSB0aGF0IGl04oCZcyBpbXBvc3NpYmxlIGZvciBhIGNhcnJpZXIgdG8gbWFpbnRh aW4gZG96ZW5zIG9mIGNvcGllcyBvZg0KPiBtaWxsaW9ucyBvZiBwcml2YXRlIGtleXMgc2VjdXJl bHksIGJ1dCBpdOKAmXMgaGFyZC4gIFlvdSBuZWVkIG11bHRpcGxlIGNvcGllcw0KPiBiZWNhdXNl IHlvdSBoYXZlIG11bHRpcGxlIGVsZW1lbnRzIHRoYXQgY2FuIGluaXRpYXRlIGEgY2FsbCwgYW5k IHlvdSBkb27igJl0DQo+IHdhbnQgdG8gZGVwZW5kIG9uIGEgY2VudHJhbGl6ZWQgcmVzb3VyY2Ug dG8gZG8gc29tZXRoaW5nIGFzIGJhc2ljIGFzIGNyZWF0ZQ0KPiBhIGNhbGwuDQo+IA0KPiBJIHRo aW5rIGl04oCZcyBoYXJkIGVub3VnaCB0aGF0IFJFUVVJUklORyBjZXJ0IHBlciBUTiBpcyBub3Qg YWNjZXB0YWJsZS4NCj4gDQo+IEZvbGtzIHdpdGggbW9yZSBpbnRpbWF0ZSBrbm93bGVkZ2Ugb2Yg Y2FycmllciBTSVAgaW5mcmFzdHJ1Y3R1cmUgbWlnaHQgaGF2ZQ0KPiBtb3JlIGluc2lnaHQgdGhh biBJIGRvLiAgSXQgbWF5IGJlIGFjY2VwdGFibGUgdG8gaGF2ZSBhIGNlbnRyYWxpemVkIHJlc291 cmNlDQo+IHRvIG1hbmFnZSBtaWxsaW9ucyBvZiBrZXlzLg0KPiANCj4gQnJpYW4NCj4gDQo+ID4g T24gSnVsIDI3LCAyMDE1LCBhdCA2OjEzIFBNLCBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeD4g d3JvdGU6DQo+ID4NCj4gPiBBZnRlciB0aGUgU1RJUiBtZWV0aW5nIGluIFByYWd1ZSwgSGVubmlu ZyBhbmQgSSBzcGVudCBhIGZldyBtaW51dGVzDQo+ID4gdGFsa2luZyB0aHJvdWdoIG9wdGlvbnMg Zm9yIHJldm9jYXRpb24gY2hlY2tpbmcgYW5kIGNlcnRpZmljYXRlDQo+ID4gc2NvcGluZywgYW5k IEkgdGhpbmsgd2UgaGF2ZSBhIGJldHRlciBpZGVhIG9mIHdoYXQgdGhlIG9wdGltYWwNCj4gPiBz b2x1dGlvbiBsb29rcyBsaWtlLiAgU29tZSBub3RlcyBhcmUgYmVsb3csIGFuZCBzb21lIHNsaWRl cyB3aXRoDQo+ID4gcGljdHVyZXMgYXR0YWNoZWQuDQo+ID4NCj4gPiB0bDtkcjogV2Ugc2hvdWxk Og0KPiA+ICogS2VlcCBUTnMgaW4gY2VydGlmaWNhdGVzIGFuZCBub3QgYm90aGVyIHdpdGggYW55 IE9DU1AgZXh0ZW5zaW9ucw0KPiA+ICogUmVxdWlyZSBJZGVudGl0eS1JbmZvIHRvIGluY2x1ZGUg T0NTUCByZXNwb25zZXMgZm9yIGFsbCBjZXJ0cyBpbiB0aGUNCj4gPiBjaGFpbg0KPiA+DQo+ID4N Cj4gPiAjIEJhY2tncm91bmQ6IFJldm9jYXRpb24gaW4gdGhlIHdlYiBQS0kNCj4gPg0KPiA+IElu IGFuIEhUVFBTIHRyYW5zYWN0aW9uLCB0aGUgSFRUUFMgc2VydmVyIHByb3ZpZGVzIHRoZSBjbGll bnQgd2l0aCBhDQo+ID4gY2VydGlmaWNhdGUsIGFuZCBpdCBjYW4gb3B0aW9uYWxseSBpbmNsdWRl IGFuIE9DU1AgcmVzcG9uc2UgKCJzdGFwbGUiDQo+ID4gaXQgdG8gdGhlIHRyYW5zYWN0aW9uKS4N Cj4gPg0KPiA+IEEgY2VydGlmaWNhdGUgY29udGFpbnMgYSB2YWxpZGl0eSBpbnRlcnZhbCwgYSBr ZXksIGFuZCBzb21lIG5hbWVzL1ROcy4NCj4gPiBBbiBPQ1NQIHJlc3BvbnNlcyBjb250YWlucyBh IHZhbGlkaXR5IGludGVydmFsLCBhIGNlcnRpZmljYXRlIElEDQo+ID4gKGkuZS4sIGEgaGFzaCks IGFuZCBhIHN0YXR1cyAoZ29vZC9yZXZva2VkL3Vua25vd24pLiAgSW4gdGhlIHdlYiBQS0ksDQo+ ID4gY2VydGlmaWNhdGVzIGFyZSByZXF1aXJlZCB0byBiZSBubyBtb3JlIHRoYW4gMzkgbW9udGhz IGxvbmcsIGFuZCBPQ1NQDQo+ID4gcmVzcG9uc2VzIG5vIG1vcmUgdGhhbiAxMCBkYXlzLg0KPiA+ DQo+ID4gSWRlYWxseSwgYSBjbGllbnQgb25seSBjb25zaWRlcnMgYSBjZXJ0aWZpY2F0ZSB2YWxp ZCBpZiBpdCBpcw0KPiA+IGFjY29tcGFuaWVkIGJ5IGFuIE9DU1AgcmVzcG9uc2UuICBJbiBwcmFj dGljZSwgdGhpcyBpcyBub3QgYWx3YXlzDQo+ID4gcG9zc2libGU7IGJlY2F1c2UgT0NTUCBxdWVy aWVzIGZhaWwgYXJvdW5kIDMlIG9mIHRoZSB0aW1lLCBicm93c2Vycw0KPiA+IGNhbid0IHJlcXVp cmUgT0NTUC4gIFRoaXMgb3BlcmF0aW9uYWwgZmFjdCB3aWxsIGJlIGltcG9ydGFudCBiZWxvdywN Cj4gPiBidXQgd2Ugd2lsbCBjb250aW51ZSB0byBoYXZlIHNjb3BpbmcgY2VydCBsaWZldGltZXMg YXMgYW4gb2JqZWN0aXZlLg0KPiA+DQo+ID4gSW4gdGhlIHdlYiBQS0ksIHRoZXJlIGFyZSBiYXNp Y2FsbHkgdGhyZWUgcmV2b2NhdGlvbiBjaGVja2luZyBtb2RhbGl0aWVzOg0KPiA+DQo+ID4gMS4g TGl2ZSBPQ1NQIGNoZWNraW5nIFtSRkM2MDY5XQ0KPiA+IDIuIE9DU1Agc3RhcGxpbmcgLyBtdXN0 X3N0YXBsZSBbUkZDNjA2NiwgZHJhZnQtaGFsbGFtYmFrZXItdGxzZmVhdHVyZV0NCj4gPiAzLiBT aG9ydC1saXZlZCBjZXJ0aWZpY2F0ZXMgKH5PQ1NQIGxpZmV0aW1lKQ0KPiA+DQo+ID4gKFRoZSBs YXN0IG9mIHRoZXNlIGlzIHJlbGF0aXZlbHkgbm92ZWwsIGFuZCBoYXMgbm90IGJlZW4gZGVwbG95 ZWQuDQo+ID4gTmVpdGhlciBoYXMgbXVzdC1zdGFwbGUuICBCdXQgdGhleSdyZSBib3RoIHByZXR0 eSB0cml2aWFsLCBhbmQgY291bGQNCj4gPiBiZSBmb2xkZWQgaW50byBhIFNUSVIgYXJjaGl0ZWN0 dXJlIHByZXR0eSBlYXNpbHkuKQ0KPiA+DQo+ID4gUmlnaHQgbm93LCBhYm91dCA5MCUgb2YgVExT IHRyYW5zYWN0aW9ucyB1c2UgbGl2ZSBPQ1NQLCBhbmQgYWJvdXQgMTAlLg0KPiA+IENBcyBhbmQg YnJvd3NlcnMgZGVhcmx5IHdhbnQgdGhlIHdvcmxkIHRvIG1vdmUgdG93YXJkIHN0YXBsZWQgT0NT UCBvcg0KPiA+IHNob3J0LWxpdmVkIGNlcnRzLCBiZWNhdXNlIHRoZXNlIHJlZHVjZXMgbGF0ZW5j eSBhbmQgaW1wcm92ZSB0aGUNCj4gPiBxdWFsaXR5IG9mIHJldm9jYXRpb24gaW5mb3JtYXRpb24u DQo+ID4NCj4gPiBSZXZvY2F0aW9uIGZvciBDQSBjZXJ0aWZpY2F0ZXMgaXMgY3VycmVudGx5IGRv bmUgYnkgaGF2aW5nIGJyb3dzZXJzDQo+ID4gZG93bmxvYWQgYSBsaXN0IGZyb20gYSBjZW50cmFs aXplZCBzZXJ2ZXIsIHNpbmNlIHRoZXJlJ3Mgbm8gd2F5IHRvDQo+ID4gc3RhcGxlIG1vcmUgdGhh biBvbmUgT0NTUCByZXNwb25zZS4gIFRoYXQgc29sdXRpb24gd29ya3MgT0sgZm9yIHRoZQ0KPiA+ IHdlYiwgYnV0IGlmIEkgd2VyZSBkZXNpZ25pbmcgc29tZXRoaW5nIGRlIG5vdm8sIEkgd291bGQg cHJvYmFibHkgdXNlDQo+ID4gbXVsdGktc3RhcGxpbmcgYXMgd2VsbC4NCj4gPg0KPiA+DQo+ID4g IyBBcHBseWluZyB0aGlzIGV4cGVyaWVuY2UgdG8gU1RJUg0KPiA+DQo+ID4gTW9zdCBvZiB0aGUg YmVsb3cgYXBwZWFyIHRvIGJlIGRlc2lyZWQgcHJvcGVydGllcyBieSB0aGUgV0c6DQo+ID4NCj4g PiAqIFZlcmlmaWVyIG5lZWVkcyB0byBrbm93IHRoYXQgYSBjZXJ0IGlzIHZhbGlkIGZvciBhIHNw ZWNpZmljIG51bWJlcg0KPiA+ICogU2NvcGVkIGNlcnQgbGlmZXRpbWU6IExpbWl0IGNlcnRzIHRv IH4xd2VlayBsaWZldGltZSAoYnkgT0NTUCBpZg0KPiA+IGlzc3VlZCBsb25nZXIpDQo+ID4gKiBD YWxsZXIgcHJpdmFjeTogRG9uJ3QgcmVwb3J0IHdoYXQgY2FsbHMgc29tZW9uZSByZWNlaXZlcyB0 byBhDQo+ID4gY2VudHJhbCBzZXJ2ZXINCj4gPiAqIENhcnJpZXIgcHJpdmFjeTogRG9uJ3QgYWxs b3cgYSB0aGlyZCBwYXJ0eSB0byBmaWd1cmUgb3V0IGFsbCB0aGUNCj4gPiBudW1iZXJzIGEgY2Fy cmllciBob2xkcw0KPiA+ICogTWluaW1pemUgdGhlIHJhdGUgYXQgd2hpY2ggdGhlIENBIGhhcyB0 byBzaWduIHRoaW5ncw0KPiA+ICogVG9sZXJhdGUgb3V0YWdlcyBhdCB0aGUgQ0ENCj4gPg0KPiA+ IEknbSBnb2luZyB0byBhc3N1bWUgZm9yIG5vdyB0aGF0IHdlIHdpbGwgbm90IGRvIGxpdmUgT0NT UC4gIEl0DQo+ID4gdmlvbGF0ZXMgdGhlIGNhbGxlciBwcml2YWN5IHJlcXVpcmVtZW50LCBhbmQg YXMgZGlzY3Vzc2VkIGFib3ZlLCBpdA0KPiA+IGp1c3Qgc3Vja3Mgb3BlcmF0aW9uYWxseS4gIFNv IFNUSVIgc2hvdWxkIHJlcXVpcmUgT0NTUCB0byBiZSBzZW50IGluDQo+ID4gInN0YXBsZWQiIGZv cm0sIHdoaWNoIHByb2JhYmx5IG1lYW5zIHNlbmRpbmcgaXQgaW4gSWRlbnRpdHktSW5mby4gIEFu ZA0KPiA+IHdoaWxlIHdlJ3JlIGF0IGl0LCB3ZSBzaG91bGQgYWxzbyBkbyAibXVsdGktc3RhcGxp bmciIC0tIHNlbmQgYW4gT0NTUA0KPiA+IHJlc3BvbnNlIGZvciBDQSBjZXJ0cyBhcyB3ZWxsLg0K PiA+DQo+ID4gU28gaWYgd2UgY29uc2lkZXIgYSBzZXJ2ZXIgd2l0aCA1MGsgVE5zIC8gYmxvY2tz LCB0aGF0IGxlYXZlcyB1cyB3aXRoDQo+ID4gYmFzaWNhbGx5IDMgb3B0aW9uczoNCj4gPg0KPiA+ IDEuIDUwayBzaG9ydC1saXZlZCBjZXJ0cyAobm8gT0NTUCkNCj4gPiAyLiA1MGsgbG9uZy1saXZl ZCBjZXJ0cyBzY29wZWQgdG8gVE5zICsgZ2VuZXJpYyBPQ1NQIDMuIDEgbG9uZy1saXZlZA0KPiA+ IGNlcnQgbm90IHNjb3BlZCB0byBUTiAob3IgYSBmZXcgbG9vc2VseSBzY29wZWQpICsgT0NTUCB3 aXRoIFROIGluZm8NCj4gPg0KPiA+IChBcyBJIGRpZG4ndCBxdWl0ZSBnZXQgdG8gc2F5IGluIHRo ZSBtZWV0aW5nLCByZWdhcmRsZXNzIG9mIHRoZQ0KPiA+IGFwcHJvYWNoLCB5b3UgaGF2ZSB0byBo YXZlIDUwayBvZiAqc29tZXRoaW5nKi4pICBPZiB0aGVzZSwgaXQgc2VlbXMNCj4gPiBsaWtlIHRo ZSBwcmVmZXJlbmNlIG9yZGVyIGlzIDIgPiAxID4gMy4NCj4gPg0KPiA+IE9wdGlvbiAzIGlzIGJh ZCBmcm9tIHNldmVyYWwgcGVyc3BlY3RpdmVzOg0KPiA+ICogUHV0dGluZyBUTiBpbmZvIGluIHRo ZSBPQ1NQIHJlc3BvbnNlIGVuYWJsZXMgc29tZW9uZSB0byB0cmF3bCBmb3INCj4gPiBudW1iZXJz IHVubGVzcyB5b3UgYWNjZXNzLWNvbnRyb2wgdGhlIE9DU1Agc2VydmVyLCBzbyB5b3UgaW5oZXJp dCBhDQo+ID4gcmVxdWlyZW1lbnQgdG8gZG8gdGhhdC4NCj4gPiAqIFdpdGggdGhlIHJhdGUgb2Yg Y2h1cm4gaW4gbnVtYmVyIGFzc2lnbm1lbnRzLCB5b3UncmUgcHJvYmFibHkgZ29pbmcNCj4gPiB0 byBoYXZlIHRvIHVwZGF0ZSB0aGUgbG9uZy1saXZlZCBjZXJ0IHByZXR0eSBmcmVxdWVudGx5IGFu eXdheS4NCj4gPiAqIFB1dHRpbmcgVE4tc3BlY2lmaWMgc3R1ZmYgaW4gY2VydHMgaXMgYmV0dGVy IHRoYW4gcHV0dGluZyBpdCBpbg0KPiA+IE9DU1AuICBBcyBiYWQgYXMgWC41MDkgbGlicmFyaWVz IGNhbiBiZSwgT0NTUCBsaWJyYXJpZXMgYXJlIG11Y2gNCj4gPiB3b3JzZS4NCj4gPg0KPiA+IE9w dGlvbiAxIGlzIG1haW5seSBiYWQgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgQ0EgbG9hZCBhbmQg b3V0YWdlcy4NCj4gPiBXaXRoIE9wdGlvbiAyLCBpZiB0aGUgQ0EgZ29lcyBkb3duLCBjbGllbnQg Y2FuIGNvbnRpbnVlIHRvIHVzZSB0aGUNCj4gPiBsb25nLWxpdmVkIGNlcnQgYW5kIGp1c3Qgbm90 IGJvdGhlciBkb2luZyBPQ1NQICh2cy4gdG9sZXJhdGluZyBhbg0KPiA+IGV4cGlyZWQgY2VydCku ICBTbGlnaHRseSBjbGVhbmVyLiAgUGx1cywgdGhlcmUncyBhIGxvdCBtb3JlIGV4cGVyaWVuY2UN Cj4gPiBjYWNoaW5nIE9DU1AgdGhhbiBuZXcgY2VydHMuICBPQ1NQIHNpZ25pbmcgY2FuIGFsc28g YmUgZGVsZWdhdGVkLCBzbw0KPiA+IHlvdSBjYW4gaGF2ZSB0aGUgcmVjdXJyaW5nIG9wZXJhdGlv biBkb25lIGJ5IGEgbG93ZXItcmlzayBrZXkuDQo+ID4NCj4gPiBPcHRpb24gMiBzaG91bGQgYmUg cHJldHR5IGVhc3kgdG8gYXV0b21hdGUuICBZb3UgY2FuIHByb2JhYmx5IHJlLXVzZQ0KPiA+IHRv b2xpbmcgZm9yIE9DU1Agc3RhcGxpbmcgdGhhdCBoYXMgYWxyZWFkeSBiZWVuIGRldmVsb3BlZCBm b3IgdXNlIHdpdGgNCj4gPiBIVFRQUy4gIElmIHlvdSdyZSBhIGJpZyBib3ggc2lnbmluZyBmb3Ig YSBidW5jaCBvZiBudW1iZXJzLCB5b3UgZG8NCj4gPiBuZWVkIHRvIHNlbGVjdCB0aGUgcmlnaHQg Y2VydCBhbmQgT0NTUCByZXNwb25zZSBmb3IgYSBnaXZlbiBjYWxsLCBidXQNCj4gPiB0aGF0J3Mg YSBwcmV0dHkgc2ltcGxlIGxvb2t1cCB0YWJsZS4NCj4gPiA8U1RJUi5wcHR4Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc3RpciBtYWlsaW5nIGxp c3QNCj4gPiBzdGlyQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zdGlyDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBzdGlyIG1haWxpbmcgbGlzdA0KPiBzdGlyQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0K From nobody Tue Jul 28 04:25:54 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682F61A8848 for ; Tue, 28 Jul 2015 04:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_H_CANADIAN=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 evr-aV6htw0x for ; Tue, 28 Jul 2015 04:25:50 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.107]) (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 A16E61A8957 for ; Tue, 28 Jul 2015 04:25:46 -0700 (PDT) Received: from [194.106.220.51] by server-3.bemta-14.messagelabs.com id EF/A9-18676-9B667B55; Tue, 28 Jul 2015 11:25:45 +0000 X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-9.tower-92.messagelabs.com!1438082743!29540678!1 X-Originating-IP: [206.172.1.98] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30168 invoked from network); 28 Jul 2015 11:25:44 -0000 Received: from unknown (HELO Tls.exchange.bell.ca) (206.172.1.98) by server-9.tower-92.messagelabs.com with AES256-SHA encrypted SMTP; 28 Jul 2015 11:25:44 -0000 X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE01-DOR.bell.corp.bce.ca Received: from DG1MBX04-DOR.bell.corp.bce.ca (198.235.121.232) by EX13EDGE01-DOR.bell.corp.bce.ca (198.235.121.54) with Microsoft SMTP Server id 15.0.1076.9; Tue, 28 Jul 2015 07:22:45 -0400 Received: from DG1MBX01-DOR.bell.corp.bce.ca (2002:8e75:d10e::8e75:d10e) by DG1MBX04-DOR.bell.corp.bce.ca (2002:8e75:d111::8e75:d111) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 28 Jul 2015 07:25:42 -0400 Received: from DG1MBX01-DOR.bell.corp.bce.ca ([fe80::203b:bd4d:1db7:f155]) by DG1MBX01-DOR.bell.corp.bce.ca ([fe80::7164:652e:4dc6:420d%19]) with mapi id 15.00.0995.031; Tue, 28 Jul 2015 06:25:42 -0500 From: "Caron, Guy (A162859)" To: "stir@ietf.org" Thread-Topic: CRTC: Empowering Canadians to protect themselves from unsolicited and illegitimate telemarketing calls Thread-Index: AQHQySgitbMOS48CV0es2tF+4UoW/w== Date: Tue, 28 Jul 2015 11:25:41 +0000 Message-ID: <646ec42bbc654a33acd3015c0634b997@DG1MBX01-DOR.bell.corp.bce.ca> References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.92.8] Content-Type: multipart/alternative; boundary="_000_646ec42bbc654a33acd3015c0634b997DG1MBX01DORbellcorpbcec_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: SoftFail (EX13EDGE01-DOR.bell.corp.bce.ca: domain of transitioning g.caron@bell.ca discourages use of 198.235.121.232 as permitted sender) X-OrganizationHeadersPreserved: EX13EDGE01-DOR.bell.corp.bce.ca Archived-At: Subject: [stir] CRTC: Empowering Canadians to protect themselves from unsolicited and illegitimate telemarketing calls X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 11:25:52 -0000 --_000_646ec42bbc654a33acd3015c0634b997DG1MBX01DORbellcorpbcec_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnlpLi4uDQoNCg0KDQpUaGUgQ1JUQyAoQ2FuYWRpYW4gcmVndWxhdG9yKSBpcyBnYXRoZXJpbmcg aW5mb3JtYXRpb24gZnJvbSBDYW5hZGlhbnMgYW5kIHRoZSB0ZWxlY29tbXVuaWNhdGlvbnMgaW5k dXN0cnkgdG8gZW5oYW5jZSB0aGUgcHJvdGVjdGlvbnMgZm9yIENhbmFkaWFucyBmcm9tIHVuc29s aWNpdGVkIGFuZCBpbGxlZ2l0aW1hdGUgdGVsZW1hcmtldGluZyBjYWxscyBkZWxpdmVyZWQgb24g YWxsIHRlbGVwaG9ueSBwbGF0Zm9ybXMgYnkgdGVsZWNvbW11bmljYXRpb25zIHNlcnZpY2UgcHJv dmlkZXJzLg0KDQpodHRwOi8vd3d3LmNydGMuZ2MuY2EvZW5nL2FyY2hpdmUvMjAxNS8yMDE1LTMz My5odG0NCg0KDQoNCkd1eQ0KDQoNCg== --_000_646ec42bbc654a33acd3015c0634b997DG1MBX01DORbellcorpbcec_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29Q bGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGJydXQgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQt ZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uVGV4dGVicnV0Q2FyDQoJe21zby1zdHlsZS1uYW1lOiJU ZXh0ZSBicnV0IENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJUZXh0ZSBicnV0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1DQSI+ RnlpLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj5UaGUgQ1JUQyAoQ2FuYWRpYW4gcmVndWxh dG9yKSBpcyBnYXRoZXJpbmcgaW5mb3JtYXRpb24gZnJvbSBDYW5hZGlhbnMgYW5kIHRoZSB0ZWxl Y29tbXVuaWNhdGlvbnMgaW5kdXN0cnkgdG8gZW5oYW5jZSB0aGUgcHJvdGVjdGlvbnMgZm9yIENh bmFkaWFucyBmcm9tIHVuc29saWNpdGVkIGFuZCBpbGxlZ2l0aW1hdGUgdGVsZW1hcmtldGluZyBj YWxscyBkZWxpdmVyZWQgb24NCiBhbGwgdGVsZXBob255IHBsYXRmb3JtcyBieSB0ZWxlY29tbXVu aWNhdGlvbnMgc2VydmljZSBwcm92aWRlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48YSBocmVmPSJo dHRwOi8vd3d3LmNydGMuZ2MuY2EvZW5nL2FyY2hpdmUvMjAxNS8yMDE1LTMzMy5odG0iPmh0dHA6 Ly93d3cuY3J0Yy5nYy5jYS9lbmcvYXJjaGl2ZS8yMDE1LzIwMTUtMzMzLmh0bTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1D QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tQ0EiPkd1eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_646ec42bbc654a33acd3015c0634b997DG1MBX01DORbellcorpbcec_-- From nobody Tue Jul 28 04:54:16 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AA21A89AE for ; Tue, 28 Jul 2015 04:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 rBs0wcl2PQ-T for ; Tue, 28 Jul 2015 04:54:11 -0700 (PDT) Received: from mail-vn0-f47.google.com (mail-vn0-f47.google.com [209.85.216.47]) (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 AAB291A89B8 for ; Tue, 28 Jul 2015 04:54:11 -0700 (PDT) Received: by vnk197 with SMTP id 197so41781535vnk.3 for ; Tue, 28 Jul 2015 04:54:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GLEzl80XaToq6aRklQ2+ISRp+ALkvk3ar3NY1WEDNgI=; b=SqevwbsJmfCcPmX2D9RhnZW7N/dVktuiE9ctKeDZuRDIT8TIABqp0e8lsfB63iBmdu zxbMN6yMOEDFQtPD2JWj3xc+muQQAU+6/H5kqgYYc2W+yLoTkEsDWJfrCdgFkzi0Jyhf kdr2WBDSj426YN6uuZEJvQ0U7bKhVAc2ONS3jAN4MB4tDaUQO8wwokb0ujrmZOhPy1WS KaLJ2wNg07F3viNHdoavC/uQEXqOmKU0IILPMpGFH1uOUkOzbp0Q1Js8+2o9ulaW3tT8 ShqTi5iGGIrQq0+GkE0sKvAZ3iWHBbMmhWKcVoDLsepYhGsmHPxkvZX0ZW8ND4zWqn8H fQPw== X-Gm-Message-State: ALoCoQnVPEzdyCPr4/wwB1x11nzw6MG3B4i/x+Y9IUNsCpuHGLsXE8ydpCpUW+hUf2TGVyqpt90w MIME-Version: 1.0 X-Received: by 10.52.69.241 with SMTP id h17mr43377720vdu.68.1438084450912; Tue, 28 Jul 2015 04:54:10 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Tue, 28 Jul 2015 04:54:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Jul 2015 07:54:10 -0400 Message-ID: From: Richard Barnes To: Brian Rosen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 11:54:14 -0000 On Mon, Jul 27, 2015 at 10:39 PM, Brian Rosen wrote: > What this means in practice is that it=E2=80=99s TN per cert. That's not quite true. It requires that the TNs be listed explicitly in the cert, which doesn't mean one TN, but probably also means not millions. > I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier to main= tain dozens of copies of millions of private keys securely, but it=E2=80=99= s hard. You need multiple copies because you have multiple elements that c= an initiate a call, and you don=E2=80=99t want to depend on a centralized r= esource to do something as basic as create a call. > > I think it=E2=80=99s hard enough that REQUIRING cert per TN is not accept= able. > > Folks with more intimate knowledge of carrier SIP infrastructure might ha= ve more insight than I do. It may be acceptable to have a centralized reso= urce to manage millions of keys. Whoa now, having N certs does not mean having N keys. You can have as many certificates as you want with the same public key. A certificate is just the granularity of the authorization granted to that key. So if the carrier and the CA are willing, the carrier can have N certificates with all the same public key. That would mean that the carrier couldn't do any load balancing, and would have to revoke all its certificates if that key pair is compromised, but that's a trade-off that can be negotiated between consenting adults. --Richard > > Brian > >> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >> >> After the STIR meeting in Prague, Henning and I spent a few minutes >> talking through options for revocation checking and certificate >> scoping, and I think we have a better idea of what the optimal >> solution looks like. Some notes are below, and some slides with >> pictures attached. >> >> tl;dr: We should: >> * Keep TNs in certificates and not bother with any OCSP extensions >> * Require Identity-Info to include OCSP responses for all certs in the c= hain >> >> >> # Background: Revocation in the web PKI >> >> In an HTTPS transaction, the HTTPS server provides the client with a >> certificate, and it can optionally include an OCSP response ("staple" >> it to the transaction). >> >> A certificate contains a validity interval, a key, and some names/TNs. >> An OCSP responses contains a validity interval, a certificate ID >> (i.e., a hash), and a status (good/revoked/unknown). In the web PKI, >> certificates are required to be no more than 39 months long, and OCSP >> responses no more than 10 days. >> >> Ideally, a client only considers a certificate valid if it is >> accompanied by an OCSP response. In practice, this is not always >> possible; because OCSP queries fail around 3% of the time, browsers >> can't require OCSP. This operational fact will be important below, >> but we will continue to have scoping cert lifetimes as an objective. >> >> In the web PKI, there are basically three revocation checking modalities= : >> >> 1. Live OCSP checking [RFC6069] >> 2. OCSP stapling / must_staple [RFC6066, draft-hallambaker-tlsfeature] >> 3. Short-lived certificates (~OCSP lifetime) >> >> (The last of these is relatively novel, and has not been deployed. >> Neither has must-staple. But they're both pretty trivial, and could >> be folded into a STIR architecture pretty easily.) >> >> Right now, about 90% of TLS transactions use live OCSP, and about 10%. >> CAs and browsers dearly want the world to move toward stapled OCSP or >> short-lived certs, because these reduces latency and improve the >> quality of revocation information. >> >> Revocation for CA certificates is currently done by having browsers >> download a list from a centralized server, since there's no way to >> staple more than one OCSP response. That solution works OK for the >> web, but if I were designing something de novo, I would probably use >> multi-stapling as well. >> >> >> # Applying this experience to STIR >> >> Most of the below appear to be desired properties by the WG: >> >> * Verifier neeeds to know that a cert is valid for a specific number >> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >> issued longer) >> * Caller privacy: Don't report what calls someone receives to a central = server >> * Carrier privacy: Don't allow a third party to figure out all the >> numbers a carrier holds >> * Minimize the rate at which the CA has to sign things >> * Tolerate outages at the CA >> >> I'm going to assume for now that we will not do live OCSP. It >> violates the caller privacy requirement, and as discussed above, it >> just sucks operationally. So STIR should require OCSP to be sent in >> "stapled" form, which probably means sending it in Identity-Info. And >> while we're at it, we should also do "multi-stapling" -- send an OCSP >> response for CA certs as well. >> >> So if we consider a server with 50k TNs / blocks, that leaves us with >> basically 3 options: >> >> 1. 50k short-lived certs (no OCSP) >> 2. 50k long-lived certs scoped to TNs + generic OCSP >> 3. 1 long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >> with TN info >> >> (As I didn't quite get to say in the meeting, regardless of the >> approach, you have to have 50k of *something*.) Of these, it seems >> like the preference order is 2 > 1 > 3. >> >> Option 3 is bad from several perspectives: >> * Putting TN info in the OCSP response enables someone to trawl for >> numbers unless you access-control the OCSP server, so you inherit a >> requirement to do that. >> * With the rate of churn in number assignments, you're probably going >> to have to update the long-lived cert pretty frequently anyway. >> * Putting TN-specific stuff in certs is better than putting it in >> OCSP. As bad as X.509 libraries can be, OCSP libraries are much >> worse. >> >> Option 1 is mainly bad from the perspective of CA load and outages. >> With Option 2, if the CA goes down, client can continue to use the >> long-lived cert and just not bother doing OCSP (vs. tolerating an >> expired cert). Slightly cleaner. Plus, there's a lot more experience >> caching OCSP than new certs. OCSP signing can also be delegated, so >> you can have the recurring operation done by a lower-risk key. >> >> Option 2 should be pretty easy to automate. You can probably re-use >> tooling for OCSP stapling that has already been developed for use with >> HTTPS. If you're a big box signing for a bunch of numbers, you do >> need to select the right cert and OCSP response for a given call, but >> that's a pretty simple lookup table. >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > From nobody Tue Jul 28 05:10:08 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27D41A8A05 for ; Tue, 28 Jul 2015 05:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 y0C0QLSUgDTn for ; Tue, 28 Jul 2015 05:10:04 -0700 (PDT) Received: from mail-vn0-f45.google.com (mail-vn0-f45.google.com [209.85.216.45]) (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 D0D9E1A89FC for ; Tue, 28 Jul 2015 05:10:03 -0700 (PDT) Received: by vnds125 with SMTP id s125so41916052vnd.1 for ; Tue, 28 Jul 2015 05:10:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=09O84anPJNGbNNnrWCGOR99rrkC4BLLE0JmpbnF+KEg=; b=Ms51EjO3naROPNCJ7AZo1diydhVGYdustsHkomTdjuAxtmlqy6prma2gIaEf1LvudS 8CHVcnXLOxruw4aYZ86R5g6B3MVXIufal1oXnoTkmysZf0tD6U8Adm+b48v4qLCoHxWs 5LERQhnsmClynplcGlvjKeR7l2nfFY2oJ4EIMPlpFGnqSM/t/5gPd6Uj/FxJYpCODKn6 5Dx3hBPct/CYXnoibVyXe57DE0Df2yXp7FjsIECoF+IL5+eoxxMQESzKZ3argqigwKsj s4CxcnzaBwatVACoQR85AFZDLlQwO8UKJ5WWPPVsqIhYNZHHLtq80OCX91gkjsBtsO7u k0Fw== X-Gm-Message-State: ALoCoQnb+VRVWTCCONInkspua1mk0GZwrqaWxWVr99WD3gRq9z+6iXunFwSLM7pnN8Em6HEJn5/i MIME-Version: 1.0 X-Received: by 10.52.69.241 with SMTP id h17mr43471159vdu.68.1438085403075; Tue, 28 Jul 2015 05:10:03 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Tue, 28 Jul 2015 05:10:03 -0700 (PDT) In-Reply-To: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> Date: Tue, 28 Jul 2015 08:10:03 -0400 Message-ID: From: Richard Barnes To: Alex Bobotek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 12:10:06 -0000 On Tue, Jul 28, 2015 at 12:36 AM, Alex Bobotek wrote: > What motivation would a carrier have to choose any model other than carri= er signing using one of a very limited set of carrier-owned keys? Large sc= ale certificate management is expensive As I noted to Brian, key management !=3D cert management. If you've got 5 signing boxes (each with it's own key pair) and 100k TNs, you can allocate those TNs among the signing boxes however you like -- including issuing each signing box a set of certs that cover all 100k numbers. Key management is hard. Cert management is only as hard as you need it to be. The benefits of "one big cert" are also illusory. If you're going to have N changes per week in your set of 100k TNs, then you're going to have to replace your one big cert N times per week as well if you don't want to lose fidelity. >, and TN-specific certificates are unneeded for securing calls placed by p= arties who choose to place calls through a single reputable telephone servi= ce provider. Anyone can get many certificates, even a free ones anonymousl= y from some issuers. It is typically a combination of the strength of the = end-user authentication performed by the service provider (or certificate i= ssuer in a provider-agnostic model) and the identity's history that are mos= t useful in security. > > If we're trying to secure the current telephone system, DNS-like key repo= sitories a la DKIM or perhaps a small number (compared to the number of TNs= ) of certificates are far more practical. Honestly, this seems like a pretty hand-wavy argument. Modern web hosting providers manage many thousands of certificates, and manage to have their front end systems pick the right ones. CloudFlare, for example, has 2 million free-tier subscribers for whom they manage certificates. They bundle subscribers 20/certificate, so that's 100k certificates they're managing. Given that they're providing that level of cert managment for their *free* tier, I have a hard time buying the argument that managing certificates is insanely expensive. --Richard > > Regards, > > Alex > >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >> Sent: Monday, July 27, 2015 7:40 PM >> To: Richard Barnes >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> What this means in practice is that it=E2=80=99s TN per cert. >> >> I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier to mai= ntain dozens of copies of >> millions of private keys securely, but it=E2=80=99s hard. You need mult= iple copies >> because you have multiple elements that can initiate a call, and you don= =E2=80=99t >> want to depend on a centralized resource to do something as basic as cre= ate >> a call. >> >> I think it=E2=80=99s hard enough that REQUIRING cert per TN is not accep= table. >> >> Folks with more intimate knowledge of carrier SIP infrastructure might h= ave >> more insight than I do. It may be acceptable to have a centralized reso= urce >> to manage millions of keys. >> >> Brian >> >> > On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >> > >> > After the STIR meeting in Prague, Henning and I spent a few minutes >> > talking through options for revocation checking and certificate >> > scoping, and I think we have a better idea of what the optimal >> > solution looks like. Some notes are below, and some slides with >> > pictures attached. >> > >> > tl;dr: We should: >> > * Keep TNs in certificates and not bother with any OCSP extensions >> > * Require Identity-Info to include OCSP responses for all certs in the >> > chain >> > >> > >> > # Background: Revocation in the web PKI >> > >> > In an HTTPS transaction, the HTTPS server provides the client with a >> > certificate, and it can optionally include an OCSP response ("staple" >> > it to the transaction). >> > >> > A certificate contains a validity interval, a key, and some names/TNs. >> > An OCSP responses contains a validity interval, a certificate ID >> > (i.e., a hash), and a status (good/revoked/unknown). In the web PKI, >> > certificates are required to be no more than 39 months long, and OCSP >> > responses no more than 10 days. >> > >> > Ideally, a client only considers a certificate valid if it is >> > accompanied by an OCSP response. In practice, this is not always >> > possible; because OCSP queries fail around 3% of the time, browsers >> > can't require OCSP. This operational fact will be important below, >> > but we will continue to have scoping cert lifetimes as an objective. >> > >> > In the web PKI, there are basically three revocation checking modaliti= es: >> > >> > 1. Live OCSP checking [RFC6069] >> > 2. OCSP stapling / must_staple [RFC6066, draft-hallambaker-tlsfeature] >> > 3. Short-lived certificates (~OCSP lifetime) >> > >> > (The last of these is relatively novel, and has not been deployed. >> > Neither has must-staple. But they're both pretty trivial, and could >> > be folded into a STIR architecture pretty easily.) >> > >> > Right now, about 90% of TLS transactions use live OCSP, and about 10%. >> > CAs and browsers dearly want the world to move toward stapled OCSP or >> > short-lived certs, because these reduces latency and improve the >> > quality of revocation information. >> > >> > Revocation for CA certificates is currently done by having browsers >> > download a list from a centralized server, since there's no way to >> > staple more than one OCSP response. That solution works OK for the >> > web, but if I were designing something de novo, I would probably use >> > multi-stapling as well. >> > >> > >> > # Applying this experience to STIR >> > >> > Most of the below appear to be desired properties by the WG: >> > >> > * Verifier neeeds to know that a cert is valid for a specific number >> > * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >> > issued longer) >> > * Caller privacy: Don't report what calls someone receives to a >> > central server >> > * Carrier privacy: Don't allow a third party to figure out all the >> > numbers a carrier holds >> > * Minimize the rate at which the CA has to sign things >> > * Tolerate outages at the CA >> > >> > I'm going to assume for now that we will not do live OCSP. It >> > violates the caller privacy requirement, and as discussed above, it >> > just sucks operationally. So STIR should require OCSP to be sent in >> > "stapled" form, which probably means sending it in Identity-Info. And >> > while we're at it, we should also do "multi-stapling" -- send an OCSP >> > response for CA certs as well. >> > >> > So if we consider a server with 50k TNs / blocks, that leaves us with >> > basically 3 options: >> > >> > 1. 50k short-lived certs (no OCSP) >> > 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 long-lived >> > cert not scoped to TN (or a few loosely scoped) + OCSP with TN info >> > >> > (As I didn't quite get to say in the meeting, regardless of the >> > approach, you have to have 50k of *something*.) Of these, it seems >> > like the preference order is 2 > 1 > 3. >> > >> > Option 3 is bad from several perspectives: >> > * Putting TN info in the OCSP response enables someone to trawl for >> > numbers unless you access-control the OCSP server, so you inherit a >> > requirement to do that. >> > * With the rate of churn in number assignments, you're probably going >> > to have to update the long-lived cert pretty frequently anyway. >> > * Putting TN-specific stuff in certs is better than putting it in >> > OCSP. As bad as X.509 libraries can be, OCSP libraries are much >> > worse. >> > >> > Option 1 is mainly bad from the perspective of CA load and outages. >> > With Option 2, if the CA goes down, client can continue to use the >> > long-lived cert and just not bother doing OCSP (vs. tolerating an >> > expired cert). Slightly cleaner. Plus, there's a lot more experience >> > caching OCSP than new certs. OCSP signing can also be delegated, so >> > you can have the recurring operation done by a lower-risk key. >> > >> > Option 2 should be pretty easy to automate. You can probably re-use >> > tooling for OCSP stapling that has already been developed for use with >> > HTTPS. If you're a big box signing for a bunch of numbers, you do >> > need to select the right cert and OCSP response for a given call, but >> > that's a pretty simple lookup table. >> > _______________________________________________ >> > 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 From nobody Tue Jul 28 05:40:05 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0711A8A4A for ; Tue, 28 Jul 2015 05:40:04 -0700 (PDT) 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_HELO_PASS=-0.001] autolearn=ham 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 RFUDCuGPDDxQ for ; Tue, 28 Jul 2015 05:40:01 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) (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 492431A8A91 for ; Tue, 28 Jul 2015 05:40:00 -0700 (PDT) Received: from [85.158.136.3] by server-13.bemta-5.messagelabs.com id 03/D8-02324-E1877B55; Tue, 28 Jul 2015 12:39:58 +0000 X-Env-Sender: Patrick.Tarpey@ofcom.org.uk X-Msg-Ref: server-11.tower-123.messagelabs.com!1438087197!47902460!1 X-Originating-IP: [194.33.160.63] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20109 invoked from network); 28 Jul 2015 12:39:58 -0000 Received: from unknown (HELO mail1.ofcom.org.uk) (194.33.160.63) by server-11.tower-123.messagelabs.com with AES128-SHA encrypted SMTP; 28 Jul 2015 12:39:58 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by mail1.ofcom.org.uk (10.130.239.19) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 28 Jul 2015 13:39:45 +0100 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%13]) with mapi id 14.03.0224.002; Tue, 28 Jul 2015 13:39:53 +0100 From: Patrick Tarpey To: Richard Barnes , Brian Rosen Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLmFn1Mx4IGn6U+VaQFbigcXcZ3wGyoAgACa2QCAABunsA== Date: Tue, 28 Jul 2015 12:39:52 +0000 Message-ID: <2FD4C4C86AF9F24AB55FEEA59BCD435E012EDAA05B@WOK-INTRA-EXC02.intra.ofcom.local> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 12:40:04 -0000 SGksDQoNCkhvdyB3b3VsZCBudW1iZXIgcG9ydGluZyB3b3JrIGluIHRoaXMgcmVzcGVjdD8gV291 bGQgdGhlIGNhcnJpZXIgaG9sZCBhIGNlcnRpZmljYXRlIGNvdmVyaW5nIGEgcGFydGljdWxhciBu dW1iZXIgaGF2ZSB0byBhdXRvbWF0aWNhbGx5IHJlaXNzdWUgdGhlIGNlcnQ/DQoNClBhdA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQgQmFybmVzDQpTZW50OiAyOCBKdWx5IDIw MTUgMTI6NTQNClRvOiBCcmlhbiBSb3Nlbg0KQ2M6IHN0aXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBhbmQgUHJpdmFjeQ0KDQpPbiBNb24sIEp1bCAyNywgMjAx NSBhdCAxMDozOSBQTSwgQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PiB3cm90ZToNCj4g V2hhdCB0aGlzIG1lYW5zIGluIHByYWN0aWNlIGlzIHRoYXQgaXTigJlzIFROIHBlciBjZXJ0Lg0K DQpUaGF0J3Mgbm90IHF1aXRlIHRydWUuICBJdCByZXF1aXJlcyB0aGF0IHRoZSBUTnMgYmUgbGlz dGVkIGV4cGxpY2l0bHkgaW4gdGhlIGNlcnQsIHdoaWNoIGRvZXNuJ3QgbWVhbiBvbmUgVE4sIGJ1 dCBwcm9iYWJseSBhbHNvIG1lYW5zIG5vdCBtaWxsaW9ucy4NCg0KDQo+IEkgd291bGRu4oCZdCBz YXkgdGhhdCBpdOKAmXMgaW1wb3NzaWJsZSBmb3IgYSBjYXJyaWVyIHRvIG1haW50YWluIGRvemVu cyBvZiBjb3BpZXMgb2YgbWlsbGlvbnMgb2YgcHJpdmF0ZSBrZXlzIHNlY3VyZWx5LCBidXQgaXTi gJlzIGhhcmQuICBZb3UgbmVlZCBtdWx0aXBsZSBjb3BpZXMgYmVjYXVzZSB5b3UgaGF2ZSBtdWx0 aXBsZSBlbGVtZW50cyB0aGF0IGNhbiBpbml0aWF0ZSBhIGNhbGwsIGFuZCB5b3UgZG9u4oCZdCB3 YW50IHRvIGRlcGVuZCBvbiBhIGNlbnRyYWxpemVkIHJlc291cmNlIHRvIGRvIHNvbWV0aGluZyBh cyBiYXNpYyBhcyBjcmVhdGUgYSBjYWxsLg0KPg0KPiBJIHRoaW5rIGl04oCZcyBoYXJkIGVub3Vn aCB0aGF0IFJFUVVJUklORyBjZXJ0IHBlciBUTiBpcyBub3QgYWNjZXB0YWJsZS4NCj4NCj4gRm9s a3Mgd2l0aCBtb3JlIGludGltYXRlIGtub3dsZWRnZSBvZiBjYXJyaWVyIFNJUCBpbmZyYXN0cnVj dHVyZSBtaWdodCBoYXZlIG1vcmUgaW5zaWdodCB0aGFuIEkgZG8uICBJdCBtYXkgYmUgYWNjZXB0 YWJsZSB0byBoYXZlIGEgY2VudHJhbGl6ZWQgcmVzb3VyY2UgdG8gbWFuYWdlIG1pbGxpb25zIG9m IGtleXMuDQoNCldob2Egbm93LCBoYXZpbmcgTiBjZXJ0cyBkb2VzIG5vdCBtZWFuIGhhdmluZyBO IGtleXMuICBZb3UgY2FuIGhhdmUgYXMgbWFueSBjZXJ0aWZpY2F0ZXMgYXMgeW91IHdhbnQgd2l0 aCB0aGUgc2FtZSBwdWJsaWMga2V5LiAgQSBjZXJ0aWZpY2F0ZSBpcyBqdXN0IHRoZSBncmFudWxh cml0eSBvZiB0aGUgYXV0aG9yaXphdGlvbiBncmFudGVkIHRvIHRoYXQga2V5Lg0KDQpTbyBpZiB0 aGUgY2FycmllciBhbmQgdGhlIENBIGFyZSB3aWxsaW5nLCB0aGUgY2FycmllciBjYW4gaGF2ZSBO IGNlcnRpZmljYXRlcyB3aXRoIGFsbCB0aGUgc2FtZSBwdWJsaWMga2V5LiAgVGhhdCB3b3VsZCBt ZWFuIHRoYXQgdGhlIGNhcnJpZXIgY291bGRuJ3QgZG8gYW55IGxvYWQgYmFsYW5jaW5nLCBhbmQg d291bGQgaGF2ZSB0byByZXZva2UgYWxsIGl0cyBjZXJ0aWZpY2F0ZXMgaWYgdGhhdCBrZXkgcGFp ciBpcyBjb21wcm9taXNlZCwgYnV0IHRoYXQncyBhIHRyYWRlLW9mZiB0aGF0IGNhbiBiZSBuZWdv dGlhdGVkIGJldHdlZW4gY29uc2VudGluZyBhZHVsdHMuDQoNCi0tUmljaGFyZA0KDQoNCj4NCj4g QnJpYW4NCj4NCj4+IE9uIEp1bCAyNywgMjAxNSwgYXQgNjoxMyBQTSwgUmljaGFyZCBCYXJuZXMg PHJsYkBpcHYuc3g+IHdyb3RlOg0KPj4NCj4+IEFmdGVyIHRoZSBTVElSIG1lZXRpbmcgaW4gUHJh Z3VlLCBIZW5uaW5nIGFuZCBJIHNwZW50IGEgZmV3IG1pbnV0ZXMNCj4+IHRhbGtpbmcgdGhyb3Vn aCBvcHRpb25zIGZvciByZXZvY2F0aW9uIGNoZWNraW5nIGFuZCBjZXJ0aWZpY2F0ZQ0KPj4gc2Nv cGluZywgYW5kIEkgdGhpbmsgd2UgaGF2ZSBhIGJldHRlciBpZGVhIG9mIHdoYXQgdGhlIG9wdGlt YWwNCj4+IHNvbHV0aW9uIGxvb2tzIGxpa2UuICBTb21lIG5vdGVzIGFyZSBiZWxvdywgYW5kIHNv bWUgc2xpZGVzIHdpdGgNCj4+IHBpY3R1cmVzIGF0dGFjaGVkLg0KPj4NCj4+IHRsO2RyOiBXZSBz aG91bGQ6DQo+PiAqIEtlZXAgVE5zIGluIGNlcnRpZmljYXRlcyBhbmQgbm90IGJvdGhlciB3aXRo IGFueSBPQ1NQIGV4dGVuc2lvbnMNCj4+ICogUmVxdWlyZSBJZGVudGl0eS1JbmZvIHRvIGluY2x1 ZGUgT0NTUCByZXNwb25zZXMgZm9yIGFsbCBjZXJ0cyBpbg0KPj4gdGhlIGNoYWluDQo+Pg0KPj4N Cj4+ICMgQmFja2dyb3VuZDogUmV2b2NhdGlvbiBpbiB0aGUgd2ViIFBLSQ0KPj4NCj4+IEluIGFu IEhUVFBTIHRyYW5zYWN0aW9uLCB0aGUgSFRUUFMgc2VydmVyIHByb3ZpZGVzIHRoZSBjbGllbnQg d2l0aCBhDQo+PiBjZXJ0aWZpY2F0ZSwgYW5kIGl0IGNhbiBvcHRpb25hbGx5IGluY2x1ZGUgYW4g T0NTUCByZXNwb25zZSAoInN0YXBsZSINCj4+IGl0IHRvIHRoZSB0cmFuc2FjdGlvbikuDQo+Pg0K Pj4gQSBjZXJ0aWZpY2F0ZSBjb250YWlucyBhIHZhbGlkaXR5IGludGVydmFsLCBhIGtleSwgYW5k IHNvbWUgbmFtZXMvVE5zLg0KPj4gQW4gT0NTUCByZXNwb25zZXMgY29udGFpbnMgYSB2YWxpZGl0 eSBpbnRlcnZhbCwgYSBjZXJ0aWZpY2F0ZSBJRA0KPj4gKGkuZS4sIGEgaGFzaCksIGFuZCBhIHN0 YXR1cyAoZ29vZC9yZXZva2VkL3Vua25vd24pLiAgSW4gdGhlIHdlYiBQS0ksDQo+PiBjZXJ0aWZp Y2F0ZXMgYXJlIHJlcXVpcmVkIHRvIGJlIG5vIG1vcmUgdGhhbiAzOSBtb250aHMgbG9uZywgYW5k IE9DU1ANCj4+IHJlc3BvbnNlcyBubyBtb3JlIHRoYW4gMTAgZGF5cy4NCj4+DQo+PiBJZGVhbGx5 LCBhIGNsaWVudCBvbmx5IGNvbnNpZGVycyBhIGNlcnRpZmljYXRlIHZhbGlkIGlmIGl0IGlzDQo+ PiBhY2NvbXBhbmllZCBieSBhbiBPQ1NQIHJlc3BvbnNlLiAgSW4gcHJhY3RpY2UsIHRoaXMgaXMg bm90IGFsd2F5cw0KPj4gcG9zc2libGU7IGJlY2F1c2UgT0NTUCBxdWVyaWVzIGZhaWwgYXJvdW5k IDMlIG9mIHRoZSB0aW1lLCBicm93c2Vycw0KPj4gY2FuJ3QgcmVxdWlyZSBPQ1NQLiAgVGhpcyBv cGVyYXRpb25hbCBmYWN0IHdpbGwgYmUgaW1wb3J0YW50IGJlbG93LA0KPj4gYnV0IHdlIHdpbGwg Y29udGludWUgdG8gaGF2ZSBzY29waW5nIGNlcnQgbGlmZXRpbWVzIGFzIGFuIG9iamVjdGl2ZS4N Cj4+DQo+PiBJbiB0aGUgd2ViIFBLSSwgdGhlcmUgYXJlIGJhc2ljYWxseSB0aHJlZSByZXZvY2F0 aW9uIGNoZWNraW5nIG1vZGFsaXRpZXM6DQo+Pg0KPj4gMS4gTGl2ZSBPQ1NQIGNoZWNraW5nIFtS RkM2MDY5XQ0KPj4gMi4gT0NTUCBzdGFwbGluZyAvIG11c3Rfc3RhcGxlIFtSRkM2MDY2LA0KPj4g ZHJhZnQtaGFsbGFtYmFrZXItdGxzZmVhdHVyZV0gMy4gU2hvcnQtbGl2ZWQgY2VydGlmaWNhdGVz ICh+T0NTUA0KPj4gbGlmZXRpbWUpDQo+Pg0KPj4gKFRoZSBsYXN0IG9mIHRoZXNlIGlzIHJlbGF0 aXZlbHkgbm92ZWwsIGFuZCBoYXMgbm90IGJlZW4gZGVwbG95ZWQuDQo+PiBOZWl0aGVyIGhhcyBt dXN0LXN0YXBsZS4gIEJ1dCB0aGV5J3JlIGJvdGggcHJldHR5IHRyaXZpYWwsIGFuZCBjb3VsZA0K Pj4gYmUgZm9sZGVkIGludG8gYSBTVElSIGFyY2hpdGVjdHVyZSBwcmV0dHkgZWFzaWx5LikNCj4+ DQo+PiBSaWdodCBub3csIGFib3V0IDkwJSBvZiBUTFMgdHJhbnNhY3Rpb25zIHVzZSBsaXZlIE9D U1AsIGFuZCBhYm91dCAxMCUuDQo+PiBDQXMgYW5kIGJyb3dzZXJzIGRlYXJseSB3YW50IHRoZSB3 b3JsZCB0byBtb3ZlIHRvd2FyZCBzdGFwbGVkIE9DU1Agb3INCj4+IHNob3J0LWxpdmVkIGNlcnRz LCBiZWNhdXNlIHRoZXNlIHJlZHVjZXMgbGF0ZW5jeSBhbmQgaW1wcm92ZSB0aGUNCj4+IHF1YWxp dHkgb2YgcmV2b2NhdGlvbiBpbmZvcm1hdGlvbi4NCj4+DQo+PiBSZXZvY2F0aW9uIGZvciBDQSBj ZXJ0aWZpY2F0ZXMgaXMgY3VycmVudGx5IGRvbmUgYnkgaGF2aW5nIGJyb3dzZXJzDQo+PiBkb3du bG9hZCBhIGxpc3QgZnJvbSBhIGNlbnRyYWxpemVkIHNlcnZlciwgc2luY2UgdGhlcmUncyBubyB3 YXkgdG8NCj4+IHN0YXBsZSBtb3JlIHRoYW4gb25lIE9DU1AgcmVzcG9uc2UuICBUaGF0IHNvbHV0 aW9uIHdvcmtzIE9LIGZvciB0aGUNCj4+IHdlYiwgYnV0IGlmIEkgd2VyZSBkZXNpZ25pbmcgc29t ZXRoaW5nIGRlIG5vdm8sIEkgd291bGQgcHJvYmFibHkgdXNlDQo+PiBtdWx0aS1zdGFwbGluZyBh cyB3ZWxsLg0KPj4NCj4+DQo+PiAjIEFwcGx5aW5nIHRoaXMgZXhwZXJpZW5jZSB0byBTVElSDQo+ Pg0KPj4gTW9zdCBvZiB0aGUgYmVsb3cgYXBwZWFyIHRvIGJlIGRlc2lyZWQgcHJvcGVydGllcyBi eSB0aGUgV0c6DQo+Pg0KPj4gKiBWZXJpZmllciBuZWVlZHMgdG8ga25vdyB0aGF0IGEgY2VydCBp cyB2YWxpZCBmb3IgYSBzcGVjaWZpYyBudW1iZXINCj4+ICogU2NvcGVkIGNlcnQgbGlmZXRpbWU6 IExpbWl0IGNlcnRzIHRvIH4xd2VlayBsaWZldGltZSAoYnkgT0NTUCBpZg0KPj4gaXNzdWVkIGxv bmdlcikNCj4+ICogQ2FsbGVyIHByaXZhY3k6IERvbid0IHJlcG9ydCB3aGF0IGNhbGxzIHNvbWVv bmUgcmVjZWl2ZXMgdG8gYQ0KPj4gY2VudHJhbCBzZXJ2ZXINCj4+ICogQ2FycmllciBwcml2YWN5 OiBEb24ndCBhbGxvdyBhIHRoaXJkIHBhcnR5IHRvIGZpZ3VyZSBvdXQgYWxsIHRoZQ0KPj4gbnVt YmVycyBhIGNhcnJpZXIgaG9sZHMNCj4+ICogTWluaW1pemUgdGhlIHJhdGUgYXQgd2hpY2ggdGhl IENBIGhhcyB0byBzaWduIHRoaW5ncw0KPj4gKiBUb2xlcmF0ZSBvdXRhZ2VzIGF0IHRoZSBDQQ0K Pj4NCj4+IEknbSBnb2luZyB0byBhc3N1bWUgZm9yIG5vdyB0aGF0IHdlIHdpbGwgbm90IGRvIGxp dmUgT0NTUC4gIEl0DQo+PiB2aW9sYXRlcyB0aGUgY2FsbGVyIHByaXZhY3kgcmVxdWlyZW1lbnQs IGFuZCBhcyBkaXNjdXNzZWQgYWJvdmUsIGl0DQo+PiBqdXN0IHN1Y2tzIG9wZXJhdGlvbmFsbHku ICBTbyBTVElSIHNob3VsZCByZXF1aXJlIE9DU1AgdG8gYmUgc2VudCBpbg0KPj4gInN0YXBsZWQi IGZvcm0sIHdoaWNoIHByb2JhYmx5IG1lYW5zIHNlbmRpbmcgaXQgaW4gSWRlbnRpdHktSW5mby4N Cj4+IEFuZCB3aGlsZSB3ZSdyZSBhdCBpdCwgd2Ugc2hvdWxkIGFsc28gZG8gIm11bHRpLXN0YXBs aW5nIiAtLSBzZW5kIGFuDQo+PiBPQ1NQIHJlc3BvbnNlIGZvciBDQSBjZXJ0cyBhcyB3ZWxsLg0K Pj4NCj4+IFNvIGlmIHdlIGNvbnNpZGVyIGEgc2VydmVyIHdpdGggNTBrIFROcyAvIGJsb2Nrcywg dGhhdCBsZWF2ZXMgdXMgd2l0aA0KPj4gYmFzaWNhbGx5IDMgb3B0aW9uczoNCj4+DQo+PiAxLiA1 MGsgc2hvcnQtbGl2ZWQgY2VydHMgKG5vIE9DU1ApDQo+PiAyLiA1MGsgbG9uZy1saXZlZCBjZXJ0 cyBzY29wZWQgdG8gVE5zICsgZ2VuZXJpYyBPQ1NQIDMuIDEgbG9uZy1saXZlZA0KPj4gY2VydCBu b3Qgc2NvcGVkIHRvIFROIChvciBhIGZldyBsb29zZWx5IHNjb3BlZCkgKyBPQ1NQIHdpdGggVE4g aW5mbw0KPj4NCj4+IChBcyBJIGRpZG4ndCBxdWl0ZSBnZXQgdG8gc2F5IGluIHRoZSBtZWV0aW5n LCByZWdhcmRsZXNzIG9mIHRoZQ0KPj4gYXBwcm9hY2gsIHlvdSBoYXZlIHRvIGhhdmUgNTBrIG9m ICpzb21ldGhpbmcqLikgIE9mIHRoZXNlLCBpdCBzZWVtcw0KPj4gbGlrZSB0aGUgcHJlZmVyZW5j ZSBvcmRlciBpcyAyID4gMSA+IDMuDQo+Pg0KPj4gT3B0aW9uIDMgaXMgYmFkIGZyb20gc2V2ZXJh bCBwZXJzcGVjdGl2ZXM6DQo+PiAqIFB1dHRpbmcgVE4gaW5mbyBpbiB0aGUgT0NTUCByZXNwb25z ZSBlbmFibGVzIHNvbWVvbmUgdG8gdHJhd2wgZm9yDQo+PiBudW1iZXJzIHVubGVzcyB5b3UgYWNj ZXNzLWNvbnRyb2wgdGhlIE9DU1Agc2VydmVyLCBzbyB5b3UgaW5oZXJpdCBhDQo+PiByZXF1aXJl bWVudCB0byBkbyB0aGF0Lg0KPj4gKiBXaXRoIHRoZSByYXRlIG9mIGNodXJuIGluIG51bWJlciBh c3NpZ25tZW50cywgeW91J3JlIHByb2JhYmx5IGdvaW5nDQo+PiB0byBoYXZlIHRvIHVwZGF0ZSB0 aGUgbG9uZy1saXZlZCBjZXJ0IHByZXR0eSBmcmVxdWVudGx5IGFueXdheS4NCj4+ICogUHV0dGlu ZyBUTi1zcGVjaWZpYyBzdHVmZiBpbiBjZXJ0cyBpcyBiZXR0ZXIgdGhhbiBwdXR0aW5nIGl0IGlu DQo+PiBPQ1NQLiAgQXMgYmFkIGFzIFguNTA5IGxpYnJhcmllcyBjYW4gYmUsIE9DU1AgbGlicmFy aWVzIGFyZSBtdWNoDQo+PiB3b3JzZS4NCj4+DQo+PiBPcHRpb24gMSBpcyBtYWlubHkgYmFkIGZy b20gdGhlIHBlcnNwZWN0aXZlIG9mIENBIGxvYWQgYW5kIG91dGFnZXMuDQo+PiBXaXRoIE9wdGlv biAyLCBpZiB0aGUgQ0EgZ29lcyBkb3duLCBjbGllbnQgY2FuIGNvbnRpbnVlIHRvIHVzZSB0aGUN Cj4+IGxvbmctbGl2ZWQgY2VydCBhbmQganVzdCBub3QgYm90aGVyIGRvaW5nIE9DU1AgKHZzLiB0 b2xlcmF0aW5nIGFuDQo+PiBleHBpcmVkIGNlcnQpLiAgU2xpZ2h0bHkgY2xlYW5lci4gIFBsdXMs IHRoZXJlJ3MgYSBsb3QgbW9yZQ0KPj4gZXhwZXJpZW5jZSBjYWNoaW5nIE9DU1AgdGhhbiBuZXcg Y2VydHMuICBPQ1NQIHNpZ25pbmcgY2FuIGFsc28gYmUNCj4+IGRlbGVnYXRlZCwgc28geW91IGNh biBoYXZlIHRoZSByZWN1cnJpbmcgb3BlcmF0aW9uIGRvbmUgYnkgYSBsb3dlci1yaXNrIGtleS4N Cj4+DQo+PiBPcHRpb24gMiBzaG91bGQgYmUgcHJldHR5IGVhc3kgdG8gYXV0b21hdGUuICBZb3Ug Y2FuIHByb2JhYmx5IHJlLXVzZQ0KPj4gdG9vbGluZyBmb3IgT0NTUCBzdGFwbGluZyB0aGF0IGhh cyBhbHJlYWR5IGJlZW4gZGV2ZWxvcGVkIGZvciB1c2UNCj4+IHdpdGggSFRUUFMuICBJZiB5b3Un cmUgYSBiaWcgYm94IHNpZ25pbmcgZm9yIGEgYnVuY2ggb2YgbnVtYmVycywgeW91DQo+PiBkbyBu ZWVkIHRvIHNlbGVjdCB0aGUgcmlnaHQgY2VydCBhbmQgT0NTUCByZXNwb25zZSBmb3IgYSBnaXZl biBjYWxsLA0KPj4gYnV0IHRoYXQncyBhIHByZXR0eSBzaW1wbGUgbG9va3VwIHRhYmxlLg0KPj4g PFNUSVIucHB0eD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+IHN0aXJAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KPg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3RpciBtYWlsaW5nIGxpc3QNCnN0aXJAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCkZvciBtb3JlIGluZm9ybWF0aW9uIHZp c2l0IHd3dy5vZmNvbS5vcmcudWsNCg0KVGhpcyBlbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykg aXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIHVzZSBvZiB0aGUgYWRkcmVzc2Vl IG9ubHkuDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNl IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZSBhbmQgZGVsZXRlIGl0IGZyb20g eW91ciBzeXN0ZW0uDQoNClRoaXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcy4g SG93ZXZlciwgeW91IG9wZW4gYW55IGF0dGFjaG1lbnRzIGF0IHlvdXIgb3duIHJpc2suDQoNCkFu eSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZp ZHVhbCBzZW5kZXIgYW5kIGRvIG5vdCByZXByZXNlbnQgdGhlIHZpZXdzIG9yIG9waW5pb25zIG9m IE9mY29tIHVubGVzcyBleHByZXNzbHkgc3RhdGVkIG90aGVyd2lzZS4NCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K From nobody Tue Jul 28 06:03:36 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5361A8AB5 for ; Tue, 28 Jul 2015 06:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 SkcYKD98pYkT for ; Tue, 28 Jul 2015 06:03:32 -0700 (PDT) Received: from mail-vn0-f51.google.com (mail-vn0-f51.google.com [209.85.216.51]) (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 831CC1A8AB2 for ; Tue, 28 Jul 2015 06:03:32 -0700 (PDT) Received: by vnaa140 with SMTP id a140so42558159vna.2 for ; Tue, 28 Jul 2015 06:03:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xqq+ziB+YiIEYOP7Cqq3qJFSKIzlfYljbr8AVOE9Hss=; b=f21GGT17KJwDxgX66Dg0zpx5Q4w01VWFeC9uLjRwKX5Hc4J2/nhVAx/nJx5ibJGyxq GLDkVXaJ2h80A9rvFNiuWs1G2DQz9KeL4KY9WYxTs6BOKtre/t2kaUBnLrAjdgquNPje 6bO+eAQwXpdzBWdIR+XCAJ2wH2JkAUTiB2HrmXzgrcafRIhYRK7lzHCTj186srHChnbP v1WeJ5P4OCR+1LCsvlQ91bufRuI/fTxkYbfIcCGQs2wKEzCo7h51BsfZxTfVPTv9u/mp d+D+xpeSNumbB8j8z1kB+8zEK6veI+Vl3fJG3QxJRprDkI/oXdfEwLEABJaGyA7V1aDL LeqA== X-Gm-Message-State: ALoCoQl4cBG2CdM9awOmzlkav00FI9qQWS1dQeyATKl5fVK7ZWsPB48Hg7M6YU0mB8WzNdAoK/e/ MIME-Version: 1.0 X-Received: by 10.52.163.243 with SMTP id yl19mr42188780vdb.51.1438088611775; Tue, 28 Jul 2015 06:03:31 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Tue, 28 Jul 2015 06:03:31 -0700 (PDT) In-Reply-To: <2FD4C4C86AF9F24AB55FEEA59BCD435E012EDAA05B@WOK-INTRA-EXC02.intra.ofcom.local> References: <2FD4C4C86AF9F24AB55FEEA59BCD435E012EDAA05B@WOK-INTRA-EXC02.intra.ofcom.local> Date: Tue, 28 Jul 2015 09:03:31 -0400 Message-ID: From: Richard Barnes To: Patrick Tarpey Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 13:03:35 -0000 On Tue, Jul 28, 2015 at 8:39 AM, Patrick Tarpey wrote: > Hi, > > How would number porting work in this respect? Would the carrier hold a c= ertificate covering a particular number have to automatically reissue the c= ert? Porting would work pretty much the same in any of these schemes. The net effect would be that any certs that the original TN holder has for the ported TN would have to be revoked, and the recipient TN holder would be issued a new certificate containing the ported TN. The major difference between the below options is whether this is between creating and destroying small objects on the one hand, and updating large objects on the other hand: 1. Revoke a single- or few-TN certificate from the original holder; issue a single- or few-TN cert to the new holder 2. Revoke a many-TN cert from the original holder and re-issue with the ported TN in addition to the others; issue the new holder a new certificate with his old holdings plus the new TN. --Richard > > Pat > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Barnes > Sent: 28 July 2015 12:54 > To: Brian Rosen > Cc: stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy > > On Mon, Jul 27, 2015 at 10:39 PM, Brian Rosen wrote: >> What this means in practice is that it=E2=80=99s TN per cert. > > That's not quite true. It requires that the TNs be listed explicitly in = the cert, which doesn't mean one TN, but probably also means not millions. > > >> I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier to mai= ntain dozens of copies of millions of private keys securely, but it=E2=80= =99s hard. You need multiple copies because you have multiple elements tha= t can initiate a call, and you don=E2=80=99t want to depend on a centralize= d resource to do something as basic as create a call. >> >> I think it=E2=80=99s hard enough that REQUIRING cert per TN is not accep= table. >> >> Folks with more intimate knowledge of carrier SIP infrastructure might h= ave more insight than I do. It may be acceptable to have a centralized res= ource to manage millions of keys. > > Whoa now, having N certs does not mean having N keys. You can have as ma= ny certificates as you want with the same public key. A certificate is jus= t the granularity of the authorization granted to that key. > > So if the carrier and the CA are willing, the carrier can have N certific= ates with all the same public key. That would mean that the carrier couldn= 't do any load balancing, and would have to revoke all its certificates if = that key pair is compromised, but that's a trade-off that can be negotiated= between consenting adults. > > --Richard > > >> >> Brian >> >>> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>> >>> After the STIR meeting in Prague, Henning and I spent a few minutes >>> talking through options for revocation checking and certificate >>> scoping, and I think we have a better idea of what the optimal >>> solution looks like. Some notes are below, and some slides with >>> pictures attached. >>> >>> tl;dr: We should: >>> * Keep TNs in certificates and not bother with any OCSP extensions >>> * Require Identity-Info to include OCSP responses for all certs in >>> the chain >>> >>> >>> # Background: Revocation in the web PKI >>> >>> In an HTTPS transaction, the HTTPS server provides the client with a >>> certificate, and it can optionally include an OCSP response ("staple" >>> it to the transaction). >>> >>> A certificate contains a validity interval, a key, and some names/TNs. >>> An OCSP responses contains a validity interval, a certificate ID >>> (i.e., a hash), and a status (good/revoked/unknown). In the web PKI, >>> certificates are required to be no more than 39 months long, and OCSP >>> responses no more than 10 days. >>> >>> Ideally, a client only considers a certificate valid if it is >>> accompanied by an OCSP response. In practice, this is not always >>> possible; because OCSP queries fail around 3% of the time, browsers >>> can't require OCSP. This operational fact will be important below, >>> but we will continue to have scoping cert lifetimes as an objective. >>> >>> In the web PKI, there are basically three revocation checking modalitie= s: >>> >>> 1. Live OCSP checking [RFC6069] >>> 2. OCSP stapling / must_staple [RFC6066, >>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>> lifetime) >>> >>> (The last of these is relatively novel, and has not been deployed. >>> Neither has must-staple. But they're both pretty trivial, and could >>> be folded into a STIR architecture pretty easily.) >>> >>> Right now, about 90% of TLS transactions use live OCSP, and about 10%. >>> CAs and browsers dearly want the world to move toward stapled OCSP or >>> short-lived certs, because these reduces latency and improve the >>> quality of revocation information. >>> >>> Revocation for CA certificates is currently done by having browsers >>> download a list from a centralized server, since there's no way to >>> staple more than one OCSP response. That solution works OK for the >>> web, but if I were designing something de novo, I would probably use >>> multi-stapling as well. >>> >>> >>> # Applying this experience to STIR >>> >>> Most of the below appear to be desired properties by the WG: >>> >>> * Verifier neeeds to know that a cert is valid for a specific number >>> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >>> issued longer) >>> * Caller privacy: Don't report what calls someone receives to a >>> central server >>> * Carrier privacy: Don't allow a third party to figure out all the >>> numbers a carrier holds >>> * Minimize the rate at which the CA has to sign things >>> * Tolerate outages at the CA >>> >>> I'm going to assume for now that we will not do live OCSP. It >>> violates the caller privacy requirement, and as discussed above, it >>> just sucks operationally. So STIR should require OCSP to be sent in >>> "stapled" form, which probably means sending it in Identity-Info. >>> And while we're at it, we should also do "multi-stapling" -- send an >>> OCSP response for CA certs as well. >>> >>> So if we consider a server with 50k TNs / blocks, that leaves us with >>> basically 3 options: >>> >>> 1. 50k short-lived certs (no OCSP) >>> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 long-lived >>> cert not scoped to TN (or a few loosely scoped) + OCSP with TN info >>> >>> (As I didn't quite get to say in the meeting, regardless of the >>> approach, you have to have 50k of *something*.) Of these, it seems >>> like the preference order is 2 > 1 > 3. >>> >>> Option 3 is bad from several perspectives: >>> * Putting TN info in the OCSP response enables someone to trawl for >>> numbers unless you access-control the OCSP server, so you inherit a >>> requirement to do that. >>> * With the rate of churn in number assignments, you're probably going >>> to have to update the long-lived cert pretty frequently anyway. >>> * Putting TN-specific stuff in certs is better than putting it in >>> OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>> worse. >>> >>> Option 1 is mainly bad from the perspective of CA load and outages. >>> With Option 2, if the CA goes down, client can continue to use the >>> long-lived cert and just not bother doing OCSP (vs. tolerating an >>> expired cert). Slightly cleaner. Plus, there's a lot more >>> experience caching OCSP than new certs. OCSP signing can also be >>> delegated, so you can have the recurring operation done by a lower-risk= key. >>> >>> Option 2 should be pretty easy to automate. You can probably re-use >>> tooling for OCSP stapling that has already been developed for use >>> with HTTPS. If you're a big box signing for a bunch of numbers, you >>> do need to select the right cert and OCSP response for a given call, >>> but that's a pretty simple lookup table. >>> _______________________________________________ >>> 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 > > ________________________________ > > *************************************************************************= ***************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the use= of the addressee only. > > If you have received this email in error please notify the originator of = the message and delete it from your system. > > This email has been scanned for viruses. However, you open any attachment= s at your own risk. > > Any views expressed in this message are those of the individual sender an= d do not represent the views or opinions of Ofcom unless expressly stated o= therwise. > *************************************************************************= ***************************************** From nobody Tue Jul 28 06:51:41 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD39F1A90CA for ; Tue, 28 Jul 2015 06:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 97J8VEvQDS45 for ; Tue, 28 Jul 2015 06:51:34 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 840BE1A9084 for ; Tue, 28 Jul 2015 06:51:09 -0700 (PDT) From: Henning Schulzrinne To: Richard Barnes , Brian Rosen Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgACa2QCAAB+wYA== Date: Tue, 28 Jul 2015 13:51:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ipv.sx; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 5:BOiOegrtay1TwXalisZBpTuPw7iDcQR5R7XJSLbEd+1+jRCrK+Qk53PAuYI8Zbyt5Meall9WH1nFGknY4Cr4FvWHrCs/OtWLbGgjDfhwv+vx2YIB62Ne9zosXpcE9O/Y3OKc1vAJembcm2Gc1tB10Q==; 24:Eqg2QN5uqs2hOeBy3Z/iGNMBM+xnLIQy7P/kVmTdXf2jMb1Z1hQtvVL5HXfl8JeHHNICb/b1eZVt+ncL+hO/t1MgYUbGEsWAVHbo5/LAsYo=; 20:ptLFJrsbXomrLABZUbQMOKTviT0AI39O7cFxmpYdZpS5XhpPYUnq8xTEyxvW1aZ/ZBKGznjvmgPH3fJBUwBF4Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0633; cy1pr09mb0633: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(5003600100002)(102836002)(77096005)(5002640100001)(62966003)(189998001)(15975445007)(54356999)(40100003)(5001960100002)(76176999)(5001770100001)(5890100001)(92566002)(2900100001)(122556002)(19580395003)(77156002)(19580405001)(86362001)(50986999)(106116001)(99286002)(76576001)(74316001)(33656002)(2656002)(2950100001)(551934003)(87936001)(46102003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2015 13:51:07.5495 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 13:51:39 -0000 SnVzdCB0byBhbXBsaWZ5OiBBIENBIGRvZXNuJ3QgdXNlIGEgbmV3IHB1YmxpYy1wcml2YXRlIGtl eSBwYWlyIGZvciBlYWNoIGNlcnQuIEl0IHVzZXMgb25lIGZvciBhbGwgb2YgdGhlbSwgbWlsbGlv bnMuIE9uZSBtb2RlbCBtaWdodCBiZSBvbmUgUEsgcGFpciBmb3IgZWFjaCBtYWpvciBTQkMsIHdp dGggdGhlIGNvcnJlc3BvbmRpbmcgY2VydCBkYXRhYmFzZSBmb3IgcXVlcmllcywgYnV0IHRoYXQn cyBvYnZpb3VzbHkgYSBsb2NhbCBpbXBsZW1lbnRhdGlvbiBjaG9pY2UuDQoNCkhlbm5pbmcNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHN0aXIgW21haWx0bzpzdGlyLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSaWNoYXJkIEJhcm5lcw0KU2VudDogVHVlc2RheSwg SnVseSAyOCwgMjAxNSA3OjU0IEFNDQpUbzogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0 Pg0KQ2M6IHN0aXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBh bmQgUHJpdmFjeQ0KDQpPbiBNb24sIEp1bCAyNywgMjAxNSBhdCAxMDozOSBQTSwgQnJpYW4gUm9z ZW4gPGJyQGJyaWFucm9zZW4ubmV0PiB3cm90ZToNCj4gV2hhdCB0aGlzIG1lYW5zIGluIHByYWN0 aWNlIGlzIHRoYXQgaXTigJlzIFROIHBlciBjZXJ0Lg0KDQpUaGF0J3Mgbm90IHF1aXRlIHRydWUu ICBJdCByZXF1aXJlcyB0aGF0IHRoZSBUTnMgYmUgbGlzdGVkIGV4cGxpY2l0bHkgaW4gdGhlIGNl cnQsIHdoaWNoIGRvZXNuJ3QgbWVhbiBvbmUgVE4sIGJ1dCBwcm9iYWJseSBhbHNvIG1lYW5zIG5v dCBtaWxsaW9ucy4NCg0KDQo+IEkgd291bGRu4oCZdCBzYXkgdGhhdCBpdOKAmXMgaW1wb3NzaWJs ZSBmb3IgYSBjYXJyaWVyIHRvIG1haW50YWluIGRvemVucyBvZiBjb3BpZXMgb2YgbWlsbGlvbnMg b2YgcHJpdmF0ZSBrZXlzIHNlY3VyZWx5LCBidXQgaXTigJlzIGhhcmQuICBZb3UgbmVlZCBtdWx0 aXBsZSBjb3BpZXMgYmVjYXVzZSB5b3UgaGF2ZSBtdWx0aXBsZSBlbGVtZW50cyB0aGF0IGNhbiBp bml0aWF0ZSBhIGNhbGwsIGFuZCB5b3UgZG9u4oCZdCB3YW50IHRvIGRlcGVuZCBvbiBhIGNlbnRy YWxpemVkIHJlc291cmNlIHRvIGRvIHNvbWV0aGluZyBhcyBiYXNpYyBhcyBjcmVhdGUgYSBjYWxs Lg0KPg0KPiBJIHRoaW5rIGl04oCZcyBoYXJkIGVub3VnaCB0aGF0IFJFUVVJUklORyBjZXJ0IHBl ciBUTiBpcyBub3QgYWNjZXB0YWJsZS4NCj4NCj4gRm9sa3Mgd2l0aCBtb3JlIGludGltYXRlIGtu b3dsZWRnZSBvZiBjYXJyaWVyIFNJUCBpbmZyYXN0cnVjdHVyZSBtaWdodCBoYXZlIG1vcmUgaW5z aWdodCB0aGFuIEkgZG8uICBJdCBtYXkgYmUgYWNjZXB0YWJsZSB0byBoYXZlIGEgY2VudHJhbGl6 ZWQgcmVzb3VyY2UgdG8gbWFuYWdlIG1pbGxpb25zIG9mIGtleXMuDQoNCldob2Egbm93LCBoYXZp bmcgTiBjZXJ0cyBkb2VzIG5vdCBtZWFuIGhhdmluZyBOIGtleXMuICBZb3UgY2FuIGhhdmUgYXMg bWFueSBjZXJ0aWZpY2F0ZXMgYXMgeW91IHdhbnQgd2l0aCB0aGUgc2FtZSBwdWJsaWMga2V5LiAg QSBjZXJ0aWZpY2F0ZSBpcyBqdXN0IHRoZSBncmFudWxhcml0eSBvZiB0aGUgYXV0aG9yaXphdGlv biBncmFudGVkIHRvIHRoYXQga2V5Lg0KDQpTbyBpZiB0aGUgY2FycmllciBhbmQgdGhlIENBIGFy ZSB3aWxsaW5nLCB0aGUgY2FycmllciBjYW4gaGF2ZSBOIGNlcnRpZmljYXRlcyB3aXRoIGFsbCB0 aGUgc2FtZSBwdWJsaWMga2V5LiAgVGhhdCB3b3VsZCBtZWFuIHRoYXQgdGhlIGNhcnJpZXIgY291 bGRuJ3QgZG8gYW55IGxvYWQgYmFsYW5jaW5nLCBhbmQgd291bGQgaGF2ZSB0byByZXZva2UgYWxs IGl0cyBjZXJ0aWZpY2F0ZXMgaWYgdGhhdCBrZXkgcGFpciBpcyBjb21wcm9taXNlZCwgYnV0IHRo YXQncyBhIHRyYWRlLW9mZiB0aGF0IGNhbiBiZSBuZWdvdGlhdGVkIGJldHdlZW4gY29uc2VudGlu ZyBhZHVsdHMuDQoNCi0tUmljaGFyZA0KDQoNCj4NCj4gQnJpYW4NCj4NCj4+IE9uIEp1bCAyNywg MjAxNSwgYXQgNjoxMyBQTSwgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+IHdyb3RlOg0KPj4N Cj4+IEFmdGVyIHRoZSBTVElSIG1lZXRpbmcgaW4gUHJhZ3VlLCBIZW5uaW5nIGFuZCBJIHNwZW50 IGEgZmV3IG1pbnV0ZXMgDQo+PiB0YWxraW5nIHRocm91Z2ggb3B0aW9ucyBmb3IgcmV2b2NhdGlv biBjaGVja2luZyBhbmQgY2VydGlmaWNhdGUgDQo+PiBzY29waW5nLCBhbmQgSSB0aGluayB3ZSBo YXZlIGEgYmV0dGVyIGlkZWEgb2Ygd2hhdCB0aGUgb3B0aW1hbCANCj4+IHNvbHV0aW9uIGxvb2tz IGxpa2UuICBTb21lIG5vdGVzIGFyZSBiZWxvdywgYW5kIHNvbWUgc2xpZGVzIHdpdGggDQo+PiBw aWN0dXJlcyBhdHRhY2hlZC4NCj4+DQo+PiB0bDtkcjogV2Ugc2hvdWxkOg0KPj4gKiBLZWVwIFRO cyBpbiBjZXJ0aWZpY2F0ZXMgYW5kIG5vdCBib3RoZXIgd2l0aCBhbnkgT0NTUCBleHRlbnNpb25z DQo+PiAqIFJlcXVpcmUgSWRlbnRpdHktSW5mbyB0byBpbmNsdWRlIE9DU1AgcmVzcG9uc2VzIGZv ciBhbGwgY2VydHMgaW4gDQo+PiB0aGUgY2hhaW4NCj4+DQo+Pg0KPj4gIyBCYWNrZ3JvdW5kOiBS ZXZvY2F0aW9uIGluIHRoZSB3ZWIgUEtJDQo+Pg0KPj4gSW4gYW4gSFRUUFMgdHJhbnNhY3Rpb24s IHRoZSBIVFRQUyBzZXJ2ZXIgcHJvdmlkZXMgdGhlIGNsaWVudCB3aXRoIGEgDQo+PiBjZXJ0aWZp Y2F0ZSwgYW5kIGl0IGNhbiBvcHRpb25hbGx5IGluY2x1ZGUgYW4gT0NTUCByZXNwb25zZSAoInN0 YXBsZSINCj4+IGl0IHRvIHRoZSB0cmFuc2FjdGlvbikuDQo+Pg0KPj4gQSBjZXJ0aWZpY2F0ZSBj b250YWlucyBhIHZhbGlkaXR5IGludGVydmFsLCBhIGtleSwgYW5kIHNvbWUgbmFtZXMvVE5zLg0K Pj4gQW4gT0NTUCByZXNwb25zZXMgY29udGFpbnMgYSB2YWxpZGl0eSBpbnRlcnZhbCwgYSBjZXJ0 aWZpY2F0ZSBJRCANCj4+IChpLmUuLCBhIGhhc2gpLCBhbmQgYSBzdGF0dXMgKGdvb2QvcmV2b2tl ZC91bmtub3duKS4gIEluIHRoZSB3ZWIgUEtJLCANCj4+IGNlcnRpZmljYXRlcyBhcmUgcmVxdWly ZWQgdG8gYmUgbm8gbW9yZSB0aGFuIDM5IG1vbnRocyBsb25nLCBhbmQgT0NTUCANCj4+IHJlc3Bv bnNlcyBubyBtb3JlIHRoYW4gMTAgZGF5cy4NCj4+DQo+PiBJZGVhbGx5LCBhIGNsaWVudCBvbmx5 IGNvbnNpZGVycyBhIGNlcnRpZmljYXRlIHZhbGlkIGlmIGl0IGlzIA0KPj4gYWNjb21wYW5pZWQg YnkgYW4gT0NTUCByZXNwb25zZS4gIEluIHByYWN0aWNlLCB0aGlzIGlzIG5vdCBhbHdheXMgDQo+ PiBwb3NzaWJsZTsgYmVjYXVzZSBPQ1NQIHF1ZXJpZXMgZmFpbCBhcm91bmQgMyUgb2YgdGhlIHRp bWUsIGJyb3dzZXJzIA0KPj4gY2FuJ3QgcmVxdWlyZSBPQ1NQLiAgVGhpcyBvcGVyYXRpb25hbCBm YWN0IHdpbGwgYmUgaW1wb3J0YW50IGJlbG93LCANCj4+IGJ1dCB3ZSB3aWxsIGNvbnRpbnVlIHRv IGhhdmUgc2NvcGluZyBjZXJ0IGxpZmV0aW1lcyBhcyBhbiBvYmplY3RpdmUuDQo+Pg0KPj4gSW4g dGhlIHdlYiBQS0ksIHRoZXJlIGFyZSBiYXNpY2FsbHkgdGhyZWUgcmV2b2NhdGlvbiBjaGVja2lu ZyBtb2RhbGl0aWVzOg0KPj4NCj4+IDEuIExpdmUgT0NTUCBjaGVja2luZyBbUkZDNjA2OV0NCj4+ IDIuIE9DU1Agc3RhcGxpbmcgLyBtdXN0X3N0YXBsZSBbUkZDNjA2NiwgDQo+PiBkcmFmdC1oYWxs YW1iYWtlci10bHNmZWF0dXJlXSAzLiBTaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZXMgKH5PQ1NQIA0K Pj4gbGlmZXRpbWUpDQo+Pg0KPj4gKFRoZSBsYXN0IG9mIHRoZXNlIGlzIHJlbGF0aXZlbHkgbm92 ZWwsIGFuZCBoYXMgbm90IGJlZW4gZGVwbG95ZWQuDQo+PiBOZWl0aGVyIGhhcyBtdXN0LXN0YXBs ZS4gIEJ1dCB0aGV5J3JlIGJvdGggcHJldHR5IHRyaXZpYWwsIGFuZCBjb3VsZCANCj4+IGJlIGZv bGRlZCBpbnRvIGEgU1RJUiBhcmNoaXRlY3R1cmUgcHJldHR5IGVhc2lseS4pDQo+Pg0KPj4gUmln aHQgbm93LCBhYm91dCA5MCUgb2YgVExTIHRyYW5zYWN0aW9ucyB1c2UgbGl2ZSBPQ1NQLCBhbmQg YWJvdXQgMTAlLg0KPj4gQ0FzIGFuZCBicm93c2VycyBkZWFybHkgd2FudCB0aGUgd29ybGQgdG8g bW92ZSB0b3dhcmQgc3RhcGxlZCBPQ1NQIG9yIA0KPj4gc2hvcnQtbGl2ZWQgY2VydHMsIGJlY2F1 c2UgdGhlc2UgcmVkdWNlcyBsYXRlbmN5IGFuZCBpbXByb3ZlIHRoZSANCj4+IHF1YWxpdHkgb2Yg cmV2b2NhdGlvbiBpbmZvcm1hdGlvbi4NCj4+DQo+PiBSZXZvY2F0aW9uIGZvciBDQSBjZXJ0aWZp Y2F0ZXMgaXMgY3VycmVudGx5IGRvbmUgYnkgaGF2aW5nIGJyb3dzZXJzIA0KPj4gZG93bmxvYWQg YSBsaXN0IGZyb20gYSBjZW50cmFsaXplZCBzZXJ2ZXIsIHNpbmNlIHRoZXJlJ3Mgbm8gd2F5IHRv IA0KPj4gc3RhcGxlIG1vcmUgdGhhbiBvbmUgT0NTUCByZXNwb25zZS4gIFRoYXQgc29sdXRpb24g d29ya3MgT0sgZm9yIHRoZSANCj4+IHdlYiwgYnV0IGlmIEkgd2VyZSBkZXNpZ25pbmcgc29tZXRo aW5nIGRlIG5vdm8sIEkgd291bGQgcHJvYmFibHkgdXNlIA0KPj4gbXVsdGktc3RhcGxpbmcgYXMg d2VsbC4NCj4+DQo+Pg0KPj4gIyBBcHBseWluZyB0aGlzIGV4cGVyaWVuY2UgdG8gU1RJUg0KPj4N Cj4+IE1vc3Qgb2YgdGhlIGJlbG93IGFwcGVhciB0byBiZSBkZXNpcmVkIHByb3BlcnRpZXMgYnkg dGhlIFdHOg0KPj4NCj4+ICogVmVyaWZpZXIgbmVlZWRzIHRvIGtub3cgdGhhdCBhIGNlcnQgaXMg dmFsaWQgZm9yIGEgc3BlY2lmaWMgbnVtYmVyDQo+PiAqIFNjb3BlZCBjZXJ0IGxpZmV0aW1lOiBM aW1pdCBjZXJ0cyB0byB+MXdlZWsgbGlmZXRpbWUgKGJ5IE9DU1AgaWYgDQo+PiBpc3N1ZWQgbG9u Z2VyKQ0KPj4gKiBDYWxsZXIgcHJpdmFjeTogRG9uJ3QgcmVwb3J0IHdoYXQgY2FsbHMgc29tZW9u ZSByZWNlaXZlcyB0byBhIA0KPj4gY2VudHJhbCBzZXJ2ZXINCj4+ICogQ2FycmllciBwcml2YWN5 OiBEb24ndCBhbGxvdyBhIHRoaXJkIHBhcnR5IHRvIGZpZ3VyZSBvdXQgYWxsIHRoZSANCj4+IG51 bWJlcnMgYSBjYXJyaWVyIGhvbGRzDQo+PiAqIE1pbmltaXplIHRoZSByYXRlIGF0IHdoaWNoIHRo ZSBDQSBoYXMgdG8gc2lnbiB0aGluZ3MNCj4+ICogVG9sZXJhdGUgb3V0YWdlcyBhdCB0aGUgQ0EN Cj4+DQo+PiBJJ20gZ29pbmcgdG8gYXNzdW1lIGZvciBub3cgdGhhdCB3ZSB3aWxsIG5vdCBkbyBs aXZlIE9DU1AuICBJdCANCj4+IHZpb2xhdGVzIHRoZSBjYWxsZXIgcHJpdmFjeSByZXF1aXJlbWVu dCwgYW5kIGFzIGRpc2N1c3NlZCBhYm92ZSwgaXQgDQo+PiBqdXN0IHN1Y2tzIG9wZXJhdGlvbmFs bHkuICBTbyBTVElSIHNob3VsZCByZXF1aXJlIE9DU1AgdG8gYmUgc2VudCBpbiANCj4+ICJzdGFw bGVkIiBmb3JtLCB3aGljaCBwcm9iYWJseSBtZWFucyBzZW5kaW5nIGl0IGluIElkZW50aXR5LUlu Zm8uICANCj4+IEFuZCB3aGlsZSB3ZSdyZSBhdCBpdCwgd2Ugc2hvdWxkIGFsc28gZG8gIm11bHRp LXN0YXBsaW5nIiAtLSBzZW5kIGFuIA0KPj4gT0NTUCByZXNwb25zZSBmb3IgQ0EgY2VydHMgYXMg d2VsbC4NCj4+DQo+PiBTbyBpZiB3ZSBjb25zaWRlciBhIHNlcnZlciB3aXRoIDUwayBUTnMgLyBi bG9ja3MsIHRoYXQgbGVhdmVzIHVzIHdpdGggDQo+PiBiYXNpY2FsbHkgMyBvcHRpb25zOg0KPj4N Cj4+IDEuIDUwayBzaG9ydC1saXZlZCBjZXJ0cyAobm8gT0NTUCkNCj4+IDIuIDUwayBsb25nLWxp dmVkIGNlcnRzIHNjb3BlZCB0byBUTnMgKyBnZW5lcmljIE9DU1AgMy4gMSBsb25nLWxpdmVkIA0K Pj4gY2VydCBub3Qgc2NvcGVkIHRvIFROIChvciBhIGZldyBsb29zZWx5IHNjb3BlZCkgKyBPQ1NQ IHdpdGggVE4gaW5mbw0KPj4NCj4+IChBcyBJIGRpZG4ndCBxdWl0ZSBnZXQgdG8gc2F5IGluIHRo ZSBtZWV0aW5nLCByZWdhcmRsZXNzIG9mIHRoZSANCj4+IGFwcHJvYWNoLCB5b3UgaGF2ZSB0byBo YXZlIDUwayBvZiAqc29tZXRoaW5nKi4pICBPZiB0aGVzZSwgaXQgc2VlbXMgDQo+PiBsaWtlIHRo ZSBwcmVmZXJlbmNlIG9yZGVyIGlzIDIgPiAxID4gMy4NCj4+DQo+PiBPcHRpb24gMyBpcyBiYWQg ZnJvbSBzZXZlcmFsIHBlcnNwZWN0aXZlczoNCj4+ICogUHV0dGluZyBUTiBpbmZvIGluIHRoZSBP Q1NQIHJlc3BvbnNlIGVuYWJsZXMgc29tZW9uZSB0byB0cmF3bCBmb3IgDQo+PiBudW1iZXJzIHVu bGVzcyB5b3UgYWNjZXNzLWNvbnRyb2wgdGhlIE9DU1Agc2VydmVyLCBzbyB5b3UgaW5oZXJpdCBh IA0KPj4gcmVxdWlyZW1lbnQgdG8gZG8gdGhhdC4NCj4+ICogV2l0aCB0aGUgcmF0ZSBvZiBjaHVy biBpbiBudW1iZXIgYXNzaWdubWVudHMsIHlvdSdyZSBwcm9iYWJseSBnb2luZyANCj4+IHRvIGhh dmUgdG8gdXBkYXRlIHRoZSBsb25nLWxpdmVkIGNlcnQgcHJldHR5IGZyZXF1ZW50bHkgYW55d2F5 Lg0KPj4gKiBQdXR0aW5nIFROLXNwZWNpZmljIHN0dWZmIGluIGNlcnRzIGlzIGJldHRlciB0aGFu IHB1dHRpbmcgaXQgaW4gDQo+PiBPQ1NQLiAgQXMgYmFkIGFzIFguNTA5IGxpYnJhcmllcyBjYW4g YmUsIE9DU1AgbGlicmFyaWVzIGFyZSBtdWNoIA0KPj4gd29yc2UuDQo+Pg0KPj4gT3B0aW9uIDEg aXMgbWFpbmx5IGJhZCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBDQSBsb2FkIGFuZCBvdXRhZ2Vz Lg0KPj4gV2l0aCBPcHRpb24gMiwgaWYgdGhlIENBIGdvZXMgZG93biwgY2xpZW50IGNhbiBjb250 aW51ZSB0byB1c2UgdGhlIA0KPj4gbG9uZy1saXZlZCBjZXJ0IGFuZCBqdXN0IG5vdCBib3RoZXIg ZG9pbmcgT0NTUCAodnMuIHRvbGVyYXRpbmcgYW4gDQo+PiBleHBpcmVkIGNlcnQpLiAgU2xpZ2h0 bHkgY2xlYW5lci4gIFBsdXMsIHRoZXJlJ3MgYSBsb3QgbW9yZSANCj4+IGV4cGVyaWVuY2UgY2Fj aGluZyBPQ1NQIHRoYW4gbmV3IGNlcnRzLiAgT0NTUCBzaWduaW5nIGNhbiBhbHNvIGJlIA0KPj4g ZGVsZWdhdGVkLCBzbyB5b3UgY2FuIGhhdmUgdGhlIHJlY3VycmluZyBvcGVyYXRpb24gZG9uZSBi eSBhIGxvd2VyLXJpc2sga2V5Lg0KPj4NCj4+IE9wdGlvbiAyIHNob3VsZCBiZSBwcmV0dHkgZWFz eSB0byBhdXRvbWF0ZS4gIFlvdSBjYW4gcHJvYmFibHkgcmUtdXNlIA0KPj4gdG9vbGluZyBmb3Ig T0NTUCBzdGFwbGluZyB0aGF0IGhhcyBhbHJlYWR5IGJlZW4gZGV2ZWxvcGVkIGZvciB1c2UgDQo+ PiB3aXRoIEhUVFBTLiAgSWYgeW91J3JlIGEgYmlnIGJveCBzaWduaW5nIGZvciBhIGJ1bmNoIG9m IG51bWJlcnMsIHlvdSANCj4+IGRvIG5lZWQgdG8gc2VsZWN0IHRoZSByaWdodCBjZXJ0IGFuZCBP Q1NQIHJlc3BvbnNlIGZvciBhIGdpdmVuIGNhbGwsIA0KPj4gYnV0IHRoYXQncyBhIHByZXR0eSBz aW1wbGUgbG9va3VwIHRhYmxlLg0KPj4gPFNUSVIucHB0eD5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+IHN0aXJA aWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0K Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3Rp ciBtYWlsaW5nIGxpc3QNCnN0aXJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3Rpcg0K From nobody Tue Jul 28 06:52:27 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AB81A907B for ; Tue, 28 Jul 2015 06:52:26 -0700 (PDT) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 GllBdAOONOfd for ; Tue, 28 Jul 2015 06:52:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC271A9074 for ; Tue, 28 Jul 2015 06:52:23 -0700 (PDT) Received: from BL2FFO11FD052.protection.gbl (10.173.160.32) by BL2FFO11HUB037.protection.gbl (10.173.160.241) with Microsoft SMTP Server (TLS) id 15.1.231.11; Tue, 28 Jul 2015 13:52:02 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com; Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BL2FFO11FD052.mail.protection.outlook.com (10.173.161.214) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Tue, 28 Jul 2015 13:52:02 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6SDnomw048965; Tue, 28 Jul 2015 08:52:01 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm1.corp.sprint.com with ESMTP id 1vv83kn1yd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2015 08:52:01 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 28 Jul 2015 08:52:00 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Tue, 28 Jul 2015 08:52:00 -0500 From: "Gorman, Pierce A [CTO]" To: Alex Bobotek , Brian Rosen , "Richard Barnes" Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3w5jYQ Date: Tue, 28 Jul 2015 13:51:59 +0000 Message-ID: <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> In-Reply-To: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD052; 1:siJ2b2OSJawF2LdA1F6SlnUexEk2g0EpRWdOSTAWUlJpdzl2krb8NXORTev7uV2RzWL3dXrKwO1M0BpEPUMHTYALmkiAPrixZhQnR5ol5HNGWZF/o51uRdHhuv4fhN+7G+mGK5bQq0X0gk6IegUsHCSHhIJiegl6K1TNBlUAt5f9Kqa8k3mR7UaXzvYL5s0qIf3Uo2JOq37+FjrAjY7rb3eVMrbNON0uQ/Ma2bB/53z8sPBmMaInggmfiSPS3uTv5OWFbbfE4F0t4v40ol1JT+sJdGCrJgt6kAEw3wSaBEy128Vr6QrqSF51SE4EM91+ X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(13464003)(377454003)(189002)(199003)(50986999)(54356999)(19580405001)(76176999)(551934003)(6806004)(102836002)(50466002)(33646002)(47776003)(23676002)(5001960100002)(77156002)(106466001)(106116001)(46102003)(2900100001)(86362001)(5250100002)(108616004)(87936001)(62966003)(5890100001)(2656002)(15975445007)(2950100001)(92566002)(5001770100001)(24736003)(19580395003)(189998001)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB037; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB037; 2:JeXacRSdgO3iA76LCLxNo/aOuSX/Yxx32ycW8J+iM0WboDOyMtU+0mYD76H33LwHGmZ3WGP1PTPOAr12QFc79LTnHQOxsl+YK2vBsttmVFno7bsouJDMyqFshVEIkm1WgXm3cKiHNdSJ5xv1bRl2yCXfylta+ctvmOMNqnk/qck=; 3:U1K+hmUuKviyMAWcJB1zhGJn/lwEoYbtfXendW8w6/mtlv9v6iXroVp4swo+c/FaCtWeSxtzyAlDKWDRVz6P3w3vB8KWs9IzHSHK85+f95r4HOb9c+WGMzVFb7J8MVyp7sYXGtqBnLZ/aN6OpeLL9gygX9jhTQz2iiZV4m5rkJ1V5iZoAi3XISAfNIp5MiR46VnVMVWknh+pjBpcWG7ZdP0LPsSRcHZe/NmWrrN3uIZV1Bkq8qbTnGAcUoqDDj3K; 25:yGsmaY/FzWCsellP3HAKHFbc/aq5aRioVbnkJeD7JE/JrgcgYv+NyO5H4wI38dmiE1vVN1ehdd8d2Rfa7vd1gCkPUIbIcN4faRysHD6U7lTicTtH3ATJtMT2QL+sDoaHKWnqmKR2qd38RI+XZ8CHq+DD5oCv31x4cbAWHnpEXzXXJRbXrehdMIxb/RrPDY7FV/NPjujJ0ZCPidBL6ixluZheWnpPPIgvENo7jxc8WJdtMNJmDnxwzsieLfrc0eqTcTNI49oHHD5KlwU/M6HShg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB037; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB037; 20:OvLKWMeDskJcGupwOJ1h7IBcLYRv8yVikPzKHc59zmROhALsEQewsnlDI+FQH0Fo2ivw4PKgPkIhsdoLDLVwTD4qjqSRb8Ejjd4jNv6trMYzQrv73jxgIwt7BfBLFBzwY8kS0ohbnCBS/4y7RifmVS/bbn1VCVM7UWZWfAAz84tNKtgqcprkJO0wKu33R6H1ll7in2L0Lb2RydYKBFjNgf6QiOYcJKqC3bHna4U9oMkRCnBCjMAQ7FKJakEyXI/5; 4:q/4hj5nB8nUZNhUaNvU0ZJ+1oP1LyPr1UikMSlbwvQRHNj+y77corbopwfb/g/UOzO7PpQwUJAwh5YhnGs/vz+zJFgNb5isMag7mbL9OmTQHbYeKD0DgqYEFIojJEWpBVBCgmE0xIK/VMXbYAR5HOCgCc+O6c44bvZKhkAuhOa151VGN0xVED7AHWnFgyfC62rDOdtdROyYFfDBPpKg1QYUyZkno7Nro2qFUsWE2cM0XdF+k9/zzyXTT8Cz9x+iFBf6d9m1Gyw6X7x56mWwx6A40VjfCtpixJAJz1MqnDV8= BL2FFO11HUB037: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BL2FFO11HUB037; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB037; X-Forefront-PRVS: 06515DA04B X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDJGRk8xMUhVQjAzNzsyMzpsaWNIQ3Z6dVpCT29aK2RZZHd4b2YzZ3RL?= =?utf-8?B?M2FwODJlRHJySUEwY0NPcE5TeW1SNlJXWEYyU3lNWUNSbFI1cVRSYTV4Nncw?= =?utf-8?B?dUpNc2VEdnRZZFlmc0VvREpDaTZHczBBMGFYRTkyMkhacHlGeDNENkFudjNR?= =?utf-8?B?QVdnS2FJWWRmaXFjNjFHcm00aGdhVjdSbmw3OTZab0tiQ0ZYTzdBd3NYVVN0?= =?utf-8?B?Z0J0ZU84Q2NKTTU2VCt6cTRuNkNoU1dkczJicHpsVDU5eHVlMGJGL0JaQjhH?= =?utf-8?B?MDJVYmxkekorcytDT3NJcXUxbDExeEdNY2pSVzJGd1QzUVNqbklzTnY5Q2o0?= =?utf-8?B?RjNrQ2xnbFZNNlV0Y0dqYkIxV29hY085U2tpRFhWTW16MDNpUU9OSWxRenVt?= =?utf-8?B?b2ZrZVdCdzl1c1VTK09xWTA4eTNFcVZ2ekd1eFJ1S3pIRGt2blQxaWR5UlpB?= =?utf-8?B?ODZJdWUybjVob2F0YjRWRUNid2kzanhJS3NhUDRCZ0pSd0YzdEd4dEJ0WkN0?= =?utf-8?B?dFgxVmdWUGNNaE5lWWZxeSszWkM0dWJKVFdodmlld3FHSHA4WURjUC8ycVdn?= =?utf-8?B?M0ppNHpBOUFKNzlNOURaNzJXWnRIQ1ZQU292cnJMSlFBWkFJUzBnUjBybzRJ?= =?utf-8?B?ekRMc0VxVllMSFprckw5S0d0dnpZbDVDamxLWU9SVU5acHZldmZmSlRtcFdU?= =?utf-8?B?ZWhZMVl5cEtoY05TcWJPRFhtenNZYmVGT1AzV0EyaWlKYXhwb0NSRi94Qk5B?= =?utf-8?B?TlJMNXhRUkdZRzF3U0pQcXl1Rm5BOEs1Q1FPVHowOXRGWmpxcGhpSmFaa2l2?= =?utf-8?B?SUI4eGx0aXNaU2dpOTIyb2RkOTdZS3FIOTJCL1pyNmo1d3hGcUtpUmxiVkc1?= =?utf-8?B?RkdSaE1IOXdselFuTUs4VU9UcUpoTXdBQ2N5M1JXY0pUdmUzWEZsa1hXNVUw?= =?utf-8?B?RGx3SWd3Q1ZoZEpLRnUza3dISndzWGpvd251UUdzaXB2SUhpdXBFWkhWay9O?= =?utf-8?B?RnduaXVsb3o2dTcxVzlBVTR1Z2RGcWhJbzl1K0lDVEdsWVpTUXRtTEprcWdo?= =?utf-8?B?N3FMRUcrNHlaTk8zNTcwaCtkejhjTjRLZE44UkgrY1A0VzRvekd4TUZPY3lq?= =?utf-8?B?bGFycURwRTdOWnFFY0NQZFVFWVBpTW12cnpMV29rekdFN0pLSTdyWGhBTGV1?= =?utf-8?B?dllIZWZzWEpMemhiaXJ0Qy9HTWxXbkkrSjdFMGcybEt1Nlk0cVcrQ2k1TUt2?= =?utf-8?B?VS82QXZaYXNvcFlEdmJXWXVSSWhvSEZSeDRKRXcweVcvamZRVE1pSUg2S05I?= =?utf-8?B?T2k3NHVvc2VVMkdBaHlERTlvbkg5Y1ZDNW9adEFNSWNnRjJGZE9lZkZ2Zy9s?= =?utf-8?B?bzdDMEF0REFSY2k0WWtjdXNPY0NSbmN6MTV0USsxSE9DNjZIc3p5SnJhdTly?= =?utf-8?Q?UZdU7aY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB037; 5:ZghIEhHq6a2gNlW6ckJ1coQSHF/s31v2ICd/JPogaNJYg8qW+exjSc8nYcsOo+8y0oZDN++7cJewSPeeObuTUwa8BBOURA1YZWBaDdUQ/RZp/1tUBVe4EceB829dv86u98nH/TZW1CujAYB7JfN2bg==; 24:NZu6czLvzM/+6iTGZUVPVyn9PcOOIbMIA4Vf+eedq8DGoinn6RPipxvMFybEFSB4grXSc3xiFQu3GARG4n+Rx/0pP5w5wQ575RaxIBveNb0= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2015 13:52:02.0002 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB037 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 13:52:27 -0000 IkxhcmdlIHNjYWxlIGNlcnRpZmljYXRlIG1hbmFnZW1lbnQgaXMgZXhwZW5zaXZlLCBhbmQgVE4t c3BlY2lmaWMgY2VydGlmaWNhdGVzIGFyZSB1bm5lZWRlZCBmb3Igc2VjdXJpbmcgY2FsbHMgcGxh Y2VkIGJ5IHBhcnRpZXMgd2hvIGNob29zZSB0byBwbGFjZSBjYWxscyB0aHJvdWdoIGEgc2luZ2xl IHJlcHV0YWJsZSB0ZWxlcGhvbmUgc2VydmljZSBwcm92aWRlci4iDQoNCkFyZSB5b3Ugc2F5aW5n IHRoYXQgZm9yICJvbi1uZXQiIGNhbGxzLCBTVElSIG1ldGhvZG9sb2d5IGlzIHVubmVjZXNzYXJ5 Pw0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KUGllcmNlIEdvcm1hbg0KQ29yZSBOZXR3b3JrIFBsYW5u aW5nDQpPOiA5MTMtNDM5LTQzNjgNCnBpZXJjZS5nb3JtYW5Ac3ByaW50LmNvbQ0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGV4IEJvYm90ZWsgW21haWx0bzphbGV4QGJv Ym90ZWsubmV0XQ0KU2VudDogSnVseSAyNywgMjAxNSAxMTozNiBQTQ0KVG86IEJyaWFuIFJvc2Vu IDxickBicmlhbnJvc2VuLm5ldD47IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4Pg0KQ2M6IHN0 aXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBhbmQgUHJpdmFj eQ0KDQpXaGF0IG1vdGl2YXRpb24gd291bGQgYSBjYXJyaWVyIGhhdmUgdG8gY2hvb3NlIGFueSBt b2RlbCBvdGhlciB0aGFuIGNhcnJpZXIgc2lnbmluZyB1c2luZyBvbmUgb2YgYSB2ZXJ5IGxpbWl0 ZWQgc2V0IG9mIGNhcnJpZXItb3duZWQga2V5cz8gIExhcmdlIHNjYWxlIGNlcnRpZmljYXRlIG1h bmFnZW1lbnQgaXMgZXhwZW5zaXZlLCBhbmQgVE4tc3BlY2lmaWMgY2VydGlmaWNhdGVzIGFyZSB1 bm5lZWRlZCBmb3Igc2VjdXJpbmcgY2FsbHMgcGxhY2VkIGJ5IHBhcnRpZXMgd2hvIGNob29zZSB0 byBwbGFjZSBjYWxscyB0aHJvdWdoIGEgc2luZ2xlIHJlcHV0YWJsZSB0ZWxlcGhvbmUgc2Vydmlj ZSBwcm92aWRlci4gIEFueW9uZSBjYW4gZ2V0IG1hbnkgY2VydGlmaWNhdGVzLCBldmVuIGEgZnJl ZSBvbmVzIGFub255bW91c2x5IGZyb20gc29tZSBpc3N1ZXJzLiAgSXQgaXMgdHlwaWNhbGx5IGEg Y29tYmluYXRpb24gb2YgdGhlIHN0cmVuZ3RoIG9mIHRoZSBlbmQtdXNlciBhdXRoZW50aWNhdGlv biBwZXJmb3JtZWQgYnkgdGhlIHNlcnZpY2UgcHJvdmlkZXIgKG9yIGNlcnRpZmljYXRlIGlzc3Vl ciBpbiBhIHByb3ZpZGVyLWFnbm9zdGljIG1vZGVsKSBhbmQgdGhlIGlkZW50aXR5J3MgaGlzdG9y eSB0aGF0IGFyZSBtb3N0IHVzZWZ1bCBpbiBzZWN1cml0eS4NCg0KSWYgd2UncmUgdHJ5aW5nIHRv IHNlY3VyZSB0aGUgY3VycmVudCB0ZWxlcGhvbmUgc3lzdGVtLCBETlMtbGlrZSBrZXkgcmVwb3Np dG9yaWVzIGEgbGEgREtJTSBvciBwZXJoYXBzIGEgc21hbGwgbnVtYmVyIChjb21wYXJlZCB0byB0 aGUgbnVtYmVyIG9mIFROcykgb2YgY2VydGlmaWNhdGVzIGFyZSBmYXIgbW9yZSBwcmFjdGljYWwu DQoNClJlZ2FyZHMsDQoNCkFsZXgNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBzdGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJp YW4gUm9zZW4NCj4gU2VudDogTW9uZGF5LCBKdWx5IDI3LCAyMDE1IDc6NDAgUE0NCj4gVG86IFJp Y2hhcmQgQmFybmVzIDxybGJAaXB2LnN4Pg0KPiBDYzogc3RpckBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW3N0aXJdIE9uIE9DU1AsIFROcywgYW5kIFByaXZhY3kNCj4NCj4gV2hhdCB0aGlzIG1l YW5zIGluIHByYWN0aWNlIGlzIHRoYXQgaXTigJlzIFROIHBlciBjZXJ0Lg0KPg0KPiBJIHdvdWxk buKAmXQgc2F5IHRoYXQgaXTigJlzIGltcG9zc2libGUgZm9yIGEgY2FycmllciB0byBtYWludGFp biBkb3plbnMNCj4gb2YgY29waWVzIG9mIG1pbGxpb25zIG9mIHByaXZhdGUga2V5cyBzZWN1cmVs eSwgYnV0IGl04oCZcyBoYXJkLiAgWW91DQo+IG5lZWQgbXVsdGlwbGUgY29waWVzIGJlY2F1c2Ug eW91IGhhdmUgbXVsdGlwbGUgZWxlbWVudHMgdGhhdCBjYW4NCj4gaW5pdGlhdGUgYSBjYWxsLCBh bmQgeW91IGRvbuKAmXQgd2FudCB0byBkZXBlbmQgb24gYSBjZW50cmFsaXplZA0KPiByZXNvdXJj ZSB0byBkbyBzb21ldGhpbmcgYXMgYmFzaWMgYXMgY3JlYXRlIGEgY2FsbC4NCj4NCj4gSSB0aGlu ayBpdOKAmXMgaGFyZCBlbm91Z2ggdGhhdCBSRVFVSVJJTkcgY2VydCBwZXIgVE4gaXMgbm90IGFj Y2VwdGFibGUuDQo+DQo+IEZvbGtzIHdpdGggbW9yZSBpbnRpbWF0ZSBrbm93bGVkZ2Ugb2YgY2Fy cmllciBTSVAgaW5mcmFzdHJ1Y3R1cmUgbWlnaHQNCj4gaGF2ZSBtb3JlIGluc2lnaHQgdGhhbiBJ IGRvLiAgSXQgbWF5IGJlIGFjY2VwdGFibGUgdG8gaGF2ZSBhDQo+IGNlbnRyYWxpemVkIHJlc291 cmNlIHRvIG1hbmFnZSBtaWxsaW9ucyBvZiBrZXlzLg0KPg0KPiBCcmlhbg0KPg0KPiA+IE9uIEp1 bCAyNywgMjAxNSwgYXQgNjoxMyBQTSwgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+IHdyb3Rl Og0KPiA+DQo+ID4gQWZ0ZXIgdGhlIFNUSVIgbWVldGluZyBpbiBQcmFndWUsIEhlbm5pbmcgYW5k IEkgc3BlbnQgYSBmZXcgbWludXRlcw0KPiA+IHRhbGtpbmcgdGhyb3VnaCBvcHRpb25zIGZvciBy ZXZvY2F0aW9uIGNoZWNraW5nIGFuZCBjZXJ0aWZpY2F0ZQ0KPiA+IHNjb3BpbmcsIGFuZCBJIHRo aW5rIHdlIGhhdmUgYSBiZXR0ZXIgaWRlYSBvZiB3aGF0IHRoZSBvcHRpbWFsDQo+ID4gc29sdXRp b24gbG9va3MgbGlrZS4gIFNvbWUgbm90ZXMgYXJlIGJlbG93LCBhbmQgc29tZSBzbGlkZXMgd2l0 aA0KPiA+IHBpY3R1cmVzIGF0dGFjaGVkLg0KPiA+DQo+ID4gdGw7ZHI6IFdlIHNob3VsZDoNCj4g PiAqIEtlZXAgVE5zIGluIGNlcnRpZmljYXRlcyBhbmQgbm90IGJvdGhlciB3aXRoIGFueSBPQ1NQ IGV4dGVuc2lvbnMNCj4gPiAqIFJlcXVpcmUgSWRlbnRpdHktSW5mbyB0byBpbmNsdWRlIE9DU1Ag cmVzcG9uc2VzIGZvciBhbGwgY2VydHMgaW4NCj4gPiB0aGUgY2hhaW4NCj4gPg0KPiA+DQo+ID4g IyBCYWNrZ3JvdW5kOiBSZXZvY2F0aW9uIGluIHRoZSB3ZWIgUEtJDQo+ID4NCj4gPiBJbiBhbiBI VFRQUyB0cmFuc2FjdGlvbiwgdGhlIEhUVFBTIHNlcnZlciBwcm92aWRlcyB0aGUgY2xpZW50IHdp dGggYQ0KPiA+IGNlcnRpZmljYXRlLCBhbmQgaXQgY2FuIG9wdGlvbmFsbHkgaW5jbHVkZSBhbiBP Q1NQIHJlc3BvbnNlICgic3RhcGxlIg0KPiA+IGl0IHRvIHRoZSB0cmFuc2FjdGlvbikuDQo+ID4N Cj4gPiBBIGNlcnRpZmljYXRlIGNvbnRhaW5zIGEgdmFsaWRpdHkgaW50ZXJ2YWwsIGEga2V5LCBh bmQgc29tZSBuYW1lcy9UTnMuDQo+ID4gQW4gT0NTUCByZXNwb25zZXMgY29udGFpbnMgYSB2YWxp ZGl0eSBpbnRlcnZhbCwgYSBjZXJ0aWZpY2F0ZSBJRA0KPiA+IChpLmUuLCBhIGhhc2gpLCBhbmQg YSBzdGF0dXMgKGdvb2QvcmV2b2tlZC91bmtub3duKS4gIEluIHRoZSB3ZWINCj4gPiBQS0ksIGNl cnRpZmljYXRlcyBhcmUgcmVxdWlyZWQgdG8gYmUgbm8gbW9yZSB0aGFuIDM5IG1vbnRocyBsb25n LA0KPiA+IGFuZCBPQ1NQIHJlc3BvbnNlcyBubyBtb3JlIHRoYW4gMTAgZGF5cy4NCj4gPg0KPiA+ IElkZWFsbHksIGEgY2xpZW50IG9ubHkgY29uc2lkZXJzIGEgY2VydGlmaWNhdGUgdmFsaWQgaWYg aXQgaXMNCj4gPiBhY2NvbXBhbmllZCBieSBhbiBPQ1NQIHJlc3BvbnNlLiAgSW4gcHJhY3RpY2Us IHRoaXMgaXMgbm90IGFsd2F5cw0KPiA+IHBvc3NpYmxlOyBiZWNhdXNlIE9DU1AgcXVlcmllcyBm YWlsIGFyb3VuZCAzJSBvZiB0aGUgdGltZSwgYnJvd3NlcnMNCj4gPiBjYW4ndCByZXF1aXJlIE9D U1AuICBUaGlzIG9wZXJhdGlvbmFsIGZhY3Qgd2lsbCBiZSBpbXBvcnRhbnQgYmVsb3csDQo+ID4g YnV0IHdlIHdpbGwgY29udGludWUgdG8gaGF2ZSBzY29waW5nIGNlcnQgbGlmZXRpbWVzIGFzIGFu IG9iamVjdGl2ZS4NCj4gPg0KPiA+IEluIHRoZSB3ZWIgUEtJLCB0aGVyZSBhcmUgYmFzaWNhbGx5 IHRocmVlIHJldm9jYXRpb24gY2hlY2tpbmcgbW9kYWxpdGllczoNCj4gPg0KPiA+IDEuIExpdmUg T0NTUCBjaGVja2luZyBbUkZDNjA2OV0NCj4gPiAyLiBPQ1NQIHN0YXBsaW5nIC8gbXVzdF9zdGFw bGUgW1JGQzYwNjYsDQo+ID4gZHJhZnQtaGFsbGFtYmFrZXItdGxzZmVhdHVyZV0gMy4gU2hvcnQt bGl2ZWQgY2VydGlmaWNhdGVzICh+T0NTUA0KPiA+IGxpZmV0aW1lKQ0KPiA+DQo+ID4gKFRoZSBs YXN0IG9mIHRoZXNlIGlzIHJlbGF0aXZlbHkgbm92ZWwsIGFuZCBoYXMgbm90IGJlZW4gZGVwbG95 ZWQuDQo+ID4gTmVpdGhlciBoYXMgbXVzdC1zdGFwbGUuICBCdXQgdGhleSdyZSBib3RoIHByZXR0 eSB0cml2aWFsLCBhbmQgY291bGQNCj4gPiBiZSBmb2xkZWQgaW50byBhIFNUSVIgYXJjaGl0ZWN0 dXJlIHByZXR0eSBlYXNpbHkuKQ0KPiA+DQo+ID4gUmlnaHQgbm93LCBhYm91dCA5MCUgb2YgVExT IHRyYW5zYWN0aW9ucyB1c2UgbGl2ZSBPQ1NQLCBhbmQgYWJvdXQgMTAlLg0KPiA+IENBcyBhbmQg YnJvd3NlcnMgZGVhcmx5IHdhbnQgdGhlIHdvcmxkIHRvIG1vdmUgdG93YXJkIHN0YXBsZWQgT0NT UA0KPiA+IG9yIHNob3J0LWxpdmVkIGNlcnRzLCBiZWNhdXNlIHRoZXNlIHJlZHVjZXMgbGF0ZW5j eSBhbmQgaW1wcm92ZSB0aGUNCj4gPiBxdWFsaXR5IG9mIHJldm9jYXRpb24gaW5mb3JtYXRpb24u DQo+ID4NCj4gPiBSZXZvY2F0aW9uIGZvciBDQSBjZXJ0aWZpY2F0ZXMgaXMgY3VycmVudGx5IGRv bmUgYnkgaGF2aW5nIGJyb3dzZXJzDQo+ID4gZG93bmxvYWQgYSBsaXN0IGZyb20gYSBjZW50cmFs aXplZCBzZXJ2ZXIsIHNpbmNlIHRoZXJlJ3Mgbm8gd2F5IHRvDQo+ID4gc3RhcGxlIG1vcmUgdGhh biBvbmUgT0NTUCByZXNwb25zZS4gIFRoYXQgc29sdXRpb24gd29ya3MgT0sgZm9yIHRoZQ0KPiA+ IHdlYiwgYnV0IGlmIEkgd2VyZSBkZXNpZ25pbmcgc29tZXRoaW5nIGRlIG5vdm8sIEkgd291bGQg cHJvYmFibHkgdXNlDQo+ID4gbXVsdGktc3RhcGxpbmcgYXMgd2VsbC4NCj4gPg0KPiA+DQo+ID4g IyBBcHBseWluZyB0aGlzIGV4cGVyaWVuY2UgdG8gU1RJUg0KPiA+DQo+ID4gTW9zdCBvZiB0aGUg YmVsb3cgYXBwZWFyIHRvIGJlIGRlc2lyZWQgcHJvcGVydGllcyBieSB0aGUgV0c6DQo+ID4NCj4g PiAqIFZlcmlmaWVyIG5lZWVkcyB0byBrbm93IHRoYXQgYSBjZXJ0IGlzIHZhbGlkIGZvciBhIHNw ZWNpZmljIG51bWJlcg0KPiA+ICogU2NvcGVkIGNlcnQgbGlmZXRpbWU6IExpbWl0IGNlcnRzIHRv IH4xd2VlayBsaWZldGltZSAoYnkgT0NTUCBpZg0KPiA+IGlzc3VlZCBsb25nZXIpDQo+ID4gKiBD YWxsZXIgcHJpdmFjeTogRG9uJ3QgcmVwb3J0IHdoYXQgY2FsbHMgc29tZW9uZSByZWNlaXZlcyB0 byBhDQo+ID4gY2VudHJhbCBzZXJ2ZXINCj4gPiAqIENhcnJpZXIgcHJpdmFjeTogRG9uJ3QgYWxs b3cgYSB0aGlyZCBwYXJ0eSB0byBmaWd1cmUgb3V0IGFsbCB0aGUNCj4gPiBudW1iZXJzIGEgY2Fy cmllciBob2xkcw0KPiA+ICogTWluaW1pemUgdGhlIHJhdGUgYXQgd2hpY2ggdGhlIENBIGhhcyB0 byBzaWduIHRoaW5ncw0KPiA+ICogVG9sZXJhdGUgb3V0YWdlcyBhdCB0aGUgQ0ENCj4gPg0KPiA+ IEknbSBnb2luZyB0byBhc3N1bWUgZm9yIG5vdyB0aGF0IHdlIHdpbGwgbm90IGRvIGxpdmUgT0NT UC4gIEl0DQo+ID4gdmlvbGF0ZXMgdGhlIGNhbGxlciBwcml2YWN5IHJlcXVpcmVtZW50LCBhbmQg YXMgZGlzY3Vzc2VkIGFib3ZlLCBpdA0KPiA+IGp1c3Qgc3Vja3Mgb3BlcmF0aW9uYWxseS4gIFNv IFNUSVIgc2hvdWxkIHJlcXVpcmUgT0NTUCB0byBiZSBzZW50IGluDQo+ID4gInN0YXBsZWQiIGZv cm0sIHdoaWNoIHByb2JhYmx5IG1lYW5zIHNlbmRpbmcgaXQgaW4gSWRlbnRpdHktSW5mby4NCj4g PiBBbmQgd2hpbGUgd2UncmUgYXQgaXQsIHdlIHNob3VsZCBhbHNvIGRvICJtdWx0aS1zdGFwbGlu ZyIgLS0gc2VuZCBhbg0KPiA+IE9DU1AgcmVzcG9uc2UgZm9yIENBIGNlcnRzIGFzIHdlbGwuDQo+ ID4NCj4gPiBTbyBpZiB3ZSBjb25zaWRlciBhIHNlcnZlciB3aXRoIDUwayBUTnMgLyBibG9ja3Ms IHRoYXQgbGVhdmVzIHVzDQo+ID4gd2l0aCBiYXNpY2FsbHkgMyBvcHRpb25zOg0KPiA+DQo+ID4g MS4gNTBrIHNob3J0LWxpdmVkIGNlcnRzIChubyBPQ1NQKQ0KPiA+IDIuIDUwayBsb25nLWxpdmVk IGNlcnRzIHNjb3BlZCB0byBUTnMgKyBnZW5lcmljIE9DU1AgMy4gMSBsb25nLWxpdmVkDQo+ID4g Y2VydCBub3Qgc2NvcGVkIHRvIFROIChvciBhIGZldyBsb29zZWx5IHNjb3BlZCkgKyBPQ1NQIHdp dGggVE4gaW5mbw0KPiA+DQo+ID4gKEFzIEkgZGlkbid0IHF1aXRlIGdldCB0byBzYXkgaW4gdGhl IG1lZXRpbmcsIHJlZ2FyZGxlc3Mgb2YgdGhlDQo+ID4gYXBwcm9hY2gsIHlvdSBoYXZlIHRvIGhh dmUgNTBrIG9mICpzb21ldGhpbmcqLikgIE9mIHRoZXNlLCBpdCBzZWVtcw0KPiA+IGxpa2UgdGhl IHByZWZlcmVuY2Ugb3JkZXIgaXMgMiA+IDEgPiAzLg0KPiA+DQo+ID4gT3B0aW9uIDMgaXMgYmFk IGZyb20gc2V2ZXJhbCBwZXJzcGVjdGl2ZXM6DQo+ID4gKiBQdXR0aW5nIFROIGluZm8gaW4gdGhl IE9DU1AgcmVzcG9uc2UgZW5hYmxlcyBzb21lb25lIHRvIHRyYXdsIGZvcg0KPiA+IG51bWJlcnMg dW5sZXNzIHlvdSBhY2Nlc3MtY29udHJvbCB0aGUgT0NTUCBzZXJ2ZXIsIHNvIHlvdSBpbmhlcml0 IGENCj4gPiByZXF1aXJlbWVudCB0byBkbyB0aGF0Lg0KPiA+ICogV2l0aCB0aGUgcmF0ZSBvZiBj aHVybiBpbiBudW1iZXIgYXNzaWdubWVudHMsIHlvdSdyZSBwcm9iYWJseQ0KPiA+IGdvaW5nIHRv IGhhdmUgdG8gdXBkYXRlIHRoZSBsb25nLWxpdmVkIGNlcnQgcHJldHR5IGZyZXF1ZW50bHkgYW55 d2F5Lg0KPiA+ICogUHV0dGluZyBUTi1zcGVjaWZpYyBzdHVmZiBpbiBjZXJ0cyBpcyBiZXR0ZXIg dGhhbiBwdXR0aW5nIGl0IGluDQo+ID4gT0NTUC4gIEFzIGJhZCBhcyBYLjUwOSBsaWJyYXJpZXMg Y2FuIGJlLCBPQ1NQIGxpYnJhcmllcyBhcmUgbXVjaA0KPiA+IHdvcnNlLg0KPiA+DQo+ID4gT3B0 aW9uIDEgaXMgbWFpbmx5IGJhZCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBDQSBsb2FkIGFuZCBv dXRhZ2VzLg0KPiA+IFdpdGggT3B0aW9uIDIsIGlmIHRoZSBDQSBnb2VzIGRvd24sIGNsaWVudCBj YW4gY29udGludWUgdG8gdXNlIHRoZQ0KPiA+IGxvbmctbGl2ZWQgY2VydCBhbmQganVzdCBub3Qg Ym90aGVyIGRvaW5nIE9DU1AgKHZzLiB0b2xlcmF0aW5nIGFuDQo+ID4gZXhwaXJlZCBjZXJ0KS4g IFNsaWdodGx5IGNsZWFuZXIuICBQbHVzLCB0aGVyZSdzIGEgbG90IG1vcmUNCj4gPiBleHBlcmll bmNlIGNhY2hpbmcgT0NTUCB0aGFuIG5ldyBjZXJ0cy4gIE9DU1Agc2lnbmluZyBjYW4gYWxzbyBi ZQ0KPiA+IGRlbGVnYXRlZCwgc28geW91IGNhbiBoYXZlIHRoZSByZWN1cnJpbmcgb3BlcmF0aW9u IGRvbmUgYnkgYSBsb3dlci1yaXNrIGtleS4NCj4gPg0KPiA+IE9wdGlvbiAyIHNob3VsZCBiZSBw cmV0dHkgZWFzeSB0byBhdXRvbWF0ZS4gIFlvdSBjYW4gcHJvYmFibHkgcmUtdXNlDQo+ID4gdG9v bGluZyBmb3IgT0NTUCBzdGFwbGluZyB0aGF0IGhhcyBhbHJlYWR5IGJlZW4gZGV2ZWxvcGVkIGZv ciB1c2UNCj4gPiB3aXRoIEhUVFBTLiAgSWYgeW91J3JlIGEgYmlnIGJveCBzaWduaW5nIGZvciBh IGJ1bmNoIG9mIG51bWJlcnMsIHlvdQ0KPiA+IGRvIG5lZWQgdG8gc2VsZWN0IHRoZSByaWdodCBj ZXJ0IGFuZCBPQ1NQIHJlc3BvbnNlIGZvciBhIGdpdmVuIGNhbGwsDQo+ID4gYnV0IHRoYXQncyBh IHByZXR0eSBzaW1wbGUgbG9va3VwIHRhYmxlLg0KPiA+IDxTVElSLnBwdHg+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzdGlyIG1haWxpbmcgbGlz dA0KPiA+IHN0aXJAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3N0aXINCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gc3RpciBtYWlsaW5nIGxpc3QNCj4gc3RpckBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVu dChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRl IGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo= From nobody Tue Jul 28 07:12:22 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028E91A9248 for ; Tue, 28 Jul 2015 07:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 GDVMm1hk8JZg for ; Tue, 28 Jul 2015 07:12:18 -0700 (PDT) Received: from mail-vn0-f41.google.com (mail-vn0-f41.google.com [209.85.216.41]) (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 209A61A9218 for ; Tue, 28 Jul 2015 07:12:06 -0700 (PDT) Received: by vnaa140 with SMTP id a140so43317315vna.2 for ; Tue, 28 Jul 2015 07:12:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F+SqOkgSVHgfkjQeo0ybu0TG0SkvQNwZkcMo85hueI8=; b=ZSpInK1ulqc3wL+B4LDRLPkF8nexgIOuD9+GHJV5xsB0sws1iOIR9z9I1q4YhU3x3a QrcFxcaI3jvNAOh/JKpJJC64f/L0MdLs5ICaSAu2Jl+W+BKMd0F/jT9/2g740HLGKfXo Zv6LhAL+/UFv1pzWZbu6dW+t+GBpkvdTiIDNbOIskDYt1xFUHQ1UdAqnd3qaxX+b9zfi ybXhhrd1c46iuV88DfXS1IWK9ZmLZIe6EPNINLQtH9WWn0QwE+rsiIv4ovLzseJx3w8n DxS/woy+KjQ3zPigaQqLvut6Tx49axvceN6AJnYTmzkhVDk5lzCSG5DdlMkCbShSpzIl OfLg== X-Gm-Message-State: ALoCoQnCrc97ZbMpivrepCBg1p+IEC1lqcSkx2+6eENlO23+Saf7lzPmAKy1TUcWrPbGLDVifbrq MIME-Version: 1.0 X-Received: by 10.52.139.210 with SMTP id ra18mr44365085vdb.5.1438092725286; Tue, 28 Jul 2015 07:12:05 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Tue, 28 Jul 2015 07:12:05 -0700 (PDT) In-Reply-To: <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> Date: Tue, 28 Jul 2015 10:12:05 -0400 Message-ID: From: Richard Barnes To: "Gorman, Pierce A [CTO]" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "stir@ietf.org" , Alex Bobotek , Brian Rosen Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 14:12:21 -0000 On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] wrote: > "Large scale certificate management is expensive, and TN-specific certifi= cates are unneeded for securing calls placed by parties who choose to place= calls through a single reputable telephone service provider." > > Are you saying that for "on-net" calls, STIR methodology is unnecessary? This seems a little off-topic for this list. --Richard > > Best regards, > > > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > > > -----Original Message----- > From: Alex Bobotek [mailto:alex@bobotek.net] > Sent: July 27, 2015 11:36 PM > To: Brian Rosen ; Richard Barnes > Cc: stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy > > What motivation would a carrier have to choose any model other than carri= er signing using one of a very limited set of carrier-owned keys? Large sc= ale certificate management is expensive, and TN-specific certificates are u= nneeded for securing calls placed by parties who choose to place calls thro= ugh a single reputable telephone service provider. Anyone can get many cer= tificates, even a free ones anonymously from some issuers. It is typically= a combination of the strength of the end-user authentication performed by = the service provider (or certificate issuer in a provider-agnostic model) a= nd the identity's history that are most useful in security. > > If we're trying to secure the current telephone system, DNS-like key repo= sitories a la DKIM or perhaps a small number (compared to the number of TNs= ) of certificates are far more practical. > > Regards, > > Alex > >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >> Sent: Monday, July 27, 2015 7:40 PM >> To: Richard Barnes >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> What this means in practice is that it=E2=80=99s TN per cert. >> >> I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier to mai= ntain dozens >> of copies of millions of private keys securely, but it=E2=80=99s hard. = You >> need multiple copies because you have multiple elements that can >> initiate a call, and you don=E2=80=99t want to depend on a centralized >> resource to do something as basic as create a call. >> >> I think it=E2=80=99s hard enough that REQUIRING cert per TN is not accep= table. >> >> Folks with more intimate knowledge of carrier SIP infrastructure might >> have more insight than I do. It may be acceptable to have a >> centralized resource to manage millions of keys. >> >> Brian >> >> > On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >> > >> > After the STIR meeting in Prague, Henning and I spent a few minutes >> > talking through options for revocation checking and certificate >> > scoping, and I think we have a better idea of what the optimal >> > solution looks like. Some notes are below, and some slides with >> > pictures attached. >> > >> > tl;dr: We should: >> > * Keep TNs in certificates and not bother with any OCSP extensions >> > * Require Identity-Info to include OCSP responses for all certs in >> > the chain >> > >> > >> > # Background: Revocation in the web PKI >> > >> > In an HTTPS transaction, the HTTPS server provides the client with a >> > certificate, and it can optionally include an OCSP response ("staple" >> > it to the transaction). >> > >> > A certificate contains a validity interval, a key, and some names/TNs. >> > An OCSP responses contains a validity interval, a certificate ID >> > (i.e., a hash), and a status (good/revoked/unknown). In the web >> > PKI, certificates are required to be no more than 39 months long, >> > and OCSP responses no more than 10 days. >> > >> > Ideally, a client only considers a certificate valid if it is >> > accompanied by an OCSP response. In practice, this is not always >> > possible; because OCSP queries fail around 3% of the time, browsers >> > can't require OCSP. This operational fact will be important below, >> > but we will continue to have scoping cert lifetimes as an objective. >> > >> > In the web PKI, there are basically three revocation checking modaliti= es: >> > >> > 1. Live OCSP checking [RFC6069] >> > 2. OCSP stapling / must_staple [RFC6066, >> > draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >> > lifetime) >> > >> > (The last of these is relatively novel, and has not been deployed. >> > Neither has must-staple. But they're both pretty trivial, and could >> > be folded into a STIR architecture pretty easily.) >> > >> > Right now, about 90% of TLS transactions use live OCSP, and about 10%. >> > CAs and browsers dearly want the world to move toward stapled OCSP >> > or short-lived certs, because these reduces latency and improve the >> > quality of revocation information. >> > >> > Revocation for CA certificates is currently done by having browsers >> > download a list from a centralized server, since there's no way to >> > staple more than one OCSP response. That solution works OK for the >> > web, but if I were designing something de novo, I would probably use >> > multi-stapling as well. >> > >> > >> > # Applying this experience to STIR >> > >> > Most of the below appear to be desired properties by the WG: >> > >> > * Verifier neeeds to know that a cert is valid for a specific number >> > * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >> > issued longer) >> > * Caller privacy: Don't report what calls someone receives to a >> > central server >> > * Carrier privacy: Don't allow a third party to figure out all the >> > numbers a carrier holds >> > * Minimize the rate at which the CA has to sign things >> > * Tolerate outages at the CA >> > >> > I'm going to assume for now that we will not do live OCSP. It >> > violates the caller privacy requirement, and as discussed above, it >> > just sucks operationally. So STIR should require OCSP to be sent in >> > "stapled" form, which probably means sending it in Identity-Info. >> > And while we're at it, we should also do "multi-stapling" -- send an >> > OCSP response for CA certs as well. >> > >> > So if we consider a server with 50k TNs / blocks, that leaves us >> > with basically 3 options: >> > >> > 1. 50k short-lived certs (no OCSP) >> > 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 long-lived >> > cert not scoped to TN (or a few loosely scoped) + OCSP with TN info >> > >> > (As I didn't quite get to say in the meeting, regardless of the >> > approach, you have to have 50k of *something*.) Of these, it seems >> > like the preference order is 2 > 1 > 3. >> > >> > Option 3 is bad from several perspectives: >> > * Putting TN info in the OCSP response enables someone to trawl for >> > numbers unless you access-control the OCSP server, so you inherit a >> > requirement to do that. >> > * With the rate of churn in number assignments, you're probably >> > going to have to update the long-lived cert pretty frequently anyway. >> > * Putting TN-specific stuff in certs is better than putting it in >> > OCSP. As bad as X.509 libraries can be, OCSP libraries are much >> > worse. >> > >> > Option 1 is mainly bad from the perspective of CA load and outages. >> > With Option 2, if the CA goes down, client can continue to use the >> > long-lived cert and just not bother doing OCSP (vs. tolerating an >> > expired cert). Slightly cleaner. Plus, there's a lot more >> > experience caching OCSP than new certs. OCSP signing can also be >> > delegated, so you can have the recurring operation done by a lower-ris= k key. >> > >> > Option 2 should be pretty easy to automate. You can probably re-use >> > tooling for OCSP stapling that has already been developed for use >> > with HTTPS. If you're a big box signing for a bunch of numbers, you >> > do need to select the right cert and OCSP response for a given call, >> > but that's a pretty simple lookup table. >> > _______________________________________________ >> > 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 > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the s= ole use of the recipient(s). Any use by others is prohibited. If you are no= t the intended recipient, please contact the sender and delete all copies o= f the message. From nobody Tue Jul 28 07:14:14 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5D31A9176 for ; Tue, 28 Jul 2015 07:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 joK0TFZoDePS for ; Tue, 28 Jul 2015 07:14:10 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id B2C0E1A92E7 for ; Tue, 28 Jul 2015 07:14:08 -0700 (PDT) From: Henning Schulzrinne To: Richard Barnes , Alex Bobotek Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAH6+gIAAH4tA Date: Tue, 28 Jul 2015 14:14:00 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ipv.sx; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 5:nBucpTMxiUaedkccNoLp2GrGObS3nAqp/OnbGD8CgvGYg3Sv8GhfCiWdZTci4Yd9UD8vUp/yEUO40JTyMjwCD2RdbWBtMZfSj5tkqtFn2j3KmWVZrVB4vD4RatcJ4KQMG2Z+ukjinMwQWzZwWKbUqA==; 24:vpGtuW7EDrgq/+NhtYB2ydEJV1XTmJj9PlVEvXaDtg8CyvKgj7EMoo4WFaJpKkqH/CX9Dv7MujuSHR4D7UxaTw18EyUNZtZZq1sExT+6t90=; 20:Ybpy7HHi1dJOclq/NifVUG+4LvbqR+kbD5f1rBckXXzy9lL9HmtAySrmpm2xa9Gvx585uIyih82I0ATk/OeI/A== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:CY1PR09MB0633; cy1pr09mb0633: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(5003600100002)(77096005)(102836002)(5002640100001)(62966003)(189998001)(15975445007)(54356999)(40100003)(5001960100002)(76176999)(5001770100001)(2900100001)(5890100001)(92566002)(122556002)(19580395003)(77156002)(19580405001)(86362001)(50986999)(106116001)(99286002)(93886004)(76576001)(74316001)(33656002)(2656002)(2950100001)(19300405004)(19273905006)(551934003)(87936001)(15395725005)(66066001)(46102003)(134034003)(562404015)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2015 14:14:00.3471 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" , Brian Rosen Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 14:14:12 -0000 QXMgZmFyIGFzIEkgY2FuIHRlbGwsIG1hbmFnaW5nIGNlcnRzIGlzIG1hbmFnaW5nIGxvdHMgb2Yg YmxvYnMgb2Ygc3RhdGljIChhdCB0aGUgc2NhbGUgb2YgeWVhcnMpIGJpdHMuIEVhc3kgdG8gZG8g d2l0aCBhIGRhdGFiYXNlLiBGb3IgYSBuZXcgY2VydCwgZS5nLiwgYWZ0ZXIgYSBwb3J0LCBqdXN0 IGlzc3VlIGEgQ1NSLiBHZXQgYmFjayBjZXJ0IGZyb20gbmV4dC1oaWdoZXIgbGF5ZXIgKGUuZy4s IExOUEEgaW4gdGhlIFVTKS4gU3RvcmUgYmxvYiBpbiBkYXRhYmFzZSBhbmQgcmV0dXJuIHVwb24g cmVxdWVzdC4gU2luY2UgdGhpcyBpcyBhIHN0cmljdCBwcmltYXJ5IGtleSBsb29rdXAsIHVzZSB5 b3VyIGZhdm9yaXRlIG5vU1FMIGRhdGFiYXNlIGlmIHlvdSdyZSB3b3JyaWVkIGFib3V0IHNwZWVk IG9yIHNjYWxpbmcuDQoNCkZvciAxME0gY2VydHMsIHRoYXQncyB2ZXJ5IHJvdWdobHkgMTAgR0Ig b2Ygc3RvcmFnZS4gKEkgdXNlZCBodHRwOi8vZm00ZGQuY29tL29wZW5zc2wvY2VydGV4YW1wbGVz Lmh0bSBmb3IgdGhlIHNpemUgZXN0aW1hdGUuKQ0KDQpNb2RpZnkgdGltZSBzY2FsZXMgc2xpZ2h0 bHkgaWYgT0NTUCBzdGFwbGluZyBpcyBhZGRlZC4NCg0KSSB0aGluayB3ZSdsbCBtYWtlIG1vcmUg cHJvZ3Jlc3MgaWYgcGVvcGxlIGFyZSBzcGVjaWZpYyAtIHdoeSBpcyBzb21ldGhpbmcgaGFyZD8g Q29udmVyc2VseSwgaXMgdGhlcmUgZXhpc3RlbmNlIHByb29mIG9mIHNpbWlsYXIgc3lzdGVtcz8N Cg0KSGVubmluZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3RpciBbbWFp bHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQgQmFybmVzDQpT ZW50OiBUdWVzZGF5LCBKdWx5IDI4LCAyMDE1IDg6MTAgQU0NClRvOiBBbGV4IEJvYm90ZWsgPGFs ZXhAYm9ib3Rlay5uZXQ+DQpDYzogc3RpckBpZXRmLm9yZzsgQnJpYW4gUm9zZW4gPGJyQGJyaWFu cm9zZW4ubmV0Pg0KU3ViamVjdDogUmU6IFtzdGlyXSBPbiBPQ1NQLCBUTnMsIGFuZCBQcml2YWN5 DQoNCk9uIFR1ZSwgSnVsIDI4LCAyMDE1IGF0IDEyOjM2IEFNLCBBbGV4IEJvYm90ZWsgPGFsZXhA Ym9ib3Rlay5uZXQ+IHdyb3RlOg0KPiBXaGF0IG1vdGl2YXRpb24gd291bGQgYSBjYXJyaWVyIGhh dmUgdG8gY2hvb3NlIGFueSBtb2RlbCBvdGhlciB0aGFuIA0KPiBjYXJyaWVyIHNpZ25pbmcgdXNp bmcgb25lIG9mIGEgdmVyeSBsaW1pdGVkIHNldCBvZiBjYXJyaWVyLW93bmVkIGtleXM/ICANCj4g TGFyZ2Ugc2NhbGUgY2VydGlmaWNhdGUgbWFuYWdlbWVudCBpcyBleHBlbnNpdmUNCg0KQXMgSSBu b3RlZCB0byBCcmlhbiwga2V5IG1hbmFnZW1lbnQgIT0gY2VydCBtYW5hZ2VtZW50LiAgSWYgeW91 J3ZlIGdvdA0KNSBzaWduaW5nIGJveGVzIChlYWNoIHdpdGggaXQncyBvd24ga2V5IHBhaXIpIGFu ZCAxMDBrIFROcywgeW91IGNhbiBhbGxvY2F0ZSB0aG9zZSBUTnMgYW1vbmcgdGhlIHNpZ25pbmcg Ym94ZXMgaG93ZXZlciB5b3UgbGlrZSAtLSBpbmNsdWRpbmcgaXNzdWluZyBlYWNoIHNpZ25pbmcg Ym94IGEgc2V0IG9mIGNlcnRzIHRoYXQgY292ZXIgYWxsIDEwMGsgbnVtYmVycy4gIEtleSBtYW5h Z2VtZW50IGlzIGhhcmQuICBDZXJ0IG1hbmFnZW1lbnQgaXMgb25seSBhcyBoYXJkIGFzIHlvdSBu ZWVkIGl0IHRvIGJlLg0KDQpUaGUgYmVuZWZpdHMgb2YgIm9uZSBiaWcgY2VydCIgYXJlIGFsc28g aWxsdXNvcnkuICAgSWYgeW91J3JlIGdvaW5nIHRvDQpoYXZlIE4gY2hhbmdlcyBwZXIgd2VlayBp biB5b3VyIHNldCBvZiAxMDBrIFROcywgdGhlbiB5b3UncmUgZ29pbmcgdG8gaGF2ZSB0byByZXBs YWNlIHlvdXIgb25lIGJpZyBjZXJ0IE4gdGltZXMgcGVyIHdlZWsgYXMgd2VsbCBpZiB5b3UgZG9u J3Qgd2FudCB0byBsb3NlIGZpZGVsaXR5Lg0KDQoNCj4sIGFuZCBUTi1zcGVjaWZpYyBjZXJ0aWZp Y2F0ZXMgYXJlIHVubmVlZGVkIGZvciBzZWN1cmluZyBjYWxscyBwbGFjZWQgYnkgcGFydGllcyB3 aG8gY2hvb3NlIHRvIHBsYWNlIGNhbGxzIHRocm91Z2ggYSBzaW5nbGUgcmVwdXRhYmxlIHRlbGVw aG9uZSBzZXJ2aWNlIHByb3ZpZGVyLiAgQW55b25lIGNhbiBnZXQgbWFueSBjZXJ0aWZpY2F0ZXMs IGV2ZW4gYSBmcmVlIG9uZXMgYW5vbnltb3VzbHkgZnJvbSBzb21lIGlzc3VlcnMuICBJdCBpcyB0 eXBpY2FsbHkgYSBjb21iaW5hdGlvbiBvZiB0aGUgc3RyZW5ndGggb2YgdGhlIGVuZC11c2VyIGF1 dGhlbnRpY2F0aW9uIHBlcmZvcm1lZCBieSB0aGUgc2VydmljZSBwcm92aWRlciAob3IgY2VydGlm aWNhdGUgaXNzdWVyIGluIGEgcHJvdmlkZXItYWdub3N0aWMgbW9kZWwpIGFuZCB0aGUgaWRlbnRp dHkncyBoaXN0b3J5IHRoYXQgYXJlIG1vc3QgdXNlZnVsIGluIHNlY3VyaXR5Lg0KPg0KPiBJZiB3 ZSdyZSB0cnlpbmcgdG8gc2VjdXJlIHRoZSBjdXJyZW50IHRlbGVwaG9uZSBzeXN0ZW0sIEROUy1s aWtlIGtleSByZXBvc2l0b3JpZXMgYSBsYSBES0lNIG9yIHBlcmhhcHMgYSBzbWFsbCBudW1iZXIg KGNvbXBhcmVkIHRvIHRoZSBudW1iZXIgb2YgVE5zKSBvZiBjZXJ0aWZpY2F0ZXMgYXJlIGZhciBt b3JlIHByYWN0aWNhbC4NCg0KSG9uZXN0bHksIHRoaXMgc2VlbXMgbGlrZSBhIHByZXR0eSBoYW5k LXdhdnkgYXJndW1lbnQuICBNb2Rlcm4gd2ViIGhvc3RpbmcgcHJvdmlkZXJzIG1hbmFnZSBtYW55 IHRob3VzYW5kcyBvZiBjZXJ0aWZpY2F0ZXMsIGFuZCBtYW5hZ2UgdG8gaGF2ZSB0aGVpciBmcm9u dCBlbmQgc3lzdGVtcyBwaWNrIHRoZSByaWdodCBvbmVzLiAgQ2xvdWRGbGFyZSwgZm9yIGV4YW1w bGUsIGhhcyAyIG1pbGxpb24gZnJlZS10aWVyIHN1YnNjcmliZXJzIGZvciB3aG9tIHRoZXkgbWFu YWdlIGNlcnRpZmljYXRlcy4gIFRoZXkgYnVuZGxlIHN1YnNjcmliZXJzIDIwL2NlcnRpZmljYXRl LCBzbyB0aGF0J3MgMTAwayBjZXJ0aWZpY2F0ZXMgdGhleSdyZSBtYW5hZ2luZy4gIEdpdmVuIHRo YXQgdGhleSdyZSBwcm92aWRpbmcgdGhhdCBsZXZlbCBvZiBjZXJ0IG1hbmFnbWVudCBmb3IgdGhl aXIgKmZyZWUqIHRpZXIsIEkgaGF2ZSBhIGhhcmQgdGltZSBidXlpbmcgdGhlIGFyZ3VtZW50IHRo YXQgbWFuYWdpbmcgY2VydGlmaWNhdGVzIGlzIGluc2FuZWx5IGV4cGVuc2l2ZS4NCg0KLS1SaWNo YXJkDQoNCg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBBbGV4DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEJyaWFuIFJvc2VuDQo+PiBTZW50OiBNb25kYXksIEp1bHkgMjcsIDIwMTUg Nzo0MCBQTQ0KPj4gVG86IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4Pg0KPj4gQ2M6IHN0aXJA aWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBhbmQgUHJpdmFj eQ0KPj4NCj4+IFdoYXQgdGhpcyBtZWFucyBpbiBwcmFjdGljZSBpcyB0aGF0IGl04oCZcyBUTiBw ZXIgY2VydC4NCj4+DQo+PiBJIHdvdWxkbuKAmXQgc2F5IHRoYXQgaXTigJlzIGltcG9zc2libGUg Zm9yIGEgY2FycmllciB0byBtYWludGFpbiBkb3plbnMgDQo+PiBvZiBjb3BpZXMgb2YgbWlsbGlv bnMgb2YgcHJpdmF0ZSBrZXlzIHNlY3VyZWx5LCBidXQgaXTigJlzIGhhcmQuICBZb3UgDQo+PiBu ZWVkIG11bHRpcGxlIGNvcGllcyBiZWNhdXNlIHlvdSBoYXZlIG11bHRpcGxlIGVsZW1lbnRzIHRo YXQgY2FuIA0KPj4gaW5pdGlhdGUgYSBjYWxsLCBhbmQgeW91IGRvbuKAmXQgd2FudCB0byBkZXBl bmQgb24gYSBjZW50cmFsaXplZCANCj4+IHJlc291cmNlIHRvIGRvIHNvbWV0aGluZyBhcyBiYXNp YyBhcyBjcmVhdGUgYSBjYWxsLg0KPj4NCj4+IEkgdGhpbmsgaXTigJlzIGhhcmQgZW5vdWdoIHRo YXQgUkVRVUlSSU5HIGNlcnQgcGVyIFROIGlzIG5vdCBhY2NlcHRhYmxlLg0KPj4NCj4+IEZvbGtz IHdpdGggbW9yZSBpbnRpbWF0ZSBrbm93bGVkZ2Ugb2YgY2FycmllciBTSVAgaW5mcmFzdHJ1Y3R1 cmUgDQo+PiBtaWdodCBoYXZlIG1vcmUgaW5zaWdodCB0aGFuIEkgZG8uICBJdCBtYXkgYmUgYWNj ZXB0YWJsZSB0byBoYXZlIGEgDQo+PiBjZW50cmFsaXplZCByZXNvdXJjZSB0byBtYW5hZ2UgbWls bGlvbnMgb2Yga2V5cy4NCj4+DQo+PiBCcmlhbg0KPj4NCj4+ID4gT24gSnVsIDI3LCAyMDE1LCBh dCA2OjEzIFBNLCBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeD4gd3JvdGU6DQo+PiA+DQo+PiA+ IEFmdGVyIHRoZSBTVElSIG1lZXRpbmcgaW4gUHJhZ3VlLCBIZW5uaW5nIGFuZCBJIHNwZW50IGEg ZmV3IG1pbnV0ZXMgDQo+PiA+IHRhbGtpbmcgdGhyb3VnaCBvcHRpb25zIGZvciByZXZvY2F0aW9u IGNoZWNraW5nIGFuZCBjZXJ0aWZpY2F0ZSANCj4+ID4gc2NvcGluZywgYW5kIEkgdGhpbmsgd2Ug aGF2ZSBhIGJldHRlciBpZGVhIG9mIHdoYXQgdGhlIG9wdGltYWwgDQo+PiA+IHNvbHV0aW9uIGxv b2tzIGxpa2UuICBTb21lIG5vdGVzIGFyZSBiZWxvdywgYW5kIHNvbWUgc2xpZGVzIHdpdGggDQo+ PiA+IHBpY3R1cmVzIGF0dGFjaGVkLg0KPj4gPg0KPj4gPiB0bDtkcjogV2Ugc2hvdWxkOg0KPj4g PiAqIEtlZXAgVE5zIGluIGNlcnRpZmljYXRlcyBhbmQgbm90IGJvdGhlciB3aXRoIGFueSBPQ1NQ IGV4dGVuc2lvbnMNCj4+ID4gKiBSZXF1aXJlIElkZW50aXR5LUluZm8gdG8gaW5jbHVkZSBPQ1NQ IHJlc3BvbnNlcyBmb3IgYWxsIGNlcnRzIGluIA0KPj4gPiB0aGUgY2hhaW4NCj4+ID4NCj4+ID4N Cj4+ID4gIyBCYWNrZ3JvdW5kOiBSZXZvY2F0aW9uIGluIHRoZSB3ZWIgUEtJDQo+PiA+DQo+PiA+ IEluIGFuIEhUVFBTIHRyYW5zYWN0aW9uLCB0aGUgSFRUUFMgc2VydmVyIHByb3ZpZGVzIHRoZSBj bGllbnQgd2l0aCANCj4+ID4gYSBjZXJ0aWZpY2F0ZSwgYW5kIGl0IGNhbiBvcHRpb25hbGx5IGlu Y2x1ZGUgYW4gT0NTUCByZXNwb25zZSAoInN0YXBsZSINCj4+ID4gaXQgdG8gdGhlIHRyYW5zYWN0 aW9uKS4NCj4+ID4NCj4+ID4gQSBjZXJ0aWZpY2F0ZSBjb250YWlucyBhIHZhbGlkaXR5IGludGVy dmFsLCBhIGtleSwgYW5kIHNvbWUgbmFtZXMvVE5zLg0KPj4gPiBBbiBPQ1NQIHJlc3BvbnNlcyBj b250YWlucyBhIHZhbGlkaXR5IGludGVydmFsLCBhIGNlcnRpZmljYXRlIElEIA0KPj4gPiAoaS5l LiwgYSBoYXNoKSwgYW5kIGEgc3RhdHVzIChnb29kL3Jldm9rZWQvdW5rbm93bikuICBJbiB0aGUg d2ViIA0KPj4gPiBQS0ksIGNlcnRpZmljYXRlcyBhcmUgcmVxdWlyZWQgdG8gYmUgbm8gbW9yZSB0 aGFuIDM5IG1vbnRocyBsb25nLCANCj4+ID4gYW5kIE9DU1AgcmVzcG9uc2VzIG5vIG1vcmUgdGhh biAxMCBkYXlzLg0KPj4gPg0KPj4gPiBJZGVhbGx5LCBhIGNsaWVudCBvbmx5IGNvbnNpZGVycyBh IGNlcnRpZmljYXRlIHZhbGlkIGlmIGl0IGlzIA0KPj4gPiBhY2NvbXBhbmllZCBieSBhbiBPQ1NQ IHJlc3BvbnNlLiAgSW4gcHJhY3RpY2UsIHRoaXMgaXMgbm90IGFsd2F5cyANCj4+ID4gcG9zc2li bGU7IGJlY2F1c2UgT0NTUCBxdWVyaWVzIGZhaWwgYXJvdW5kIDMlIG9mIHRoZSB0aW1lLCBicm93 c2VycyANCj4+ID4gY2FuJ3QgcmVxdWlyZSBPQ1NQLiAgVGhpcyBvcGVyYXRpb25hbCBmYWN0IHdp bGwgYmUgaW1wb3J0YW50IGJlbG93LCANCj4+ID4gYnV0IHdlIHdpbGwgY29udGludWUgdG8gaGF2 ZSBzY29waW5nIGNlcnQgbGlmZXRpbWVzIGFzIGFuIG9iamVjdGl2ZS4NCj4+ID4NCj4+ID4gSW4g dGhlIHdlYiBQS0ksIHRoZXJlIGFyZSBiYXNpY2FsbHkgdGhyZWUgcmV2b2NhdGlvbiBjaGVja2lu ZyBtb2RhbGl0aWVzOg0KPj4gPg0KPj4gPiAxLiBMaXZlIE9DU1AgY2hlY2tpbmcgW1JGQzYwNjld DQo+PiA+IDIuIE9DU1Agc3RhcGxpbmcgLyBtdXN0X3N0YXBsZSBbUkZDNjA2NiwgDQo+PiA+IGRy YWZ0LWhhbGxhbWJha2VyLXRsc2ZlYXR1cmVdIDMuIFNob3J0LWxpdmVkIGNlcnRpZmljYXRlcyAo fk9DU1AgDQo+PiA+IGxpZmV0aW1lKQ0KPj4gPg0KPj4gPiAoVGhlIGxhc3Qgb2YgdGhlc2UgaXMg cmVsYXRpdmVseSBub3ZlbCwgYW5kIGhhcyBub3QgYmVlbiBkZXBsb3llZC4NCj4+ID4gTmVpdGhl ciBoYXMgbXVzdC1zdGFwbGUuICBCdXQgdGhleSdyZSBib3RoIHByZXR0eSB0cml2aWFsLCBhbmQg DQo+PiA+IGNvdWxkIGJlIGZvbGRlZCBpbnRvIGEgU1RJUiBhcmNoaXRlY3R1cmUgcHJldHR5IGVh c2lseS4pDQo+PiA+DQo+PiA+IFJpZ2h0IG5vdywgYWJvdXQgOTAlIG9mIFRMUyB0cmFuc2FjdGlv bnMgdXNlIGxpdmUgT0NTUCwgYW5kIGFib3V0IDEwJS4NCj4+ID4gQ0FzIGFuZCBicm93c2VycyBk ZWFybHkgd2FudCB0aGUgd29ybGQgdG8gbW92ZSB0b3dhcmQgc3RhcGxlZCBPQ1NQIA0KPj4gPiBv ciBzaG9ydC1saXZlZCBjZXJ0cywgYmVjYXVzZSB0aGVzZSByZWR1Y2VzIGxhdGVuY3kgYW5kIGlt cHJvdmUgdGhlIA0KPj4gPiBxdWFsaXR5IG9mIHJldm9jYXRpb24gaW5mb3JtYXRpb24uDQo+PiA+ DQo+PiA+IFJldm9jYXRpb24gZm9yIENBIGNlcnRpZmljYXRlcyBpcyBjdXJyZW50bHkgZG9uZSBi eSBoYXZpbmcgYnJvd3NlcnMgDQo+PiA+IGRvd25sb2FkIGEgbGlzdCBmcm9tIGEgY2VudHJhbGl6 ZWQgc2VydmVyLCBzaW5jZSB0aGVyZSdzIG5vIHdheSB0byANCj4+ID4gc3RhcGxlIG1vcmUgdGhh biBvbmUgT0NTUCByZXNwb25zZS4gIFRoYXQgc29sdXRpb24gd29ya3MgT0sgZm9yIHRoZSANCj4+ ID4gd2ViLCBidXQgaWYgSSB3ZXJlIGRlc2lnbmluZyBzb21ldGhpbmcgZGUgbm92bywgSSB3b3Vs ZCBwcm9iYWJseSANCj4+ID4gdXNlIG11bHRpLXN0YXBsaW5nIGFzIHdlbGwuDQo+PiA+DQo+PiA+ DQo+PiA+ICMgQXBwbHlpbmcgdGhpcyBleHBlcmllbmNlIHRvIFNUSVINCj4+ID4NCj4+ID4gTW9z dCBvZiB0aGUgYmVsb3cgYXBwZWFyIHRvIGJlIGRlc2lyZWQgcHJvcGVydGllcyBieSB0aGUgV0c6 DQo+PiA+DQo+PiA+ICogVmVyaWZpZXIgbmVlZWRzIHRvIGtub3cgdGhhdCBhIGNlcnQgaXMgdmFs aWQgZm9yIGEgc3BlY2lmaWMgDQo+PiA+IG51bWJlcg0KPj4gPiAqIFNjb3BlZCBjZXJ0IGxpZmV0 aW1lOiBMaW1pdCBjZXJ0cyB0byB+MXdlZWsgbGlmZXRpbWUgKGJ5IE9DU1AgaWYgDQo+PiA+IGlz c3VlZCBsb25nZXIpDQo+PiA+ICogQ2FsbGVyIHByaXZhY3k6IERvbid0IHJlcG9ydCB3aGF0IGNh bGxzIHNvbWVvbmUgcmVjZWl2ZXMgdG8gYSANCj4+ID4gY2VudHJhbCBzZXJ2ZXINCj4+ID4gKiBD YXJyaWVyIHByaXZhY3k6IERvbid0IGFsbG93IGEgdGhpcmQgcGFydHkgdG8gZmlndXJlIG91dCBh bGwgdGhlIA0KPj4gPiBudW1iZXJzIGEgY2FycmllciBob2xkcw0KPj4gPiAqIE1pbmltaXplIHRo ZSByYXRlIGF0IHdoaWNoIHRoZSBDQSBoYXMgdG8gc2lnbiB0aGluZ3MNCj4+ID4gKiBUb2xlcmF0 ZSBvdXRhZ2VzIGF0IHRoZSBDQQ0KPj4gPg0KPj4gPiBJJ20gZ29pbmcgdG8gYXNzdW1lIGZvciBu b3cgdGhhdCB3ZSB3aWxsIG5vdCBkbyBsaXZlIE9DU1AuICBJdCANCj4+ID4gdmlvbGF0ZXMgdGhl IGNhbGxlciBwcml2YWN5IHJlcXVpcmVtZW50LCBhbmQgYXMgZGlzY3Vzc2VkIGFib3ZlLCBpdCAN Cj4+ID4ganVzdCBzdWNrcyBvcGVyYXRpb25hbGx5LiAgU28gU1RJUiBzaG91bGQgcmVxdWlyZSBP Q1NQIHRvIGJlIHNlbnQgDQo+PiA+IGluICJzdGFwbGVkIiBmb3JtLCB3aGljaCBwcm9iYWJseSBt ZWFucyBzZW5kaW5nIGl0IGluIA0KPj4gPiBJZGVudGl0eS1JbmZvLiAgQW5kIHdoaWxlIHdlJ3Jl IGF0IGl0LCB3ZSBzaG91bGQgYWxzbyBkbyANCj4+ID4gIm11bHRpLXN0YXBsaW5nIiAtLSBzZW5k IGFuIE9DU1AgcmVzcG9uc2UgZm9yIENBIGNlcnRzIGFzIHdlbGwuDQo+PiA+DQo+PiA+IFNvIGlm IHdlIGNvbnNpZGVyIGEgc2VydmVyIHdpdGggNTBrIFROcyAvIGJsb2NrcywgdGhhdCBsZWF2ZXMg dXMgDQo+PiA+IHdpdGggYmFzaWNhbGx5IDMgb3B0aW9uczoNCj4+ID4NCj4+ID4gMS4gNTBrIHNo b3J0LWxpdmVkIGNlcnRzIChubyBPQ1NQKQ0KPj4gPiAyLiA1MGsgbG9uZy1saXZlZCBjZXJ0cyBz Y29wZWQgdG8gVE5zICsgZ2VuZXJpYyBPQ1NQIDMuIDEgDQo+PiA+IGxvbmctbGl2ZWQgY2VydCBu b3Qgc2NvcGVkIHRvIFROIChvciBhIGZldyBsb29zZWx5IHNjb3BlZCkgKyBPQ1NQIA0KPj4gPiB3 aXRoIFROIGluZm8NCj4+ID4NCj4+ID4gKEFzIEkgZGlkbid0IHF1aXRlIGdldCB0byBzYXkgaW4g dGhlIG1lZXRpbmcsIHJlZ2FyZGxlc3Mgb2YgdGhlIA0KPj4gPiBhcHByb2FjaCwgeW91IGhhdmUg dG8gaGF2ZSA1MGsgb2YgKnNvbWV0aGluZyouKSAgT2YgdGhlc2UsIGl0IHNlZW1zIA0KPj4gPiBs aWtlIHRoZSBwcmVmZXJlbmNlIG9yZGVyIGlzIDIgPiAxID4gMy4NCj4+ID4NCj4+ID4gT3B0aW9u IDMgaXMgYmFkIGZyb20gc2V2ZXJhbCBwZXJzcGVjdGl2ZXM6DQo+PiA+ICogUHV0dGluZyBUTiBp bmZvIGluIHRoZSBPQ1NQIHJlc3BvbnNlIGVuYWJsZXMgc29tZW9uZSB0byB0cmF3bCBmb3IgDQo+ PiA+IG51bWJlcnMgdW5sZXNzIHlvdSBhY2Nlc3MtY29udHJvbCB0aGUgT0NTUCBzZXJ2ZXIsIHNv IHlvdSBpbmhlcml0IGEgDQo+PiA+IHJlcXVpcmVtZW50IHRvIGRvIHRoYXQuDQo+PiA+ICogV2l0 aCB0aGUgcmF0ZSBvZiBjaHVybiBpbiBudW1iZXIgYXNzaWdubWVudHMsIHlvdSdyZSBwcm9iYWJs eSANCj4+ID4gZ29pbmcgdG8gaGF2ZSB0byB1cGRhdGUgdGhlIGxvbmctbGl2ZWQgY2VydCBwcmV0 dHkgZnJlcXVlbnRseSBhbnl3YXkuDQo+PiA+ICogUHV0dGluZyBUTi1zcGVjaWZpYyBzdHVmZiBp biBjZXJ0cyBpcyBiZXR0ZXIgdGhhbiBwdXR0aW5nIGl0IGluIA0KPj4gPiBPQ1NQLiAgQXMgYmFk IGFzIFguNTA5IGxpYnJhcmllcyBjYW4gYmUsIE9DU1AgbGlicmFyaWVzIGFyZSBtdWNoIA0KPj4g PiB3b3JzZS4NCj4+ID4NCj4+ID4gT3B0aW9uIDEgaXMgbWFpbmx5IGJhZCBmcm9tIHRoZSBwZXJz cGVjdGl2ZSBvZiBDQSBsb2FkIGFuZCBvdXRhZ2VzLg0KPj4gPiBXaXRoIE9wdGlvbiAyLCBpZiB0 aGUgQ0EgZ29lcyBkb3duLCBjbGllbnQgY2FuIGNvbnRpbnVlIHRvIHVzZSB0aGUgDQo+PiA+IGxv bmctbGl2ZWQgY2VydCBhbmQganVzdCBub3QgYm90aGVyIGRvaW5nIE9DU1AgKHZzLiB0b2xlcmF0 aW5nIGFuIA0KPj4gPiBleHBpcmVkIGNlcnQpLiAgU2xpZ2h0bHkgY2xlYW5lci4gIFBsdXMsIHRo ZXJlJ3MgYSBsb3QgbW9yZSANCj4+ID4gZXhwZXJpZW5jZSBjYWNoaW5nIE9DU1AgdGhhbiBuZXcg Y2VydHMuICBPQ1NQIHNpZ25pbmcgY2FuIGFsc28gYmUgDQo+PiA+IGRlbGVnYXRlZCwgc28geW91 IGNhbiBoYXZlIHRoZSByZWN1cnJpbmcgb3BlcmF0aW9uIGRvbmUgYnkgYSBsb3dlci1yaXNrIGtl eS4NCj4+ID4NCj4+ID4gT3B0aW9uIDIgc2hvdWxkIGJlIHByZXR0eSBlYXN5IHRvIGF1dG9tYXRl LiAgWW91IGNhbiBwcm9iYWJseSANCj4+ID4gcmUtdXNlIHRvb2xpbmcgZm9yIE9DU1Agc3RhcGxp bmcgdGhhdCBoYXMgYWxyZWFkeSBiZWVuIGRldmVsb3BlZCANCj4+ID4gZm9yIHVzZSB3aXRoIEhU VFBTLiAgSWYgeW91J3JlIGEgYmlnIGJveCBzaWduaW5nIGZvciBhIGJ1bmNoIG9mIA0KPj4gPiBu dW1iZXJzLCB5b3UgZG8gbmVlZCB0byBzZWxlY3QgdGhlIHJpZ2h0IGNlcnQgYW5kIE9DU1AgcmVz cG9uc2UgZm9yIA0KPj4gPiBhIGdpdmVuIGNhbGwsIGJ1dCB0aGF0J3MgYSBwcmV0dHkgc2ltcGxl IGxvb2t1cCB0YWJsZS4NCj4+ID4gPFNUSVIucHB0eD5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiBzdGlyIG1haWxpbmcgbGlzdA0KPj4gPiBzdGly QGlldGYub3JnDQo+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rp cg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBzdGlyIG1haWxpbmcgbGlzdA0KPj4gc3RpckBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzdGlyIG1haWxpbmcgbGlzdA0Kc3RpckBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo= From nobody Tue Jul 28 07:14:40 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343DC1A92F1 for ; Tue, 28 Jul 2015 07:14:39 -0700 (PDT) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 giSwY5lKuCHe for ; Tue, 28 Jul 2015 07:14:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C745F1A92E9 for ; Tue, 28 Jul 2015 07:14:35 -0700 (PDT) Received: from BN1AFFO11FD033.protection.gbl (10.58.52.32) by BN1AFFO11HUB025.protection.gbl (10.58.52.135) with Microsoft SMTP Server (TLS) id 15.1.231.11; Tue, 28 Jul 2015 14:14:27 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com; Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BN1AFFO11FD033.mail.protection.outlook.com (10.58.52.246) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Tue, 28 Jul 2015 14:14:27 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6SECMoe024587; Tue, 28 Jul 2015 09:14:27 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm1.corp.sprint.com with ESMTP id 1vv83kn7fh-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2015 09:14:27 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 28 Jul 2015 10:14:25 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Tue, 28 Jul 2015 09:14:25 -0500 From: "Gorman, Pierce A [CTO]" To: Richard Barnes Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3w5jYQgABaDoD//6yTMA== Date: Tue, 28 Jul 2015 14:14:24 +0000 Message-ID: <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD033; 1:s/Uh7cXB0Jw7JllrBSMEtdvEsuEFV9WksLttdL9cR8GL6fa1X9vAPV+3Axd+7YFy5ZrUuYZ3+pf0dDrlcVra0yj2jmx6NhlTrsF8MdchaSlm1Z493nj7VtsjEmDHnfN/PbKlqVe0n8hmr1sDJkwqWeo47P99i52zpMROWGq65T4DxNPAeCe6cPv3AcsUOQ2JpiVg9nw/eKuw9Xt87hK4kq5O7P4WepYBDRIiA8YZSn7LxOrocDrZnHBNCnEPASsH3MMLdonE7IICO/8TuMsaZXjlzML05OfdSKKmFNKFxgs4BMlfzhakGKBeXcduM2yr X-Forefront-Antispam-Report: CIP:144.230.172.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(377454003)(24454002)(189002)(13464003)(551934003)(33646002)(19580405001)(19580395003)(76176999)(86362001)(5001960100002)(87936001)(50986999)(2656002)(47776003)(6806004)(110136002)(46102003)(5890100001)(15975445007)(2950100001)(2900100001)(92566002)(102836002)(23676002)(77156002)(189998001)(93886004)(54356999)(5003600100002)(62966003)(108616004)(106116001)(24736003)(106466001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB025; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB025; 2:mP0Z9iQp0V0GvmoQJjDmb81dnlnqWWK3fq6akji02uF0lAi//5NVWp2GAGvrP/PomAyH36Xi+DxS7HCWbQ/zhBNqbaldfk8vS2pXaAiKQSe7wVGPdqr/rWb8PmEHOBfTOvS/N8KkQh0Apew3QZYlffJvAr3bLU+ByzYsVg/Wu8o=; 3:JDKfOfe+e4+5c5z6+jlRELdKNXYZGmQ18bHxQWhs638Xf5nQFX+ojtLQe2V57n8E9oI6/onaddxXqN8d4qLClYqVmbpK3xlBLpjFHtQ3f1IvRNGsjiLF31hmo7gQmD1wy49NkFc7oozCDmVihuUU2PKCik3fRU0OfWcjuyeIJp/4FIL91dVY/OlZ1p87rl1Dkz3zog0wb473GhynMuLTDNT8KBHlyyw6YjcCRqVGsMwPujy2I2M65aD0SBl8ldTe; 25:FMLwm7r6FVc2KwF6i3x8KhURSvshXlaqcu3qPlbZG/QQqmFRX5DzGtN+GDZ6zC9UAGQ35c2jm0f3kMyBe3wGVINrUJwDd2WKQ8CMahuvmcvBgN0cSiTCb2flXG43AVQ6WK4/0XrfZtz3m7/Nue6x70E2dNOqtpUiRx0MIxLF5lBqkaflTD0hDaS6yl+RcR5T2QKrIi5eryrxMMobQ+y2VBmjU4SbnbVCSgenQtCysYSKQNCzPqHd2Y3KQEg7y5JKtMZpeF5KzG6N3tpcFE+AtQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB025; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB025; 20:HI+Sc2Y2v1mZRpcCuwlr7a2g08fTvfSBhnZlet4HGk7XMuaWooIyQe2H/BPUF2KFd2X6hAO2FElfxx9m0HQYtUNnkwIY/IvRLo2ywQFJR4dE9a1MoR2KqZJm+I7ERgh6C2zgIREqj+c3zQCFUrLuXTSenuG9cr0KV13bKPM4hTxlGG1hknt42KqmpiXvJ6/CqBbtY8AyQMZ0LpPWS5wxcYd3G0UXTtWMjBZ+95D+K3kuA4St2QuqL9o2i/9Y067e; 4:xNGFi9iOlfXXMF23ETKTphecqoEPZuavL/lePAX4O9yacJByquw1moggIHLbZWCqu8shGLGuvrvPh4jBwjFg8ejWAgcOLTzbkuEhPIwGevh3mnHhpOLwUD9MMIkn1xWVY+QA6sJj1OTuvzMJXbV5P1aGxdnlpiL4C/zR3C4Hq6uexMo1zndnsDC4HxWwvG1Br6Tuny3irT1ExRHsATvPqcOEnia9jUs74k/soC8oKYYyJm/9uGuVuw2HuJZtQpuiWmsWYlwGRgqGIRpcRN8DKwU3ZYQ/0rC6VqlSfHj1Ues= BN1AFFO11HUB025: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1AFFO11HUB025; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB025; X-Forefront-PRVS: 06515DA04B X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFBRkZPMTFIVUIwMjU7MjM6dElFNjBqY05kMDB1VlF2YktWTTJYUHVs?= =?utf-8?B?Uk1WZDgvWk1UT3ZROUZkNjRwS05pVnZsOHFLK2NCakcrRkxyNnpxVXdJUTRF?= =?utf-8?B?NXdTc1UxcFhpK3lDdW1wamcxbHhhanh3MzQyYlNkTFBDdmhrZkQ2eEw0TmxY?= =?utf-8?B?N282RDY0dXg2WG1jZDN0UmUweGFDUTAzcU5GRG5pQ2tWamloajNNSG50dnYy?= =?utf-8?B?dXhCYTVHUnB5L01CUmtvTW5iWUxnY0NDTWo5dzFJUUFjUEZBNDh6RllYZURx?= =?utf-8?B?Q0MzSmZKbFVjTW1pQXlIaVRpcXRsWXQzT2xQVXlZaSttbzdGSzAzc3dnM2x5?= =?utf-8?B?Ti9vQlpTektreUROMzFGYWJyLzQyRVZZZDRvU0x6ZzVOWFZLeXdmNGFmZ0Nr?= =?utf-8?B?RXl3UVI2dlgrallCQVJJQmd1ODM0d0NsZXI3TXI5NGVETTNhNU5oYmVFd1Q3?= =?utf-8?B?c29iWjVTMExYVDJlWlllNHcrSENOSlZyNzF6bUYzcWU2cDhaR2thUGdXeHJk?= =?utf-8?B?MllhSzE4OXhkblpCQll0RUhDRDFDSkQxQ0MvOGFrczVybDFRWGJLSTNHSWdz?= =?utf-8?B?cDdEZExBQWg4NXprbmMxbm0yajl5VDNHZEtPZEpIT1BqNVlHeExHTHJBSk95?= =?utf-8?B?SGNlNFhHQ2tUN3V3T1JBS0VmZytIN281NmJMMFo2Q3J5M3Z4M0R1dndodDkr?= =?utf-8?B?aTAvcXErRDhZZHU4UXBMeHRlMjlxTkRZY3hjcU1Ea2dtRFFKVlZrczRNZk9y?= =?utf-8?B?QTNvaSt1bjlNaUlZV0lOT0laenZlTzdsWSt4bDRsWGU4MG5Da1hjQjhVeEpu?= =?utf-8?B?SWZNZ2hrOEo3NGhEeVFQUnlTcnhRS05ONEZwZzRzSW1DY3VwMk5kdVNLOGhk?= =?utf-8?B?aW5HWjhkRU9sN1BpV1V5NTlOTkRualVFMW9xanExZ1dyQVNXdFdPeXRadURC?= =?utf-8?B?WjZBTkRmbHJkcUdRNUlCZFU2anZaQXNyZjA0a0E5WlRadDdzQnNxU3k2aVBp?= =?utf-8?B?cXQ0K0FUaFZWdHVPWHFadWcvUi9DSjA4eTVmSTJSUzQvVmRRSEdiQ3cyeDdZ?= =?utf-8?B?UjV0OHhtOCtZVWVaYk8zL0QvcnBkNW9SNkFoTDJ5SExjYktEU2dRZ2F3ME1t?= =?utf-8?B?ZklIcjdsRkxIbENiVHpLZnhRaUlmUHpER0ovZkcxZUNWd0VqUFU3dHI1R0Jn?= =?utf-8?B?UzdITkpvWXQwVS82a0F3ditQQjNCUXlsT3dtSG10Q0k2VVB6VElzYldHRWZZ?= =?utf-8?B?Y1Y1RGxSSTN6ZllxU3lVWm5SZ0pqdEg4aVVjTUxCNzNNQlMwTnhvNGNVb0xz?= =?utf-8?B?YVNWeEZnV1U1eDVWNnA3YTd0bDdQaS9PTkpoNWxOQ0NiQkRXSVhaTHlzUWZN?= =?utf-8?B?dm9GVXNnM1JUcE5HdG5IV1dVUHhtY2lGNFBrbklmNmc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB025; 5:AZc33P0KP+sYfl+jr4vWngLS0Qq0bqrexbp323T7nxQ40D/RMY9tljG+5cT4ICQJ0ZAgF9dNvbNjQBkkG1l4waMVcy9S9wDsLoDc1uow4MJbaW//SkR5/NHaZHx0p2L6XfPLyOH9+LsBlKrDAnpO2w==; 24:wavJHn3RowHNh4aN+DqDwvOoZioaCW24z8TzZ4/aK1BEva7oM+Fx16QCH736yizHQUoffzsn4CzWlvstR+vgmZoYgIbmaQ0sTZw6MGobT/w= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2015 14:14:27.3156 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB025 Archived-At: Cc: "stir@ietf.org" , Alex Bobotek , Brian Rosen Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 14:14:39 -0000 SSB0aG91Z2h0IHRoZSBkaXNjdXNzaW9uIHdhcyBvbiBrZXkvY2VydCBtYW5hZ2VtZW50LiAgSSdt IGFza2luZyBpZiBJIHVuZGVyc3Rvb2QgdGhlIHN1Z2dlc3Rpb24gdG8gbWluaW1pemUgcmVxdWly ZW1lbnRzLiAgSG93IGlzIHRoYXQgb2ZmIHRvcGljPw0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KUGll cmNlIEdvcm1hbg0KQ29yZSBOZXR3b3JrIFBsYW5uaW5nDQpPOiA5MTMtNDM5LTQzNjgNCnBpZXJj ZS5nb3JtYW5Ac3ByaW50LmNvbQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBSaWNoYXJkIEJhcm5lcyBbbWFpbHRvOnJsYkBpcHYuc3hdDQpTZW50OiBKdWx5IDI4LCAyMDE1 IDk6MTIgQU0NClRvOiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dIDxQaWVyY2UuR29ybWFuQHNwcmlu dC5jb20+DQpDYzogQWxleCBCb2JvdGVrIDxhbGV4QGJvYm90ZWsubmV0PjsgQnJpYW4gUm9zZW4g PGJyQGJyaWFucm9zZW4ubmV0Pjsgc3RpckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzdGlyXSBP biBPQ1NQLCBUTnMsIGFuZCBQcml2YWN5DQoNCk9uIFR1ZSwgSnVsIDI4LCAyMDE1IGF0IDk6NTEg QU0sIEdvcm1hbiwgUGllcmNlIEEgW0NUT10gPFBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbT4gd3Jv dGU6DQo+ICJMYXJnZSBzY2FsZSBjZXJ0aWZpY2F0ZSBtYW5hZ2VtZW50IGlzIGV4cGVuc2l2ZSwg YW5kIFROLXNwZWNpZmljIGNlcnRpZmljYXRlcyBhcmUgdW5uZWVkZWQgZm9yIHNlY3VyaW5nIGNh bGxzIHBsYWNlZCBieSBwYXJ0aWVzIHdobyBjaG9vc2UgdG8gcGxhY2UgY2FsbHMgdGhyb3VnaCBh IHNpbmdsZSByZXB1dGFibGUgdGVsZXBob25lIHNlcnZpY2UgcHJvdmlkZXIuIg0KPg0KPiBBcmUg eW91IHNheWluZyB0aGF0IGZvciAib24tbmV0IiBjYWxscywgU1RJUiBtZXRob2RvbG9neSBpcyB1 bm5lY2Vzc2FyeT8NCg0KVGhpcyBzZWVtcyBhIGxpdHRsZSBvZmYtdG9waWMgZm9yIHRoaXMgbGlz dC4NCg0KLS1SaWNoYXJkDQoNCj4NCj4gQmVzdCByZWdhcmRzLA0KPg0KPg0KPiBQaWVyY2UgR29y bWFuDQo+IENvcmUgTmV0d29yayBQbGFubmluZw0KPiBPOiA5MTMtNDM5LTQzNjgNCj4gcGllcmNl Lmdvcm1hbkBzcHJpbnQuY29tDQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IEFsZXggQm9ib3RlayBbbWFpbHRvOmFsZXhAYm9ib3Rlay5uZXRdDQo+IFNlbnQ6IEp1 bHkgMjcsIDIwMTUgMTE6MzYgUE0NCj4gVG86IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5l dD47IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4Pg0KPiBDYzogc3RpckBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW3N0aXJdIE9uIE9DU1AsIFROcywgYW5kIFByaXZhY3kNCj4NCj4gV2hhdCBt b3RpdmF0aW9uIHdvdWxkIGEgY2FycmllciBoYXZlIHRvIGNob29zZSBhbnkgbW9kZWwgb3RoZXIg dGhhbiBjYXJyaWVyIHNpZ25pbmcgdXNpbmcgb25lIG9mIGEgdmVyeSBsaW1pdGVkIHNldCBvZiBj YXJyaWVyLW93bmVkIGtleXM/ICBMYXJnZSBzY2FsZSBjZXJ0aWZpY2F0ZSBtYW5hZ2VtZW50IGlz IGV4cGVuc2l2ZSwgYW5kIFROLXNwZWNpZmljIGNlcnRpZmljYXRlcyBhcmUgdW5uZWVkZWQgZm9y IHNlY3VyaW5nIGNhbGxzIHBsYWNlZCBieSBwYXJ0aWVzIHdobyBjaG9vc2UgdG8gcGxhY2UgY2Fs bHMgdGhyb3VnaCBhIHNpbmdsZSByZXB1dGFibGUgdGVsZXBob25lIHNlcnZpY2UgcHJvdmlkZXIu ICBBbnlvbmUgY2FuIGdldCBtYW55IGNlcnRpZmljYXRlcywgZXZlbiBhIGZyZWUgb25lcyBhbm9u eW1vdXNseSBmcm9tIHNvbWUgaXNzdWVycy4gIEl0IGlzIHR5cGljYWxseSBhIGNvbWJpbmF0aW9u IG9mIHRoZSBzdHJlbmd0aCBvZiB0aGUgZW5kLXVzZXIgYXV0aGVudGljYXRpb24gcGVyZm9ybWVk IGJ5IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIChvciBjZXJ0aWZpY2F0ZSBpc3N1ZXIgaW4gYSBwcm92 aWRlci1hZ25vc3RpYyBtb2RlbCkgYW5kIHRoZSBpZGVudGl0eSdzIGhpc3RvcnkgdGhhdCBhcmUg bW9zdCB1c2VmdWwgaW4gc2VjdXJpdHkuDQo+DQo+IElmIHdlJ3JlIHRyeWluZyB0byBzZWN1cmUg dGhlIGN1cnJlbnQgdGVsZXBob25lIHN5c3RlbSwgRE5TLWxpa2Uga2V5IHJlcG9zaXRvcmllcyBh IGxhIERLSU0gb3IgcGVyaGFwcyBhIHNtYWxsIG51bWJlciAoY29tcGFyZWQgdG8gdGhlIG51bWJl ciBvZiBUTnMpIG9mIGNlcnRpZmljYXRlcyBhcmUgZmFyIG1vcmUgcHJhY3RpY2FsLg0KPg0KPiBS ZWdhcmRzLA0KPg0KPiBBbGV4DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJy aWFuIFJvc2VuDQo+PiBTZW50OiBNb25kYXksIEp1bHkgMjcsIDIwMTUgNzo0MCBQTQ0KPj4gVG86 IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4Pg0KPj4gQ2M6IHN0aXJAaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBhbmQgUHJpdmFjeQ0KPj4NCj4+IFdoYXQg dGhpcyBtZWFucyBpbiBwcmFjdGljZSBpcyB0aGF0IGl04oCZcyBUTiBwZXIgY2VydC4NCj4+DQo+ PiBJIHdvdWxkbuKAmXQgc2F5IHRoYXQgaXTigJlzIGltcG9zc2libGUgZm9yIGEgY2FycmllciB0 byBtYWludGFpbiBkb3plbnMNCj4+IG9mIGNvcGllcyBvZiBtaWxsaW9ucyBvZiBwcml2YXRlIGtl eXMgc2VjdXJlbHksIGJ1dCBpdOKAmXMgaGFyZC4gIFlvdQ0KPj4gbmVlZCBtdWx0aXBsZSBjb3Bp ZXMgYmVjYXVzZSB5b3UgaGF2ZSBtdWx0aXBsZSBlbGVtZW50cyB0aGF0IGNhbg0KPj4gaW5pdGlh dGUgYSBjYWxsLCBhbmQgeW91IGRvbuKAmXQgd2FudCB0byBkZXBlbmQgb24gYSBjZW50cmFsaXpl ZA0KPj4gcmVzb3VyY2UgdG8gZG8gc29tZXRoaW5nIGFzIGJhc2ljIGFzIGNyZWF0ZSBhIGNhbGwu DQo+Pg0KPj4gSSB0aGluayBpdOKAmXMgaGFyZCBlbm91Z2ggdGhhdCBSRVFVSVJJTkcgY2VydCBw ZXIgVE4gaXMgbm90IGFjY2VwdGFibGUuDQo+Pg0KPj4gRm9sa3Mgd2l0aCBtb3JlIGludGltYXRl IGtub3dsZWRnZSBvZiBjYXJyaWVyIFNJUCBpbmZyYXN0cnVjdHVyZQ0KPj4gbWlnaHQgaGF2ZSBt b3JlIGluc2lnaHQgdGhhbiBJIGRvLiAgSXQgbWF5IGJlIGFjY2VwdGFibGUgdG8gaGF2ZSBhDQo+ PiBjZW50cmFsaXplZCByZXNvdXJjZSB0byBtYW5hZ2UgbWlsbGlvbnMgb2Yga2V5cy4NCj4+DQo+ PiBCcmlhbg0KPj4NCj4+ID4gT24gSnVsIDI3LCAyMDE1LCBhdCA2OjEzIFBNLCBSaWNoYXJkIEJh cm5lcyA8cmxiQGlwdi5zeD4gd3JvdGU6DQo+PiA+DQo+PiA+IEFmdGVyIHRoZSBTVElSIG1lZXRp bmcgaW4gUHJhZ3VlLCBIZW5uaW5nIGFuZCBJIHNwZW50IGEgZmV3IG1pbnV0ZXMNCj4+ID4gdGFs a2luZyB0aHJvdWdoIG9wdGlvbnMgZm9yIHJldm9jYXRpb24gY2hlY2tpbmcgYW5kIGNlcnRpZmlj YXRlDQo+PiA+IHNjb3BpbmcsIGFuZCBJIHRoaW5rIHdlIGhhdmUgYSBiZXR0ZXIgaWRlYSBvZiB3 aGF0IHRoZSBvcHRpbWFsDQo+PiA+IHNvbHV0aW9uIGxvb2tzIGxpa2UuICBTb21lIG5vdGVzIGFy ZSBiZWxvdywgYW5kIHNvbWUgc2xpZGVzIHdpdGgNCj4+ID4gcGljdHVyZXMgYXR0YWNoZWQuDQo+ PiA+DQo+PiA+IHRsO2RyOiBXZSBzaG91bGQ6DQo+PiA+ICogS2VlcCBUTnMgaW4gY2VydGlmaWNh dGVzIGFuZCBub3QgYm90aGVyIHdpdGggYW55IE9DU1AgZXh0ZW5zaW9ucw0KPj4gPiAqIFJlcXVp cmUgSWRlbnRpdHktSW5mbyB0byBpbmNsdWRlIE9DU1AgcmVzcG9uc2VzIGZvciBhbGwgY2VydHMg aW4NCj4+ID4gdGhlIGNoYWluDQo+PiA+DQo+PiA+DQo+PiA+ICMgQmFja2dyb3VuZDogUmV2b2Nh dGlvbiBpbiB0aGUgd2ViIFBLSQ0KPj4gPg0KPj4gPiBJbiBhbiBIVFRQUyB0cmFuc2FjdGlvbiwg dGhlIEhUVFBTIHNlcnZlciBwcm92aWRlcyB0aGUgY2xpZW50IHdpdGgNCj4+ID4gYSBjZXJ0aWZp Y2F0ZSwgYW5kIGl0IGNhbiBvcHRpb25hbGx5IGluY2x1ZGUgYW4gT0NTUCByZXNwb25zZSAoInN0 YXBsZSINCj4+ID4gaXQgdG8gdGhlIHRyYW5zYWN0aW9uKS4NCj4+ID4NCj4+ID4gQSBjZXJ0aWZp Y2F0ZSBjb250YWlucyBhIHZhbGlkaXR5IGludGVydmFsLCBhIGtleSwgYW5kIHNvbWUgbmFtZXMv VE5zLg0KPj4gPiBBbiBPQ1NQIHJlc3BvbnNlcyBjb250YWlucyBhIHZhbGlkaXR5IGludGVydmFs LCBhIGNlcnRpZmljYXRlIElEDQo+PiA+IChpLmUuLCBhIGhhc2gpLCBhbmQgYSBzdGF0dXMgKGdv b2QvcmV2b2tlZC91bmtub3duKS4gIEluIHRoZSB3ZWINCj4+ID4gUEtJLCBjZXJ0aWZpY2F0ZXMg YXJlIHJlcXVpcmVkIHRvIGJlIG5vIG1vcmUgdGhhbiAzOSBtb250aHMgbG9uZywNCj4+ID4gYW5k IE9DU1AgcmVzcG9uc2VzIG5vIG1vcmUgdGhhbiAxMCBkYXlzLg0KPj4gPg0KPj4gPiBJZGVhbGx5 LCBhIGNsaWVudCBvbmx5IGNvbnNpZGVycyBhIGNlcnRpZmljYXRlIHZhbGlkIGlmIGl0IGlzDQo+ PiA+IGFjY29tcGFuaWVkIGJ5IGFuIE9DU1AgcmVzcG9uc2UuICBJbiBwcmFjdGljZSwgdGhpcyBp cyBub3QgYWx3YXlzDQo+PiA+IHBvc3NpYmxlOyBiZWNhdXNlIE9DU1AgcXVlcmllcyBmYWlsIGFy b3VuZCAzJSBvZiB0aGUgdGltZSwgYnJvd3NlcnMNCj4+ID4gY2FuJ3QgcmVxdWlyZSBPQ1NQLiAg VGhpcyBvcGVyYXRpb25hbCBmYWN0IHdpbGwgYmUgaW1wb3J0YW50IGJlbG93LA0KPj4gPiBidXQg d2Ugd2lsbCBjb250aW51ZSB0byBoYXZlIHNjb3BpbmcgY2VydCBsaWZldGltZXMgYXMgYW4gb2Jq ZWN0aXZlLg0KPj4gPg0KPj4gPiBJbiB0aGUgd2ViIFBLSSwgdGhlcmUgYXJlIGJhc2ljYWxseSB0 aHJlZSByZXZvY2F0aW9uIGNoZWNraW5nIG1vZGFsaXRpZXM6DQo+PiA+DQo+PiA+IDEuIExpdmUg T0NTUCBjaGVja2luZyBbUkZDNjA2OV0NCj4+ID4gMi4gT0NTUCBzdGFwbGluZyAvIG11c3Rfc3Rh cGxlIFtSRkM2MDY2LA0KPj4gPiBkcmFmdC1oYWxsYW1iYWtlci10bHNmZWF0dXJlXSAzLiBTaG9y dC1saXZlZCBjZXJ0aWZpY2F0ZXMgKH5PQ1NQDQo+PiA+IGxpZmV0aW1lKQ0KPj4gPg0KPj4gPiAo VGhlIGxhc3Qgb2YgdGhlc2UgaXMgcmVsYXRpdmVseSBub3ZlbCwgYW5kIGhhcyBub3QgYmVlbiBk ZXBsb3llZC4NCj4+ID4gTmVpdGhlciBoYXMgbXVzdC1zdGFwbGUuICBCdXQgdGhleSdyZSBib3Ro IHByZXR0eSB0cml2aWFsLCBhbmQNCj4+ID4gY291bGQgYmUgZm9sZGVkIGludG8gYSBTVElSIGFy Y2hpdGVjdHVyZSBwcmV0dHkgZWFzaWx5LikNCj4+ID4NCj4+ID4gUmlnaHQgbm93LCBhYm91dCA5 MCUgb2YgVExTIHRyYW5zYWN0aW9ucyB1c2UgbGl2ZSBPQ1NQLCBhbmQgYWJvdXQgMTAlLg0KPj4g PiBDQXMgYW5kIGJyb3dzZXJzIGRlYXJseSB3YW50IHRoZSB3b3JsZCB0byBtb3ZlIHRvd2FyZCBz dGFwbGVkIE9DU1ANCj4+ID4gb3Igc2hvcnQtbGl2ZWQgY2VydHMsIGJlY2F1c2UgdGhlc2UgcmVk dWNlcyBsYXRlbmN5IGFuZCBpbXByb3ZlIHRoZQ0KPj4gPiBxdWFsaXR5IG9mIHJldm9jYXRpb24g aW5mb3JtYXRpb24uDQo+PiA+DQo+PiA+IFJldm9jYXRpb24gZm9yIENBIGNlcnRpZmljYXRlcyBp cyBjdXJyZW50bHkgZG9uZSBieSBoYXZpbmcgYnJvd3NlcnMNCj4+ID4gZG93bmxvYWQgYSBsaXN0 IGZyb20gYSBjZW50cmFsaXplZCBzZXJ2ZXIsIHNpbmNlIHRoZXJlJ3Mgbm8gd2F5IHRvDQo+PiA+ IHN0YXBsZSBtb3JlIHRoYW4gb25lIE9DU1AgcmVzcG9uc2UuICBUaGF0IHNvbHV0aW9uIHdvcmtz IE9LIGZvciB0aGUNCj4+ID4gd2ViLCBidXQgaWYgSSB3ZXJlIGRlc2lnbmluZyBzb21ldGhpbmcg ZGUgbm92bywgSSB3b3VsZCBwcm9iYWJseQ0KPj4gPiB1c2UgbXVsdGktc3RhcGxpbmcgYXMgd2Vs bC4NCj4+ID4NCj4+ID4NCj4+ID4gIyBBcHBseWluZyB0aGlzIGV4cGVyaWVuY2UgdG8gU1RJUg0K Pj4gPg0KPj4gPiBNb3N0IG9mIHRoZSBiZWxvdyBhcHBlYXIgdG8gYmUgZGVzaXJlZCBwcm9wZXJ0 aWVzIGJ5IHRoZSBXRzoNCj4+ID4NCj4+ID4gKiBWZXJpZmllciBuZWVlZHMgdG8ga25vdyB0aGF0 IGEgY2VydCBpcyB2YWxpZCBmb3IgYSBzcGVjaWZpYw0KPj4gPiBudW1iZXINCj4+ID4gKiBTY29w ZWQgY2VydCBsaWZldGltZTogTGltaXQgY2VydHMgdG8gfjF3ZWVrIGxpZmV0aW1lIChieSBPQ1NQ IGlmDQo+PiA+IGlzc3VlZCBsb25nZXIpDQo+PiA+ICogQ2FsbGVyIHByaXZhY3k6IERvbid0IHJl cG9ydCB3aGF0IGNhbGxzIHNvbWVvbmUgcmVjZWl2ZXMgdG8gYQ0KPj4gPiBjZW50cmFsIHNlcnZl cg0KPj4gPiAqIENhcnJpZXIgcHJpdmFjeTogRG9uJ3QgYWxsb3cgYSB0aGlyZCBwYXJ0eSB0byBm aWd1cmUgb3V0IGFsbCB0aGUNCj4+ID4gbnVtYmVycyBhIGNhcnJpZXIgaG9sZHMNCj4+ID4gKiBN aW5pbWl6ZSB0aGUgcmF0ZSBhdCB3aGljaCB0aGUgQ0EgaGFzIHRvIHNpZ24gdGhpbmdzDQo+PiA+ ICogVG9sZXJhdGUgb3V0YWdlcyBhdCB0aGUgQ0ENCj4+ID4NCj4+ID4gSSdtIGdvaW5nIHRvIGFz c3VtZSBmb3Igbm93IHRoYXQgd2Ugd2lsbCBub3QgZG8gbGl2ZSBPQ1NQLiAgSXQNCj4+ID4gdmlv bGF0ZXMgdGhlIGNhbGxlciBwcml2YWN5IHJlcXVpcmVtZW50LCBhbmQgYXMgZGlzY3Vzc2VkIGFi b3ZlLCBpdA0KPj4gPiBqdXN0IHN1Y2tzIG9wZXJhdGlvbmFsbHkuICBTbyBTVElSIHNob3VsZCBy ZXF1aXJlIE9DU1AgdG8gYmUgc2VudA0KPj4gPiBpbiAic3RhcGxlZCIgZm9ybSwgd2hpY2ggcHJv YmFibHkgbWVhbnMgc2VuZGluZyBpdCBpbiBJZGVudGl0eS1JbmZvLg0KPj4gPiBBbmQgd2hpbGUg d2UncmUgYXQgaXQsIHdlIHNob3VsZCBhbHNvIGRvICJtdWx0aS1zdGFwbGluZyIgLS0gc2VuZA0K Pj4gPiBhbiBPQ1NQIHJlc3BvbnNlIGZvciBDQSBjZXJ0cyBhcyB3ZWxsLg0KPj4gPg0KPj4gPiBT byBpZiB3ZSBjb25zaWRlciBhIHNlcnZlciB3aXRoIDUwayBUTnMgLyBibG9ja3MsIHRoYXQgbGVh dmVzIHVzDQo+PiA+IHdpdGggYmFzaWNhbGx5IDMgb3B0aW9uczoNCj4+ID4NCj4+ID4gMS4gNTBr IHNob3J0LWxpdmVkIGNlcnRzIChubyBPQ1NQKQ0KPj4gPiAyLiA1MGsgbG9uZy1saXZlZCBjZXJ0 cyBzY29wZWQgdG8gVE5zICsgZ2VuZXJpYyBPQ1NQIDMuIDENCj4+ID4gbG9uZy1saXZlZCBjZXJ0 IG5vdCBzY29wZWQgdG8gVE4gKG9yIGEgZmV3IGxvb3NlbHkgc2NvcGVkKSArIE9DU1ANCj4+ID4g d2l0aCBUTiBpbmZvDQo+PiA+DQo+PiA+IChBcyBJIGRpZG4ndCBxdWl0ZSBnZXQgdG8gc2F5IGlu IHRoZSBtZWV0aW5nLCByZWdhcmRsZXNzIG9mIHRoZQ0KPj4gPiBhcHByb2FjaCwgeW91IGhhdmUg dG8gaGF2ZSA1MGsgb2YgKnNvbWV0aGluZyouKSAgT2YgdGhlc2UsIGl0IHNlZW1zDQo+PiA+IGxp a2UgdGhlIHByZWZlcmVuY2Ugb3JkZXIgaXMgMiA+IDEgPiAzLg0KPj4gPg0KPj4gPiBPcHRpb24g MyBpcyBiYWQgZnJvbSBzZXZlcmFsIHBlcnNwZWN0aXZlczoNCj4+ID4gKiBQdXR0aW5nIFROIGlu Zm8gaW4gdGhlIE9DU1AgcmVzcG9uc2UgZW5hYmxlcyBzb21lb25lIHRvIHRyYXdsIGZvcg0KPj4g PiBudW1iZXJzIHVubGVzcyB5b3UgYWNjZXNzLWNvbnRyb2wgdGhlIE9DU1Agc2VydmVyLCBzbyB5 b3UgaW5oZXJpdCBhDQo+PiA+IHJlcXVpcmVtZW50IHRvIGRvIHRoYXQuDQo+PiA+ICogV2l0aCB0 aGUgcmF0ZSBvZiBjaHVybiBpbiBudW1iZXIgYXNzaWdubWVudHMsIHlvdSdyZSBwcm9iYWJseQ0K Pj4gPiBnb2luZyB0byBoYXZlIHRvIHVwZGF0ZSB0aGUgbG9uZy1saXZlZCBjZXJ0IHByZXR0eSBm cmVxdWVudGx5IGFueXdheS4NCj4+ID4gKiBQdXR0aW5nIFROLXNwZWNpZmljIHN0dWZmIGluIGNl cnRzIGlzIGJldHRlciB0aGFuIHB1dHRpbmcgaXQgaW4NCj4+ID4gT0NTUC4gIEFzIGJhZCBhcyBY LjUwOSBsaWJyYXJpZXMgY2FuIGJlLCBPQ1NQIGxpYnJhcmllcyBhcmUgbXVjaA0KPj4gPiB3b3Jz ZS4NCj4+ID4NCj4+ID4gT3B0aW9uIDEgaXMgbWFpbmx5IGJhZCBmcm9tIHRoZSBwZXJzcGVjdGl2 ZSBvZiBDQSBsb2FkIGFuZCBvdXRhZ2VzLg0KPj4gPiBXaXRoIE9wdGlvbiAyLCBpZiB0aGUgQ0Eg Z29lcyBkb3duLCBjbGllbnQgY2FuIGNvbnRpbnVlIHRvIHVzZSB0aGUNCj4+ID4gbG9uZy1saXZl ZCBjZXJ0IGFuZCBqdXN0IG5vdCBib3RoZXIgZG9pbmcgT0NTUCAodnMuIHRvbGVyYXRpbmcgYW4N Cj4+ID4gZXhwaXJlZCBjZXJ0KS4gIFNsaWdodGx5IGNsZWFuZXIuICBQbHVzLCB0aGVyZSdzIGEg bG90IG1vcmUNCj4+ID4gZXhwZXJpZW5jZSBjYWNoaW5nIE9DU1AgdGhhbiBuZXcgY2VydHMuICBP Q1NQIHNpZ25pbmcgY2FuIGFsc28gYmUNCj4+ID4gZGVsZWdhdGVkLCBzbyB5b3UgY2FuIGhhdmUg dGhlIHJlY3VycmluZyBvcGVyYXRpb24gZG9uZSBieSBhIGxvd2VyLXJpc2sga2V5Lg0KPj4gPg0K Pj4gPiBPcHRpb24gMiBzaG91bGQgYmUgcHJldHR5IGVhc3kgdG8gYXV0b21hdGUuICBZb3UgY2Fu IHByb2JhYmx5DQo+PiA+IHJlLXVzZSB0b29saW5nIGZvciBPQ1NQIHN0YXBsaW5nIHRoYXQgaGFz IGFscmVhZHkgYmVlbiBkZXZlbG9wZWQNCj4+ID4gZm9yIHVzZSB3aXRoIEhUVFBTLiAgSWYgeW91 J3JlIGEgYmlnIGJveCBzaWduaW5nIGZvciBhIGJ1bmNoIG9mDQo+PiA+IG51bWJlcnMsIHlvdSBk byBuZWVkIHRvIHNlbGVjdCB0aGUgcmlnaHQgY2VydCBhbmQgT0NTUCByZXNwb25zZSBmb3INCj4+ ID4gYSBnaXZlbiBjYWxsLCBidXQgdGhhdCdzIGEgcHJldHR5IHNpbXBsZSBsb29rdXAgdGFibGUu DQo+PiA+IDxTVElSLnBwdHg+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+ID4gc3RpciBtYWlsaW5nIGxpc3QNCj4+ID4gc3RpckBpZXRmLm9yZw0KPj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc3RpciBtYWls aW5nIGxpc3QNCj4+IHN0aXJAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3Rpcg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pg0KPiBUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNl IGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBv ZiB0aGUgbWVzc2FnZS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhp cyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVu ZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhl cnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1l c3NhZ2UuDQo= From nobody Tue Jul 28 07:24:31 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5D81AC3A1 for ; Tue, 28 Jul 2015 07:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uYz8ZfZaFDIB for ; Tue, 28 Jul 2015 07:24:26 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 7B76C1AC39D for ; Tue, 28 Jul 2015 07:24:26 -0700 (PDT) From: Henning Schulzrinne To: "Gorman, Pierce A [CTO]" Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAJs4gIAABZ6AgAAApgCAAAEaoA== Date: Tue, 28 Jul 2015 14:24:22 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> In-Reply-To: <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sprint.com; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 5:Jar9Zrir9en4KsknMWM/ne0yRyhR8iy5paa8pYIWr3d+H9t+KH69OaIxYsSuLjMunwWzdu0WkNOGVRzcM1pAsWd1MjC0UggG7eGtaU73o+s0X+ah/kOUPgIHFSiaZP31V77/1coabJzj6SVHaTFCQg==; 24:MQFiwrWZWVI1qdnAFYU0ESg61dn8svMBefPKz+MUyWKOO1l33mp+fsmP5xrPRIIVE9SalwTI9+6IMz6RKD+YjlRl70X9Z9Ot8M1DbOT4v7o=; 20:rh/3Dg9/mV0+m9092QwvPdpDIAaiBxOco6amqzDug5/q9n+E5kkF0wcieGQR7hVId5wVEO4uRJQk1J13naS5JA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635; cy1pr09mb0635: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(13464003)(102836002)(77096005)(2900100001)(2950100001)(46102003)(93886004)(15975445007)(76576001)(86362001)(5003600100002)(106116001)(50986999)(5001960100002)(110136002)(74316001)(99286002)(54356999)(87936001)(76176999)(19580395003)(33656002)(77156002)(62966003)(19580405001)(2656002)(189998001)(40100003)(66066001)(122556002)(5002640100001)(5890100001)(92566002)(551934003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2015 14:24:22.9873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 14:24:29 -0000 SW4gdGhlIFVTIGFsb25lLCB3ZSBoYXZlIGFib3V0IDQwMDAgY2FycmllcnMuIE1hbmFnaW5nIHRo ZSByZXB1dGF0aW9uIG9mIHRoYXQgbWFueSBlbnRpdGllcywgcmVsaWFibHkgKGkuZS4sIHdpdGhv dXQgbWFraW5nIGZhbHNlIHBvc2l0aXZlL25lZ2F0aXZlIG1pc3Rha2VzKSBzZWVtcyBhIHdob2xl IGxvdCBtb3JlIG1hbnVhbCBlZmZvcnQgdGhhbiBzdG9yaW5nIGJhZ3Mgb2YgYml0cy4gU3RvcmFn ZSBhbmQgYXV0b21hdGlvbiBpcyBjaGVhcCwgaHVtYW4ganVkZ2VtZW50IGFuZCBkZWFsaW5nIHdp dGggbWlzdGFrZXMgaXMgZXhwZW5zaXZlLg0KDQpPYnZpb3VzbHksIG5vdGhpbmcgaW4gdGhlIGFy Y2hpdGVjdHVyZSBwcmV2ZW50cyB3aWxkY2FyZCBjZXJ0aWZpY2F0ZXMuDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzdGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgR29ybWFuLCBQaWVyY2UgQSBbQ1RPXQ0KU2VudDogVHVlc2RheSwgSnVs eSAyOCwgMjAxNSAxMDoxNCBBTQ0KVG86IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4Pg0KQ2M6 IHN0aXJAaWV0Zi5vcmc7IEFsZXggQm9ib3RlayA8YWxleEBib2JvdGVrLm5ldD47IEJyaWFuIFJv c2VuIDxickBicmlhbnJvc2VuLm5ldD4NClN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5z LCBhbmQgUHJpdmFjeQ0KDQpJIHRob3VnaHQgdGhlIGRpc2N1c3Npb24gd2FzIG9uIGtleS9jZXJ0 IG1hbmFnZW1lbnQuICBJJ20gYXNraW5nIGlmIEkgdW5kZXJzdG9vZCB0aGUgc3VnZ2VzdGlvbiB0 byBtaW5pbWl6ZSByZXF1aXJlbWVudHMuICBIb3cgaXMgdGhhdCBvZmYgdG9waWM/DQoNCkJlc3Qg cmVnYXJkcywNCg0KDQpQaWVyY2UgR29ybWFuDQpDb3JlIE5ldHdvcmsgUGxhbm5pbmcNCk86IDkx My00MzktNDM2OA0KcGllcmNlLmdvcm1hbkBzcHJpbnQuY29tDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxiQGlwdi5zeF0NClNl bnQ6IEp1bHkgMjgsIDIwMTUgOToxMiBBTQ0KVG86IEdvcm1hbiwgUGllcmNlIEEgW0NUT10gPFBp ZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbT4NCkNjOiBBbGV4IEJvYm90ZWsgPGFsZXhAYm9ib3Rlay5u ZXQ+OyBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+OyBzdGlyQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3N0aXJdIE9uIE9DU1AsIFROcywgYW5kIFByaXZhY3kNCg0KT24gVHVlLCBKdWwg MjgsIDIwMTUgYXQgOTo1MSBBTSwgR29ybWFuLCBQaWVyY2UgQSBbQ1RPXSA8UGllcmNlLkdvcm1h bkBzcHJpbnQuY29tPiB3cm90ZToNCj4gIkxhcmdlIHNjYWxlIGNlcnRpZmljYXRlIG1hbmFnZW1l bnQgaXMgZXhwZW5zaXZlLCBhbmQgVE4tc3BlY2lmaWMgY2VydGlmaWNhdGVzIGFyZSB1bm5lZWRl ZCBmb3Igc2VjdXJpbmcgY2FsbHMgcGxhY2VkIGJ5IHBhcnRpZXMgd2hvIGNob29zZSB0byBwbGFj ZSBjYWxscyB0aHJvdWdoIGEgc2luZ2xlIHJlcHV0YWJsZSB0ZWxlcGhvbmUgc2VydmljZSBwcm92 aWRlci4iDQo+DQo+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgZm9yICJvbi1uZXQiIGNhbGxzLCBTVElS IG1ldGhvZG9sb2d5IGlzIHVubmVjZXNzYXJ5Pw0KDQpUaGlzIHNlZW1zIGEgbGl0dGxlIG9mZi10 b3BpYyBmb3IgdGhpcyBsaXN0Lg0KDQotLVJpY2hhcmQNCg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+ DQo+DQo+IFBpZXJjZSBHb3JtYW4NCj4gQ29yZSBOZXR3b3JrIFBsYW5uaW5nDQo+IE86IDkxMy00 MzktNDM2OA0KPiBwaWVyY2UuZ29ybWFuQHNwcmludC5jb20NCj4NCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleCBCb2JvdGVrIFttYWlsdG86YWxleEBib2JvdGVr Lm5ldF0NCj4gU2VudDogSnVseSAyNywgMjAxNSAxMTozNiBQTQ0KPiBUbzogQnJpYW4gUm9zZW4g PGJyQGJyaWFucm9zZW4ubmV0PjsgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+DQo+IENjOiBz dGlyQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBhbmQgUHJp dmFjeQ0KPg0KPiBXaGF0IG1vdGl2YXRpb24gd291bGQgYSBjYXJyaWVyIGhhdmUgdG8gY2hvb3Nl IGFueSBtb2RlbCBvdGhlciB0aGFuIGNhcnJpZXIgc2lnbmluZyB1c2luZyBvbmUgb2YgYSB2ZXJ5 IGxpbWl0ZWQgc2V0IG9mIGNhcnJpZXItb3duZWQga2V5cz8gIExhcmdlIHNjYWxlIGNlcnRpZmlj YXRlIG1hbmFnZW1lbnQgaXMgZXhwZW5zaXZlLCBhbmQgVE4tc3BlY2lmaWMgY2VydGlmaWNhdGVz IGFyZSB1bm5lZWRlZCBmb3Igc2VjdXJpbmcgY2FsbHMgcGxhY2VkIGJ5IHBhcnRpZXMgd2hvIGNo b29zZSB0byBwbGFjZSBjYWxscyB0aHJvdWdoIGEgc2luZ2xlIHJlcHV0YWJsZSB0ZWxlcGhvbmUg c2VydmljZSBwcm92aWRlci4gIEFueW9uZSBjYW4gZ2V0IG1hbnkgY2VydGlmaWNhdGVzLCBldmVu IGEgZnJlZSBvbmVzIGFub255bW91c2x5IGZyb20gc29tZSBpc3N1ZXJzLiAgSXQgaXMgdHlwaWNh bGx5IGEgY29tYmluYXRpb24gb2YgdGhlIHN0cmVuZ3RoIG9mIHRoZSBlbmQtdXNlciBhdXRoZW50 aWNhdGlvbiBwZXJmb3JtZWQgYnkgdGhlIHNlcnZpY2UgcHJvdmlkZXIgKG9yIGNlcnRpZmljYXRl IGlzc3VlciBpbiBhIHByb3ZpZGVyLWFnbm9zdGljIG1vZGVsKSBhbmQgdGhlIGlkZW50aXR5J3Mg aGlzdG9yeSB0aGF0IGFyZSBtb3N0IHVzZWZ1bCBpbiBzZWN1cml0eS4NCj4NCj4gSWYgd2UncmUg dHJ5aW5nIHRvIHNlY3VyZSB0aGUgY3VycmVudCB0ZWxlcGhvbmUgc3lzdGVtLCBETlMtbGlrZSBr ZXkgcmVwb3NpdG9yaWVzIGEgbGEgREtJTSBvciBwZXJoYXBzIGEgc21hbGwgbnVtYmVyIChjb21w YXJlZCB0byB0aGUgbnVtYmVyIG9mIFROcykgb2YgY2VydGlmaWNhdGVzIGFyZSBmYXIgbW9yZSBw cmFjdGljYWwuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IEFsZXgNCj4NCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBzdGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NCj4+IFNlbnQ6IE1vbmRheSwgSnVseSAyNywgMjAx NSA3OjQwIFBNDQo+PiBUbzogUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+DQo+PiBDYzogc3Rp ckBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzdGlyXSBPbiBPQ1NQLCBUTnMsIGFuZCBQcml2 YWN5DQo+Pg0KPj4gV2hhdCB0aGlzIG1lYW5zIGluIHByYWN0aWNlIGlzIHRoYXQgaXTigJlzIFRO IHBlciBjZXJ0Lg0KPj4NCj4+IEkgd291bGRu4oCZdCBzYXkgdGhhdCBpdOKAmXMgaW1wb3NzaWJs ZSBmb3IgYSBjYXJyaWVyIHRvIG1haW50YWluIGRvemVucyANCj4+IG9mIGNvcGllcyBvZiBtaWxs aW9ucyBvZiBwcml2YXRlIGtleXMgc2VjdXJlbHksIGJ1dCBpdOKAmXMgaGFyZC4gIFlvdSANCj4+ IG5lZWQgbXVsdGlwbGUgY29waWVzIGJlY2F1c2UgeW91IGhhdmUgbXVsdGlwbGUgZWxlbWVudHMg dGhhdCBjYW4gDQo+PiBpbml0aWF0ZSBhIGNhbGwsIGFuZCB5b3UgZG9u4oCZdCB3YW50IHRvIGRl cGVuZCBvbiBhIGNlbnRyYWxpemVkIA0KPj4gcmVzb3VyY2UgdG8gZG8gc29tZXRoaW5nIGFzIGJh c2ljIGFzIGNyZWF0ZSBhIGNhbGwuDQo+Pg0KPj4gSSB0aGluayBpdOKAmXMgaGFyZCBlbm91Z2gg dGhhdCBSRVFVSVJJTkcgY2VydCBwZXIgVE4gaXMgbm90IGFjY2VwdGFibGUuDQo+Pg0KPj4gRm9s a3Mgd2l0aCBtb3JlIGludGltYXRlIGtub3dsZWRnZSBvZiBjYXJyaWVyIFNJUCBpbmZyYXN0cnVj dHVyZSANCj4+IG1pZ2h0IGhhdmUgbW9yZSBpbnNpZ2h0IHRoYW4gSSBkby4gIEl0IG1heSBiZSBh Y2NlcHRhYmxlIHRvIGhhdmUgYSANCj4+IGNlbnRyYWxpemVkIHJlc291cmNlIHRvIG1hbmFnZSBt aWxsaW9ucyBvZiBrZXlzLg0KPj4NCj4+IEJyaWFuDQo+Pg0KPj4gPiBPbiBKdWwgMjcsIDIwMTUs IGF0IDY6MTMgUE0sIFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4PiB3cm90ZToNCj4+ID4NCj4+ ID4gQWZ0ZXIgdGhlIFNUSVIgbWVldGluZyBpbiBQcmFndWUsIEhlbm5pbmcgYW5kIEkgc3BlbnQg YSBmZXcgbWludXRlcyANCj4+ID4gdGFsa2luZyB0aHJvdWdoIG9wdGlvbnMgZm9yIHJldm9jYXRp b24gY2hlY2tpbmcgYW5kIGNlcnRpZmljYXRlIA0KPj4gPiBzY29waW5nLCBhbmQgSSB0aGluayB3 ZSBoYXZlIGEgYmV0dGVyIGlkZWEgb2Ygd2hhdCB0aGUgb3B0aW1hbCANCj4+ID4gc29sdXRpb24g bG9va3MgbGlrZS4gIFNvbWUgbm90ZXMgYXJlIGJlbG93LCBhbmQgc29tZSBzbGlkZXMgd2l0aCAN Cj4+ID4gcGljdHVyZXMgYXR0YWNoZWQuDQo+PiA+DQo+PiA+IHRsO2RyOiBXZSBzaG91bGQ6DQo+ PiA+ICogS2VlcCBUTnMgaW4gY2VydGlmaWNhdGVzIGFuZCBub3QgYm90aGVyIHdpdGggYW55IE9D U1AgZXh0ZW5zaW9ucw0KPj4gPiAqIFJlcXVpcmUgSWRlbnRpdHktSW5mbyB0byBpbmNsdWRlIE9D U1AgcmVzcG9uc2VzIGZvciBhbGwgY2VydHMgaW4gDQo+PiA+IHRoZSBjaGFpbg0KPj4gPg0KPj4g Pg0KPj4gPiAjIEJhY2tncm91bmQ6IFJldm9jYXRpb24gaW4gdGhlIHdlYiBQS0kNCj4+ID4NCj4+ ID4gSW4gYW4gSFRUUFMgdHJhbnNhY3Rpb24sIHRoZSBIVFRQUyBzZXJ2ZXIgcHJvdmlkZXMgdGhl IGNsaWVudCB3aXRoIA0KPj4gPiBhIGNlcnRpZmljYXRlLCBhbmQgaXQgY2FuIG9wdGlvbmFsbHkg aW5jbHVkZSBhbiBPQ1NQIHJlc3BvbnNlICgic3RhcGxlIg0KPj4gPiBpdCB0byB0aGUgdHJhbnNh Y3Rpb24pLg0KPj4gPg0KPj4gPiBBIGNlcnRpZmljYXRlIGNvbnRhaW5zIGEgdmFsaWRpdHkgaW50 ZXJ2YWwsIGEga2V5LCBhbmQgc29tZSBuYW1lcy9UTnMuDQo+PiA+IEFuIE9DU1AgcmVzcG9uc2Vz IGNvbnRhaW5zIGEgdmFsaWRpdHkgaW50ZXJ2YWwsIGEgY2VydGlmaWNhdGUgSUQgDQo+PiA+IChp LmUuLCBhIGhhc2gpLCBhbmQgYSBzdGF0dXMgKGdvb2QvcmV2b2tlZC91bmtub3duKS4gIEluIHRo ZSB3ZWIgDQo+PiA+IFBLSSwgY2VydGlmaWNhdGVzIGFyZSByZXF1aXJlZCB0byBiZSBubyBtb3Jl IHRoYW4gMzkgbW9udGhzIGxvbmcsIA0KPj4gPiBhbmQgT0NTUCByZXNwb25zZXMgbm8gbW9yZSB0 aGFuIDEwIGRheXMuDQo+PiA+DQo+PiA+IElkZWFsbHksIGEgY2xpZW50IG9ubHkgY29uc2lkZXJz IGEgY2VydGlmaWNhdGUgdmFsaWQgaWYgaXQgaXMgDQo+PiA+IGFjY29tcGFuaWVkIGJ5IGFuIE9D U1AgcmVzcG9uc2UuICBJbiBwcmFjdGljZSwgdGhpcyBpcyBub3QgYWx3YXlzIA0KPj4gPiBwb3Nz aWJsZTsgYmVjYXVzZSBPQ1NQIHF1ZXJpZXMgZmFpbCBhcm91bmQgMyUgb2YgdGhlIHRpbWUsIGJy b3dzZXJzIA0KPj4gPiBjYW4ndCByZXF1aXJlIE9DU1AuICBUaGlzIG9wZXJhdGlvbmFsIGZhY3Qg d2lsbCBiZSBpbXBvcnRhbnQgYmVsb3csIA0KPj4gPiBidXQgd2Ugd2lsbCBjb250aW51ZSB0byBo YXZlIHNjb3BpbmcgY2VydCBsaWZldGltZXMgYXMgYW4gb2JqZWN0aXZlLg0KPj4gPg0KPj4gPiBJ biB0aGUgd2ViIFBLSSwgdGhlcmUgYXJlIGJhc2ljYWxseSB0aHJlZSByZXZvY2F0aW9uIGNoZWNr aW5nIG1vZGFsaXRpZXM6DQo+PiA+DQo+PiA+IDEuIExpdmUgT0NTUCBjaGVja2luZyBbUkZDNjA2 OV0NCj4+ID4gMi4gT0NTUCBzdGFwbGluZyAvIG11c3Rfc3RhcGxlIFtSRkM2MDY2LCANCj4+ID4g ZHJhZnQtaGFsbGFtYmFrZXItdGxzZmVhdHVyZV0gMy4gU2hvcnQtbGl2ZWQgY2VydGlmaWNhdGVz ICh+T0NTUA0KPj4gPiBsaWZldGltZSkNCj4+ID4NCj4+ID4gKFRoZSBsYXN0IG9mIHRoZXNlIGlz IHJlbGF0aXZlbHkgbm92ZWwsIGFuZCBoYXMgbm90IGJlZW4gZGVwbG95ZWQuDQo+PiA+IE5laXRo ZXIgaGFzIG11c3Qtc3RhcGxlLiAgQnV0IHRoZXkncmUgYm90aCBwcmV0dHkgdHJpdmlhbCwgYW5k IA0KPj4gPiBjb3VsZCBiZSBmb2xkZWQgaW50byBhIFNUSVIgYXJjaGl0ZWN0dXJlIHByZXR0eSBl YXNpbHkuKQ0KPj4gPg0KPj4gPiBSaWdodCBub3csIGFib3V0IDkwJSBvZiBUTFMgdHJhbnNhY3Rp b25zIHVzZSBsaXZlIE9DU1AsIGFuZCBhYm91dCAxMCUuDQo+PiA+IENBcyBhbmQgYnJvd3NlcnMg ZGVhcmx5IHdhbnQgdGhlIHdvcmxkIHRvIG1vdmUgdG93YXJkIHN0YXBsZWQgT0NTUCANCj4+ID4g b3Igc2hvcnQtbGl2ZWQgY2VydHMsIGJlY2F1c2UgdGhlc2UgcmVkdWNlcyBsYXRlbmN5IGFuZCBp bXByb3ZlIHRoZSANCj4+ID4gcXVhbGl0eSBvZiByZXZvY2F0aW9uIGluZm9ybWF0aW9uLg0KPj4g Pg0KPj4gPiBSZXZvY2F0aW9uIGZvciBDQSBjZXJ0aWZpY2F0ZXMgaXMgY3VycmVudGx5IGRvbmUg YnkgaGF2aW5nIGJyb3dzZXJzIA0KPj4gPiBkb3dubG9hZCBhIGxpc3QgZnJvbSBhIGNlbnRyYWxp emVkIHNlcnZlciwgc2luY2UgdGhlcmUncyBubyB3YXkgdG8gDQo+PiA+IHN0YXBsZSBtb3JlIHRo YW4gb25lIE9DU1AgcmVzcG9uc2UuICBUaGF0IHNvbHV0aW9uIHdvcmtzIE9LIGZvciB0aGUgDQo+ PiA+IHdlYiwgYnV0IGlmIEkgd2VyZSBkZXNpZ25pbmcgc29tZXRoaW5nIGRlIG5vdm8sIEkgd291 bGQgcHJvYmFibHkgDQo+PiA+IHVzZSBtdWx0aS1zdGFwbGluZyBhcyB3ZWxsLg0KPj4gPg0KPj4g Pg0KPj4gPiAjIEFwcGx5aW5nIHRoaXMgZXhwZXJpZW5jZSB0byBTVElSDQo+PiA+DQo+PiA+IE1v c3Qgb2YgdGhlIGJlbG93IGFwcGVhciB0byBiZSBkZXNpcmVkIHByb3BlcnRpZXMgYnkgdGhlIFdH Og0KPj4gPg0KPj4gPiAqIFZlcmlmaWVyIG5lZWVkcyB0byBrbm93IHRoYXQgYSBjZXJ0IGlzIHZh bGlkIGZvciBhIHNwZWNpZmljIA0KPj4gPiBudW1iZXINCj4+ID4gKiBTY29wZWQgY2VydCBsaWZl dGltZTogTGltaXQgY2VydHMgdG8gfjF3ZWVrIGxpZmV0aW1lIChieSBPQ1NQIGlmIA0KPj4gPiBp c3N1ZWQgbG9uZ2VyKQ0KPj4gPiAqIENhbGxlciBwcml2YWN5OiBEb24ndCByZXBvcnQgd2hhdCBj YWxscyBzb21lb25lIHJlY2VpdmVzIHRvIGEgDQo+PiA+IGNlbnRyYWwgc2VydmVyDQo+PiA+ICog Q2FycmllciBwcml2YWN5OiBEb24ndCBhbGxvdyBhIHRoaXJkIHBhcnR5IHRvIGZpZ3VyZSBvdXQg YWxsIHRoZSANCj4+ID4gbnVtYmVycyBhIGNhcnJpZXIgaG9sZHMNCj4+ID4gKiBNaW5pbWl6ZSB0 aGUgcmF0ZSBhdCB3aGljaCB0aGUgQ0EgaGFzIHRvIHNpZ24gdGhpbmdzDQo+PiA+ICogVG9sZXJh dGUgb3V0YWdlcyBhdCB0aGUgQ0ENCj4+ID4NCj4+ID4gSSdtIGdvaW5nIHRvIGFzc3VtZSBmb3Ig bm93IHRoYXQgd2Ugd2lsbCBub3QgZG8gbGl2ZSBPQ1NQLiAgSXQgDQo+PiA+IHZpb2xhdGVzIHRo ZSBjYWxsZXIgcHJpdmFjeSByZXF1aXJlbWVudCwgYW5kIGFzIGRpc2N1c3NlZCBhYm92ZSwgaXQg DQo+PiA+IGp1c3Qgc3Vja3Mgb3BlcmF0aW9uYWxseS4gIFNvIFNUSVIgc2hvdWxkIHJlcXVpcmUg T0NTUCB0byBiZSBzZW50IA0KPj4gPiBpbiAic3RhcGxlZCIgZm9ybSwgd2hpY2ggcHJvYmFibHkg bWVhbnMgc2VuZGluZyBpdCBpbiBJZGVudGl0eS1JbmZvLg0KPj4gPiBBbmQgd2hpbGUgd2UncmUg YXQgaXQsIHdlIHNob3VsZCBhbHNvIGRvICJtdWx0aS1zdGFwbGluZyIgLS0gc2VuZCANCj4+ID4g YW4gT0NTUCByZXNwb25zZSBmb3IgQ0EgY2VydHMgYXMgd2VsbC4NCj4+ID4NCj4+ID4gU28gaWYg d2UgY29uc2lkZXIgYSBzZXJ2ZXIgd2l0aCA1MGsgVE5zIC8gYmxvY2tzLCB0aGF0IGxlYXZlcyB1 cyANCj4+ID4gd2l0aCBiYXNpY2FsbHkgMyBvcHRpb25zOg0KPj4gPg0KPj4gPiAxLiA1MGsgc2hv cnQtbGl2ZWQgY2VydHMgKG5vIE9DU1ApDQo+PiA+IDIuIDUwayBsb25nLWxpdmVkIGNlcnRzIHNj b3BlZCB0byBUTnMgKyBnZW5lcmljIE9DU1AgMy4gMSANCj4+ID4gbG9uZy1saXZlZCBjZXJ0IG5v dCBzY29wZWQgdG8gVE4gKG9yIGEgZmV3IGxvb3NlbHkgc2NvcGVkKSArIE9DU1AgDQo+PiA+IHdp dGggVE4gaW5mbw0KPj4gPg0KPj4gPiAoQXMgSSBkaWRuJ3QgcXVpdGUgZ2V0IHRvIHNheSBpbiB0 aGUgbWVldGluZywgcmVnYXJkbGVzcyBvZiB0aGUgDQo+PiA+IGFwcHJvYWNoLCB5b3UgaGF2ZSB0 byBoYXZlIDUwayBvZiAqc29tZXRoaW5nKi4pICBPZiB0aGVzZSwgaXQgc2VlbXMgDQo+PiA+IGxp a2UgdGhlIHByZWZlcmVuY2Ugb3JkZXIgaXMgMiA+IDEgPiAzLg0KPj4gPg0KPj4gPiBPcHRpb24g MyBpcyBiYWQgZnJvbSBzZXZlcmFsIHBlcnNwZWN0aXZlczoNCj4+ID4gKiBQdXR0aW5nIFROIGlu Zm8gaW4gdGhlIE9DU1AgcmVzcG9uc2UgZW5hYmxlcyBzb21lb25lIHRvIHRyYXdsIGZvciANCj4+ ID4gbnVtYmVycyB1bmxlc3MgeW91IGFjY2Vzcy1jb250cm9sIHRoZSBPQ1NQIHNlcnZlciwgc28g eW91IGluaGVyaXQgYSANCj4+ID4gcmVxdWlyZW1lbnQgdG8gZG8gdGhhdC4NCj4+ID4gKiBXaXRo IHRoZSByYXRlIG9mIGNodXJuIGluIG51bWJlciBhc3NpZ25tZW50cywgeW91J3JlIHByb2JhYmx5 IA0KPj4gPiBnb2luZyB0byBoYXZlIHRvIHVwZGF0ZSB0aGUgbG9uZy1saXZlZCBjZXJ0IHByZXR0 eSBmcmVxdWVudGx5IGFueXdheS4NCj4+ID4gKiBQdXR0aW5nIFROLXNwZWNpZmljIHN0dWZmIGlu IGNlcnRzIGlzIGJldHRlciB0aGFuIHB1dHRpbmcgaXQgaW4gDQo+PiA+IE9DU1AuICBBcyBiYWQg YXMgWC41MDkgbGlicmFyaWVzIGNhbiBiZSwgT0NTUCBsaWJyYXJpZXMgYXJlIG11Y2ggDQo+PiA+ IHdvcnNlLg0KPj4gPg0KPj4gPiBPcHRpb24gMSBpcyBtYWlubHkgYmFkIGZyb20gdGhlIHBlcnNw ZWN0aXZlIG9mIENBIGxvYWQgYW5kIG91dGFnZXMuDQo+PiA+IFdpdGggT3B0aW9uIDIsIGlmIHRo ZSBDQSBnb2VzIGRvd24sIGNsaWVudCBjYW4gY29udGludWUgdG8gdXNlIHRoZSANCj4+ID4gbG9u Zy1saXZlZCBjZXJ0IGFuZCBqdXN0IG5vdCBib3RoZXIgZG9pbmcgT0NTUCAodnMuIHRvbGVyYXRp bmcgYW4gDQo+PiA+IGV4cGlyZWQgY2VydCkuICBTbGlnaHRseSBjbGVhbmVyLiAgUGx1cywgdGhl cmUncyBhIGxvdCBtb3JlIA0KPj4gPiBleHBlcmllbmNlIGNhY2hpbmcgT0NTUCB0aGFuIG5ldyBj ZXJ0cy4gIE9DU1Agc2lnbmluZyBjYW4gYWxzbyBiZSANCj4+ID4gZGVsZWdhdGVkLCBzbyB5b3Ug Y2FuIGhhdmUgdGhlIHJlY3VycmluZyBvcGVyYXRpb24gZG9uZSBieSBhIGxvd2VyLXJpc2sga2V5 Lg0KPj4gPg0KPj4gPiBPcHRpb24gMiBzaG91bGQgYmUgcHJldHR5IGVhc3kgdG8gYXV0b21hdGUu ICBZb3UgY2FuIHByb2JhYmx5IA0KPj4gPiByZS11c2UgdG9vbGluZyBmb3IgT0NTUCBzdGFwbGlu ZyB0aGF0IGhhcyBhbHJlYWR5IGJlZW4gZGV2ZWxvcGVkIA0KPj4gPiBmb3IgdXNlIHdpdGggSFRU UFMuICBJZiB5b3UncmUgYSBiaWcgYm94IHNpZ25pbmcgZm9yIGEgYnVuY2ggb2YgDQo+PiA+IG51 bWJlcnMsIHlvdSBkbyBuZWVkIHRvIHNlbGVjdCB0aGUgcmlnaHQgY2VydCBhbmQgT0NTUCByZXNw b25zZSBmb3IgDQo+PiA+IGEgZ2l2ZW4gY2FsbCwgYnV0IHRoYXQncyBhIHByZXR0eSBzaW1wbGUg bG9va3VwIHRhYmxlLg0KPj4gPiA8U1RJUi5wcHR4Pl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiA+IHN0aXIgbWFpbGluZyBsaXN0DQo+PiA+IHN0aXJA aWV0Zi5vcmcNCj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGly DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IHN0aXIgbWFpbGluZyBsaXN0DQo+PiBzdGlyQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4NCj4gVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVu dChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRl IGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNClRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZv cm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFu eSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29w aWVzIG9mIHRoZSBtZXNzYWdlLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnN0aXIgbWFpbGluZyBsaXN0DQpzdGlyQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCg== From nobody Tue Jul 28 07:47:32 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952551ABB1A for ; Tue, 28 Jul 2015 07:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 r41x6YX6fMsw for ; Tue, 28 Jul 2015 07:47:29 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id AB9041AC3CB for ; Tue, 28 Jul 2015 07:47:26 -0700 (PDT) From: Henning Schulzrinne To: Paul Kyzivat , "" Thread-Topic: [stir] the role of trust in stir Thread-Index: AQHQw6Us0Hud9aHEgUmw8EizwVsL053w/5dw Date: Tue, 28 Jul 2015 14:47:24 +0000 Message-ID: References: <55AE2770.9020101@alum.mit.edu> In-Reply-To: <55AE2770.9020101@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 5:8KbELzJexIVBagwTot5GofwIomfqbfLjUCXK5eAzREJ4vP7VOixILtgW5SRmyVQ8waGvalaPYBnbCHeiirI8VqR0/powEmh2EI97bz07VNZIPv4G96oqdKCrj+0T18sG065h6cd0emF1of66K8qKAA==; 24:SPNA3dM/+K67FJrzN97pFAph+R7oZyxbYyr1gr7ngiaD3CkKfzHhOXDEG+aAHvKcHD6mpGbYI1hmYbfCOyYHakDncMauaFiPod6pZGv276M=; 20:VPyNuNdEi6P5dIjI4hF9yZrIdIagcQx0pscy9rAh7HDeRTc8ibvAroLUpn79rwrWqIx9gcjikvLuqbQafvVCaQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635; cy1pr09mb0635: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(164054003)(77096005)(102836002)(2900100001)(2950100001)(5001770100001)(46102003)(15975445007)(76576001)(86362001)(5003600100002)(106116001)(50986999)(5001960100002)(107886002)(54356999)(74316001)(99286002)(2171001)(87936001)(76176999)(19580395003)(33656002)(77156002)(62966003)(19580405001)(2656002)(189998001)(66066001)(40100003)(122556002)(5002640100001)(92566002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2015 14:47:24.4588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [stir] the role of trust in stir X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 14:47:31 -0000 There are two separate policy issues: (1) The call was made by somebody who is authorized to use the number. (2) The call is/is not a nuisance/fraud call. I suspect local policy and white/blacklisting is mainly involved in the sec= ond one (which is outside the STIR concern). I agree that having a uniform signing behavior seems least likely to lead t= o have to code special cases, maintain lists, etc. We know from experience = that maintaining the CA list in browsers (a whitelist, if you like) has not= been a happy experience, and there are only a handful of browsers, not tho= usands of carriers, who have to make that decision. Similarly, wildcard cer= ts (beyond domain-specific wildcards like *.example.com) also have not had = a good track record. You could call this the categorical imperative of signing: it's not a good = idea if it can't be made the law of the land. -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, July 21, 2015 7:05 AM To: Subject: [stir] the role of trust in stir I couldn't make myself clear via jabber during the discussion, so I'll try = again. This is similar to a point that Henning made. There seem to be a few models for how verifier determines whether a cert ac= tually covers the number it signs: - the message contains the cert - the message contains a ref to the cert And then, regardless of how the cert is obtained: - the cert contains the TN. - the cert contains a reference to a list of covered TNs. - the cert has neither (is that a real possibility?) This then leads to several possible cases for the verifier: 1) there is no signature 2) there is a signature, but the cert can't be obtained 3) cert has been obtained, no attempt is made to determine formal coverage = of the TN (because policy doesn't require it). 4) cert has been obtained, but coverage of TN by cert can't be determined 5) cert has been obtained, and it explicitly does NOT cover the TN. 6) cert has been obtained, and coverage of TN has been verified I think all of those cases are possible regardless of policy. It then becom= es a matter of policy how to treat calls in each case: allow or not, displa= y calling TN or not, indicate warning or not. But if certain policies become widely used they could have the effect of ma= king other policies unusable. And that can have the effect of encouraging o= ligopolies. In particular, if a common verifier policy is to just whitelist certain sig= ners without checking coverage, and block the id from everybody else, then = anybody who gets service from a provider who isn't on the whitelist runs th= e risk of not having their calls answered. Also, when providers know most verifiers follow that policy, then they can = also sign calls from favored peers not on the whitelist. (IOW, they can *li= e*, assuming the lie won't be checked, instead reinstituting a transitive t= rust model.) That will allow them to further extend their business lock in = and discriminate against whoever they want. It seems especially bad to enable an environment where signatures can be ma= de by signers who don't have authority over the signed TN. I would like to see a system where verification doesn't depend on whitelist= s. (However blacklists could be used to reduce verification cost for bad ac= tors.) (I guess ultimately whitelists must exist at some level, but better be only= at the very top of the delegation chain.) Thanks, Paul _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 28 12:14:43 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59AC1B2DEB for ; Tue, 28 Jul 2015 12:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EN0NpYDiyCFY for ; Tue, 28 Jul 2015 12:14:40 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88ED01B2DDD for ; Tue, 28 Jul 2015 12:14:39 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id f94d7b55.2b9bbee2a940.628433.00-2475.1797172.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 28 Jul 2015 19:14:39 +0000 (UTC) X-MXL-Hash: 55b7d49f641fb928-396c599d142e690da3e0c45c68de7697a8437dba Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 694d7b55.0.628371.00-2072.1796956.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 28 Jul 2015 19:14:32 +0000 (UTC) X-MXL-Hash: 55b7d49829f25916-e81a6ec2df206c7726fc638b85e7ee62885d0f46 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 t6SJETVj014916; Tue, 28 Jul 2015 15:14:30 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6SJEGcN014569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jul 2015 15:14:20 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 28 Jul 2015 19:13:50 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.237]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0224.002; Tue, 28 Jul 2015 15:13:49 -0400 From: "PFAUTZ, PENN L" To: Henning Schulzrinne , "Gorman, Pierce A [CTO]" Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLmIfuNwwir/xEOjfOFArSLlWp3wbvsAgAAgjQCAAJs4gIAABZ6AgAAApQCAAALJAIAAC/+w Date: Tue, 28 Jul 2015 19:13:49 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: NUMBER PORTABILITY, public X-AnalysisOut: [v=2.0 cv=ONaQK1mB c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=_Je7GUglaHMA:10 a=zOBTX] X-AnalysisOut: [jUuO1YA:10 a=48vgC7mUAAAA:8 a=VfgTrTGYAAAA:8 a=HLLxP2VMAAA] X-AnalysisOut: [A:8 a=izV7ms69AAAA:8 a=_bZvfwF9VCtE2YeE1ysA:9 a=QEXdDO2ut3] X-AnalysisOut: [YA:10 a=DzjOOp_o1eYA:10 a=YYWFc57rIUUZfpNf:21 a=D8RS8zZ8nr] X-AnalysisOut: [Xfj21P:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072801)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 19:14:43 -0000 Rm9yZ2l2ZSBtZSBidXQgbXkgcmVwdGlsZSBicmFpbiBrZWVwcyB3aGlzcGVyaW5nIGluIG15IGVh ciB0aGF0IHRoaXMgd291bGQgYmUgYSBsb3QgZWFzaWVyIGlmIHdlIHNpbXBseSBoYWQgYSBudW1i ZXJpbmcgcmVnaXN0cnksIHdoZXRoZXIgZGlzdHJpYnV0ZWQgb3IgY2VudHJhbGl6ZWQgLSBsaWtl IHdlIG5lZWQgYW55d2F5IGZvciBhdCBsZWFzdCBmb3IgbnVtYmVyIHBvcnRhYmlsaXR5IC0gdGhh dCBhbHNvIGNvbnRhaW5lZCB0aGUgcHVibGljIGtleXMuIE5vIHRlZGlvdXMgbXVja2luZyBhYm91 dCBpbiBjeWJlcnNwYWNlIHdpdGggY2VydHMsIENSTHMsIG9yIE9DU1AuDQoNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEhlbm5pbmcgU2NodWx6cmlubmUNClNlbnQ6IFR1ZXNkYXksIEp1 bHkgMjgsIDIwMTUgMTA6MjQgQU0NClRvOiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dDQpDYzogc3Rp ckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzdGlyXSBPbiBPQ1NQLCBUTnMsIGFuZCBQcml2YWN5 DQoNCkluIHRoZSBVUyBhbG9uZSwgd2UgaGF2ZSBhYm91dCA0MDAwIGNhcnJpZXJzLiBNYW5hZ2lu ZyB0aGUgcmVwdXRhdGlvbiBvZiB0aGF0IG1hbnkgZW50aXRpZXMsIHJlbGlhYmx5IChpLmUuLCB3 aXRob3V0IG1ha2luZyBmYWxzZSBwb3NpdGl2ZS9uZWdhdGl2ZSBtaXN0YWtlcykgc2VlbXMgYSB3 aG9sZSBsb3QgbW9yZSBtYW51YWwgZWZmb3J0IHRoYW4gc3RvcmluZyBiYWdzIG9mIGJpdHMuIFN0 b3JhZ2UgYW5kIGF1dG9tYXRpb24gaXMgY2hlYXAsIGh1bWFuIGp1ZGdlbWVudCBhbmQgZGVhbGlu ZyB3aXRoIG1pc3Rha2VzIGlzIGV4cGVuc2l2ZS4NCg0KT2J2aW91c2x5LCBub3RoaW5nIGluIHRo ZSBhcmNoaXRlY3R1cmUgcHJldmVudHMgd2lsZGNhcmQgY2VydGlmaWNhdGVzLg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEdvcm1hbiwgUGllcmNlIEEgW0NUT10NClNlbnQ6IFR1ZXNkYXks IEp1bHkgMjgsIDIwMTUgMTA6MTQgQU0NClRvOiBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeD4N CkNjOiBzdGlyQGlldGYub3JnOyBBbGV4IEJvYm90ZWsgPGFsZXhAYm9ib3Rlay5uZXQ+OyBCcmlh biBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQpTdWJqZWN0OiBSZTogW3N0aXJdIE9uIE9DU1As IFROcywgYW5kIFByaXZhY3kNCg0KSSB0aG91Z2h0IHRoZSBkaXNjdXNzaW9uIHdhcyBvbiBrZXkv Y2VydCBtYW5hZ2VtZW50LiAgSSdtIGFza2luZyBpZiBJIHVuZGVyc3Rvb2QgdGhlIHN1Z2dlc3Rp b24gdG8gbWluaW1pemUgcmVxdWlyZW1lbnRzLiAgSG93IGlzIHRoYXQgb2ZmIHRvcGljPw0KDQpC ZXN0IHJlZ2FyZHMsDQoNCg0KUGllcmNlIEdvcm1hbg0KQ29yZSBOZXR3b3JrIFBsYW5uaW5nDQpP OiA5MTMtNDM5LTQzNjgNCnBpZXJjZS5nb3JtYW5Ac3ByaW50LmNvbQ0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSaWNoYXJkIEJhcm5lcyBbbWFpbHRvOnJsYkBpcHYuc3hd DQpTZW50OiBKdWx5IDI4LCAyMDE1IDk6MTIgQU0NClRvOiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9d IDxQaWVyY2UuR29ybWFuQHNwcmludC5jb20+DQpDYzogQWxleCBCb2JvdGVrIDxhbGV4QGJvYm90 ZWsubmV0PjsgQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0Pjsgc3RpckBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtzdGlyXSBPbiBPQ1NQLCBUTnMsIGFuZCBQcml2YWN5DQoNCk9uIFR1ZSwg SnVsIDI4LCAyMDE1IGF0IDk6NTEgQU0sIEdvcm1hbiwgUGllcmNlIEEgW0NUT10gPFBpZXJjZS5H b3JtYW5Ac3ByaW50LmNvbT4gd3JvdGU6DQo+ICJMYXJnZSBzY2FsZSBjZXJ0aWZpY2F0ZSBtYW5h Z2VtZW50IGlzIGV4cGVuc2l2ZSwgYW5kIFROLXNwZWNpZmljIGNlcnRpZmljYXRlcyBhcmUgdW5u ZWVkZWQgZm9yIHNlY3VyaW5nIGNhbGxzIHBsYWNlZCBieSBwYXJ0aWVzIHdobyBjaG9vc2UgdG8g cGxhY2UgY2FsbHMgdGhyb3VnaCBhIHNpbmdsZSByZXB1dGFibGUgdGVsZXBob25lIHNlcnZpY2Ug cHJvdmlkZXIuIg0KPg0KPiBBcmUgeW91IHNheWluZyB0aGF0IGZvciAib24tbmV0IiBjYWxscywg U1RJUiBtZXRob2RvbG9neSBpcyB1bm5lY2Vzc2FyeT8NCg0KVGhpcyBzZWVtcyBhIGxpdHRsZSBv ZmYtdG9waWMgZm9yIHRoaXMgbGlzdC4NCg0KLS1SaWNoYXJkDQoNCj4NCj4gQmVzdCByZWdhcmRz LA0KPg0KPg0KPiBQaWVyY2UgR29ybWFuDQo+IENvcmUgTmV0d29yayBQbGFubmluZw0KPiBPOiA5 MTMtNDM5LTQzNjgNCj4gcGllcmNlLmdvcm1hbkBzcHJpbnQuY29tDQo+DQo+DQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFsZXggQm9ib3RlayBbbWFpbHRvOmFsZXhAYm9i b3Rlay5uZXRdDQo+IFNlbnQ6IEp1bHkgMjcsIDIwMTUgMTE6MzYgUE0NCj4gVG86IEJyaWFuIFJv c2VuIDxickBicmlhbnJvc2VuLm5ldD47IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4Pg0KPiBD Yzogc3RpckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3N0aXJdIE9uIE9DU1AsIFROcywgYW5k IFByaXZhY3kNCj4NCj4gV2hhdCBtb3RpdmF0aW9uIHdvdWxkIGEgY2FycmllciBoYXZlIHRvIGNo b29zZSBhbnkgbW9kZWwgb3RoZXIgdGhhbiBjYXJyaWVyIHNpZ25pbmcgdXNpbmcgb25lIG9mIGEg dmVyeSBsaW1pdGVkIHNldCBvZiBjYXJyaWVyLW93bmVkIGtleXM/ICBMYXJnZSBzY2FsZSBjZXJ0 aWZpY2F0ZSBtYW5hZ2VtZW50IGlzIGV4cGVuc2l2ZSwgYW5kIFROLXNwZWNpZmljIGNlcnRpZmlj YXRlcyBhcmUgdW5uZWVkZWQgZm9yIHNlY3VyaW5nIGNhbGxzIHBsYWNlZCBieSBwYXJ0aWVzIHdo byBjaG9vc2UgdG8gcGxhY2UgY2FsbHMgdGhyb3VnaCBhIHNpbmdsZSByZXB1dGFibGUgdGVsZXBo b25lIHNlcnZpY2UgcHJvdmlkZXIuICBBbnlvbmUgY2FuIGdldCBtYW55IGNlcnRpZmljYXRlcywg ZXZlbiBhIGZyZWUgb25lcyBhbm9ueW1vdXNseSBmcm9tIHNvbWUgaXNzdWVycy4gIEl0IGlzIHR5 cGljYWxseSBhIGNvbWJpbmF0aW9uIG9mIHRoZSBzdHJlbmd0aCBvZiB0aGUgZW5kLXVzZXIgYXV0 aGVudGljYXRpb24gcGVyZm9ybWVkIGJ5IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIChvciBjZXJ0aWZp Y2F0ZSBpc3N1ZXIgaW4gYSBwcm92aWRlci1hZ25vc3RpYyBtb2RlbCkgYW5kIHRoZSBpZGVudGl0 eSdzIGhpc3RvcnkgdGhhdCBhcmUgbW9zdCB1c2VmdWwgaW4gc2VjdXJpdHkuDQo+DQo+IElmIHdl J3JlIHRyeWluZyB0byBzZWN1cmUgdGhlIGN1cnJlbnQgdGVsZXBob25lIHN5c3RlbSwgRE5TLWxp a2Uga2V5IHJlcG9zaXRvcmllcyBhIGxhIERLSU0gb3IgcGVyaGFwcyBhIHNtYWxsIG51bWJlciAo Y29tcGFyZWQgdG8gdGhlIG51bWJlciBvZiBUTnMpIG9mIGNlcnRpZmljYXRlcyBhcmUgZmFyIG1v cmUgcHJhY3RpY2FsLg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBBbGV4DQo+DQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIFJvc2VuDQo+PiBTZW50OiBNb25kYXksIEp1bHkgMjcs IDIwMTUgNzo0MCBQTQ0KPj4gVG86IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4Pg0KPj4gQ2M6 IHN0aXJAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBhbmQg UHJpdmFjeQ0KPj4NCj4+IFdoYXQgdGhpcyBtZWFucyBpbiBwcmFjdGljZSBpcyB0aGF0IGl04oCZ cyBUTiBwZXIgY2VydC4NCj4+DQo+PiBJIHdvdWxkbuKAmXQgc2F5IHRoYXQgaXTigJlzIGltcG9z c2libGUgZm9yIGEgY2FycmllciB0byBtYWludGFpbiBkb3plbnMgDQo+PiBvZiBjb3BpZXMgb2Yg bWlsbGlvbnMgb2YgcHJpdmF0ZSBrZXlzIHNlY3VyZWx5LCBidXQgaXTigJlzIGhhcmQuICBZb3Ug DQo+PiBuZWVkIG11bHRpcGxlIGNvcGllcyBiZWNhdXNlIHlvdSBoYXZlIG11bHRpcGxlIGVsZW1l bnRzIHRoYXQgY2FuIA0KPj4gaW5pdGlhdGUgYSBjYWxsLCBhbmQgeW91IGRvbuKAmXQgd2FudCB0 byBkZXBlbmQgb24gYSBjZW50cmFsaXplZCANCj4+IHJlc291cmNlIHRvIGRvIHNvbWV0aGluZyBh cyBiYXNpYyBhcyBjcmVhdGUgYSBjYWxsLg0KPj4NCj4+IEkgdGhpbmsgaXTigJlzIGhhcmQgZW5v dWdoIHRoYXQgUkVRVUlSSU5HIGNlcnQgcGVyIFROIGlzIG5vdCBhY2NlcHRhYmxlLg0KPj4NCj4+ IEZvbGtzIHdpdGggbW9yZSBpbnRpbWF0ZSBrbm93bGVkZ2Ugb2YgY2FycmllciBTSVAgaW5mcmFz dHJ1Y3R1cmUgDQo+PiBtaWdodCBoYXZlIG1vcmUgaW5zaWdodCB0aGFuIEkgZG8uICBJdCBtYXkg YmUgYWNjZXB0YWJsZSB0byBoYXZlIGEgDQo+PiBjZW50cmFsaXplZCByZXNvdXJjZSB0byBtYW5h Z2UgbWlsbGlvbnMgb2Yga2V5cy4NCj4+DQo+PiBCcmlhbg0KPj4NCj4+ID4gT24gSnVsIDI3LCAy MDE1LCBhdCA2OjEzIFBNLCBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeD4gd3JvdGU6DQo+PiA+ DQo+PiA+IEFmdGVyIHRoZSBTVElSIG1lZXRpbmcgaW4gUHJhZ3VlLCBIZW5uaW5nIGFuZCBJIHNw ZW50IGEgZmV3IG1pbnV0ZXMgDQo+PiA+IHRhbGtpbmcgdGhyb3VnaCBvcHRpb25zIGZvciByZXZv Y2F0aW9uIGNoZWNraW5nIGFuZCBjZXJ0aWZpY2F0ZSANCj4+ID4gc2NvcGluZywgYW5kIEkgdGhp bmsgd2UgaGF2ZSBhIGJldHRlciBpZGVhIG9mIHdoYXQgdGhlIG9wdGltYWwgDQo+PiA+IHNvbHV0 aW9uIGxvb2tzIGxpa2UuICBTb21lIG5vdGVzIGFyZSBiZWxvdywgYW5kIHNvbWUgc2xpZGVzIHdp dGggDQo+PiA+IHBpY3R1cmVzIGF0dGFjaGVkLg0KPj4gPg0KPj4gPiB0bDtkcjogV2Ugc2hvdWxk Og0KPj4gPiAqIEtlZXAgVE5zIGluIGNlcnRpZmljYXRlcyBhbmQgbm90IGJvdGhlciB3aXRoIGFu eSBPQ1NQIGV4dGVuc2lvbnMNCj4+ID4gKiBSZXF1aXJlIElkZW50aXR5LUluZm8gdG8gaW5jbHVk ZSBPQ1NQIHJlc3BvbnNlcyBmb3IgYWxsIGNlcnRzIGluIA0KPj4gPiB0aGUgY2hhaW4NCj4+ID4N Cj4+ID4NCj4+ID4gIyBCYWNrZ3JvdW5kOiBSZXZvY2F0aW9uIGluIHRoZSB3ZWIgUEtJDQo+PiA+ DQo+PiA+IEluIGFuIEhUVFBTIHRyYW5zYWN0aW9uLCB0aGUgSFRUUFMgc2VydmVyIHByb3ZpZGVz IHRoZSBjbGllbnQgd2l0aCANCj4+ID4gYSBjZXJ0aWZpY2F0ZSwgYW5kIGl0IGNhbiBvcHRpb25h bGx5IGluY2x1ZGUgYW4gT0NTUCByZXNwb25zZSAoInN0YXBsZSINCj4+ID4gaXQgdG8gdGhlIHRy YW5zYWN0aW9uKS4NCj4+ID4NCj4+ID4gQSBjZXJ0aWZpY2F0ZSBjb250YWlucyBhIHZhbGlkaXR5 IGludGVydmFsLCBhIGtleSwgYW5kIHNvbWUgbmFtZXMvVE5zLg0KPj4gPiBBbiBPQ1NQIHJlc3Bv bnNlcyBjb250YWlucyBhIHZhbGlkaXR5IGludGVydmFsLCBhIGNlcnRpZmljYXRlIElEIA0KPj4g PiAoaS5lLiwgYSBoYXNoKSwgYW5kIGEgc3RhdHVzIChnb29kL3Jldm9rZWQvdW5rbm93bikuICBJ biB0aGUgd2ViIA0KPj4gPiBQS0ksIGNlcnRpZmljYXRlcyBhcmUgcmVxdWlyZWQgdG8gYmUgbm8g bW9yZSB0aGFuIDM5IG1vbnRocyBsb25nLCANCj4+ID4gYW5kIE9DU1AgcmVzcG9uc2VzIG5vIG1v cmUgdGhhbiAxMCBkYXlzLg0KPj4gPg0KPj4gPiBJZGVhbGx5LCBhIGNsaWVudCBvbmx5IGNvbnNp ZGVycyBhIGNlcnRpZmljYXRlIHZhbGlkIGlmIGl0IGlzIA0KPj4gPiBhY2NvbXBhbmllZCBieSBh biBPQ1NQIHJlc3BvbnNlLiAgSW4gcHJhY3RpY2UsIHRoaXMgaXMgbm90IGFsd2F5cyANCj4+ID4g cG9zc2libGU7IGJlY2F1c2UgT0NTUCBxdWVyaWVzIGZhaWwgYXJvdW5kIDMlIG9mIHRoZSB0aW1l LCBicm93c2VycyANCj4+ID4gY2FuJ3QgcmVxdWlyZSBPQ1NQLiAgVGhpcyBvcGVyYXRpb25hbCBm YWN0IHdpbGwgYmUgaW1wb3J0YW50IGJlbG93LCANCj4+ID4gYnV0IHdlIHdpbGwgY29udGludWUg dG8gaGF2ZSBzY29waW5nIGNlcnQgbGlmZXRpbWVzIGFzIGFuIG9iamVjdGl2ZS4NCj4+ID4NCj4+ ID4gSW4gdGhlIHdlYiBQS0ksIHRoZXJlIGFyZSBiYXNpY2FsbHkgdGhyZWUgcmV2b2NhdGlvbiBj aGVja2luZyBtb2RhbGl0aWVzOg0KPj4gPg0KPj4gPiAxLiBMaXZlIE9DU1AgY2hlY2tpbmcgW1JG QzYwNjldDQo+PiA+IDIuIE9DU1Agc3RhcGxpbmcgLyBtdXN0X3N0YXBsZSBbUkZDNjA2NiwgDQo+ PiA+IGRyYWZ0LWhhbGxhbWJha2VyLXRsc2ZlYXR1cmVdIDMuIFNob3J0LWxpdmVkIGNlcnRpZmlj YXRlcyAofk9DU1ANCj4+ID4gbGlmZXRpbWUpDQo+PiA+DQo+PiA+IChUaGUgbGFzdCBvZiB0aGVz ZSBpcyByZWxhdGl2ZWx5IG5vdmVsLCBhbmQgaGFzIG5vdCBiZWVuIGRlcGxveWVkLg0KPj4gPiBO ZWl0aGVyIGhhcyBtdXN0LXN0YXBsZS4gIEJ1dCB0aGV5J3JlIGJvdGggcHJldHR5IHRyaXZpYWws IGFuZCANCj4+ID4gY291bGQgYmUgZm9sZGVkIGludG8gYSBTVElSIGFyY2hpdGVjdHVyZSBwcmV0 dHkgZWFzaWx5LikNCj4+ID4NCj4+ID4gUmlnaHQgbm93LCBhYm91dCA5MCUgb2YgVExTIHRyYW5z YWN0aW9ucyB1c2UgbGl2ZSBPQ1NQLCBhbmQgYWJvdXQgMTAlLg0KPj4gPiBDQXMgYW5kIGJyb3dz ZXJzIGRlYXJseSB3YW50IHRoZSB3b3JsZCB0byBtb3ZlIHRvd2FyZCBzdGFwbGVkIE9DU1AgDQo+ PiA+IG9yIHNob3J0LWxpdmVkIGNlcnRzLCBiZWNhdXNlIHRoZXNlIHJlZHVjZXMgbGF0ZW5jeSBh bmQgaW1wcm92ZSB0aGUgDQo+PiA+IHF1YWxpdHkgb2YgcmV2b2NhdGlvbiBpbmZvcm1hdGlvbi4N Cj4+ID4NCj4+ID4gUmV2b2NhdGlvbiBmb3IgQ0EgY2VydGlmaWNhdGVzIGlzIGN1cnJlbnRseSBk b25lIGJ5IGhhdmluZyBicm93c2VycyANCj4+ID4gZG93bmxvYWQgYSBsaXN0IGZyb20gYSBjZW50 cmFsaXplZCBzZXJ2ZXIsIHNpbmNlIHRoZXJlJ3Mgbm8gd2F5IHRvIA0KPj4gPiBzdGFwbGUgbW9y ZSB0aGFuIG9uZSBPQ1NQIHJlc3BvbnNlLiAgVGhhdCBzb2x1dGlvbiB3b3JrcyBPSyBmb3IgdGhl IA0KPj4gPiB3ZWIsIGJ1dCBpZiBJIHdlcmUgZGVzaWduaW5nIHNvbWV0aGluZyBkZSBub3ZvLCBJ IHdvdWxkIHByb2JhYmx5IA0KPj4gPiB1c2UgbXVsdGktc3RhcGxpbmcgYXMgd2VsbC4NCj4+ID4N Cj4+ID4NCj4+ID4gIyBBcHBseWluZyB0aGlzIGV4cGVyaWVuY2UgdG8gU1RJUg0KPj4gPg0KPj4g PiBNb3N0IG9mIHRoZSBiZWxvdyBhcHBlYXIgdG8gYmUgZGVzaXJlZCBwcm9wZXJ0aWVzIGJ5IHRo ZSBXRzoNCj4+ID4NCj4+ID4gKiBWZXJpZmllciBuZWVlZHMgdG8ga25vdyB0aGF0IGEgY2VydCBp cyB2YWxpZCBmb3IgYSBzcGVjaWZpYyANCj4+ID4gbnVtYmVyDQo+PiA+ICogU2NvcGVkIGNlcnQg bGlmZXRpbWU6IExpbWl0IGNlcnRzIHRvIH4xd2VlayBsaWZldGltZSAoYnkgT0NTUCBpZiANCj4+ ID4gaXNzdWVkIGxvbmdlcikNCj4+ID4gKiBDYWxsZXIgcHJpdmFjeTogRG9uJ3QgcmVwb3J0IHdo YXQgY2FsbHMgc29tZW9uZSByZWNlaXZlcyB0byBhIA0KPj4gPiBjZW50cmFsIHNlcnZlcg0KPj4g PiAqIENhcnJpZXIgcHJpdmFjeTogRG9uJ3QgYWxsb3cgYSB0aGlyZCBwYXJ0eSB0byBmaWd1cmUg b3V0IGFsbCB0aGUgDQo+PiA+IG51bWJlcnMgYSBjYXJyaWVyIGhvbGRzDQo+PiA+ICogTWluaW1p emUgdGhlIHJhdGUgYXQgd2hpY2ggdGhlIENBIGhhcyB0byBzaWduIHRoaW5ncw0KPj4gPiAqIFRv bGVyYXRlIG91dGFnZXMgYXQgdGhlIENBDQo+PiA+DQo+PiA+IEknbSBnb2luZyB0byBhc3N1bWUg Zm9yIG5vdyB0aGF0IHdlIHdpbGwgbm90IGRvIGxpdmUgT0NTUC4gIEl0IA0KPj4gPiB2aW9sYXRl cyB0aGUgY2FsbGVyIHByaXZhY3kgcmVxdWlyZW1lbnQsIGFuZCBhcyBkaXNjdXNzZWQgYWJvdmUs IGl0IA0KPj4gPiBqdXN0IHN1Y2tzIG9wZXJhdGlvbmFsbHkuICBTbyBTVElSIHNob3VsZCByZXF1 aXJlIE9DU1AgdG8gYmUgc2VudCANCj4+ID4gaW4gInN0YXBsZWQiIGZvcm0sIHdoaWNoIHByb2Jh Ymx5IG1lYW5zIHNlbmRpbmcgaXQgaW4gSWRlbnRpdHktSW5mby4NCj4+ID4gQW5kIHdoaWxlIHdl J3JlIGF0IGl0LCB3ZSBzaG91bGQgYWxzbyBkbyAibXVsdGktc3RhcGxpbmciIC0tIHNlbmQgDQo+ PiA+IGFuIE9DU1AgcmVzcG9uc2UgZm9yIENBIGNlcnRzIGFzIHdlbGwuDQo+PiA+DQo+PiA+IFNv IGlmIHdlIGNvbnNpZGVyIGEgc2VydmVyIHdpdGggNTBrIFROcyAvIGJsb2NrcywgdGhhdCBsZWF2 ZXMgdXMgDQo+PiA+IHdpdGggYmFzaWNhbGx5IDMgb3B0aW9uczoNCj4+ID4NCj4+ID4gMS4gNTBr IHNob3J0LWxpdmVkIGNlcnRzIChubyBPQ1NQKQ0KPj4gPiAyLiA1MGsgbG9uZy1saXZlZCBjZXJ0 cyBzY29wZWQgdG8gVE5zICsgZ2VuZXJpYyBPQ1NQIDMuIDEgDQo+PiA+IGxvbmctbGl2ZWQgY2Vy dCBub3Qgc2NvcGVkIHRvIFROIChvciBhIGZldyBsb29zZWx5IHNjb3BlZCkgKyBPQ1NQIA0KPj4g PiB3aXRoIFROIGluZm8NCj4+ID4NCj4+ID4gKEFzIEkgZGlkbid0IHF1aXRlIGdldCB0byBzYXkg aW4gdGhlIG1lZXRpbmcsIHJlZ2FyZGxlc3Mgb2YgdGhlIA0KPj4gPiBhcHByb2FjaCwgeW91IGhh dmUgdG8gaGF2ZSA1MGsgb2YgKnNvbWV0aGluZyouKSAgT2YgdGhlc2UsIGl0IHNlZW1zIA0KPj4g PiBsaWtlIHRoZSBwcmVmZXJlbmNlIG9yZGVyIGlzIDIgPiAxID4gMy4NCj4+ID4NCj4+ID4gT3B0 aW9uIDMgaXMgYmFkIGZyb20gc2V2ZXJhbCBwZXJzcGVjdGl2ZXM6DQo+PiA+ICogUHV0dGluZyBU TiBpbmZvIGluIHRoZSBPQ1NQIHJlc3BvbnNlIGVuYWJsZXMgc29tZW9uZSB0byB0cmF3bCBmb3Ig DQo+PiA+IG51bWJlcnMgdW5sZXNzIHlvdSBhY2Nlc3MtY29udHJvbCB0aGUgT0NTUCBzZXJ2ZXIs IHNvIHlvdSBpbmhlcml0IGEgDQo+PiA+IHJlcXVpcmVtZW50IHRvIGRvIHRoYXQuDQo+PiA+ICog V2l0aCB0aGUgcmF0ZSBvZiBjaHVybiBpbiBudW1iZXIgYXNzaWdubWVudHMsIHlvdSdyZSBwcm9i YWJseSANCj4+ID4gZ29pbmcgdG8gaGF2ZSB0byB1cGRhdGUgdGhlIGxvbmctbGl2ZWQgY2VydCBw cmV0dHkgZnJlcXVlbnRseSBhbnl3YXkuDQo+PiA+ICogUHV0dGluZyBUTi1zcGVjaWZpYyBzdHVm ZiBpbiBjZXJ0cyBpcyBiZXR0ZXIgdGhhbiBwdXR0aW5nIGl0IGluIA0KPj4gPiBPQ1NQLiAgQXMg YmFkIGFzIFguNTA5IGxpYnJhcmllcyBjYW4gYmUsIE9DU1AgbGlicmFyaWVzIGFyZSBtdWNoIA0K Pj4gPiB3b3JzZS4NCj4+ID4NCj4+ID4gT3B0aW9uIDEgaXMgbWFpbmx5IGJhZCBmcm9tIHRoZSBw ZXJzcGVjdGl2ZSBvZiBDQSBsb2FkIGFuZCBvdXRhZ2VzLg0KPj4gPiBXaXRoIE9wdGlvbiAyLCBp ZiB0aGUgQ0EgZ29lcyBkb3duLCBjbGllbnQgY2FuIGNvbnRpbnVlIHRvIHVzZSB0aGUgDQo+PiA+ IGxvbmctbGl2ZWQgY2VydCBhbmQganVzdCBub3QgYm90aGVyIGRvaW5nIE9DU1AgKHZzLiB0b2xl cmF0aW5nIGFuIA0KPj4gPiBleHBpcmVkIGNlcnQpLiAgU2xpZ2h0bHkgY2xlYW5lci4gIFBsdXMs IHRoZXJlJ3MgYSBsb3QgbW9yZSANCj4+ID4gZXhwZXJpZW5jZSBjYWNoaW5nIE9DU1AgdGhhbiBu ZXcgY2VydHMuICBPQ1NQIHNpZ25pbmcgY2FuIGFsc28gYmUgDQo+PiA+IGRlbGVnYXRlZCwgc28g eW91IGNhbiBoYXZlIHRoZSByZWN1cnJpbmcgb3BlcmF0aW9uIGRvbmUgYnkgYSBsb3dlci1yaXNr IGtleS4NCj4+ID4NCj4+ID4gT3B0aW9uIDIgc2hvdWxkIGJlIHByZXR0eSBlYXN5IHRvIGF1dG9t YXRlLiAgWW91IGNhbiBwcm9iYWJseSANCj4+ID4gcmUtdXNlIHRvb2xpbmcgZm9yIE9DU1Agc3Rh cGxpbmcgdGhhdCBoYXMgYWxyZWFkeSBiZWVuIGRldmVsb3BlZCANCj4+ID4gZm9yIHVzZSB3aXRo IEhUVFBTLiAgSWYgeW91J3JlIGEgYmlnIGJveCBzaWduaW5nIGZvciBhIGJ1bmNoIG9mIA0KPj4g PiBudW1iZXJzLCB5b3UgZG8gbmVlZCB0byBzZWxlY3QgdGhlIHJpZ2h0IGNlcnQgYW5kIE9DU1Ag cmVzcG9uc2UgZm9yIA0KPj4gPiBhIGdpdmVuIGNhbGwsIGJ1dCB0aGF0J3MgYSBwcmV0dHkgc2lt cGxlIGxvb2t1cCB0YWJsZS4NCj4+ID4gPFNUSVIucHB0eD5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiBzdGlyIG1haWxpbmcgbGlzdA0KPj4gPiBz dGlyQGlldGYub3JnDQo+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3Rpcg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBzdGlyIG1haWxpbmcgbGlzdA0KPj4gc3RpckBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+DQo+IFRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9w cmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNp cGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkg aW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMp LiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxs IGNvcGllcyBvZiB0aGUgbWVzc2FnZS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzdGlyIG1haWxpbmcgbGlzdA0Kc3RpckBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3RpciBtYWlsaW5nIGxpc3QNCnN0aXJAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0K From nobody Tue Jul 28 12:27:34 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82ECB1B2E4B for ; Tue, 28 Jul 2015 12:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5g7GHH2VIGgg for ; Tue, 28 Jul 2015 12:27:29 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 37BC41B2E49 for ; Tue, 28 Jul 2015 12:27:29 -0700 (PDT) From: Henning Schulzrinne To: "PFAUTZ, PENN L" , "Gorman, Pierce A [CTO]" Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAJs4gIAABZ6AgAAApgCAAAEaoIAAUo6AgAAA4XA= Date: Tue, 28 Jul 2015 19:27:26 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: att.com; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 5:KepUn7tVf613p3dhoLS77H3MRzqi+z1cz7IADgt+wkeDDeTHitonXfnGQpNN6Xv3B8sms6tLxPGH0qHCmWrhmRkaAvOKYgL2Q36Z2oNt/bCAv+F75RPPwFptxyA2chM5HlI4Ftyhiv8LdsHanZagkQ==; 24:29zAiK/0WoMpOYQLZqFqFgZYPN2WcWGd4YeqEfm867RtamilKcwNTt2+qxrsJZH+gJkjeDMDjNBIjHIq5MZ0+5tU2BdQWDmjpqCNsyhUuJM=; 20:4EVhHQcLKVqhKQGFuDuHG86qTtXeQ7A1FtMTDQK85oxEiR5CCsuHAgzl1LoGW8tZq4Lm68lwI6nz+ziqJ3SsFQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0634; cy1pr09mb0634: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(77156002)(19580395003)(102836002)(54356999)(99286002)(50986999)(106116001)(33656002)(86362001)(5003600100002)(93886004)(551934003)(74316001)(2656002)(66066001)(46102003)(87936001)(15975445007)(76576001)(189998001)(5002640100001)(5890100001)(19580405001)(5001920100001)(2900100001)(92566002)(77096005)(62966003)(2950100001)(5001770100001)(76176999)(40100003)(5001960100002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2015 19:27:26.6904 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 19:27:32 -0000 VGhhdCB3YXMgY2VydGFpbmx5IG9uZSBvZiB0aGUgbW9kZWxzIHRoYXQgaGF2ZSBiZWVuIGRpc2N1 c3NlZCBpbiB0aGUgcGFzdC4gUGFydGljdWxhcmx5IGZvciBzbWFsbCBjYXJyaWVycywgdGhpcyB3 b3VsZCBsaWtlbHkgcmVkdWNlIHRoZSBvcGVyYXRpb25hbCBpbXBhY3QgdG8gYSBjb25maWd1cmF0 aW9uIG9wdGlvbiBpbiB0aGUgU0JDLg0KDQpUaGUgZGlzYWR2YW50YWdlIG9mIHRoaXMgbW9kZWwg aXMgY2FsbGVyIHByaXZhY3k6IElmIHRoZSBjZXJ0IGlzIHN0b3JlZCBhdCBhIG51bWJlcmluZyBh dXRob3JpdHksIGl0IHdvdWxkIGJlIGVhc3kgZm9yIHRoYXQgYXV0aG9yaXR5IHRvIGtub3cgd2hp Y2ggY2FycmllciBpcyByZWNlaXZpbmcgY2FsbHMgZnJvbSB3aG9tLiAoSXQncyBub3QgdGhlIGNv bXBsZXRlIG1ldGEgZGF0YSBzaW5jZSBpdCdzIGxhY2tpbmcgdGhlIGNhbGxlZSBpbmZvcm1hdGlv bi4pDQoNCkhvd2V2ZXIsIHVubGVzcyB0aGUgVE4tdG8tTFJOIChpbiB0aGUgVVMpIG1hcHBpbmcg aXMgY2FjaGVkLCB0aGlzICJsZWFrIiBhbHJlYWR5IGV4aXN0cyB0b2RheS4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBGQVVUWiwgUEVOTiBMIFttYWlsdG86cHAzMTI5QGF0 dC5jb21dIA0KU2VudDogVHVlc2RheSwgSnVseSAyOCwgMjAxNSAzOjE0IFBNDQpUbzogSGVubmlu ZyBTY2h1bHpyaW5uZSA8SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292PjsgR29ybWFuLCBQaWVy Y2UgQSBbQ1RPXSA8UGllcmNlLkdvcm1hbkBzcHJpbnQuY29tPg0KQ2M6IHN0aXJAaWV0Zi5vcmcN ClN1YmplY3Q6IFJFOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBhbmQgUHJpdmFjeQ0KDQpGb3JnaXZl IG1lIGJ1dCBteSByZXB0aWxlIGJyYWluIGtlZXBzIHdoaXNwZXJpbmcgaW4gbXkgZWFyIHRoYXQg dGhpcyB3b3VsZCBiZSBhIGxvdCBlYXNpZXIgaWYgd2Ugc2ltcGx5IGhhZCBhIG51bWJlcmluZyBy ZWdpc3RyeSwgd2hldGhlciBkaXN0cmlidXRlZCBvciBjZW50cmFsaXplZCAtIGxpa2Ugd2UgbmVl ZCBhbnl3YXkgZm9yIGF0IGxlYXN0IGZvciBudW1iZXIgcG9ydGFiaWxpdHkgLSB0aGF0IGFsc28g Y29udGFpbmVkIHRoZSBwdWJsaWMga2V5cy4gTm8gdGVkaW91cyBtdWNraW5nIGFib3V0IGluIGN5 YmVyc3BhY2Ugd2l0aCBjZXJ0cywgQ1JMcywgb3IgT0NTUC4NCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBzdGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSGVubmluZyBTY2h1bHpyaW5uZQ0KU2VudDogVHVlc2RheSwgSnVseSAyOCwg MjAxNSAxMDoyNCBBTQ0KVG86IEdvcm1hbiwgUGllcmNlIEEgW0NUT10NCkNjOiBzdGlyQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3N0aXJdIE9uIE9DU1AsIFROcywgYW5kIFByaXZhY3kNCg0KSW4g dGhlIFVTIGFsb25lLCB3ZSBoYXZlIGFib3V0IDQwMDAgY2FycmllcnMuIE1hbmFnaW5nIHRoZSBy ZXB1dGF0aW9uIG9mIHRoYXQgbWFueSBlbnRpdGllcywgcmVsaWFibHkgKGkuZS4sIHdpdGhvdXQg bWFraW5nIGZhbHNlIHBvc2l0aXZlL25lZ2F0aXZlIG1pc3Rha2VzKSBzZWVtcyBhIHdob2xlIGxv dCBtb3JlIG1hbnVhbCBlZmZvcnQgdGhhbiBzdG9yaW5nIGJhZ3Mgb2YgYml0cy4gU3RvcmFnZSBh bmQgYXV0b21hdGlvbiBpcyBjaGVhcCwgaHVtYW4ganVkZ2VtZW50IGFuZCBkZWFsaW5nIHdpdGgg bWlzdGFrZXMgaXMgZXhwZW5zaXZlLg0KDQpPYnZpb3VzbHksIG5vdGhpbmcgaW4gdGhlIGFyY2hp dGVjdHVyZSBwcmV2ZW50cyB3aWxkY2FyZCBjZXJ0aWZpY2F0ZXMuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBzdGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgR29ybWFuLCBQaWVyY2UgQSBbQ1RPXQ0KU2VudDogVHVlc2RheSwgSnVseSAy OCwgMjAxNSAxMDoxNCBBTQ0KVG86IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4Pg0KQ2M6IHN0 aXJAaWV0Zi5vcmc7IEFsZXggQm9ib3RlayA8YWxleEBib2JvdGVrLm5ldD47IEJyaWFuIFJvc2Vu IDxickBicmlhbnJvc2VuLm5ldD4NClN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBh bmQgUHJpdmFjeQ0KDQpJIHRob3VnaHQgdGhlIGRpc2N1c3Npb24gd2FzIG9uIGtleS9jZXJ0IG1h bmFnZW1lbnQuICBJJ20gYXNraW5nIGlmIEkgdW5kZXJzdG9vZCB0aGUgc3VnZ2VzdGlvbiB0byBt aW5pbWl6ZSByZXF1aXJlbWVudHMuICBIb3cgaXMgdGhhdCBvZmYgdG9waWM/DQoNCkJlc3QgcmVn YXJkcywNCg0KDQpQaWVyY2UgR29ybWFuDQpDb3JlIE5ldHdvcmsgUGxhbm5pbmcNCk86IDkxMy00 MzktNDM2OA0KcGllcmNlLmdvcm1hbkBzcHJpbnQuY29tDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxiQGlwdi5zeF0NClNlbnQ6 IEp1bHkgMjgsIDIwMTUgOToxMiBBTQ0KVG86IEdvcm1hbiwgUGllcmNlIEEgW0NUT10gPFBpZXJj ZS5Hb3JtYW5Ac3ByaW50LmNvbT4NCkNjOiBBbGV4IEJvYm90ZWsgPGFsZXhAYm9ib3Rlay5uZXQ+ OyBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+OyBzdGlyQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3N0aXJdIE9uIE9DU1AsIFROcywgYW5kIFByaXZhY3kNCg0KT24gVHVlLCBKdWwgMjgs IDIwMTUgYXQgOTo1MSBBTSwgR29ybWFuLCBQaWVyY2UgQSBbQ1RPXSA8UGllcmNlLkdvcm1hbkBz cHJpbnQuY29tPiB3cm90ZToNCj4gIkxhcmdlIHNjYWxlIGNlcnRpZmljYXRlIG1hbmFnZW1lbnQg aXMgZXhwZW5zaXZlLCBhbmQgVE4tc3BlY2lmaWMgY2VydGlmaWNhdGVzIGFyZSB1bm5lZWRlZCBm b3Igc2VjdXJpbmcgY2FsbHMgcGxhY2VkIGJ5IHBhcnRpZXMgd2hvIGNob29zZSB0byBwbGFjZSBj YWxscyB0aHJvdWdoIGEgc2luZ2xlIHJlcHV0YWJsZSB0ZWxlcGhvbmUgc2VydmljZSBwcm92aWRl ci4iDQo+DQo+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgZm9yICJvbi1uZXQiIGNhbGxzLCBTVElSIG1l dGhvZG9sb2d5IGlzIHVubmVjZXNzYXJ5Pw0KDQpUaGlzIHNlZW1zIGEgbGl0dGxlIG9mZi10b3Bp YyBmb3IgdGhpcyBsaXN0Lg0KDQotLVJpY2hhcmQNCg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+DQo+ DQo+IFBpZXJjZSBHb3JtYW4NCj4gQ29yZSBOZXR3b3JrIFBsYW5uaW5nDQo+IE86IDkxMy00Mzkt NDM2OA0KPiBwaWVyY2UuZ29ybWFuQHNwcmludC5jb20NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleCBCb2JvdGVrIFttYWlsdG86YWxleEBib2JvdGVrLm5l dF0NCj4gU2VudDogSnVseSAyNywgMjAxNSAxMTozNiBQTQ0KPiBUbzogQnJpYW4gUm9zZW4gPGJy QGJyaWFucm9zZW4ubmV0PjsgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+DQo+IENjOiBzdGly QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBhbmQgUHJpdmFj eQ0KPg0KPiBXaGF0IG1vdGl2YXRpb24gd291bGQgYSBjYXJyaWVyIGhhdmUgdG8gY2hvb3NlIGFu eSBtb2RlbCBvdGhlciB0aGFuIGNhcnJpZXIgc2lnbmluZyB1c2luZyBvbmUgb2YgYSB2ZXJ5IGxp bWl0ZWQgc2V0IG9mIGNhcnJpZXItb3duZWQga2V5cz8gIExhcmdlIHNjYWxlIGNlcnRpZmljYXRl IG1hbmFnZW1lbnQgaXMgZXhwZW5zaXZlLCBhbmQgVE4tc3BlY2lmaWMgY2VydGlmaWNhdGVzIGFy ZSB1bm5lZWRlZCBmb3Igc2VjdXJpbmcgY2FsbHMgcGxhY2VkIGJ5IHBhcnRpZXMgd2hvIGNob29z ZSB0byBwbGFjZSBjYWxscyB0aHJvdWdoIGEgc2luZ2xlIHJlcHV0YWJsZSB0ZWxlcGhvbmUgc2Vy dmljZSBwcm92aWRlci4gIEFueW9uZSBjYW4gZ2V0IG1hbnkgY2VydGlmaWNhdGVzLCBldmVuIGEg ZnJlZSBvbmVzIGFub255bW91c2x5IGZyb20gc29tZSBpc3N1ZXJzLiAgSXQgaXMgdHlwaWNhbGx5 IGEgY29tYmluYXRpb24gb2YgdGhlIHN0cmVuZ3RoIG9mIHRoZSBlbmQtdXNlciBhdXRoZW50aWNh dGlvbiBwZXJmb3JtZWQgYnkgdGhlIHNlcnZpY2UgcHJvdmlkZXIgKG9yIGNlcnRpZmljYXRlIGlz c3VlciBpbiBhIHByb3ZpZGVyLWFnbm9zdGljIG1vZGVsKSBhbmQgdGhlIGlkZW50aXR5J3MgaGlz dG9yeSB0aGF0IGFyZSBtb3N0IHVzZWZ1bCBpbiBzZWN1cml0eS4NCj4NCj4gSWYgd2UncmUgdHJ5 aW5nIHRvIHNlY3VyZSB0aGUgY3VycmVudCB0ZWxlcGhvbmUgc3lzdGVtLCBETlMtbGlrZSBrZXkg cmVwb3NpdG9yaWVzIGEgbGEgREtJTSBvciBwZXJoYXBzIGEgc21hbGwgbnVtYmVyIChjb21wYXJl ZCB0byB0aGUgbnVtYmVyIG9mIFROcykgb2YgY2VydGlmaWNhdGVzIGFyZSBmYXIgbW9yZSBwcmFj dGljYWwuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IEFsZXgNCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiBGcm9tOiBzdGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NCj4+IFNlbnQ6IE1vbmRheSwgSnVseSAyNywgMjAxNSA3 OjQwIFBNDQo+PiBUbzogUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+DQo+PiBDYzogc3RpckBp ZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzdGlyXSBPbiBPQ1NQLCBUTnMsIGFuZCBQcml2YWN5 DQo+Pg0KPj4gV2hhdCB0aGlzIG1lYW5zIGluIHByYWN0aWNlIGlzIHRoYXQgaXTigJlzIFROIHBl ciBjZXJ0Lg0KPj4NCj4+IEkgd291bGRu4oCZdCBzYXkgdGhhdCBpdOKAmXMgaW1wb3NzaWJsZSBm b3IgYSBjYXJyaWVyIHRvIG1haW50YWluIGRvemVucyANCj4+IG9mIGNvcGllcyBvZiBtaWxsaW9u cyBvZiBwcml2YXRlIGtleXMgc2VjdXJlbHksIGJ1dCBpdOKAmXMgaGFyZC4gIFlvdSANCj4+IG5l ZWQgbXVsdGlwbGUgY29waWVzIGJlY2F1c2UgeW91IGhhdmUgbXVsdGlwbGUgZWxlbWVudHMgdGhh dCBjYW4gDQo+PiBpbml0aWF0ZSBhIGNhbGwsIGFuZCB5b3UgZG9u4oCZdCB3YW50IHRvIGRlcGVu ZCBvbiBhIGNlbnRyYWxpemVkIA0KPj4gcmVzb3VyY2UgdG8gZG8gc29tZXRoaW5nIGFzIGJhc2lj IGFzIGNyZWF0ZSBhIGNhbGwuDQo+Pg0KPj4gSSB0aGluayBpdOKAmXMgaGFyZCBlbm91Z2ggdGhh dCBSRVFVSVJJTkcgY2VydCBwZXIgVE4gaXMgbm90IGFjY2VwdGFibGUuDQo+Pg0KPj4gRm9sa3Mg d2l0aCBtb3JlIGludGltYXRlIGtub3dsZWRnZSBvZiBjYXJyaWVyIFNJUCBpbmZyYXN0cnVjdHVy ZSANCj4+IG1pZ2h0IGhhdmUgbW9yZSBpbnNpZ2h0IHRoYW4gSSBkby4gIEl0IG1heSBiZSBhY2Nl cHRhYmxlIHRvIGhhdmUgYSANCj4+IGNlbnRyYWxpemVkIHJlc291cmNlIHRvIG1hbmFnZSBtaWxs aW9ucyBvZiBrZXlzLg0KPj4NCj4+IEJyaWFuDQo+Pg0KPj4gPiBPbiBKdWwgMjcsIDIwMTUsIGF0 IDY6MTMgUE0sIFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4PiB3cm90ZToNCj4+ID4NCj4+ID4g QWZ0ZXIgdGhlIFNUSVIgbWVldGluZyBpbiBQcmFndWUsIEhlbm5pbmcgYW5kIEkgc3BlbnQgYSBm ZXcgbWludXRlcyANCj4+ID4gdGFsa2luZyB0aHJvdWdoIG9wdGlvbnMgZm9yIHJldm9jYXRpb24g Y2hlY2tpbmcgYW5kIGNlcnRpZmljYXRlIA0KPj4gPiBzY29waW5nLCBhbmQgSSB0aGluayB3ZSBo YXZlIGEgYmV0dGVyIGlkZWEgb2Ygd2hhdCB0aGUgb3B0aW1hbCANCj4+ID4gc29sdXRpb24gbG9v a3MgbGlrZS4gIFNvbWUgbm90ZXMgYXJlIGJlbG93LCBhbmQgc29tZSBzbGlkZXMgd2l0aCANCj4+ ID4gcGljdHVyZXMgYXR0YWNoZWQuDQo+PiA+DQo+PiA+IHRsO2RyOiBXZSBzaG91bGQ6DQo+PiA+ ICogS2VlcCBUTnMgaW4gY2VydGlmaWNhdGVzIGFuZCBub3QgYm90aGVyIHdpdGggYW55IE9DU1Ag ZXh0ZW5zaW9ucw0KPj4gPiAqIFJlcXVpcmUgSWRlbnRpdHktSW5mbyB0byBpbmNsdWRlIE9DU1Ag cmVzcG9uc2VzIGZvciBhbGwgY2VydHMgaW4gDQo+PiA+IHRoZSBjaGFpbg0KPj4gPg0KPj4gPg0K Pj4gPiAjIEJhY2tncm91bmQ6IFJldm9jYXRpb24gaW4gdGhlIHdlYiBQS0kNCj4+ID4NCj4+ID4g SW4gYW4gSFRUUFMgdHJhbnNhY3Rpb24sIHRoZSBIVFRQUyBzZXJ2ZXIgcHJvdmlkZXMgdGhlIGNs aWVudCB3aXRoIA0KPj4gPiBhIGNlcnRpZmljYXRlLCBhbmQgaXQgY2FuIG9wdGlvbmFsbHkgaW5j bHVkZSBhbiBPQ1NQIHJlc3BvbnNlICgic3RhcGxlIg0KPj4gPiBpdCB0byB0aGUgdHJhbnNhY3Rp b24pLg0KPj4gPg0KPj4gPiBBIGNlcnRpZmljYXRlIGNvbnRhaW5zIGEgdmFsaWRpdHkgaW50ZXJ2 YWwsIGEga2V5LCBhbmQgc29tZSBuYW1lcy9UTnMuDQo+PiA+IEFuIE9DU1AgcmVzcG9uc2VzIGNv bnRhaW5zIGEgdmFsaWRpdHkgaW50ZXJ2YWwsIGEgY2VydGlmaWNhdGUgSUQgDQo+PiA+IChpLmUu LCBhIGhhc2gpLCBhbmQgYSBzdGF0dXMgKGdvb2QvcmV2b2tlZC91bmtub3duKS4gIEluIHRoZSB3 ZWIgDQo+PiA+IFBLSSwgY2VydGlmaWNhdGVzIGFyZSByZXF1aXJlZCB0byBiZSBubyBtb3JlIHRo YW4gMzkgbW9udGhzIGxvbmcsIA0KPj4gPiBhbmQgT0NTUCByZXNwb25zZXMgbm8gbW9yZSB0aGFu IDEwIGRheXMuDQo+PiA+DQo+PiA+IElkZWFsbHksIGEgY2xpZW50IG9ubHkgY29uc2lkZXJzIGEg Y2VydGlmaWNhdGUgdmFsaWQgaWYgaXQgaXMgDQo+PiA+IGFjY29tcGFuaWVkIGJ5IGFuIE9DU1Ag cmVzcG9uc2UuICBJbiBwcmFjdGljZSwgdGhpcyBpcyBub3QgYWx3YXlzIA0KPj4gPiBwb3NzaWJs ZTsgYmVjYXVzZSBPQ1NQIHF1ZXJpZXMgZmFpbCBhcm91bmQgMyUgb2YgdGhlIHRpbWUsIGJyb3dz ZXJzIA0KPj4gPiBjYW4ndCByZXF1aXJlIE9DU1AuICBUaGlzIG9wZXJhdGlvbmFsIGZhY3Qgd2ls bCBiZSBpbXBvcnRhbnQgYmVsb3csIA0KPj4gPiBidXQgd2Ugd2lsbCBjb250aW51ZSB0byBoYXZl IHNjb3BpbmcgY2VydCBsaWZldGltZXMgYXMgYW4gb2JqZWN0aXZlLg0KPj4gPg0KPj4gPiBJbiB0 aGUgd2ViIFBLSSwgdGhlcmUgYXJlIGJhc2ljYWxseSB0aHJlZSByZXZvY2F0aW9uIGNoZWNraW5n IG1vZGFsaXRpZXM6DQo+PiA+DQo+PiA+IDEuIExpdmUgT0NTUCBjaGVja2luZyBbUkZDNjA2OV0N Cj4+ID4gMi4gT0NTUCBzdGFwbGluZyAvIG11c3Rfc3RhcGxlIFtSRkM2MDY2LCANCj4+ID4gZHJh ZnQtaGFsbGFtYmFrZXItdGxzZmVhdHVyZV0gMy4gU2hvcnQtbGl2ZWQgY2VydGlmaWNhdGVzICh+ T0NTUA0KPj4gPiBsaWZldGltZSkNCj4+ID4NCj4+ID4gKFRoZSBsYXN0IG9mIHRoZXNlIGlzIHJl bGF0aXZlbHkgbm92ZWwsIGFuZCBoYXMgbm90IGJlZW4gZGVwbG95ZWQuDQo+PiA+IE5laXRoZXIg aGFzIG11c3Qtc3RhcGxlLiAgQnV0IHRoZXkncmUgYm90aCBwcmV0dHkgdHJpdmlhbCwgYW5kIA0K Pj4gPiBjb3VsZCBiZSBmb2xkZWQgaW50byBhIFNUSVIgYXJjaGl0ZWN0dXJlIHByZXR0eSBlYXNp bHkuKQ0KPj4gPg0KPj4gPiBSaWdodCBub3csIGFib3V0IDkwJSBvZiBUTFMgdHJhbnNhY3Rpb25z IHVzZSBsaXZlIE9DU1AsIGFuZCBhYm91dCAxMCUuDQo+PiA+IENBcyBhbmQgYnJvd3NlcnMgZGVh cmx5IHdhbnQgdGhlIHdvcmxkIHRvIG1vdmUgdG93YXJkIHN0YXBsZWQgT0NTUCANCj4+ID4gb3Ig c2hvcnQtbGl2ZWQgY2VydHMsIGJlY2F1c2UgdGhlc2UgcmVkdWNlcyBsYXRlbmN5IGFuZCBpbXBy b3ZlIHRoZSANCj4+ID4gcXVhbGl0eSBvZiByZXZvY2F0aW9uIGluZm9ybWF0aW9uLg0KPj4gPg0K Pj4gPiBSZXZvY2F0aW9uIGZvciBDQSBjZXJ0aWZpY2F0ZXMgaXMgY3VycmVudGx5IGRvbmUgYnkg aGF2aW5nIGJyb3dzZXJzIA0KPj4gPiBkb3dubG9hZCBhIGxpc3QgZnJvbSBhIGNlbnRyYWxpemVk IHNlcnZlciwgc2luY2UgdGhlcmUncyBubyB3YXkgdG8gDQo+PiA+IHN0YXBsZSBtb3JlIHRoYW4g b25lIE9DU1AgcmVzcG9uc2UuICBUaGF0IHNvbHV0aW9uIHdvcmtzIE9LIGZvciB0aGUgDQo+PiA+ IHdlYiwgYnV0IGlmIEkgd2VyZSBkZXNpZ25pbmcgc29tZXRoaW5nIGRlIG5vdm8sIEkgd291bGQg cHJvYmFibHkgDQo+PiA+IHVzZSBtdWx0aS1zdGFwbGluZyBhcyB3ZWxsLg0KPj4gPg0KPj4gPg0K Pj4gPiAjIEFwcGx5aW5nIHRoaXMgZXhwZXJpZW5jZSB0byBTVElSDQo+PiA+DQo+PiA+IE1vc3Qg b2YgdGhlIGJlbG93IGFwcGVhciB0byBiZSBkZXNpcmVkIHByb3BlcnRpZXMgYnkgdGhlIFdHOg0K Pj4gPg0KPj4gPiAqIFZlcmlmaWVyIG5lZWVkcyB0byBrbm93IHRoYXQgYSBjZXJ0IGlzIHZhbGlk IGZvciBhIHNwZWNpZmljIA0KPj4gPiBudW1iZXINCj4+ID4gKiBTY29wZWQgY2VydCBsaWZldGlt ZTogTGltaXQgY2VydHMgdG8gfjF3ZWVrIGxpZmV0aW1lIChieSBPQ1NQIGlmIA0KPj4gPiBpc3N1 ZWQgbG9uZ2VyKQ0KPj4gPiAqIENhbGxlciBwcml2YWN5OiBEb24ndCByZXBvcnQgd2hhdCBjYWxs cyBzb21lb25lIHJlY2VpdmVzIHRvIGEgDQo+PiA+IGNlbnRyYWwgc2VydmVyDQo+PiA+ICogQ2Fy cmllciBwcml2YWN5OiBEb24ndCBhbGxvdyBhIHRoaXJkIHBhcnR5IHRvIGZpZ3VyZSBvdXQgYWxs IHRoZSANCj4+ID4gbnVtYmVycyBhIGNhcnJpZXIgaG9sZHMNCj4+ID4gKiBNaW5pbWl6ZSB0aGUg cmF0ZSBhdCB3aGljaCB0aGUgQ0EgaGFzIHRvIHNpZ24gdGhpbmdzDQo+PiA+ICogVG9sZXJhdGUg b3V0YWdlcyBhdCB0aGUgQ0ENCj4+ID4NCj4+ID4gSSdtIGdvaW5nIHRvIGFzc3VtZSBmb3Igbm93 IHRoYXQgd2Ugd2lsbCBub3QgZG8gbGl2ZSBPQ1NQLiAgSXQgDQo+PiA+IHZpb2xhdGVzIHRoZSBj YWxsZXIgcHJpdmFjeSByZXF1aXJlbWVudCwgYW5kIGFzIGRpc2N1c3NlZCBhYm92ZSwgaXQgDQo+ PiA+IGp1c3Qgc3Vja3Mgb3BlcmF0aW9uYWxseS4gIFNvIFNUSVIgc2hvdWxkIHJlcXVpcmUgT0NT UCB0byBiZSBzZW50IA0KPj4gPiBpbiAic3RhcGxlZCIgZm9ybSwgd2hpY2ggcHJvYmFibHkgbWVh bnMgc2VuZGluZyBpdCBpbiBJZGVudGl0eS1JbmZvLg0KPj4gPiBBbmQgd2hpbGUgd2UncmUgYXQg aXQsIHdlIHNob3VsZCBhbHNvIGRvICJtdWx0aS1zdGFwbGluZyIgLS0gc2VuZCANCj4+ID4gYW4g T0NTUCByZXNwb25zZSBmb3IgQ0EgY2VydHMgYXMgd2VsbC4NCj4+ID4NCj4+ID4gU28gaWYgd2Ug Y29uc2lkZXIgYSBzZXJ2ZXIgd2l0aCA1MGsgVE5zIC8gYmxvY2tzLCB0aGF0IGxlYXZlcyB1cyAN Cj4+ID4gd2l0aCBiYXNpY2FsbHkgMyBvcHRpb25zOg0KPj4gPg0KPj4gPiAxLiA1MGsgc2hvcnQt bGl2ZWQgY2VydHMgKG5vIE9DU1ApDQo+PiA+IDIuIDUwayBsb25nLWxpdmVkIGNlcnRzIHNjb3Bl ZCB0byBUTnMgKyBnZW5lcmljIE9DU1AgMy4gMSANCj4+ID4gbG9uZy1saXZlZCBjZXJ0IG5vdCBz Y29wZWQgdG8gVE4gKG9yIGEgZmV3IGxvb3NlbHkgc2NvcGVkKSArIE9DU1AgDQo+PiA+IHdpdGgg VE4gaW5mbw0KPj4gPg0KPj4gPiAoQXMgSSBkaWRuJ3QgcXVpdGUgZ2V0IHRvIHNheSBpbiB0aGUg bWVldGluZywgcmVnYXJkbGVzcyBvZiB0aGUgDQo+PiA+IGFwcHJvYWNoLCB5b3UgaGF2ZSB0byBo YXZlIDUwayBvZiAqc29tZXRoaW5nKi4pICBPZiB0aGVzZSwgaXQgc2VlbXMgDQo+PiA+IGxpa2Ug dGhlIHByZWZlcmVuY2Ugb3JkZXIgaXMgMiA+IDEgPiAzLg0KPj4gPg0KPj4gPiBPcHRpb24gMyBp cyBiYWQgZnJvbSBzZXZlcmFsIHBlcnNwZWN0aXZlczoNCj4+ID4gKiBQdXR0aW5nIFROIGluZm8g aW4gdGhlIE9DU1AgcmVzcG9uc2UgZW5hYmxlcyBzb21lb25lIHRvIHRyYXdsIGZvciANCj4+ID4g bnVtYmVycyB1bmxlc3MgeW91IGFjY2Vzcy1jb250cm9sIHRoZSBPQ1NQIHNlcnZlciwgc28geW91 IGluaGVyaXQgYSANCj4+ID4gcmVxdWlyZW1lbnQgdG8gZG8gdGhhdC4NCj4+ID4gKiBXaXRoIHRo ZSByYXRlIG9mIGNodXJuIGluIG51bWJlciBhc3NpZ25tZW50cywgeW91J3JlIHByb2JhYmx5IA0K Pj4gPiBnb2luZyB0byBoYXZlIHRvIHVwZGF0ZSB0aGUgbG9uZy1saXZlZCBjZXJ0IHByZXR0eSBm cmVxdWVudGx5IGFueXdheS4NCj4+ID4gKiBQdXR0aW5nIFROLXNwZWNpZmljIHN0dWZmIGluIGNl cnRzIGlzIGJldHRlciB0aGFuIHB1dHRpbmcgaXQgaW4gDQo+PiA+IE9DU1AuICBBcyBiYWQgYXMg WC41MDkgbGlicmFyaWVzIGNhbiBiZSwgT0NTUCBsaWJyYXJpZXMgYXJlIG11Y2ggDQo+PiA+IHdv cnNlLg0KPj4gPg0KPj4gPiBPcHRpb24gMSBpcyBtYWlubHkgYmFkIGZyb20gdGhlIHBlcnNwZWN0 aXZlIG9mIENBIGxvYWQgYW5kIG91dGFnZXMuDQo+PiA+IFdpdGggT3B0aW9uIDIsIGlmIHRoZSBD QSBnb2VzIGRvd24sIGNsaWVudCBjYW4gY29udGludWUgdG8gdXNlIHRoZSANCj4+ID4gbG9uZy1s aXZlZCBjZXJ0IGFuZCBqdXN0IG5vdCBib3RoZXIgZG9pbmcgT0NTUCAodnMuIHRvbGVyYXRpbmcg YW4gDQo+PiA+IGV4cGlyZWQgY2VydCkuICBTbGlnaHRseSBjbGVhbmVyLiAgUGx1cywgdGhlcmUn cyBhIGxvdCBtb3JlIA0KPj4gPiBleHBlcmllbmNlIGNhY2hpbmcgT0NTUCB0aGFuIG5ldyBjZXJ0 cy4gIE9DU1Agc2lnbmluZyBjYW4gYWxzbyBiZSANCj4+ID4gZGVsZWdhdGVkLCBzbyB5b3UgY2Fu IGhhdmUgdGhlIHJlY3VycmluZyBvcGVyYXRpb24gZG9uZSBieSBhIGxvd2VyLXJpc2sga2V5Lg0K Pj4gPg0KPj4gPiBPcHRpb24gMiBzaG91bGQgYmUgcHJldHR5IGVhc3kgdG8gYXV0b21hdGUuICBZ b3UgY2FuIHByb2JhYmx5IA0KPj4gPiByZS11c2UgdG9vbGluZyBmb3IgT0NTUCBzdGFwbGluZyB0 aGF0IGhhcyBhbHJlYWR5IGJlZW4gZGV2ZWxvcGVkIA0KPj4gPiBmb3IgdXNlIHdpdGggSFRUUFMu ICBJZiB5b3UncmUgYSBiaWcgYm94IHNpZ25pbmcgZm9yIGEgYnVuY2ggb2YgDQo+PiA+IG51bWJl cnMsIHlvdSBkbyBuZWVkIHRvIHNlbGVjdCB0aGUgcmlnaHQgY2VydCBhbmQgT0NTUCByZXNwb25z ZSBmb3IgDQo+PiA+IGEgZ2l2ZW4gY2FsbCwgYnV0IHRoYXQncyBhIHByZXR0eSBzaW1wbGUgbG9v a3VwIHRhYmxlLg0KPj4gPiA8U1RJUi5wcHR4Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+IHN0aXIgbWFpbGluZyBsaXN0DQo+PiA+IHN0aXJAaWV0 Zi5vcmcNCj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo+ Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IHN0aXIgbWFpbGluZyBsaXN0DQo+PiBzdGlyQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4NCj4gVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5 IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChz KS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFs bCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNClRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1h dGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFueSB1 c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVz IG9mIHRoZSBtZXNzYWdlLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnN0aXIgbWFpbGluZyBsaXN0DQpzdGlyQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpzdGlyIG1haWxpbmcgbGlzdA0Kc3RpckBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQo= From nobody Tue Jul 28 12:36:15 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DF11B2E61 for ; Tue, 28 Jul 2015 12:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YO3kcDbjtrNY for ; Tue, 28 Jul 2015 12:36:10 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5856D1B2E5F for ; Tue, 28 Jul 2015 12:36:07 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 7a9d7b55.2b9bb0813940.643056.00-2482.1839445.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 28 Jul 2015 19:36:07 +0000 (UTC) X-MXL-Hash: 55b7d9a7507a0b78-dfe6c185ffde44033fc8057e4a121b058578d910 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id c99d7b55.0.642923.00-2343.1839024.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 28 Jul 2015 19:35:56 +0000 (UTC) X-MXL-Hash: 55b7d99c6b756e6b-965b2adbb8675fff6dae1f7af6bfe547972be377 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 t6SJZtog019277; Tue, 28 Jul 2015 15:35:56 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6SJZfip018937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jul 2015 15:35:48 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 28 Jul 2015 19:35:29 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.200]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0224.002; Tue, 28 Jul 2015 15:35:29 -0400 From: "DOLLY, MARTIN C" To: Henning Schulzrinne Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLmIvVsjGeB+H0aKZAlcHlFXg53wbvsAgAAgjQCAAJs4gIAABZ6AgAAApQCAAALJAIAAUN+AgAADzgD//78yoQ== Date: Tue, 28 Jul 2015 19:35:29 +0000 Message-ID: <7DE72B93-5458-4DF9-943C-D0F331254EC4@att.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: NUMBER PORTABILITY, public X-AnalysisOut: [v=2.0 cv=ONaQK1mB c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=zOBTXjUuO1YA:10 a=izV7ms69AAAA:8 a=48vgC] X-AnalysisOut: [7mUAAAA:8 a=VfgTrTGYAAAA:8 a=HLLxP2VMAAAA:8 a=eYoRx4E0BzAe] X-AnalysisOut: [EVvbwusA:9 a=pILNOxqGKmIA:10 a=DzjOOp_o1eYA:10 a=xmyk6UmIt] X-AnalysisOut: [EXoxf5e:21 a=r428_A1QsAua6M77:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072801)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 19:36:14 -0000 It has to be easy and deplorable, without creating a business case for some= 3rd party or we may just have white/black lists Sent from my iPhone > On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne wrote: >=20 > That was certainly one of the models that have been discussed in the past= . Particularly for small carriers, this would likely reduce the operational= impact to a configuration option in the SBC. >=20 > The disadvantage of this model is caller privacy: If the cert is stored a= t a numbering authority, it would be easy for that authority to know which = carrier is receiving calls from whom. (It's not the complete meta data sinc= e it's lacking the callee information.) >=20 > However, unless the TN-to-LRN (in the US) mapping is cached, this "leak" = already exists today. >=20 > -----Original Message----- > From: PFAUTZ, PENN L [mailto:pp3129@att.com]=20 > Sent: Tuesday, July 28, 2015 3:14 PM > To: Henning Schulzrinne ; Gorman, Pierce A [= CTO] > Cc: stir@ietf.org > Subject: RE: [stir] On OCSP, TNs, and Privacy >=20 > Forgive me but my reptile brain keeps whispering in my ear that this woul= d be a lot easier if we simply had a numbering registry, whether distribute= d or centralized - like we need anyway for at least for number portability = - that also contained the public keys. No tedious mucking about in cyberspa= ce with certs, CRLs, or OCSP. >=20 >=20 >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinn= e > Sent: Tuesday, July 28, 2015 10:24 AM > To: Gorman, Pierce A [CTO] > Cc: stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 > In the US alone, we have about 4000 carriers. Managing the reputation of = that many entities, reliably (i.e., without making false positive/negative = mistakes) seems a whole lot more manual effort than storing bags of bits. S= torage and automation is cheap, human judgement and dealing with mistakes i= s expensive. >=20 > Obviously, nothing in the architecture prevents wildcard certificates. >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A [= CTO] > Sent: Tuesday, July 28, 2015 10:14 AM > To: Richard Barnes > Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 > I thought the discussion was on key/cert management. I'm asking if I und= erstood the suggestion to minimize requirements. How is that off topic? >=20 > Best regards, >=20 >=20 > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com >=20 >=20 > -----Original Message----- > From: Richard Barnes [mailto:rlb@ipv.sx] > Sent: July 28, 2015 9:12 AM > To: Gorman, Pierce A [CTO] > Cc: Alex Bobotek ; Brian Rosen ; sti= r@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 >> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] wrote: >> "Large scale certificate management is expensive, and TN-specific certif= icates are unneeded for securing calls placed by parties who choose to plac= e calls through a single reputable telephone service provider." >>=20 >> Are you saying that for "on-net" calls, STIR methodology is unnecessary? >=20 > This seems a little off-topic for this list. >=20 > --Richard >=20 >>=20 >> Best regards, >>=20 >>=20 >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >>=20 >>=20 >> -----Original Message----- >> From: Alex Bobotek [mailto:alex@bobotek.net] >> Sent: July 27, 2015 11:36 PM >> To: Brian Rosen ; Richard Barnes >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >>=20 >> What motivation would a carrier have to choose any model other than carr= ier signing using one of a very limited set of carrier-owned keys? Large s= cale certificate management is expensive, and TN-specific certificates are = unneeded for securing calls placed by parties who choose to place calls thr= ough a single reputable telephone service provider. Anyone can get many ce= rtificates, even a free ones anonymously from some issuers. It is typicall= y a combination of the strength of the end-user authentication performed by= the service provider (or certificate issuer in a provider-agnostic model) = and the identity's history that are most useful in security. >>=20 >> If we're trying to secure the current telephone system, DNS-like key rep= ositories a la DKIM or perhaps a small number (compared to the number of TN= s) of certificates are far more practical. >>=20 >> Regards, >>=20 >> Alex >>=20 >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>> Sent: Monday, July 27, 2015 7:40 PM >>> To: Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>=20 >>> What this means in practice is that it=92s TN per cert. >>>=20 >>> I wouldn=92t say that it=92s impossible for a carrier to maintain dozen= s=20 >>> of copies of millions of private keys securely, but it=92s hard. You=20 >>> need multiple copies because you have multiple elements that can=20 >>> initiate a call, and you don=92t want to depend on a centralized=20 >>> resource to do something as basic as create a call. >>>=20 >>> I think it=92s hard enough that REQUIRING cert per TN is not acceptable= . >>>=20 >>> Folks with more intimate knowledge of carrier SIP infrastructure=20 >>> might have more insight than I do. It may be acceptable to have a=20 >>> centralized resource to manage millions of keys. >>>=20 >>> Brian >>>=20 >>>> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>>>=20 >>>> After the STIR meeting in Prague, Henning and I spent a few minutes=20 >>>> talking through options for revocation checking and certificate=20 >>>> scoping, and I think we have a better idea of what the optimal=20 >>>> solution looks like. Some notes are below, and some slides with=20 >>>> pictures attached. >>>>=20 >>>> tl;dr: We should: >>>> * Keep TNs in certificates and not bother with any OCSP extensions >>>> * Require Identity-Info to include OCSP responses for all certs in=20 >>>> the chain >>>>=20 >>>>=20 >>>> # Background: Revocation in the web PKI >>>>=20 >>>> In an HTTPS transaction, the HTTPS server provides the client with=20 >>>> a certificate, and it can optionally include an OCSP response ("staple= " >>>> it to the transaction). >>>>=20 >>>> A certificate contains a validity interval, a key, and some names/TNs. >>>> An OCSP responses contains a validity interval, a certificate ID=20 >>>> (i.e., a hash), and a status (good/revoked/unknown). In the web=20 >>>> PKI, certificates are required to be no more than 39 months long,=20 >>>> and OCSP responses no more than 10 days. >>>>=20 >>>> Ideally, a client only considers a certificate valid if it is=20 >>>> accompanied by an OCSP response. In practice, this is not always=20 >>>> possible; because OCSP queries fail around 3% of the time, browsers=20 >>>> can't require OCSP. This operational fact will be important below,=20 >>>> but we will continue to have scoping cert lifetimes as an objective. >>>>=20 >>>> In the web PKI, there are basically three revocation checking modaliti= es: >>>>=20 >>>> 1. Live OCSP checking [RFC6069] >>>> 2. OCSP stapling / must_staple [RFC6066,=20 >>>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>>> lifetime) >>>>=20 >>>> (The last of these is relatively novel, and has not been deployed. >>>> Neither has must-staple. But they're both pretty trivial, and=20 >>>> could be folded into a STIR architecture pretty easily.) >>>>=20 >>>> Right now, about 90% of TLS transactions use live OCSP, and about 10%. >>>> CAs and browsers dearly want the world to move toward stapled OCSP=20 >>>> or short-lived certs, because these reduces latency and improve the=20 >>>> quality of revocation information. >>>>=20 >>>> Revocation for CA certificates is currently done by having browsers=20 >>>> download a list from a centralized server, since there's no way to=20 >>>> staple more than one OCSP response. That solution works OK for the=20 >>>> web, but if I were designing something de novo, I would probably=20 >>>> use multi-stapling as well. >>>>=20 >>>>=20 >>>> # Applying this experience to STIR >>>>=20 >>>> Most of the below appear to be desired properties by the WG: >>>>=20 >>>> * Verifier neeeds to know that a cert is valid for a specific=20 >>>> number >>>> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if=20 >>>> issued longer) >>>> * Caller privacy: Don't report what calls someone receives to a=20 >>>> central server >>>> * Carrier privacy: Don't allow a third party to figure out all the=20 >>>> numbers a carrier holds >>>> * Minimize the rate at which the CA has to sign things >>>> * Tolerate outages at the CA >>>>=20 >>>> I'm going to assume for now that we will not do live OCSP. It=20 >>>> violates the caller privacy requirement, and as discussed above, it=20 >>>> just sucks operationally. So STIR should require OCSP to be sent=20 >>>> in "stapled" form, which probably means sending it in Identity-Info. >>>> And while we're at it, we should also do "multi-stapling" -- send=20 >>>> an OCSP response for CA certs as well. >>>>=20 >>>> So if we consider a server with 50k TNs / blocks, that leaves us=20 >>>> with basically 3 options: >>>>=20 >>>> 1. 50k short-lived certs (no OCSP) >>>> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1=20 >>>> long-lived cert not scoped to TN (or a few loosely scoped) + OCSP=20 >>>> with TN info >>>>=20 >>>> (As I didn't quite get to say in the meeting, regardless of the=20 >>>> approach, you have to have 50k of *something*.) Of these, it seems=20 >>>> like the preference order is 2 > 1 > 3. >>>>=20 >>>> Option 3 is bad from several perspectives: >>>> * Putting TN info in the OCSP response enables someone to trawl for=20 >>>> numbers unless you access-control the OCSP server, so you inherit a=20 >>>> requirement to do that. >>>> * With the rate of churn in number assignments, you're probably=20 >>>> going to have to update the long-lived cert pretty frequently anyway. >>>> * Putting TN-specific stuff in certs is better than putting it in=20 >>>> OCSP. As bad as X.509 libraries can be, OCSP libraries are much=20 >>>> worse. >>>>=20 >>>> Option 1 is mainly bad from the perspective of CA load and outages. >>>> With Option 2, if the CA goes down, client can continue to use the=20 >>>> long-lived cert and just not bother doing OCSP (vs. tolerating an=20 >>>> expired cert). Slightly cleaner. Plus, there's a lot more=20 >>>> experience caching OCSP than new certs. OCSP signing can also be=20 >>>> delegated, so you can have the recurring operation done by a lower-ris= k key. >>>>=20 >>>> Option 2 should be pretty easy to automate. You can probably=20 >>>> re-use tooling for OCSP stapling that has already been developed=20 >>>> for use with HTTPS. If you're a big box signing for a bunch of=20 >>>> numbers, you do need to select the right cert and OCSP response for=20 >>>> a given call, but that's a pretty simple lookup table. >>>> _______________________________________________ >>>> 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 >> ________________________________ >>=20 >> This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you are n= ot the intended recipient, please contact the sender and delete all copies = of the message. >=20 > ________________________________ >=20 > This e-mail may contain Sprint proprietary information intended for the s= ole use of the recipient(s). Any use by others is prohibited. If you are no= t the intended recipient, please contact the sender and delete all copies o= f the message. > _______________________________________________ > 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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 28 12:38:51 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548131B2E86 for ; Tue, 28 Jul 2015 12:38:50 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wjMj-IInQois for ; Tue, 28 Jul 2015 12:38:46 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4221B2E82 for ; Tue, 28 Jul 2015 12:38:46 -0700 (PDT) Received: from BL2FFO11FD024.protection.gbl (10.173.160.31) by BL2FFO11HUB046.protection.gbl (10.173.161.122) with Microsoft SMTP Server (TLS) id 15.1.231.11; Tue, 28 Jul 2015 19:38:45 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.39 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.39; helo=plsapdm3.corp.sprint.com; Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BL2FFO11FD024.mail.protection.outlook.com (10.173.161.103) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Tue, 28 Jul 2015 19:38:44 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6SJbaY2001659; Tue, 28 Jul 2015 14:38:44 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm3.corp.sprint.com with ESMTP id 1vw3yh079j-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2015 14:38:44 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 28 Jul 2015 14:38:43 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Tue, 28 Jul 2015 14:38:43 -0500 From: "Gorman, Pierce A [CTO]" To: "DOLLY, MARTIN C" , Henning Schulzrinne Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3wbvsAgAAgjQCAAJs4gIAABZ6AgAAApQCAAALJAIAAUN+AgAADzgD//78yof///+4g Date: Tue, 28 Jul 2015 19:38:42 +0000 Message-ID: <1ed3b028355f401abd323b9b5488bc4e@PLSWE13M08.ad.sprint.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com>, <7DE72B93-5458-4DF9-943C-D0F331254EC4@att.com> In-Reply-To: <7DE72B93-5458-4DF9-943C-D0F331254EC4@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD024; 1:OSNV4cHSu5oOPiXzTHCYgoBGKylX+zH9hDgRCXmnut74CWGhKEVCB6XCRb8Br9VbSdxnxdX87PIQWT/w34Tci5/k3VWq5LXMujT9gsaK1wJsKWBrzXA7LA5P4/F9wO0GFxWdOiMvErY2Nd1ulqZzSV25SOllhCUSbSVA1l3A7Z0KamTzUtpGqlt4DlQoSML1FZtnPB9H7qtw2AJUfQhYpir+OLyK92tVbRZItPz8+5WQTn0ShiLRysl0BzbgIImh+EzT3qwiZ11maawq0fjHlIHrmXM3IXCgLfBnfFngeqQvHV7u6ZHUiVIgmcl89l5y X-Forefront-Antispam-Report: CIP:144.230.172.39; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(377454003)(13464003)(189002)(24454002)(46102003)(2900100001)(2950100001)(2656002)(92566002)(93886004)(108616004)(87936001)(5250100002)(5890100001)(5001960100002)(106466001)(86362001)(62966003)(5003600100002)(77156002)(5001770100001)(5003630100001)(19580405001)(47776003)(76176999)(23726002)(189998001)(102836002)(46406003)(15975445007)(551934003)(24736003)(6806004)(19580395003)(97756001)(54356999)(50466002)(106116001)(33646002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB046; H:plsapdm3.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB046; 2:jLXFb7EIt4yEvT5hro774fEMM0X07Z+vS6KnOYoiRlQJtzHgr1z0pj/cQjAANmCyeU+jcouG9oriey/QrFvpPrOr+r2YWNrE2zR+iWLED8wUMFNys3q9Y65L1VyXJP45NxGYT4tve5x0rtqTmHRrRURYRqT3uHOK8zrUe2/o2zk=; 3:Pew1IK2i6isaWhWENV/HMM9LthuLQR7CFnVqnKxNvGOyS3P7e6BgJL0CztBUJn9kZGz5OsRV8k4gU0uw+NF2ldFBzXAAmkFHj5ya08nKuSmZ5h9yOuVBa65E8sILs8sjPz1oVrtNoeTM4yfvMjabV4dtBBN97vB2ihPLveO0/ws81gTqnMIfEDTMh5epm9zRq9FeeGic8m41iylB355/rpM9YhAexIqIPe5HdiF5UqjqvtukD3IAPwtiFS/84xKP; 25:hoAJQQkm5G+4YVqbImIIvKuwbp3zfJjr1kFQK9qBvs9JVuTtGkkDIfSsgzTMSiJWHSPs8+dzQLpJd9k4ZUUeDV4mNFbagVHsfxhQLh3Xb9PKvXslMSR8zi7S+BqRWe+O+OmUCV6RZz9y8eaEP+f+kElvZxJigzHbpdVrrR+FIMdMbBVT1UkDVZEtxLk9xi6RNzneOf98nBZITkDyWYjjNprnyIUHW3hIvS5nMyo8XUb/bxBbHU65DWrjtshs1Zc3UiWfy0I+ipnC7wY6xzkaSw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB046; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB046; 20:0tS/uaDrVv8VQzua+yfZHchXnLFlCJIx/HiRD2dJD2I/YSzuU3/Fjfs1Uvu/jV0MHfFkE/6YMI2usYIIYHYdQnBjFXnFi3Fbo5ko+OAtf8V19Sj13g1rWNREvMO1B5ysiyPaUkHKTmEnmQzd1uiIEnWAgWetBUUiBmA+xQlOYJqBwG+O8Wlz5SybPw4N2nIDD3gsVcrbNcuOPU3VrAh6d3XINLmrPJLAzyWH+Fjd/gRlyKMa/PUtlURYvfnIkHdz; 4:9Rk+esJbNZYCzxg1kND/NQrUsWeESo4//6SdJ2uSuOaNlBIS7hEm5t/5LBw15/+MqfUmyBkk0Bxcwh8dpp0flYeYVC7fsaICpWgSEIHOsIoJp4hHLxSDg1YAhZJCzVG8+PyiwVhcsxEMXKY4SKwUxN+RxstFmueeI1bab7bv4zP+FYVs4x/EQ5+GGzMJkiTkdmvmAtAupyn5BeQdac7XAttHPGlVQ0uaIAy6nXCFxDsoO5j+G8DDEkGsRMYOSQo14FpYrqbJAoTCIfUPnZmRWUddUsAk7odjn5KNPAzbYPk= BL2FFO11HUB046: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BL2FFO11HUB046; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB046; X-Forefront-PRVS: 06515DA04B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB046; 23:gJXpAXNX4kEWSdp5Mohz3BsCmzmw6HZpIrkZMDjD?= =?us-ascii?Q?57swFBSR+S8FU7tBJ14vc1Sc/2yLdRLhSvbkSQtBcMOwfzDXxMCAuXtyK+S7?= =?us-ascii?Q?fqHx1v4pmtnuJkYARo9jpIs7VH44oysjwdy0z/0zVBZzwtvsoabkdaRtjHCm?= =?us-ascii?Q?7xfgNTgg7EUelJDe30HLeJ94n1EaGqeOKn7TKXBJeZTkQVtcTqkSAGkGGRSe?= =?us-ascii?Q?3lyTofQMkRCiMkqHtTbKgKkHUvzP2myv4T5DoHObCbV8eAnSbw5bixoI3iRK?= =?us-ascii?Q?iZVCDDiG1mGnB+MObbq1ftc/HJ3/Ws/X132gg56EMT7SPDrkl2iSaVCnh0HI?= =?us-ascii?Q?QJwQXDRSEpKmSI/ZbDvW7/M+5BFm6Ix+eh8jv0zhHox4crj3uLmaHuKWUwqf?= =?us-ascii?Q?DQJXxMQ4kQyOTSKopAtXprN4jx/Ywj6LY+26tBGu2pcv2qKgypmcShFIj5AC?= =?us-ascii?Q?5bB7ccU71eL61Rq2mML6A89IbJNqLFPyaIeh3OIj7vaiJHhGw4qDPh+TtUZD?= =?us-ascii?Q?wa2DRwN87crTEwmhK9B7uMUSD0LeBMrFqeagaxvEPq7uyfpn5xXrhheH/kqE?= =?us-ascii?Q?g0MylGJS7oS9SJxH/n5rZUz9SXDD2uPInj0sfAGemQAnwf6fFL06caF1lTzB?= =?us-ascii?Q?FAmxJGsDd53XsjtUOT1cY+nUa9CzT4pITNUbo3g3bJsqbtyQrNEayfuEV2eg?= =?us-ascii?Q?sEzK/qi3Nx2/3MAT5fPOs+pbWvbQ1j4lg1xaoEbdJnO2CMPpntL+c5BNnDn1?= =?us-ascii?Q?BwqqZxTY3L6zga9WXObdgEWuFTsVUstDXY0j5bx+aKsahQukwlntJyHhJJVb?= =?us-ascii?Q?9OotMpEws7fU38lHGE/IXo08tsJ5xegXWckMoiY1JwCpAgJHaVmUJiRoBrTd?= =?us-ascii?Q?y6Ys1gdpbwKxNslk1yQXjlb9/p+Aw01ajnJGWqVTYW5JvKpLUSXObipLy5Bj?= =?us-ascii?Q?MWPlA/rhGy7dx8S415wVhkbQ3NsxIH3cbtySdQfJrmZ3RNUfzcATDW7wnlx6?= =?us-ascii?Q?NdbHD4o40byhIPn3oIPkzND0zR/Y4/Krt9XcwngPGtovAXyQ2bTwDBBHujW7?= =?us-ascii?Q?L7l2k4cSHcXLsZ7pigaIxD3ve2VVrw1IF8xvO+XigbeP/YNKUrRwJa3XZ+gW?= =?us-ascii?Q?XToB9mlKx+j/Cpu51o9krjFZjOsmqO8G+sVkRpbXp88muxf++shYEGCcQxbY?= =?us-ascii?Q?K3WR+h3YmPHpatU=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB046; 5:9n6jdkY6KQvYvnrleapEnpzYv02EHRBDe8ep5XPYTAs3jfoaNw3uLDFENYowztLUkYWrTrViT2q/kw6zbSfkhLC6pesxifjDHcREeHykc2ebQ9Z+GhcPrOsM4332XjmZizpc8AX7Ch9IVpziEgTpcw==; 24:VHAhI3u7b4PM1n6A05/FfSUpMEChswcmjjcJRqImB8zIUiJS/IaIi0L7bQ6ChNt1xIob5dAXQ6zW+FbUk1BKLqkwPKXA68Y4RjO0ycVYA/U= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2015 19:38:44.9647 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB046 Archived-At: Cc: "stir@ietf.org" , "PFAUTZ, PENN L" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 19:38:50 -0000 One of the better auto-corrections I suspect. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: DOLLY, MARTIN C [mailto:md3135@att.com] Sent: July 28, 2015 2:35 PM To: Henning Schulzrinne Cc: PFAUTZ, PENN L ; Gorman, Pierce A [CTO] ; stir@ietf.org Subject: Re: [stir] On OCSP, TNs, and Privacy It has to be easy and deplorable, without creating a business case for some= 3rd party or we may just have white/black lists Sent from my iPhone > On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne wrote: > > That was certainly one of the models that have been discussed in the past= . Particularly for small carriers, this would likely reduce the operational= impact to a configuration option in the SBC. > > The disadvantage of this model is caller privacy: If the cert is > stored at a numbering authority, it would be easy for that authority > to know which carrier is receiving calls from whom. (It's not the > complete meta data since it's lacking the callee information.) > > However, unless the TN-to-LRN (in the US) mapping is cached, this "leak" = already exists today. > > -----Original Message----- > From: PFAUTZ, PENN L [mailto:pp3129@att.com] > Sent: Tuesday, July 28, 2015 3:14 PM > To: Henning Schulzrinne ; Gorman, Pierce > A [CTO] > Cc: stir@ietf.org > Subject: RE: [stir] On OCSP, TNs, and Privacy > > Forgive me but my reptile brain keeps whispering in my ear that this woul= d be a lot easier if we simply had a numbering registry, whether distribute= d or centralized - like we need anyway for at least for number portability = - that also contained the public keys. No tedious mucking about in cyberspa= ce with certs, CRLs, or OCSP. > > > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning > Schulzrinne > Sent: Tuesday, July 28, 2015 10:24 AM > To: Gorman, Pierce A [CTO] > Cc: stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy > > In the US alone, we have about 4000 carriers. Managing the reputation of = that many entities, reliably (i.e., without making false positive/negative = mistakes) seems a whole lot more manual effort than storing bags of bits. S= torage and automation is cheap, human judgement and dealing with mistakes i= s expensive. > > Obviously, nothing in the architecture prevents wildcard certificates. > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce > A [CTO] > Sent: Tuesday, July 28, 2015 10:14 AM > To: Richard Barnes > Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen > > Subject: Re: [stir] On OCSP, TNs, and Privacy > > I thought the discussion was on key/cert management. I'm asking if I und= erstood the suggestion to minimize requirements. How is that off topic? > > Best regards, > > > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > > > -----Original Message----- > From: Richard Barnes [mailto:rlb@ipv.sx] > Sent: July 28, 2015 9:12 AM > To: Gorman, Pierce A [CTO] > Cc: Alex Bobotek ; Brian Rosen ; > stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy > >> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] wrote: >> "Large scale certificate management is expensive, and TN-specific certif= icates are unneeded for securing calls placed by parties who choose to plac= e calls through a single reputable telephone service provider." >> >> Are you saying that for "on-net" calls, STIR methodology is unnecessary? > > This seems a little off-topic for this list. > > --Richard > >> >> Best regards, >> >> >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> -----Original Message----- >> From: Alex Bobotek [mailto:alex@bobotek.net] >> Sent: July 27, 2015 11:36 PM >> To: Brian Rosen ; Richard Barnes >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> What motivation would a carrier have to choose any model other than carr= ier signing using one of a very limited set of carrier-owned keys? Large s= cale certificate management is expensive, and TN-specific certificates are = unneeded for securing calls placed by parties who choose to place calls thr= ough a single reputable telephone service provider. Anyone can get many ce= rtificates, even a free ones anonymously from some issuers. It is typicall= y a combination of the strength of the end-user authentication performed by= the service provider (or certificate issuer in a provider-agnostic model) = and the identity's history that are most useful in security. >> >> If we're trying to secure the current telephone system, DNS-like key rep= ositories a la DKIM or perhaps a small number (compared to the number of TN= s) of certificates are far more practical. >> >> Regards, >> >> Alex >> >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>> Sent: Monday, July 27, 2015 7:40 PM >>> To: Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> What this means in practice is that it's TN per cert. >>> >>> I wouldn't say that it's impossible for a carrier to maintain dozens >>> of copies of millions of private keys securely, but it's hard. You >>> need multiple copies because you have multiple elements that can >>> initiate a call, and you don't want to depend on a centralized >>> resource to do something as basic as create a call. >>> >>> I think it's hard enough that REQUIRING cert per TN is not acceptable. >>> >>> Folks with more intimate knowledge of carrier SIP infrastructure >>> might have more insight than I do. It may be acceptable to have a >>> centralized resource to manage millions of keys. >>> >>> Brian >>> >>>> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>>> >>>> After the STIR meeting in Prague, Henning and I spent a few minutes >>>> talking through options for revocation checking and certificate >>>> scoping, and I think we have a better idea of what the optimal >>>> solution looks like. Some notes are below, and some slides with >>>> pictures attached. >>>> >>>> tl;dr: We should: >>>> * Keep TNs in certificates and not bother with any OCSP extensions >>>> * Require Identity-Info to include OCSP responses for all certs in >>>> the chain >>>> >>>> >>>> # Background: Revocation in the web PKI >>>> >>>> In an HTTPS transaction, the HTTPS server provides the client with >>>> a certificate, and it can optionally include an OCSP response ("staple= " >>>> it to the transaction). >>>> >>>> A certificate contains a validity interval, a key, and some names/TNs. >>>> An OCSP responses contains a validity interval, a certificate ID >>>> (i.e., a hash), and a status (good/revoked/unknown). In the web >>>> PKI, certificates are required to be no more than 39 months long, >>>> and OCSP responses no more than 10 days. >>>> >>>> Ideally, a client only considers a certificate valid if it is >>>> accompanied by an OCSP response. In practice, this is not always >>>> possible; because OCSP queries fail around 3% of the time, browsers >>>> can't require OCSP. This operational fact will be important below, >>>> but we will continue to have scoping cert lifetimes as an objective. >>>> >>>> In the web PKI, there are basically three revocation checking modaliti= es: >>>> >>>> 1. Live OCSP checking [RFC6069] >>>> 2. OCSP stapling / must_staple [RFC6066, >>>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>>> lifetime) >>>> >>>> (The last of these is relatively novel, and has not been deployed. >>>> Neither has must-staple. But they're both pretty trivial, and >>>> could be folded into a STIR architecture pretty easily.) >>>> >>>> Right now, about 90% of TLS transactions use live OCSP, and about 10%. >>>> CAs and browsers dearly want the world to move toward stapled OCSP >>>> or short-lived certs, because these reduces latency and improve the >>>> quality of revocation information. >>>> >>>> Revocation for CA certificates is currently done by having browsers >>>> download a list from a centralized server, since there's no way to >>>> staple more than one OCSP response. That solution works OK for the >>>> web, but if I were designing something de novo, I would probably >>>> use multi-stapling as well. >>>> >>>> >>>> # Applying this experience to STIR >>>> >>>> Most of the below appear to be desired properties by the WG: >>>> >>>> * Verifier neeeds to know that a cert is valid for a specific >>>> number >>>> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >>>> issued longer) >>>> * Caller privacy: Don't report what calls someone receives to a >>>> central server >>>> * Carrier privacy: Don't allow a third party to figure out all the >>>> numbers a carrier holds >>>> * Minimize the rate at which the CA has to sign things >>>> * Tolerate outages at the CA >>>> >>>> I'm going to assume for now that we will not do live OCSP. It >>>> violates the caller privacy requirement, and as discussed above, it >>>> just sucks operationally. So STIR should require OCSP to be sent >>>> in "stapled" form, which probably means sending it in Identity-Info. >>>> And while we're at it, we should also do "multi-stapling" -- send >>>> an OCSP response for CA certs as well. >>>> >>>> So if we consider a server with 50k TNs / blocks, that leaves us >>>> with basically 3 options: >>>> >>>> 1. 50k short-lived certs (no OCSP) >>>> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 >>>> long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >>>> with TN info >>>> >>>> (As I didn't quite get to say in the meeting, regardless of the >>>> approach, you have to have 50k of *something*.) Of these, it seems >>>> like the preference order is 2 > 1 > 3. >>>> >>>> Option 3 is bad from several perspectives: >>>> * Putting TN info in the OCSP response enables someone to trawl for >>>> numbers unless you access-control the OCSP server, so you inherit a >>>> requirement to do that. >>>> * With the rate of churn in number assignments, you're probably >>>> going to have to update the long-lived cert pretty frequently anyway. >>>> * Putting TN-specific stuff in certs is better than putting it in >>>> OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>>> worse. >>>> >>>> Option 1 is mainly bad from the perspective of CA load and outages. >>>> With Option 2, if the CA goes down, client can continue to use the >>>> long-lived cert and just not bother doing OCSP (vs. tolerating an >>>> expired cert). Slightly cleaner. Plus, there's a lot more >>>> experience caching OCSP than new certs. OCSP signing can also be >>>> delegated, so you can have the recurring operation done by a lower-ris= k key. >>>> >>>> Option 2 should be pretty easy to automate. You can probably >>>> re-use tooling for OCSP stapling that has already been developed >>>> for use with HTTPS. If you're a big box signing for a bunch of >>>> numbers, you do need to select the right cert and OCSP response for >>>> a given call, but that's a pretty simple lookup table. >>>> _______________________________________________ >>>> 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 >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you are n= ot the intended recipient, please contact the sender and delete all copies = of the message. > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the s= ole use of the recipient(s). Any use by others is prohibited. If you are no= t the intended recipient, please contact the sender and delete all copies o= f the message. > _______________________________________________ > 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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Tue Jul 28 12:43:49 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277B31B2E88 for ; Tue, 28 Jul 2015 12:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 WqxNkJhn9cnm for ; Tue, 28 Jul 2015 12:43:45 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id BC6531B2E89 for ; Tue, 28 Jul 2015 12:43:44 -0700 (PDT) From: Henning Schulzrinne To: "DOLLY, MARTIN C" Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAJs4gIAABZ6AgAAApgCAAAEaoIAAUo6AgAAA4XCAAAUsgIAAAU3w Date: Tue, 28 Jul 2015 19:43:41 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com>, <7DE72B93-5458-4DF9-943C-D0F331254EC4@att.com> In-Reply-To: <7DE72B93-5458-4DF9-943C-D0F331254EC4@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: att.com; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 5:64GZ95iL64Ziw2MGKelH0TIUjro+OlZxpOatoClPlvLJCeDtsCJSfitvnZ86IY63Xi3pBcIrzP5RJxi0ZvIaavK580AnF44zYOGGpoj2nOOoarNBJzkFKYwlhgC+F9pIe34U+4N6cVJvP5efUD10+A==; 24:uQjKXU8WA/mlFGtDUI42EkoTUq8KnZuFfopDhfCK3OFMmg7pkluXV239w/laBVLoIyuHgsB6bSzVXwZ1rvUJiDekLmkpMrt0JB8Gy8zLvL4=; 20:9d1DHnRDp2wbtzrnnoFXS1ZNSK3k3DsCszuJctl4yoFlqhOv0uwYIsFuFioufc39NPk8eUF2Esb/J6pdQe+7UA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0633; cy1pr09mb0633: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(5003600100002)(77096005)(102836002)(5002640100001)(15975445007)(189998001)(62966003)(54356999)(5001960100002)(40100003)(76176999)(2900100001)(5890100001)(110136002)(92566002)(77156002)(5003630100001)(19580405001)(86362001)(19580395003)(106116001)(50986999)(99286002)(76576001)(74316001)(33656002)(93886004)(2656002)(2950100001)(87936001)(46102003)(551934003)(66066001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2015 19:43:41.0866 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 19:43:48 -0000 I suspect we all deplore CNAM dip fees as a model here. Fortunately, here t= he caller has an incentive to make it easy to validate the caller identity,= so the incentives seem better aligned. Both parties are likely to have an = existing relationship to the porting database, and self-provisioning will a= lso likely limit the opportunity for above-cost services. (After all, the o= riginating server can always run their own cert server, so any third party = is likely to be limited to the cost of running such a server, even if it is= n't made part of some existing service, like number portability, that's pai= d in some non-dip-fee manner.) -----Original Message----- From: DOLLY, MARTIN C [mailto:md3135@att.com]=20 Sent: Tuesday, July 28, 2015 3:35 PM To: Henning Schulzrinne Cc: PFAUTZ, PENN L ; Gorman, Pierce A [CTO] ; stir@ietf.org Subject: Re: [stir] On OCSP, TNs, and Privacy It has to be easy and deplorable, without creating a business case for some= 3rd party or we may just have white/black lists Sent from my iPhone > On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne wrote: >=20 > That was certainly one of the models that have been discussed in the past= . Particularly for small carriers, this would likely reduce the operational= impact to a configuration option in the SBC. >=20 > The disadvantage of this model is caller privacy: If the cert is=20 > stored at a numbering authority, it would be easy for that authority=20 > to know which carrier is receiving calls from whom. (It's not the=20 > complete meta data since it's lacking the callee information.) >=20 > However, unless the TN-to-LRN (in the US) mapping is cached, this "leak" = already exists today. >=20 > -----Original Message----- > From: PFAUTZ, PENN L [mailto:pp3129@att.com] > Sent: Tuesday, July 28, 2015 3:14 PM > To: Henning Schulzrinne ; Gorman, Pierce=20 > A [CTO] > Cc: stir@ietf.org > Subject: RE: [stir] On OCSP, TNs, and Privacy >=20 > Forgive me but my reptile brain keeps whispering in my ear that this woul= d be a lot easier if we simply had a numbering registry, whether distribute= d or centralized - like we need anyway for at least for number portability = - that also contained the public keys. No tedious mucking about in cyberspa= ce with certs, CRLs, or OCSP. >=20 >=20 >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning=20 > Schulzrinne > Sent: Tuesday, July 28, 2015 10:24 AM > To: Gorman, Pierce A [CTO] > Cc: stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 > In the US alone, we have about 4000 carriers. Managing the reputation of = that many entities, reliably (i.e., without making false positive/negative = mistakes) seems a whole lot more manual effort than storing bags of bits. S= torage and automation is cheap, human judgement and dealing with mistakes i= s expensive. >=20 > Obviously, nothing in the architecture prevents wildcard certificates. >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce=20 > A [CTO] > Sent: Tuesday, July 28, 2015 10:14 AM > To: Richard Barnes > Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen=20 > > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 > I thought the discussion was on key/cert management. I'm asking if I und= erstood the suggestion to minimize requirements. How is that off topic? >=20 > Best regards, >=20 >=20 > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com >=20 >=20 > -----Original Message----- > From: Richard Barnes [mailto:rlb@ipv.sx] > Sent: July 28, 2015 9:12 AM > To: Gorman, Pierce A [CTO] > Cc: Alex Bobotek ; Brian Rosen ;=20 > stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 >> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] wrote: >> "Large scale certificate management is expensive, and TN-specific certif= icates are unneeded for securing calls placed by parties who choose to plac= e calls through a single reputable telephone service provider." >>=20 >> Are you saying that for "on-net" calls, STIR methodology is unnecessary? >=20 > This seems a little off-topic for this list. >=20 > --Richard >=20 >>=20 >> Best regards, >>=20 >>=20 >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >>=20 >>=20 >> -----Original Message----- >> From: Alex Bobotek [mailto:alex@bobotek.net] >> Sent: July 27, 2015 11:36 PM >> To: Brian Rosen ; Richard Barnes >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >>=20 >> What motivation would a carrier have to choose any model other than carr= ier signing using one of a very limited set of carrier-owned keys? Large s= cale certificate management is expensive, and TN-specific certificates are = unneeded for securing calls placed by parties who choose to place calls thr= ough a single reputable telephone service provider. Anyone can get many ce= rtificates, even a free ones anonymously from some issuers. It is typicall= y a combination of the strength of the end-user authentication performed by= the service provider (or certificate issuer in a provider-agnostic model) = and the identity's history that are most useful in security. >>=20 >> If we're trying to secure the current telephone system, DNS-like key rep= ositories a la DKIM or perhaps a small number (compared to the number of TN= s) of certificates are far more practical. >>=20 >> Regards, >>=20 >> Alex >>=20 >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>> Sent: Monday, July 27, 2015 7:40 PM >>> To: Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>=20 >>> What this means in practice is that it's TN per cert. >>>=20 >>> I wouldn't say that it's impossible for a carrier to maintain dozens=20 >>> of copies of millions of private keys securely, but it's hard. You=20 >>> need multiple copies because you have multiple elements that can=20 >>> initiate a call, and you don't want to depend on a centralized=20 >>> resource to do something as basic as create a call. >>>=20 >>> I think it's hard enough that REQUIRING cert per TN is not acceptable. >>>=20 >>> Folks with more intimate knowledge of carrier SIP infrastructure=20 >>> might have more insight than I do. It may be acceptable to have a=20 >>> centralized resource to manage millions of keys. >>>=20 >>> Brian >>>=20 >>>> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>>>=20 >>>> After the STIR meeting in Prague, Henning and I spent a few minutes=20 >>>> talking through options for revocation checking and certificate=20 >>>> scoping, and I think we have a better idea of what the optimal=20 >>>> solution looks like. Some notes are below, and some slides with=20 >>>> pictures attached. >>>>=20 >>>> tl;dr: We should: >>>> * Keep TNs in certificates and not bother with any OCSP extensions >>>> * Require Identity-Info to include OCSP responses for all certs in=20 >>>> the chain >>>>=20 >>>>=20 >>>> # Background: Revocation in the web PKI >>>>=20 >>>> In an HTTPS transaction, the HTTPS server provides the client with=20 >>>> a certificate, and it can optionally include an OCSP response ("staple= " >>>> it to the transaction). >>>>=20 >>>> A certificate contains a validity interval, a key, and some names/TNs. >>>> An OCSP responses contains a validity interval, a certificate ID=20 >>>> (i.e., a hash), and a status (good/revoked/unknown). In the web=20 >>>> PKI, certificates are required to be no more than 39 months long,=20 >>>> and OCSP responses no more than 10 days. >>>>=20 >>>> Ideally, a client only considers a certificate valid if it is=20 >>>> accompanied by an OCSP response. In practice, this is not always=20 >>>> possible; because OCSP queries fail around 3% of the time, browsers=20 >>>> can't require OCSP. This operational fact will be important below,=20 >>>> but we will continue to have scoping cert lifetimes as an objective. >>>>=20 >>>> In the web PKI, there are basically three revocation checking modaliti= es: >>>>=20 >>>> 1. Live OCSP checking [RFC6069] >>>> 2. OCSP stapling / must_staple [RFC6066,=20 >>>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>>> lifetime) >>>>=20 >>>> (The last of these is relatively novel, and has not been deployed. >>>> Neither has must-staple. But they're both pretty trivial, and=20 >>>> could be folded into a STIR architecture pretty easily.) >>>>=20 >>>> Right now, about 90% of TLS transactions use live OCSP, and about 10%. >>>> CAs and browsers dearly want the world to move toward stapled OCSP=20 >>>> or short-lived certs, because these reduces latency and improve the=20 >>>> quality of revocation information. >>>>=20 >>>> Revocation for CA certificates is currently done by having browsers=20 >>>> download a list from a centralized server, since there's no way to=20 >>>> staple more than one OCSP response. That solution works OK for the=20 >>>> web, but if I were designing something de novo, I would probably=20 >>>> use multi-stapling as well. >>>>=20 >>>>=20 >>>> # Applying this experience to STIR >>>>=20 >>>> Most of the below appear to be desired properties by the WG: >>>>=20 >>>> * Verifier neeeds to know that a cert is valid for a specific=20 >>>> number >>>> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if=20 >>>> issued longer) >>>> * Caller privacy: Don't report what calls someone receives to a=20 >>>> central server >>>> * Carrier privacy: Don't allow a third party to figure out all the=20 >>>> numbers a carrier holds >>>> * Minimize the rate at which the CA has to sign things >>>> * Tolerate outages at the CA >>>>=20 >>>> I'm going to assume for now that we will not do live OCSP. It=20 >>>> violates the caller privacy requirement, and as discussed above, it=20 >>>> just sucks operationally. So STIR should require OCSP to be sent=20 >>>> in "stapled" form, which probably means sending it in Identity-Info. >>>> And while we're at it, we should also do "multi-stapling" -- send=20 >>>> an OCSP response for CA certs as well. >>>>=20 >>>> So if we consider a server with 50k TNs / blocks, that leaves us=20 >>>> with basically 3 options: >>>>=20 >>>> 1. 50k short-lived certs (no OCSP) >>>> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1=20 >>>> long-lived cert not scoped to TN (or a few loosely scoped) + OCSP=20 >>>> with TN info >>>>=20 >>>> (As I didn't quite get to say in the meeting, regardless of the=20 >>>> approach, you have to have 50k of *something*.) Of these, it seems=20 >>>> like the preference order is 2 > 1 > 3. >>>>=20 >>>> Option 3 is bad from several perspectives: >>>> * Putting TN info in the OCSP response enables someone to trawl for=20 >>>> numbers unless you access-control the OCSP server, so you inherit a=20 >>>> requirement to do that. >>>> * With the rate of churn in number assignments, you're probably=20 >>>> going to have to update the long-lived cert pretty frequently anyway. >>>> * Putting TN-specific stuff in certs is better than putting it in=20 >>>> OCSP. As bad as X.509 libraries can be, OCSP libraries are much=20 >>>> worse. >>>>=20 >>>> Option 1 is mainly bad from the perspective of CA load and outages. >>>> With Option 2, if the CA goes down, client can continue to use the=20 >>>> long-lived cert and just not bother doing OCSP (vs. tolerating an=20 >>>> expired cert). Slightly cleaner. Plus, there's a lot more=20 >>>> experience caching OCSP than new certs. OCSP signing can also be=20 >>>> delegated, so you can have the recurring operation done by a lower-ris= k key. >>>>=20 >>>> Option 2 should be pretty easy to automate. You can probably=20 >>>> re-use tooling for OCSP stapling that has already been developed=20 >>>> for use with HTTPS. If you're a big box signing for a bunch of=20 >>>> numbers, you do need to select the right cert and OCSP response for=20 >>>> a given call, but that's a pretty simple lookup table. >>>> _______________________________________________ >>>> 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 >> ________________________________ >>=20 >> This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you are n= ot the intended recipient, please contact the sender and delete all copies = of the message. >=20 > ________________________________ >=20 > This e-mail may contain Sprint proprietary information intended for the s= ole use of the recipient(s). Any use by others is prohibited. If you are no= t the intended recipient, please contact the sender and delete all copies o= f the message. > _______________________________________________ > 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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 28 12:49:19 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCD11B2EC1 for ; Tue, 28 Jul 2015 12:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gYQd3YmPlapq for ; Tue, 28 Jul 2015 12:49:15 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97B51B2DF7 for ; Tue, 28 Jul 2015 12:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1438112955; x=1469648955; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rQYxHO8WD2Pw+/Bw8bZcdgF+QPQY7fYHqeeODwFkg98=; b=LLdlXp3fhBmMMWoBThDX6XlgjIe+aMe3zleWIfOxvI2iI4Z2ApPzBrWi vLULV9H6Lvhv+9b6yo5t6u8n/9skGJoYJVppnhGdogqNHgm+wv9W4J85a y/rPTO7E2c/tbC2fnARWeVDhzfNS/uLBA9J4mpEUPa0MMUWDYfdti1nvr Y=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 28 Jul 2015 19:49:14 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="5.15,565,1432598400"; d="scan'208";a="42979215" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 28 Jul 2015 19:49:13 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Tue, 28 Jul 2015 15:49:13 -0400 To: Henning Schulzrinne , "PFAUTZ, PENN L" , "Gorman, Pierce A [CTO]" Date: Tue, 28 Jul 2015 15:49:11 -0400 Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAJs4gIAABZ6AgAAApgCAAAEaoIAAUo6AgAAA4XCAAAYaAA== Message-ID: <2B0F677F0B95454297753F58D4A07FA3027C2B0B09@FHDP1LUMXC7V31.us.one.verizon.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 19:49:18 -0000 SW4gYWxsIFUuUy4gbmV0d29ya3MgSSdtIGZhbWlsaWFyIHdpdGgsIHRoZSBUTi10by1MUk4gbWFw cGluZyBpcyBjYWNoZWQuICBJIGFzc3VtZSB0aGF0IHRoZSBzYW1lIG1vZGVsIHdvdWxkIHdvcmsg aWYgd2UgYWRkZWQgcHVibGljIGtleXMgdG8gd2hhdCBQZW5uIGNhbGxzIHRoZSBudW1iZXJpbmcg cmVnaXN0cnkuDQoNClRoaXMgb2YgY291cnNlIGlzIGEgVVMgLWNlbnRyaWMgc29sdXRpb24gc2lu Y2UgaXQgYXNzdW1lcyB0aGF0IGNhY2hlcyBpbiB0aGUgb3JpZ2luYXRpbmcgbmV0d29yayBhcmUg cG9wdWxhdGVkIGZyb20gYSBjZW50cmFsaXplZCBhdXRob3JpdHkuICANCg0KdGltDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzdGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgSGVubmluZyBTY2h1bHpyaW5uZQ0KU2VudDogVHVlc2RheSwg SnVseSAyOCwgMjAxNSAyOjI3IFBNDQpUbzogUEZBVVRaLCBQRU5OIEw7IEdvcm1hbiwgUGllcmNl IEEgW0NUT10NCkNjOiBzdGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3N0aXJdIE9uIE9DU1As IFROcywgYW5kIFByaXZhY3kNCg0KVGhhdCB3YXMgY2VydGFpbmx5IG9uZSBvZiB0aGUgbW9kZWxz IHRoYXQgaGF2ZSBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgcGFzdC4gUGFydGljdWxhcmx5IGZvciBz bWFsbCBjYXJyaWVycywgdGhpcyB3b3VsZCBsaWtlbHkgcmVkdWNlIHRoZSBvcGVyYXRpb25hbCBp bXBhY3QgdG8gYSBjb25maWd1cmF0aW9uIG9wdGlvbiBpbiB0aGUgU0JDLg0KDQpUaGUgZGlzYWR2 YW50YWdlIG9mIHRoaXMgbW9kZWwgaXMgY2FsbGVyIHByaXZhY3k6IElmIHRoZSBjZXJ0IGlzIHN0 b3JlZCBhdCBhIG51bWJlcmluZyBhdXRob3JpdHksIGl0IHdvdWxkIGJlIGVhc3kgZm9yIHRoYXQg YXV0aG9yaXR5IHRvIGtub3cgd2hpY2ggY2FycmllciBpcyByZWNlaXZpbmcgY2FsbHMgZnJvbSB3 aG9tLiAoSXQncyBub3QgdGhlIGNvbXBsZXRlIG1ldGEgZGF0YSBzaW5jZSBpdCdzIGxhY2tpbmcg dGhlIGNhbGxlZSBpbmZvcm1hdGlvbi4pDQoNCkhvd2V2ZXIsIHVubGVzcyB0aGUgVE4tdG8tTFJO IChpbiB0aGUgVVMpIG1hcHBpbmcgaXMgY2FjaGVkLCB0aGlzICJsZWFrIiBhbHJlYWR5IGV4aXN0 cyB0b2RheS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBGQVVUWiwgUEVO TiBMIFttYWlsdG86cHAzMTI5QGF0dC5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDI4LCAyMDE1 IDM6MTQgUE0NClRvOiBIZW5uaW5nIFNjaHVsenJpbm5lIDxIZW5uaW5nLlNjaHVsenJpbm5lQGZj Yy5nb3Y+OyBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dIDxQaWVyY2UuR29ybWFuQHNwcmludC5jb20+ DQpDYzogc3RpckBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzdGlyXSBPbiBPQ1NQLCBUTnMsIGFu ZCBQcml2YWN5DQoNCkZvcmdpdmUgbWUgYnV0IG15IHJlcHRpbGUgYnJhaW4ga2VlcHMgd2hpc3Bl cmluZyBpbiBteSBlYXIgdGhhdCB0aGlzIHdvdWxkIGJlIGEgbG90IGVhc2llciBpZiB3ZSBzaW1w bHkgaGFkIGEgbnVtYmVyaW5nIHJlZ2lzdHJ5LCB3aGV0aGVyIGRpc3RyaWJ1dGVkIG9yIGNlbnRy YWxpemVkIC0gbGlrZSB3ZSBuZWVkIGFueXdheSBmb3IgYXQgbGVhc3QgZm9yIG51bWJlciBwb3J0 YWJpbGl0eSAtIHRoYXQgYWxzbyBjb250YWluZWQgdGhlIHB1YmxpYyBrZXlzLiBObyB0ZWRpb3Vz IG11Y2tpbmcgYWJvdXQgaW4gY3liZXJzcGFjZSB3aXRoIGNlcnRzLCBDUkxzLCBvciBPQ1NQLg0K DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHN0aXIgW21haWx0bzpzdGly LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIZW5uaW5nIFNjaHVsenJpbm5lDQpTZW50 OiBUdWVzZGF5LCBKdWx5IDI4LCAyMDE1IDEwOjI0IEFNDQpUbzogR29ybWFuLCBQaWVyY2UgQSBb Q1RPXQ0KQ2M6IHN0aXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5z LCBhbmQgUHJpdmFjeQ0KDQpJbiB0aGUgVVMgYWxvbmUsIHdlIGhhdmUgYWJvdXQgNDAwMCBjYXJy aWVycy4gTWFuYWdpbmcgdGhlIHJlcHV0YXRpb24gb2YgdGhhdCBtYW55IGVudGl0aWVzLCByZWxp YWJseSAoaS5lLiwgd2l0aG91dCBtYWtpbmcgZmFsc2UgcG9zaXRpdmUvbmVnYXRpdmUgbWlzdGFr ZXMpIHNlZW1zIGEgd2hvbGUgbG90IG1vcmUgbWFudWFsIGVmZm9ydCB0aGFuIHN0b3JpbmcgYmFn cyBvZiBiaXRzLiBTdG9yYWdlIGFuZCBhdXRvbWF0aW9uIGlzIGNoZWFwLCBodW1hbiBqdWRnZW1l bnQgYW5kIGRlYWxpbmcgd2l0aCBtaXN0YWtlcyBpcyBleHBlbnNpdmUuDQoNCk9idmlvdXNseSwg bm90aGluZyBpbiB0aGUgYXJjaGl0ZWN0dXJlIHByZXZlbnRzIHdpbGRjYXJkIGNlcnRpZmljYXRl cy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHN0aXIgW21haWx0bzpzdGly LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHb3JtYW4sIFBpZXJjZSBBIFtDVE9dDQpT ZW50OiBUdWVzZGF5LCBKdWx5IDI4LCAyMDE1IDEwOjE0IEFNDQpUbzogUmljaGFyZCBCYXJuZXMg PHJsYkBpcHYuc3g+DQpDYzogc3RpckBpZXRmLm9yZzsgQWxleCBCb2JvdGVrIDxhbGV4QGJvYm90 ZWsubmV0PjsgQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0Pg0KU3ViamVjdDogUmU6IFtz dGlyXSBPbiBPQ1NQLCBUTnMsIGFuZCBQcml2YWN5DQoNCkkgdGhvdWdodCB0aGUgZGlzY3Vzc2lv biB3YXMgb24ga2V5L2NlcnQgbWFuYWdlbWVudC4gIEknbSBhc2tpbmcgaWYgSSB1bmRlcnN0b29k IHRoZSBzdWdnZXN0aW9uIHRvIG1pbmltaXplIHJlcXVpcmVtZW50cy4gIEhvdyBpcyB0aGF0IG9m ZiB0b3BpYz8NCg0KQmVzdCByZWdhcmRzLA0KDQoNClBpZXJjZSBHb3JtYW4NCkNvcmUgTmV0d29y ayBQbGFubmluZw0KTzogOTEzLTQzOS00MzY4DQpwaWVyY2UuZ29ybWFuQHNwcmludC5jb20NCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmljaGFyZCBCYXJuZXMgW21haWx0 bzpybGJAaXB2LnN4XQ0KU2VudDogSnVseSAyOCwgMjAxNSA5OjEyIEFNDQpUbzogR29ybWFuLCBQ aWVyY2UgQSBbQ1RPXSA8UGllcmNlLkdvcm1hbkBzcHJpbnQuY29tPg0KQ2M6IEFsZXggQm9ib3Rl ayA8YWxleEBib2JvdGVrLm5ldD47IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD47IHN0 aXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBhbmQgUHJpdmFj eQ0KDQpPbiBUdWUsIEp1bCAyOCwgMjAxNSBhdCA5OjUxIEFNLCBHb3JtYW4sIFBpZXJjZSBBIFtD VE9dIDxQaWVyY2UuR29ybWFuQHNwcmludC5jb20+IHdyb3RlOg0KPiAiTGFyZ2Ugc2NhbGUgY2Vy dGlmaWNhdGUgbWFuYWdlbWVudCBpcyBleHBlbnNpdmUsIGFuZCBUTi1zcGVjaWZpYyBjZXJ0aWZp Y2F0ZXMgYXJlIHVubmVlZGVkIGZvciBzZWN1cmluZyBjYWxscyBwbGFjZWQgYnkgcGFydGllcyB3 aG8gY2hvb3NlIHRvIHBsYWNlIGNhbGxzIHRocm91Z2ggYSBzaW5nbGUgcmVwdXRhYmxlIHRlbGVw aG9uZSBzZXJ2aWNlIHByb3ZpZGVyLiINCj4NCj4gQXJlIHlvdSBzYXlpbmcgdGhhdCBmb3IgIm9u LW5ldCIgY2FsbHMsIFNUSVIgbWV0aG9kb2xvZ3kgaXMgdW5uZWNlc3Nhcnk/DQoNClRoaXMgc2Vl bXMgYSBsaXR0bGUgb2ZmLXRvcGljIGZvciB0aGlzIGxpc3QuDQoNCi0tUmljaGFyZA0KDQo+DQo+ IEJlc3QgcmVnYXJkcywNCj4NCj4NCj4gUGllcmNlIEdvcm1hbg0KPiBDb3JlIE5ldHdvcmsgUGxh bm5pbmcNCj4gTzogOTEzLTQzOS00MzY4DQo+IHBpZXJjZS5nb3JtYW5Ac3ByaW50LmNvbQ0KPg0K Pg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4IEJvYm90ZWsgW21h aWx0bzphbGV4QGJvYm90ZWsubmV0XQ0KPiBTZW50OiBKdWx5IDI3LCAyMDE1IDExOjM2IFBNDQo+ IFRvOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+OyBSaWNoYXJkIEJhcm5lcyA8cmxi QGlwdi5zeD4NCj4gQ2M6IHN0aXJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzdGlyXSBPbiBP Q1NQLCBUTnMsIGFuZCBQcml2YWN5DQo+DQo+IFdoYXQgbW90aXZhdGlvbiB3b3VsZCBhIGNhcnJp ZXIgaGF2ZSB0byBjaG9vc2UgYW55IG1vZGVsIG90aGVyIHRoYW4gY2FycmllciBzaWduaW5nIHVz aW5nIG9uZSBvZiBhIHZlcnkgbGltaXRlZCBzZXQgb2YgY2Fycmllci1vd25lZCBrZXlzPyAgTGFy Z2Ugc2NhbGUgY2VydGlmaWNhdGUgbWFuYWdlbWVudCBpcyBleHBlbnNpdmUsIGFuZCBUTi1zcGVj aWZpYyBjZXJ0aWZpY2F0ZXMgYXJlIHVubmVlZGVkIGZvciBzZWN1cmluZyBjYWxscyBwbGFjZWQg YnkgcGFydGllcyB3aG8gY2hvb3NlIHRvIHBsYWNlIGNhbGxzIHRocm91Z2ggYSBzaW5nbGUgcmVw dXRhYmxlIHRlbGVwaG9uZSBzZXJ2aWNlIHByb3ZpZGVyLiAgQW55b25lIGNhbiBnZXQgbWFueSBj ZXJ0aWZpY2F0ZXMsIGV2ZW4gYSBmcmVlIG9uZXMgYW5vbnltb3VzbHkgZnJvbSBzb21lIGlzc3Vl cnMuICBJdCBpcyB0eXBpY2FsbHkgYSBjb21iaW5hdGlvbiBvZiB0aGUgc3RyZW5ndGggb2YgdGhl IGVuZC11c2VyIGF1dGhlbnRpY2F0aW9uIHBlcmZvcm1lZCBieSB0aGUgc2VydmljZSBwcm92aWRl ciAob3IgY2VydGlmaWNhdGUgaXNzdWVyIGluIGEgcHJvdmlkZXItYWdub3N0aWMgbW9kZWwpIGFu ZCB0aGUgaWRlbnRpdHkncyBoaXN0b3J5IHRoYXQgYXJlIG1vc3QgdXNlZnVsIGluIHNlY3VyaXR5 Lg0KPg0KPiBJZiB3ZSdyZSB0cnlpbmcgdG8gc2VjdXJlIHRoZSBjdXJyZW50IHRlbGVwaG9uZSBz eXN0ZW0sIEROUy1saWtlIGtleSByZXBvc2l0b3JpZXMgYSBsYSBES0lNIG9yIHBlcmhhcHMgYSBz bWFsbCBudW1iZXIgKGNvbXBhcmVkIHRvIHRoZSBudW1iZXIgb2YgVE5zKSBvZiBjZXJ0aWZpY2F0 ZXMgYXJlIGZhciBtb3JlIHByYWN0aWNhbC4NCj4NCj4gUmVnYXJkcywNCj4NCj4gQWxleA0KPg0K Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHN0aXIgW21haWx0bzpzdGly LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBSb3Nlbg0KPj4gU2VudDogTW9u ZGF5LCBKdWx5IDI3LCAyMDE1IDc6NDAgUE0NCj4+IFRvOiBSaWNoYXJkIEJhcm5lcyA8cmxiQGlw di5zeD4NCj4+IENjOiBzdGlyQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3N0aXJdIE9uIE9D U1AsIFROcywgYW5kIFByaXZhY3kNCj4+DQo+PiBXaGF0IHRoaXMgbWVhbnMgaW4gcHJhY3RpY2Ug aXMgdGhhdCBpdOKAmXMgVE4gcGVyIGNlcnQuDQo+Pg0KPj4gSSB3b3VsZG7igJl0IHNheSB0aGF0 IGl04oCZcyBpbXBvc3NpYmxlIGZvciBhIGNhcnJpZXIgdG8gbWFpbnRhaW4gZG96ZW5zIA0KPj4g b2YgY29waWVzIG9mIG1pbGxpb25zIG9mIHByaXZhdGUga2V5cyBzZWN1cmVseSwgYnV0IGl04oCZ cyBoYXJkLiAgWW91IA0KPj4gbmVlZCBtdWx0aXBsZSBjb3BpZXMgYmVjYXVzZSB5b3UgaGF2ZSBt dWx0aXBsZSBlbGVtZW50cyB0aGF0IGNhbiANCj4+IGluaXRpYXRlIGEgY2FsbCwgYW5kIHlvdSBk b27igJl0IHdhbnQgdG8gZGVwZW5kIG9uIGEgY2VudHJhbGl6ZWQgDQo+PiByZXNvdXJjZSB0byBk byBzb21ldGhpbmcgYXMgYmFzaWMgYXMgY3JlYXRlIGEgY2FsbC4NCj4+DQo+PiBJIHRoaW5rIGl0 4oCZcyBoYXJkIGVub3VnaCB0aGF0IFJFUVVJUklORyBjZXJ0IHBlciBUTiBpcyBub3QgYWNjZXB0 YWJsZS4NCj4+DQo+PiBGb2xrcyB3aXRoIG1vcmUgaW50aW1hdGUga25vd2xlZGdlIG9mIGNhcnJp ZXIgU0lQIGluZnJhc3RydWN0dXJlIA0KPj4gbWlnaHQgaGF2ZSBtb3JlIGluc2lnaHQgdGhhbiBJ IGRvLiAgSXQgbWF5IGJlIGFjY2VwdGFibGUgdG8gaGF2ZSBhIA0KPj4gY2VudHJhbGl6ZWQgcmVz b3VyY2UgdG8gbWFuYWdlIG1pbGxpb25zIG9mIGtleXMuDQo+Pg0KPj4gQnJpYW4NCj4+DQo+PiA+ IE9uIEp1bCAyNywgMjAxNSwgYXQgNjoxMyBQTSwgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+ IHdyb3RlOg0KPj4gPg0KPj4gPiBBZnRlciB0aGUgU1RJUiBtZWV0aW5nIGluIFByYWd1ZSwgSGVu bmluZyBhbmQgSSBzcGVudCBhIGZldyBtaW51dGVzIA0KPj4gPiB0YWxraW5nIHRocm91Z2ggb3B0 aW9ucyBmb3IgcmV2b2NhdGlvbiBjaGVja2luZyBhbmQgY2VydGlmaWNhdGUgDQo+PiA+IHNjb3Bp bmcsIGFuZCBJIHRoaW5rIHdlIGhhdmUgYSBiZXR0ZXIgaWRlYSBvZiB3aGF0IHRoZSBvcHRpbWFs IA0KPj4gPiBzb2x1dGlvbiBsb29rcyBsaWtlLiAgU29tZSBub3RlcyBhcmUgYmVsb3csIGFuZCBz b21lIHNsaWRlcyB3aXRoIA0KPj4gPiBwaWN0dXJlcyBhdHRhY2hlZC4NCj4+ID4NCj4+ID4gdGw7 ZHI6IFdlIHNob3VsZDoNCj4+ID4gKiBLZWVwIFROcyBpbiBjZXJ0aWZpY2F0ZXMgYW5kIG5vdCBi b3RoZXIgd2l0aCBhbnkgT0NTUCBleHRlbnNpb25zDQo+PiA+ICogUmVxdWlyZSBJZGVudGl0eS1J bmZvIHRvIGluY2x1ZGUgT0NTUCByZXNwb25zZXMgZm9yIGFsbCBjZXJ0cyBpbiANCj4+ID4gdGhl IGNoYWluDQo+PiA+DQo+PiA+DQo+PiA+ICMgQmFja2dyb3VuZDogUmV2b2NhdGlvbiBpbiB0aGUg d2ViIFBLSQ0KPj4gPg0KPj4gPiBJbiBhbiBIVFRQUyB0cmFuc2FjdGlvbiwgdGhlIEhUVFBTIHNl cnZlciBwcm92aWRlcyB0aGUgY2xpZW50IHdpdGggDQo+PiA+IGEgY2VydGlmaWNhdGUsIGFuZCBp dCBjYW4gb3B0aW9uYWxseSBpbmNsdWRlIGFuIE9DU1AgcmVzcG9uc2UgKCJzdGFwbGUiDQo+PiA+ IGl0IHRvIHRoZSB0cmFuc2FjdGlvbikuDQo+PiA+DQo+PiA+IEEgY2VydGlmaWNhdGUgY29udGFp bnMgYSB2YWxpZGl0eSBpbnRlcnZhbCwgYSBrZXksIGFuZCBzb21lIG5hbWVzL1ROcy4NCj4+ID4g QW4gT0NTUCByZXNwb25zZXMgY29udGFpbnMgYSB2YWxpZGl0eSBpbnRlcnZhbCwgYSBjZXJ0aWZp Y2F0ZSBJRCANCj4+ID4gKGkuZS4sIGEgaGFzaCksIGFuZCBhIHN0YXR1cyAoZ29vZC9yZXZva2Vk L3Vua25vd24pLiAgSW4gdGhlIHdlYiANCj4+ID4gUEtJLCBjZXJ0aWZpY2F0ZXMgYXJlIHJlcXVp cmVkIHRvIGJlIG5vIG1vcmUgdGhhbiAzOSBtb250aHMgbG9uZywgDQo+PiA+IGFuZCBPQ1NQIHJl c3BvbnNlcyBubyBtb3JlIHRoYW4gMTAgZGF5cy4NCj4+ID4NCj4+ID4gSWRlYWxseSwgYSBjbGll bnQgb25seSBjb25zaWRlcnMgYSBjZXJ0aWZpY2F0ZSB2YWxpZCBpZiBpdCBpcyANCj4+ID4gYWNj b21wYW5pZWQgYnkgYW4gT0NTUCByZXNwb25zZS4gIEluIHByYWN0aWNlLCB0aGlzIGlzIG5vdCBh bHdheXMgDQo+PiA+IHBvc3NpYmxlOyBiZWNhdXNlIE9DU1AgcXVlcmllcyBmYWlsIGFyb3VuZCAz JSBvZiB0aGUgdGltZSwgYnJvd3NlcnMgDQo+PiA+IGNhbid0IHJlcXVpcmUgT0NTUC4gIFRoaXMg b3BlcmF0aW9uYWwgZmFjdCB3aWxsIGJlIGltcG9ydGFudCBiZWxvdywgDQo+PiA+IGJ1dCB3ZSB3 aWxsIGNvbnRpbnVlIHRvIGhhdmUgc2NvcGluZyBjZXJ0IGxpZmV0aW1lcyBhcyBhbiBvYmplY3Rp dmUuDQo+PiA+DQo+PiA+IEluIHRoZSB3ZWIgUEtJLCB0aGVyZSBhcmUgYmFzaWNhbGx5IHRocmVl IHJldm9jYXRpb24gY2hlY2tpbmcgbW9kYWxpdGllczoNCj4+ID4NCj4+ID4gMS4gTGl2ZSBPQ1NQ IGNoZWNraW5nIFtSRkM2MDY5XQ0KPj4gPiAyLiBPQ1NQIHN0YXBsaW5nIC8gbXVzdF9zdGFwbGUg W1JGQzYwNjYsIA0KPj4gPiBkcmFmdC1oYWxsYW1iYWtlci10bHNmZWF0dXJlXSAzLiBTaG9ydC1s aXZlZCBjZXJ0aWZpY2F0ZXMgKH5PQ1NQDQo+PiA+IGxpZmV0aW1lKQ0KPj4gPg0KPj4gPiAoVGhl IGxhc3Qgb2YgdGhlc2UgaXMgcmVsYXRpdmVseSBub3ZlbCwgYW5kIGhhcyBub3QgYmVlbiBkZXBs b3llZC4NCj4+ID4gTmVpdGhlciBoYXMgbXVzdC1zdGFwbGUuICBCdXQgdGhleSdyZSBib3RoIHBy ZXR0eSB0cml2aWFsLCBhbmQgDQo+PiA+IGNvdWxkIGJlIGZvbGRlZCBpbnRvIGEgU1RJUiBhcmNo aXRlY3R1cmUgcHJldHR5IGVhc2lseS4pDQo+PiA+DQo+PiA+IFJpZ2h0IG5vdywgYWJvdXQgOTAl IG9mIFRMUyB0cmFuc2FjdGlvbnMgdXNlIGxpdmUgT0NTUCwgYW5kIGFib3V0IDEwJS4NCj4+ID4g Q0FzIGFuZCBicm93c2VycyBkZWFybHkgd2FudCB0aGUgd29ybGQgdG8gbW92ZSB0b3dhcmQgc3Rh cGxlZCBPQ1NQIA0KPj4gPiBvciBzaG9ydC1saXZlZCBjZXJ0cywgYmVjYXVzZSB0aGVzZSByZWR1 Y2VzIGxhdGVuY3kgYW5kIGltcHJvdmUgdGhlIA0KPj4gPiBxdWFsaXR5IG9mIHJldm9jYXRpb24g aW5mb3JtYXRpb24uDQo+PiA+DQo+PiA+IFJldm9jYXRpb24gZm9yIENBIGNlcnRpZmljYXRlcyBp cyBjdXJyZW50bHkgZG9uZSBieSBoYXZpbmcgYnJvd3NlcnMgDQo+PiA+IGRvd25sb2FkIGEgbGlz dCBmcm9tIGEgY2VudHJhbGl6ZWQgc2VydmVyLCBzaW5jZSB0aGVyZSdzIG5vIHdheSB0byANCj4+ ID4gc3RhcGxlIG1vcmUgdGhhbiBvbmUgT0NTUCByZXNwb25zZS4gIFRoYXQgc29sdXRpb24gd29y a3MgT0sgZm9yIHRoZSANCj4+ID4gd2ViLCBidXQgaWYgSSB3ZXJlIGRlc2lnbmluZyBzb21ldGhp bmcgZGUgbm92bywgSSB3b3VsZCBwcm9iYWJseSANCj4+ID4gdXNlIG11bHRpLXN0YXBsaW5nIGFz IHdlbGwuDQo+PiA+DQo+PiA+DQo+PiA+ICMgQXBwbHlpbmcgdGhpcyBleHBlcmllbmNlIHRvIFNU SVINCj4+ID4NCj4+ID4gTW9zdCBvZiB0aGUgYmVsb3cgYXBwZWFyIHRvIGJlIGRlc2lyZWQgcHJv cGVydGllcyBieSB0aGUgV0c6DQo+PiA+DQo+PiA+ICogVmVyaWZpZXIgbmVlZWRzIHRvIGtub3cg dGhhdCBhIGNlcnQgaXMgdmFsaWQgZm9yIGEgc3BlY2lmaWMgDQo+PiA+IG51bWJlcg0KPj4gPiAq IFNjb3BlZCBjZXJ0IGxpZmV0aW1lOiBMaW1pdCBjZXJ0cyB0byB+MXdlZWsgbGlmZXRpbWUgKGJ5 IE9DU1AgaWYgDQo+PiA+IGlzc3VlZCBsb25nZXIpDQo+PiA+ICogQ2FsbGVyIHByaXZhY3k6IERv bid0IHJlcG9ydCB3aGF0IGNhbGxzIHNvbWVvbmUgcmVjZWl2ZXMgdG8gYSANCj4+ID4gY2VudHJh bCBzZXJ2ZXINCj4+ID4gKiBDYXJyaWVyIHByaXZhY3k6IERvbid0IGFsbG93IGEgdGhpcmQgcGFy dHkgdG8gZmlndXJlIG91dCBhbGwgdGhlIA0KPj4gPiBudW1iZXJzIGEgY2FycmllciBob2xkcw0K Pj4gPiAqIE1pbmltaXplIHRoZSByYXRlIGF0IHdoaWNoIHRoZSBDQSBoYXMgdG8gc2lnbiB0aGlu Z3MNCj4+ID4gKiBUb2xlcmF0ZSBvdXRhZ2VzIGF0IHRoZSBDQQ0KPj4gPg0KPj4gPiBJJ20gZ29p bmcgdG8gYXNzdW1lIGZvciBub3cgdGhhdCB3ZSB3aWxsIG5vdCBkbyBsaXZlIE9DU1AuICBJdCAN Cj4+ID4gdmlvbGF0ZXMgdGhlIGNhbGxlciBwcml2YWN5IHJlcXVpcmVtZW50LCBhbmQgYXMgZGlz Y3Vzc2VkIGFib3ZlLCBpdCANCj4+ID4ganVzdCBzdWNrcyBvcGVyYXRpb25hbGx5LiAgU28gU1RJ UiBzaG91bGQgcmVxdWlyZSBPQ1NQIHRvIGJlIHNlbnQgDQo+PiA+IGluICJzdGFwbGVkIiBmb3Jt LCB3aGljaCBwcm9iYWJseSBtZWFucyBzZW5kaW5nIGl0IGluIElkZW50aXR5LUluZm8uDQo+PiA+ IEFuZCB3aGlsZSB3ZSdyZSBhdCBpdCwgd2Ugc2hvdWxkIGFsc28gZG8gIm11bHRpLXN0YXBsaW5n IiAtLSBzZW5kIA0KPj4gPiBhbiBPQ1NQIHJlc3BvbnNlIGZvciBDQSBjZXJ0cyBhcyB3ZWxsLg0K Pj4gPg0KPj4gPiBTbyBpZiB3ZSBjb25zaWRlciBhIHNlcnZlciB3aXRoIDUwayBUTnMgLyBibG9j a3MsIHRoYXQgbGVhdmVzIHVzIA0KPj4gPiB3aXRoIGJhc2ljYWxseSAzIG9wdGlvbnM6DQo+PiA+ DQo+PiA+IDEuIDUwayBzaG9ydC1saXZlZCBjZXJ0cyAobm8gT0NTUCkNCj4+ID4gMi4gNTBrIGxv bmctbGl2ZWQgY2VydHMgc2NvcGVkIHRvIFROcyArIGdlbmVyaWMgT0NTUCAzLiAxIA0KPj4gPiBs b25nLWxpdmVkIGNlcnQgbm90IHNjb3BlZCB0byBUTiAob3IgYSBmZXcgbG9vc2VseSBzY29wZWQp ICsgT0NTUCANCj4+ID4gd2l0aCBUTiBpbmZvDQo+PiA+DQo+PiA+IChBcyBJIGRpZG4ndCBxdWl0 ZSBnZXQgdG8gc2F5IGluIHRoZSBtZWV0aW5nLCByZWdhcmRsZXNzIG9mIHRoZSANCj4+ID4gYXBw cm9hY2gsIHlvdSBoYXZlIHRvIGhhdmUgNTBrIG9mICpzb21ldGhpbmcqLikgIE9mIHRoZXNlLCBp dCBzZWVtcyANCj4+ID4gbGlrZSB0aGUgcHJlZmVyZW5jZSBvcmRlciBpcyAyID4gMSA+IDMuDQo+ PiA+DQo+PiA+IE9wdGlvbiAzIGlzIGJhZCBmcm9tIHNldmVyYWwgcGVyc3BlY3RpdmVzOg0KPj4g PiAqIFB1dHRpbmcgVE4gaW5mbyBpbiB0aGUgT0NTUCByZXNwb25zZSBlbmFibGVzIHNvbWVvbmUg dG8gdHJhd2wgZm9yIA0KPj4gPiBudW1iZXJzIHVubGVzcyB5b3UgYWNjZXNzLWNvbnRyb2wgdGhl IE9DU1Agc2VydmVyLCBzbyB5b3UgaW5oZXJpdCBhIA0KPj4gPiByZXF1aXJlbWVudCB0byBkbyB0 aGF0Lg0KPj4gPiAqIFdpdGggdGhlIHJhdGUgb2YgY2h1cm4gaW4gbnVtYmVyIGFzc2lnbm1lbnRz LCB5b3UncmUgcHJvYmFibHkgDQo+PiA+IGdvaW5nIHRvIGhhdmUgdG8gdXBkYXRlIHRoZSBsb25n LWxpdmVkIGNlcnQgcHJldHR5IGZyZXF1ZW50bHkgYW55d2F5Lg0KPj4gPiAqIFB1dHRpbmcgVE4t c3BlY2lmaWMgc3R1ZmYgaW4gY2VydHMgaXMgYmV0dGVyIHRoYW4gcHV0dGluZyBpdCBpbiANCj4+ ID4gT0NTUC4gIEFzIGJhZCBhcyBYLjUwOSBsaWJyYXJpZXMgY2FuIGJlLCBPQ1NQIGxpYnJhcmll cyBhcmUgbXVjaCANCj4+ID4gd29yc2UuDQo+PiA+DQo+PiA+IE9wdGlvbiAxIGlzIG1haW5seSBi YWQgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgQ0EgbG9hZCBhbmQgb3V0YWdlcy4NCj4+ID4gV2l0 aCBPcHRpb24gMiwgaWYgdGhlIENBIGdvZXMgZG93biwgY2xpZW50IGNhbiBjb250aW51ZSB0byB1 c2UgdGhlIA0KPj4gPiBsb25nLWxpdmVkIGNlcnQgYW5kIGp1c3Qgbm90IGJvdGhlciBkb2luZyBP Q1NQICh2cy4gdG9sZXJhdGluZyBhbiANCj4+ID4gZXhwaXJlZCBjZXJ0KS4gIFNsaWdodGx5IGNs ZWFuZXIuICBQbHVzLCB0aGVyZSdzIGEgbG90IG1vcmUgDQo+PiA+IGV4cGVyaWVuY2UgY2FjaGlu ZyBPQ1NQIHRoYW4gbmV3IGNlcnRzLiAgT0NTUCBzaWduaW5nIGNhbiBhbHNvIGJlIA0KPj4gPiBk ZWxlZ2F0ZWQsIHNvIHlvdSBjYW4gaGF2ZSB0aGUgcmVjdXJyaW5nIG9wZXJhdGlvbiBkb25lIGJ5 IGEgbG93ZXItcmlzayBrZXkuDQo+PiA+DQo+PiA+IE9wdGlvbiAyIHNob3VsZCBiZSBwcmV0dHkg ZWFzeSB0byBhdXRvbWF0ZS4gIFlvdSBjYW4gcHJvYmFibHkgDQo+PiA+IHJlLXVzZSB0b29saW5n IGZvciBPQ1NQIHN0YXBsaW5nIHRoYXQgaGFzIGFscmVhZHkgYmVlbiBkZXZlbG9wZWQgDQo+PiA+ IGZvciB1c2Ugd2l0aCBIVFRQUy4gIElmIHlvdSdyZSBhIGJpZyBib3ggc2lnbmluZyBmb3IgYSBi dW5jaCBvZiANCj4+ID4gbnVtYmVycywgeW91IGRvIG5lZWQgdG8gc2VsZWN0IHRoZSByaWdodCBj ZXJ0IGFuZCBPQ1NQIHJlc3BvbnNlIGZvciANCj4+ID4gYSBnaXZlbiBjYWxsLCBidXQgdGhhdCdz IGEgcHJldHR5IHNpbXBsZSBsb29rdXAgdGFibGUuDQo+PiA+IDxTVElSLnBwdHg+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4gc3RpciBtYWlsaW5n IGxpc3QNCj4+ID4gc3RpckBpZXRmLm9yZw0KPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3N0aXINCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gc3RpciBtYWlsaW5nIGxpc3QNCj4+IHN0aXJAaWV0Zi5vcmcN Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiBUaGlzIGUtbWFpbCBtYXkgY29udGFp biBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVz ZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50 IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhl IHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBh bmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3RpciBtYWlsaW5nIGxpc3QNCnN0aXJAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Rpcg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnN0aXIgbWFpbGluZyBs aXN0DQpzdGlyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N0aXINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpz dGlyIG1haWxpbmcgbGlzdA0Kc3RpckBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zdGlyDQo= From nobody Tue Jul 28 13:06:55 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40041B2F40 for ; Tue, 28 Jul 2015 13:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 atUkYZsR93y3 for ; Tue, 28 Jul 2015 13:06:52 -0700 (PDT) Received: from mail-vn0-f44.google.com (mail-vn0-f44.google.com [209.85.216.44]) (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 ECFC41B2F3D for ; Tue, 28 Jul 2015 13:06:51 -0700 (PDT) Received: by vnk197 with SMTP id 197so47139564vnk.3 for ; Tue, 28 Jul 2015 13:06:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GFitLPi99v22CByCd5vJTRLLGFXdUGvS8R6tJrM50ic=; b=SXILpEuJYMx+ykC7uvf9H9yvmgYzSqhr0WWvE8BW6CYpgDjBzFLCrkftxuwF41+8M2 XzRZP260e4nrRvFGtlpCK9BqLNLogBbZ6FCdksVVxiuNEY+FMTXkEXKLQb89YyTVJeLF 5L1Yp74gRR8nyPXud6upxVKTamf5+1yn+ft2GERVm1X5P6Ta3El4kRu/23NsAUqp85JA aWE1ano1W7XT/NdO6IBCelxbezaeX/7gTNzDyeQdpyfzQ7MCYRGW8ouYVjOtfG8m+hkr +lI5fvBvgw4C/McATCllw49pgiAQk9xSg2MiJirUO8GFbxU6tG/Cnni74sJ+ZiFAsng0 8uqw== X-Gm-Message-State: ALoCoQncIcOPYQYuLqndXK81GxaP/EwEOa2Jva8DR754+JjCwp45Nh77oLUwQqq9XIMfxvtoa4ch MIME-Version: 1.0 X-Received: by 10.52.69.241 with SMTP id h17mr47009994vdu.68.1438114011085; Tue, 28 Jul 2015 13:06:51 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Tue, 28 Jul 2015 13:06:50 -0700 (PDT) In-Reply-To: <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> Date: Tue, 28 Jul 2015 16:06:50 -0400 Message-ID: From: Richard Barnes To: "PFAUTZ, PENN L" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 20:06:54 -0000 http://www.afldreamers.com/wp-content/uploads/2014/01/why-not-have-both-300= x187.png You could have a database of certs+OCSP responses as an optimization. IIRC, Identity-Info only has pointers to certs anyway. On Tue, Jul 28, 2015 at 3:13 PM, PFAUTZ, PENN L wrote: > Forgive me but my reptile brain keeps whispering in my ear that this woul= d be a lot easier if we simply had a numbering registry, whether distribute= d or centralized - like we need anyway for at least for number portability = - that also contained the public keys. No tedious mucking about in cyberspa= ce with certs, CRLs, or OCSP. > > > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinn= e > Sent: Tuesday, July 28, 2015 10:24 AM > To: Gorman, Pierce A [CTO] > Cc: stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy > > In the US alone, we have about 4000 carriers. Managing the reputation of = that many entities, reliably (i.e., without making false positive/negative = mistakes) seems a whole lot more manual effort than storing bags of bits. S= torage and automation is cheap, human judgement and dealing with mistakes i= s expensive. > > Obviously, nothing in the architecture prevents wildcard certificates. > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A [= CTO] > Sent: Tuesday, July 28, 2015 10:14 AM > To: Richard Barnes > Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen > Subject: Re: [stir] On OCSP, TNs, and Privacy > > I thought the discussion was on key/cert management. I'm asking if I und= erstood the suggestion to minimize requirements. How is that off topic? > > Best regards, > > > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > > > -----Original Message----- > From: Richard Barnes [mailto:rlb@ipv.sx] > Sent: July 28, 2015 9:12 AM > To: Gorman, Pierce A [CTO] > Cc: Alex Bobotek ; Brian Rosen ; sti= r@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy > > On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] wrote: >> "Large scale certificate management is expensive, and TN-specific certif= icates are unneeded for securing calls placed by parties who choose to plac= e calls through a single reputable telephone service provider." >> >> Are you saying that for "on-net" calls, STIR methodology is unnecessary? > > This seems a little off-topic for this list. > > --Richard > >> >> Best regards, >> >> >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> -----Original Message----- >> From: Alex Bobotek [mailto:alex@bobotek.net] >> Sent: July 27, 2015 11:36 PM >> To: Brian Rosen ; Richard Barnes >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> What motivation would a carrier have to choose any model other than carr= ier signing using one of a very limited set of carrier-owned keys? Large s= cale certificate management is expensive, and TN-specific certificates are = unneeded for securing calls placed by parties who choose to place calls thr= ough a single reputable telephone service provider. Anyone can get many ce= rtificates, even a free ones anonymously from some issuers. It is typicall= y a combination of the strength of the end-user authentication performed by= the service provider (or certificate issuer in a provider-agnostic model) = and the identity's history that are most useful in security. >> >> If we're trying to secure the current telephone system, DNS-like key rep= ositories a la DKIM or perhaps a small number (compared to the number of TN= s) of certificates are far more practical. >> >> Regards, >> >> Alex >> >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>> Sent: Monday, July 27, 2015 7:40 PM >>> To: Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> What this means in practice is that it=E2=80=99s TN per cert. >>> >>> I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier to ma= intain dozens >>> of copies of millions of private keys securely, but it=E2=80=99s hard. = You >>> need multiple copies because you have multiple elements that can >>> initiate a call, and you don=E2=80=99t want to depend on a centralized >>> resource to do something as basic as create a call. >>> >>> I think it=E2=80=99s hard enough that REQUIRING cert per TN is not acce= ptable. >>> >>> Folks with more intimate knowledge of carrier SIP infrastructure >>> might have more insight than I do. It may be acceptable to have a >>> centralized resource to manage millions of keys. >>> >>> Brian >>> >>> > On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>> > >>> > After the STIR meeting in Prague, Henning and I spent a few minutes >>> > talking through options for revocation checking and certificate >>> > scoping, and I think we have a better idea of what the optimal >>> > solution looks like. Some notes are below, and some slides with >>> > pictures attached. >>> > >>> > tl;dr: We should: >>> > * Keep TNs in certificates and not bother with any OCSP extensions >>> > * Require Identity-Info to include OCSP responses for all certs in >>> > the chain >>> > >>> > >>> > # Background: Revocation in the web PKI >>> > >>> > In an HTTPS transaction, the HTTPS server provides the client with >>> > a certificate, and it can optionally include an OCSP response ("stapl= e" >>> > it to the transaction). >>> > >>> > A certificate contains a validity interval, a key, and some names/TNs= . >>> > An OCSP responses contains a validity interval, a certificate ID >>> > (i.e., a hash), and a status (good/revoked/unknown). In the web >>> > PKI, certificates are required to be no more than 39 months long, >>> > and OCSP responses no more than 10 days. >>> > >>> > Ideally, a client only considers a certificate valid if it is >>> > accompanied by an OCSP response. In practice, this is not always >>> > possible; because OCSP queries fail around 3% of the time, browsers >>> > can't require OCSP. This operational fact will be important below, >>> > but we will continue to have scoping cert lifetimes as an objective. >>> > >>> > In the web PKI, there are basically three revocation checking modalit= ies: >>> > >>> > 1. Live OCSP checking [RFC6069] >>> > 2. OCSP stapling / must_staple [RFC6066, >>> > draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>> > lifetime) >>> > >>> > (The last of these is relatively novel, and has not been deployed. >>> > Neither has must-staple. But they're both pretty trivial, and >>> > could be folded into a STIR architecture pretty easily.) >>> > >>> > Right now, about 90% of TLS transactions use live OCSP, and about 10%= . >>> > CAs and browsers dearly want the world to move toward stapled OCSP >>> > or short-lived certs, because these reduces latency and improve the >>> > quality of revocation information. >>> > >>> > Revocation for CA certificates is currently done by having browsers >>> > download a list from a centralized server, since there's no way to >>> > staple more than one OCSP response. That solution works OK for the >>> > web, but if I were designing something de novo, I would probably >>> > use multi-stapling as well. >>> > >>> > >>> > # Applying this experience to STIR >>> > >>> > Most of the below appear to be desired properties by the WG: >>> > >>> > * Verifier neeeds to know that a cert is valid for a specific >>> > number >>> > * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >>> > issued longer) >>> > * Caller privacy: Don't report what calls someone receives to a >>> > central server >>> > * Carrier privacy: Don't allow a third party to figure out all the >>> > numbers a carrier holds >>> > * Minimize the rate at which the CA has to sign things >>> > * Tolerate outages at the CA >>> > >>> > I'm going to assume for now that we will not do live OCSP. It >>> > violates the caller privacy requirement, and as discussed above, it >>> > just sucks operationally. So STIR should require OCSP to be sent >>> > in "stapled" form, which probably means sending it in Identity-Info. >>> > And while we're at it, we should also do "multi-stapling" -- send >>> > an OCSP response for CA certs as well. >>> > >>> > So if we consider a server with 50k TNs / blocks, that leaves us >>> > with basically 3 options: >>> > >>> > 1. 50k short-lived certs (no OCSP) >>> > 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 >>> > long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >>> > with TN info >>> > >>> > (As I didn't quite get to say in the meeting, regardless of the >>> > approach, you have to have 50k of *something*.) Of these, it seems >>> > like the preference order is 2 > 1 > 3. >>> > >>> > Option 3 is bad from several perspectives: >>> > * Putting TN info in the OCSP response enables someone to trawl for >>> > numbers unless you access-control the OCSP server, so you inherit a >>> > requirement to do that. >>> > * With the rate of churn in number assignments, you're probably >>> > going to have to update the long-lived cert pretty frequently anyway. >>> > * Putting TN-specific stuff in certs is better than putting it in >>> > OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>> > worse. >>> > >>> > Option 1 is mainly bad from the perspective of CA load and outages. >>> > With Option 2, if the CA goes down, client can continue to use the >>> > long-lived cert and just not bother doing OCSP (vs. tolerating an >>> > expired cert). Slightly cleaner. Plus, there's a lot more >>> > experience caching OCSP than new certs. OCSP signing can also be >>> > delegated, so you can have the recurring operation done by a lower-ri= sk key. >>> > >>> > Option 2 should be pretty easy to automate. You can probably >>> > re-use tooling for OCSP stapling that has already been developed >>> > for use with HTTPS. If you're a big box signing for a bunch of >>> > numbers, you do need to select the right cert and OCSP response for >>> > a given call, but that's a pretty simple lookup table. >>> > _______________________________________________ >>> > 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 >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you are n= ot the intended recipient, please contact the sender and delete all copies = of the message. > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the s= ole use of the recipient(s). Any use by others is prohibited. If you are no= t the intended recipient, please contact the sender and delete all copies o= f the message. > _______________________________________________ > 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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 28 13:16:15 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFD01B2F5A for ; Tue, 28 Jul 2015 13:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=ham 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 Sg5zTeoNaWtn for ; Tue, 28 Jul 2015 13:16:10 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 150661B2F5D for ; Tue, 28 Jul 2015 13:16:10 -0700 (PDT) Received: (qmail 15593 invoked by uid 0); 28 Jul 2015 20:16:08 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy4.mail.unifiedlayer.com with SMTP; 28 Jul 2015 20:16:08 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id xvw11q0071MNPNq01vw4ER; Tue, 28 Jul 2015 13:56:06 -0600 X-Authority-Analysis: v=2.1 cv=O9qq4nNW c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=zQP7CpKOAAAA:8 a=VfgTrTGYAAAA:8 a=HLLxP2VMAAAA:8 a=Lu6jx12CAZjPgdWz_N4A:9 a=C-Ml_8uXoAHXop74:21 a=Lka-bgBgvQoeD_bx:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=DzjOOp_o1eYA:10 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; bh=eSm6ubGPrX6rIn6+sb0L+5TmGKxp3ePcEQ4RXE2XU5g=; b=OeuPwd2TBWc+bSdvCN826ZL/CPdKGlsHrFa3pgkZYmbID5mifES1+gjI0R6rkUhoUKmafdmb/c1XlU+uR1xhsbrieOPVnQYPcNKCbyRcChmh8C0FEB9Blv0z7AdcLydX; Received: from [100.36.26.202] (port=59960 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZKAyo-0006ln-Oh; Tue, 28 Jul 2015 13:56:02 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Tue, 28 Jul 2015 15:55:57 -0400 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , "DOLLY, MARTIN C" , Henning Schulzrinne Message-ID: Thread-Topic: [stir] On OCSP, TNs, and Privacy References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <7DE72B93-5458-4DF9-943C-D0F331254EC4@att.com> <1ed3b028355f401abd323b9b5488bc4e@PLSWE13M08.ad.sprint.com> In-Reply-To: <1ed3b028355f401abd323b9b5488bc4e@PLSWE13M08.ad.sprint.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "stir@ietf.org" , "PFAUTZ, PENN L" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 20:16:13 -0000 LOL .. Its a classic. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 7/28/15, 3:38 PM, "stir on behalf of Gorman, Pierce A [CTO]" wrote: >One of the better auto-corrections I suspect. > >Best regards, > > >Pierce Gorman >Core Network Planning >O: 913-439-4368 >pierce.gorman@sprint.com > > >-----Original Message----- >From: DOLLY, MARTIN C [mailto:md3135@att.com] >Sent: July 28, 2015 2:35 PM >To: Henning Schulzrinne >Cc: PFAUTZ, PENN L ; Gorman, Pierce A [CTO] >; stir@ietf.org >Subject: Re: [stir] On OCSP, TNs, and Privacy > >It has to be easy and deplorable, without creating a business case for >some 3rd party or we may just have white/black lists > >Sent from my iPhone > >> On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne >> wrote: >> >> That was certainly one of the models that have been discussed in the >>past. Particularly for small carriers, this would likely reduce the >>operational impact to a configuration option in the SBC. >> >> The disadvantage of this model is caller privacy: If the cert is >> stored at a numbering authority, it would be easy for that authority >> to know which carrier is receiving calls from whom. (It's not the >> complete meta data since it's lacking the callee information.) >> >> However, unless the TN-to-LRN (in the US) mapping is cached, this >>"leak" already exists today. >> >> -----Original Message----- >> From: PFAUTZ, PENN L [mailto:pp3129@att.com] >> Sent: Tuesday, July 28, 2015 3:14 PM >> To: Henning Schulzrinne ; Gorman, Pierce >> A [CTO] >> Cc: stir@ietf.org >> Subject: RE: [stir] On OCSP, TNs, and Privacy >> >> Forgive me but my reptile brain keeps whispering in my ear that this >>would be a lot easier if we simply had a numbering registry, whether >>distributed or centralized - like we need anyway for at least for number >>portability - that also contained the public keys. No tedious mucking >>about in cyberspace with certs, CRLs, or OCSP. >> >> >> >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning >> Schulzrinne >> Sent: Tuesday, July 28, 2015 10:24 AM >> To: Gorman, Pierce A [CTO] >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> In the US alone, we have about 4000 carriers. Managing the reputation >>of that many entities, reliably (i.e., without making false >>positive/negative mistakes) seems a whole lot more manual effort than >>storing bags of bits. Storage and automation is cheap, human judgement >>and dealing with mistakes is expensive. >> >> Obviously, nothing in the architecture prevents wildcard certificates. >> >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce >> A [CTO] >> Sent: Tuesday, July 28, 2015 10:14 AM >> To: Richard Barnes >> Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen >> >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> I thought the discussion was on key/cert management. I'm asking if I >>understood the suggestion to minimize requirements. How is that off >>topic? >> >> Best regards, >> >> >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> -----Original Message----- >> From: Richard Barnes [mailto:rlb@ipv.sx] >> Sent: July 28, 2015 9:12 AM >> To: Gorman, Pierce A [CTO] >> Cc: Alex Bobotek ; Brian Rosen ; >> stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >>> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] >>> wrote: >>> "Large scale certificate management is expensive, and TN-specific >>>certificates are unneeded for securing calls placed by parties who >>>choose to place calls through a single reputable telephone service >>>provider." >>> >>> Are you saying that for "on-net" calls, STIR methodology is >>>unnecessary? >> >> This seems a little off-topic for this list. >> >> --Richard >> >>> >>> Best regards, >>> >>> >>> Pierce Gorman >>> Core Network Planning >>> O: 913-439-4368 >>> pierce.gorman@sprint.com >>> >>> >>> -----Original Message----- >>> From: Alex Bobotek [mailto:alex@bobotek.net] >>> Sent: July 27, 2015 11:36 PM >>> To: Brian Rosen ; Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> What motivation would a carrier have to choose any model other than >>>carrier signing using one of a very limited set of carrier-owned keys? >>>Large scale certificate management is expensive, and TN-specific >>>certificates are unneeded for securing calls placed by parties who >>>choose to place calls through a single reputable telephone service >>>provider. Anyone can get many certificates, even a free ones >>>anonymously from some issuers. It is typically a combination of the >>>strength of the end-user authentication performed by the service >>>provider (or certificate issuer in a provider-agnostic model) and the >>>identity's history that are most useful in security. >>> >>> If we're trying to secure the current telephone system, DNS-like key >>>repositories a la DKIM or perhaps a small number (compared to the >>>number of TNs) of certificates are far more practical. >>> >>> Regards, >>> >>> Alex >>> >>>> -----Original Message----- >>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>>> Sent: Monday, July 27, 2015 7:40 PM >>>> To: Richard Barnes >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>> >>>> What this means in practice is that it's TN per cert. >>>> >>>> I wouldn't say that it's impossible for a carrier to maintain dozens >>>> of copies of millions of private keys securely, but it's hard. You >>>> need multiple copies because you have multiple elements that can >>>> initiate a call, and you don't want to depend on a centralized >>>> resource to do something as basic as create a call. >>>> >>>> I think it's hard enough that REQUIRING cert per TN is not acceptable. >>>> >>>> Folks with more intimate knowledge of carrier SIP infrastructure >>>> might have more insight than I do. It may be acceptable to have a >>>> centralized resource to manage millions of keys. >>>> >>>> Brian >>>> >>>>> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>>>> >>>>> After the STIR meeting in Prague, Henning and I spent a few minutes >>>>> talking through options for revocation checking and certificate >>>>> scoping, and I think we have a better idea of what the optimal >>>>> solution looks like. Some notes are below, and some slides with >>>>> pictures attached. >>>>> >>>>> tl;dr: We should: >>>>> * Keep TNs in certificates and not bother with any OCSP extensions >>>>> * Require Identity-Info to include OCSP responses for all certs in >>>>> the chain >>>>> >>>>> >>>>> # Background: Revocation in the web PKI >>>>> >>>>> In an HTTPS transaction, the HTTPS server provides the client with >>>>> a certificate, and it can optionally include an OCSP response >>>>>("staple" >>>>> it to the transaction). >>>>> >>>>> A certificate contains a validity interval, a key, and some >>>>>names/TNs. >>>>> An OCSP responses contains a validity interval, a certificate ID >>>>> (i.e., a hash), and a status (good/revoked/unknown). In the web >>>>> PKI, certificates are required to be no more than 39 months long, >>>>> and OCSP responses no more than 10 days. >>>>> >>>>> Ideally, a client only considers a certificate valid if it is >>>>> accompanied by an OCSP response. In practice, this is not always >>>>> possible; because OCSP queries fail around 3% of the time, browsers >>>>> can't require OCSP. This operational fact will be important below, >>>>> but we will continue to have scoping cert lifetimes as an objective. >>>>> >>>>> In the web PKI, there are basically three revocation checking >>>>>modalities: >>>>> >>>>> 1. Live OCSP checking [RFC6069] >>>>> 2. OCSP stapling / must_staple [RFC6066, >>>>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>>>> lifetime) >>>>> >>>>> (The last of these is relatively novel, and has not been deployed. >>>>> Neither has must-staple. But they're both pretty trivial, and >>>>> could be folded into a STIR architecture pretty easily.) >>>>> >>>>> Right now, about 90% of TLS transactions use live OCSP, and about >>>>>10%. >>>>> CAs and browsers dearly want the world to move toward stapled OCSP >>>>> or short-lived certs, because these reduces latency and improve the >>>>> quality of revocation information. >>>>> >>>>> Revocation for CA certificates is currently done by having browsers >>>>> download a list from a centralized server, since there's no way to >>>>> staple more than one OCSP response. That solution works OK for the >>>>> web, but if I were designing something de novo, I would probably >>>>> use multi-stapling as well. >>>>> >>>>> >>>>> # Applying this experience to STIR >>>>> >>>>> Most of the below appear to be desired properties by the WG: >>>>> >>>>> * Verifier neeeds to know that a cert is valid for a specific >>>>> number >>>>> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >>>>> issued longer) >>>>> * Caller privacy: Don't report what calls someone receives to a >>>>> central server >>>>> * Carrier privacy: Don't allow a third party to figure out all the >>>>> numbers a carrier holds >>>>> * Minimize the rate at which the CA has to sign things >>>>> * Tolerate outages at the CA >>>>> >>>>> I'm going to assume for now that we will not do live OCSP. It >>>>> violates the caller privacy requirement, and as discussed above, it >>>>> just sucks operationally. So STIR should require OCSP to be sent >>>>> in "stapled" form, which probably means sending it in Identity-Info. >>>>> And while we're at it, we should also do "multi-stapling" -- send >>>>> an OCSP response for CA certs as well. >>>>> >>>>> So if we consider a server with 50k TNs / blocks, that leaves us >>>>> with basically 3 options: >>>>> >>>>> 1. 50k short-lived certs (no OCSP) >>>>> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 >>>>> long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >>>>> with TN info >>>>> >>>>> (As I didn't quite get to say in the meeting, regardless of the >>>>> approach, you have to have 50k of *something*.) Of these, it seems >>>>> like the preference order is 2 > 1 > 3. >>>>> >>>>> Option 3 is bad from several perspectives: >>>>> * Putting TN info in the OCSP response enables someone to trawl for >>>>> numbers unless you access-control the OCSP server, so you inherit a >>>>> requirement to do that. >>>>> * With the rate of churn in number assignments, you're probably >>>>> going to have to update the long-lived cert pretty frequently anyway. >>>>> * Putting TN-specific stuff in certs is better than putting it in >>>>> OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>>>> worse. >>>>> >>>>> Option 1 is mainly bad from the perspective of CA load and outages. >>>>> With Option 2, if the CA goes down, client can continue to use the >>>>> long-lived cert and just not bother doing OCSP (vs. tolerating an >>>>> expired cert). Slightly cleaner. Plus, there's a lot more >>>>> experience caching OCSP than new certs. OCSP signing can also be >>>>> delegated, so you can have the recurring operation done by a >>>>>lower-risk key. >>>>> >>>>> Option 2 should be pretty easy to automate. You can probably >>>>> re-use tooling for OCSP stapling that has already been developed >>>>> for use with HTTPS. If you're a big box signing for a bunch of >>>>> numbers, you do need to select the right cert and OCSP response for >>>>> a given call, but that's a pretty simple lookup table. >>>>> _______________________________________________ >>>>> 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 >>> >>> ________________________________ >>> >>> This e-mail may contain Sprint proprietary information intended for >>>the sole use of the recipient(s). Any use by others is prohibited. If >>>you are not the intended recipient, please contact the sender and >>>delete all copies of the message. >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the >>sole use of the recipient(s). Any use by others is prohibited. If you >>are not the intended recipient, please contact the sender and delete all >>copies of the message. >> _______________________________________________ >> 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 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 28 13:23:12 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A511B2FE3 for ; Tue, 28 Jul 2015 13:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 TxQ9CTJOkfcL for ; Tue, 28 Jul 2015 13:23:08 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id EB17F1B2FB4 for ; Tue, 28 Jul 2015 13:23:07 -0700 (PDT) Received: (qmail 21740 invoked by uid 0); 28 Jul 2015 20:23:06 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 28 Jul 2015 20:23:05 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id y2311q0061MNPNq012347F; Tue, 28 Jul 2015 20:03:05 -0600 X-Authority-Analysis: v=2.1 cv=Qc314Krv c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=ZsyXEVtvAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=VfgTrTGYAAAA:8 a=HLLxP2VMAAAA:8 a=hb8Mmy9yDPF4MrbzCjsA:9 a=rZ0WBvYbc9iuAwwr:21 a=iAEdN5-KMBP-y3C0:21 a=wPNLvfGTeEIA:10 a=DzjOOp_o1eYA:10 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; bh=hXloQQgMleiVL1fQaexKw60csLJDgfUleFqx5ZCF3m4=; b=mQSwB0gEHyHKTYXF0ReGaryMCxu5WEYFh6KM9wZ8S8nK76Q6jUiJAIEZyGVfH8RuclsKTP7TA+G5t7Qjv6ExGehhRZtIHv4WQ3ZaVLtTI2uidCFdjYsL56e3OTE1JTpZ; Received: from [100.36.26.202] (port=59964 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZKB5Z-00041X-Im; Tue, 28 Jul 2015 14:03:01 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Tue, 28 Jul 2015 16:02:56 -0400 From: Richard Shockey To: "Dwight, Timothy M (Tim)" , Henning Schulzrinne , "PFAUTZ, PENN L" , "Gorman, Pierce A [CTO]" Message-ID: Thread-Topic: [stir] On OCSP, TNs, and Privacy References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <2B0F677F0B95454297753F58D4A07FA3027C2B0B09@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3027C2B0B09@FHDP1LUMXC7V31.us.one.verizon.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 20:23:10 -0000 Exactly everything is cached. But its the same system in Canada and most of the smaller European countries. The Dutch COIN system operates very much like the US NPAC model of a centralized authority but it is a non profit cooperative like RIPE or ARIN. Very very cost effective for the Dutch operators. Ireland Sweden Finland are the same as well. On 7/28/15, 3:49 PM, "stir on behalf of Dwight, Timothy M (Tim)" wrote: >In all U.S. networks I'm familiar with, the TN-to-LRN mapping is cached. >I assume that the same model would work if we added public keys to what >Penn calls the numbering registry. > >This of course is a US -centric solution since it assumes that caches in >the originating network are populated from a centralized authority. > >tim > >-----Original Message----- >From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne >Sent: Tuesday, July 28, 2015 2:27 PM >To: PFAUTZ, PENN L; Gorman, Pierce A [CTO] >Cc: stir@ietf.org >Subject: Re: [stir] On OCSP, TNs, and Privacy > >That was certainly one of the models that have been discussed in the >past. Particularly for small carriers, this would likely reduce the >operational impact to a configuration option in the SBC. > >The disadvantage of this model is caller privacy: If the cert is stored >at a numbering authority, it would be easy for that authority to know >which carrier is receiving calls from whom. (It's not the complete meta >data since it's lacking the callee information.) > >However, unless the TN-to-LRN (in the US) mapping is cached, this "leak" >already exists today. > >-----Original Message----- >From: PFAUTZ, PENN L [mailto:pp3129@att.com] >Sent: Tuesday, July 28, 2015 3:14 PM >To: Henning Schulzrinne ; Gorman, Pierce A >[CTO] >Cc: stir@ietf.org >Subject: RE: [stir] On OCSP, TNs, and Privacy > >Forgive me but my reptile brain keeps whispering in my ear that this >would be a lot easier if we simply had a numbering registry, whether >distributed or centralized - like we need anyway for at least for number >portability - that also contained the public keys. No tedious mucking >about in cyberspace with certs, CRLs, or OCSP. > > > >-----Original Message----- >From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne >Sent: Tuesday, July 28, 2015 10:24 AM >To: Gorman, Pierce A [CTO] >Cc: stir@ietf.org >Subject: Re: [stir] On OCSP, TNs, and Privacy > >In the US alone, we have about 4000 carriers. Managing the reputation of >that many entities, reliably (i.e., without making false >positive/negative mistakes) seems a whole lot more manual effort than >storing bags of bits. Storage and automation is cheap, human judgement >and dealing with mistakes is expensive. > >Obviously, nothing in the architecture prevents wildcard certificates. > >-----Original Message----- >From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A >[CTO] >Sent: Tuesday, July 28, 2015 10:14 AM >To: Richard Barnes >Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen > >Subject: Re: [stir] On OCSP, TNs, and Privacy > >I thought the discussion was on key/cert management. I'm asking if I >understood the suggestion to minimize requirements. How is that off >topic? > >Best regards, > > >Pierce Gorman >Core Network Planning >O: 913-439-4368 >pierce.gorman@sprint.com > > >-----Original Message----- >From: Richard Barnes [mailto:rlb@ipv.sx] >Sent: July 28, 2015 9:12 AM >To: Gorman, Pierce A [CTO] >Cc: Alex Bobotek ; Brian Rosen ; >stir@ietf.org >Subject: Re: [stir] On OCSP, TNs, and Privacy > >On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] > wrote: >> "Large scale certificate management is expensive, and TN-specific >>certificates are unneeded for securing calls placed by parties who >>choose to place calls through a single reputable telephone service >>provider." >> >> Are you saying that for "on-net" calls, STIR methodology is unnecessary? > >This seems a little off-topic for this list. > >--Richard > >> >> Best regards, >> >> >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> -----Original Message----- >> From: Alex Bobotek [mailto:alex@bobotek.net] >> Sent: July 27, 2015 11:36 PM >> To: Brian Rosen ; Richard Barnes >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> What motivation would a carrier have to choose any model other than >>carrier signing using one of a very limited set of carrier-owned keys? >>Large scale certificate management is expensive, and TN-specific >>certificates are unneeded for securing calls placed by parties who >>choose to place calls through a single reputable telephone service >>provider. Anyone can get many certificates, even a free ones >>anonymously from some issuers. It is typically a combination of the >>strength of the end-user authentication performed by the service >>provider (or certificate issuer in a provider-agnostic model) and the >>identity's history that are most useful in security. >> >> If we're trying to secure the current telephone system, DNS-like key >>repositories a la DKIM or perhaps a small number (compared to the number >>of TNs) of certificates are far more practical. >> >> Regards, >> >> Alex >> >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>> Sent: Monday, July 27, 2015 7:40 PM >>> To: Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> What this means in practice is that it=B9s TN per cert. >>> >>> I wouldn=B9t say that it=B9s impossible for a carrier to maintain dozens >>> of copies of millions of private keys securely, but it=B9s hard. You >>> need multiple copies because you have multiple elements that can >>> initiate a call, and you don=B9t want to depend on a centralized >>> resource to do something as basic as create a call. >>> >>> I think it=B9s hard enough that REQUIRING cert per TN is not acceptable. >>> >>> Folks with more intimate knowledge of carrier SIP infrastructure >>> might have more insight than I do. It may be acceptable to have a >>> centralized resource to manage millions of keys. >>> >>> Brian >>> >>> > On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>> > >>> > After the STIR meeting in Prague, Henning and I spent a few minutes >>> > talking through options for revocation checking and certificate >>> > scoping, and I think we have a better idea of what the optimal >>> > solution looks like. Some notes are below, and some slides with >>> > pictures attached. >>> > >>> > tl;dr: We should: >>> > * Keep TNs in certificates and not bother with any OCSP extensions >>> > * Require Identity-Info to include OCSP responses for all certs in >>> > the chain >>> > >>> > >>> > # Background: Revocation in the web PKI >>> > >>> > In an HTTPS transaction, the HTTPS server provides the client with >>> > a certificate, and it can optionally include an OCSP response >>>("staple" >>> > it to the transaction). >>> > >>> > A certificate contains a validity interval, a key, and some >>>names/TNs. >>> > An OCSP responses contains a validity interval, a certificate ID >>> > (i.e., a hash), and a status (good/revoked/unknown). In the web >>> > PKI, certificates are required to be no more than 39 months long, >>> > and OCSP responses no more than 10 days. >>> > >>> > Ideally, a client only considers a certificate valid if it is >>> > accompanied by an OCSP response. In practice, this is not always >>> > possible; because OCSP queries fail around 3% of the time, browsers >>> > can't require OCSP. This operational fact will be important below, >>> > but we will continue to have scoping cert lifetimes as an objective. >>> > >>> > In the web PKI, there are basically three revocation checking >>>modalities: >>> > >>> > 1. Live OCSP checking [RFC6069] >>> > 2. OCSP stapling / must_staple [RFC6066, >>> > draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>> > lifetime) >>> > >>> > (The last of these is relatively novel, and has not been deployed. >>> > Neither has must-staple. But they're both pretty trivial, and >>> > could be folded into a STIR architecture pretty easily.) >>> > >>> > Right now, about 90% of TLS transactions use live OCSP, and about >>>10%. >>> > CAs and browsers dearly want the world to move toward stapled OCSP >>> > or short-lived certs, because these reduces latency and improve the >>> > quality of revocation information. >>> > >>> > Revocation for CA certificates is currently done by having browsers >>> > download a list from a centralized server, since there's no way to >>> > staple more than one OCSP response. That solution works OK for the >>> > web, but if I were designing something de novo, I would probably >>> > use multi-stapling as well. >>> > >>> > >>> > # Applying this experience to STIR >>> > >>> > Most of the below appear to be desired properties by the WG: >>> > >>> > * Verifier neeeds to know that a cert is valid for a specific >>> > number >>> > * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >>> > issued longer) >>> > * Caller privacy: Don't report what calls someone receives to a >>> > central server >>> > * Carrier privacy: Don't allow a third party to figure out all the >>> > numbers a carrier holds >>> > * Minimize the rate at which the CA has to sign things >>> > * Tolerate outages at the CA >>> > >>> > I'm going to assume for now that we will not do live OCSP. It >>> > violates the caller privacy requirement, and as discussed above, it >>> > just sucks operationally. So STIR should require OCSP to be sent >>> > in "stapled" form, which probably means sending it in Identity-Info. >>> > And while we're at it, we should also do "multi-stapling" -- send >>> > an OCSP response for CA certs as well. >>> > >>> > So if we consider a server with 50k TNs / blocks, that leaves us >>> > with basically 3 options: >>> > >>> > 1. 50k short-lived certs (no OCSP) >>> > 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 >>> > long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >>> > with TN info >>> > >>> > (As I didn't quite get to say in the meeting, regardless of the >>> > approach, you have to have 50k of *something*.) Of these, it seems >>> > like the preference order is 2 > 1 > 3. >>> > >>> > Option 3 is bad from several perspectives: >>> > * Putting TN info in the OCSP response enables someone to trawl for >>> > numbers unless you access-control the OCSP server, so you inherit a >>> > requirement to do that. >>> > * With the rate of churn in number assignments, you're probably >>> > going to have to update the long-lived cert pretty frequently anyway. >>> > * Putting TN-specific stuff in certs is better than putting it in >>> > OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>> > worse. >>> > >>> > Option 1 is mainly bad from the perspective of CA load and outages. >>> > With Option 2, if the CA goes down, client can continue to use the >>> > long-lived cert and just not bother doing OCSP (vs. tolerating an >>> > expired cert). Slightly cleaner. Plus, there's a lot more >>> > experience caching OCSP than new certs. OCSP signing can also be >>> > delegated, so you can have the recurring operation done by a >>>lower-risk key. >>> > >>> > Option 2 should be pretty easy to automate. You can probably >>> > re-use tooling for OCSP stapling that has already been developed >>> > for use with HTTPS. If you're a big box signing for a bunch of >>> > numbers, you do need to select the right cert and OCSP response for >>> > a given call, but that's a pretty simple lookup table. >>> > _______________________________________________ >>> > 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 >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the >>sole use of the recipient(s). Any use by others is prohibited. If you >>are not the intended recipient, please contact the sender and delete all >>copies of the message. > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. >_______________________________________________ >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 >_______________________________________________ >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 From nobody Tue Jul 28 15:21:56 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1911B32D1 for ; Tue, 28 Jul 2015 15:21:54 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 yg9RhrErrVwQ for ; Tue, 28 Jul 2015 15:21:52 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477A61B32D3 for ; Tue, 28 Jul 2015 15:21:51 -0700 (PDT) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-08v.sys.comcast.net with comcast id xyMp1q0084zp9eg01yMpuj; Tue, 28 Jul 2015 22:21:49 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by resomta-po-07v.sys.comcast.net with comcast id xyMo1q0094EJ4tY01yMooe; Tue, 28 Jul 2015 22:21:49 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Tue, 28 Jul 2015 15:19:29 -0700 From: Alex Bobotek To: "Gorman, Pierce A [CTO]" , Brian Rosen , Richard Barnes Date: Tue, 28 Jul 2015 15:21:46 -0700 Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3w5jYQgACJ60A= Message-ID: <4B1956260CD29F4A9622F00322FE0531011D3D1D5046@BOBO1A.bobotek.net> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> In-Reply-To: <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1438122109; bh=DvGFpyfOjWvlHrslQUt42mMg4ujS5Musfpj4r1+x1p8=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=IvAjOUPUYMsOMI60QQ2RsKLVaOhWVHwdBDIIVEZn6sa/l0qAbMsJw1cxf8/Dkq9Mg M/yoBgb/adaY/MhKu81z5q9vuEzMVD6C1lNFfsJoLVzcbuNl72UUNIQTgH5c+veuWj TjzX2PimWZK+i2BOiSSpIPbaeAr+uALJYgsLHMEzp2Eda5xBpVxGzFj21Xu9pVZ5g4 BKjOHhHg5MhYNIt5YM1FBHmF0bBKu+W4GZ8xHRAwJelitoIqWk/2aIDo2lK/AnbP0p zFRgQ0Mk18MIn0MaEkwrpdZqyRUzVXgYHD4QEzbil0LemwL+P9Cx/dKnjajtW+QBA+ 7ABY+vo4BTomA== Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 22:21:55 -0000 UGllcmNlLA0KDQpJIGFwcHJlY2lhdGUgeW91ciBxdWVzdGlvbiwgYW5kIHdpbGwgdHJ5IHRvIGJl IGxlc3MgYWJzdHJhY3QuICBQdW5jaCBsaW5lIGlzIG5lYXIgdGhlIGVuZC4gIA0KDQpJIGFtIHNh eWluZyB0aGF0IF9jZXJ0aWZpY2F0ZXNfIGFyZSBub3QgbmVlZGVkIGZvciBhdXRoLiAgQSBjb2xs ZWN0aW9uIG9mIHNlcnZpY2UgcHJvdmlkZXIgcHVibGljIGtleXMgc3RvcmVkIGluIHNvbWUgcmVw b3NpdG9yeSAoZS5nLiwgaW4gRU5VTSBvciBETlMpIGlzIGFuIGFsdGVybmF0aXZlLiAgQXMgb3Vy IHRyYW5zcG9ydCBuZXR3b3JrcyBhbHJlYWR5IHVzZSByZWdpc3RyaWVzIHRoYXQgY2FuIHNlcnZl ciBhcyByZXBvc2l0b3JpZXMsIGFuZCB0aGV5IGhhdmUgYSBkZWdyZWUgb2Ygc2VjdXJpdHkgdGhh dCBhbGxvd3MgYSBzZXJ2aW5nIGNhcnJpZXIgdG8gc3BlY2lmeSBhIHRydXN0ZWQgcGFyYW1ldGVy LCBpdCBzZWVtcyB0byBiZSB0aGUgbW9zdCBwcmFjdGljYWwgc29sdXRpb24uICBUaGlzIGlzIHdo YXQgd2FzIGRvbmUgaW4gREtJTSwgYW5kIGl0IGNsZWFybHkgd29ya3MuDQoNCkFuZCBhcyBvdGhl cnMgaGF2ZSBhbHNvIHN1Z2dlc3RlZCwgdGhpcyBpcyBzaW1wbGVyIHRoYW4gY3JlYXRpbmcgYSBj ZXJ0aWZpY2F0ZSBkaXN0cmlidXRpb24gYW5kIG1hbmFnZW1lbnQgaW5mcmFzdHJ1Y3R1cmUuICAN Cg0KUHVuY2ggbGluZTogDQpZZXMsIEkgYW0gbW9zdCBkZWZpbml0ZWx5IGV4cHJlc3NpbmcgdGhl IG9waW5pb24gdGhhdCBJRVRGIHNob3VsZCB3b3JrIG9uIHN0YW5kYXJkcyBmb3IgYSByZWdpc3Ry eS1iYXNlZCBwdWJsaWMga2V5IHJlcG9zaXRvcnkgYW5kIHJlZ2lzdHJ5LWJhc2VkIHZhbGlkYXRp b24gbWV0aG9kcyB0byBiZSB1c2VkIGZvciBTVElSIHZhbGlkYXRpb24uICBJIGhvcGUgdGhhdCB0 aGVyZSBhcmUgb3RoZXIgbGlrZS1taW5kZWQgcGVvcGxlIHRvIGpvaW4gaW4gcHJvZHVjaW5nIGFu IEludGVybmV0IERyYWZ0IG9uIHRoaXMuICANCg0KUmVnYXJkcywNCg0KQWxleA0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdvcm1hbiwgUGllcmNlIEEgW0NUT10gW21h aWx0bzpQaWVyY2UuR29ybWFuQHNwcmludC5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMjgs IDIwMTUgNjo1MiBBTQ0KPiBUbzogQWxleCBCb2JvdGVrIDxhbGV4QGJvYm90ZWsubmV0PjsgQnJp YW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PjsNCj4gUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYu c3g+DQo+IENjOiBzdGlyQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbc3Rpcl0gT24gT0NTUCwg VE5zLCBhbmQgUHJpdmFjeQ0KPiANCj4gIkxhcmdlIHNjYWxlIGNlcnRpZmljYXRlIG1hbmFnZW1l bnQgaXMgZXhwZW5zaXZlLCBhbmQgVE4tc3BlY2lmaWMgY2VydGlmaWNhdGVzDQo+IGFyZSB1bm5l ZWRlZCBmb3Igc2VjdXJpbmcgY2FsbHMgcGxhY2VkIGJ5IHBhcnRpZXMgd2hvIGNob29zZSB0byBw bGFjZSBjYWxscw0KPiB0aHJvdWdoIGEgc2luZ2xlIHJlcHV0YWJsZSB0ZWxlcGhvbmUgc2Vydmlj ZSBwcm92aWRlci4iDQo+IA0KPiBBcmUgeW91IHNheWluZyB0aGF0IGZvciAib24tbmV0IiBjYWxs cywgU1RJUiBtZXRob2RvbG9neSBpcyB1bm5lY2Vzc2FyeT8NCj4gDQo+IEJlc3QgcmVnYXJkcywN Cj4gDQo+IA0KPiBQaWVyY2UgR29ybWFuDQo+IENvcmUgTmV0d29yayBQbGFubmluZw0KPiBPOiA5 MTMtNDM5LTQzNjgNCj4gcGllcmNlLmdvcm1hbkBzcHJpbnQuY29tDQo+IA0KPiANCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleCBCb2JvdGVrIFttYWlsdG86YWxleEBi b2JvdGVrLm5ldF0NCj4gU2VudDogSnVseSAyNywgMjAxNSAxMTozNiBQTQ0KPiBUbzogQnJpYW4g Um9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PjsgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+DQo+ IENjOiBzdGlyQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwgVE5zLCBh bmQgUHJpdmFjeQ0KPiANCj4gV2hhdCBtb3RpdmF0aW9uIHdvdWxkIGEgY2FycmllciBoYXZlIHRv IGNob29zZSBhbnkgbW9kZWwgb3RoZXIgdGhhbiBjYXJyaWVyDQo+IHNpZ25pbmcgdXNpbmcgb25l IG9mIGEgdmVyeSBsaW1pdGVkIHNldCBvZiBjYXJyaWVyLW93bmVkIGtleXM/ICBMYXJnZSBzY2Fs ZQ0KPiBjZXJ0aWZpY2F0ZSBtYW5hZ2VtZW50IGlzIGV4cGVuc2l2ZSwgYW5kIFROLXNwZWNpZmlj IGNlcnRpZmljYXRlcyBhcmUNCj4gdW5uZWVkZWQgZm9yIHNlY3VyaW5nIGNhbGxzIHBsYWNlZCBi eSBwYXJ0aWVzIHdobyBjaG9vc2UgdG8gcGxhY2UgY2FsbHMNCj4gdGhyb3VnaCBhIHNpbmdsZSBy ZXB1dGFibGUgdGVsZXBob25lIHNlcnZpY2UgcHJvdmlkZXIuICBBbnlvbmUgY2FuIGdldCBtYW55 DQo+IGNlcnRpZmljYXRlcywgZXZlbiBhIGZyZWUgb25lcyBhbm9ueW1vdXNseSBmcm9tIHNvbWUg aXNzdWVycy4gIEl0IGlzIHR5cGljYWxseSBhDQo+IGNvbWJpbmF0aW9uIG9mIHRoZSBzdHJlbmd0 aCBvZiB0aGUgZW5kLXVzZXIgYXV0aGVudGljYXRpb24gcGVyZm9ybWVkIGJ5DQo+IHRoZSBzZXJ2 aWNlIHByb3ZpZGVyIChvciBjZXJ0aWZpY2F0ZSBpc3N1ZXIgaW4gYSBwcm92aWRlci1hZ25vc3Rp YyBtb2RlbCkgYW5kDQo+IHRoZSBpZGVudGl0eSdzIGhpc3RvcnkgdGhhdCBhcmUgbW9zdCB1c2Vm dWwgaW4gc2VjdXJpdHkuDQo+IA0KPiBJZiB3ZSdyZSB0cnlpbmcgdG8gc2VjdXJlIHRoZSBjdXJy ZW50IHRlbGVwaG9uZSBzeXN0ZW0sIEROUy1saWtlIGtleQ0KPiByZXBvc2l0b3JpZXMgYSBsYSBE S0lNIG9yIHBlcmhhcHMgYSBzbWFsbCBudW1iZXIgKGNvbXBhcmVkIHRvIHRoZSBudW1iZXINCj4g b2YgVE5zKSBvZiBjZXJ0aWZpY2F0ZXMgYXJlIGZhciBtb3JlIHByYWN0aWNhbC4NCj4gDQo+IFJl Z2FyZHMsDQo+IA0KPiBBbGV4DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEJyaWFuIFJvc2VuDQo+ID4gU2VudDogTW9uZGF5LCBKdWx5IDI3LCAyMDE1IDc6NDAgUE0NCj4g PiBUbzogUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+DQo+ID4gQ2M6IHN0aXJAaWV0Zi5vcmcN Cj4gPiBTdWJqZWN0OiBSZTogW3N0aXJdIE9uIE9DU1AsIFROcywgYW5kIFByaXZhY3kNCj4gPg0K PiA+IFdoYXQgdGhpcyBtZWFucyBpbiBwcmFjdGljZSBpcyB0aGF0IGl04oCZcyBUTiBwZXIgY2Vy dC4NCj4gPg0KPiA+IEkgd291bGRu4oCZdCBzYXkgdGhhdCBpdOKAmXMgaW1wb3NzaWJsZSBmb3Ig YSBjYXJyaWVyIHRvIG1haW50YWluIGRvemVucw0KPiA+IG9mIGNvcGllcyBvZiBtaWxsaW9ucyBv ZiBwcml2YXRlIGtleXMgc2VjdXJlbHksIGJ1dCBpdOKAmXMgaGFyZC4gIFlvdQ0KPiA+IG5lZWQg bXVsdGlwbGUgY29waWVzIGJlY2F1c2UgeW91IGhhdmUgbXVsdGlwbGUgZWxlbWVudHMgdGhhdCBj YW4NCj4gPiBpbml0aWF0ZSBhIGNhbGwsIGFuZCB5b3UgZG9u4oCZdCB3YW50IHRvIGRlcGVuZCBv biBhIGNlbnRyYWxpemVkDQo+ID4gcmVzb3VyY2UgdG8gZG8gc29tZXRoaW5nIGFzIGJhc2ljIGFz IGNyZWF0ZSBhIGNhbGwuDQo+ID4NCj4gPiBJIHRoaW5rIGl04oCZcyBoYXJkIGVub3VnaCB0aGF0 IFJFUVVJUklORyBjZXJ0IHBlciBUTiBpcyBub3QgYWNjZXB0YWJsZS4NCj4gPg0KPiA+IEZvbGtz IHdpdGggbW9yZSBpbnRpbWF0ZSBrbm93bGVkZ2Ugb2YgY2FycmllciBTSVAgaW5mcmFzdHJ1Y3R1 cmUgbWlnaHQNCj4gPiBoYXZlIG1vcmUgaW5zaWdodCB0aGFuIEkgZG8uICBJdCBtYXkgYmUgYWNj ZXB0YWJsZSB0byBoYXZlIGENCj4gPiBjZW50cmFsaXplZCByZXNvdXJjZSB0byBtYW5hZ2UgbWls bGlvbnMgb2Yga2V5cy4NCj4gPg0KPiA+IEJyaWFuDQo+ID4NCj4gPiA+IE9uIEp1bCAyNywgMjAx NSwgYXQgNjoxMyBQTSwgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+IHdyb3RlOg0KPiA+ID4N Cj4gPiA+IEFmdGVyIHRoZSBTVElSIG1lZXRpbmcgaW4gUHJhZ3VlLCBIZW5uaW5nIGFuZCBJIHNw ZW50IGEgZmV3IG1pbnV0ZXMNCj4gPiA+IHRhbGtpbmcgdGhyb3VnaCBvcHRpb25zIGZvciByZXZv Y2F0aW9uIGNoZWNraW5nIGFuZCBjZXJ0aWZpY2F0ZQ0KPiA+ID4gc2NvcGluZywgYW5kIEkgdGhp bmsgd2UgaGF2ZSBhIGJldHRlciBpZGVhIG9mIHdoYXQgdGhlIG9wdGltYWwNCj4gPiA+IHNvbHV0 aW9uIGxvb2tzIGxpa2UuICBTb21lIG5vdGVzIGFyZSBiZWxvdywgYW5kIHNvbWUgc2xpZGVzIHdp dGgNCj4gPiA+IHBpY3R1cmVzIGF0dGFjaGVkLg0KPiA+ID4NCj4gPiA+IHRsO2RyOiBXZSBzaG91 bGQ6DQo+ID4gPiAqIEtlZXAgVE5zIGluIGNlcnRpZmljYXRlcyBhbmQgbm90IGJvdGhlciB3aXRo IGFueSBPQ1NQIGV4dGVuc2lvbnMNCj4gPiA+ICogUmVxdWlyZSBJZGVudGl0eS1JbmZvIHRvIGlu Y2x1ZGUgT0NTUCByZXNwb25zZXMgZm9yIGFsbCBjZXJ0cyBpbg0KPiA+ID4gdGhlIGNoYWluDQo+ ID4gPg0KPiA+ID4NCj4gPiA+ICMgQmFja2dyb3VuZDogUmV2b2NhdGlvbiBpbiB0aGUgd2ViIFBL SQ0KPiA+ID4NCj4gPiA+IEluIGFuIEhUVFBTIHRyYW5zYWN0aW9uLCB0aGUgSFRUUFMgc2VydmVy IHByb3ZpZGVzIHRoZSBjbGllbnQgd2l0aCBhDQo+ID4gPiBjZXJ0aWZpY2F0ZSwgYW5kIGl0IGNh biBvcHRpb25hbGx5IGluY2x1ZGUgYW4gT0NTUCByZXNwb25zZSAoInN0YXBsZSINCj4gPiA+IGl0 IHRvIHRoZSB0cmFuc2FjdGlvbikuDQo+ID4gPg0KPiA+ID4gQSBjZXJ0aWZpY2F0ZSBjb250YWlu cyBhIHZhbGlkaXR5IGludGVydmFsLCBhIGtleSwgYW5kIHNvbWUgbmFtZXMvVE5zLg0KPiA+ID4g QW4gT0NTUCByZXNwb25zZXMgY29udGFpbnMgYSB2YWxpZGl0eSBpbnRlcnZhbCwgYSBjZXJ0aWZp Y2F0ZSBJRA0KPiA+ID4gKGkuZS4sIGEgaGFzaCksIGFuZCBhIHN0YXR1cyAoZ29vZC9yZXZva2Vk L3Vua25vd24pLiAgSW4gdGhlIHdlYg0KPiA+ID4gUEtJLCBjZXJ0aWZpY2F0ZXMgYXJlIHJlcXVp cmVkIHRvIGJlIG5vIG1vcmUgdGhhbiAzOSBtb250aHMgbG9uZywNCj4gPiA+IGFuZCBPQ1NQIHJl c3BvbnNlcyBubyBtb3JlIHRoYW4gMTAgZGF5cy4NCj4gPiA+DQo+ID4gPiBJZGVhbGx5LCBhIGNs aWVudCBvbmx5IGNvbnNpZGVycyBhIGNlcnRpZmljYXRlIHZhbGlkIGlmIGl0IGlzDQo+ID4gPiBh Y2NvbXBhbmllZCBieSBhbiBPQ1NQIHJlc3BvbnNlLiAgSW4gcHJhY3RpY2UsIHRoaXMgaXMgbm90 IGFsd2F5cw0KPiA+ID4gcG9zc2libGU7IGJlY2F1c2UgT0NTUCBxdWVyaWVzIGZhaWwgYXJvdW5k IDMlIG9mIHRoZSB0aW1lLCBicm93c2Vycw0KPiA+ID4gY2FuJ3QgcmVxdWlyZSBPQ1NQLiAgVGhp cyBvcGVyYXRpb25hbCBmYWN0IHdpbGwgYmUgaW1wb3J0YW50IGJlbG93LA0KPiA+ID4gYnV0IHdl IHdpbGwgY29udGludWUgdG8gaGF2ZSBzY29waW5nIGNlcnQgbGlmZXRpbWVzIGFzIGFuIG9iamVj dGl2ZS4NCj4gPiA+DQo+ID4gPiBJbiB0aGUgd2ViIFBLSSwgdGhlcmUgYXJlIGJhc2ljYWxseSB0 aHJlZSByZXZvY2F0aW9uIGNoZWNraW5nIG1vZGFsaXRpZXM6DQo+ID4gPg0KPiA+ID4gMS4gTGl2 ZSBPQ1NQIGNoZWNraW5nIFtSRkM2MDY5XQ0KPiA+ID4gMi4gT0NTUCBzdGFwbGluZyAvIG11c3Rf c3RhcGxlIFtSRkM2MDY2LA0KPiA+ID4gZHJhZnQtaGFsbGFtYmFrZXItdGxzZmVhdHVyZV0gMy4g U2hvcnQtbGl2ZWQgY2VydGlmaWNhdGVzICh+T0NTUA0KPiA+ID4gbGlmZXRpbWUpDQo+ID4gPg0K PiA+ID4gKFRoZSBsYXN0IG9mIHRoZXNlIGlzIHJlbGF0aXZlbHkgbm92ZWwsIGFuZCBoYXMgbm90 IGJlZW4gZGVwbG95ZWQuDQo+ID4gPiBOZWl0aGVyIGhhcyBtdXN0LXN0YXBsZS4gIEJ1dCB0aGV5 J3JlIGJvdGggcHJldHR5IHRyaXZpYWwsIGFuZCBjb3VsZA0KPiA+ID4gYmUgZm9sZGVkIGludG8g YSBTVElSIGFyY2hpdGVjdHVyZSBwcmV0dHkgZWFzaWx5LikNCj4gPiA+DQo+ID4gPiBSaWdodCBu b3csIGFib3V0IDkwJSBvZiBUTFMgdHJhbnNhY3Rpb25zIHVzZSBsaXZlIE9DU1AsIGFuZCBhYm91 dCAxMCUuDQo+ID4gPiBDQXMgYW5kIGJyb3dzZXJzIGRlYXJseSB3YW50IHRoZSB3b3JsZCB0byBt b3ZlIHRvd2FyZCBzdGFwbGVkIE9DU1ANCj4gPiA+IG9yIHNob3J0LWxpdmVkIGNlcnRzLCBiZWNh dXNlIHRoZXNlIHJlZHVjZXMgbGF0ZW5jeSBhbmQgaW1wcm92ZSB0aGUNCj4gPiA+IHF1YWxpdHkg b2YgcmV2b2NhdGlvbiBpbmZvcm1hdGlvbi4NCj4gPiA+DQo+ID4gPiBSZXZvY2F0aW9uIGZvciBD QSBjZXJ0aWZpY2F0ZXMgaXMgY3VycmVudGx5IGRvbmUgYnkgaGF2aW5nIGJyb3dzZXJzDQo+ID4g PiBkb3dubG9hZCBhIGxpc3QgZnJvbSBhIGNlbnRyYWxpemVkIHNlcnZlciwgc2luY2UgdGhlcmUn cyBubyB3YXkgdG8NCj4gPiA+IHN0YXBsZSBtb3JlIHRoYW4gb25lIE9DU1AgcmVzcG9uc2UuICBU aGF0IHNvbHV0aW9uIHdvcmtzIE9LIGZvciB0aGUNCj4gPiA+IHdlYiwgYnV0IGlmIEkgd2VyZSBk ZXNpZ25pbmcgc29tZXRoaW5nIGRlIG5vdm8sIEkgd291bGQgcHJvYmFibHkgdXNlDQo+ID4gPiBt dWx0aS1zdGFwbGluZyBhcyB3ZWxsLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAjIEFwcGx5aW5nIHRo aXMgZXhwZXJpZW5jZSB0byBTVElSDQo+ID4gPg0KPiA+ID4gTW9zdCBvZiB0aGUgYmVsb3cgYXBw ZWFyIHRvIGJlIGRlc2lyZWQgcHJvcGVydGllcyBieSB0aGUgV0c6DQo+ID4gPg0KPiA+ID4gKiBW ZXJpZmllciBuZWVlZHMgdG8ga25vdyB0aGF0IGEgY2VydCBpcyB2YWxpZCBmb3IgYSBzcGVjaWZp YyBudW1iZXINCj4gPiA+ICogU2NvcGVkIGNlcnQgbGlmZXRpbWU6IExpbWl0IGNlcnRzIHRvIH4x d2VlayBsaWZldGltZSAoYnkgT0NTUCBpZg0KPiA+ID4gaXNzdWVkIGxvbmdlcikNCj4gPiA+ICog Q2FsbGVyIHByaXZhY3k6IERvbid0IHJlcG9ydCB3aGF0IGNhbGxzIHNvbWVvbmUgcmVjZWl2ZXMg dG8gYQ0KPiA+ID4gY2VudHJhbCBzZXJ2ZXINCj4gPiA+ICogQ2FycmllciBwcml2YWN5OiBEb24n dCBhbGxvdyBhIHRoaXJkIHBhcnR5IHRvIGZpZ3VyZSBvdXQgYWxsIHRoZQ0KPiA+ID4gbnVtYmVy cyBhIGNhcnJpZXIgaG9sZHMNCj4gPiA+ICogTWluaW1pemUgdGhlIHJhdGUgYXQgd2hpY2ggdGhl IENBIGhhcyB0byBzaWduIHRoaW5ncw0KPiA+ID4gKiBUb2xlcmF0ZSBvdXRhZ2VzIGF0IHRoZSBD QQ0KPiA+ID4NCj4gPiA+IEknbSBnb2luZyB0byBhc3N1bWUgZm9yIG5vdyB0aGF0IHdlIHdpbGwg bm90IGRvIGxpdmUgT0NTUC4gIEl0DQo+ID4gPiB2aW9sYXRlcyB0aGUgY2FsbGVyIHByaXZhY3kg cmVxdWlyZW1lbnQsIGFuZCBhcyBkaXNjdXNzZWQgYWJvdmUsIGl0DQo+ID4gPiBqdXN0IHN1Y2tz IG9wZXJhdGlvbmFsbHkuICBTbyBTVElSIHNob3VsZCByZXF1aXJlIE9DU1AgdG8gYmUgc2VudCBp bg0KPiA+ID4gInN0YXBsZWQiIGZvcm0sIHdoaWNoIHByb2JhYmx5IG1lYW5zIHNlbmRpbmcgaXQg aW4gSWRlbnRpdHktSW5mby4NCj4gPiA+IEFuZCB3aGlsZSB3ZSdyZSBhdCBpdCwgd2Ugc2hvdWxk IGFsc28gZG8gIm11bHRpLXN0YXBsaW5nIiAtLSBzZW5kIGFuDQo+ID4gPiBPQ1NQIHJlc3BvbnNl IGZvciBDQSBjZXJ0cyBhcyB3ZWxsLg0KPiA+ID4NCj4gPiA+IFNvIGlmIHdlIGNvbnNpZGVyIGEg c2VydmVyIHdpdGggNTBrIFROcyAvIGJsb2NrcywgdGhhdCBsZWF2ZXMgdXMNCj4gPiA+IHdpdGgg YmFzaWNhbGx5IDMgb3B0aW9uczoNCj4gPiA+DQo+ID4gPiAxLiA1MGsgc2hvcnQtbGl2ZWQgY2Vy dHMgKG5vIE9DU1ApDQo+ID4gPiAyLiA1MGsgbG9uZy1saXZlZCBjZXJ0cyBzY29wZWQgdG8gVE5z ICsgZ2VuZXJpYyBPQ1NQIDMuIDEgbG9uZy1saXZlZA0KPiA+ID4gY2VydCBub3Qgc2NvcGVkIHRv IFROIChvciBhIGZldyBsb29zZWx5IHNjb3BlZCkgKyBPQ1NQIHdpdGggVE4gaW5mbw0KPiA+ID4N Cj4gPiA+IChBcyBJIGRpZG4ndCBxdWl0ZSBnZXQgdG8gc2F5IGluIHRoZSBtZWV0aW5nLCByZWdh cmRsZXNzIG9mIHRoZQ0KPiA+ID4gYXBwcm9hY2gsIHlvdSBoYXZlIHRvIGhhdmUgNTBrIG9mICpz b21ldGhpbmcqLikgIE9mIHRoZXNlLCBpdCBzZWVtcw0KPiA+ID4gbGlrZSB0aGUgcHJlZmVyZW5j ZSBvcmRlciBpcyAyID4gMSA+IDMuDQo+ID4gPg0KPiA+ID4gT3B0aW9uIDMgaXMgYmFkIGZyb20g c2V2ZXJhbCBwZXJzcGVjdGl2ZXM6DQo+ID4gPiAqIFB1dHRpbmcgVE4gaW5mbyBpbiB0aGUgT0NT UCByZXNwb25zZSBlbmFibGVzIHNvbWVvbmUgdG8gdHJhd2wgZm9yDQo+ID4gPiBudW1iZXJzIHVu bGVzcyB5b3UgYWNjZXNzLWNvbnRyb2wgdGhlIE9DU1Agc2VydmVyLCBzbyB5b3UgaW5oZXJpdCBh DQo+ID4gPiByZXF1aXJlbWVudCB0byBkbyB0aGF0Lg0KPiA+ID4gKiBXaXRoIHRoZSByYXRlIG9m IGNodXJuIGluIG51bWJlciBhc3NpZ25tZW50cywgeW91J3JlIHByb2JhYmx5DQo+ID4gPiBnb2lu ZyB0byBoYXZlIHRvIHVwZGF0ZSB0aGUgbG9uZy1saXZlZCBjZXJ0IHByZXR0eSBmcmVxdWVudGx5 IGFueXdheS4NCj4gPiA+ICogUHV0dGluZyBUTi1zcGVjaWZpYyBzdHVmZiBpbiBjZXJ0cyBpcyBi ZXR0ZXIgdGhhbiBwdXR0aW5nIGl0IGluDQo+ID4gPiBPQ1NQLiAgQXMgYmFkIGFzIFguNTA5IGxp YnJhcmllcyBjYW4gYmUsIE9DU1AgbGlicmFyaWVzIGFyZSBtdWNoDQo+ID4gPiB3b3JzZS4NCj4g PiA+DQo+ID4gPiBPcHRpb24gMSBpcyBtYWlubHkgYmFkIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9m IENBIGxvYWQgYW5kIG91dGFnZXMuDQo+ID4gPiBXaXRoIE9wdGlvbiAyLCBpZiB0aGUgQ0EgZ29l cyBkb3duLCBjbGllbnQgY2FuIGNvbnRpbnVlIHRvIHVzZSB0aGUNCj4gPiA+IGxvbmctbGl2ZWQg Y2VydCBhbmQganVzdCBub3QgYm90aGVyIGRvaW5nIE9DU1AgKHZzLiB0b2xlcmF0aW5nIGFuDQo+ ID4gPiBleHBpcmVkIGNlcnQpLiAgU2xpZ2h0bHkgY2xlYW5lci4gIFBsdXMsIHRoZXJlJ3MgYSBs b3QgbW9yZQ0KPiA+ID4gZXhwZXJpZW5jZSBjYWNoaW5nIE9DU1AgdGhhbiBuZXcgY2VydHMuICBP Q1NQIHNpZ25pbmcgY2FuIGFsc28gYmUNCj4gPiA+IGRlbGVnYXRlZCwgc28geW91IGNhbiBoYXZl IHRoZSByZWN1cnJpbmcgb3BlcmF0aW9uIGRvbmUgYnkgYSBsb3dlci1yaXNrDQo+IGtleS4NCj4g PiA+DQo+ID4gPiBPcHRpb24gMiBzaG91bGQgYmUgcHJldHR5IGVhc3kgdG8gYXV0b21hdGUuICBZ b3UgY2FuIHByb2JhYmx5IHJlLXVzZQ0KPiA+ID4gdG9vbGluZyBmb3IgT0NTUCBzdGFwbGluZyB0 aGF0IGhhcyBhbHJlYWR5IGJlZW4gZGV2ZWxvcGVkIGZvciB1c2UNCj4gPiA+IHdpdGggSFRUUFMu ICBJZiB5b3UncmUgYSBiaWcgYm94IHNpZ25pbmcgZm9yIGEgYnVuY2ggb2YgbnVtYmVycywgeW91 DQo+ID4gPiBkbyBuZWVkIHRvIHNlbGVjdCB0aGUgcmlnaHQgY2VydCBhbmQgT0NTUCByZXNwb25z ZSBmb3IgYSBnaXZlbiBjYWxsLA0KPiA+ID4gYnV0IHRoYXQncyBhIHByZXR0eSBzaW1wbGUgbG9v a3VwIHRhYmxlLg0KPiA+ID4NCj4gPFNUSVIucHB0eD5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gc3RpciBtYWlsaW5nIGxpc3QNCj4gPiA+IHN0 aXJAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3Rpcg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBzdGlyIG1haWxpbmcgbGlzdA0KPiA+IHN0aXJAaWV0Zi5vcmcNCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJp bnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlDQo+IHVzZSBv ZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5 b3UgYXJlIG5vdCB0aGUNCj4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUNCj4gbWVzc2FnZS4NCg== From nobody Tue Jul 28 15:43:30 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E541B3315 for ; Tue, 28 Jul 2015 15:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 l4-oxNNXAljl for ; Tue, 28 Jul 2015 15:43:26 -0700 (PDT) Received: from mail-vn0-f54.google.com (mail-vn0-f54.google.com [209.85.216.54]) (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 C02381B3317 for ; Tue, 28 Jul 2015 15:43:25 -0700 (PDT) Received: by vnk197 with SMTP id 197so48464179vnk.3 for ; Tue, 28 Jul 2015 15:43:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0E+EQkbNC1//zhvpmkocNE9JquqsGm8z9/5pHU0JHZ0=; b=jea7/xL5uUBwEGtORuGdrp7zB89t1hXPZN+TfjuU/3UKq/yPLYkrwJD8eSAe+v++kd qPUQxR46y/wiCR47buyYxPVMCrZt5irPJzsEpy122qUpus4nr07NCsrZYKlmir7uqaTa aLoXYvk6IaJJA1xdIQKDJicB/xWBF9h0i0y5sandqF18lVNtWHbxdyWs+qeXoSutm4yE i+Z895YDT0pifYrTfW0mgs7KcZQ2ppnIbuOq4CYmLwACSbVWg/KGPn/zQZJ0eD2y6wox hBntTtBBFaAwZpvgHvih7YwIz6eE1RemRzpgLf3pyYSP7IOlfaLEThPrEwszMBoK0jwe eySQ== X-Gm-Message-State: ALoCoQnslYQJ6cf9ecrMC2NwzImpnGUelcGFlK54Fc5G+lVsCttO5j2F0f+1+Ny1mogjKRHfMMd+ MIME-Version: 1.0 X-Received: by 10.52.164.173 with SMTP id yr13mr46797767vdb.12.1438123404806; Tue, 28 Jul 2015 15:43:24 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Tue, 28 Jul 2015 15:43:24 -0700 (PDT) In-Reply-To: <4B1956260CD29F4A9622F00322FE0531011D3D1D5046@BOBO1A.bobotek.net> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <4B1956260CD29F4A9622F00322FE0531011D3D1D5046@BOBO1A.bobotek.net> Date: Tue, 28 Jul 2015 18:43:24 -0400 Message-ID: From: Richard Barnes To: Alex Bobotek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , Brian Rosen Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 22:43:29 -0000 On Tue, Jul 28, 2015 at 6:21 PM, Alex Bobotek wrote: > Pierce, > > I appreciate your question, and will try to be less abstract. Punch line= is near the end. > > I am saying that _certificates_ are not needed for auth. A collection of= service provider public keys stored in some repository (e.g., in ENUM or D= NS) is an alternative. As our transport networks already use registries th= at can server as repositories, and they have a degree of security that allo= ws a serving carrier to specify a trusted parameter, it seems to be the mos= t practical solution. This is what was done in DKIM, and it clearly works. > > And as others have also suggested, this is simpler than creating a certif= icate distribution and management infrastructure. > > Punch line: > Yes, I am most definitely expressing the opinion that IETF should work on= standards for a registry-based public key repository and registry-based va= lidation methods to be used for STIR validation. I hope that there are oth= er like-minded people to join in producing an Internet Draft on this. I'm having a little trouble understanding how this solution is better than certificates at all. In either case: - the authority (CA or registry) has to maintain up-to-date info as to which numbers go with which public keys - relying parties have to know who to trust (CA or registry public key) The only difference is that if the authority issues certificates, then you don't have the crushing uptime requirements that you do with a registry. Also ENUM and DNS are clearly not acceptable solutions, unless they're done with DNSSEC. This does not seem like a win to me. --Richard > > Regards, > > Alex > >> -----Original Message----- >> From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com] >> Sent: Tuesday, July 28, 2015 6:52 AM >> To: Alex Bobotek ; Brian Rosen ; >> Richard Barnes >> Cc: stir@ietf.org >> Subject: RE: [stir] On OCSP, TNs, and Privacy >> >> "Large scale certificate management is expensive, and TN-specific certif= icates >> are unneeded for securing calls placed by parties who choose to place ca= lls >> through a single reputable telephone service provider." >> >> Are you saying that for "on-net" calls, STIR methodology is unnecessary? >> >> Best regards, >> >> >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> -----Original Message----- >> From: Alex Bobotek [mailto:alex@bobotek.net] >> Sent: July 27, 2015 11:36 PM >> To: Brian Rosen ; Richard Barnes >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> What motivation would a carrier have to choose any model other than carr= ier >> signing using one of a very limited set of carrier-owned keys? Large sc= ale >> certificate management is expensive, and TN-specific certificates are >> unneeded for securing calls placed by parties who choose to place calls >> through a single reputable telephone service provider. Anyone can get m= any >> certificates, even a free ones anonymously from some issuers. It is typ= ically a >> combination of the strength of the end-user authentication performed by >> the service provider (or certificate issuer in a provider-agnostic model= ) and >> the identity's history that are most useful in security. >> >> If we're trying to secure the current telephone system, DNS-like key >> repositories a la DKIM or perhaps a small number (compared to the number >> of TNs) of certificates are far more practical. >> >> Regards, >> >> Alex >> >> > -----Original Message----- >> > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >> > Sent: Monday, July 27, 2015 7:40 PM >> > To: Richard Barnes >> > Cc: stir@ietf.org >> > Subject: Re: [stir] On OCSP, TNs, and Privacy >> > >> > What this means in practice is that it=E2=80=99s TN per cert. >> > >> > I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier to m= aintain dozens >> > of copies of millions of private keys securely, but it=E2=80=99s hard.= You >> > need multiple copies because you have multiple elements that can >> > initiate a call, and you don=E2=80=99t want to depend on a centralized >> > resource to do something as basic as create a call. >> > >> > I think it=E2=80=99s hard enough that REQUIRING cert per TN is not acc= eptable. >> > >> > Folks with more intimate knowledge of carrier SIP infrastructure might >> > have more insight than I do. It may be acceptable to have a >> > centralized resource to manage millions of keys. >> > >> > Brian >> > >> > > On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >> > > >> > > After the STIR meeting in Prague, Henning and I spent a few minutes >> > > talking through options for revocation checking and certificate >> > > scoping, and I think we have a better idea of what the optimal >> > > solution looks like. Some notes are below, and some slides with >> > > pictures attached. >> > > >> > > tl;dr: We should: >> > > * Keep TNs in certificates and not bother with any OCSP extensions >> > > * Require Identity-Info to include OCSP responses for all certs in >> > > the chain >> > > >> > > >> > > # Background: Revocation in the web PKI >> > > >> > > In an HTTPS transaction, the HTTPS server provides the client with a >> > > certificate, and it can optionally include an OCSP response ("staple= " >> > > it to the transaction). >> > > >> > > A certificate contains a validity interval, a key, and some names/TN= s. >> > > An OCSP responses contains a validity interval, a certificate ID >> > > (i.e., a hash), and a status (good/revoked/unknown). In the web >> > > PKI, certificates are required to be no more than 39 months long, >> > > and OCSP responses no more than 10 days. >> > > >> > > Ideally, a client only considers a certificate valid if it is >> > > accompanied by an OCSP response. In practice, this is not always >> > > possible; because OCSP queries fail around 3% of the time, browsers >> > > can't require OCSP. This operational fact will be important below, >> > > but we will continue to have scoping cert lifetimes as an objective. >> > > >> > > In the web PKI, there are basically three revocation checking modali= ties: >> > > >> > > 1. Live OCSP checking [RFC6069] >> > > 2. OCSP stapling / must_staple [RFC6066, >> > > draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >> > > lifetime) >> > > >> > > (The last of these is relatively novel, and has not been deployed. >> > > Neither has must-staple. But they're both pretty trivial, and could >> > > be folded into a STIR architecture pretty easily.) >> > > >> > > Right now, about 90% of TLS transactions use live OCSP, and about 10= %. >> > > CAs and browsers dearly want the world to move toward stapled OCSP >> > > or short-lived certs, because these reduces latency and improve the >> > > quality of revocation information. >> > > >> > > Revocation for CA certificates is currently done by having browsers >> > > download a list from a centralized server, since there's no way to >> > > staple more than one OCSP response. That solution works OK for the >> > > web, but if I were designing something de novo, I would probably use >> > > multi-stapling as well. >> > > >> > > >> > > # Applying this experience to STIR >> > > >> > > Most of the below appear to be desired properties by the WG: >> > > >> > > * Verifier neeeds to know that a cert is valid for a specific number >> > > * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >> > > issued longer) >> > > * Caller privacy: Don't report what calls someone receives to a >> > > central server >> > > * Carrier privacy: Don't allow a third party to figure out all the >> > > numbers a carrier holds >> > > * Minimize the rate at which the CA has to sign things >> > > * Tolerate outages at the CA >> > > >> > > I'm going to assume for now that we will not do live OCSP. It >> > > violates the caller privacy requirement, and as discussed above, it >> > > just sucks operationally. So STIR should require OCSP to be sent in >> > > "stapled" form, which probably means sending it in Identity-Info. >> > > And while we're at it, we should also do "multi-stapling" -- send an >> > > OCSP response for CA certs as well. >> > > >> > > So if we consider a server with 50k TNs / blocks, that leaves us >> > > with basically 3 options: >> > > >> > > 1. 50k short-lived certs (no OCSP) >> > > 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 long-lived >> > > cert not scoped to TN (or a few loosely scoped) + OCSP with TN info >> > > >> > > (As I didn't quite get to say in the meeting, regardless of the >> > > approach, you have to have 50k of *something*.) Of these, it seems >> > > like the preference order is 2 > 1 > 3. >> > > >> > > Option 3 is bad from several perspectives: >> > > * Putting TN info in the OCSP response enables someone to trawl for >> > > numbers unless you access-control the OCSP server, so you inherit a >> > > requirement to do that. >> > > * With the rate of churn in number assignments, you're probably >> > > going to have to update the long-lived cert pretty frequently anyway= . >> > > * Putting TN-specific stuff in certs is better than putting it in >> > > OCSP. As bad as X.509 libraries can be, OCSP libraries are much >> > > worse. >> > > >> > > Option 1 is mainly bad from the perspective of CA load and outages. >> > > With Option 2, if the CA goes down, client can continue to use the >> > > long-lived cert and just not bother doing OCSP (vs. tolerating an >> > > expired cert). Slightly cleaner. Plus, there's a lot more >> > > experience caching OCSP than new certs. OCSP signing can also be >> > > delegated, so you can have the recurring operation done by a lower-r= isk >> key. >> > > >> > > Option 2 should be pretty easy to automate. You can probably re-use >> > > tooling for OCSP stapling that has already been developed for use >> > > with HTTPS. If you're a big box signing for a bunch of numbers, you >> > > do need to select the right cert and OCSP response for a given call, >> > > but that's a pretty simple lookup table. >> > > >> _______________________________________________ >> > > 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 >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the = sole >> use of the recipient(s). Any use by others is prohibited. If you are not= the >> intended recipient, please contact the sender and delete all copies of t= he >> message. From nobody Tue Jul 28 15:50:36 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5911B2A1E for ; Tue, 28 Jul 2015 15:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 BYOMIOZKkC2B for ; Tue, 28 Jul 2015 15:50:31 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id B727A1B32EA for ; Tue, 28 Jul 2015 15:50:31 -0700 (PDT) Received: (qmail 16145 invoked by uid 0); 28 Jul 2015 22:50:29 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy2.mail.unifiedlayer.com with SMTP; 28 Jul 2015 22:50:29 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id xyWN1q00Q1MNPNq01yWRWK; Tue, 28 Jul 2015 16:30:28 -0600 X-Authority-Analysis: v=2.1 cv=NJxGpSKg c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=N7-_X-PFAAAA:8 a=zQP7CpKOAAAA:8 a=VfgTrTGYAAAA:8 a=HLLxP2VMAAAA:8 a=izV7ms69AAAA:8 a=wY1d8m7nRgXn517DdjIA:9 a=-68UjDy56VCc7vb3:21 a=5QPA04bf2ZZRXB9E:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=DzjOOp_o1eYA:10 a=-h7pEDzCGw4A:10 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; bh=rCArHHr6QAF4EakqM8bucKvIGwwAjtmLzBW7+LdY4v8=; b=XQIWSP9+ZQMJOpDNKB2tZyTTYI6UASpkbedsUDIVdccplArvGC6i1Bw5XW5qB5S7Za6MnXtInoudW46qXZsjmbA7NdaUl6RyzA5vv3FkYmAQ0jIkg1roqGh0g3rR2+5h; Received: from [100.36.26.202] (port=61786 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZKDOA-0001re-O7; Tue, 28 Jul 2015 16:30:23 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Tue, 28 Jul 2015 18:30:18 -0400 From: Richard Shockey To: Richard Barnes , "PFAUTZ, PENN L" Message-ID: Thread-Topic: [stir] On OCSP, TNs, and Privacy References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 22:50:34 -0000 Richard .. Be reasonable here its not a perfect world and IETF protocols, especially its security protocols are not perfect. At some point the limited competency of the IETF will move into the realm of policy. In the US that means the usual suspects will have to weigh in. ATIS INC, the NANC,FCC. Its only a matter of time this ends up being a FCC Docket. This is not to say engineering concerns do not drive policy, far from it look at spectrum issues for instance. But its their [FCC CRTC OFCOM ART BeNetA FICORA) numbers and we (IETF) do not dictate policy. Only offer options. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 7/28/15, 4:06 PM, "stir on behalf of Richard Barnes" wrote: >http://www.afldreamers.com/wp-content/uploads/2014/01/why-not-have-both-30 >0x187.png > >You could have a database of certs+OCSP responses as an optimization. >IIRC, Identity-Info only has pointers to certs anyway. > >On Tue, Jul 28, 2015 at 3:13 PM, PFAUTZ, PENN L wrote: >> Forgive me but my reptile brain keeps whispering in my ear that this >>would be a lot easier if we simply had a numbering registry, whether >>distributed or centralized - like we need anyway for at least for number >>portability - that also contained the public keys. No tedious mucking >>about in cyberspace with certs, CRLs, or OCSP. >> >> >> >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning >>Schulzrinne >> Sent: Tuesday, July 28, 2015 10:24 AM >> To: Gorman, Pierce A [CTO] >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> In the US alone, we have about 4000 carriers. Managing the reputation >>of that many entities, reliably (i.e., without making false >>positive/negative mistakes) seems a whole lot more manual effort than >>storing bags of bits. Storage and automation is cheap, human judgement >>and dealing with mistakes is expensive. >> >> Obviously, nothing in the architecture prevents wildcard certificates. >> >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A >>[CTO] >> Sent: Tuesday, July 28, 2015 10:14 AM >> To: Richard Barnes >> Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen >> >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> I thought the discussion was on key/cert management. I'm asking if I >>understood the suggestion to minimize requirements. How is that off >>topic? >> >> Best regards, >> >> >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> -----Original Message----- >> From: Richard Barnes [mailto:rlb@ipv.sx] >> Sent: July 28, 2015 9:12 AM >> To: Gorman, Pierce A [CTO] >> Cc: Alex Bobotek ; Brian Rosen ; >>stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] >> wrote: >>> "Large scale certificate management is expensive, and TN-specific >>>certificates are unneeded for securing calls placed by parties who >>>choose to place calls through a single reputable telephone service >>>provider." >>> >>> Are you saying that for "on-net" calls, STIR methodology is >>>unnecessary? >> >> This seems a little off-topic for this list. >> >> --Richard >> >>> >>> Best regards, >>> >>> >>> Pierce Gorman >>> Core Network Planning >>> O: 913-439-4368 >>> pierce.gorman@sprint.com >>> >>> >>> -----Original Message----- >>> From: Alex Bobotek [mailto:alex@bobotek.net] >>> Sent: July 27, 2015 11:36 PM >>> To: Brian Rosen ; Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> What motivation would a carrier have to choose any model other than >>>carrier signing using one of a very limited set of carrier-owned keys? >>>Large scale certificate management is expensive, and TN-specific >>>certificates are unneeded for securing calls placed by parties who >>>choose to place calls through a single reputable telephone service >>>provider. Anyone can get many certificates, even a free ones >>>anonymously from some issuers. It is typically a combination of the >>>strength of the end-user authentication performed by the service >>>provider (or certificate issuer in a provider-agnostic model) and the >>>identity's history that are most useful in security. >>> >>> If we're trying to secure the current telephone system, DNS-like key >>>repositories a la DKIM or perhaps a small number (compared to the >>>number of TNs) of certificates are far more practical. >>> >>> Regards, >>> >>> Alex >>> >>>> -----Original Message----- >>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>>> Sent: Monday, July 27, 2015 7:40 PM >>>> To: Richard Barnes >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>> >>>> What this means in practice is that it=B9s TN per cert. >>>> >>>> I wouldn=B9t say that it=B9s impossible for a carrier to maintain dozens >>>> of copies of millions of private keys securely, but it=B9s hard. You >>>> need multiple copies because you have multiple elements that can >>>> initiate a call, and you don=B9t want to depend on a centralized >>>> resource to do something as basic as create a call. >>>> >>>> I think it=B9s hard enough that REQUIRING cert per TN is not acceptable. >>>> >>>> Folks with more intimate knowledge of carrier SIP infrastructure >>>> might have more insight than I do. It may be acceptable to have a >>>> centralized resource to manage millions of keys. >>>> >>>> Brian >>>> >>>> > On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>>> > >>>> > After the STIR meeting in Prague, Henning and I spent a few minutes >>>> > talking through options for revocation checking and certificate >>>> > scoping, and I think we have a better idea of what the optimal >>>> > solution looks like. Some notes are below, and some slides with >>>> > pictures attached. >>>> > >>>> > tl;dr: We should: >>>> > * Keep TNs in certificates and not bother with any OCSP extensions >>>> > * Require Identity-Info to include OCSP responses for all certs in >>>> > the chain >>>> > >>>> > >>>> > # Background: Revocation in the web PKI >>>> > >>>> > In an HTTPS transaction, the HTTPS server provides the client with >>>> > a certificate, and it can optionally include an OCSP response >>>>("staple" >>>> > it to the transaction). >>>> > >>>> > A certificate contains a validity interval, a key, and some >>>>names/TNs. >>>> > An OCSP responses contains a validity interval, a certificate ID >>>> > (i.e., a hash), and a status (good/revoked/unknown). In the web >>>> > PKI, certificates are required to be no more than 39 months long, >>>> > and OCSP responses no more than 10 days. >>>> > >>>> > Ideally, a client only considers a certificate valid if it is >>>> > accompanied by an OCSP response. In practice, this is not always >>>> > possible; because OCSP queries fail around 3% of the time, browsers >>>> > can't require OCSP. This operational fact will be important below, >>>> > but we will continue to have scoping cert lifetimes as an objective. >>>> > >>>> > In the web PKI, there are basically three revocation checking >>>>modalities: >>>> > >>>> > 1. Live OCSP checking [RFC6069] >>>> > 2. OCSP stapling / must_staple [RFC6066, >>>> > draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>>> > lifetime) >>>> > >>>> > (The last of these is relatively novel, and has not been deployed. >>>> > Neither has must-staple. But they're both pretty trivial, and >>>> > could be folded into a STIR architecture pretty easily.) >>>> > >>>> > Right now, about 90% of TLS transactions use live OCSP, and about >>>>10%. >>>> > CAs and browsers dearly want the world to move toward stapled OCSP >>>> > or short-lived certs, because these reduces latency and improve the >>>> > quality of revocation information. >>>> > >>>> > Revocation for CA certificates is currently done by having browsers >>>> > download a list from a centralized server, since there's no way to >>>> > staple more than one OCSP response. That solution works OK for the >>>> > web, but if I were designing something de novo, I would probably >>>> > use multi-stapling as well. >>>> > >>>> > >>>> > # Applying this experience to STIR >>>> > >>>> > Most of the below appear to be desired properties by the WG: >>>> > >>>> > * Verifier neeeds to know that a cert is valid for a specific >>>> > number >>>> > * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >>>> > issued longer) >>>> > * Caller privacy: Don't report what calls someone receives to a >>>> > central server >>>> > * Carrier privacy: Don't allow a third party to figure out all the >>>> > numbers a carrier holds >>>> > * Minimize the rate at which the CA has to sign things >>>> > * Tolerate outages at the CA >>>> > >>>> > I'm going to assume for now that we will not do live OCSP. It >>>> > violates the caller privacy requirement, and as discussed above, it >>>> > just sucks operationally. So STIR should require OCSP to be sent >>>> > in "stapled" form, which probably means sending it in Identity-Info. >>>> > And while we're at it, we should also do "multi-stapling" -- send >>>> > an OCSP response for CA certs as well. >>>> > >>>> > So if we consider a server with 50k TNs / blocks, that leaves us >>>> > with basically 3 options: >>>> > >>>> > 1. 50k short-lived certs (no OCSP) >>>> > 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 >>>> > long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >>>> > with TN info >>>> > >>>> > (As I didn't quite get to say in the meeting, regardless of the >>>> > approach, you have to have 50k of *something*.) Of these, it seems >>>> > like the preference order is 2 > 1 > 3. >>>> > >>>> > Option 3 is bad from several perspectives: >>>> > * Putting TN info in the OCSP response enables someone to trawl for >>>> > numbers unless you access-control the OCSP server, so you inherit a >>>> > requirement to do that. >>>> > * With the rate of churn in number assignments, you're probably >>>> > going to have to update the long-lived cert pretty frequently >>>>anyway. >>>> > * Putting TN-specific stuff in certs is better than putting it in >>>> > OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>>> > worse. >>>> > >>>> > Option 1 is mainly bad from the perspective of CA load and outages. >>>> > With Option 2, if the CA goes down, client can continue to use the >>>> > long-lived cert and just not bother doing OCSP (vs. tolerating an >>>> > expired cert). Slightly cleaner. Plus, there's a lot more >>>> > experience caching OCSP than new certs. OCSP signing can also be >>>> > delegated, so you can have the recurring operation done by a >>>>lower-risk key. >>>> > >>>> > Option 2 should be pretty easy to automate. You can probably >>>> > re-use tooling for OCSP stapling that has already been developed >>>> > for use with HTTPS. If you're a big box signing for a bunch of >>>> > numbers, you do need to select the right cert and OCSP response for >>>> > a given call, but that's a pretty simple lookup table. >>>> > _______________________________________________ >>>> > 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 >>> >>> ________________________________ >>> >>> This e-mail may contain Sprint proprietary information intended for >>>the sole use of the recipient(s). Any use by others is prohibited. If >>>you are not the intended recipient, please contact the sender and >>>delete all copies of the message. >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the >>sole use of the recipient(s). Any use by others is prohibited. If you >>are not the intended recipient, please contact the sender and delete all >>copies of the message. >> _______________________________________________ >> 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 >> _______________________________________________ >> 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 From nobody Tue Jul 28 15:57:34 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24641B330F for ; Tue, 28 Jul 2015 15:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 7eg5wzYlUPdC for ; Tue, 28 Jul 2015 15:57:30 -0700 (PDT) Received: from mail-vn0-f47.google.com (mail-vn0-f47.google.com [209.85.216.47]) (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 0F25D1B2A06 for ; Tue, 28 Jul 2015 15:57:30 -0700 (PDT) Received: by vnav141 with SMTP id v141so48579497vna.0 for ; Tue, 28 Jul 2015 15:57:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BihMwXrP2mMRrS1djfvSGXbnQqwn9urkZgEOfpZweQ4=; b=YH+RN8PyCYfarQ+xRC8Xrtng/s5K2UNyl6K+wXH7092ydxe6q/p9TFKCtewr2PYdKm vBE2zVnM5q30Uqi4g7nYmzM2mhX2OgcI0xnHHR8capgfa3iEJE8Z/R8TgcwTopmYZJNy I4E/by0pa5MQEuOClQlhScFPF1GQTIjGdzuWt/7Hhileo+UPlM4Ll5m36AZ3VeMqa0mu D4HHR+GdesbqsmSe0agXlnJ7EBE4vysYVSZ3knxZiXcO8hWa0ciPJQaP7sTq/x++QB3Q XTngZOb8xQe93SYdviEJ89wG0eFIRGEd7/GMCok5C8H3kVyRDMOsUCch/lDQpJlds8/o xYzw== X-Gm-Message-State: ALoCoQk44zbGm9vn/ljXiMmtQ3VnAuYyHeT7c/YPyeKGmjGiEg0PVDxo6QTUKNqbWZ2MdhzG8t5C MIME-Version: 1.0 X-Received: by 10.52.163.243 with SMTP id yl19mr46588504vdb.51.1438124249220; Tue, 28 Jul 2015 15:57:29 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Tue, 28 Jul 2015 15:57:29 -0700 (PDT) In-Reply-To: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> Date: Tue, 28 Jul 2015 18:57:29 -0400 Message-ID: From: Richard Barnes To: Richard Shockey Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 22:57:33 -0000 On Tue, Jul 28, 2015 at 6:30 PM, Richard Shockey wrote= : > > Richard .. Be reasonable here its not a perfect world and IETF protocols, You are correct that if we build a putative security solution based on public keys passed DNS, it will not be an IETF protocol. It will not become an RFC because it will not meet the IETF's security standards. And in any case, it's not that much harder to do the really secure thing. Even if you want a central registry, do it over HTTPS, and it'll be just as fast and 100% more secure. --Richard > especially its security protocols are not perfect. At some point the > limited competency of the IETF will move into the realm of policy. > > In the US that means the usual suspects will have to weigh in. ATIS INC, > the NANC,FCC. Its only a matter of time this ends up being a FCC Docket. > This is not to say engineering concerns do not drive policy, far from it > look at spectrum issues for instance. > > But its their [FCC CRTC OFCOM ART BeNetA FICORA) numbers and we (IETF) do > not dictate policy. Only offer options. > > > =E2=80=B9 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 > > > > > > On 7/28/15, 4:06 PM, "stir on behalf of Richard Barnes" > wrote: > >>http://www.afldreamers.com/wp-content/uploads/2014/01/why-not-have-both-3= 0 >>0x187.png >> >>You could have a database of certs+OCSP responses as an optimization. >>IIRC, Identity-Info only has pointers to certs anyway. >> >>On Tue, Jul 28, 2015 at 3:13 PM, PFAUTZ, PENN L wrote: >>> Forgive me but my reptile brain keeps whispering in my ear that this >>>would be a lot easier if we simply had a numbering registry, whether >>>distributed or centralized - like we need anyway for at least for number >>>portability - that also contained the public keys. No tedious mucking >>>about in cyberspace with certs, CRLs, or OCSP. >>> >>> >>> >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning >>>Schulzrinne >>> Sent: Tuesday, July 28, 2015 10:24 AM >>> To: Gorman, Pierce A [CTO] >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> In the US alone, we have about 4000 carriers. Managing the reputation >>>of that many entities, reliably (i.e., without making false >>>positive/negative mistakes) seems a whole lot more manual effort than >>>storing bags of bits. Storage and automation is cheap, human judgement >>>and dealing with mistakes is expensive. >>> >>> Obviously, nothing in the architecture prevents wildcard certificates. >>> >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A >>>[CTO] >>> Sent: Tuesday, July 28, 2015 10:14 AM >>> To: Richard Barnes >>> Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen >>> >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> I thought the discussion was on key/cert management. I'm asking if I >>>understood the suggestion to minimize requirements. How is that off >>>topic? >>> >>> Best regards, >>> >>> >>> Pierce Gorman >>> Core Network Planning >>> O: 913-439-4368 >>> pierce.gorman@sprint.com >>> >>> >>> -----Original Message----- >>> From: Richard Barnes [mailto:rlb@ipv.sx] >>> Sent: July 28, 2015 9:12 AM >>> To: Gorman, Pierce A [CTO] >>> Cc: Alex Bobotek ; Brian Rosen ; >>>stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] >>> wrote: >>>> "Large scale certificate management is expensive, and TN-specific >>>>certificates are unneeded for securing calls placed by parties who >>>>choose to place calls through a single reputable telephone service >>>>provider." >>>> >>>> Are you saying that for "on-net" calls, STIR methodology is >>>>unnecessary? >>> >>> This seems a little off-topic for this list. >>> >>> --Richard >>> >>>> >>>> Best regards, >>>> >>>> >>>> Pierce Gorman >>>> Core Network Planning >>>> O: 913-439-4368 >>>> pierce.gorman@sprint.com >>>> >>>> >>>> -----Original Message----- >>>> From: Alex Bobotek [mailto:alex@bobotek.net] >>>> Sent: July 27, 2015 11:36 PM >>>> To: Brian Rosen ; Richard Barnes >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>> >>>> What motivation would a carrier have to choose any model other than >>>>carrier signing using one of a very limited set of carrier-owned keys? >>>>Large scale certificate management is expensive, and TN-specific >>>>certificates are unneeded for securing calls placed by parties who >>>>choose to place calls through a single reputable telephone service >>>>provider. Anyone can get many certificates, even a free ones >>>>anonymously from some issuers. It is typically a combination of the >>>>strength of the end-user authentication performed by the service >>>>provider (or certificate issuer in a provider-agnostic model) and the >>>>identity's history that are most useful in security. >>>> >>>> If we're trying to secure the current telephone system, DNS-like key >>>>repositories a la DKIM or perhaps a small number (compared to the >>>>number of TNs) of certificates are far more practical. >>>> >>>> Regards, >>>> >>>> Alex >>>> >>>>> -----Original Message----- >>>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>>>> Sent: Monday, July 27, 2015 7:40 PM >>>>> To: Richard Barnes >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>>> >>>>> What this means in practice is that it=C2=B9s TN per cert. >>>>> >>>>> I wouldn=C2=B9t say that it=C2=B9s impossible for a carrier to mainta= in dozens >>>>> of copies of millions of private keys securely, but it=C2=B9s hard. = You >>>>> need multiple copies because you have multiple elements that can >>>>> initiate a call, and you don=C2=B9t want to depend on a centralized >>>>> resource to do something as basic as create a call. >>>>> >>>>> I think it=C2=B9s hard enough that REQUIRING cert per TN is not accep= table. >>>>> >>>>> Folks with more intimate knowledge of carrier SIP infrastructure >>>>> might have more insight than I do. It may be acceptable to have a >>>>> centralized resource to manage millions of keys. >>>>> >>>>> Brian >>>>> >>>>> > On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>>>> > >>>>> > After the STIR meeting in Prague, Henning and I spent a few minutes >>>>> > talking through options for revocation checking and certificate >>>>> > scoping, and I think we have a better idea of what the optimal >>>>> > solution looks like. Some notes are below, and some slides with >>>>> > pictures attached. >>>>> > >>>>> > tl;dr: We should: >>>>> > * Keep TNs in certificates and not bother with any OCSP extensions >>>>> > * Require Identity-Info to include OCSP responses for all certs in >>>>> > the chain >>>>> > >>>>> > >>>>> > # Background: Revocation in the web PKI >>>>> > >>>>> > In an HTTPS transaction, the HTTPS server provides the client with >>>>> > a certificate, and it can optionally include an OCSP response >>>>>("staple" >>>>> > it to the transaction). >>>>> > >>>>> > A certificate contains a validity interval, a key, and some >>>>>names/TNs. >>>>> > An OCSP responses contains a validity interval, a certificate ID >>>>> > (i.e., a hash), and a status (good/revoked/unknown). In the web >>>>> > PKI, certificates are required to be no more than 39 months long, >>>>> > and OCSP responses no more than 10 days. >>>>> > >>>>> > Ideally, a client only considers a certificate valid if it is >>>>> > accompanied by an OCSP response. In practice, this is not always >>>>> > possible; because OCSP queries fail around 3% of the time, browsers >>>>> > can't require OCSP. This operational fact will be important below, >>>>> > but we will continue to have scoping cert lifetimes as an objective= . >>>>> > >>>>> > In the web PKI, there are basically three revocation checking >>>>>modalities: >>>>> > >>>>> > 1. Live OCSP checking [RFC6069] >>>>> > 2. OCSP stapling / must_staple [RFC6066, >>>>> > draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>>>> > lifetime) >>>>> > >>>>> > (The last of these is relatively novel, and has not been deployed. >>>>> > Neither has must-staple. But they're both pretty trivial, and >>>>> > could be folded into a STIR architecture pretty easily.) >>>>> > >>>>> > Right now, about 90% of TLS transactions use live OCSP, and about >>>>>10%. >>>>> > CAs and browsers dearly want the world to move toward stapled OCSP >>>>> > or short-lived certs, because these reduces latency and improve the >>>>> > quality of revocation information. >>>>> > >>>>> > Revocation for CA certificates is currently done by having browsers >>>>> > download a list from a centralized server, since there's no way to >>>>> > staple more than one OCSP response. That solution works OK for the >>>>> > web, but if I were designing something de novo, I would probably >>>>> > use multi-stapling as well. >>>>> > >>>>> > >>>>> > # Applying this experience to STIR >>>>> > >>>>> > Most of the below appear to be desired properties by the WG: >>>>> > >>>>> > * Verifier neeeds to know that a cert is valid for a specific >>>>> > number >>>>> > * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >>>>> > issued longer) >>>>> > * Caller privacy: Don't report what calls someone receives to a >>>>> > central server >>>>> > * Carrier privacy: Don't allow a third party to figure out all the >>>>> > numbers a carrier holds >>>>> > * Minimize the rate at which the CA has to sign things >>>>> > * Tolerate outages at the CA >>>>> > >>>>> > I'm going to assume for now that we will not do live OCSP. It >>>>> > violates the caller privacy requirement, and as discussed above, it >>>>> > just sucks operationally. So STIR should require OCSP to be sent >>>>> > in "stapled" form, which probably means sending it in Identity-Info= . >>>>> > And while we're at it, we should also do "multi-stapling" -- send >>>>> > an OCSP response for CA certs as well. >>>>> > >>>>> > So if we consider a server with 50k TNs / blocks, that leaves us >>>>> > with basically 3 options: >>>>> > >>>>> > 1. 50k short-lived certs (no OCSP) >>>>> > 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 >>>>> > long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >>>>> > with TN info >>>>> > >>>>> > (As I didn't quite get to say in the meeting, regardless of the >>>>> > approach, you have to have 50k of *something*.) Of these, it seems >>>>> > like the preference order is 2 > 1 > 3. >>>>> > >>>>> > Option 3 is bad from several perspectives: >>>>> > * Putting TN info in the OCSP response enables someone to trawl for >>>>> > numbers unless you access-control the OCSP server, so you inherit a >>>>> > requirement to do that. >>>>> > * With the rate of churn in number assignments, you're probably >>>>> > going to have to update the long-lived cert pretty frequently >>>>>anyway. >>>>> > * Putting TN-specific stuff in certs is better than putting it in >>>>> > OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>>>> > worse. >>>>> > >>>>> > Option 1 is mainly bad from the perspective of CA load and outages. >>>>> > With Option 2, if the CA goes down, client can continue to use the >>>>> > long-lived cert and just not bother doing OCSP (vs. tolerating an >>>>> > expired cert). Slightly cleaner. Plus, there's a lot more >>>>> > experience caching OCSP than new certs. OCSP signing can also be >>>>> > delegated, so you can have the recurring operation done by a >>>>>lower-risk key. >>>>> > >>>>> > Option 2 should be pretty easy to automate. You can probably >>>>> > re-use tooling for OCSP stapling that has already been developed >>>>> > for use with HTTPS. If you're a big box signing for a bunch of >>>>> > numbers, you do need to select the right cert and OCSP response for >>>>> > a given call, but that's a pretty simple lookup table. >>>>> > _______________________________________________ >>>>> > 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 >>>> >>>> ________________________________ >>>> >>>> This e-mail may contain Sprint proprietary information intended for >>>>the sole use of the recipient(s). Any use by others is prohibited. If >>>>you are not the intended recipient, please contact the sender and >>>>delete all copies of the message. >>> >>> ________________________________ >>> >>> This e-mail may contain Sprint proprietary information intended for the >>>sole use of the recipient(s). Any use by others is prohibited. If you >>>are not the intended recipient, please contact the sender and delete all >>>copies of the message. >>> _______________________________________________ >>> 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 >>> _______________________________________________ >>> 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 > > From nobody Tue Jul 28 16:38:50 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEA21B3489 for ; Tue, 28 Jul 2015 16:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 J1DCnrPRkF-M for ; Tue, 28 Jul 2015 16:38:45 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5711B3485 for ; Tue, 28 Jul 2015 16:38:44 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 48218b55.2ac89403f940.3082955.00-2413.8718396.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 28 Jul 2015 23:38:44 +0000 (UTC) X-MXL-Hash: 55b81284416fc94a-b4dcc5e0f5157312828e2b41466a46a24ef376b3 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 28218b55.0.3082938.00-2172.8718330.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 28 Jul 2015 23:38:43 +0000 (UTC) X-MXL-Hash: 55b8128321786e27-98a0bcf660e71b60f5aaf865a6c6fb3a0fd834f2 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 t6SNcf7D015210; Tue, 28 Jul 2015 19:38:41 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6SNcS4a014987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jul 2015 19:38:30 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 28 Jul 2015 23:38:19 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.237]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0224.002; Tue, 28 Jul 2015 19:38:19 -0400 From: "PFAUTZ, PENN L" To: Richard Barnes Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLmIfuNwwir/xEOjfOFArSLlWp3wbvsAgAAgjQCAAJs4gIAAjm4AgAAGDAD//8xJ3Q== Date: Tue, 28 Jul 2015 23:38:18 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <4B1956260CD29F4A9622F00322FE0531011D3D1D5046@BOBO1A.bobotek.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=eoxoOPVX c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=zOBTXjUuO1YA:10 a=VfgTrTGYAAAA:8 a=izV7m] X-AnalysisOut: [s69AAAA:8 a=HLLxP2VMAAAA:8 a=48vgC7mUAAAA:8 a=PV6r1O3hWco0] X-AnalysisOut: [dFdMcpgA:9 a=pILNOxqGKmIA:10 a=DzjOOp_o1eYA:10 a=bqJ9KWJar] X-AnalysisOut: [1g7GkQv:21 a=fy0SYNeWJFWjD0sb:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072801)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "stir@ietf.org" , Alex Bobotek , "Gorman, Pierce A \[CTO\]" , Brian Rosen Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 23:38:48 -0000 to be clear much as I've labored on ENUM a registry doesn't have to be DNS = based. The the LNP DBOR already has to be robust as do the SP and service bureau p= latforms it loads so I've added nothing but a new data field and the provis= ioning that goes with it. The authority is already built in, synched with portability, and tied to "p= arties that can be punished."=20 regards, Penn Sent from my iPad > On Jul 28, 2015, at 6:43 PM, Richard Barnes wrote: >=20 >> On Tue, Jul 28, 2015 at 6:21 PM, Alex Bobotek wrote: >> Pierce, >>=20 >> I appreciate your question, and will try to be less abstract. Punch lin= e is near the end. >>=20 >> I am saying that _certificates_ are not needed for auth. A collection o= f service provider public keys stored in some repository (e.g., in ENUM or = DNS) is an alternative. As our transport networks already use registries t= hat can server as repositories, and they have a degree of security that all= ows a serving carrier to specify a trusted parameter, it seems to be the mo= st practical solution. This is what was done in DKIM, and it clearly works= . >>=20 >> And as others have also suggested, this is simpler than creating a certi= ficate distribution and management infrastructure. >>=20 >> Punch line: >> Yes, I am most definitely expressing the opinion that IETF should work o= n standards for a registry-based public key repository and registry-based v= alidation methods to be used for STIR validation. I hope that there are ot= her like-minded people to join in producing an Internet Draft on this. >=20 > I'm having a little trouble understanding how this solution is better > than certificates at all. In either case: > - the authority (CA or registry) has to maintain up-to-date info as to > which numbers go with which public keys > - relying parties have to know who to trust (CA or registry public key) >=20 > The only difference is that if the authority issues certificates, then > you don't have the crushing uptime requirements that you do with a > registry. >=20 > Also ENUM and DNS are clearly not acceptable solutions, unless they're > done with DNSSEC. >=20 > This does not seem like a win to me. >=20 > --Richard >=20 >>=20 >> Regards, >>=20 >> Alex >>=20 >>> -----Original Message----- >>> From: Gorman, Pierce A [CTO] [mailto:Pierce.Gorman@sprint.com] >>> Sent: Tuesday, July 28, 2015 6:52 AM >>> To: Alex Bobotek ; Brian Rosen ; >>> Richard Barnes >>> Cc: stir@ietf.org >>> Subject: RE: [stir] On OCSP, TNs, and Privacy >>>=20 >>> "Large scale certificate management is expensive, and TN-specific certi= ficates >>> are unneeded for securing calls placed by parties who choose to place c= alls >>> through a single reputable telephone service provider." >>>=20 >>> Are you saying that for "on-net" calls, STIR methodology is unnecessary= ? >>>=20 >>> Best regards, >>>=20 >>>=20 >>> Pierce Gorman >>> Core Network Planning >>> O: 913-439-4368 >>> pierce.gorman@sprint.com >>>=20 >>>=20 >>> -----Original Message----- >>> From: Alex Bobotek [mailto:alex@bobotek.net] >>> Sent: July 27, 2015 11:36 PM >>> To: Brian Rosen ; Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>=20 >>> What motivation would a carrier have to choose any model other than car= rier >>> signing using one of a very limited set of carrier-owned keys? Large s= cale >>> certificate management is expensive, and TN-specific certificates are >>> unneeded for securing calls placed by parties who choose to place calls >>> through a single reputable telephone service provider. Anyone can get = many >>> certificates, even a free ones anonymously from some issuers. It is ty= pically a >>> combination of the strength of the end-user authentication performed by >>> the service provider (or certificate issuer in a provider-agnostic mode= l) and >>> the identity's history that are most useful in security. >>>=20 >>> If we're trying to secure the current telephone system, DNS-like key >>> repositories a la DKIM or perhaps a small number (compared to the numbe= r >>> of TNs) of certificates are far more practical. >>>=20 >>> Regards, >>>=20 >>> Alex >>>=20 >>>> -----Original Message----- >>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>>> Sent: Monday, July 27, 2015 7:40 PM >>>> To: Richard Barnes >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>>=20 >>>> What this means in practice is that it=92s TN per cert. >>>>=20 >>>> I wouldn=92t say that it=92s impossible for a carrier to maintain doze= ns >>>> of copies of millions of private keys securely, but it=92s hard. You >>>> need multiple copies because you have multiple elements that can >>>> initiate a call, and you don=92t want to depend on a centralized >>>> resource to do something as basic as create a call. >>>>=20 >>>> I think it=92s hard enough that REQUIRING cert per TN is not acceptabl= e. >>>>=20 >>>> Folks with more intimate knowledge of carrier SIP infrastructure might >>>> have more insight than I do. It may be acceptable to have a >>>> centralized resource to manage millions of keys. >>>>=20 >>>> Brian >>>>=20 >>>>> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>>>>=20 >>>>> After the STIR meeting in Prague, Henning and I spent a few minutes >>>>> talking through options for revocation checking and certificate >>>>> scoping, and I think we have a better idea of what the optimal >>>>> solution looks like. Some notes are below, and some slides with >>>>> pictures attached. >>>>>=20 >>>>> tl;dr: We should: >>>>> * Keep TNs in certificates and not bother with any OCSP extensions >>>>> * Require Identity-Info to include OCSP responses for all certs in >>>>> the chain >>>>>=20 >>>>>=20 >>>>> # Background: Revocation in the web PKI >>>>>=20 >>>>> In an HTTPS transaction, the HTTPS server provides the client with a >>>>> certificate, and it can optionally include an OCSP response ("staple" >>>>> it to the transaction). >>>>>=20 >>>>> A certificate contains a validity interval, a key, and some names/TNs= . >>>>> An OCSP responses contains a validity interval, a certificate ID >>>>> (i.e., a hash), and a status (good/revoked/unknown). In the web >>>>> PKI, certificates are required to be no more than 39 months long, >>>>> and OCSP responses no more than 10 days. >>>>>=20 >>>>> Ideally, a client only considers a certificate valid if it is >>>>> accompanied by an OCSP response. In practice, this is not always >>>>> possible; because OCSP queries fail around 3% of the time, browsers >>>>> can't require OCSP. This operational fact will be important below, >>>>> but we will continue to have scoping cert lifetimes as an objective. >>>>>=20 >>>>> In the web PKI, there are basically three revocation checking modalit= ies: >>>>>=20 >>>>> 1. Live OCSP checking [RFC6069] >>>>> 2. OCSP stapling / must_staple [RFC6066, >>>>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>>>> lifetime) >>>>>=20 >>>>> (The last of these is relatively novel, and has not been deployed. >>>>> Neither has must-staple. But they're both pretty trivial, and could >>>>> be folded into a STIR architecture pretty easily.) >>>>>=20 >>>>> Right now, about 90% of TLS transactions use live OCSP, and about 10%= . >>>>> CAs and browsers dearly want the world to move toward stapled OCSP >>>>> or short-lived certs, because these reduces latency and improve the >>>>> quality of revocation information. >>>>>=20 >>>>> Revocation for CA certificates is currently done by having browsers >>>>> download a list from a centralized server, since there's no way to >>>>> staple more than one OCSP response. That solution works OK for the >>>>> web, but if I were designing something de novo, I would probably use >>>>> multi-stapling as well. >>>>>=20 >>>>>=20 >>>>> # Applying this experience to STIR >>>>>=20 >>>>> Most of the below appear to be desired properties by the WG: >>>>>=20 >>>>> * Verifier neeeds to know that a cert is valid for a specific number >>>>> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >>>>> issued longer) >>>>> * Caller privacy: Don't report what calls someone receives to a >>>>> central server >>>>> * Carrier privacy: Don't allow a third party to figure out all the >>>>> numbers a carrier holds >>>>> * Minimize the rate at which the CA has to sign things >>>>> * Tolerate outages at the CA >>>>>=20 >>>>> I'm going to assume for now that we will not do live OCSP. It >>>>> violates the caller privacy requirement, and as discussed above, it >>>>> just sucks operationally. So STIR should require OCSP to be sent in >>>>> "stapled" form, which probably means sending it in Identity-Info. >>>>> And while we're at it, we should also do "multi-stapling" -- send an >>>>> OCSP response for CA certs as well. >>>>>=20 >>>>> So if we consider a server with 50k TNs / blocks, that leaves us >>>>> with basically 3 options: >>>>>=20 >>>>> 1. 50k short-lived certs (no OCSP) >>>>> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 long-lived >>>>> cert not scoped to TN (or a few loosely scoped) + OCSP with TN info >>>>>=20 >>>>> (As I didn't quite get to say in the meeting, regardless of the >>>>> approach, you have to have 50k of *something*.) Of these, it seems >>>>> like the preference order is 2 > 1 > 3. >>>>>=20 >>>>> Option 3 is bad from several perspectives: >>>>> * Putting TN info in the OCSP response enables someone to trawl for >>>>> numbers unless you access-control the OCSP server, so you inherit a >>>>> requirement to do that. >>>>> * With the rate of churn in number assignments, you're probably >>>>> going to have to update the long-lived cert pretty frequently anyway. >>>>> * Putting TN-specific stuff in certs is better than putting it in >>>>> OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>>>> worse. >>>>>=20 >>>>> Option 1 is mainly bad from the perspective of CA load and outages. >>>>> With Option 2, if the CA goes down, client can continue to use the >>>>> long-lived cert and just not bother doing OCSP (vs. tolerating an >>>>> expired cert). Slightly cleaner. Plus, there's a lot more >>>>> experience caching OCSP than new certs. OCSP signing can also be >>>>> delegated, so you can have the recurring operation done by a lower-ri= sk >>> key. >>>>>=20 >>>>> Option 2 should be pretty easy to automate. You can probably re-use >>>>> tooling for OCSP stapling that has already been developed for use >>>>> with HTTPS. If you're a big box signing for a bunch of numbers, you >>>>> do need to select the right cert and OCSP response for a given call, >>>>> but that's a pretty simple lookup table. >>> _______________________________________________ >>>>> 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 >>> ________________________________ >>>=20 >>> This e-mail may contain Sprint proprietary information intended for the= sole >>> use of the recipient(s). Any use by others is prohibited. If you are no= t the >>> intended recipient, please contact the sender and delete all copies of = the >>> message. >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 28 18:22:57 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0661A1A9D for ; Tue, 28 Jul 2015 18:22:56 -0700 (PDT) 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] autolearn=ham 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 ZIXVdatBsfkP for ; Tue, 28 Jul 2015 18:22:53 -0700 (PDT) Received: from mail-qg0-f65.google.com (mail-qg0-f65.google.com [209.85.192.65]) (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 896441B32E2 for ; Tue, 28 Jul 2015 18:22:52 -0700 (PDT) Received: by qgeu79 with SMTP id u79so8423605qge.0 for ; Tue, 28 Jul 2015 18:22:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=l2vCyjy6CoaPfnushRzay4UUxZ9l9aJ+7tbkpGaa2IY=; b=fqLF2CDTj8jBLdFhDABDxbx7KYKpDIRrOUaZjdk15nwz/03z4dzlT3TdgR1gHHk9eL X1UQjlGBsGH25b6DLMcnWE4Dj3MGH/aj0j8exlOqA4lmEU3vT7NCXNS7tSGK2LxkLtZu kENITdvwnk4knED9hS/lZm+cblOd8UJ+DhVZWDGDvhSSjk7TDTZ+ObhjEPuHLGpyEaQ2 9gyC9YutlwrJq/i33E24rkYPY86hqeHIOb8zYRH4QPg7cfqpb/eKrHpqy3VmvNneECrB b+K5KloeuECaFFqpzqawHcVQiSLSOD6zwN+V35L5TfyaC8GxQxKAtOo2BGafLzv8VYJZ YJEw== X-Gm-Message-State: ALoCoQkUdhLb1nP86ANyBESuxGJrRE9OGhhHMQuiKuUuZTNCoKexCWCVjwUNz3eb23NTmkTDPRAW X-Received: by 10.140.105.183 with SMTP id c52mr54270310qgf.7.1438132971671; Tue, 28 Jul 2015 18:22:51 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:992:3ba9:dca8:7b2d? ([2601:41:c101:9364:992:3ba9:dca8:7b2d]) by smtp.gmail.com with ESMTPSA id g80sm2699748qkh.18.2015.07.28.18.22.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jul 2015 18:22:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Chris Wendt In-Reply-To: Date: Tue, 28 Jul 2015 21:22:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C8D48CD-F4A8-4160-A5A7-594DF61A9B60@chriswendt.net> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 01:22:56 -0000 If the registry is distributed, and the certificate dip is local to the = provider, the numbering authority isn=E2=80=99t in the middle of each = call, one of the points we are advocating in general, in terms of making = this scalable and =E2=80=9Cdeployable=E2=80=9D. > On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne = wrote: >=20 > That was certainly one of the models that have been discussed in the = past. Particularly for small carriers, this would likely reduce the = operational impact to a configuration option in the SBC. >=20 > The disadvantage of this model is caller privacy: If the cert is = stored at a numbering authority, it would be easy for that authority to = know which carrier is receiving calls from whom. (It's not the complete = meta data since it's lacking the callee information.) >=20 > However, unless the TN-to-LRN (in the US) mapping is cached, this = "leak" already exists today. >=20 > -----Original Message----- > From: PFAUTZ, PENN L [mailto:pp3129@att.com]=20 > Sent: Tuesday, July 28, 2015 3:14 PM > To: Henning Schulzrinne ; Gorman, Pierce = A [CTO] > Cc: stir@ietf.org > Subject: RE: [stir] On OCSP, TNs, and Privacy >=20 > Forgive me but my reptile brain keeps whispering in my ear that this = would be a lot easier if we simply had a numbering registry, whether = distributed or centralized - like we need anyway for at least for number = portability - that also contained the public keys. No tedious mucking = about in cyberspace with certs, CRLs, or OCSP. >=20 >=20 >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne > Sent: Tuesday, July 28, 2015 10:24 AM > To: Gorman, Pierce A [CTO] > Cc: stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 > In the US alone, we have about 4000 carriers. Managing the reputation = of that many entities, reliably (i.e., without making false = positive/negative mistakes) seems a whole lot more manual effort than = storing bags of bits. Storage and automation is cheap, human judgement = and dealing with mistakes is expensive. >=20 > Obviously, nothing in the architecture prevents wildcard certificates. >=20 > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce = A [CTO] > Sent: Tuesday, July 28, 2015 10:14 AM > To: Richard Barnes > Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen = > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 > I thought the discussion was on key/cert management. I'm asking if I = understood the suggestion to minimize requirements. How is that off = topic? >=20 > Best regards, >=20 >=20 > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com >=20 >=20 > -----Original Message----- > From: Richard Barnes [mailto:rlb@ipv.sx] > Sent: July 28, 2015 9:12 AM > To: Gorman, Pierce A [CTO] > Cc: Alex Bobotek ; Brian Rosen ; = stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 > On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] = wrote: >> "Large scale certificate management is expensive, and TN-specific = certificates are unneeded for securing calls placed by parties who = choose to place calls through a single reputable telephone service = provider." >>=20 >> Are you saying that for "on-net" calls, STIR methodology is = unnecessary? >=20 > This seems a little off-topic for this list. >=20 > --Richard >=20 >>=20 >> Best regards, >>=20 >>=20 >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >>=20 >>=20 >> -----Original Message----- >> From: Alex Bobotek [mailto:alex@bobotek.net] >> Sent: July 27, 2015 11:36 PM >> To: Brian Rosen ; Richard Barnes >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >>=20 >> What motivation would a carrier have to choose any model other than = carrier signing using one of a very limited set of carrier-owned keys? = Large scale certificate management is expensive, and TN-specific = certificates are unneeded for securing calls placed by parties who = choose to place calls through a single reputable telephone service = provider. Anyone can get many certificates, even a free ones = anonymously from some issuers. It is typically a combination of the = strength of the end-user authentication performed by the service = provider (or certificate issuer in a provider-agnostic model) and the = identity's history that are most useful in security. >>=20 >> If we're trying to secure the current telephone system, DNS-like key = repositories a la DKIM or perhaps a small number (compared to the number = of TNs) of certificates are far more practical. >>=20 >> Regards, >>=20 >> Alex >>=20 >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>> Sent: Monday, July 27, 2015 7:40 PM >>> To: Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>=20 >>> What this means in practice is that it=E2=80=99s TN per cert. >>>=20 >>> I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier to = maintain dozens=20 >>> of copies of millions of private keys securely, but it=E2=80=99s = hard. You=20 >>> need multiple copies because you have multiple elements that can=20 >>> initiate a call, and you don=E2=80=99t want to depend on a = centralized=20 >>> resource to do something as basic as create a call. >>>=20 >>> I think it=E2=80=99s hard enough that REQUIRING cert per TN is not = acceptable. >>>=20 >>> Folks with more intimate knowledge of carrier SIP infrastructure=20 >>> might have more insight than I do. It may be acceptable to have a=20= >>> centralized resource to manage millions of keys. >>>=20 >>> Brian >>>=20 >>>> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>>>=20 >>>> After the STIR meeting in Prague, Henning and I spent a few minutes=20= >>>> talking through options for revocation checking and certificate=20 >>>> scoping, and I think we have a better idea of what the optimal=20 >>>> solution looks like. Some notes are below, and some slides with=20 >>>> pictures attached. >>>>=20 >>>> tl;dr: We should: >>>> * Keep TNs in certificates and not bother with any OCSP extensions >>>> * Require Identity-Info to include OCSP responses for all certs in=20= >>>> the chain >>>>=20 >>>>=20 >>>> # Background: Revocation in the web PKI >>>>=20 >>>> In an HTTPS transaction, the HTTPS server provides the client with=20= >>>> a certificate, and it can optionally include an OCSP response = ("staple" >>>> it to the transaction). >>>>=20 >>>> A certificate contains a validity interval, a key, and some = names/TNs. >>>> An OCSP responses contains a validity interval, a certificate ID=20 >>>> (i.e., a hash), and a status (good/revoked/unknown). In the web=20 >>>> PKI, certificates are required to be no more than 39 months long,=20= >>>> and OCSP responses no more than 10 days. >>>>=20 >>>> Ideally, a client only considers a certificate valid if it is=20 >>>> accompanied by an OCSP response. In practice, this is not always=20= >>>> possible; because OCSP queries fail around 3% of the time, browsers=20= >>>> can't require OCSP. This operational fact will be important below,=20= >>>> but we will continue to have scoping cert lifetimes as an = objective. >>>>=20 >>>> In the web PKI, there are basically three revocation checking = modalities: >>>>=20 >>>> 1. Live OCSP checking [RFC6069] >>>> 2. OCSP stapling / must_staple [RFC6066,=20 >>>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>>> lifetime) >>>>=20 >>>> (The last of these is relatively novel, and has not been deployed. >>>> Neither has must-staple. But they're both pretty trivial, and=20 >>>> could be folded into a STIR architecture pretty easily.) >>>>=20 >>>> Right now, about 90% of TLS transactions use live OCSP, and about = 10%. >>>> CAs and browsers dearly want the world to move toward stapled OCSP=20= >>>> or short-lived certs, because these reduces latency and improve the=20= >>>> quality of revocation information. >>>>=20 >>>> Revocation for CA certificates is currently done by having browsers=20= >>>> download a list from a centralized server, since there's no way to=20= >>>> staple more than one OCSP response. That solution works OK for the=20= >>>> web, but if I were designing something de novo, I would probably=20 >>>> use multi-stapling as well. >>>>=20 >>>>=20 >>>> # Applying this experience to STIR >>>>=20 >>>> Most of the below appear to be desired properties by the WG: >>>>=20 >>>> * Verifier neeeds to know that a cert is valid for a specific=20 >>>> number >>>> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if=20= >>>> issued longer) >>>> * Caller privacy: Don't report what calls someone receives to a=20 >>>> central server >>>> * Carrier privacy: Don't allow a third party to figure out all the=20= >>>> numbers a carrier holds >>>> * Minimize the rate at which the CA has to sign things >>>> * Tolerate outages at the CA >>>>=20 >>>> I'm going to assume for now that we will not do live OCSP. It=20 >>>> violates the caller privacy requirement, and as discussed above, it=20= >>>> just sucks operationally. So STIR should require OCSP to be sent=20= >>>> in "stapled" form, which probably means sending it in = Identity-Info. >>>> And while we're at it, we should also do "multi-stapling" -- send=20= >>>> an OCSP response for CA certs as well. >>>>=20 >>>> So if we consider a server with 50k TNs / blocks, that leaves us=20 >>>> with basically 3 options: >>>>=20 >>>> 1. 50k short-lived certs (no OCSP) >>>> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1=20 >>>> long-lived cert not scoped to TN (or a few loosely scoped) + OCSP=20= >>>> with TN info >>>>=20 >>>> (As I didn't quite get to say in the meeting, regardless of the=20 >>>> approach, you have to have 50k of *something*.) Of these, it seems=20= >>>> like the preference order is 2 > 1 > 3. >>>>=20 >>>> Option 3 is bad from several perspectives: >>>> * Putting TN info in the OCSP response enables someone to trawl for=20= >>>> numbers unless you access-control the OCSP server, so you inherit a=20= >>>> requirement to do that. >>>> * With the rate of churn in number assignments, you're probably=20 >>>> going to have to update the long-lived cert pretty frequently = anyway. >>>> * Putting TN-specific stuff in certs is better than putting it in=20= >>>> OCSP. As bad as X.509 libraries can be, OCSP libraries are much=20 >>>> worse. >>>>=20 >>>> Option 1 is mainly bad from the perspective of CA load and outages. >>>> With Option 2, if the CA goes down, client can continue to use the=20= >>>> long-lived cert and just not bother doing OCSP (vs. tolerating an=20= >>>> expired cert). Slightly cleaner. Plus, there's a lot more=20 >>>> experience caching OCSP than new certs. OCSP signing can also be=20= >>>> delegated, so you can have the recurring operation done by a = lower-risk key. >>>>=20 >>>> Option 2 should be pretty easy to automate. You can probably=20 >>>> re-use tooling for OCSP stapling that has already been developed=20 >>>> for use with HTTPS. If you're a big box signing for a bunch of=20 >>>> numbers, you do need to select the right cert and OCSP response for=20= >>>> a given call, but that's a pretty simple lookup table. >>>> _______________________________________________ >>>> 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 >> ________________________________ >>=20 >> This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. >=20 > ________________________________ >=20 > This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. > _______________________________________________ > 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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 28 18:30:15 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0674B1A1A6B for ; Tue, 28 Jul 2015 18:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 50NsFGEJQoLQ for ; Tue, 28 Jul 2015 18:30:09 -0700 (PDT) Received: from mail-vn0-f46.google.com (mail-vn0-f46.google.com [209.85.216.46]) (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 0DEFC1A037C for ; Tue, 28 Jul 2015 18:30:08 -0700 (PDT) Received: by vnk197 with SMTP id 197so49436934vnk.3 for ; Tue, 28 Jul 2015 18:30:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JpGJ3/N/tnFXmXtl6bC1w77F/6MLVFiqQOG6o2SfLUg=; b=FaWgDVzkZ4cjSzicrv3loD9E/LXbjVxjCU2JUBVlNi76PVEk1dwbzNhOC9nVQowJKd rqKGjkyTgjJ4J4+er1LKj6Rao5wvB87twIFjoc77xTU3OLj3M5TJy7DWEXUUXtwYDE4X imS2k/96fBKLm3h0mCk5MB6LCV29bKrKOvbKeo5KCSQjFXXCTYbk0BY+i5i7aHSIf212 80kTVvY7ynFFzTaPyhxuhsJhd7OFBqXkwnWNc51a/gi/fIUiLTGc034bTAh7B41JKCvz IdMMqAIOJ3duc4MJrWF6QnxOqjwL8H696lKgFDn+Bl+TE10V82WAx+1MqX93z/pdB2F6 E33w== X-Gm-Message-State: ALoCoQlRrsx+7+1tw8xu7rMyrAQtQxcbGQUy4B9MII1V34+M1s1IliOWA3N5zkH6arSHESxMTWQb MIME-Version: 1.0 X-Received: by 10.52.69.241 with SMTP id h17mr49283652vdu.68.1438133408030; Tue, 28 Jul 2015 18:30:08 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Tue, 28 Jul 2015 18:30:07 -0700 (PDT) In-Reply-To: <8C8D48CD-F4A8-4160-A5A7-594DF61A9B60@chriswendt.net> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <8C8D48CD-F4A8-4160-A5A7-594DF61A9B60@chriswendt.net> Date: Tue, 28 Jul 2015 21:30:07 -0400 Message-ID: From: Richard Barnes To: Chris Wendt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 01:30:14 -0000 On Tue, Jul 28, 2015 at 9:22 PM, Chris Wendt wr= ote: > If the registry is distributed, and the certificate dip is local to the p= rovider, the numbering authority isn=E2=80=99t in the middle of each call, = one of the points we are advocating in general, in terms of making this sca= lable and =E2=80=9Cdeployable=E2=80=9D. Do you happen to have a good standard technology on hand for synchronizing a database across a potentially unbounded set of signers/verifiers? I don't think we can assume that that set of actors is limited to the set of "providers", for any definition of that term. For so it is written in RFC 7340: """ Generation: Intermediaries as well as end systems must be able to generate the source identity information. Validation: Intermediaries as well as end systems must be able to validate the source identity information. """ If you're going to meet that requirement, I think your distributed registry ends up looking far more complex than just passing around certificates. Of course, if you're just talking about a signer looking up what cert it should use, then we agree; that's just what I meant when I said that managing multiple certs is just a hash table lookup. --Richard > > >> On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne wrote: >> >> That was certainly one of the models that have been discussed in the pas= t. Particularly for small carriers, this would likely reduce the operationa= l impact to a configuration option in the SBC. >> >> The disadvantage of this model is caller privacy: If the cert is stored = at a numbering authority, it would be easy for that authority to know which= carrier is receiving calls from whom. (It's not the complete meta data sin= ce it's lacking the callee information.) >> >> However, unless the TN-to-LRN (in the US) mapping is cached, this "leak"= already exists today. >> >> -----Original Message----- >> From: PFAUTZ, PENN L [mailto:pp3129@att.com] >> Sent: Tuesday, July 28, 2015 3:14 PM >> To: Henning Schulzrinne ; Gorman, Pierce A = [CTO] >> Cc: stir@ietf.org >> Subject: RE: [stir] On OCSP, TNs, and Privacy >> >> Forgive me but my reptile brain keeps whispering in my ear that this wou= ld be a lot easier if we simply had a numbering registry, whether distribut= ed or centralized - like we need anyway for at least for number portability= - that also contained the public keys. No tedious mucking about in cybersp= ace with certs, CRLs, or OCSP. >> >> >> >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrin= ne >> Sent: Tuesday, July 28, 2015 10:24 AM >> To: Gorman, Pierce A [CTO] >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> In the US alone, we have about 4000 carriers. Managing the reputation of= that many entities, reliably (i.e., without making false positive/negative= mistakes) seems a whole lot more manual effort than storing bags of bits. = Storage and automation is cheap, human judgement and dealing with mistakes = is expensive. >> >> Obviously, nothing in the architecture prevents wildcard certificates. >> >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A = [CTO] >> Sent: Tuesday, July 28, 2015 10:14 AM >> To: Richard Barnes >> Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> I thought the discussion was on key/cert management. I'm asking if I un= derstood the suggestion to minimize requirements. How is that off topic? >> >> Best regards, >> >> >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >> >> >> -----Original Message----- >> From: Richard Barnes [mailto:rlb@ipv.sx] >> Sent: July 28, 2015 9:12 AM >> To: Gorman, Pierce A [CTO] >> Cc: Alex Bobotek ; Brian Rosen ; st= ir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] wrote: >>> "Large scale certificate management is expensive, and TN-specific certi= ficates are unneeded for securing calls placed by parties who choose to pla= ce calls through a single reputable telephone service provider." >>> >>> Are you saying that for "on-net" calls, STIR methodology is unnecessary= ? >> >> This seems a little off-topic for this list. >> >> --Richard >> >>> >>> Best regards, >>> >>> >>> Pierce Gorman >>> Core Network Planning >>> O: 913-439-4368 >>> pierce.gorman@sprint.com >>> >>> >>> -----Original Message----- >>> From: Alex Bobotek [mailto:alex@bobotek.net] >>> Sent: July 27, 2015 11:36 PM >>> To: Brian Rosen ; Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> What motivation would a carrier have to choose any model other than car= rier signing using one of a very limited set of carrier-owned keys? Large = scale certificate management is expensive, and TN-specific certificates are= unneeded for securing calls placed by parties who choose to place calls th= rough a single reputable telephone service provider. Anyone can get many c= ertificates, even a free ones anonymously from some issuers. It is typical= ly a combination of the strength of the end-user authentication performed b= y the service provider (or certificate issuer in a provider-agnostic model)= and the identity's history that are most useful in security. >>> >>> If we're trying to secure the current telephone system, DNS-like key re= positories a la DKIM or perhaps a small number (compared to the number of T= Ns) of certificates are far more practical. >>> >>> Regards, >>> >>> Alex >>> >>>> -----Original Message----- >>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>>> Sent: Monday, July 27, 2015 7:40 PM >>>> To: Richard Barnes >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>> >>>> What this means in practice is that it=E2=80=99s TN per cert. >>>> >>>> I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier to m= aintain dozens >>>> of copies of millions of private keys securely, but it=E2=80=99s hard.= You >>>> need multiple copies because you have multiple elements that can >>>> initiate a call, and you don=E2=80=99t want to depend on a centralized >>>> resource to do something as basic as create a call. >>>> >>>> I think it=E2=80=99s hard enough that REQUIRING cert per TN is not acc= eptable. >>>> >>>> Folks with more intimate knowledge of carrier SIP infrastructure >>>> might have more insight than I do. It may be acceptable to have a >>>> centralized resource to manage millions of keys. >>>> >>>> Brian >>>> >>>>> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>>>> >>>>> After the STIR meeting in Prague, Henning and I spent a few minutes >>>>> talking through options for revocation checking and certificate >>>>> scoping, and I think we have a better idea of what the optimal >>>>> solution looks like. Some notes are below, and some slides with >>>>> pictures attached. >>>>> >>>>> tl;dr: We should: >>>>> * Keep TNs in certificates and not bother with any OCSP extensions >>>>> * Require Identity-Info to include OCSP responses for all certs in >>>>> the chain >>>>> >>>>> >>>>> # Background: Revocation in the web PKI >>>>> >>>>> In an HTTPS transaction, the HTTPS server provides the client with >>>>> a certificate, and it can optionally include an OCSP response ("stapl= e" >>>>> it to the transaction). >>>>> >>>>> A certificate contains a validity interval, a key, and some names/TNs= . >>>>> An OCSP responses contains a validity interval, a certificate ID >>>>> (i.e., a hash), and a status (good/revoked/unknown). In the web >>>>> PKI, certificates are required to be no more than 39 months long, >>>>> and OCSP responses no more than 10 days. >>>>> >>>>> Ideally, a client only considers a certificate valid if it is >>>>> accompanied by an OCSP response. In practice, this is not always >>>>> possible; because OCSP queries fail around 3% of the time, browsers >>>>> can't require OCSP. This operational fact will be important below, >>>>> but we will continue to have scoping cert lifetimes as an objective. >>>>> >>>>> In the web PKI, there are basically three revocation checking modalit= ies: >>>>> >>>>> 1. Live OCSP checking [RFC6069] >>>>> 2. OCSP stapling / must_staple [RFC6066, >>>>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>>>> lifetime) >>>>> >>>>> (The last of these is relatively novel, and has not been deployed. >>>>> Neither has must-staple. But they're both pretty trivial, and >>>>> could be folded into a STIR architecture pretty easily.) >>>>> >>>>> Right now, about 90% of TLS transactions use live OCSP, and about 10%= . >>>>> CAs and browsers dearly want the world to move toward stapled OCSP >>>>> or short-lived certs, because these reduces latency and improve the >>>>> quality of revocation information. >>>>> >>>>> Revocation for CA certificates is currently done by having browsers >>>>> download a list from a centralized server, since there's no way to >>>>> staple more than one OCSP response. That solution works OK for the >>>>> web, but if I were designing something de novo, I would probably >>>>> use multi-stapling as well. >>>>> >>>>> >>>>> # Applying this experience to STIR >>>>> >>>>> Most of the below appear to be desired properties by the WG: >>>>> >>>>> * Verifier neeeds to know that a cert is valid for a specific >>>>> number >>>>> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >>>>> issued longer) >>>>> * Caller privacy: Don't report what calls someone receives to a >>>>> central server >>>>> * Carrier privacy: Don't allow a third party to figure out all the >>>>> numbers a carrier holds >>>>> * Minimize the rate at which the CA has to sign things >>>>> * Tolerate outages at the CA >>>>> >>>>> I'm going to assume for now that we will not do live OCSP. It >>>>> violates the caller privacy requirement, and as discussed above, it >>>>> just sucks operationally. So STIR should require OCSP to be sent >>>>> in "stapled" form, which probably means sending it in Identity-Info. >>>>> And while we're at it, we should also do "multi-stapling" -- send >>>>> an OCSP response for CA certs as well. >>>>> >>>>> So if we consider a server with 50k TNs / blocks, that leaves us >>>>> with basically 3 options: >>>>> >>>>> 1. 50k short-lived certs (no OCSP) >>>>> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 >>>>> long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >>>>> with TN info >>>>> >>>>> (As I didn't quite get to say in the meeting, regardless of the >>>>> approach, you have to have 50k of *something*.) Of these, it seems >>>>> like the preference order is 2 > 1 > 3. >>>>> >>>>> Option 3 is bad from several perspectives: >>>>> * Putting TN info in the OCSP response enables someone to trawl for >>>>> numbers unless you access-control the OCSP server, so you inherit a >>>>> requirement to do that. >>>>> * With the rate of churn in number assignments, you're probably >>>>> going to have to update the long-lived cert pretty frequently anyway. >>>>> * Putting TN-specific stuff in certs is better than putting it in >>>>> OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>>>> worse. >>>>> >>>>> Option 1 is mainly bad from the perspective of CA load and outages. >>>>> With Option 2, if the CA goes down, client can continue to use the >>>>> long-lived cert and just not bother doing OCSP (vs. tolerating an >>>>> expired cert). Slightly cleaner. Plus, there's a lot more >>>>> experience caching OCSP than new certs. OCSP signing can also be >>>>> delegated, so you can have the recurring operation done by a lower-ri= sk key. >>>>> >>>>> Option 2 should be pretty easy to automate. You can probably >>>>> re-use tooling for OCSP stapling that has already been developed >>>>> for use with HTTPS. If you're a big box signing for a bunch of >>>>> numbers, you do need to select the right cert and OCSP response for >>>>> a given call, but that's a pretty simple lookup table. >>>>> _______________________________________________ >>>>> 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 >>> >>> ________________________________ >>> >>> This e-mail may contain Sprint proprietary information intended for the= sole use of the recipient(s). Any use by others is prohibited. If you are = not the intended recipient, please contact the sender and delete all copies= of the message. >> >> ________________________________ >> >> This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you are n= ot the intended recipient, please contact the sender and delete all copies = of the message. >> _______________________________________________ >> 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 >> _______________________________________________ >> 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 From nobody Tue Jul 28 18:35:46 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BEB1B2C09 for ; Tue, 28 Jul 2015 18:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uD8svDMzFSTa for ; Tue, 28 Jul 2015 18:35:44 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 065871AC3F2 for ; Tue, 28 Jul 2015 18:35:43 -0700 (PDT) From: Henning Schulzrinne To: "PFAUTZ, PENN L" , Richard Barnes Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAJs4gIAAjm8AgAAGCwCAAA9XAIAAHdna Date: Wed, 29 Jul 2015 01:35:39 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <4B1956260CD29F4A9622F00322FE0531011D3D1D5046@BOBO1A.bobotek.net>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 5:4oSDRYTAZCqXSOtFmVlZbbqa8dXmBcicU+SvntimAroh0LeG48BALc3Qv+QDLbTVkVAddb8pF5NFVozJl7HMA3dh3Gu4v0eL01Le/skLE+K6F2aS5eDF7h1W/8NicUfFvgI67R30SCraq0VsSF0Phw==; 24:iKlRshHNtEu933jfLlSqmAGg75I3Gn6KrWiVlc8j3HUF8bNv3mEr4j1uJ0xSwSoco2RBtxGpfG+K8HbpjMW2BF606jsajim8wokB4I+7ptQ=; 20:PS5PXaoALoks2R76DL5d6xOInRa3YT4wE+ay5nfE8QmTt3/JkBLzhLuP1UeRLjsIMC66EI2c0xMbs26uCt5dvw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635; cy1pr09mb0635: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(2656002)(19580395003)(77156002)(62966003)(33656002)(19580405001)(5002640100001)(92566002)(66066001)(189998001)(40100003)(122556002)(46102003)(2950100001)(93886004)(102836002)(2900100001)(5001920100001)(86362001)(5003630100001)(77096005)(5001770100001)(76576001)(54356999)(5003600100002)(87936001)(76176999)(106116001)(5001960100002)(50986999)(74316001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2015 01:35:39.8727 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" , Alex Bobotek , "Gorman, Pierce A \[CTO\]" , Brian Rosen Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 01:35:45 -0000 I admit, like Richard, I'm confused why this offers significant performance= or simplicity advantages. A cert contains the public key of the number hol= der (in our case), some meta data (validity dates, algorithm descriptions, = CA name) and a signature of the CA. Like a public key, it would likely be s= tored either as a binary blob or some base-64 representation. If you stored just the public key, you'd probably have to replicate at leas= t some of the meta data in other database fields. What simplicity or performance would be gained here? I'm all for allowing registries to store certs, which would be downloaded a= nd cached by validating proxies/SBCs at the callee side as *one* option, si= milar to how the LRN data is maintained today, avoiding both the privacy an= d single-point-of-failure issues. But storing public keys instead doesn't s= eem to offer any inherent advantages that I can see. Another advantage for the cert-by-pointer model is rapid failover: If a car= rier experiences a catastrophic failure in their cert retrieval mechanism, = they can immediately switch the Identity-Info pointer to the public server = (registry), without anybody else being inconvenienced. Or vice versa. This = obviously doesn't work since you can't just point at some random public key= somewhere. Henning ________________________________________ From: stir on behalf of PFAUTZ, PENN L Sent: Tuesday, July 28, 2015 7:38 PM To: Richard Barnes Cc: stir@ietf.org; Alex Bobotek; Gorman, Pierce A [CTO]; Brian Rosen Subject: Re: [stir] On OCSP, TNs, and Privacy to be clear much as I've labored on ENUM a registry doesn't have to be DNS = based. The the LNP DBOR already has to be robust as do the SP and service bureau p= latforms it loads so I've added nothing but a new data field and the provis= ioning that goes with it. The authority is already built in, synched with portability, and tied to "p= arties that can be punished." regards, Penn Sent from my iPad From nobody Tue Jul 28 18:42:34 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF0F1B2CCB for ; Tue, 28 Jul 2015 18:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 75B1vfttwhK2 for ; Tue, 28 Jul 2015 18:42:31 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id BC31D1B2CC8 for ; Tue, 28 Jul 2015 18:42:30 -0700 (PDT) From: Henning Schulzrinne To: Richard Barnes , Chris Wendt Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAJs4gIAABZ6AgAAApgCAAAEaoIAAUo6AgAAA4XCAAGY1gIAAAg2AgAAB3jM= Date: Wed, 29 Jul 2015 01:42:28 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <8C8D48CD-F4A8-4160-A5A7-594DF61A9B60@chriswendt.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 5:i+79ZI6NNJb5BcLI4cLECLgW4Jf9B4fh/ZLTdbw5N5hUFTxYgfoStHdEPZzvuZVf80AECwN2Wg8koA4HWdhVIzecTV+G3lPY/cm3BX17YnQCStRdLE3SbXp1aeQ2yKgb2S670kqOz2g+r2vMdRbEgA==; 24:rrr9d5BgzUMtI5WqixmF7f4OAYwZ77b+ULkLuhF7KwQGL7dliEpa3I/Liu5YRFyCefOTD4MjtapNlJrh1ZloqLgRVIvT2jONTBJI0xLmSP8=; 20:Dp5zetPQPZlyeqO9sPG328ABP6M0ps11NJoTAMTXqMoipAc+FCNn1EgGJJDFvhN1diFeQhPNkNOw4cOMjKAKrA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0633; cy1pr09mb0633: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(50986999)(106116001)(76576001)(33656002)(74316001)(93886004)(19580405001)(77156002)(19580395003)(86362001)(46102003)(87936001)(66066001)(2656002)(2950100001)(62966003)(189998001)(5003600100002)(5002640100001)(102836002)(40100003)(77096005)(5001920100001)(2900100001)(5001770100001)(122556002)(92566002)(5001960100002)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2015 01:42:28.0147 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 01:42:32 -0000 I'm confused by "numbering authority in the middle of each call" part. The = model would be that the numbering authority might serve as the "origin serv= er" and signer, but the cert is stored, at least for high-volume call origi= nators, at the originator, so that you are likely to have fate sharing. Cac= hing at the validator is another option, but calls may not experience suffi= cient locality to give good cache hit ratios. Downloading all certs is not = impossible (with 800M US numbers in use, we're talking 800 GB of data for s= ingle-TN certs, every 1-3 years, and somewhat less if you aggregate TNs in = a cert). ________________________________________ From: Richard Barnes Sent: Tuesday, July 28, 2015 9:30 PM To: Chris Wendt Cc: Henning Schulzrinne; stir@ietf.org; Gorman, Pierce A [CTO]; PFAUTZ, PEN= N L Subject: Re: [stir] On OCSP, TNs, and Privacy On Tue, Jul 28, 2015 at 9:22 PM, Chris Wendt wr= ote: > If the registry is distributed, and the certificate dip is local to the p= rovider, the numbering authority isn=92t in the middle of each call, one of= the points we are advocating in general, in terms of making this scalable = and =93deployable=94. Do you happen to have a good standard technology on hand for synchronizing a database across a potentially unbounded set of signers/verifiers? I don't think we can assume that that set of actors is limited to the set of "providers", for any definition of that term. For so it is written in RFC 7340: """ Generation: Intermediaries as well as end systems must be able to generate the source identity information. Validation: Intermediaries as well as end systems must be able to validate the source identity information. """ If you're going to meet that requirement, I think your distributed registry ends up looking far more complex than just passing around certificates. Of course, if you're just talking about a signer looking up what cert it should use, then we agree; that's just what I meant when I said that managing multiple certs is just a hash table lookup. --Richard From nobody Tue Jul 28 18:43:17 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5371B2CC8 for ; Tue, 28 Jul 2015 18:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 mJToAPdd6iM3 for ; Tue, 28 Jul 2015 18:43:10 -0700 (PDT) Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) (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 EC2031B2CCB for ; Tue, 28 Jul 2015 18:43:09 -0700 (PDT) Received: by qkdv3 with SMTP id v3so59679987qkd.3 for ; Tue, 28 Jul 2015 18:43:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=+hUSH44P7iiX//H0rbwiRxdtooispBbd7s1NCs5dQlo=; b=bqC+Xz1mKgv8Vsnq82V1cGZe9JZzIDI96TFZp3Auyw6aY/GaQAj3AWkjHodQdy5YFf ooLGJGrITVQX4A21ADINdjFO4lRmi4QL7ziacizaBLCtLG2xsOOqkVn+SylPiLBqWj+b E384PAsi2Df6nX3kyarMIpY4lwieExi1/K7IBEsKnZGdPMFWjKhY1fQFwhITPaDjWh+h oamVcgP3zX8p9pzMPPTYqDhMS20bVPUzmGzkaCFAYsrvl2yDQGcww9PpHnknFIh1RF/O qzVusi2ASr8C8Q8JFAdLf0DmHBT5MCwLuIX2xXnYTn/tUV+DtQriuBbb7GFd7B5R3Ma7 8S5A== X-Gm-Message-State: ALoCoQlQh/SuaHUshWZGaMkKLAvot9NJNZBN6wBcjz8jDGjOiqjGf06QFgjrSN8AOfW1+ac2tYha X-Received: by 10.55.21.94 with SMTP id f91mr54081827qkh.51.1438134189074; Tue, 28 Jul 2015 18:43:09 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:992:3ba9:dca8:7b2d? ([2601:41:c101:9364:992:3ba9:dca8:7b2d]) by smtp.gmail.com with ESMTPSA id w68sm12584310qge.18.2015.07.28.18.43.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jul 2015 18:43:07 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8F13BB53-62B1-4094-8FC9-03021BFF8285" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Chris Wendt In-Reply-To: Date: Tue, 28 Jul 2015 21:43:04 -0400 Message-Id: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <8C8D48CD-F4A8-4160-A5A7-594DF61A9B60@chriswendt.net> To: Richard Barnes X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 01:43:16 -0000 --Apple-Mail=_8F13BB53-62B1-4094-8FC9-03021BFF8285 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Henning discussed an example at the modern meeting. Gossip based = distributed mechanisms can be used. I=E2=80=99m curious what you mean by unbounded, in terms of numbers? = 1k/10k/100k/1M? DNS is a much more brute force mechanism for a distributed system but = yet it propagates things pretty quickly globally. 4474bis if i remember correctly even mentions the fact that we will need = to store multiple historical certificate records and references (maybe 2 = is enough in practice) in order to mitigate delays in propagation of new = certificates. I don=E2=80=99t see the issue. > On Jul 28, 2015, at 9:30 PM, Richard Barnes wrote: >=20 > On Tue, Jul 28, 2015 at 9:22 PM, Chris Wendt = > wrote: >> If the registry is distributed, and the certificate dip is local to = the provider, the numbering authority isn=E2=80=99t in the middle of = each call, one of the points we are advocating in general, in terms of = making this scalable and =E2=80=9Cdeployable=E2=80=9D. >=20 > Do you happen to have a good standard technology on hand for > synchronizing a database across a potentially unbounded set of > signers/verifiers? I don't think we can assume that that set of > actors is limited to the set of "providers", for any definition of > that term. For so it is written in RFC 7340: >=20 > """ > Generation: Intermediaries as well as end systems must be able to > generate the source identity information. >=20 > Validation: Intermediaries as well as end systems must be able to > validate the source identity information. > """ >=20 > If you're going to meet that requirement, I think your distributed > registry ends up looking far more complex than just passing around > certificates. >=20 > Of course, if you're just talking about a signer looking up what cert > it should use, then we agree; that's just what I meant when I said > that managing multiple certs is just a hash table lookup. >=20 > --Richard >=20 >=20 >>=20 >>=20 >>> On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne = wrote: >>>=20 >>> That was certainly one of the models that have been discussed in the = past. Particularly for small carriers, this would likely reduce the = operational impact to a configuration option in the SBC. >>>=20 >>> The disadvantage of this model is caller privacy: If the cert is = stored at a numbering authority, it would be easy for that authority to = know which carrier is receiving calls from whom. (It's not the complete = meta data since it's lacking the callee information.) >>>=20 >>> However, unless the TN-to-LRN (in the US) mapping is cached, this = "leak" already exists today. >>>=20 >>> -----Original Message----- >>> From: PFAUTZ, PENN L [mailto:pp3129@att.com] >>> Sent: Tuesday, July 28, 2015 3:14 PM >>> To: Henning Schulzrinne ; Gorman, = Pierce A [CTO] >>> Cc: stir@ietf.org >>> Subject: RE: [stir] On OCSP, TNs, and Privacy >>>=20 >>> Forgive me but my reptile brain keeps whispering in my ear that this = would be a lot easier if we simply had a numbering registry, whether = distributed or centralized - like we need anyway for at least for number = portability - that also contained the public keys. No tedious mucking = about in cyberspace with certs, CRLs, or OCSP. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne >>> Sent: Tuesday, July 28, 2015 10:24 AM >>> To: Gorman, Pierce A [CTO] >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>=20 >>> In the US alone, we have about 4000 carriers. Managing the = reputation of that many entities, reliably (i.e., without making false = positive/negative mistakes) seems a whole lot more manual effort than = storing bags of bits. Storage and automation is cheap, human judgement = and dealing with mistakes is expensive. >>>=20 >>> Obviously, nothing in the architecture prevents wildcard = certificates. >>>=20 >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, = Pierce A [CTO] >>> Sent: Tuesday, July 28, 2015 10:14 AM >>> To: Richard Barnes >>> Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen = >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>=20 >>> I thought the discussion was on key/cert management. I'm asking if = I understood the suggestion to minimize requirements. How is that off = topic? >>>=20 >>> Best regards, >>>=20 >>>=20 >>> Pierce Gorman >>> Core Network Planning >>> O: 913-439-4368 >>> pierce.gorman@sprint.com >>>=20 >>>=20 >>> -----Original Message----- >>> From: Richard Barnes [mailto:rlb@ipv.sx] >>> Sent: July 28, 2015 9:12 AM >>> To: Gorman, Pierce A [CTO] >>> Cc: Alex Bobotek ; Brian Rosen = ; stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>=20 >>> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] = wrote: >>>> "Large scale certificate management is expensive, and TN-specific = certificates are unneeded for securing calls placed by parties who = choose to place calls through a single reputable telephone service = provider." >>>>=20 >>>> Are you saying that for "on-net" calls, STIR methodology is = unnecessary? >>>=20 >>> This seems a little off-topic for this list. >>>=20 >>> --Richard >>>=20 >>>>=20 >>>> Best regards, >>>>=20 >>>>=20 >>>> Pierce Gorman >>>> Core Network Planning >>>> O: 913-439-4368 >>>> pierce.gorman@sprint.com >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Alex Bobotek [mailto:alex@bobotek.net] >>>> Sent: July 27, 2015 11:36 PM >>>> To: Brian Rosen ; Richard Barnes >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>>=20 >>>> What motivation would a carrier have to choose any model other than = carrier signing using one of a very limited set of carrier-owned keys? = Large scale certificate management is expensive, and TN-specific = certificates are unneeded for securing calls placed by parties who = choose to place calls through a single reputable telephone service = provider. Anyone can get many certificates, even a free ones = anonymously from some issuers. It is typically a combination of the = strength of the end-user authentication performed by the service = provider (or certificate issuer in a provider-agnostic model) and the = identity's history that are most useful in security. >>>>=20 >>>> If we're trying to secure the current telephone system, DNS-like = key repositories a la DKIM or perhaps a small number (compared to the = number of TNs) of certificates are far more practical. >>>>=20 >>>> Regards, >>>>=20 >>>> Alex >>>>=20 >>>>> -----Original Message----- >>>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>>>> Sent: Monday, July 27, 2015 7:40 PM >>>>> To: Richard Barnes >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>>>=20 >>>>> What this means in practice is that it=E2=80=99s TN per cert. >>>>>=20 >>>>> I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier = to maintain dozens >>>>> of copies of millions of private keys securely, but it=E2=80=99s = hard. You >>>>> need multiple copies because you have multiple elements that can >>>>> initiate a call, and you don=E2=80=99t want to depend on a = centralized >>>>> resource to do something as basic as create a call. >>>>>=20 >>>>> I think it=E2=80=99s hard enough that REQUIRING cert per TN is not = acceptable. >>>>>=20 >>>>> Folks with more intimate knowledge of carrier SIP infrastructure >>>>> might have more insight than I do. It may be acceptable to have a >>>>> centralized resource to manage millions of keys. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>>>>>=20 >>>>>> After the STIR meeting in Prague, Henning and I spent a few = minutes >>>>>> talking through options for revocation checking and certificate >>>>>> scoping, and I think we have a better idea of what the optimal >>>>>> solution looks like. Some notes are below, and some slides with >>>>>> pictures attached. >>>>>>=20 >>>>>> tl;dr: We should: >>>>>> * Keep TNs in certificates and not bother with any OCSP = extensions >>>>>> * Require Identity-Info to include OCSP responses for all certs = in >>>>>> the chain >>>>>>=20 >>>>>>=20 >>>>>> # Background: Revocation in the web PKI >>>>>>=20 >>>>>> In an HTTPS transaction, the HTTPS server provides the client = with >>>>>> a certificate, and it can optionally include an OCSP response = ("staple" >>>>>> it to the transaction). >>>>>>=20 >>>>>> A certificate contains a validity interval, a key, and some = names/TNs. >>>>>> An OCSP responses contains a validity interval, a certificate ID >>>>>> (i.e., a hash), and a status (good/revoked/unknown). In the web >>>>>> PKI, certificates are required to be no more than 39 months long, >>>>>> and OCSP responses no more than 10 days. >>>>>>=20 >>>>>> Ideally, a client only considers a certificate valid if it is >>>>>> accompanied by an OCSP response. In practice, this is not always >>>>>> possible; because OCSP queries fail around 3% of the time, = browsers >>>>>> can't require OCSP. This operational fact will be important = below, >>>>>> but we will continue to have scoping cert lifetimes as an = objective. >>>>>>=20 >>>>>> In the web PKI, there are basically three revocation checking = modalities: >>>>>>=20 >>>>>> 1. Live OCSP checking [RFC6069] >>>>>> 2. OCSP stapling / must_staple [RFC6066, >>>>>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>>>>> lifetime) >>>>>>=20 >>>>>> (The last of these is relatively novel, and has not been = deployed. >>>>>> Neither has must-staple. But they're both pretty trivial, and >>>>>> could be folded into a STIR architecture pretty easily.) >>>>>>=20 >>>>>> Right now, about 90% of TLS transactions use live OCSP, and about = 10%. >>>>>> CAs and browsers dearly want the world to move toward stapled = OCSP >>>>>> or short-lived certs, because these reduces latency and improve = the >>>>>> quality of revocation information. >>>>>>=20 >>>>>> Revocation for CA certificates is currently done by having = browsers >>>>>> download a list from a centralized server, since there's no way = to >>>>>> staple more than one OCSP response. That solution works OK for = the >>>>>> web, but if I were designing something de novo, I would probably >>>>>> use multi-stapling as well. >>>>>>=20 >>>>>>=20 >>>>>> # Applying this experience to STIR >>>>>>=20 >>>>>> Most of the below appear to be desired properties by the WG: >>>>>>=20 >>>>>> * Verifier neeeds to know that a cert is valid for a specific >>>>>> number >>>>>> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP = if >>>>>> issued longer) >>>>>> * Caller privacy: Don't report what calls someone receives to a >>>>>> central server >>>>>> * Carrier privacy: Don't allow a third party to figure out all = the >>>>>> numbers a carrier holds >>>>>> * Minimize the rate at which the CA has to sign things >>>>>> * Tolerate outages at the CA >>>>>>=20 >>>>>> I'm going to assume for now that we will not do live OCSP. It >>>>>> violates the caller privacy requirement, and as discussed above, = it >>>>>> just sucks operationally. So STIR should require OCSP to be sent >>>>>> in "stapled" form, which probably means sending it in = Identity-Info. >>>>>> And while we're at it, we should also do "multi-stapling" -- send >>>>>> an OCSP response for CA certs as well. >>>>>>=20 >>>>>> So if we consider a server with 50k TNs / blocks, that leaves us >>>>>> with basically 3 options: >>>>>>=20 >>>>>> 1. 50k short-lived certs (no OCSP) >>>>>> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 >>>>>> long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >>>>>> with TN info >>>>>>=20 >>>>>> (As I didn't quite get to say in the meeting, regardless of the >>>>>> approach, you have to have 50k of *something*.) Of these, it = seems >>>>>> like the preference order is 2 > 1 > 3. >>>>>>=20 >>>>>> Option 3 is bad from several perspectives: >>>>>> * Putting TN info in the OCSP response enables someone to trawl = for >>>>>> numbers unless you access-control the OCSP server, so you inherit = a >>>>>> requirement to do that. >>>>>> * With the rate of churn in number assignments, you're probably >>>>>> going to have to update the long-lived cert pretty frequently = anyway. >>>>>> * Putting TN-specific stuff in certs is better than putting it in >>>>>> OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>>>>> worse. >>>>>>=20 >>>>>> Option 1 is mainly bad from the perspective of CA load and = outages. >>>>>> With Option 2, if the CA goes down, client can continue to use = the >>>>>> long-lived cert and just not bother doing OCSP (vs. tolerating an >>>>>> expired cert). Slightly cleaner. Plus, there's a lot more >>>>>> experience caching OCSP than new certs. OCSP signing can also be >>>>>> delegated, so you can have the recurring operation done by a = lower-risk key. >>>>>>=20 >>>>>> Option 2 should be pretty easy to automate. You can probably >>>>>> re-use tooling for OCSP stapling that has already been developed >>>>>> for use with HTTPS. If you're a big box signing for a bunch of >>>>>> numbers, you do need to select the right cert and OCSP response = for >>>>>> a given call, but that's a pretty simple lookup table. >>>>>> _______________________________________________ >>>>>> 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 >>>> ________________________________ >>>>=20 >>>> This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. >>>=20 >>> ________________________________ >>>=20 >>> This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. >>> _______________________________________________ >>> 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 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_8F13BB53-62B1-4094-8FC9-03021BFF8285 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Henning discussed an example at the modern meeting. =  Gossip based distributed mechanisms can be used.

I=E2=80=99m curious what you mean by = unbounded, in terms of numbers?  1k/10k/100k/1M?

DNS is a much more brute = force mechanism for a distributed system but yet it propagates things = pretty quickly globally.

4474bis if i remember correctly even mentions the fact that = we will need to store multiple historical certificate records and = references (maybe 2 is enough in practice) in order to mitigate delays = in propagation of new certificates.

I don=E2=80=99t see the = issue.


On Jul 28, 2015, at 9:30 PM, Richard Barnes <rlb@ipv.sx> wrote:

On Tue, Jul 28, 2015 at 9:22 PM, Chris Wendt = <chris-ietf@chriswendt.net> wrote:
If the registry is = distributed, and the certificate dip is local to the provider, the = numbering authority isn=E2=80=99t in the middle of each call, one of the = points we are advocating in general, in terms of making this scalable = and =E2=80=9Cdeployable=E2=80=9D.

Do you happen to have a good standard technology = on hand for
synchronizing a database = across a potentially unbounded set of
signers/verifiers?  I don't think we can = assume that that set of
actors is limited to the = set of "providers", for any definition of
that term.  For so it is written in RFC = 7340:

"""
  Generation:  Intermediaries as = well as end systems must be able to
     generate the = source identity information.

  Validation: =  Intermediaries as well as end systems must be able to
     validate the = source identity information.
"""

If you're going to meet that requirement, I = think your distributed
registry ends up looking = far more complex than just passing around
certificates.

Of course, if you're just talking about a signer = looking up what cert
it should use, then we = agree; that's just what I meant when I said
that managing multiple certs is just a hash = table lookup.

--Richard




On Jul 28, 2015, at 3:27 = PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

That was certainly one of the models that have been discussed = in the past. Particularly for small carriers, this would likely reduce = the operational impact to a configuration option in the SBC.

The disadvantage of this model is caller = privacy: If the cert is stored at a numbering authority, it would be = easy for that authority to know which carrier is receiving calls from = whom. (It's not the complete meta data since it's lacking the callee = information.)

However, unless the TN-to-LRN = (in the US) mapping is cached, this "leak" already exists today.

-----Original Message-----
From: = PFAUTZ, PENN L [mailto:pp3129@att.com]
Sent: Tuesday, July = 28, 2015 3:14 PM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; Gorman, Pierce A [CTO] = <Pierce.Gorman@sprint.com>
Cc: stir@ietf.org
Subject: RE: [stir] On OCSP, TNs, and Privacy
Forgive me but my reptile brain keeps whispering in my ear = that this would be a lot easier if we simply had a numbering registry, = whether distributed or centralized - like we need anyway for at least = for number portability - that also contained the public keys. No tedious = mucking about in cyberspace with certs, CRLs, or OCSP.



-----Original Message-----
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne
Sent: Tuesday, July 28, 2015 10:24 AM
To: Gorman, Pierce A [CTO]
Cc: stir@ietf.org
Subject: Re: [stir] On OCSP, TNs, and Privacy
In the US alone, we have about 4000 carriers. Managing the = reputation of that many entities, reliably (i.e., without making false = positive/negative mistakes) seems a whole lot more manual effort than = storing bags of bits. Storage and automation is cheap, human judgement = and dealing with mistakes is expensive.

Obviously, nothing in the architecture prevents wildcard = certificates.

-----Original Message-----
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce = A [CTO]
Sent: Tuesday, July 28, 2015 10:14 AM
To: Richard Barnes <rlb@ipv.sx>
Cc: stir@ietf.org; Alex Bobotek = <alex@bobotek.net>; Brian Rosen <br@brianrosen.net>
Subject: Re: [stir] On OCSP, TNs, and Privacy
I thought the discussion was on key/cert management. =  I'm asking if I understood the suggestion to minimize = requirements.  How is that off topic?

Best regards,


Pierce Gorman
Core Network Planning
O: 913-439-4368
pierce.gorman@sprint.com


-----Original Message-----
From: Richard Barnes = [mailto:rlb@ipv.sx]
Sent: July 28, 2015 9:12 AM
To: Gorman, Pierce A [CTO] = <Pierce.Gorman@sprint.com>
Cc: Alex Bobotek = <alex@bobotek.net>; Brian Rosen <br@brianrosen.net>; = stir@ietf.org
Subject: Re: [stir] On OCSP, TNs, and = Privacy

On Tue, Jul 28, 2015 at 9:51 AM, = Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com> wrote:
"Large scale certificate = management is expensive, and TN-specific certificates are unneeded for = securing calls placed by parties who choose to place calls through a = single reputable telephone service provider."

Are you saying that for "on-net" calls, STIR methodology is = unnecessary?

This seems a = little off-topic for this list.

--Richard


Best regards,


Pierce Gorman
Core Network Planning
O: 913-439-4368
pierce.gorman@sprint.com


-----Original Message-----
From: Alex Bobotek [mailto:alex@bobotek.net]
Sent: July 27, 2015 11:36 PM
To: Brian Rosen = <br@brianrosen.net>; Richard Barnes <rlb@ipv.sx>
Cc: stir@ietf.org
Subject: Re: [stir] On OCSP, = TNs, and Privacy

What motivation would a = carrier have to choose any model other than carrier signing using one of = a very limited set of carrier-owned keys? Large scale certificate = management is expensive, and TN-specific certificates are unneeded for = securing calls placed by parties who choose to place calls through a = single reputable telephone service provider.  Anyone can get many = certificates, even a free ones anonymously from some issuers.  It = is typically a combination of the strength of the end-user = authentication performed by the service provider (or certificate issuer = in a provider-agnostic model) and the identity's history that are most = useful in security.

If we're trying to = secure the current telephone system, DNS-like key repositories a la DKIM = or perhaps a small number (compared to the number of TNs) of = certificates are far more practical.

Regards,

Alex

-----Original = Message-----
From: stir [mailto:stir-bounces@ietf.org] On = Behalf Of Brian Rosen
Sent: Monday, July 27, 2015 7:40 = PM
To: Richard Barnes <rlb@ipv.sx>
Cc: = stir@ietf.org
Subject: Re: [stir] On OCSP, TNs, and = Privacy

What this means in practice is that = it=E2=80=99s TN per cert.

I wouldn=E2=80=99t = say that it=E2=80=99s impossible for a carrier to maintain dozens
of copies of millions of private keys securely, but it=E2=80=99= s hard.  You
need multiple copies because you have = multiple elements that can
initiate a call, and you = don=E2=80=99t want to depend on a centralized
resource to = do something as basic as create a call.

I = think it=E2=80=99s hard enough that REQUIRING cert per TN is not = acceptable.

Folks with more intimate = knowledge of carrier SIP infrastructure
might have more = insight than I do.  It may be acceptable to have a
centralized resource to manage millions of keys.

Brian

On Jul 27, 2015, at 6:13 PM, Richard Barnes = <rlb@ipv.sx> wrote:

After the STIR = meeting in Prague, Henning and I spent a few minutes
talking= through options for revocation checking and certificate
scoping, and I think we have a better idea of what the = optimal
solution looks like.  Some notes are below, = and some slides with
pictures attached.

tl;dr: We should:
* Keep TNs in certificates = and not bother with any OCSP extensions
* Require = Identity-Info to include OCSP responses for all certs in
the= chain


# Background: = Revocation in the web PKI

In an HTTPS = transaction, the HTTPS server provides the client with
a = certificate, and it can optionally include an OCSP response ("staple"
it to the transaction).

A = certificate contains a validity interval, a key, and some names/TNs.
An OCSP responses contains a validity interval, a certificate = ID
(i.e., a hash), and a status (good/revoked/unknown). =  In the web
PKI, certificates are required to be no = more than 39 months long,
and OCSP responses no more than = 10 days.

Ideally, a client only considers a = certificate valid if it is
accompanied by an OCSP = response.  In practice, this is not always
possible; = because OCSP queries fail around 3% of the time, browsers
can't require OCSP.  This operational fact will be = important below,
but we will continue to have scoping cert = lifetimes as an objective.

In the web PKI, = there are basically three revocation checking modalities:

1. Live OCSP checking [RFC6069]
2.= OCSP stapling / must_staple [RFC6066,
draft-hallambaker-tlsfeature] 3. Short-lived certificates = (~OCSP
lifetime)

(The last of = these is relatively novel, and has not been deployed.
Neither has must-staple.  But they're both pretty = trivial, and
could be folded into a STIR architecture = pretty easily.)

Right now, about 90% of TLS = transactions use live OCSP, and about 10%.
CAs and = browsers dearly want the world to move toward stapled OCSP
or short-lived certs, because these reduces latency and = improve the
quality of revocation information.

Revocation for CA certificates is currently = done by having browsers
download a list from a centralized = server, since there's no way to
staple more than one OCSP = response.  That solution works OK for the
web, but if = I were designing something de novo, I would probably
use = multi-stapling as well.


# = Applying this experience to STIR

Most of = the below appear to be desired properties by the WG:

* Verifier neeeds to know that a cert is valid for a = specific
number
* Scoped cert lifetime: = Limit certs to ~1week lifetime (by OCSP if
issued = longer)
* Caller privacy: Don't report what calls someone = receives to a
central server
* Carrier = privacy: Don't allow a third party to figure out all the
numbers a carrier holds
* Minimize the rate at = which the CA has to sign things
* Tolerate outages at the = CA

I'm going to assume for now that we will = not do live OCSP.  It
violates the caller privacy = requirement, and as discussed above, it
just sucks = operationally.  So STIR should require OCSP to be sent
in "stapled" form, which probably means sending it in = Identity-Info.
And while we're at it, we should also do = "multi-stapling" -- send
an OCSP response for CA certs as = well.

So if we consider a server with 50k = TNs / blocks, that leaves us
with basically 3 options:

1. 50k short-lived certs (no OCSP)
2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1
long-lived cert not scoped to TN (or a few loosely scoped) + = OCSP
with TN info

(As I = didn't quite get to say in the meeting, regardless of the
approach, you have to have 50k of *something*.)  Of = these, it seems
like the preference order is 2 > 1 > = 3.

Option 3 is bad from several = perspectives:
* Putting TN info in the OCSP response = enables someone to trawl for
numbers unless you = access-control the OCSP server, so you inherit a
requirement= to do that.
* With the rate of churn in number = assignments, you're probably
going to have to update the = long-lived cert pretty frequently anyway.
* Putting = TN-specific stuff in certs is better than putting it in
OCSP.  As bad as X.509 libraries can be, OCSP libraries = are much
worse.

Option 1 is = mainly bad from the perspective of CA load and outages.
With= Option 2, if the CA goes down, client can continue to use the
long-lived cert and just not bother doing OCSP (vs. = tolerating an
expired cert).  Slightly cleaner. =  Plus, there's a lot more
experience caching OCSP = than new certs.  OCSP signing can also be
delegated, = so you can have the recurring operation done by a lower-risk key.

Option 2 should be pretty easy to automate. =  You can probably
re-use tooling for OCSP stapling = that has already been developed
for use with HTTPS. =  If you're a big box signing for a bunch of
numbers, = you do need to select the right cert and OCSP response for
a= given call, but that's a pretty simple lookup table.
<STIR.pptx>______________________________________________= _
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

________________________________
This e-mail may contain Sprint proprietary = information intended for the sole use of the recipient(s). Any use by = others is prohibited. If you are not the intended recipient, please = contact the sender and delete all copies of the message.

________________________________
This e-mail may contain Sprint proprietary = information intended for the sole use of the recipient(s). Any use by = others is prohibited. If you are not the intended recipient, please = contact the sender and delete all copies of the message.
_______________________________________________
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
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

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

= --Apple-Mail=_8F13BB53-62B1-4094-8FC9-03021BFF8285-- From nobody Tue Jul 28 18:47:10 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AD31B34BE for ; Tue, 28 Jul 2015 18:47:08 -0700 (PDT) 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] autolearn=ham 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 nRziYTWfJ67G for ; Tue, 28 Jul 2015 18:47:06 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (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 4D69D1B34BA for ; Tue, 28 Jul 2015 18:47:06 -0700 (PDT) Received: by qgeu79 with SMTP id u79so85508440qge.1 for ; Tue, 28 Jul 2015 18:47:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=68qh4AbzapnbpEsmuywHp0O0vDMSHRqY11+1h+JIXWI=; b=ais6+hiz0cMjUV72Db5+Pj8lCqEnn0DyWFJQiOGRwxndvLYUbpq57QDKv9XIdqUOJt RvOTVwFLhcNzFgD6v+scAmGOhQhz3ScerT914pLp+xjAUamAGun8BdK7FcUO85vOQ4X8 HqYWIXZ8I4/OghjRIBrioUU/bgJCjdv+fuTM68OUtTL053TlB2yssA8iOU78wcbb6GDq +BU1ycuf99Usg3fIdh45U97xMYKhqkOaxBo0RzIouizBFZc6ql76CRhFzYkcJdNmNwPY WprrT6e0uaNUF4rDNbmLBIuDC9cramzLYyAOFbhu0iXNqyMB/63V5nPp9FPZjIw2r4lX qP6g== X-Gm-Message-State: ALoCoQnXW8b3A9HdFP6e0hJBXeLJnBEWhpJ9ta/PqMqOWSLY0uCtkUtBl4avyS2xAgzAnkarnT8v X-Received: by 10.140.92.41 with SMTP id a38mr54506456qge.30.1438134425518; Tue, 28 Jul 2015 18:47:05 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:992:3ba9:dca8:7b2d? ([2601:41:c101:9364:992:3ba9:dca8:7b2d]) by smtp.gmail.com with ESMTPSA id c88sm12588817qge.26.2015.07.28.18.47.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jul 2015 18:47:04 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Chris Wendt In-Reply-To: Date: Tue, 28 Jul 2015 21:47:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <19CE0D74-D1BE-4707-A9DD-ABCA19E097D5@chriswendt.net> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <8C8D48CD-F4A8-4160-A5A7-594DF61A9B60@chriswendt.net> To: Henning Schulzrinne X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Richard Barnes , "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 01:47:08 -0000 Sorry, a poor choice of words, i was responding to your concern: > The disadvantage of this model is caller privacy: If the cert is = stored at a numbering authority, it would be easy for that authority to = know which carrier is receiving calls from whom. (It's not the complete = meta data since it's lacking the callee information.) so replace =93in the middle of the call=94 with being able to correlate = carrier calling information. > On Jul 28, 2015, at 9:42 PM, Henning Schulzrinne = wrote: >=20 > I'm confused by "numbering authority in the middle of each call" part. = The model would be that the numbering authority might serve as the = "origin server" and signer, but the cert is stored, at least for = high-volume call originators, at the originator, so that you are likely = to have fate sharing. Caching at the validator is another option, but = calls may not experience sufficient locality to give good cache hit = ratios. Downloading all certs is not impossible (with 800M US numbers in = use, we're talking 800 GB of data for single-TN certs, every 1-3 years, = and somewhat less if you aggregate TNs in a cert). >=20 > ________________________________________ > From: Richard Barnes > Sent: Tuesday, July 28, 2015 9:30 PM > To: Chris Wendt > Cc: Henning Schulzrinne; stir@ietf.org; Gorman, Pierce A [CTO]; = PFAUTZ, PENN L > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 > On Tue, Jul 28, 2015 at 9:22 PM, Chris Wendt = wrote: >> If the registry is distributed, and the certificate dip is local to = the provider, the numbering authority isn=92t in the middle of each = call, one of the points we are advocating in general, in terms of making = this scalable and =93deployable=94. >=20 > Do you happen to have a good standard technology on hand for > synchronizing a database across a potentially unbounded set of > signers/verifiers? I don't think we can assume that that set of > actors is limited to the set of "providers", for any definition of > that term. For so it is written in RFC 7340: >=20 > """ > Generation: Intermediaries as well as end systems must be able to > generate the source identity information. >=20 > Validation: Intermediaries as well as end systems must be able to > validate the source identity information. > """ >=20 > If you're going to meet that requirement, I think your distributed > registry ends up looking far more complex than just passing around > certificates. >=20 > Of course, if you're just talking about a signer looking up what cert > it should use, then we agree; that's just what I meant when I said > that managing multiple certs is just a hash table lookup. >=20 > --Richard >=20 From nobody Tue Jul 28 18:51:11 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1630B1B30DB for ; Tue, 28 Jul 2015 18:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 NmBgaeGJx1Fh for ; Tue, 28 Jul 2015 18:51:04 -0700 (PDT) Received: from mail-vn0-f52.google.com (mail-vn0-f52.google.com [209.85.216.52]) (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 168401B2C95 for ; Tue, 28 Jul 2015 18:51:03 -0700 (PDT) Received: by vnaa140 with SMTP id a140so49683001vna.2 for ; Tue, 28 Jul 2015 18:51:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vCaN64txaMCoXENU5yULZPGViy3oJRhkIflq/Y6cy0s=; b=VUSzwNOzNHsQXuVeITAFp6i7L2JRR/eFouqALXCXS0lIVu2UWLU2xY2k8HlRRLChQl WbtDclMXFvw7E1qkaDRFyv9j35pl6srj9nfSx6ZrsRP5q36M6W6a8oOaHTgjnbtH0VFN l3sdmbtJaKxgRrZspefEdFDf4cccFofNeEiVdEsPs8O1hmJ4Z7E/uq3BI3OhjVoWYPUl jZvpM8ZchR+9hCQ+7e7zTRvczMGbcgt9NB8+aPvlEqCq1KLEf01lTcu3AUhFCK0ztuHc bKnpYqn0Gv+xUJWeQVbVFEpYy1fvWjsT/7WNBwwocRjbiKEZcBimX1M9PjRlLWzUZhB9 THmg== X-Gm-Message-State: ALoCoQluidZ6P+fALjon5M0fVHgPVvssVfJ6OpM2Fgs9LJUU228UtVdP8oP+vDCpPbydQC3TbuLH MIME-Version: 1.0 X-Received: by 10.52.163.243 with SMTP id yl19mr47687100vdb.51.1438134662128; Tue, 28 Jul 2015 18:51:02 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Tue, 28 Jul 2015 18:51:01 -0700 (PDT) In-Reply-To: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <8C8D48CD-F4A8-4160-A5A7-594DF61A9B60@chriswendt.net> Date: Tue, 28 Jul 2015 21:51:01 -0400 Message-ID: From: Richard Barnes To: Chris Wendt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 01:51:10 -0000 On Tue, Jul 28, 2015 at 9:43 PM, Chris Wendt wr= ote: > Henning discussed an example at the modern meeting. Gossip based > distributed mechanisms can be used. > > I=E2=80=99m curious what you mean by unbounded, in terms of numbers? > 1k/10k/100k/1M? How many phones are there out there? "end systems must be able to validate the source identity information." > DNS is a much more brute force mechanism for a distributed system but yet= it > propagates things pretty quickly globally. > > 4474bis if i remember correctly even mentions the fact that we will need = to > store multiple historical certificate records and references (maybe 2 is > enough in practice) in order to mitigate delays in propagation of new > certificates. > > I don=E2=80=99t see the issue. The point is that when my phone gets a call it needs to be able to verify the caller's authorization. The Identity-Info signature binds the call to the caller's public key. So the my phone needs to verify that the public key is authorized. If I understand you correctly, you're proposing that my phone needs to sync down a giant database of which public keys are authorized for which numbers, or it needs to call out to some registry it trusts, which needs to be online all the time. Those both seem far worse than my phone just having to look up a certificate, or verify one that was included in the INVITE directly. The only cost of on the signer side is that the signer has to pick the right cert to send, which, as I said before, is just a hash table lookup. --Richard > > > On Jul 28, 2015, at 9:30 PM, Richard Barnes wrote: > > On Tue, Jul 28, 2015 at 9:22 PM, Chris Wendt > wrote: > > If the registry is distributed, and the certificate dip is local to the > provider, the numbering authority isn=E2=80=99t in the middle of each cal= l, one of > the points we are advocating in general, in terms of making this scalable > and =E2=80=9Cdeployable=E2=80=9D. > > > Do you happen to have a good standard technology on hand for > synchronizing a database across a potentially unbounded set of > signers/verifiers? I don't think we can assume that that set of > actors is limited to the set of "providers", for any definition of > that term. For so it is written in RFC 7340: > > """ > Generation: Intermediaries as well as end systems must be able to > generate the source identity information. > > Validation: Intermediaries as well as end systems must be able to > validate the source identity information. > """ > > If you're going to meet that requirement, I think your distributed > registry ends up looking far more complex than just passing around > certificates. > > Of course, if you're just talking about a signer looking up what cert > it should use, then we agree; that's just what I meant when I said > that managing multiple certs is just a hash table lookup. > > --Richard > > > > > On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne > wrote: > > That was certainly one of the models that have been discussed in the past= . > Particularly for small carriers, this would likely reduce the operational > impact to a configuration option in the SBC. > > The disadvantage of this model is caller privacy: If the cert is stored a= t a > numbering authority, it would be easy for that authority to know which > carrier is receiving calls from whom. (It's not the complete meta data si= nce > it's lacking the callee information.) > > However, unless the TN-to-LRN (in the US) mapping is cached, this "leak" > already exists today. > > -----Original Message----- > From: PFAUTZ, PENN L [mailto:pp3129@att.com] > Sent: Tuesday, July 28, 2015 3:14 PM > To: Henning Schulzrinne ; Gorman, Pierce A > [CTO] > Cc: stir@ietf.org > Subject: RE: [stir] On OCSP, TNs, and Privacy > > Forgive me but my reptile brain keeps whispering in my ear that this woul= d > be a lot easier if we simply had a numbering registry, whether distribute= d > or centralized - like we need anyway for at least for number portability = - > that also contained the public keys. No tedious mucking about in cyberspa= ce > with certs, CRLs, or OCSP. > > > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinn= e > Sent: Tuesday, July 28, 2015 10:24 AM > To: Gorman, Pierce A [CTO] > Cc: stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy > > In the US alone, we have about 4000 carriers. Managing the reputation of > that many entities, reliably (i.e., without making false positive/negativ= e > mistakes) seems a whole lot more manual effort than storing bags of bits. > Storage and automation is cheap, human judgement and dealing with mistake= s > is expensive. > > Obviously, nothing in the architecture prevents wildcard certificates. > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A > [CTO] > Sent: Tuesday, July 28, 2015 10:14 AM > To: Richard Barnes > Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen > > Subject: Re: [stir] On OCSP, TNs, and Privacy > > I thought the discussion was on key/cert management. I'm asking if I > understood the suggestion to minimize requirements. How is that off topi= c? > > Best regards, > > > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > > > -----Original Message----- > From: Richard Barnes [mailto:rlb@ipv.sx] > Sent: July 28, 2015 9:12 AM > To: Gorman, Pierce A [CTO] > Cc: Alex Bobotek ; Brian Rosen ; > stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy > > On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] > wrote: > > "Large scale certificate management is expensive, and TN-specific > certificates are unneeded for securing calls placed by parties who choose= to > place calls through a single reputable telephone service provider." > > Are you saying that for "on-net" calls, STIR methodology is unnecessary? > > > This seems a little off-topic for this list. > > --Richard > > > Best regards, > > > Pierce Gorman > Core Network Planning > O: 913-439-4368 > pierce.gorman@sprint.com > > > -----Original Message----- > From: Alex Bobotek [mailto:alex@bobotek.net] > Sent: July 27, 2015 11:36 PM > To: Brian Rosen ; Richard Barnes > Cc: stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy > > What motivation would a carrier have to choose any model other than carri= er > signing using one of a very limited set of carrier-owned keys? Large scal= e > certificate management is expensive, and TN-specific certificates are > unneeded for securing calls placed by parties who choose to place calls > through a single reputable telephone service provider. Anyone can get ma= ny > certificates, even a free ones anonymously from some issuers. It is > typically a combination of the strength of the end-user authentication > performed by the service provider (or certificate issuer in a > provider-agnostic model) and the identity's history that are most useful = in > security. > > If we're trying to secure the current telephone system, DNS-like key > repositories a la DKIM or perhaps a small number (compared to the number = of > TNs) of certificates are far more practical. > > Regards, > > Alex > > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen > Sent: Monday, July 27, 2015 7:40 PM > To: Richard Barnes > Cc: stir@ietf.org > Subject: Re: [stir] On OCSP, TNs, and Privacy > > What this means in practice is that it=E2=80=99s TN per cert. > > I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier to main= tain dozens > of copies of millions of private keys securely, but it=E2=80=99s hard. Y= ou > need multiple copies because you have multiple elements that can > initiate a call, and you don=E2=80=99t want to depend on a centralized > resource to do something as basic as create a call. > > I think it=E2=80=99s hard enough that REQUIRING cert per TN is not accept= able. > > Folks with more intimate knowledge of carrier SIP infrastructure > might have more insight than I do. It may be acceptable to have a > centralized resource to manage millions of keys. > > Brian > > On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: > > After the STIR meeting in Prague, Henning and I spent a few minutes > talking through options for revocation checking and certificate > scoping, and I think we have a better idea of what the optimal > solution looks like. Some notes are below, and some slides with > pictures attached. > > tl;dr: We should: > * Keep TNs in certificates and not bother with any OCSP extensions > * Require Identity-Info to include OCSP responses for all certs in > the chain > > > # Background: Revocation in the web PKI > > In an HTTPS transaction, the HTTPS server provides the client with > a certificate, and it can optionally include an OCSP response ("staple" > it to the transaction). > > A certificate contains a validity interval, a key, and some names/TNs. > An OCSP responses contains a validity interval, a certificate ID > (i.e., a hash), and a status (good/revoked/unknown). In the web > PKI, certificates are required to be no more than 39 months long, > and OCSP responses no more than 10 days. > > Ideally, a client only considers a certificate valid if it is > accompanied by an OCSP response. In practice, this is not always > possible; because OCSP queries fail around 3% of the time, browsers > can't require OCSP. This operational fact will be important below, > but we will continue to have scoping cert lifetimes as an objective. > > In the web PKI, there are basically three revocation checking modalities: > > 1. Live OCSP checking [RFC6069] > 2. OCSP stapling / must_staple [RFC6066, > draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP > lifetime) > > (The last of these is relatively novel, and has not been deployed. > Neither has must-staple. But they're both pretty trivial, and > could be folded into a STIR architecture pretty easily.) > > Right now, about 90% of TLS transactions use live OCSP, and about 10%. > CAs and browsers dearly want the world to move toward stapled OCSP > or short-lived certs, because these reduces latency and improve the > quality of revocation information. > > Revocation for CA certificates is currently done by having browsers > download a list from a centralized server, since there's no way to > staple more than one OCSP response. That solution works OK for the > web, but if I were designing something de novo, I would probably > use multi-stapling as well. > > > # Applying this experience to STIR > > Most of the below appear to be desired properties by the WG: > > * Verifier neeeds to know that a cert is valid for a specific > number > * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if > issued longer) > * Caller privacy: Don't report what calls someone receives to a > central server > * Carrier privacy: Don't allow a third party to figure out all the > numbers a carrier holds > * Minimize the rate at which the CA has to sign things > * Tolerate outages at the CA > > I'm going to assume for now that we will not do live OCSP. It > violates the caller privacy requirement, and as discussed above, it > just sucks operationally. So STIR should require OCSP to be sent > in "stapled" form, which probably means sending it in Identity-Info. > And while we're at it, we should also do "multi-stapling" -- send > an OCSP response for CA certs as well. > > So if we consider a server with 50k TNs / blocks, that leaves us > with basically 3 options: > > 1. 50k short-lived certs (no OCSP) > 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 > long-lived cert not scoped to TN (or a few loosely scoped) + OCSP > with TN info > > (As I didn't quite get to say in the meeting, regardless of the > approach, you have to have 50k of *something*.) Of these, it seems > like the preference order is 2 > 1 > 3. > > Option 3 is bad from several perspectives: > * Putting TN info in the OCSP response enables someone to trawl for > numbers unless you access-control the OCSP server, so you inherit a > requirement to do that. > * With the rate of churn in number assignments, you're probably > going to have to update the long-lived cert pretty frequently anyway. > * Putting TN-specific stuff in certs is better than putting it in > OCSP. As bad as X.509 libraries can be, OCSP libraries are much > worse. > > Option 1 is mainly bad from the perspective of CA load and outages. > With Option 2, if the CA goes down, client can continue to use the > long-lived cert and just not bother doing OCSP (vs. tolerating an > expired cert). Slightly cleaner. Plus, there's a lot more > experience caching OCSP than new certs. OCSP signing can also be > delegated, so you can have the recurring operation done by a lower-risk k= ey. > > Option 2 should be pretty easy to automate. You can probably > re-use tooling for OCSP stapling that has already been developed > for use with HTTPS. If you're a big box signing for a bunch of > numbers, you do need to select the right cert and OCSP response for > a given call, but that's a pretty simple lookup table. > _______________________________________________ > 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 > > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the s= ole > use of the recipient(s). Any use by others is prohibited. If you are not = the > intended recipient, please contact the sender and delete all copies of th= e > message. > > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the s= ole > use of the recipient(s). Any use by others is prohibited. If you are not = the > intended recipient, please contact the sender and delete all copies of th= e > message. > _______________________________________________ > 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 > _______________________________________________ > 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 > > From nobody Tue Jul 28 18:57:18 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B34D1B3155 for ; Tue, 28 Jul 2015 18:57:16 -0700 (PDT) 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] autolearn=ham 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 RXo8tdqSpJq3 for ; Tue, 28 Jul 2015 18:57:12 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (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 3DE581B3156 for ; Tue, 28 Jul 2015 18:57:12 -0700 (PDT) Received: by qged69 with SMTP id d69so85298305qge.0 for ; Tue, 28 Jul 2015 18:57:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=XjioblF4sBq6+9v2Ph0jmyRS5qUjvaw8lco/f6gwsQY=; b=IisAaHcOs+ntEyZGPfJ9NtxChCb4pxcXruj90kn/J0Vl9xVsJIfNuD4qxZYkRjRob2 C8GsCKF249AYvljYWeq7EWzc79Srjvndh1NhZsYXue1EFaJ+5Gc7tHARiFxFLiacVDiF hrgMNHAzo8SOuLEXf9Idxd9PW4W4zMJZlD11uVq5vm1m5MaEzJEBkp4oz3dCReJ8HeBE bHGbofBMheThck0v3y80cd+PESXsQanXRHJTdA4ibjEV09njYvJ1GRCyM/MS1ufEV/NC fuvYyWFkqcVHRr6N9h9YK6vb//Uc+stkqx2JdclGIEKV89M7Ypn+hUBE8aEXAjQWj578 gXQw== X-Gm-Message-State: ALoCoQnTh1HHDtlDrH/24yDPit2lKR6tNwmFMyX1z7i2Xlx2ej/KaThkUEcdPWZSEOGXGHW0sF2D X-Received: by 10.140.89.197 with SMTP id v63mr54375008qgd.97.1438135031308; Tue, 28 Jul 2015 18:57:11 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:992:3ba9:dca8:7b2d? ([2601:41:c101:9364:992:3ba9:dca8:7b2d]) by smtp.gmail.com with ESMTPSA id d8sm12624627qka.21.2015.07.28.18.57.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jul 2015 18:57:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Chris Wendt In-Reply-To: Date: Tue, 28 Jul 2015 21:57:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <8C8D48CD-F4A8-4160-A5A7-594DF61A9B60@chriswendt.net> To: Richard Barnes X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 01:57:16 -0000 Depends on your perspective.=20 I would suspect we would both agree that =E2=80=9Cphones querying the = numbering authority registry" is not the problem statement we are = working towards, for very different reasons. > On Jul 28, 2015, at 9:51 PM, Richard Barnes wrote: >=20 > On Tue, Jul 28, 2015 at 9:43 PM, Chris Wendt = wrote: >> Henning discussed an example at the modern meeting. Gossip based >> distributed mechanisms can be used. >>=20 >> I=E2=80=99m curious what you mean by unbounded, in terms of numbers? >> 1k/10k/100k/1M? >=20 > How many phones are there out there? "end systems must be able to > validate the source identity information." >=20 >=20 >> DNS is a much more brute force mechanism for a distributed system but = yet it >> propagates things pretty quickly globally. >>=20 >> 4474bis if i remember correctly even mentions the fact that we will = need to >> store multiple historical certificate records and references (maybe 2 = is >> enough in practice) in order to mitigate delays in propagation of new >> certificates. >>=20 >> I don=E2=80=99t see the issue. >=20 > The point is that when my phone gets a call it needs to be able to > verify the caller's authorization. The Identity-Info signature binds > the call to the caller's public key. So the my phone needs to verify > that the public key is authorized. >=20 > If I understand you correctly, you're proposing that my phone needs to > sync down a giant database of which public keys are authorized for > which numbers, or it needs to call out to some registry it trusts, > which needs to be online all the time. >=20 > Those both seem far worse than my phone just having to look up a > certificate, or verify one that was included in the INVITE directly. > The only cost of on the signer side is that the signer has to pick the > right cert to send, which, as I said before, is just a hash table > lookup. >=20 > --Richard >=20 >>=20 >>=20 >> On Jul 28, 2015, at 9:30 PM, Richard Barnes wrote: >>=20 >> On Tue, Jul 28, 2015 at 9:22 PM, Chris Wendt = >> wrote: >>=20 >> If the registry is distributed, and the certificate dip is local to = the >> provider, the numbering authority isn=E2=80=99t in the middle of each = call, one of >> the points we are advocating in general, in terms of making this = scalable >> and =E2=80=9Cdeployable=E2=80=9D. >>=20 >>=20 >> Do you happen to have a good standard technology on hand for >> synchronizing a database across a potentially unbounded set of >> signers/verifiers? I don't think we can assume that that set of >> actors is limited to the set of "providers", for any definition of >> that term. For so it is written in RFC 7340: >>=20 >> """ >> Generation: Intermediaries as well as end systems must be able to >> generate the source identity information. >>=20 >> Validation: Intermediaries as well as end systems must be able to >> validate the source identity information. >> """ >>=20 >> If you're going to meet that requirement, I think your distributed >> registry ends up looking far more complex than just passing around >> certificates. >>=20 >> Of course, if you're just talking about a signer looking up what cert >> it should use, then we agree; that's just what I meant when I said >> that managing multiple certs is just a hash table lookup. >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >> On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne >> wrote: >>=20 >> That was certainly one of the models that have been discussed in the = past. >> Particularly for small carriers, this would likely reduce the = operational >> impact to a configuration option in the SBC. >>=20 >> The disadvantage of this model is caller privacy: If the cert is = stored at a >> numbering authority, it would be easy for that authority to know = which >> carrier is receiving calls from whom. (It's not the complete meta = data since >> it's lacking the callee information.) >>=20 >> However, unless the TN-to-LRN (in the US) mapping is cached, this = "leak" >> already exists today. >>=20 >> -----Original Message----- >> From: PFAUTZ, PENN L [mailto:pp3129@att.com] >> Sent: Tuesday, July 28, 2015 3:14 PM >> To: Henning Schulzrinne ; Gorman, Pierce = A >> [CTO] >> Cc: stir@ietf.org >> Subject: RE: [stir] On OCSP, TNs, and Privacy >>=20 >> Forgive me but my reptile brain keeps whispering in my ear that this = would >> be a lot easier if we simply had a numbering registry, whether = distributed >> or centralized - like we need anyway for at least for number = portability - >> that also contained the public keys. No tedious mucking about in = cyberspace >> with certs, CRLs, or OCSP. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning = Schulzrinne >> Sent: Tuesday, July 28, 2015 10:24 AM >> To: Gorman, Pierce A [CTO] >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >>=20 >> In the US alone, we have about 4000 carriers. Managing the reputation = of >> that many entities, reliably (i.e., without making false = positive/negative >> mistakes) seems a whole lot more manual effort than storing bags of = bits. >> Storage and automation is cheap, human judgement and dealing with = mistakes >> is expensive. >>=20 >> Obviously, nothing in the architecture prevents wildcard = certificates. >>=20 >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce = A >> [CTO] >> Sent: Tuesday, July 28, 2015 10:14 AM >> To: Richard Barnes >> Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen >> >> Subject: Re: [stir] On OCSP, TNs, and Privacy >>=20 >> I thought the discussion was on key/cert management. I'm asking if I >> understood the suggestion to minimize requirements. How is that off = topic? >>=20 >> Best regards, >>=20 >>=20 >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >>=20 >>=20 >> -----Original Message----- >> From: Richard Barnes [mailto:rlb@ipv.sx] >> Sent: July 28, 2015 9:12 AM >> To: Gorman, Pierce A [CTO] >> Cc: Alex Bobotek ; Brian Rosen ; >> stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >>=20 >> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] >> wrote: >>=20 >> "Large scale certificate management is expensive, and TN-specific >> certificates are unneeded for securing calls placed by parties who = choose to >> place calls through a single reputable telephone service provider." >>=20 >> Are you saying that for "on-net" calls, STIR methodology is = unnecessary? >>=20 >>=20 >> This seems a little off-topic for this list. >>=20 >> --Richard >>=20 >>=20 >> Best regards, >>=20 >>=20 >> Pierce Gorman >> Core Network Planning >> O: 913-439-4368 >> pierce.gorman@sprint.com >>=20 >>=20 >> -----Original Message----- >> From: Alex Bobotek [mailto:alex@bobotek.net] >> Sent: July 27, 2015 11:36 PM >> To: Brian Rosen ; Richard Barnes >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >>=20 >> What motivation would a carrier have to choose any model other than = carrier >> signing using one of a very limited set of carrier-owned keys? Large = scale >> certificate management is expensive, and TN-specific certificates are >> unneeded for securing calls placed by parties who choose to place = calls >> through a single reputable telephone service provider. Anyone can = get many >> certificates, even a free ones anonymously from some issuers. It is >> typically a combination of the strength of the end-user = authentication >> performed by the service provider (or certificate issuer in a >> provider-agnostic model) and the identity's history that are most = useful in >> security. >>=20 >> If we're trying to secure the current telephone system, DNS-like key >> repositories a la DKIM or perhaps a small number (compared to the = number of >> TNs) of certificates are far more practical. >>=20 >> Regards, >>=20 >> Alex >>=20 >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >> Sent: Monday, July 27, 2015 7:40 PM >> To: Richard Barnes >> Cc: stir@ietf.org >> Subject: Re: [stir] On OCSP, TNs, and Privacy >>=20 >> What this means in practice is that it=E2=80=99s TN per cert. >>=20 >> I wouldn=E2=80=99t say that it=E2=80=99s impossible for a carrier to = maintain dozens >> of copies of millions of private keys securely, but it=E2=80=99s = hard. You >> need multiple copies because you have multiple elements that can >> initiate a call, and you don=E2=80=99t want to depend on a = centralized >> resource to do something as basic as create a call. >>=20 >> I think it=E2=80=99s hard enough that REQUIRING cert per TN is not = acceptable. >>=20 >> Folks with more intimate knowledge of carrier SIP infrastructure >> might have more insight than I do. It may be acceptable to have a >> centralized resource to manage millions of keys. >>=20 >> Brian >>=20 >> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>=20 >> After the STIR meeting in Prague, Henning and I spent a few minutes >> talking through options for revocation checking and certificate >> scoping, and I think we have a better idea of what the optimal >> solution looks like. Some notes are below, and some slides with >> pictures attached. >>=20 >> tl;dr: We should: >> * Keep TNs in certificates and not bother with any OCSP extensions >> * Require Identity-Info to include OCSP responses for all certs in >> the chain >>=20 >>=20 >> # Background: Revocation in the web PKI >>=20 >> In an HTTPS transaction, the HTTPS server provides the client with >> a certificate, and it can optionally include an OCSP response = ("staple" >> it to the transaction). >>=20 >> A certificate contains a validity interval, a key, and some = names/TNs. >> An OCSP responses contains a validity interval, a certificate ID >> (i.e., a hash), and a status (good/revoked/unknown). In the web >> PKI, certificates are required to be no more than 39 months long, >> and OCSP responses no more than 10 days. >>=20 >> Ideally, a client only considers a certificate valid if it is >> accompanied by an OCSP response. In practice, this is not always >> possible; because OCSP queries fail around 3% of the time, browsers >> can't require OCSP. This operational fact will be important below, >> but we will continue to have scoping cert lifetimes as an objective. >>=20 >> In the web PKI, there are basically three revocation checking = modalities: >>=20 >> 1. Live OCSP checking [RFC6069] >> 2. OCSP stapling / must_staple [RFC6066, >> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >> lifetime) >>=20 >> (The last of these is relatively novel, and has not been deployed. >> Neither has must-staple. But they're both pretty trivial, and >> could be folded into a STIR architecture pretty easily.) >>=20 >> Right now, about 90% of TLS transactions use live OCSP, and about = 10%. >> CAs and browsers dearly want the world to move toward stapled OCSP >> or short-lived certs, because these reduces latency and improve the >> quality of revocation information. >>=20 >> Revocation for CA certificates is currently done by having browsers >> download a list from a centralized server, since there's no way to >> staple more than one OCSP response. That solution works OK for the >> web, but if I were designing something de novo, I would probably >> use multi-stapling as well. >>=20 >>=20 >> # Applying this experience to STIR >>=20 >> Most of the below appear to be desired properties by the WG: >>=20 >> * Verifier neeeds to know that a cert is valid for a specific >> number >> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >> issued longer) >> * Caller privacy: Don't report what calls someone receives to a >> central server >> * Carrier privacy: Don't allow a third party to figure out all the >> numbers a carrier holds >> * Minimize the rate at which the CA has to sign things >> * Tolerate outages at the CA >>=20 >> I'm going to assume for now that we will not do live OCSP. It >> violates the caller privacy requirement, and as discussed above, it >> just sucks operationally. So STIR should require OCSP to be sent >> in "stapled" form, which probably means sending it in Identity-Info. >> And while we're at it, we should also do "multi-stapling" -- send >> an OCSP response for CA certs as well. >>=20 >> So if we consider a server with 50k TNs / blocks, that leaves us >> with basically 3 options: >>=20 >> 1. 50k short-lived certs (no OCSP) >> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 >> long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >> with TN info >>=20 >> (As I didn't quite get to say in the meeting, regardless of the >> approach, you have to have 50k of *something*.) Of these, it seems >> like the preference order is 2 > 1 > 3. >>=20 >> Option 3 is bad from several perspectives: >> * Putting TN info in the OCSP response enables someone to trawl for >> numbers unless you access-control the OCSP server, so you inherit a >> requirement to do that. >> * With the rate of churn in number assignments, you're probably >> going to have to update the long-lived cert pretty frequently anyway. >> * Putting TN-specific stuff in certs is better than putting it in >> OCSP. As bad as X.509 libraries can be, OCSP libraries are much >> worse. >>=20 >> Option 1 is mainly bad from the perspective of CA load and outages. >> With Option 2, if the CA goes down, client can continue to use the >> long-lived cert and just not bother doing OCSP (vs. tolerating an >> expired cert). Slightly cleaner. Plus, there's a lot more >> experience caching OCSP than new certs. OCSP signing can also be >> delegated, so you can have the recurring operation done by a = lower-risk key. >>=20 >> Option 2 should be pretty easy to automate. You can probably >> re-use tooling for OCSP stapling that has already been developed >> for use with HTTPS. If you're a big box signing for a bunch of >> numbers, you do need to select the right cert and OCSP response for >> a given call, but that's a pretty simple lookup table. >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=20 >> ________________________________ >>=20 >> This e-mail may contain Sprint proprietary information intended for = the sole >> use of the recipient(s). Any use by others is prohibited. If you are = not the >> intended recipient, please contact the sender and delete all copies = of the >> message. >>=20 >>=20 >> ________________________________ >>=20 >> This e-mail may contain Sprint proprietary information intended for = the sole >> use of the recipient(s). Any use by others is prohibited. If you are = not the >> intended recipient, please contact the sender and delete all copies = of the >> message. >> _______________________________________________ >> 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 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=20 From nobody Tue Jul 28 19:07:31 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385101A1B5A for ; Tue, 28 Jul 2015 19:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 76AmJoJtIqzb for ; Tue, 28 Jul 2015 19:07:27 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id EFB5F1A1B59 for ; Tue, 28 Jul 2015 19:07:26 -0700 (PDT) Received: (qmail 1068 invoked by uid 0); 29 Jul 2015 02:07:25 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 29 Jul 2015 02:07:25 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id y1nF1q00f1MNPNq011nJjg; Tue, 28 Jul 2015 19:47:23 -0600 X-Authority-Analysis: v=2.1 cv=O9qq4nNW c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=N7-_X-PFAAAA:8 a=zQP7CpKOAAAA:8 a=VfgTrTGYAAAA:8 a=HLLxP2VMAAAA:8 a=izV7ms69AAAA:8 a=0pPj3hHQnHfLbYAIOaQA:9 a=jV0tfMMF-RLq_ghK:21 a=tAh4Jrgy399YKpU9:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=DzjOOp_o1eYA:10 a=-h7pEDzCGw4A:10 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; bh=oiXT6MBHzw61Ntn1k6rkFS/hagWiXG823iEaM8d/mz8=; b=K+314sRBkJm6SesjO+PwO9I5ZSIJRgAwjT2Cee1b9CichuXMYgIDfWOYaeYtbq9Qe9x2Bi2dBUq0J6JBxjNgbvb+q9iLjlklkX2S52uQHXe58Rrnp6t/7K5CdFwHUBQx; Received: from [100.36.26.202] (port=49246 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZKGSj-0004e4-9R; Tue, 28 Jul 2015 19:47:17 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Tue, 28 Jul 2015 21:47:12 -0400 From: Richard Shockey To: Richard Barnes Message-ID: Thread-Topic: [stir] On OCSP, TNs, and Privacy References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 02:07:30 -0000 Richard. That is the core problem here. As far as some of us believe there are no silver bullets and STIR in itself is not the ultimate solution. It was in the beginning a multifaceted problem. We knew that the goal was to suppress the problem sufficiently in order to restore public confidence in the system. Perfection is not the goal. Goodness knows I don=E2=80=99t think ENUM is now the solution for database distrbution. The model to be sure but we have much better tools and HTTPS now for distributed databases. Focus on tools and not policy. On 7/28/15, 6:57 PM, "stir on behalf of Richard Barnes" wrote: >On Tue, Jul 28, 2015 at 6:30 PM, Richard Shockey >wrote: >> >> Richard .. Be reasonable here its not a perfect world and IETF >>protocols, > >You are correct that if we build a putative security solution based on >public keys passed DNS, it will not be an IETF protocol. It will not >become an RFC because it will not meet the IETF's security standards. > >And in any case, it's not that much harder to do the really secure >thing. Even if you want a central registry, do it over HTTPS, and >it'll be just as fast and 100% more secure. > >--Richard > > >> especially its security protocols are not perfect. At some point the >> limited competency of the IETF will move into the realm of policy. >> >> In the US that means the usual suspects will have to weigh in. ATIS INC, >> the NANC,FCC. Its only a matter of time this ends up being a FCC Docket. >> This is not to say engineering concerns do not drive policy, far from it >> look at spectrum issues for instance. >> >> But its their [FCC CRTC OFCOM ART BeNetA FICORA) numbers and we (IETF) >>do >> not dictate policy. Only offer options. >> >> >> =E2=80=B9 >> Richard Shockey >> Shockey Consulting LLC >> Chairman of the Board SIP Forum >> www.shockey.us >> www.sipforum.org >> richardshockey.us >> Skype-Linkedin-Facebook rshockey101 >> PSTN +1 703-593-2683 >> >> >> >> >> >> On 7/28/15, 4:06 PM, "stir on behalf of Richard Barnes" >> wrote: >> >>>http://www.afldreamers.com/wp-content/uploads/2014/01/why-not-have-both- >>>30 >>>0x187.png >>> >>>You could have a database of certs+OCSP responses as an optimization. >>>IIRC, Identity-Info only has pointers to certs anyway. >>> >>>On Tue, Jul 28, 2015 at 3:13 PM, PFAUTZ, PENN L wrote: >>>> Forgive me but my reptile brain keeps whispering in my ear that this >>>>would be a lot easier if we simply had a numbering registry, whether >>>>distributed or centralized - like we need anyway for at least for >>>>number >>>>portability - that also contained the public keys. No tedious mucking >>>>about in cyberspace with certs, CRLs, or OCSP. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning >>>>Schulzrinne >>>> Sent: Tuesday, July 28, 2015 10:24 AM >>>> To: Gorman, Pierce A [CTO] >>>> Cc: stir@ietf.org >>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>> >>>> In the US alone, we have about 4000 carriers. Managing the reputation >>>>of that many entities, reliably (i.e., without making false >>>>positive/negative mistakes) seems a whole lot more manual effort than >>>>storing bags of bits. Storage and automation is cheap, human judgement >>>>and dealing with mistakes is expensive. >>>> >>>> Obviously, nothing in the architecture prevents wildcard certificates. >>>> >>>> -----Original Message----- >>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce >>>>A >>>>[CTO] >>>> Sent: Tuesday, July 28, 2015 10:14 AM >>>> To: Richard Barnes >>>> Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen >>>> >>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>> >>>> I thought the discussion was on key/cert management. I'm asking if I >>>>understood the suggestion to minimize requirements. How is that off >>>>topic? >>>> >>>> Best regards, >>>> >>>> >>>> Pierce Gorman >>>> Core Network Planning >>>> O: 913-439-4368 >>>> pierce.gorman@sprint.com >>>> >>>> >>>> -----Original Message----- >>>> From: Richard Barnes [mailto:rlb@ipv.sx] >>>> Sent: July 28, 2015 9:12 AM >>>> To: Gorman, Pierce A [CTO] >>>> Cc: Alex Bobotek ; Brian Rosen ; >>>>stir@ietf.org >>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>> >>>> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] >>>> wrote: >>>>> "Large scale certificate management is expensive, and TN-specific >>>>>certificates are unneeded for securing calls placed by parties who >>>>>choose to place calls through a single reputable telephone service >>>>>provider." >>>>> >>>>> Are you saying that for "on-net" calls, STIR methodology is >>>>>unnecessary? >>>> >>>> This seems a little off-topic for this list. >>>> >>>> --Richard >>>> >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Pierce Gorman >>>>> Core Network Planning >>>>> O: 913-439-4368 >>>>> pierce.gorman@sprint.com >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Alex Bobotek [mailto:alex@bobotek.net] >>>>> Sent: July 27, 2015 11:36 PM >>>>> To: Brian Rosen ; Richard Barnes >>>>> Cc: stir@ietf.org >>>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>>> >>>>> What motivation would a carrier have to choose any model other than >>>>>carrier signing using one of a very limited set of carrier-owned keys? >>>>>Large scale certificate management is expensive, and TN-specific >>>>>certificates are unneeded for securing calls placed by parties who >>>>>choose to place calls through a single reputable telephone service >>>>>provider. Anyone can get many certificates, even a free ones >>>>>anonymously from some issuers. It is typically a combination of the >>>>>strength of the end-user authentication performed by the service >>>>>provider (or certificate issuer in a provider-agnostic model) and the >>>>>identity's history that are most useful in security. >>>>> >>>>> If we're trying to secure the current telephone system, DNS-like key >>>>>repositories a la DKIM or perhaps a small number (compared to the >>>>>number of TNs) of certificates are far more practical. >>>>> >>>>> Regards, >>>>> >>>>> Alex >>>>> >>>>>> -----Original Message----- >>>>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>>>>> Sent: Monday, July 27, 2015 7:40 PM >>>>>> To: Richard Barnes >>>>>> Cc: stir@ietf.org >>>>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>>>> >>>>>> What this means in practice is that it=C2=B9s TN per cert. >>>>>> >>>>>> I wouldn=C2=B9t say that it=C2=B9s impossible for a carrier to maintain doze= ns >>>>>> of copies of millions of private keys securely, but it=C2=B9s hard. You >>>>>> need multiple copies because you have multiple elements that can >>>>>> initiate a call, and you don=C2=B9t want to depend on a centralized >>>>>> resource to do something as basic as create a call. >>>>>> >>>>>> I think it=C2=B9s hard enough that REQUIRING cert per TN is not >>>>>>acceptable. >>>>>> >>>>>> Folks with more intimate knowledge of carrier SIP infrastructure >>>>>> might have more insight than I do. It may be acceptable to have a >>>>>> centralized resource to manage millions of keys. >>>>>> >>>>>> Brian >>>>>> >>>>>> > On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>>>>> > >>>>>> > After the STIR meeting in Prague, Henning and I spent a few >>>>>>minutes >>>>>> > talking through options for revocation checking and certificate >>>>>> > scoping, and I think we have a better idea of what the optimal >>>>>> > solution looks like. Some notes are below, and some slides with >>>>>> > pictures attached. >>>>>> > >>>>>> > tl;dr: We should: >>>>>> > * Keep TNs in certificates and not bother with any OCSP extensions >>>>>> > * Require Identity-Info to include OCSP responses for all certs in >>>>>> > the chain >>>>>> > >>>>>> > >>>>>> > # Background: Revocation in the web PKI >>>>>> > >>>>>> > In an HTTPS transaction, the HTTPS server provides the client with >>>>>> > a certificate, and it can optionally include an OCSP response >>>>>>("staple" >>>>>> > it to the transaction). >>>>>> > >>>>>> > A certificate contains a validity interval, a key, and some >>>>>>names/TNs. >>>>>> > An OCSP responses contains a validity interval, a certificate ID >>>>>> > (i.e., a hash), and a status (good/revoked/unknown). In the web >>>>>> > PKI, certificates are required to be no more than 39 months long, >>>>>> > and OCSP responses no more than 10 days. >>>>>> > >>>>>> > Ideally, a client only considers a certificate valid if it is >>>>>> > accompanied by an OCSP response. In practice, this is not always >>>>>> > possible; because OCSP queries fail around 3% of the time, >>>>>>browsers >>>>>> > can't require OCSP. This operational fact will be important >>>>>>below, >>>>>> > but we will continue to have scoping cert lifetimes as an >>>>>>objective. >>>>>> > >>>>>> > In the web PKI, there are basically three revocation checking >>>>>>modalities: >>>>>> > >>>>>> > 1. Live OCSP checking [RFC6069] >>>>>> > 2. OCSP stapling / must_staple [RFC6066, >>>>>> > draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>>>>> > lifetime) >>>>>> > >>>>>> > (The last of these is relatively novel, and has not been deployed. >>>>>> > Neither has must-staple. But they're both pretty trivial, and >>>>>> > could be folded into a STIR architecture pretty easily.) >>>>>> > >>>>>> > Right now, about 90% of TLS transactions use live OCSP, and about >>>>>>10%. >>>>>> > CAs and browsers dearly want the world to move toward stapled OCSP >>>>>> > or short-lived certs, because these reduces latency and improve >>>>>>the >>>>>> > quality of revocation information. >>>>>> > >>>>>> > Revocation for CA certificates is currently done by having >>>>>>browsers >>>>>> > download a list from a centralized server, since there's no way to >>>>>> > staple more than one OCSP response. That solution works OK for >>>>>>the >>>>>> > web, but if I were designing something de novo, I would probably >>>>>> > use multi-stapling as well. >>>>>> > >>>>>> > >>>>>> > # Applying this experience to STIR >>>>>> > >>>>>> > Most of the below appear to be desired properties by the WG: >>>>>> > >>>>>> > * Verifier neeeds to know that a cert is valid for a specific >>>>>> > number >>>>>> > * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >>>>>> > issued longer) >>>>>> > * Caller privacy: Don't report what calls someone receives to a >>>>>> > central server >>>>>> > * Carrier privacy: Don't allow a third party to figure out all the >>>>>> > numbers a carrier holds >>>>>> > * Minimize the rate at which the CA has to sign things >>>>>> > * Tolerate outages at the CA >>>>>> > >>>>>> > I'm going to assume for now that we will not do live OCSP. It >>>>>> > violates the caller privacy requirement, and as discussed above, >>>>>>it >>>>>> > just sucks operationally. So STIR should require OCSP to be sent >>>>>> > in "stapled" form, which probably means sending it in >>>>>>Identity-Info. >>>>>> > And while we're at it, we should also do "multi-stapling" -- send >>>>>> > an OCSP response for CA certs as well. >>>>>> > >>>>>> > So if we consider a server with 50k TNs / blocks, that leaves us >>>>>> > with basically 3 options: >>>>>> > >>>>>> > 1. 50k short-lived certs (no OCSP) >>>>>> > 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 >>>>>> > long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >>>>>> > with TN info >>>>>> > >>>>>> > (As I didn't quite get to say in the meeting, regardless of the >>>>>> > approach, you have to have 50k of *something*.) Of these, it >>>>>>seems >>>>>> > like the preference order is 2 > 1 > 3. >>>>>> > >>>>>> > Option 3 is bad from several perspectives: >>>>>> > * Putting TN info in the OCSP response enables someone to trawl >>>>>>for >>>>>> > numbers unless you access-control the OCSP server, so you inherit >>>>>>a >>>>>> > requirement to do that. >>>>>> > * With the rate of churn in number assignments, you're probably >>>>>> > going to have to update the long-lived cert pretty frequently >>>>>>anyway. >>>>>> > * Putting TN-specific stuff in certs is better than putting it in >>>>>> > OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>>>>> > worse. >>>>>> > >>>>>> > Option 1 is mainly bad from the perspective of CA load and >>>>>>outages. >>>>>> > With Option 2, if the CA goes down, client can continue to use the >>>>>> > long-lived cert and just not bother doing OCSP (vs. tolerating an >>>>>> > expired cert). Slightly cleaner. Plus, there's a lot more >>>>>> > experience caching OCSP than new certs. OCSP signing can also be >>>>>> > delegated, so you can have the recurring operation done by a >>>>>>lower-risk key. >>>>>> > >>>>>> > Option 2 should be pretty easy to automate. You can probably >>>>>> > re-use tooling for OCSP stapling that has already been developed >>>>>> > for use with HTTPS. If you're a big box signing for a bunch of >>>>>> > numbers, you do need to select the right cert and OCSP response >>>>>>for >>>>>> > a given call, but that's a pretty simple lookup table. >>>>>> > _______________________________________________ >>>>>> > 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 >>>>> >>>>> ________________________________ >>>>> >>>>> This e-mail may contain Sprint proprietary information intended for >>>>>the sole use of the recipient(s). Any use by others is prohibited. If >>>>>you are not the intended recipient, please contact the sender and >>>>>delete all copies of the message. >>>> >>>> ________________________________ >>>> >>>> This e-mail may contain Sprint proprietary information intended for >>>>the >>>>sole use of the recipient(s). Any use by others is prohibited. If you >>>>are not the intended recipient, please contact the sender and delete >>>>all >>>>copies of the message. >>>> _______________________________________________ >>>> 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 >>>> _______________________________________________ >>>> 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 >> >> > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jul 28 19:58:29 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE48B1B353B for ; Tue, 28 Jul 2015 19:58:27 -0700 (PDT) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ar-EWZzqJfaw for ; Tue, 28 Jul 2015 19:58:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB131B34EA for ; Tue, 28 Jul 2015 19:58:19 -0700 (PDT) Received: from BL2FFO11FD041.protection.gbl (10.173.160.33) by BL2FFO11HUB038.protection.gbl (10.173.160.242) with Microsoft SMTP Server (TLS) id 15.1.231.11; Wed, 29 Jul 2015 02:58:03 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.81) smtp.mailfrom=sprint.com; att.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.81 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.81; helo=preapdm2.corp.sprint.com; Received: from preapdm2.corp.sprint.com (144.230.32.81) by BL2FFO11FD041.mail.protection.outlook.com (10.173.161.137) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Wed, 29 Jul 2015 02:58:03 +0000 Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6T2uild013786; Tue, 28 Jul 2015 22:58:03 -0400 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by preapdm2.corp.sprint.com with ESMTP id 1vxgn3j83y-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2015 22:58:03 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 28 Jul 2015 22:58:02 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Tue, 28 Jul 2015 21:58:01 -0500 From: "Gorman, Pierce A [CTO]" To: Chris Wendt Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3w5jYQgABaDoD//6yTMIAAuw5wgABV0ICAAAOeAIAAAjiAgAABtYD//70y0w== Date: Wed, 29 Jul 2015 02:58:00 +0000 Message-ID: <44D8CE23-4291-4463-91E5-E4C648EEF873@sprint.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <8C8D48CD-F4A8-4160-A5A7-594DF61A9B60@chriswendt.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD041; 1:s/vt5V4cRo2eHBMjVEovUfjacY3mD6rT4gzEPRPWujusNfjqNqtWiCrlt3SEpkYCZQi5agtQ1s1Qcond9CdRYrOvDoazJyJRx7B0jtx4l5EnuwoMMPLH3Mctu7NMhjLec8mYzK7IT+Ru40/aibBX1VbqDPhdewkpRMNdhYdu5S00ZrHNS/5f5bhYmntQbX+cDU67JS74c0hJNxODykwnhL3y/wIdRd2xB/OattboPFh54lDqOvMOJo+Z478m63jh9hs8RJe43BiqhtH3TQjSWCv7GHDe27XBRA7gCnJi1zNVOTPlw2sqDtP2L1iT5Od7 X-Forefront-Antispam-Report: CIP:144.230.32.81; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(13464003)(377454003)(24454002)(189002)(199003)(50986999)(82746002)(76176999)(102836002)(15975445007)(83716003)(36756003)(19580395003)(47776003)(6806004)(19580405001)(33656002)(50466002)(106116001)(62966003)(5890100001)(110136002)(2900100001)(86362001)(5001920100001)(23746002)(93886004)(46102003)(87936001)(2656002)(106466001)(5003600100002)(54356999)(2950100001)(189998001)(92566002)(5003630100001)(77156002)(5001960100002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB038; H:preapdm2.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 2:qdQyfzJEvTFSCDIlBmTbsjuCbJ+JP/s9A1L1RNJ30mpzruqbCVZX88ZW8q9WbVAfsM92maOB+1LsC/Hs7ai398UxWoXgmCqR0CTn8rG/iWFe0R2zDrLgk7qm22ot606DdTTTWbGRDqPMJfijug9vGdJ1H7hrqe/YOkmghQqHwjU=; 3:2uGX8SRo20OQ6sADPZpxVE3++5WJOjYR1Do1z5X91u9aEFbb0JpoW7KPHA63EGoMhU1H/cQE+MyUBRZxGGRXDRj2D7FaIPZ1LggbMq54g9OtfQVoQNzLIatJD+4uJUk+l33zC/rQ4hrq6tp1l7EIa4FdaaheRWH7UhKifqEfHQ/sdQ3a8WUzs1BqeWsOusPNAATcKlIjRDFIxw2nMNxUbJ6HEMbLyh892XU0Z/T9aY4=; 25:cx1t3ADCcl1ZLi9i4GkdkXdMuIiJjFZuqzzmgin/QxjR+13JHF8Pu/0w4teZcV0D1lti+aKV5Nnx2B+9dAtClKpqx/b7qXYlmUUj6EDfscxHsxzoSvFnkXFFrBxybYGmS5/GQuRj5LA16BPxSTweLcWvr/o9uoypfI+5K0zc3MeaDmspZZak9RdBLniAnoZfdn7kH1u+s0tDLMAfrlcjOsu7KeWuTiQEcDkPZp+6J8FvkS6QZX2CAS+L5DRldA4KEHabyUpHLBgg3foM8o5sGQ==; 20:4fEY+7XKYLsBRQuJz2zBQd5+vXPEgQZ5/yCXWRbaD3Cre9HBoQbHjsKWxfqqiJ8qQ1LWT31b2n9ufr+kY12pbyMw2rutB+G/gaWzNxkizxK/5aKaxfIbgPxB5p8j1etk+93kRW7J4Bv1jWzljuGHaMdFRRLTv4x11Q31dbFXlnvZDNyU811he1lXsTbQpT9fn+HF4BBcb/TZGOfs7DOH8KNjhm+BftvYIbIr3uQgMmxH1CbDgsDvyFdJvQjKLfBH X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB038; BL2FFO11HUB038: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BL2FFO11HUB038; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB038; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 4:oOx6defsLe8BmHlGCwX5c0mB8fD3BlqbmpKqsfs0bsRJN/G2sXOxclpLJSpR7MrmRX7IOPJeaTak7jeBn+fefEATBD2H43eh8y3+10O/PpJR5Wy98I8fWK5fpC88RZWuY1KdqnYS40a6XMrB4qds36fIeyABZnZoAjqhZihJMWdNA65hNSeo7znYWFIMKqkYtBdv8p7tJaNJPpM7cgVhyWSZU0k1+OyMLVS77r0pXodoIS814feqj7+uNP+SymsA2ZKCGMU9wrjgJXxVkp8BWSOfdZsLYP+4ODAlua00IJE= X-Forefront-PRVS: 0652EA5565 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BL2FFO11HUB038; 23:RV0HlfEJM+A3GuWAVC7CnNoErBzXv0525miG?= =?Windows-1252?Q?51RpE/uS8LqBb1c0GgpGiGKsZOwLSRdta9tjorTtB6L9U8vuGbM0wJCn?= =?Windows-1252?Q?HqU4XZkwhKIgTvJTFEUP0CsIagZ04CTijbThw3axP7K4vJktLRr62kZQ?= =?Windows-1252?Q?1eHjKJhlECrz/CWSq3jEOzYPpcI7KxYTyDYeTUGwBlS6ATOgAvekrHr9?= =?Windows-1252?Q?s+F6TSik+0ywv5CB8qsC1/Val9sx4lDio4zKhcVNrWcHK868Me4LRAP0?= =?Windows-1252?Q?iOE5+J4Vj3+f9ANTyRszmCFCUd1hJMTdXAWXxDkvFV9u4NmDqA35Ik1V?= =?Windows-1252?Q?b4dngRvO51oXi7ZnCnYAdcJ0M5gNMLpP2i3tDBwmzdezqBDafQHLieKO?= =?Windows-1252?Q?3NQs6IWxk4zL6uRRAifBLcGiHOSm+/i9jhybn8Z/HIfW2UqiGeCQ9Ua2?= =?Windows-1252?Q?p6COgdgDh1nVXbbwXQEv08vQF+ZEcdGtxgIGkDGiGHzbIOHbbxTqeyCi?= =?Windows-1252?Q?BeQi0Ru0B1FEnZ5ERBZDA94alRH4eK+dscMOTyV9IefMmFRuhvuEyTWY?= =?Windows-1252?Q?TsIeR9ZptlY4NU7fzXRMvOhRYpQ8d8jnxcbO41RfwcLQqvJLgwX9SYEl?= =?Windows-1252?Q?BlVZSS/DKcti3kubxk4Xcn1NeCBCqA4XKBkjKf4PVCo410vgHTmCMds7?= =?Windows-1252?Q?pn1MOJgiqTIfXQWfCwdLt2/Ev4PP2TtXo/rD2/PMPvcKy682Niom7LaS?= =?Windows-1252?Q?F7giFg7cue6g8eYuTwBW+Go1nvs1usoT/JOrv4L3pn17NHD2hnKEvhX2?= =?Windows-1252?Q?5uOIbX8knnf+bnFV7HaBgNpKmPwwKkiE/cPzVDi2BzLrcRpqA7NPV/1q?= =?Windows-1252?Q?ipfGYQeVFfEGffVA9uwJKUJNE44bay9T1JtmruPxTHLOwoxtalDYZ2y5?= =?Windows-1252?Q?dDSBNZTCOd/KFiNVFwyZRUjZ3ZtkTEc7bVWIs/2l3MCTWGrQskScv+KO?= =?Windows-1252?Q?y0zQEUXvJxOUUYUTal1qpURv9GWzHaCS1ykGPr87F2ylbcx0F/IQbj0o?= =?Windows-1252?Q?OyxbEVGX1jnuseDiuMw16y4N0NS0tpYAB623PPNb0nWzIE0ixex4oBqZ?= =?Windows-1252?Q?CyiOAIcLs3pt6qv1PsVgONBaseRBWmozVx1npFVkiJY4+YKOFC6uIG5C?= =?Windows-1252?Q?Bm+hYUwq99GQCM/QEzktKLJPZTqDMaP3I2o0qdncViT+QvAgVBb6?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB038; 5:ZkQ/TOWz7RdEBf+Fj83IFB/ltgIe+I2peVGXco54hdDkwQZZQRhmC72P1RzYHCi4j7ST3fsLoscvW6e6PAeCe8NNd5KbCbwitTWAFuw405B9CHCwCav6B8PLupDgYYz4xqmkW1v75+Nr+38kBgMXag==; 24:v0UNiaWbd03RbJguOw/YrU24IRK52SEP8c28S+FR+WMuZo8RWEOjn87aooyzh+63M2Iqjtxi87R6xTVqBnkE6Cf44yd4leet6KjRrZj4oFY= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2015 02:58:03.5653 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.81]; Helo=[preapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB038 Archived-At: Cc: Richard Barnes , "stir@ietf.org" , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 02:58:27 -0000 I assume in practice there will be billions of communication endpoints (in = the discussion they've been referred to as phones, but laptops, tablets, to= asters, cars, M2M/IoT are also candidates) which may authenticate calling n= umber in situ, and others which may have authenticated information proxied = to them (over a secure communications channel?), and not necessarily using = SIP (think WebRTC) or HTML. Computing power and time is cheaper in the core as compared to endpoints. = More signaling messages and dips are bad as compared to less signaling and = dips. There are always trade-offs and the safe thing to assume is don't assume an= ything (with regard to centralized or distributed, cached or dipped). Sent from my iPad > On Jul 28, 2015, at 8:57 PM, Chris Wendt wrot= e: > > Depends on your perspective. > > I would suspect we would both agree that =93phones querying the numbering= authority registry" is not the problem statement we are working towards, f= or very different reasons. > > >> On Jul 28, 2015, at 9:51 PM, Richard Barnes wrote: >> >> On Tue, Jul 28, 2015 at 9:43 PM, Chris Wendt = wrote: >>> Henning discussed an example at the modern meeting. Gossip based >>> distributed mechanisms can be used. >>> >>> I=92m curious what you mean by unbounded, in terms of numbers? >>> 1k/10k/100k/1M? >> >> How many phones are there out there? "end systems must be able to >> validate the source identity information." >> >> >>> DNS is a much more brute force mechanism for a distributed system but y= et it >>> propagates things pretty quickly globally. >>> >>> 4474bis if i remember correctly even mentions the fact that we will nee= d to >>> store multiple historical certificate records and references (maybe 2 i= s >>> enough in practice) in order to mitigate delays in propagation of new >>> certificates. >>> >>> I don=92t see the issue. >> >> The point is that when my phone gets a call it needs to be able to >> verify the caller's authorization. The Identity-Info signature binds >> the call to the caller's public key. So the my phone needs to verify >> that the public key is authorized. >> >> If I understand you correctly, you're proposing that my phone needs to >> sync down a giant database of which public keys are authorized for >> which numbers, or it needs to call out to some registry it trusts, >> which needs to be online all the time. >> >> Those both seem far worse than my phone just having to look up a >> certificate, or verify one that was included in the INVITE directly. >> The only cost of on the signer side is that the signer has to pick the >> right cert to send, which, as I said before, is just a hash table >> lookup. >> >> --Richard >> >>> >>> >>> On Jul 28, 2015, at 9:30 PM, Richard Barnes wrote: >>> >>> On Tue, Jul 28, 2015 at 9:22 PM, Chris Wendt >>> wrote: >>> >>> If the registry is distributed, and the certificate dip is local to the >>> provider, the numbering authority isn=92t in the middle of each call, o= ne of >>> the points we are advocating in general, in terms of making this scalab= le >>> and =93deployable=94. >>> >>> >>> Do you happen to have a good standard technology on hand for >>> synchronizing a database across a potentially unbounded set of >>> signers/verifiers? I don't think we can assume that that set of >>> actors is limited to the set of "providers", for any definition of >>> that term. For so it is written in RFC 7340: >>> >>> """ >>> Generation: Intermediaries as well as end systems must be able to >>> generate the source identity information. >>> >>> Validation: Intermediaries as well as end systems must be able to >>> validate the source identity information. >>> """ >>> >>> If you're going to meet that requirement, I think your distributed >>> registry ends up looking far more complex than just passing around >>> certificates. >>> >>> Of course, if you're just talking about a signer looking up what cert >>> it should use, then we agree; that's just what I meant when I said >>> that managing multiple certs is just a hash table lookup. >>> >>> --Richard >>> >>> >>> >>> >>> On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne >>> wrote: >>> >>> That was certainly one of the models that have been discussed in the pa= st. >>> Particularly for small carriers, this would likely reduce the operation= al >>> impact to a configuration option in the SBC. >>> >>> The disadvantage of this model is caller privacy: If the cert is stored= at a >>> numbering authority, it would be easy for that authority to know which >>> carrier is receiving calls from whom. (It's not the complete meta data = since >>> it's lacking the callee information.) >>> >>> However, unless the TN-to-LRN (in the US) mapping is cached, this "leak= " >>> already exists today. >>> >>> -----Original Message----- >>> From: PFAUTZ, PENN L [mailto:pp3129@att.com] >>> Sent: Tuesday, July 28, 2015 3:14 PM >>> To: Henning Schulzrinne ; Gorman, Pierce A >>> [CTO] >>> Cc: stir@ietf.org >>> Subject: RE: [stir] On OCSP, TNs, and Privacy >>> >>> Forgive me but my reptile brain keeps whispering in my ear that this wo= uld >>> be a lot easier if we simply had a numbering registry, whether distribu= ted >>> or centralized - like we need anyway for at least for number portabilit= y - >>> that also contained the public keys. No tedious mucking about in cybers= pace >>> with certs, CRLs, or OCSP. >>> >>> >>> >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzri= nne >>> Sent: Tuesday, July 28, 2015 10:24 AM >>> To: Gorman, Pierce A [CTO] >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> In the US alone, we have about 4000 carriers. Managing the reputation o= f >>> that many entities, reliably (i.e., without making false positive/negat= ive >>> mistakes) seems a whole lot more manual effort than storing bags of bit= s. >>> Storage and automation is cheap, human judgement and dealing with mista= kes >>> is expensive. >>> >>> Obviously, nothing in the architecture prevents wildcard certificates. >>> >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Gorman, Pierce A >>> [CTO] >>> Sent: Tuesday, July 28, 2015 10:14 AM >>> To: Richard Barnes >>> Cc: stir@ietf.org; Alex Bobotek ; Brian Rosen >>> >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> I thought the discussion was on key/cert management. I'm asking if I >>> understood the suggestion to minimize requirements. How is that off to= pic? >>> >>> Best regards, >>> >>> >>> Pierce Gorman >>> Core Network Planning >>> O: 913-439-4368 >>> pierce.gorman@sprint.com >>> >>> >>> -----Original Message----- >>> From: Richard Barnes [mailto:rlb@ipv.sx] >>> Sent: July 28, 2015 9:12 AM >>> To: Gorman, Pierce A [CTO] >>> Cc: Alex Bobotek ; Brian Rosen ; >>> stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] >>> wrote: >>> >>> "Large scale certificate management is expensive, and TN-specific >>> certificates are unneeded for securing calls placed by parties who choo= se to >>> place calls through a single reputable telephone service provider." >>> >>> Are you saying that for "on-net" calls, STIR methodology is unnecessary= ? >>> >>> >>> This seems a little off-topic for this list. >>> >>> --Richard >>> >>> >>> Best regards, >>> >>> >>> Pierce Gorman >>> Core Network Planning >>> O: 913-439-4368 >>> pierce.gorman@sprint.com >>> >>> >>> -----Original Message----- >>> From: Alex Bobotek [mailto:alex@bobotek.net] >>> Sent: July 27, 2015 11:36 PM >>> To: Brian Rosen ; Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> What motivation would a carrier have to choose any model other than car= rier >>> signing using one of a very limited set of carrier-owned keys? Large sc= ale >>> certificate management is expensive, and TN-specific certificates are >>> unneeded for securing calls placed by parties who choose to place calls >>> through a single reputable telephone service provider. Anyone can get = many >>> certificates, even a free ones anonymously from some issuers. It is >>> typically a combination of the strength of the end-user authentication >>> performed by the service provider (or certificate issuer in a >>> provider-agnostic model) and the identity's history that are most usefu= l in >>> security. >>> >>> If we're trying to secure the current telephone system, DNS-like key >>> repositories a la DKIM or perhaps a small number (compared to the numbe= r of >>> TNs) of certificates are far more practical. >>> >>> Regards, >>> >>> Alex >>> >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen >>> Sent: Monday, July 27, 2015 7:40 PM >>> To: Richard Barnes >>> Cc: stir@ietf.org >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>> >>> What this means in practice is that it=92s TN per cert. >>> >>> I wouldn=92t say that it=92s impossible for a carrier to maintain dozen= s >>> of copies of millions of private keys securely, but it=92s hard. You >>> need multiple copies because you have multiple elements that can >>> initiate a call, and you don=92t want to depend on a centralized >>> resource to do something as basic as create a call. >>> >>> I think it=92s hard enough that REQUIRING cert per TN is not acceptable= . >>> >>> Folks with more intimate knowledge of carrier SIP infrastructure >>> might have more insight than I do. It may be acceptable to have a >>> centralized resource to manage millions of keys. >>> >>> Brian >>> >>> On Jul 27, 2015, at 6:13 PM, Richard Barnes wrote: >>> >>> After the STIR meeting in Prague, Henning and I spent a few minutes >>> talking through options for revocation checking and certificate >>> scoping, and I think we have a better idea of what the optimal >>> solution looks like. Some notes are below, and some slides with >>> pictures attached. >>> >>> tl;dr: We should: >>> * Keep TNs in certificates and not bother with any OCSP extensions >>> * Require Identity-Info to include OCSP responses for all certs in >>> the chain >>> >>> >>> # Background: Revocation in the web PKI >>> >>> In an HTTPS transaction, the HTTPS server provides the client with >>> a certificate, and it can optionally include an OCSP response ("staple" >>> it to the transaction). >>> >>> A certificate contains a validity interval, a key, and some names/TNs. >>> An OCSP responses contains a validity interval, a certificate ID >>> (i.e., a hash), and a status (good/revoked/unknown). In the web >>> PKI, certificates are required to be no more than 39 months long, >>> and OCSP responses no more than 10 days. >>> >>> Ideally, a client only considers a certificate valid if it is >>> accompanied by an OCSP response. In practice, this is not always >>> possible; because OCSP queries fail around 3% of the time, browsers >>> can't require OCSP. This operational fact will be important below, >>> but we will continue to have scoping cert lifetimes as an objective. >>> >>> In the web PKI, there are basically three revocation checking modalitie= s: >>> >>> 1. Live OCSP checking [RFC6069] >>> 2. OCSP stapling / must_staple [RFC6066, >>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP >>> lifetime) >>> >>> (The last of these is relatively novel, and has not been deployed. >>> Neither has must-staple. But they're both pretty trivial, and >>> could be folded into a STIR architecture pretty easily.) >>> >>> Right now, about 90% of TLS transactions use live OCSP, and about 10%. >>> CAs and browsers dearly want the world to move toward stapled OCSP >>> or short-lived certs, because these reduces latency and improve the >>> quality of revocation information. >>> >>> Revocation for CA certificates is currently done by having browsers >>> download a list from a centralized server, since there's no way to >>> staple more than one OCSP response. That solution works OK for the >>> web, but if I were designing something de novo, I would probably >>> use multi-stapling as well. >>> >>> >>> # Applying this experience to STIR >>> >>> Most of the below appear to be desired properties by the WG: >>> >>> * Verifier neeeds to know that a cert is valid for a specific >>> number >>> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if >>> issued longer) >>> * Caller privacy: Don't report what calls someone receives to a >>> central server >>> * Carrier privacy: Don't allow a third party to figure out all the >>> numbers a carrier holds >>> * Minimize the rate at which the CA has to sign things >>> * Tolerate outages at the CA >>> >>> I'm going to assume for now that we will not do live OCSP. It >>> violates the caller privacy requirement, and as discussed above, it >>> just sucks operationally. So STIR should require OCSP to be sent >>> in "stapled" form, which probably means sending it in Identity-Info. >>> And while we're at it, we should also do "multi-stapling" -- send >>> an OCSP response for CA certs as well. >>> >>> So if we consider a server with 50k TNs / blocks, that leaves us >>> with basically 3 options: >>> >>> 1. 50k short-lived certs (no OCSP) >>> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 >>> long-lived cert not scoped to TN (or a few loosely scoped) + OCSP >>> with TN info >>> >>> (As I didn't quite get to say in the meeting, regardless of the >>> approach, you have to have 50k of *something*.) Of these, it seems >>> like the preference order is 2 > 1 > 3. >>> >>> Option 3 is bad from several perspectives: >>> * Putting TN info in the OCSP response enables someone to trawl for >>> numbers unless you access-control the OCSP server, so you inherit a >>> requirement to do that. >>> * With the rate of churn in number assignments, you're probably >>> going to have to update the long-lived cert pretty frequently anyway. >>> * Putting TN-specific stuff in certs is better than putting it in >>> OCSP. As bad as X.509 libraries can be, OCSP libraries are much >>> worse. >>> >>> Option 1 is mainly bad from the perspective of CA load and outages. >>> With Option 2, if the CA goes down, client can continue to use the >>> long-lived cert and just not bother doing OCSP (vs. tolerating an >>> expired cert). Slightly cleaner. Plus, there's a lot more >>> experience caching OCSP than new certs. OCSP signing can also be >>> delegated, so you can have the recurring operation done by a lower-risk= key. >>> >>> Option 2 should be pretty easy to automate. You can probably >>> re-use tooling for OCSP stapling that has already been developed >>> for use with HTTPS. If you're a big box signing for a bunch of >>> numbers, you do need to select the right cert and OCSP response for >>> a given call, but that's a pretty simple lookup table. >>> _______________________________________________ >>> 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 >>> >>> >>> ________________________________ >>> >>> This e-mail may contain Sprint proprietary information intended for the= sole >>> use of the recipient(s). Any use by others is prohibited. If you are no= t the >>> intended recipient, please contact the sender and delete all copies of = the >>> message. >>> >>> >>> ________________________________ >>> >>> This e-mail may contain Sprint proprietary information intended for the= sole >>> use of the recipient(s). Any use by others is prohibited. If you are no= t the >>> intended recipient, please contact the sender and delete all copies of = the >>> message. >>> _______________________________________________ >>> 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 >>> _______________________________________________ >>> 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 > ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Jul 29 02:34:53 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490981A0125 for ; Wed, 29 Jul 2015 02:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HARngKwVHHFh for ; Wed, 29 Jul 2015 02:34:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A271A00FE for ; Wed, 29 Jul 2015 02:34:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D19EBBE35; Wed, 29 Jul 2015 10:34:46 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoHmxJMKkPqS; Wed, 29 Jul 2015 10:34:46 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 62ACDBE56; Wed, 29 Jul 2015 10:34:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438162486; bh=Hej9OKcGCWt+r0ne0ALM1kbZ8Ptsb2EjgzlXYHWBmME=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=NRkPALE/upUP1zl1FSkorJSjM3DvOeGa6QesSMNo4sWTwy/uz8mVEve/eIms1K4yt 1kthiOMLbSzeQn2/k+pZF6rH1J1t+JXDBiiGHB2EGgBeT2y1B+BWIkV/ItihE/hULa 0qNYrnAeJWmuWePp5Ar6NAnIg/98P4Q0qQnKOqXI= Message-ID: <55B89E36.30305@cs.tcd.ie> Date: Wed, 29 Jul 2015 10:34:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Richard Barnes , Richard Shockey References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 09:34:52 -0000 Hi Richard, On 28/07/15 23:57, Richard Barnes wrote: > You are correct that if we build a putative security solution based on > public keys passed DNS, it will not be an IETF protocol. It will not > become an RFC because it will not meet the IETF's security standards. Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e. not a Proposed Standard) that does exactly that and that is in widespread use and that does not require DNSSEC. That is ok in that context because a bad signature is the same as a missing signature. If this WG wanted to use a DKIM-like solution and could justify the lack of 3rd party cryptographic binding between the TN and the public key, that could be entirely analogous. I'm not saying the WG should do that, but it could. Cheers, S. [1] https://tools.ietf.org/html/rfc6376 From nobody Wed Jul 29 06:15:30 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4211AC3BE for ; Wed, 29 Jul 2015 06:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 WCIj9m3x7sUl for ; Wed, 29 Jul 2015 06:15:27 -0700 (PDT) Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com [209.85.213.51]) (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 3FCE01A90D2 for ; Wed, 29 Jul 2015 06:15:27 -0700 (PDT) Received: by vkgc186 with SMTP id c186so1596414vkg.0 for ; Wed, 29 Jul 2015 06:15:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SvvQuKWw/FkkhAx/4sU7oLHtsTFVBZKyaBCSJfINC8Q=; b=jQ/Af8WnbPLqWfg1D08p6XN+46y/zcdwBiz1OZ+McoqtL/nrEBA3rmM0J4+mPYFSr1 e02Wsgz2xfbU3fzrD5Kt8F+VRm0q8nS57xiSu1tztQmQYcASsVTUWYjXhSS9P6K6W8zF j0ZmTJDqhla08RCyDni4/VnCOkvEIwB+CFhI8GhPalIOHLQsR3UV0syQtgJgScxZ+qoj pVNxnwGj24JkwUyG2mf1smKptKDjrZeFZuFWKHXOjWyIjtGMO2uwux5y34XufYhIVYb9 lxQq8OirGKqjlmN2eZ3wWYFNJDiIrw2pIefmfODLnLItGJ2bzhLCA9suBKPITa8fwsQU 3Y3Q== X-Gm-Message-State: ALoCoQm0jakd13Qu9nopn8+3zpQyEAQuTUkIRL2yrXRxlgKUcsCjtUKpSRDnh4bU+qLAdyks1xWg MIME-Version: 1.0 X-Received: by 10.52.5.133 with SMTP id s5mr52387599vds.65.1438175726454; Wed, 29 Jul 2015 06:15:26 -0700 (PDT) Received: by 10.31.164.207 with HTTP; Wed, 29 Jul 2015 06:15:26 -0700 (PDT) In-Reply-To: <55B89E36.30305@cs.tcd.ie> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> Date: Wed, 29 Jul 2015 09:15:26 -0400 Message-ID: From: Richard Barnes To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Henning Schulzrinne , "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Richard Shockey Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 13:15:29 -0000 On Wed, Jul 29, 2015 at 5:34 AM, Stephen Farrell wrote: > > Hi Richard, > > On 28/07/15 23:57, Richard Barnes wrote: >> You are correct that if we build a putative security solution based on >> public keys passed DNS, it will not be an IETF protocol. It will not >> become an RFC because it will not meet the IETF's security standards. > > Eh, that's not accurate. DKIM [1] is an Internet Standard > (i.e. not a Proposed Standard) that does exactly that and > that is in widespread use and that does not require DNSSEC. > That is ok in that context because a bad signature is the > same as a missing signature. > > If this WG wanted to use a DKIM-like solution and could > justify the lack of 3rd party cryptographic binding between > the TN and the public key, that could be entirely analogous. > > I'm not saying the WG should do that, but it could. Yeah, I guess what I'm saying is that I don't really see that justification in this case. Doing it right is cheap, so we should. --Richard > > Cheers, > S. > > [1] https://tools.ietf.org/html/rfc6376 From nobody Wed Jul 29 07:01:08 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FB41A1BAF for ; Wed, 29 Jul 2015 07:01:07 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 bbgXOCAtjsly for ; Wed, 29 Jul 2015 07:01:01 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E218F1A1BA2 for ; Wed, 29 Jul 2015 07:00:59 -0700 (PDT) Received: from BL2FFO11FD016.protection.gbl (10.173.160.33) by BL2FFO11HUB017.protection.gbl (10.173.160.109) with Microsoft SMTP Server (TLS) id 15.1.231.11; Wed, 29 Jul 2015 14:00:58 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.81) smtp.mailfrom=sprint.com; fcc.gov; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.81 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.81; helo=preapdm2.corp.sprint.com; Received: from preapdm2.corp.sprint.com (144.230.32.81) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Wed, 29 Jul 2015 14:00:58 +0000 Received: from pps.filterd (preapdm2.corp.sprint.com [127.0.0.1]) by preapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6TDvCJs008287; Wed, 29 Jul 2015 10:00:58 -0400 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm2.corp.sprint.com with ESMTP id 1vxgn3n489-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2015 10:00:58 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 29 Jul 2015 10:00:57 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Wed, 29 Jul 2015 09:00:56 -0500 From: "Gorman, Pierce A [CTO]" To: Richard Barnes , Stephen Farrell Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3w5jYQgABaDoD//6yTMIAAkHs8gABVvYCAALIOAIAAPagA//+32tA= Date: Wed, 29 Jul 2015 14:00:56 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD016; 1:rvJWy5o4TZfnHcrmQ9NOwRnGMrNInK/qTYy76h8hSik49H6Wt/obsm/IwSzCONHUQnST+wdYLsW4436jsw2Dtj3Z6Wa4pw9m+U+WXWreYANSlk3E8VEf64dHe+/lYkCVraYeqICqHGWmCWa2anQHhYCyQem8eI1xJ2iyKTgBHEnER5sF/FgwVL4DPcwN2sB61MN58khS8U1JaSkQLzd+7pdzHP+3t4nTZhjhRDCLfuDJG+zMyUSbXq8rVVW9IN4ia44N0Fb1Jei96p6U6Afc2KobMHiuDWct5UFXiQSpifDfSnNHGFR2T8wrzFN72Tz8uqw8pfNVy4GMRfY4R/FV9Q== X-Forefront-Antispam-Report: CIP:144.230.32.81; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(189002)(13464003)(24454002)(479174004)(199003)(377454003)(5250100002)(86362001)(2656002)(87936001)(47776003)(33646002)(19580405001)(19580395003)(108616004)(76176999)(46102003)(106116001)(189998001)(50466002)(15975445007)(77156002)(24736003)(50986999)(102836002)(2900100001)(92566002)(54356999)(5003600100002)(2950100001)(62966003)(6806004)(5001960100002)(5001770100001)(93886004)(23676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB017; H:preapdm2.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB017; 2:eqXuR5BiriIVVCBN52GHKGV8MkAJx4wk61/ClFwZvXA0hsqLnCJNyMFgve+rXr3SQQ1PQb9EkoRRhcKzbGJqTMqQvitddZEDjWwjhQAeo21RhRgFEH72xQPx1faxdPteyd26wDOpL4P2xls6XJBFp26ZDBC5qN8VEt1+RxU54Us=; 3:Mrn15F9dcpN3uRCFeSlCpN32Xg5yWzS0WTV5XIq933BbQUsMRXLNIPM1yhspYXHhj2sXm5cpsloX9xkMo3HfFGlOUhaiZHg6jG5Nh/UCmKjAsavy3lTz3SqPdKQ2oe34z+iiYk3MVU1dXAoR38uN04y0/kiIFvwj5oOoMbtPMnIs84ofRkO2OQXGzIlenghBU3z0K1ByMbrx87QgU39J3VqOF3wrDvcs6+lUKfuqwqM=; 25:QjQ3fzYNaLAd77vCsRPDzpLxkqA7sPpu2xqvrnbgH4MFIgcUs/w5engMEd76dgatR539vQMJelSOpVtmc6bBWWtOxbetjzz6SS/Pxnnjdln5na8nnTFk2rClQXEhLHzvq8/yq76paha66Qtpt+4+pHgivgA+4tQCcLZOm4nHI3fLbLUPiuADr28j3HfNB/oxHtoLtRAZ+sEhW9e/yPva0KA9LsQ0gJWz8Q4IJCLpcqVvxB+DEUAHJ9Lxgcx4Ot/Nd6vCHZTqcrKCr+1uEBEyhg==; 20:zE+uFSU0KNNpGD1usgpQEGDmSpkldtv3IRC5GKmm+KEHoboIQkYDioj3mLcjbZeT4ceClqlJHqskizefQC/wIyVdMIEYncX8WmdkxeeaWB7fNGEYl4unB8Az3rqFEdbKnLgbs4WDwlZYiH2rpKtcHa19YTh8IL6IKpyhLfP2itEx1ETHtlmVWnINbU2YpvGNc/GiEbArEUI2qKKT0PFsxwE7RrYhlXVK+C8x7A/+O39zIZ8oG6btpLGQ+KXB71/V X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB017; BL2FFO11HUB017: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BL2FFO11HUB017; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB017; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB017; 4:sliCa8Hckwzl9G+jXaQOVyv2jGqK+/hvB71689k2mBbZir0Ux/RedUFWLm49ec0SNtvyTnqV4wcR4/YX6iGARl3mV07RbQhOetvrDVXO1yqkwOSELRWM8pDOzxx9RighPfafMiAR2nB8aeM5hyfdADi3IMc9btjH0SQQ9AgjtypbofquPk2fOj6wERuH6RICTTcIcR68HExFPtRJZAA3zlTp6BwnsmsCnFn2YMuTxuq9GP4GIzCSmU5hg3AwGmGZznvpqbLpRku6ZNmsza9pl111MyGDg+UFiM0Lph88ncY= X-Forefront-PRVS: 0652EA5565 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDJGRk8xMUhVQjAxNzsyMzpOOU8zQ3QzaDJsL0UyWXNtRm9SL1Z6czRT?= =?utf-8?B?eTVabFI3Vy9tYXdidklHNTVmUGRQQkowWmdGdWs0aElheWZxOWs5VCt0STJv?= =?utf-8?B?eXUxUFd0T2RZakF6YStqZDlrUHB3UFA5a2w0K3VMVENFK2xPSEJjWDBTRThh?= =?utf-8?B?Y1BWdHl5NDg1akd1d2dxcFJ1MWRsZENTZ2dwYkY0a0NMQUxhUUhnd054bVV2?= =?utf-8?B?STYxL0dZdVdBNzNwZUkycHlZWWNSWERPYTFTWFhYZkhLOUpNeEFRZnlDYWg2?= =?utf-8?B?QzFmbmNJanlYZlJLa2czd09iN1BFb0hkNEhLbnVoR3ZyWUNVU1BHWStWMzRm?= =?utf-8?B?VWtXa2dDMjRhdm5IaEZQeGY3UFRrVVZFNEJwcnp5a2lvS09UdDdGNytkYzVy?= =?utf-8?B?dUtQTkFLL1hTUGRBS3JDNGVVbWo5WnJoYWdhRGVBRjU1WE13cUlWa0JIZTRD?= =?utf-8?B?UXZ3a2IzdURSUUozeGt6OHMrV25mSTRDOS9MVVRYaTczVnpXanRubks4bjA5?= =?utf-8?B?TkliaTRoVG1BUnkzU3lpWitrSmVFWkt3cUtqRXNuekJ4SGlvaW1XbmhOYzFQ?= =?utf-8?B?NERwUFdvU3pUMlFMNUxLTElRRk8xUUhqTXFCY3V1T2VrTDVGR0lBc2hHUUJY?= =?utf-8?B?RExNd3JCb2tpdlMwQUF2eCtLSGJlRkNBOEYvTlZJWHhGK1JMNndGcDNZRjRp?= =?utf-8?B?cEgrWTJMT0t4TEtGNS9YOFdRQ0NoWjI1dWJIdnI1VnQ2OFpTUDZLZ2lrZGIy?= =?utf-8?B?VTNiUG9mN0h5cDBqN0ROMnJsYStUTXA5UVpSL1BjdEluZzFrUzlnK1hiRFdw?= =?utf-8?B?ckhHV2w1azZtc1hMdUJnanpON3FEaXllT245RzlVOVEvNCtEajBraFlWaEcx?= =?utf-8?B?U1UvdGVnWkNyclZQL0RuL1FETDJ5RElzNmxucS9hV29pbWlhQXBsdkFESzFx?= =?utf-8?B?a3VMMjN4OCtZRERHTFlmRWlaNzhnVHF2czB2emNaNmNXUEVyU0N0NWhxc1h3?= =?utf-8?B?OVY1Y3dJYjE3K1BON1V2djMyK2U4TGszQjNvclI0cC9yU0tqWFJiWXBMdkUy?= =?utf-8?B?UlBWT2RKVEFGNVIzdGNnMmVjOHlBd2hqN2JRUU5pbnNtTHV2aVYwQjFsMWRz?= =?utf-8?B?aklRTGQvQUE4a0Nid3pTY1AvcC92ZzJQUHdBSVZKdEJ2VnVNRVZPYTV1eDVE?= =?utf-8?B?dGtSUDZCTzFkK21NY3l5amptbE1sMDU0TFR5YlhCSzBsQyt1WXBTeWdlZm4v?= =?utf-8?B?NCszMSt1NlF5NzN4cmRjdFI3NEFheExWOFpFV3hZRE4xNW54UUxGVUlZNUdU?= =?utf-8?B?T2tpOGllVGZCbEM4c1NuSERHUVdOOFZYUTR4dVFzajNOUnpneDZFdUUvYW9Z?= =?utf-8?B?TUZtOCtrM0ZDY2MvcTdxVWpyaDBjcmN4V1lHMEZ5L2hpVGNzcUR0aE1zMHNW?= =?utf-8?Q?5HEAaBo=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB017; 5:3XpTIFCGP2O/VeRj8FkyZGLZ9uEZ1Y28Z6wSJ10qWOmY01xiekyHyls8SMWsvBw6piCpNO3vbiEg0J5MhDAZGimXD2nzYzZ++3BQ+nQgBO/buKZFme3qtFJoil1VMeWkkzab5m4zbL2mzbi06xSkhw==; 24:GABgcLIz2OfLKx30U64fnBAapaFN64eSbn6PQJ+k7knity811imLx0IQ3eljYXAXZrXV3cXjZ/lP/WLBXvMnTB7tBp9Hvajyam1YBzsFlbw= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2015 14:00:58.4644 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.81]; Helo=[preapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB017 Archived-At: Cc: "stir@ietf.org" , Henning Schulzrinne , "PFAUTZ, PENN L" , Richard Shockey Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 14:01:07 -0000 SWYgaXQgaXNuJ3Qgb2J2aW91cyBhbHJlYWR5LCBJJ2xsIGFkbWl0IHVwIGZyb250IEkgaGF2ZSBs aW1pdGVkIChub3QgemVybykgZXhwZXJpZW5jZSB3aXRoIGJ1aWxkaW5nIFZvSVAgc3lzdGVtcyB3 aXRoIFNCQ3MgZW5nYWdpbmcgaW4gY2VydGlmaWNhdGUtYmFzZWQgKGluIG91ciBjYXNlLCBtdXR1 YWwpIGF1dGhlbnRpY2F0aW9uLCBidXQgdGhlIGV4cGVyaWVuY2Ugd2FzIG9uZXJvdXMsIHdoaWNo IG1ha2VzIG1lIHRvIGJlIGltbWVkaWF0ZWx5IHN1c3BpY2lvdXMgb2YgdGhlIGNsYWltLCAiRG9p bmcgaXQgcmlnaHQgaXMgY2hlYXAsIHNvIHdlIHNob3VsZCIuDQoNCkJlc3QgcmVnYXJkcywNCg0K DQpQaWVyY2UgR29ybWFuDQpDb3JlIE5ldHdvcmsgUGxhbm5pbmcNCk86IDkxMy00MzktNDM2OA0K cGllcmNlLmdvcm1hbkBzcHJpbnQuY29tDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxiQGlwdi5zeF0NClNlbnQ6IEp1bHkgMjks IDIwMTUgODoxNSBBTQ0KVG86IFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRj ZC5pZT4NCkNjOiBSaWNoYXJkIFNob2NrZXkgPHJpY2hhcmRAc2hvY2tleS51cz47IHN0aXJAaWV0 Zi5vcmc7IEdvcm1hbiwgUGllcmNlIEEgW0NUT10gPFBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbT47 IFBGQVVUWiwgUEVOTiBMIDxwcDMxMjlAYXR0LmNvbT47IEhlbm5pbmcgU2NodWx6cmlubmUgPEhl bm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdj4NClN1YmplY3Q6IFJlOiBbc3Rpcl0gT24gT0NTUCwg VE5zLCBhbmQgUHJpdmFjeQ0KDQpPbiBXZWQsIEp1bCAyOSwgMjAxNSBhdCA1OjM0IEFNLCBTdGVw aGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KPg0KPiBIaSBS aWNoYXJkLA0KPg0KPiBPbiAyOC8wNy8xNSAyMzo1NywgUmljaGFyZCBCYXJuZXMgd3JvdGU6DQo+ PiBZb3UgYXJlIGNvcnJlY3QgdGhhdCBpZiB3ZSBidWlsZCBhIHB1dGF0aXZlIHNlY3VyaXR5IHNv bHV0aW9uIGJhc2VkDQo+PiBvbiBwdWJsaWMga2V5cyBwYXNzZWQgRE5TLCBpdCB3aWxsIG5vdCBi ZSBhbiBJRVRGIHByb3RvY29sLiAgSXQgd2lsbA0KPj4gbm90IGJlY29tZSBhbiBSRkMgYmVjYXVz ZSBpdCB3aWxsIG5vdCBtZWV0IHRoZSBJRVRGJ3Mgc2VjdXJpdHkgc3RhbmRhcmRzLg0KPg0KPiBF aCwgdGhhdCdzIG5vdCBhY2N1cmF0ZS4gREtJTSBbMV0gaXMgYW4gSW50ZXJuZXQgU3RhbmRhcmQg KGkuZS4gbm90IGENCj4gUHJvcG9zZWQgU3RhbmRhcmQpIHRoYXQgZG9lcyBleGFjdGx5IHRoYXQg YW5kIHRoYXQgaXMgaW4gd2lkZXNwcmVhZA0KPiB1c2UgYW5kIHRoYXQgZG9lcyBub3QgcmVxdWly ZSBETlNTRUMuDQo+IFRoYXQgaXMgb2sgaW4gdGhhdCBjb250ZXh0IGJlY2F1c2UgYSBiYWQgc2ln bmF0dXJlIGlzIHRoZSBzYW1lIGFzIGENCj4gbWlzc2luZyBzaWduYXR1cmUuDQo+DQo+IElmIHRo aXMgV0cgd2FudGVkIHRvIHVzZSBhIERLSU0tbGlrZSBzb2x1dGlvbiBhbmQgY291bGQganVzdGlm eSB0aGUNCj4gbGFjayBvZiAzcmQgcGFydHkgY3J5cHRvZ3JhcGhpYyBiaW5kaW5nIGJldHdlZW4g dGhlIFROIGFuZCB0aGUgcHVibGljDQo+IGtleSwgdGhhdCBjb3VsZCBiZSBlbnRpcmVseSBhbmFs b2dvdXMuDQo+DQo+IEknbSBub3Qgc2F5aW5nIHRoZSBXRyBzaG91bGQgZG8gdGhhdCwgYnV0IGl0 IGNvdWxkLg0KDQpZZWFoLCBJIGd1ZXNzIHdoYXQgSSdtIHNheWluZyBpcyB0aGF0IEkgZG9uJ3Qg cmVhbGx5IHNlZSB0aGF0IGp1c3RpZmljYXRpb24gaW4gdGhpcyBjYXNlLiAgRG9pbmcgaXQgcmln aHQgaXMgY2hlYXAsIHNvIHdlIHNob3VsZC4NCg0KLS1SaWNoYXJkDQoNCj4NCj4gQ2hlZXJzLA0K PiBTLg0KPg0KPiBbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYzNzYNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4g U3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ug b2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNl bmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo= From nobody Wed Jul 29 11:50:29 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7351ACDEB for ; Wed, 29 Jul 2015 11:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.493 X-Spam-Level: X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=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 hFEAJuUCfEo8 for ; Wed, 29 Jul 2015 11:50:26 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5151AC39E for ; Wed, 29 Jul 2015 11:50:25 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-08v.sys.comcast.net with comcast id yJq91q00552QWKC01JqRLb; Wed, 29 Jul 2015 18:50:25 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by resomta-po-09v.sys.comcast.net with comcast id yJqP1q00D4EJ4tY01JqPnk; Wed, 29 Jul 2015 18:50:25 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Wed, 29 Jul 2015 11:48:07 -0700 From: Alex Bobotek To: Richard Barnes , Stephen Farrell Date: Wed, 29 Jul 2015 11:50:21 -0700 Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AdDKAFPQJxH8Mn1JSBS4w5XLc62//wAJelkw Message-ID: <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1438195825; bh=8yiFYq6yGvmF0m5OrCzj0cuGaiW+15ZKWT+WYPpZCBM=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=XV8Qp3BY9lPFMvo3KsLfehiOcgtJBkEqHP8P6cUedFmKBKZ0CqYy/KI/teX4K5hWx KkIYuGZi+W3AghRBmsflShv1tHcSP/Ok606AGylOBl20CZgGzlCLn06yYWtXY7H4sT wktuQTSDwil+uorFJv3gEcNfnkArp3huuVnBwACT14+UmwNbefn3ylnH/4BDRpR6nB Wp/Wq4Z/oX/mqGNUKu3OgNYLFMSdjxcc2TnWhpKr2Syp0QV/AHx5q7WYft2/tQMGI0 EMyNwiPTQrXm9VIEhJiwpsAb9InTj7camlGoBJ8w21nQtOvXUDWELN6SMy+/L9WcIe i8d5WZM1yKM/Q== Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Richard Shockey , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 18:50:27 -0000 Arguably the most important thing STIR can do is to help service providers = make intelligent policy decisions. An endpoint (aka the recipient's phone)= policy decision based solely on STIR validation results will not be anywhe= re near as effective as one based on a large network or even crowd-sourced = view. Network-based inputs such as complaints, submissions of unwanted voi= cemail, call volumetrics, calling graphs, reputation of the originating ser= vice provider, reputation of the originating TN, account history, call comp= letion records and call durations are important. Privacy considerations ma= ke many of these inputs difficult to crowd source. And these inputs are d= ifficult to provide to an endpoint even with new standards, but could be co= nveyed either as an aggregate score or individual parameters. Endpoint pol= icy enforcement should of course be supported, but we should recognize that= network-based enforcement is in practice the most widely adopted and effec= tive policy enforcement implementation (e.g., in email and SMS spaces). =20 Therefore STIR should provide network operators with * a validated identity of the originating service provider, and=20 * a validated originating service provider assertion of the originating TN= . (Note: this might be provided to networks but not endpoints in cases wh= ere caller ID is masked.) This provides much needed technical information and accountability for tech= nical and non-technical enforcement. =20 Operational considerations are the primary barrier to STIR implementation -= - what's easy to create in a lab may take many years and thousands of serve= rs to be implemented in a complex telco production environment. STIR shoul= d consider these as dominant drivers. It is much more practical for a telc= o to manage a dozen or so of its private-public key pairs than to create an= d manage a per-TN (> 100M TNs in the case of some carriers) certificate inf= rastructure. Adding a per-call database dip or per-TN cache is a huge impa= ct. =20 Public key distribution to carriers can be accomplished using some existing= lookup-based registry, and/or via attached certificates. Using a registry= already accessible to policy/routing engines is IMHO more practical in a s= ervice provider environment.=20 Regards, Alex > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Barnes > Sent: Wednesday, July 29, 2015 6:15 AM > To: Stephen Farrell > Cc: Henning Schulzrinne ; stir@ietf.org; > Gorman, Pierce A [CTO] ; PFAUTZ, PENN L > ; Richard Shockey > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 > On Wed, Jul 29, 2015 at 5:34 AM, Stephen Farrell > wrote: > > > > Hi Richard, > > > > On 28/07/15 23:57, Richard Barnes wrote: > >> You are correct that if we build a putative security solution based > >> on public keys passed DNS, it will not be an IETF protocol. It will > >> not become an RFC because it will not meet the IETF's security standar= ds. > > > > Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e. not a > > Proposed Standard) that does exactly that and that is in widespread > > use and that does not require DNSSEC. > > That is ok in that context because a bad signature is the same as a > > missing signature. > > > > If this WG wanted to use a DKIM-like solution and could justify the > > lack of 3rd party cryptographic binding between the TN and the public > > key, that could be entirely analogous. > > > > I'm not saying the WG should do that, but it could. >=20 > Yeah, I guess what I'm saying is that I don't really see that justificati= on in this > case. Doing it right is cheap, so we should. >=20 > --Richard >=20 > > > > Cheers, > > S. > > > > [1] https://tools.ietf.org/html/rfc6376 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Jul 29 12:00:05 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22381ACE16 for ; Wed, 29 Jul 2015 12:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.491 X-Spam-Level: X-Spam-Status: No, score=0.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=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 DOGNtMFt3rnp for ; Wed, 29 Jul 2015 12:00:01 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9A41ACE15 for ; Wed, 29 Jul 2015 12:00:00 -0700 (PDT) Received: from BN1AFFO11FD007.protection.gbl (10.58.52.33) by BN1AFFO11HUB027.protection.gbl (10.58.52.137) with Microsoft SMTP Server (TLS) id 15.1.231.11; Wed, 29 Jul 2015 18:59:59 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; shockey.us; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.39 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.39; helo=plsapdm3.corp.sprint.com; Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BN1AFFO11FD007.mail.protection.outlook.com (10.58.52.67) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Wed, 29 Jul 2015 18:59:59 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6TIv4ep023569; Wed, 29 Jul 2015 13:59:58 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm3.corp.sprint.com with ESMTP id 1vxgn1ykhf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2015 13:59:58 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 29 Jul 2015 14:59:56 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Wed, 29 Jul 2015 13:59:55 -0500 From: "Gorman, Pierce A [CTO]" To: Alex Bobotek , Richard Barnes , "Stephen Farrell" Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBAAJelkwnfKDPrA= Date: Wed, 29 Jul 2015 18:59:54 +0000 Message-ID: <1079f8fd44554c06b9fb64e0f62c0c1f@PLSWE13M08.ad.sprint.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> In-Reply-To: <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD007; 1:1OktC47zIXEYOACYpVgnAIlV95hLxCl0idYWRd+Gmb61iwYlvOt8/69EHqWdiH7ozwQFp+63UL243mMiVNWexl8oqa2QB85wYhmhxEhaNyf1saeb06bAgnzSDRGAY9j7VQ1s8q2Q29MYtOK852ZJcJ0Q/8DzR+lfv+eBZUDPCzAeqkPLDbPZDHwVIQVzvPb02TZj4N3McVQs2SZwlzzFY9yP4BHZ4GqcwCCrNL7Bn1JftGDY/NmmALlx6cyZnldCJ/82cKzn2eijGgF1xu2/hvkTcrk9u3+dAShzfkdOyzG1olztmd4xs/D0ggkRDxeKz2uv0qGCKZ1AwHFeDi8/ng== X-Forefront-Antispam-Report: CIP:144.230.172.39; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(377454003)(479174004)(13464003)(189002)(24454002)(102836002)(46102003)(93886004)(86362001)(108616004)(87936001)(77156002)(106116001)(92566002)(2900100001)(5890100001)(2656002)(189998001)(24736003)(5003600100002)(2950100001)(5001770100001)(19580395003)(19580405001)(47776003)(50986999)(33646002)(5001960100002)(76176999)(54356999)(46406003)(5250100002)(62966003)(15975445007)(50466002)(23726002)(106466001)(97756001)(6806004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB027; H:plsapdm3.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB027; 2:8S2fq5Uo/KOO+Gv8lW7LnBhnCFk92axIUIGzHV9O9h8v2eBO992jhk7+ZjhrDTjJXxCC2ZIClUOkS+6YDuIEW6lAHdX3L0Ihv08FqeJKua9ePnMl9j5p5rJ1V6hSHBjH7rgOm16tgqXPhqed6YJZfloubKcDBvP5P1W84uDLPGo=; 3:Vp/ZO6Dw5qe7ylBBaodOEw6QbcYiBOJug9qaEQXNIfJQILo5o6GEld6FYscr4Rl4Pjtzc23Nf1Vj7+6oyzPz5RdzhkLsYhKXuKHm9i2BshIBvBKJUWyFH7QkgWOYbTPTrsZyArw6PcT/sdmS6U0GUQM8vMZ3d8UKZZKMkmvL7Ed7Utj3oswmZ4d/WuKPxmgT140L+PjxsMvuwnwpEQrvKFbLuMaY+mJWwJ5YH+9Aij5lnPdqp+OzAIeBsaZWWcRc; 25:k+gWYxgulY/Fd6ixG8Uq5cvhNot0gr+gMhDb7tuuiGCTY737VunTDQNzvz/ebBAjh6+hk2Ca3U8Vw5NP3Fn2CCSimJPzI2kaAdQ5/kRN06i1Bw82mh5QAqGWAM4phTNTOGn+jb+4UsAZAlztOfQ8eBS907jRXWb+etLUx1u7Ye+xyz5AOKGtrmNKTkB57GeF2luE+BLXytdWkyRvTPSvUcet1XAAKZq7j1NC2UZGbZBksN+DAi8Z9vgf3ZbAsfk4moMNs/KzIPcSSjcEYBkxsg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB027; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB027; 20:QJazP6ueq0gGruBAgXWGy2/wK5qCDcfGATr38i4TgY13fuvmFjbUj2pPzB+v0lGmN2Mnfm0WD4JYVFYvb4YfaJe3Fn6zfbqVKDgk2zAbvAd4oW4gdbyQo3DKED9nfb0NPO7xjz72yRVSEKvQeRo0BEnURHZHNCb8sv7zEruQtP0qGw4q8XWHB7NjJDSeoOMD7xBrLJlpynYhdC8lE+YS8TTpOO7PvzBGrr8kIXCF+WfObzG4LX9AVEYWpHPDCxVI; 4:aGplvncKVE9EAIl9mGWDDCbCIM7U0bLY1sGC2f32EdYIS+Y6SD5caJZtFCA2dg7Al1tFZoF8Cc10Zg1nEOWFAk+4cpur+HTB89NnxX1L6uqEqRuE4Re2rit/NSIum6hC8BSB51iodemZyZWWTRh83UWZO+auXT6fqxEovusRJoLnw90m7lnpts1wlM+hVmv6caUvqUhidDf4GhACnhoRXmfNOVUljY4qHGrC3MpLi3Z0DuD+f+LtvczwcCVpchkRmZzIz85v1gbjsC7yEEGTShaQVOeMB7ifSbw1BBqq6LM= BN1AFFO11HUB027: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1AFFO11HUB027; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB027; X-Forefront-PRVS: 0652EA5565 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB027; 23:xKIR/PG65AGQBina/xroXI19UfAmnCk1Fco5nJD?= =?us-ascii?Q?NAiicFcU03ciSk8QZxHSwwf5Tqi3GKTB/LwnS0ABz5oPHEriO2O0m//Pyfyt?= =?us-ascii?Q?nTwVzL9m38BbL0idXv7NanPNWjn2HKuLAE7mNItCZoKWgLka0M3CrYdukOmA?= =?us-ascii?Q?+29DUZZnbc7a230vPScdqbafQ+fNtt3rwt5U3kpilzi33+ovu54M3x4KrH2Z?= =?us-ascii?Q?3EBXL9+FVml9GmTl5EnPILgFv8G/wsQEmWTqxw2e4iXmxzK8iMrcsdSraFBo?= =?us-ascii?Q?9xiwaecPeOMP5mi3CA1fnzZeyx2xD+NekaOdYC+eoo6O/OrdXKgi1vVg6J5e?= =?us-ascii?Q?dlzp3WTdLYwGK6+Zho3GloPRRR4H728CX1S8wjzrVukhWb6t7VFH3/Po7hIW?= =?us-ascii?Q?ZEXmrqGcNJD3GmOWeJS/P0DqnF5uHxV+Fpckf7G/PUWo/8TUrAR5a5DD+SNV?= =?us-ascii?Q?HFCZ07KsJCvQw0QSCiAr/7eeEInAHy8wQNr4s77RVWw+JpQgrpgIZTbhPB/0?= =?us-ascii?Q?Hus9QutXtgYe/Y2noYzwVgbimXeuKPS3gU7NY5hTYruBMp2Bjvl+sBnlrjk+?= =?us-ascii?Q?NPvdq3ulbRxuSwHuEbPUtp4mIILluMc9HwQh60hjvGiwOPplR+kE/RuSBTbU?= =?us-ascii?Q?jAT30E1o8P1xg+tc0EKZ88ijL9fk8uiF9ANpYm188yzT92MzDbLopUu+ZOUp?= =?us-ascii?Q?O8T8YuZd8NcNjg3lmdb8Gsn4FcHIWWLX/fEOjtIvZ1DEuEui8ybkeQih2KyE?= =?us-ascii?Q?7L7DOqLMmUAvLasMOm4kVXKHOdZdacss1fO7ZyxLAqVTfsLRe656sHW4GtrJ?= =?us-ascii?Q?lxQcSW3PeG5ucq2DrxPa2tCLrfxOyJNnFNsqKalEtaEBBWJ9wpeXzWy+gSwI?= =?us-ascii?Q?LiPKFruuK58tPpRb6qePCT2XrWvjO4g4kTlOK9IcMKs1k3Tpn1ZPwtV+jTRA?= =?us-ascii?Q?vR3EeXT8ms4gYhcJWhMARSGOgiDTqQ/muxEn10WC3nlQy38RsXKmvcOit6bH?= =?us-ascii?Q?Mn3SbmEGgekezLQERJN4QM+SHCYDgA5jJVz8/0R9GOm/aqlSxFDjI6rbKPEm?= =?us-ascii?Q?qrkylmopLlAj5Caso6daqCUEPhiHOxdVLyY8E2OXNmnw7h5Ze9xLTy58RNLV?= =?us-ascii?Q?S0VpFnOh+0wJ7njUs6OoTkH0iljbYOALW?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB027; 5:gieaXJqR+iReYgNOcaBGlWuho5SXPdKIK8+QKYHvNB03Q14ph1E3OifBEtk7lpPdiNxZETXPzI7ncB0xTJNSf8cwSTeXiy7lvfX8pfWkH5Nq/+EMXCVTUKZxQjFV+Rx5tMXaKxYmA98LJ/ORB09OIQ==; 24:lRkncFi21k8nEiShVReBryxrRirKAcFfJFfDrjjl1L5AsFJcjGf/nW5AakPTOAimnfxzdCUcJ3F6HjJMr+DekqmYukYBhAtZwyfPrI45TXs= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2015 18:59:59.1409 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB027 Archived-At: Cc: "stir@ietf.org" , Richard Shockey , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 19:00:03 -0000 Yeah, what he said times infinity. :-) Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Alex Bobotek [mailto:alex@bobotek.net] Sent: July 29, 2015 1:50 PM To: Richard Barnes ; Stephen Farrell Cc: Henning Schulzrinne ; stir@ietf.org; Gorma= n, Pierce A [CTO] ; PFAUTZ, PENN L ; Richard Shockey Subject: RE: [stir] On OCSP, TNs, and Privacy Arguably the most important thing STIR can do is to help service providers = make intelligent policy decisions. An endpoint (aka the recipient's phone)= policy decision based solely on STIR validation results will not be anywhe= re near as effective as one based on a large network or even crowd-sourced = view. Network-based inputs such as complaints, submissions of unwanted voi= cemail, call volumetrics, calling graphs, reputation of the originating ser= vice provider, reputation of the originating TN, account history, call comp= letion records and call durations are important. Privacy considerations ma= ke many of these inputs difficult to crowd source. And these inputs are d= ifficult to provide to an endpoint even with new standards, but could be co= nveyed either as an aggregate score or individual parameters. Endpoint pol= icy enforcement should of course be supported, but we should recognize that= network-based enforcement is in practice the most widely adopted and effec= tive policy enforcement implementation (e.g., in email and SMS spaces). Therefore STIR should provide network operators with * a validated identity of the originating service provider, and * a validated originating service provider assertion of the originating TN.= (Note: this might be provided to networks but not endpoints in cases whe= re caller ID is masked.) This provides much needed technical information an= d accountability for technical and non-technical enforcement. Operational considerations are the primary barrier to STIR implementation -= - what's easy to create in a lab may take many years and thousands of serve= rs to be implemented in a complex telco production environment. STIR shoul= d consider these as dominant drivers. It is much more practical for a telc= o to manage a dozen or so of its private-public key pairs than to create an= d manage a per-TN (> 100M TNs in the case of some carriers) certificate inf= rastructure. Adding a per-call database dip or per-TN cache is a huge impa= ct. Public key distribution to carriers can be accomplished using some existing= lookup-based registry, and/or via attached certificates. Using a registry= already accessible to policy/routing engines is IMHO more practical in a s= ervice provider environment. Regards, Alex > -----Original Message----- > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Barnes > Sent: Wednesday, July 29, 2015 6:15 AM > To: Stephen Farrell > Cc: Henning Schulzrinne ; stir@ietf.org; > Gorman, Pierce A [CTO] ; PFAUTZ, PENN L > ; Richard Shockey > Subject: Re: [stir] On OCSP, TNs, and Privacy > > On Wed, Jul 29, 2015 at 5:34 AM, Stephen Farrell > > wrote: > > > > Hi Richard, > > > > On 28/07/15 23:57, Richard Barnes wrote: > >> You are correct that if we build a putative security solution based > >> on public keys passed DNS, it will not be an IETF protocol. It > >> will not become an RFC because it will not meet the IETF's security st= andards. > > > > Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e. not > > a Proposed Standard) that does exactly that and that is in > > widespread use and that does not require DNSSEC. > > That is ok in that context because a bad signature is the same as a > > missing signature. > > > > If this WG wanted to use a DKIM-like solution and could justify the > > lack of 3rd party cryptographic binding between the TN and the > > public key, that could be entirely analogous. > > > > I'm not saying the WG should do that, but it could. > > Yeah, I guess what I'm saying is that I don't really see that > justification in this case. Doing it right is cheap, so we should. > > --Richard > > > > > Cheers, > > S. > > > > [1] https://tools.ietf.org/html/rfc6376 > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Thu Jul 30 08:27:33 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3491A87EB for ; Thu, 30 Jul 2015 08:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.874 X-Spam-Level: X-Spam-Status: No, score=-99.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393, USER_IN_WHITELIST=-100] autolearn=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 XYIL2tBWk5X1 for ; Thu, 30 Jul 2015 08:27:30 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 3A4F91A87D7 for ; Thu, 30 Jul 2015 08:27:23 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6UFQmTE026331; Thu, 30 Jul 2015 11:27:10 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vy8mr91kn-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Jul 2015 11:27:10 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Thu, 30 Jul 2015 11:27:08 -0400 From: "Peterson, Jon" To: Alex Bobotek , Richard Barnes , "Stephen Farrell" Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLpo71wZyAoryUWyV/ENo5W4tZ3wbvkAgAAgjQCAAJs4gIAABZ6AgAAApgCAAALIAIAAUOCAgAAO0ACAACgVAIAAB5iAgACyDgCAAD2oAIAAXZOAgADkMYA= Date: Thu, 30 Jul 2015 15:27:07 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> In-Reply-To: <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.129.245] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-30_08:2015-07-30,2015-07-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507300247 Archived-At: Cc: Henning Schulzrinne , "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Richard Shockey Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 15:27:31 -0000 I don't think those properties are very different from what RFC3325 provides. If all you care about is that someone you deem a "network operator" has asserted the originating TN, then PAI is surely adequate. The scope of STIR is different, however. We are considering a more pluralist world, after the IP transition, wherein a somewhat messy mixture of network operators, enterprises, and even end users could hold credentials that let them sign telephone calls. In that environment, the credentials need to reflect more than just the identity of the signer: they need to reflect number assignment itself. Personally, I agree that in this world I would not want to require holders of large number blocks (carriers) to have a cert per TN. And I totally agree that in that world, it would make sense for carrier policies to involve mutual trust that is based on the subject of certificates rather than the TNAuthList. But in STIR we're defining what goes on the wire, and in the certs, rather than the particulars of operator policy. We're providing mechanisms that will help in the messier cases, which may not need to be exercised in cases that look more like traditional PSTN operator handoffs. Yes, STIR treats a more complex world operationally than the effectively closed network of the PSTN, which RFC3325 tries to emulate. But it is the world that is coming, as far as I can tell. Jon Peterson Neustar, Inc. On 7/29/15, 11:50 AM, "Alex Bobotek" wrote: >Arguably the most important thing STIR can do is to help service >providers make intelligent policy decisions. An endpoint (aka the >recipient's phone) policy decision based solely on STIR validation >results will not be anywhere near as effective as one based on a large >network or even crowd-sourced view. Network-based inputs such as >complaints, submissions of unwanted voicemail, call volumetrics, calling >graphs, reputation of the originating service provider, reputation of the >originating TN, account history, call completion records and call >durations are important. Privacy considerations make many of these >inputs difficult to crowd source. And these inputs are difficult to >provide to an endpoint even with new standards, but could be conveyed >either as an aggregate score or individual parameters. Endpoint policy >enforcement should of course be supported, but we should recognize that >network-based enforcement is in practice the most widely adopted and >effective policy enforcement > implementation (e.g., in email and SMS spaces). > >Therefore STIR should provide network operators with > * a validated identity of the originating service provider, and > * a validated originating service provider assertion of the originating >TN. (Note: this might be provided to networks but not endpoints in >cases where caller ID is masked.) >This provides much needed technical information and accountability for >technical and non-technical enforcement. > >Operational considerations are the primary barrier to STIR implementation >-- what's easy to create in a lab may take many years and thousands of >servers to be implemented in a complex telco production environment. >STIR should consider these as dominant drivers. It is much more >practical for a telco to manage a dozen or so of its private-public key >pairs than to create and manage a per-TN (> 100M TNs in the case of some >carriers) certificate infrastructure. Adding a per-call database dip or >per-TN cache is a huge impact. > >Public key distribution to carriers can be accomplished using some >existing lookup-based registry, and/or via attached certificates. Using >a registry already accessible to policy/routing engines is IMHO more >practical in a service provider environment. > >Regards, > >Alex > > > >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Barnes >> Sent: Wednesday, July 29, 2015 6:15 AM >> To: Stephen Farrell >> Cc: Henning Schulzrinne ; stir@ietf.org; >> Gorman, Pierce A [CTO] ; PFAUTZ, PENN L >> ; Richard Shockey >> Subject: Re: [stir] On OCSP, TNs, and Privacy >>=20 >> On Wed, Jul 29, 2015 at 5:34 AM, Stephen Farrell >> >> wrote: >> > >> > Hi Richard, >> > >> > On 28/07/15 23:57, Richard Barnes wrote: >> >> You are correct that if we build a putative security solution based >> >> on public keys passed DNS, it will not be an IETF protocol. It will >> >> not become an RFC because it will not meet the IETF's security >>standards. >> > >> > Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e. not a >> > Proposed Standard) that does exactly that and that is in widespread >> > use and that does not require DNSSEC. >> > That is ok in that context because a bad signature is the same as a >> > missing signature. >> > >> > If this WG wanted to use a DKIM-like solution and could justify the >> > lack of 3rd party cryptographic binding between the TN and the public >> > key, that could be entirely analogous. >> > >> > I'm not saying the WG should do that, but it could. >>=20 >> Yeah, I guess what I'm saying is that I don't really see that >>justification in this >> case. Doing it right is cheap, so we should. >>=20 >> --Richard >>=20 >> > >> > Cheers, >> > S. >> > >> > [1] https://tools.ietf.org/html/rfc6376 >>=20 >> _______________________________________________ >> 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 From nobody Thu Jul 30 09:34:15 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3080A1A8837 for ; Thu, 30 Jul 2015 09:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.392 X-Spam-Level: X-Spam-Status: No, score=0.392 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, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=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 YZDXqfM9NQS9 for ; Thu, 30 Jul 2015 09:34:12 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 844631A8836 for ; Thu, 30 Jul 2015 09:34:11 -0700 (PDT) Received: (qmail 19294 invoked by uid 0); 30 Jul 2015 16:34:06 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy4.mail.unifiedlayer.com with SMTP; 30 Jul 2015 16:34:06 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id ygDu1q00A1MNPNq01gDxvy; Thu, 30 Jul 2015 10:14:04 -0600 X-Authority-Analysis: v=2.1 cv=O9qq4nNW c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=hGBaWAWWAAAA:8 a=VfgTrTGYAAAA:8 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=zQP7CpKOAAAA:8 a=DMUrj_QkdbabGV-z-uUA:9 a=tsKTaBCH8lUqPuJc:21 a=a7hqyRsUE1--BcrX:21 a=wPNLvfGTeEIA:10 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; bh=42fF73cTAGz3hAjCiPMrkeG2ONyyhqbq4U3kxjZOXiM=; b=GbsGzjCBfhXnKeCay5Mcd8w+LcNU+JFFaDw+kYa9XlGkjOAHMQz3t5NstmW5ma+pW9uHQyOqfJhlIcpF+kPAYlDOKO8GcXRm4vyEAyJjw3U2jvBosgjNf4ihzbpf+vkI; Received: from [100.36.26.202] (port=53178 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZKqSx-0004NY-4O; Thu, 30 Jul 2015 10:13:56 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Thu, 30 Jul 2015 12:13:48 -0400 From: Richard Shockey To: "Peterson, Jon" , Alex Bobotek , Richard Barnes , Stephen Farrell Message-ID: Thread-Topic: [stir] On OCSP, TNs, and Privacy References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:34:14 -0000 On 7/30/15, 11:27 AM, "Peterson, Jon" wrote: > >I don't think those properties are very different from what RFC3325 >provides. If all you care about is that someone you deem a "network >operator" has asserted the originating TN, then PAI is surely adequate. > >The scope of STIR is different, however. We are considering a more >pluralist world, after the IP transition, wherein a somewhat messy mixture >of network operators, enterprises, and even end users could hold >credentials that let them sign telephone calls. In that environment, the >credentials need to reflect more than just the identity of the signer: >they need to reflect number assignment itself. > >Personally, I agree that in this world I would not want to require holders >of large number blocks (carriers) to have a cert per TN. And I totally >agree that in that world, it would make sense for carrier policies to >involve mutual trust that is based on the subject of certificates rather >than the TNAuthList. But in STIR we're defining what goes on the wire, and >in the certs, rather than the particulars of operator policy. We're >providing mechanisms that will help in the messier cases, which may not >need to be exercised in cases that look more like traditional PSTN >operator handoffs. > >Yes, STIR treats a more complex world operationally than the effectively >closed network of the PSTN, which RFC3325 tries to emulate. But it is the >world that is coming, as far as I can tell. This is what I profoundly object to. The attempt to impose by IETF protocol a policy on how carrier networks should operate in the future. Its policy by stealth and it needs to stop right now. Code is NOT law. Its certainly not a R&O. Our concern should focus on what is the optimal deliverable on the wire today and we will see in the future how networks evolve. The problem TODAY lies in the traditional trust model between service providers that we know is broken. There are clearly tools to address that now and in the future we can build from success. As for the operational issue there is little or no empirical evidence that the future is going to be structured all that different from what we see today. The PSTN model of interconnected =B3any to any=B2 model, in large part mediated by carriers, continues to have real and demonstrable consumer enterprise value. We have swapped out SIP for TD/SS7 ok some progress. Contrary to popular opinion its a very good business. Its the reason we have iPhones and not iPods as the dominant end user device model. If SIP URI's were the dominant addressing model for real time communications we would not be having this conversation. The SMS service totally crushed instant messaging due to its interconnected model. I should have hats made up NO SILO. Facebook might be a phone company in the future. Now they can get their own E.164 blocks but they will play by PSTN policy that is not made here. Don=B9t even get me started on WEBRTC. I don=B9t know what world you see in your crystal ball but you might double check if its cracked or not. I=B9m open minded on the per TN cert issue. So long as the chain of trust is very very clear it could be a manageable problem. There are sound reasons for doing that but even how that deploys will not be decided here. I would like someone to explain when we might see a consensus on 4474bis so some of us could try and build a proof of concept and move on to something that can be deployed. > >Jon Peterson >Neustar, Inc. > >On 7/29/15, 11:50 AM, "Alex Bobotek" wrote: > >>Arguably the most important thing STIR can do is to help service >>providers make intelligent policy decisions. An endpoint (aka the >>recipient's phone) policy decision based solely on STIR validation >>results will not be anywhere near as effective as one based on a large >>network or even crowd-sourced view. Network-based inputs such as >>complaints, submissions of unwanted voicemail, call volumetrics, calling >>graphs, reputation of the originating service provider, reputation of the >>originating TN, account history, call completion records and call >>durations are important. Privacy considerations make many of these >>inputs difficult to crowd source. And these inputs are difficult to >>provide to an endpoint even with new standards, but could be conveyed >>either as an aggregate score or individual parameters. Endpoint policy >>enforcement should of course be supported, but we should recognize that >>network-based enforcement is in practice the most widely adopted and >>effective policy enforcement >> implementation (e.g., in email and SMS spaces). >> >>Therefore STIR should provide network operators with >> * a validated identity of the originating service provider, and >> * a validated originating service provider assertion of the originating >>TN. (Note: this might be provided to networks but not endpoints in >>cases where caller ID is masked.) >>This provides much needed technical information and accountability for >>technical and non-technical enforcement. >> >>Operational considerations are the primary barrier to STIR implementation >>-- what's easy to create in a lab may take many years and thousands of >>servers to be implemented in a complex telco production environment. >>STIR should consider these as dominant drivers. It is much more >>practical for a telco to manage a dozen or so of its private-public key >>pairs than to create and manage a per-TN (> 100M TNs in the case of some >>carriers) certificate infrastructure. Adding a per-call database dip or >>per-TN cache is a huge impact. >> >>Public key distribution to carriers can be accomplished using some >>existing lookup-based registry, and/or via attached certificates. Using >>a registry already accessible to policy/routing engines is IMHO more >>practical in a service provider environment. >> >>Regards, >> >>Alex >> >> >> >>> -----Original Message----- >>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Barnes >>> Sent: Wednesday, July 29, 2015 6:15 AM >>> To: Stephen Farrell >>> Cc: Henning Schulzrinne ; stir@ietf.org; >>> Gorman, Pierce A [CTO] ; PFAUTZ, PENN L >>> ; Richard Shockey >>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>=20 >>> On Wed, Jul 29, 2015 at 5:34 AM, Stephen Farrell >>> >>> wrote: >>> > >>> > Hi Richard, >>> > >>> > On 28/07/15 23:57, Richard Barnes wrote: >>> >> You are correct that if we build a putative security solution based >>> >> on public keys passed DNS, it will not be an IETF protocol. It will >>> >> not become an RFC because it will not meet the IETF's security >>>standards. >>> > >>> > Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e. not a >>> > Proposed Standard) that does exactly that and that is in widespread >>> > use and that does not require DNSSEC. >>> > That is ok in that context because a bad signature is the same as a >>> > missing signature. >>> > >>> > If this WG wanted to use a DKIM-like solution and could justify the >>> > lack of 3rd party cryptographic binding between the TN and the public >>> > key, that could be entirely analogous. >>> > >>> > I'm not saying the WG should do that, but it could. >>>=20 >>> Yeah, I guess what I'm saying is that I don't really see that >>>justification in this >>> case. Doing it right is cheap, so we should. >>>=20 >>> --Richard >>>=20 >>> > >>> > Cheers, >>> > S. >>> > >>> > [1] https://tools.ietf.org/html/rfc6376 >>>=20 >>> _______________________________________________ >>> 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 > From nobody Thu Jul 30 09:52:54 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9F61A924A for ; Thu, 30 Jul 2015 09:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 W_QSlVpsoQyw for ; Thu, 30 Jul 2015 09:52:50 -0700 (PDT) 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 97F501A8ABE for ; Thu, 30 Jul 2015 09:52:48 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6UGqgdB028090; Thu, 30 Jul 2015 12:52:42 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1vyk7nghjn-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Jul 2015 12:52:42 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Thu, 30 Jul 2015 12:52:34 -0400 From: "Peterson, Jon" To: Richard Shockey , Alex Bobotek , Richard Barnes , Stephen Farrell Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLpo71wZyAoryUWyV/ENo5W4tZ3wbvkAgAAgjQCAAJs4gIAABZ6AgAAApgCAAALIAIAAUOCAgAAO0ACAACgVAIAAB5iAgACyDgCAAD2oAIAAXZOAgADkMYCAAIJmAP//lXmA Date: Thu, 30 Jul 2015 16:52:33 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [192.168.129.245] Content-Type: text/plain; charset="us-ascii" Content-ID: <7CBD73583001284D92F8B3534EDC25A2@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-30_08:2015-07-30,2015-07-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507300269 Archived-At: Cc: "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:52:51 -0000 On 7/30/15, 9:13 AM, "Richard Shockey" wrote: > > > >> >> But in STIR we're defining what goes on the wire, and >>in the certs, rather than the particulars of operator policy. We're >>providing mechanisms that will help in the messier cases, which may not >>need to be exercised in cases that look more like traditional PSTN >>operator handoffs. >> > > >This is what I profoundly object to. The attempt to impose by IETF >protocol a policy on how carrier networks should operate in the future. And what I profoundly object to is this sort of cynical misrepresentation of the work here, in light of the fact that what I wrote (excerpted above) says the opposite of what you are claiming. But more particularly, the crisis of spoofing today does not result from traditional carrier handoffs. It comes from the fact that the Internet and PSTN have interconnected in ways that have made many parties other than traditional carriers responsible for attesting numbers. That is the reality on the ground today, not a prophecy about the future. STIR tries to address that reality head-on. Saying that we should reduce its scope to 1980s PSTN interconnection is woefully short-sighted, and bluntly has no place in a serious discussion about resolving the problem of spoofing. Jon Peterson Neustar, Inc. From nobody Thu Jul 30 12:12:36 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CAB1A89A2 for ; Thu, 30 Jul 2015 12:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 29oRGo7KsV83 for ; Thu, 30 Jul 2015 12:12:32 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id DCFCA1A1ADC for ; Thu, 30 Jul 2015 12:12:31 -0700 (PDT) From: Henning Schulzrinne To: "Peterson, Jon" , Alex Bobotek , Richard Barnes Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAJs4gIAABZ6AgAAApgCAAAEaoIAAUo6AgAAO0ACAACgVAIAAB5mAgACyDgCAAD2nAIAAXZOAgAFZjYCAADMyog== Date: Thu, 30 Jul 2015 19:12:25 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 5:Ve/8dmT4TG0qRcPAL5oTNqpkL9ZogIMbULNQjecJ+F10TnxEn8M/mw5N40q4msLx80izffgF/JA9yvwv5Z5fGx2aCktQ8Q7Q/1yWYeHMVo3ljOK995cTqInhkrA0EpFMynOud4j9ZxG7tc3RvlFj3Q==; 24:YeoHr0W1Lz5WYacTkUVO3CWiGYidNQiJrI83maiS5zO4bw1DxWXogEQ2SMq5VaTH9vk8brLmjwqc+ftIPqWM0eFnUINMgN8kaW6DH8DXrgA=; 20:AtPExBvabiJ/h9L5hGm4szywrBJ5etrz5tuYoIOmDYmBgjObU8ZOFiW3Pb0suqhqyl1LyceYdB0D8IBE2/7B2A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635; cy1pr09mb0635: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(5003600100002)(5001960100002)(77156002)(19580395003)(74316001)(106116001)(15975445007)(54356999)(86362001)(93886004)(99286002)(5001770100001)(50986999)(77096005)(76176999)(2950100001)(102836002)(76576001)(33656002)(62966003)(46102003)(19580405001)(122556002)(5002640100001)(2656002)(2900100001)(87936001)(92566002)(189998001)(40100003)(5890100001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 19:12:25.7000 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" , Richard Shockey Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 19:12:35 -0000 I think it's helpful to describe specific deployment scenarios and their tr= ade-offs - not to pick one, but to make sure we have one or more plausible = systems stories. I would advise caution when discussions arise that seem to= favor a "club" of large carriers and that disadvantage smaller carriers or= entities. Anti-trust lawyers don't like that, I've been told. If we get back down from philosophy to engineering, we seem to be discussin= g three different models (leaving CRL/revocation aside): (1) A "wildcard" model: An entity signs with a private key that's part of a= certificate for all numbers. Essentially, this simply says "this call orig= inated by Carrier A". Maybe you'd get the cert along with the OCN from NECA= . (2) A "multi-TN-per-cert" model: The cert applies to ten to (maybe) hundred= numbers, enumerated or identified by range/prefix. If number porting is fr= equent, this means that either the certs become over-inclusive (which may n= ot be a major problem) or need to be re-issued. Example: with a typical mob= ile churn rate of around 2% per month (http://www.statista.com/statistics/2= 83511/average-monthly-churn-rate-top-wireless-carriers-us/), a ten-TN cert = would have a 19% chance each month of being incorrect. (3) A single-TN per cert model. The number of public-private key pairs is independent of the choice, as men= tioned by Richard B. If certs are delivered out-of-band, caching determines the number of HTTP s= ervers needed. #1 will have near-perfect hit ratios (unless carriers use lo= ts of certs), #3 will have a poor hit ratio, particularly if the OCSP objec= t is stapled on and part of the cache. #2 will be somewhere in-between. The= alternative is to do what it's being done for LRN lookup, i.e., download t= he cert database and pub-sub updates. For 800M US numbers, we're talking 80= 0 GB of data for model #3, or about 100 GB a day with OCSP or 1 GB/day with= 2 year cert lifetime and some other (e.g., pub-sub) invalidation mechanism= . Obviously, the three models can co-exist. Random googling claims that there are 3 B calls in the US per day. A signif= icant fraction is likely within the same carrier or may otherwise not requi= re validation or downloading (e.g., because of caching), so this is an uppe= r bound for our purpose. According to https://wrongsideofmemphis.wordpress.com/2013/10/21/requests-per-second-a-r= eference/ 2,000 RPS are "is a decent amount of load for a normal server for a regular= service." This translates to roughly 0.2 B requests per server per day, so for all of= the US, across all carriers, we're talking 15 servers. (As noted, cert ret= rieval is a trivial static file/object download, so this doesn't seem unrea= listic even without custom-designed stacks.) My guess is that SBCs and cert= servers will be paired in practice, for a variety of logistical, network a= ccess (e.g., VPN) and fate-sharing reasons, but that's obviously an impleme= ntation detail. If a carrier needs hundreds of servers for cert delivery, they may want to = check if they are still hoarding 3B2's. (There is obviously separate overhead for SIP request signing and validatio= n, but that doesn't depend on the model #1, #2 or #3, just on key lengths a= nd algorithm.) My back of the envelope is full, but I'm sure others can add more. Henning ________________________________________ From: Peterson, Jon Sent: Thursday, July 30, 2015 11:27 AM To: Alex Bobotek; Richard Barnes; Stephen Farrell Cc: stir@ietf.org; Gorman, Pierce A [CTO]; PFAUTZ, PENN L; Richard Shockey;= Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy I don't think those properties are very different from what RFC3325 provides. If all you care about is that someone you deem a "network operator" has asserted the originating TN, then PAI is surely adequate. The scope of STIR is different, however. We are considering a more pluralist world, after the IP transition, wherein a somewhat messy mixture of network operators, enterprises, and even end users could hold credentials that let them sign telephone calls. In that environment, the credentials need to reflect more than just the identity of the signer: they need to reflect number assignment itself. Personally, I agree that in this world I would not want to require holders of large number blocks (carriers) to have a cert per TN. And I totally agree that in that world, it would make sense for carrier policies to involve mutual trust that is based on the subject of certificates rather than the TNAuthList. But in STIR we're defining what goes on the wire, and in the certs, rather than the particulars of operator policy. We're providing mechanisms that will help in the messier cases, which may not need to be exercised in cases that look more like traditional PSTN operator handoffs. Yes, STIR treats a more complex world operationally than the effectively closed network of the PSTN, which RFC3325 tries to emulate. But it is the world that is coming, as far as I can tell. Jon Peterson Neustar, Inc. On 7/29/15, 11:50 AM, "Alex Bobotek" wrote: >Arguably the most important thing STIR can do is to help service >providers make intelligent policy decisions. An endpoint (aka the >recipient's phone) policy decision based solely on STIR validation >results will not be anywhere near as effective as one based on a large >network or even crowd-sourced view. Network-based inputs such as >complaints, submissions of unwanted voicemail, call volumetrics, calling >graphs, reputation of the originating service provider, reputation of the >originating TN, account history, call completion records and call >durations are important. Privacy considerations make many of these >inputs difficult to crowd source. And these inputs are difficult to >provide to an endpoint even with new standards, but could be conveyed >either as an aggregate score or individual parameters. Endpoint policy >enforcement should of course be supported, but we should recognize that >network-based enforcement is in practice the most widely adopted and >effective policy enforcement > implementation (e.g., in email and SMS spaces). > >Therefore STIR should provide network operators with > * a validated identity of the originating service provider, and > * a validated originating service provider assertion of the origina= ting >TN. (Note: this might be provided to networks but not endpoints in >cases where caller ID is masked.) >This provides much needed technical information and accountability for >technical and non-technical enforcement. > >Operational considerations are the primary barrier to STIR implementation >-- what's easy to create in a lab may take many years and thousands of >servers to be implemented in a complex telco production environment. >STIR should consider these as dominant drivers. It is much more >practical for a telco to manage a dozen or so of its private-public key >pairs than to create and manage a per-TN (> 100M TNs in the case of some >carriers) certificate infrastructure. Adding a per-call database dip or >per-TN cache is a huge impact. > >Public key distribution to carriers can be accomplished using some >existing lookup-based registry, and/or via attached certificates. Using >a registry already accessible to policy/routing engines is IMHO more >practical in a service provider environment. > >Regards, > >Alex > From nobody Thu Jul 30 14:21:40 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08661ACCE8 for ; Thu, 30 Jul 2015 14:21:39 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YLM7bwSC7mhF for ; Thu, 30 Jul 2015 14:21:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5AA1ACD0D for ; Thu, 30 Jul 2015 14:21:36 -0700 (PDT) Received: from BL2FFO11OLC014.protection.gbl (10.173.160.31) by BL2FFO11HUB010.protection.gbl (10.173.161.112) with Microsoft SMTP Server (TLS) id 15.1.231.11; Thu, 30 Jul 2015 21:21:35 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; fcc.gov; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com; Received: from preapdm1.corp.sprint.com (144.230.32.80) by BL2FFO11OLC014.mail.protection.outlook.com (10.173.160.144) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Thu, 30 Jul 2015 21:21:34 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6ULIr8v008094; Thu, 30 Jul 2015 17:21:34 -0400 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by preapdm1.corp.sprint.com with ESMTP id 1vxgn3s75b-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Jul 2015 17:21:34 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 30 Jul 2015 17:21:32 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Thu, 30 Jul 2015 16:21:32 -0500 From: "Gorman, Pierce A [CTO]" To: "Peterson, Jon" , Alex Bobotek , Richard Barnes , Stephen Farrell Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3wbvkAgAAgjQCAAJs4gIAABZ6AgAAApgCAAALIAIAAUOCAgAAO0ACAACgVAIAAB5iAgACyDgCAAD2oAIAAXZOAgADkMYCAAJLhgA== Date: Thu, 30 Jul 2015 21:21:31 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC014; 1:0PED1wCO7MTohsyRaEnct3OBlTGn/4hOSUZaEzxtGPk1Ad60qoeKMkj2Vl4CynlvPHcLhO3hxvwMtQ+FG/3HUKyCZzGnkhHQCc0OlbfW5b2PAyD4DwjCAH69pcgHWQ03Bj2po3JEMK8izVj5c3a8zj53lrEl7ahpODPpCroA13DL4gEMPwXIyCNCKsTG+vTcK5K92lOoa9ihGP3CUZ0Z9wd7ADG3A+UVUvoTJDnjXFdSMhLraI5QAWtcjntEJmqSIyGram5IUm0H4DgBsfnnZlW4Wq47mCZzxlGAPSG8TcSx5XOQXA7aVt1laz15rpD4pkD/gr3SR8uvR6RhY+bUPg== X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(2980300002)(438002)(479174004)(199003)(377454003)(24454002)(13464003)(189002)(47776003)(76176999)(86362001)(19580395003)(102836002)(15975445007)(106466001)(54356999)(87936001)(93886004)(108616004)(50466002)(50986999)(46406003)(2950100001)(23726002)(5003600100002)(46102003)(2656002)(92566002)(6806004)(2900100001)(5890100001)(62966003)(5001960100002)(24736003)(33646002)(5250100002)(106116001)(97756001)(77156002)(5001770100001)(19580405001)(189998001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB010; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB010; 2:3MUk8bIrfPxYLa++qhJen4pVj/lg87q6epYUblfVxM4NIZP7JweWTHBJXOP47Y4aKOpk55bUNlNt4++QEZzCHOis5q3gfr059iGbB3WZfj87jHGXbk1H3BBtPdfxO1UTvdjTSnFi+4ge8VcOItzNv8gFTS0Gd6jMBny9h08IRYE=; 3:9gK9FPF3UCK15ti2ZzYegI3DZ2b1HAKdJt8V9GV3vi1D3+MrQR/qP0ZcWSsS9+VaQE9nAZq5qSjtybOPpaLxkrPJvW59zYS5z72ZsKVDyINcPa7rboIhHFvdOo0eS+zgoNE3PMyUpqt1jCCYcS8KG1iZeusev7mbKrIIQblVM3gZh6IraPidA8CUOKh7iFhMbvXWyrHmGY8f/wNXD0gPLkGBzQpYokLkfpZPF5bXSnY=; 25:YX4h7/o4hCZN/YV8aAnVpmkgxTUjdjMVDh7h9pquSMS04R41kDXh5yJQyBAwpBkTnjl3T0DxcFz/ln3Is+dqNu8jDe8Sm1srmmZW+yAorjq6nwdbNfCGcJub9A5jY9tvLl95ZOSnlINsl/bh9Mhk4G7Gq0mZ/wq0iscNgjCovRaNhjPhsnvWqTORG3+NxUACogUKj2dT4r1ixeBdemDjm6VIP5+/ghY88N4xEACHTpvoRgAi4WtEcVwXbscH/slZkkR2x6F4unaU0K4aghoSvw==; 20:q0u/D1C+hpQWMf8j8qhdIzZmYEcxxp1mMppzatNxwMDpHSLFKnoONoqnFAECSZWrU3GrM4Y80B6bX0BYlkehjOYhGbc1My3b85Div16IlP2NjbUkZwJ1JDI0GJSkAS+8S4hHchzLMQ3pWIMNHKmUgv5P5ckh7LP7d9qWQYyypEyM/jOZMwqJEsVSC0uwZUewk21NkO2M+anFKuSN8vm2cvCvN0OF1BupRhyBveiL2Mnj4/TUihivVg4BGvQPe18K X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB010; BL2FFO11HUB010: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BL2FFO11HUB010; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB010; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB010; 4:H7zHQiiogEtFCMldKBpfsjqx0j2aApJcVvNhJRFT+jgNonllHDpam+6kKEuOjblVJWoJ/LOdjMwofDwD87nS6sCW3UjrmQhdLRKVrZXjzRyWf7h0cHZHuDBhRHjGTguRG8tAdKrx+o7ycH3YjHnS0Nlpy8VQ0dd2i4niJlDXzyBzh8BoFMt8iDhmDw1WLvws7wwq3bpLGaMs+5x6nqUcGdcMBtnLGSDJq12ygq4FBzNzDeJniGDTCnkcVC3t54/N9Alp0fuC5TJrStpvZVlVYcnfyIKW9eigULidljI0nXo= X-Forefront-PRVS: 06530126A4 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB010; 23:QKoyobM6rMW9qg1uKG6X9TeD5GjKdKCwP0Erpozz?= =?us-ascii?Q?apD7yjOBWKj1VX/shdAZEMN4m8GEqulAr62rsd7MiRlTm0Nq+oVTcNSrIo6I?= =?us-ascii?Q?XBBEt+wwkls6oldZscL/oLAxmDmb11JMnKEYt101o46EjROpCz50uDfIqNUg?= =?us-ascii?Q?N/kUyynyKMVm+3NNf+jfnXXW4ssVhNSsdomvX1aOBHjSTQtm5eRqm2K5nrfe?= =?us-ascii?Q?NSk4BrDtsYNZTDKtehvfMTRTmoNwG+XCnka8lY05PAmGGFuBOEsPy4YpS08d?= =?us-ascii?Q?KGwNzlhr8xwk37ZN6v5oAfgptBJogY4b45TIhEPo1GtoXOt380ow5Dcwp+5d?= =?us-ascii?Q?Qf+1XGhbggJdNououDtEuD3wVKyzeb6bb1tsCOnSJxdq9l4hsiUKIclByBvp?= =?us-ascii?Q?7DvkrnI3zPzVizu8gSE3rG4EaK07542jNYyPTl17ix6/ofkOwxP5/jAADnj+?= =?us-ascii?Q?22CJDgBJRD9Y9a34n9uWkqWVyzURBsW16FWrWvAPUr+JfwfVFkmnxgkngBtm?= =?us-ascii?Q?KgBKh+36Eqvec7G0zRI9dxPM9nREB4c5M6T+fPn4GYGffmo9j2mB01PzmrUL?= =?us-ascii?Q?uHvqPyzDrd4fg8y5jMhJx6hMOxOta0hPC7SvXCF9UeB2BFPd1RIvBqHi8QhJ?= =?us-ascii?Q?BORm8xn2AWrN6396Eq8K9Yk8vKCal/5nBKziyId3simkEp2h6y5akLlnIP97?= =?us-ascii?Q?Ao16Y6W6DR4FCFXrvA3Aa7LwSlU8pyXvsdX1jUqWgHTCKbaY2VbJrh+JdLz+?= =?us-ascii?Q?V2dLP56bhzT7K8gyic7VDltZbtovBdtwJaaoph+LtJWhRotq6aKBTHUtngVs?= =?us-ascii?Q?m6cykHNfGC3MPXSh+p/NhOjQEBcldJICIOxEtteKgjqoBRKfPEXmy0V6ckUK?= =?us-ascii?Q?ew4QG30PqaqrmPgRZUpfEuwP76L9qquMs5XACvGxd5+aBBF/TdVwDMbcZl6X?= =?us-ascii?Q?ttQ3OdOCbfjPxEeAqmbIyZoBX9Fw9UshIZ5Hj2wj5CXxAwww+ajJ5hwo2ObH?= =?us-ascii?Q?wL/OBOWasjNkbKl1GSrJv+uie6xbWgH+K0A7BKqkrwd2pFxtEa9NOqaY0H2a?= =?us-ascii?Q?0IyG5pfgcvE1mNzkznioG8g1U7pnKj3Kr0t5iZa2Q3B65l+LjahB5z2Z11g2?= =?us-ascii?Q?QX+XalLvFQIjKGSraap9tgFFyP1ob3m3Voi3OYJho3dXJ/YayCQz1uMWo2fC?= =?us-ascii?Q?feAUcmjtrKR+Q1+AqhMTyJmSqQw+5v/UFSqXHSRdkXwhtL7myQxk92ojFt4+?= =?us-ascii?Q?8S0Q8KrUFVPeHOhvNYI=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB010; 5:G5cpUqi5ocjtT4nXoShGNGEwb9Mfs27aXNYxgKUdl+PKXhDQD/jQNoK9sQLEYtote2ouaOp4G80VJwWSeRbxWgLf2wIPSEWlHjfRvfJ1WrHyRLgjux+U+00Y9nuuIQEfpaY/jPzxopCvi5llwlVv9w==; 24:P8RkmL558LLdAMzyQ8tAK59wMNr+tdmgkhvMIS1orMLsKENt+BU+vaDRH5DVcKODSZTEXFW4qJEf/kgSRE/4xUJSLi/Ta6b1bqUtQ6ZqFCE= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2015 21:21:34.7332 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB010 Archived-At: Cc: "stir@ietf.org" , Henning Schulzrinne , "PFAUTZ, PENN L" , Richard Shockey Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 21:21:39 -0000 Jon, I didn't follow what you meant in your phrase, " Yes, STIR treats a more co= mplex world operationally than the effectively closed network of the PSTN..= ." Can you perhaps explain a little more what you meant there? Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: July 30, 2015 10:27 AM To: Alex Bobotek ; Richard Barnes ; Stephen F= arrell Cc: stir@ietf.org; Gorman, Pierce A [CTO] ; PFAUT= Z, PENN L ; Richard Shockey ; Henning S= chulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy I don't think those properties are very different from what RFC3325 provide= s. If all you care about is that someone you deem a "network operator" has = asserted the originating TN, then PAI is surely adequate. The scope of STIR is different, however. We are considering a more pluralis= t world, after the IP transition, wherein a somewhat messy mixture of netwo= rk operators, enterprises, and even end users could hold credentials that l= et them sign telephone calls. In that environment, the credentials need to = reflect more than just the identity of the signer: they need to reflect number assignment itself. Personally, I agree that in this world I would not want to require holders = of large number blocks (carriers) to have a cert per TN. And I totally agre= e that in that world, it would make sense for carrier policies to involve m= utual trust that is based on the subject of certificates rather than the TN= AuthList. But in STIR we're defining what goes on the wire, and in the cert= s, rather than the particulars of operator policy. We're providing mechanis= ms that will help in the messier cases, which may not need to be exercised = in cases that look more like traditional PSTN operator handoffs. Yes, STIR treats a more complex world operationally than the effectively cl= osed network of the PSTN, which RFC3325 tries to emulate. But it is the wor= ld that is coming, as far as I can tell. Jon Peterson Neustar, Inc. On 7/29/15, 11:50 AM, "Alex Bobotek" wrote: >Arguably the most important thing STIR can do is to help service >providers make intelligent policy decisions. An endpoint (aka the >recipient's phone) policy decision based solely on STIR validation >results will not be anywhere near as effective as one based on a large >network or even crowd-sourced view. Network-based inputs such as >complaints, submissions of unwanted voicemail, call volumetrics, >calling graphs, reputation of the originating service provider, >reputation of the originating TN, account history, call completion >records and call durations are important. Privacy considerations make >many of these inputs difficult to crowd source. And these inputs are >difficult to provide to an endpoint even with new standards, but could >be conveyed either as an aggregate score or individual parameters. >Endpoint policy enforcement should of course be supported, but we >should recognize that network-based enforcement is in practice the most >widely adopted and effective policy enforcement > implementation (e.g., in email and SMS spaces). > >Therefore STIR should provide network operators with >* a validated identity of the originating service provider, and >* a validated originating service provider assertion of the >originating TN. (Note: this might be provided to networks but not >endpoints in cases where caller ID is masked.) This provides much >needed technical information and accountability for technical and >non-technical enforcement. > >Operational considerations are the primary barrier to STIR >implementation >-- what's easy to create in a lab may take many years and thousands of >servers to be implemented in a complex telco production environment. >STIR should consider these as dominant drivers. It is much more >practical for a telco to manage a dozen or so of its private-public key >pairs than to create and manage a per-TN (> 100M TNs in the case of >some >carriers) certificate infrastructure. Adding a per-call database dip >or per-TN cache is a huge impact. > >Public key distribution to carriers can be accomplished using some >existing lookup-based registry, and/or via attached certificates. >Using a registry already accessible to policy/routing engines is IMHO >more practical in a service provider environment. > >Regards, > >Alex > > > >> -----Original Message----- >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Barnes >> Sent: Wednesday, July 29, 2015 6:15 AM >> To: Stephen Farrell >> Cc: Henning Schulzrinne ; stir@ietf.org; >> Gorman, Pierce A [CTO] ; PFAUTZ, PENN L >> ; Richard Shockey >> Subject: Re: [stir] On OCSP, TNs, and Privacy >> >> On Wed, Jul 29, 2015 at 5:34 AM, Stephen Farrell >> >> wrote: >> > >> > Hi Richard, >> > >> > On 28/07/15 23:57, Richard Barnes wrote: >> >> You are correct that if we build a putative security solution >> >> based on public keys passed DNS, it will not be an IETF protocol. >> >> It will not become an RFC because it will not meet the IETF's >> >> security >>standards. >> > >> > Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e. not >> > a Proposed Standard) that does exactly that and that is in >> > widespread use and that does not require DNSSEC. >> > That is ok in that context because a bad signature is the same as a >> > missing signature. >> > >> > If this WG wanted to use a DKIM-like solution and could justify the >> > lack of 3rd party cryptographic binding between the TN and the >> > public key, that could be entirely analogous. >> > >> > I'm not saying the WG should do that, but it could. >> >> Yeah, I guess what I'm saying is that I don't really see that >>justification in this case. Doing it right is cheap, so we should. >> >> --Richard >> >> > >> > Cheers, >> > S. >> > >> > [1] https://tools.ietf.org/html/rfc6376 >> >> _______________________________________________ >> 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 ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Thu Jul 30 16:59:08 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8176B1B2AE5 for ; Thu, 30 Jul 2015 16:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.392 X-Spam-Level: X-Spam-Status: No, score=0.392 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, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=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 k8woS03JKUJE for ; Thu, 30 Jul 2015 16:59:04 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 14B241B2AB5 for ; Thu, 30 Jul 2015 16:57:51 -0700 (PDT) Received: (qmail 28438 invoked by uid 0); 30 Jul 2015 23:57:49 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 30 Jul 2015 23:57:48 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id ytda1q01J1MNPNq01tddzp; Thu, 30 Jul 2015 23:37:48 -0600 X-Authority-Analysis: v=2.1 cv=Qc314Krv c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=15FYYZ9mYYQA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=YQA3agX6zLcA:10 a=zOBTXjUuO1YA:10 a=U6J5ibo-AAAA:8 a=iuCujQbmAAAA:8 a=hGBaWAWWAAAA:8 a=48vgC7mUAAAA:8 a=VfgTrTGYAAAA:8 a=yyvXFlbYYZHthFzPMa0A:9 a=RcLd4yrJk50XbkuN:21 a=f1a5sWq17pGAGkQD:21 a=wPNLvfGTeEIA:10 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; bh=S8T8NzV3l2H4lIXjTZoKw4UhCmw+ut66ctbv+WCXpws=; b=A7RUd0jswOutK7/m3tRSuNDLBTbGkFMD8KsLrQP/cB5nPe8xXp2aBpnTXSs4ic4atAH+UWsl1G0pHm3uKT2uFUfptAHHkz5wC5cC6TyCfqpbfgfrbqGr96gZMLvxJQZT; Received: from [100.36.26.202] (port=54723 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZKxOJ-0001sg-62; Thu, 30 Jul 2015 17:37:35 -0600 User-Agent: Microsoft-MacOutlook/14.5.3.150624 Date: Thu, 30 Jul 2015 19:37:30 -0400 From: Richard Shockey To: Henning Schulzrinne , "Peterson, Jon" , Alex Bobotek , Richard Barnes Message-ID: Thread-Topic: [stir] On OCSP, TNs, and Privacy References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.26.202 authed with richard+shockey.us} Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 23:59:06 -0000 Fair enough but the club here,for the time being, are the entities that have been assigned telephone numbers by a duly constituted National Numbering Authority. That is where I would suggest the trust model begins and as the network evolves we can look at how other assignees deal with the model. So where is the trust anchor? We are not going to decide that issue here. And Brian has a point in that we can look at a Forrest Guide if this gets complicated. I=B9ve always felt we had a much simpler problem in securing the numbering plan since the trust anchor could be mandated by the relevant NRA. Absolute power is sometimes sometimes absolutely fabulous. This was always a multi faceted problem that required a multi faceted solution.=20 Part one got solved with the recent FCC order that gave the carriers the legal right ( safe harbor ) to block a call given a clear and explicit request from the consumer or the enterprise. This is where several National Regulatory Authorities want to go. The second part was creating the tools to actually examine the INVITE to validate the origin of the call.That is the STIR problem. BTW this is only applicable to a transitioned networks. If anyone believes this is going to work for existing TDM networks the need to consult their drug counsellors. It will not happen. The third was the display to the consumer of information on call origin and reputation data from the validation process in order for the called party to to make a informed decision on whether to accept the session. This still includes all smaller carriers and all sorts of folks, or at least that is what I read into the recent R&O. Look at the chain of trust. I see no technical impediment to having 3rd party=B9s manage various aspects of this system for those SP that do not have the resources to manage this.=20 In SIDR the RPKI trust model begins with the RIR=B9s and flows accordingly. So far it seems to work though implementation is voluntary. I have good reason to believe there is a strong core among NA carriers that=20 actually wants to do something. Its willing to make the investment if the deployment scenarios is not deplorable.(pun intended) Granted its been a while since I was a WG chair around here but I don=B9t see the kind of open, multi-stakeholder consensus driven process that leads to deployable cost effective solutions. I emphasize multi-stakeholder and we know who the stake holders are and consensus. And someone presumably has to get a budget to get any of this deployed so as usual =B3Money is the answer what is the question?=B2 applies. Jon if you want to be part of the solution and not the problem itself then you have to reengage. This whole discussion looks like something I=B9d see out of the US Congress. On 7/30/15, 3:12 PM, "Henning Schulzrinne" wrote: >I think it's helpful to describe specific deployment scenarios and their >trade-offs - not to pick one, but to make sure we have one or more >plausible systems stories. I would advise caution when discussions arise >that seem to favor a "club" of large carriers and that disadvantage >smaller carriers or entities. Anti-trust lawyers don't like that, I've >been told. > >If we get back down from philosophy to engineering, we seem to be >discussing three different models (leaving CRL/revocation aside): > >(1) A "wildcard" model: An entity signs with a private key that's part of >a certificate for all numbers. Essentially, this simply says "this call >originated by Carrier A". Maybe you'd get the cert along with the OCN >from NECA. > >(2) A "multi-TN-per-cert" model: The cert applies to ten to (maybe) >hundred numbers, enumerated or identified by range/prefix. If number >porting is frequent, this means that either the certs become >over-inclusive (which may not be a major problem) or need to be >re-issued. Example: with a typical mobile churn rate of around 2% per >month=20 >(http://www.statista.com/statistics/283511/average-monthly-churn-rate-top- >wireless-carriers-us/), a ten-TN cert would have a 19% chance each month >of being incorrect. > >(3) A single-TN per cert model. > >The number of public-private key pairs is independent of the choice, as >mentioned by Richard B. > >If certs are delivered out-of-band, caching determines the number of HTTP >servers needed. #1 will have near-perfect hit ratios (unless carriers use >lots of certs), #3 will have a poor hit ratio, particularly if the OCSP >object is stapled on and part of the cache. #2 will be somewhere >in-between. The alternative is to do what it's being done for LRN lookup, >i.e., download the cert database and pub-sub updates. For 800M US >numbers, we're talking 800 GB of data for model #3, or about 100 GB a day >with OCSP or 1 GB/day with 2 year cert lifetime and some other (e.g., >pub-sub) invalidation mechanism. > >Obviously, the three models can co-exist. > >Random googling claims that there are 3 B calls in the US per day. A >significant fraction is likely within the same carrier or may otherwise >not require validation or downloading (e.g., because of caching), so this >is an upper bound for our purpose. According to > >https://wrongsideofmemphis.wordpress.com/2013/10/21/requests-per-second-a- >reference/ > >2,000 RPS are "is a decent amount of load for a normal server for a >regular service." > >This translates to roughly 0.2 B requests per server per day, so for all >of the US, across all carriers, we're talking 15 servers. (As noted, cert >retrieval is a trivial static file/object download, so this doesn't seem >unrealistic even without custom-designed stacks.) My guess is that SBCs >and cert servers will be paired in practice, for a variety of logistical, >network access (e.g., VPN) and fate-sharing reasons, but that's obviously >an implementation detail. > >If a carrier needs hundreds of servers for cert delivery, they may want >to check if they are still hoarding 3B2's. > >(There is obviously separate overhead for SIP request signing and >validation, but that doesn't depend on the model #1, #2 or #3, just on >key lengths and algorithm.) > >My back of the envelope is full, but I'm sure others can add more. > >Henning > >________________________________________ >From: Peterson, Jon >Sent: Thursday, July 30, 2015 11:27 AM >To: Alex Bobotek; Richard Barnes; Stephen Farrell >Cc: stir@ietf.org; Gorman, Pierce A [CTO]; PFAUTZ, PENN L; Richard >Shockey; Henning Schulzrinne >Subject: Re: [stir] On OCSP, TNs, and Privacy > >I don't think those properties are very different from what RFC3325 >provides. If all you care about is that someone you deem a "network >operator" has asserted the originating TN, then PAI is surely adequate. > >The scope of STIR is different, however. We are considering a more >pluralist world, after the IP transition, wherein a somewhat messy mixture >of network operators, enterprises, and even end users could hold >credentials that let them sign telephone calls. In that environment, the >credentials need to reflect more than just the identity of the signer: >they need to reflect number assignment itself. > >Personally, I agree that in this world I would not want to require holders >of large number blocks (carriers) to have a cert per TN. And I totally >agree that in that world, it would make sense for carrier policies to >involve mutual trust that is based on the subject of certificates rather >than the TNAuthList. But in STIR we're defining what goes on the wire, and >in the certs, rather than the particulars of operator policy. We're >providing mechanisms that will help in the messier cases, which may not >need to be exercised in cases that look more like traditional PSTN >operator handoffs. > >Yes, STIR treats a more complex world operationally than the effectively >closed network of the PSTN, which RFC3325 tries to emulate. But it is the >world that is coming, as far as I can tell. > >Jon Peterson >Neustar, Inc. > >On 7/29/15, 11:50 AM, "Alex Bobotek" wrote: > >>Arguably the most important thing STIR can do is to help service >>providers make intelligent policy decisions. An endpoint (aka the >>recipient's phone) policy decision based solely on STIR validation >>results will not be anywhere near as effective as one based on a large >>network or even crowd-sourced view. Network-based inputs such as >>complaints, submissions of unwanted voicemail, call volumetrics, calling >>graphs, reputation of the originating service provider, reputation of the >>originating TN, account history, call completion records and call >>durations are important. Privacy considerations make many of these >>inputs difficult to crowd source. And these inputs are difficult to >>provide to an endpoint even with new standards, but could be conveyed >>either as an aggregate score or individual parameters. Endpoint policy >>enforcement should of course be supported, but we should recognize that >>network-based enforcement is in practice the most widely adopted and >>effective policy enforcement >> implementation (e.g., in email and SMS spaces). >> >>Therefore STIR should provide network operators with >> * a validated identity of the originating service provider, and >> * a validated originating service provider assertion of the >>originating >>TN. (Note: this might be provided to networks but not endpoints in >>cases where caller ID is masked.) >>This provides much needed technical information and accountability for >>technical and non-technical enforcement. >> >>Operational considerations are the primary barrier to STIR implementation >>-- what's easy to create in a lab may take many years and thousands of >>servers to be implemented in a complex telco production environment. >>STIR should consider these as dominant drivers. It is much more >>practical for a telco to manage a dozen or so of its private-public key >>pairs than to create and manage a per-TN (> 100M TNs in the case of some >>carriers) certificate infrastructure. Adding a per-call database dip or >>per-TN cache is a huge impact. >> >>Public key distribution to carriers can be accomplished using some >>existing lookup-based registry, and/or via attached certificates. Using >>a registry already accessible to policy/routing engines is IMHO more >>practical in a service provider environment. >> >>Regards, >> >>Alex From nobody Thu Jul 30 18:38:10 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8B71A00BE for ; Thu, 30 Jul 2015 18:38:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 d8QlRd4OAaCh for ; Thu, 30 Jul 2015 18:38:06 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D2E1A00D4 for ; Thu, 30 Jul 2015 18:38:05 -0700 (PDT) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-11v.sys.comcast.net with comcast id ypcj1q0054ueUHc01pe4f2; Fri, 31 Jul 2015 01:38:04 +0000 Received: from BOBO1A.bobotek.net ([76.22.113.196]) by resomta-po-03v.sys.comcast.net with comcast id ype11q00M4EJ4tY01pe1lU; Fri, 31 Jul 2015 01:38:04 +0000 Received: from BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad]) by BOBO1A.bobotek.net ([fe80::4851:b4bb:416a:e1ad%10]) with mapi; Thu, 30 Jul 2015 15:25:30 -0700 From: Alex Bobotek To: "Peterson, Jon" , Richard Barnes , Stephen Farrell Date: Thu, 30 Jul 2015 15:27:43 -0700 Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLpo71wZyAoryUWyV/ENo5W4tZ3wbvkAgAAgjQCAAJs4gIAABZ6AgAAApgCAAALIAIAAUOCAgAAO0ACAACgVAIAAB5iAgACyDgCAAD2oAIAAXZOAgADkMYCAADO1wA== Message-ID: <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1438306684; bh=RXrVmAn+i7CBEgG0HyYtQwsQDBV4LcPQ4UiAQ+Ymo+c=; h=Received:Received:Received:From:To:Date:Subject:Message-ID: Content-Type:MIME-Version; b=rkPx/GI94Yzr59e5Qe67BW4ZJjX1q7tsEpl7SJnhTPy8sMFIRJ6vmEJ0quOwRNXG1 09LXtOPoyV/UdIzathjSpOQVCtJS2MNT7t0qS+ePuQyEKjGc3kjYzA2g8sp1KR1IAV qb6mTCoHMsapzBETv6xtZOxg/UBLkmMGUKqPw6C7w7wVyKYHDkcJxBYmJ/YdY9CX5v K7YD2F1YjJHWdKfwqxmmr4y0CjmxAOJVeoxnSgIzsmXSkJZz01QxyeoH9NhPZn4LEW JWaJAVXQT3M8tctPm1E3NhsWnjFRMJ4xpd5TlG8vXqYbiQlXu8ajxeT1V2i/cAyNQ4 a+fbHk4r9l/1g== Archived-At: Cc: Henning Schulzrinne , "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Richard Shockey Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 01:38:09 -0000 Jon, The basic STIR requirements require a trusted identity assertion at or near= origination that can be validated at or near termination. While the conce= pt of PAI is close (and IHMO is very useful in many but an insufficient num= ber of existing scenarios), I do not see how it can provide the needed func= tionality. I see that you are one of the authors of RFC3325 and undoubtedl= y have a better understanding than I of it. So if I don't understand, I ho= pe you will set me straight. Here are some issues I see with PAI as define= d in standards: The Boolean trust model assumed in RFC3325 and removal/replacements specifi= ed in RFC3325 prevent conveyance of information from originating to termina= ting service providers. PAI may not traverse proxies, and may not identify= the originating provider by the time it reaches a terminating provider. C= ryptographic signatures rather than chains of trust seem to be the most fea= sible solution. =20 Further, we IMHO need a system that allows for and is interoperable with id= entity assertions made by a party other than a service provider. =20 Regards, Alex > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Thursday, July 30, 2015 8:27 AM > To: Alex Bobotek ; Richard Barnes ; > Stephen Farrell > Cc: stir@ietf.org; Gorman, Pierce A [CTO] ; > PFAUTZ, PENN L ; Richard Shockey > ; Henning Schulzrinne > Subject: Re: [stir] On OCSP, TNs, and Privacy >=20 >=20 > I don't think those properties are very different from what RFC3325 provi= des. > If all you care about is that someone you deem a "network operator" has > asserted the originating TN, then PAI is surely adequate. >=20 > The scope of STIR is different, however. We are considering a more plural= ist > world, after the IP transition, wherein a somewhat messy mixture of > network operators, enterprises, and even end users could hold credentials > that let them sign telephone calls. In that environment, the credentials = need > to reflect more than just the identity of the signer: > they need to reflect number assignment itself. >=20 > Personally, I agree that in this world I would not want to require holder= s of > large number blocks (carriers) to have a cert per TN. And I totally agree= that > in that world, it would make sense for carrier policies to involve mutual= trust > that is based on the subject of certificates rather than the TNAuthList. = But in > STIR we're defining what goes on the wire, and in the certs, rather than = the > particulars of operator policy. We're providing mechanisms that will help= in > the messier cases, which may not need to be exercised in cases that look > more like traditional PSTN operator handoffs. >=20 > Yes, STIR treats a more complex world operationally than the effectively > closed network of the PSTN, which RFC3325 tries to emulate. But it is the > world that is coming, as far as I can tell. >=20 > Jon Peterson > Neustar, Inc. >=20 > On 7/29/15, 11:50 AM, "Alex Bobotek" wrote: >=20 > >Arguably the most important thing STIR can do is to help service > >providers make intelligent policy decisions. An endpoint (aka the > >recipient's phone) policy decision based solely on STIR validation > >results will not be anywhere near as effective as one based on a large > >network or even crowd-sourced view. Network-based inputs such as > >complaints, submissions of unwanted voicemail, call volumetrics, > >calling graphs, reputation of the originating service provider, > >reputation of the originating TN, account history, call completion > >records and call durations are important. Privacy considerations make > >many of these inputs difficult to crowd source. And these inputs are > >difficult to provide to an endpoint even with new standards, but could > >be conveyed either as an aggregate score or individual parameters. > >Endpoint policy enforcement should of course be supported, but we > >should recognize that network-based enforcement is in practice the most > >widely adopted and effective policy enforcement > > implementation (e.g., in email and SMS spaces). > > > >Therefore STIR should provide network operators with > > * a validated identity of the originating service provider, and > > * a validated originating service provider assertion of the > >originating TN. (Note: this might be provided to networks but not > >endpoints in cases where caller ID is masked.) This provides much > >needed technical information and accountability for technical and > >non-technical enforcement. > > > >Operational considerations are the primary barrier to STIR > >implementation > >-- what's easy to create in a lab may take many years and thousands of > >servers to be implemented in a complex telco production environment. > >STIR should consider these as dominant drivers. It is much more > >practical for a telco to manage a dozen or so of its private-public key > >pairs than to create and manage a per-TN (> 100M TNs in the case of > >some > >carriers) certificate infrastructure. Adding a per-call database dip > >or per-TN cache is a huge impact. > > > >Public key distribution to carriers can be accomplished using some > >existing lookup-based registry, and/or via attached certificates. > >Using a registry already accessible to policy/routing engines is IMHO > >more practical in a service provider environment. > > > >Regards, > > > >Alex > > > > > > > >> -----Original Message----- > >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Barnes > >> Sent: Wednesday, July 29, 2015 6:15 AM > >> To: Stephen Farrell > >> Cc: Henning Schulzrinne ; stir@ietf.org; > >> Gorman, Pierce A [CTO] ; PFAUTZ, PENN L > >> ; Richard Shockey > >> Subject: Re: [stir] On OCSP, TNs, and Privacy > >> > >> On Wed, Jul 29, 2015 at 5:34 AM, Stephen Farrell > >> > >> wrote: > >> > > >> > Hi Richard, > >> > > >> > On 28/07/15 23:57, Richard Barnes wrote: > >> >> You are correct that if we build a putative security solution > >> >> based on public keys passed DNS, it will not be an IETF protocol. > >> >> It will not become an RFC because it will not meet the IETF's > >> >> security > >>standards. > >> > > >> > Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e. not > >> > a Proposed Standard) that does exactly that and that is in > >> > widespread use and that does not require DNSSEC. > >> > That is ok in that context because a bad signature is the same as a > >> > missing signature. > >> > > >> > If this WG wanted to use a DKIM-like solution and could justify the > >> > lack of 3rd party cryptographic binding between the TN and the > >> > public key, that could be entirely analogous. > >> > > >> > I'm not saying the WG should do that, but it could. > >> > >> Yeah, I guess what I'm saying is that I don't really see that > >>justification in this case. Doing it right is cheap, so we should. > >> > >> --Richard > >> > >> > > >> > Cheers, > >> > S. > >> > > >> > [1] https://tools.ietf.org/html/rfc6376 > >> > >> _______________________________________________ > >> 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 From nobody Thu Jul 30 18:49:12 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC691A00A1 for ; Thu, 30 Jul 2015 18:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ouUZw67axE4b for ; Thu, 30 Jul 2015 18:49:08 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9251A00FF for ; Thu, 30 Jul 2015 18:49:08 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 414dab55.2b87afe32940.4673390.00-2464.13259086.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 31 Jul 2015 01:49:08 +0000 (UTC) X-MXL-Hash: 55bad41409a9ce17-ec24fcdcbb68ad2e95fd605d08e726d776d11981 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 214dab55.0.4673383.00-2058.13259058.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 31 Jul 2015 01:49:07 +0000 (UTC) X-MXL-Hash: 55bad413241d42ec-b8851d68b2b669296f716280af0174742f1d6c09 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 t6V1n5Ah029251; Thu, 30 Jul 2015 21:49:05 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6V1mqH8029150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Jul 2015 21:48:52 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 31 Jul 2015 01:48:35 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.200]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0224.002; Thu, 30 Jul 2015 21:48:35 -0400 From: "DOLLY, MARTIN C" To: Alex Bobotek Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyYT7vVsjGeB+H0aKZAlcHlFXg53xwZKAgACyDgCAAD2oAIAAXZOAgAFZjICAAHWEgP//9RDW Date: Fri, 31 Jul 2015 01:48:34 +0000 Message-ID: <4366DFBE-3078-4B38-9A8F-DC7A89C86EAB@att.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> , <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net> In-Reply-To: <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OuH4PVDt c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=zOBTXjUuO1YA:10 a=VfgTrTGYAAAA:8 a=hGBaW] X-AnalysisOut: [AWWAAAA:8 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=BQHToeOamOjg] X-AnalysisOut: [UMFi-S4A:9 a=CjuIK1q_8ugA:10 a=MZRBdPjlsfU-IyLr:21 a=213iI] X-AnalysisOut: [XLiLfaJwJPF:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Cc: "Peterson, Jon" , Richard Barnes , Richard Shockey , "stir@ietf.org" , "Gorman, Pierce A \[CTO\]" , "PFAUTZ, PENN L" , Stephen Farrell , Henning Schulzrinne Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 01:49:11 -0000 Not correct Sent from my iPhone > On Jul 30, 2015, at 9:38 PM, Alex Bobotek wrote: >=20 > Jon, >=20 > The basic STIR requirements require a trusted identity assertion at or ne= ar origination that can be validated at or near termination. While the con= cept of PAI is close (and IHMO is very useful in many but an insufficient n= umber of existing scenarios), I do not see how it can provide the needed fu= nctionality. I see that you are one of the authors of RFC3325 and undoubte= dly have a better understanding than I of it. So if I don't understand, I = hope you will set me straight. Here are some issues I see with PAI as defi= ned in standards: >=20 > The Boolean trust model assumed in RFC3325 and removal/replacements speci= fied in RFC3325 prevent conveyance of information from originating to termi= nating service providers. PAI may not traverse proxies, and may not identi= fy the originating provider by the time it reaches a terminating provider. = Cryptographic signatures rather than chains of trust seem to be the most f= easible solution. =20 >=20 > Further, we IMHO need a system that allows for and is interoperable with = identity assertions made by a party other than a service provider. =20 >=20 > Regards, >=20 > Alex >> -----Original Message----- >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >> Sent: Thursday, July 30, 2015 8:27 AM >> To: Alex Bobotek ; Richard Barnes ; >> Stephen Farrell >> Cc: stir@ietf.org; Gorman, Pierce A [CTO] ; >> PFAUTZ, PENN L ; Richard Shockey >> ; Henning Schulzrinne >> Subject: Re: [stir] On OCSP, TNs, and Privacy >>=20 >>=20 >> I don't think those properties are very different from what RFC3325 prov= ides. >> If all you care about is that someone you deem a "network operator" has >> asserted the originating TN, then PAI is surely adequate. >>=20 >> The scope of STIR is different, however. We are considering a more plura= list >> world, after the IP transition, wherein a somewhat messy mixture of >> network operators, enterprises, and even end users could hold credential= s >> that let them sign telephone calls. In that environment, the credentials= need >> to reflect more than just the identity of the signer: >> they need to reflect number assignment itself. >>=20 >> Personally, I agree that in this world I would not want to require holde= rs of >> large number blocks (carriers) to have a cert per TN. And I totally agre= e that >> in that world, it would make sense for carrier policies to involve mutua= l trust >> that is based on the subject of certificates rather than the TNAuthList.= But in >> STIR we're defining what goes on the wire, and in the certs, rather than= the >> particulars of operator policy. We're providing mechanisms that will hel= p in >> the messier cases, which may not need to be exercised in cases that look >> more like traditional PSTN operator handoffs. >>=20 >> Yes, STIR treats a more complex world operationally than the effectively >> closed network of the PSTN, which RFC3325 tries to emulate. But it is th= e >> world that is coming, as far as I can tell. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >>> On 7/29/15, 11:50 AM, "Alex Bobotek" wrote: >>>=20 >>> Arguably the most important thing STIR can do is to help service >>> providers make intelligent policy decisions. An endpoint (aka the >>> recipient's phone) policy decision based solely on STIR validation >>> results will not be anywhere near as effective as one based on a large >>> network or even crowd-sourced view. Network-based inputs such as >>> complaints, submissions of unwanted voicemail, call volumetrics, >>> calling graphs, reputation of the originating service provider, >>> reputation of the originating TN, account history, call completion >>> records and call durations are important. Privacy considerations make >>> many of these inputs difficult to crowd source. And these inputs are >>> difficult to provide to an endpoint even with new standards, but could >>> be conveyed either as an aggregate score or individual parameters. >>> Endpoint policy enforcement should of course be supported, but we >>> should recognize that network-based enforcement is in practice the most >>> widely adopted and effective policy enforcement >>> implementation (e.g., in email and SMS spaces). >>>=20 >>> Therefore STIR should provide network operators with >>> * a validated identity of the originating service provider, and >>> * a validated originating service provider assertion of the >>> originating TN. (Note: this might be provided to networks but not >>> endpoints in cases where caller ID is masked.) This provides much >>> needed technical information and accountability for technical and >>> non-technical enforcement. >>>=20 >>> Operational considerations are the primary barrier to STIR >>> implementation >>> -- what's easy to create in a lab may take many years and thousands of >>> servers to be implemented in a complex telco production environment. >>> STIR should consider these as dominant drivers. It is much more >>> practical for a telco to manage a dozen or so of its private-public key >>> pairs than to create and manage a per-TN (> 100M TNs in the case of >>> some >>> carriers) certificate infrastructure. Adding a per-call database dip >>> or per-TN cache is a huge impact. >>>=20 >>> Public key distribution to carriers can be accomplished using some >>> existing lookup-based registry, and/or via attached certificates. >>> Using a registry already accessible to policy/routing engines is IMHO >>> more practical in a service provider environment. >>>=20 >>> Regards, >>>=20 >>> Alex >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Barnes >>>> Sent: Wednesday, July 29, 2015 6:15 AM >>>> To: Stephen Farrell >>>> Cc: Henning Schulzrinne ; stir@ietf.org; >>>> Gorman, Pierce A [CTO] ; PFAUTZ, PENN L >>>> ; Richard Shockey >>>> Subject: Re: [stir] On OCSP, TNs, and Privacy >>>>=20 >>>> On Wed, Jul 29, 2015 at 5:34 AM, Stephen Farrell >>>> >>>> wrote: >>>>>=20 >>>>> Hi Richard, >>>>>=20 >>>>>> On 28/07/15 23:57, Richard Barnes wrote: >>>>>> You are correct that if we build a putative security solution >>>>>> based on public keys passed DNS, it will not be an IETF protocol. >>>>>> It will not become an RFC because it will not meet the IETF's >>>>>> security >>>> standards. >>>>>=20 >>>>> Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e. not >>>>> a Proposed Standard) that does exactly that and that is in >>>>> widespread use and that does not require DNSSEC. >>>>> That is ok in that context because a bad signature is the same as a >>>>> missing signature. >>>>>=20 >>>>> If this WG wanted to use a DKIM-like solution and could justify the >>>>> lack of 3rd party cryptographic binding between the TN and the >>>>> public key, that could be entirely analogous. >>>>>=20 >>>>> I'm not saying the WG should do that, but it could. >>>>=20 >>>> Yeah, I guess what I'm saying is that I don't really see that >>>> justification in this case. Doing it right is cheap, so we should. >>>>=20 >>>> --Richard >>>>=20 >>>>>=20 >>>>> Cheers, >>>>> S. >>>>>=20 >>>>> [1] https://tools.ietf.org/html/rfc6376 >>>>=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 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Fri Jul 31 09:27:08 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D4E1ACEBF for ; Fri, 31 Jul 2015 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ObfYJ7PN4BIU for ; Fri, 31 Jul 2015 09:27:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0129.outbound.protection.outlook.com [207.46.100.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98DB21A8AE5 for ; Fri, 31 Jul 2015 09:27:02 -0700 (PDT) Received: from BY2FFO11OLC007.protection.gbl (10.1.14.33) by BY2FFO11HUB053.protection.gbl (10.1.14.242) with Microsoft SMTP Server (TLS) id 15.1.231.11; Fri, 31 Jul 2015 16:27:00 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; fcc.gov; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2FFO11OLC007.mail.protection.outlook.com (10.1.14.254) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Fri, 31 Jul 2015 16:27:00 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6VGQiqq034951; Fri, 31 Jul 2015 11:26:59 -0500 Received: from plswe13m07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by plsapdm2.corp.sprint.com with ESMTP id 1vxgn2y64a-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2015 11:26:59 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 31 Jul 2015 11:26:58 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Fri, 31 Jul 2015 11:26:58 -0500 From: "Gorman, Pierce A [CTO]" To: Alex Bobotek , "Peterson, Jon" , Richard Barnes , Stephen Farrell Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3wbvkAgAAgjQCAAJs4gIAABZ6AgAAApgCAAALIAIAAUOCAgAAO0ACAACgVAIAAB5iAgACyDgCAAD2oAIAAXZOAgADkMYCAADO1wIABnOsA Date: Fri, 31 Jul 2015 16:26:57 +0000 Message-ID: <9d00e5dc922741449bbdff104b95fedd@PLSWE13M08.ad.sprint.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net> In-Reply-To: <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC007; 1:tdaW8CfjleUXo08/oHstI9Syazh94E8DaGsPMm0rGuzUbENiXvI0eY4wb1uFShYrjkzWJxoEWqebeytljhz9fiYBEWJW5urIguncVCD+ZmxqdALap0ozRqaeHeswFrwlzyVvudcH7ytFfmPvNgMaEpP4v2VHZUzPqE9gj2X8QigRM3y2d/lShqJmEl0qiFkKSh3R1bcns2apSGa1x+27R8QNHXLvxpb1dVheYCnkCMpS6AcB7fxoSVHrV0pESUjXMJwF145kGNhgU3yLnNLN+z9MJyU16y9pORq34nN6HtV2AyQ/7+7b75u8d+iRCjJUfaPkNSEUhGgOqfC5TFKyyg== X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(479174004)(377454003)(24454002)(189002)(199003)(13464003)(2656002)(50466002)(50986999)(54356999)(92566002)(76176999)(47776003)(102836002)(15975445007)(77156002)(87936001)(46102003)(33646002)(62966003)(46406003)(2900100001)(2950100001)(86362001)(5001770100001)(5890100001)(5250100002)(5003600100002)(19580405001)(93886004)(19580395003)(6806004)(108616004)(106116001)(5001960100002)(23726002)(106466001)(24736003)(189998001)(97756001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB053; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB053; 2:qaxD0zTqC1ZXbSZ8wReEa6US9efN6g9U1+6g455hiy9WFjV2Vhu/bbWiMHj+mksh0ohwAwzlyeHT8+w9+LcpHOGdkAaCPTdvb2BKNPgG1Vy/ctiIjJpQfDhywSV5YLvuDOQgsGkUqOEFXZsdQRHbEfaP+dxcqRy7Uls3D7vIolg=; 3:OLfWOqe0fJuR96kvJghI5w6Z+TRt28FlpQbL3aUenKRYNeQix2SbFtQ3WMS0xBnzaH5PDaluDL4xjLof/QZyrxLQGHtfsWLJzfkpQxUFkwRsNXHlPEZZvj97BbSwz0Kf2OrNk68q4Kax5Xma7AZp5GEHSSDW73DrZU4my41QwiLgHLIAHb1zMIFD392ysTyMY+ONqiWEEjX8oMG1Mlkg0WQx8/TmdUAlq8cH7w5mupwig2gStVYj/mS/Mk1yOJW1; 25:v5qpLu9IEy5V0J3LckMcqT2/jYSd81XddZofJvPYWM6xV9o15r3YVGNt5q23B/f+aUvjAFAaY9QRngP9jt5ONoX/AlhB9Zz16H6TBwrzfT4iLy5BZdH5foc33427Ojs3s+SsQbIsd7+/cYHnO2/b/MXjWZgmp17XPvbR8kqUwm7Va0NmX/SkLPK50wq6o7RiGXW2P0qkd4nnu7RJtUSj9kTgmbaeBTLhyh+OI/YO3bCJZxkvN5lX1oFvrDbEqhJAYQQwsoGT3ufcmV7/YW4iSA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB053; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB053; 20:tpB5YEhdPeC80vwb8+pCRZsg3eHfF0UBhOrM6BuNRmO/26qQqw93u2VAaSKTQRGhgNKnjTWuS2AFWLJZ1uJhBf7R4e1wtnkjXc93URHJh6iJcqCdcMrOQWDYjm3uTY1VDQ6DxAxu8yFAWIXB6qw1sscaXbtRBoA9/pwZ2kkAglH+f/b+FEurGL7SI5cyHkMDvhGfBr+pOEj9R+aEqMoN2Gqmiv6ztGd1j3JPUgPVnwwu+6bjQf8foyzUYzSCuvkO; 4:EsKrTc7Jlo7hVAURQsNaAeUDmxtxmWkIlGVwxdxTCsnUJyG4eEZIHEYQoqCaMb9EJqU7cWO9k/i9ECWAKVt6XFF1ovengpOWvPANnIU3X4JmW1hj0h+bQGLscwON8Bpb8SrK0TSBLQnKHhFoiExuGpyRvh4gqpY1Cb0m8t1iQx5nvk8+q5YxME5bias3HXW/L/8mMXirhm6kvieDsvBqH2TbQaIZxctjJeTe5cL4cBkZJJmpDN8COvL9qVSAV7m93EWVNOXxfcHHQP5OqYCHF7KHvjpWXWY/1dDJwPmMwX4= BY2FFO11HUB053: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2FFO11HUB053; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB053; X-Forefront-PRVS: 0654257CF5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB053; 23:z5OaCPyng8BC5QGUPcRIGLHOkBrVXGbBxCcMKqyr?= =?us-ascii?Q?fkGNo5O6pUuS1AULGJ4KEZyQW+nUXlbFpjnDUTNRM8R7PWKBdU+B7IsivS16?= =?us-ascii?Q?MkoDXcGsYrEIiZGY0FPOfT888FHvE5omRFonNeP5kCpQi2YH32vfIqElz7t+?= =?us-ascii?Q?qSGS9gtwvQbxAYbF2JO+H8gszZi+aqlq2hem+osjWZO29x+fGEyl9Bwek6U5?= =?us-ascii?Q?oBal+MKBrlsnc2+5uSEhbnHzpUWFN8/c1sJrsdbjmn0X1SaY7T8a9fh6YNd9?= =?us-ascii?Q?KohJ0qe1lOgFxXoFn92zyfP5L4g7Riz0rI1clAeOxN2tlmoPxvSKxsPqfvjI?= =?us-ascii?Q?ECMW9hY3XoTPcDd3R9gtx/jr2Uaiik/AvmHravn+dR/FbxrDH9XHHu0i2uib?= =?us-ascii?Q?wA6fSXkurzROaQaxecNsb6CSZGfsoeZC+HbnLnOCglbZHicqceJzO1XsVNAH?= =?us-ascii?Q?8bpFTOj161zqRdapJoarGjddWauu+cChJBb8VxcK38J+dIgfWCMst75WyPYx?= =?us-ascii?Q?/3A4KuYAK902a6uqOmGP2ERHrSc7UVcEi/4FAxU1gGiFnJ1ljvBpPY5QHP4D?= =?us-ascii?Q?JTUcJ3u0z20HtthTS3Jh+8l2fFC7gOuFCTnAs0xSVONR9g/bJuGSKuOY3Wps?= =?us-ascii?Q?q2G7wSeNX0taDjRj5bPd+LkyL89PFcmvgGNpSntiO1FTTsk6iZa18z+kRyEd?= =?us-ascii?Q?2bMZsXXdiioDQlOa2oCXCE9T1MoktO48ExXQ7AtEo4Q/c7zXdlBDVAGrdUOb?= =?us-ascii?Q?P2QoRrTuHfdWY4KSDcBx4//4Kgro9wroojAlfrlPrF3owzBCLlNrK5aWq0Wg?= =?us-ascii?Q?XjGXaPoQYM+m6wjGG5R/XxSlOBTH7BRuND+ZWnyjDPIUbLHZ0mSjRSegD+EH?= =?us-ascii?Q?311vyODstacDOHh+PPOD3B3R3abnDsyhPgUYto6XpIz05LwLI78CK0C8WlEk?= =?us-ascii?Q?9QRgfnkAkpsOlidfI2ZxAFDYm3Kl9oZHDxI7cMu9aS2IXMy9j0CaRTFBdKze?= =?us-ascii?Q?pVPDPXSXfU6GgJCdnk2Kr2n3UeGggJpxY63sB3Wrz+w1vdTrum+zb8RNX78f?= =?us-ascii?Q?1fWXh2SkEHP8bAM9j9URx6aqkvWecF8q6RGq4u99gDW35UnafeaUiH4msW86?= =?us-ascii?Q?SeRD5riuWYRoKU9I5fyGVYmeoy9kJfVT?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB053; 5:bwfEFS86Gq0B2Q+BZ0Up/pP/dK2Cz3XiolescRzcq0PuvYpLJ46u55VhHnIio4n+qnMNBCq7Ob15+XSv5g1HibxDp9rHMNNe7E+6Eb/QvdqEr5AP9xvu4SxHQkORwn1N9zlNqkC6jTihm8sFMuY1uA==; 24:6+8tfEkGhcLmeVtcY4CiBo8+8DoQ8QBUorKqYUUNY5ZqV4yOTseojPAzv2XrNQR55d5IJTaNRqlLUclMuLLob/Z1UkamiLEDp0Hl1HTqrJg= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2015 16:27:00.7364 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB053 Archived-At: Cc: "stir@ietf.org" , Henning Schulzrinne , "PFAUTZ, PENN L" , Richard Shockey Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 16:27:06 -0000 Jon, 1. I'll do my best to help STIR get implemented when it is either required = by mandate or just to remain relevant. 2. I personally think STIR will be an expensive, painful, and futile game o= f wack-a-rat (especially thanks to buying computing resources in the cloud = using a credit card and the MODERN WG assuming they will be "successful" in= their attempts to bypass traditional policy development and automate provi= sioning of TNs over the Inernet at the user and non-carrier levels). 3. I think it would be cheaper and more effective for carriers to remind th= eir customers not to trust anyone who calls them that they don't personally= know (and maybe not some of them either). The real danger to consumers is not telephone calls with an unauthenticated= calling ID. The real threat is from the monumental tsunami of bad behavio= r on non-voice Internet-based communications. Firewalls, SPAM filters, vir= us protection software, honey-pots and AUTHENTICATION and encryption protoc= ols have regularly failed to prevent phishing, pharming, intrusion, and tru= ly staggering amounts of theft and misuse of credit card, identity, and oth= er personal information, including the most recent egregious example of the= cyberattack on the US Federal Government's Office of Personnel Management = which acquired sensitive information on every single US federal employee (i= ncluding Henning?). I'm not wishing for the days of the 1980s telephone network. I'm looking f= orward to the days when folks finally realize the Internet is the Wild West= of the 1880s. I know none of this is helpful in your quest to develop a useless protocol,= but saying it anyway. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Alex Bobotek [mailto:alex@bobotek.net] Sent: July 30, 2015 5:28 PM To: Peterson, Jon ; Richard Barnes ; = Stephen Farrell Cc: stir@ietf.org; Gorman, Pierce A [CTO] ; PFAUT= Z, PENN L ; Richard Shockey ; Henning S= chulzrinne Subject: RE: [stir] On OCSP, TNs, and Privacy Jon, The basic STIR requirements require a trusted identity assertion at or near= origination that can be validated at or near termination. While the conce= pt of PAI is close (and IHMO is very useful in many but an insufficient num= ber of existing scenarios), I do not see how it can provide the needed func= tionality. I see that you are one of the authors of RFC3325 and undoubtedl= y have a better understanding than I of it. So if I don't understand, I ho= pe you will set me straight. Here are some issues I see with PAI as define= d in standards: The Boolean trust model assumed in RFC3325 and removal/replacements specifi= ed in RFC3325 prevent conveyance of information from originating to termina= ting service providers. PAI may not traverse proxies, and may not identify= the originating provider by the time it reaches a terminating provider. C= ryptographic signatures rather than chains of trust seem to be the most fea= sible solution. Further, we IMHO need a system that allows for and is interoperable with id= entity assertions made by a party other than a service provider. Regards, Alex > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Thursday, July 30, 2015 8:27 AM > To: Alex Bobotek ; Richard Barnes ; > Stephen Farrell > Cc: stir@ietf.org; Gorman, Pierce A [CTO] ; > PFAUTZ, PENN L ; Richard Shockey ; > Henning Schulzrinne > Subject: Re: [stir] On OCSP, TNs, and Privacy > > > I don't think those properties are very different from what RFC3325 provi= des. > If all you care about is that someone you deem a "network operator" > has asserted the originating TN, then PAI is surely adequate. > > The scope of STIR is different, however. We are considering a more > pluralist world, after the IP transition, wherein a somewhat messy > mixture of network operators, enterprises, and even end users could > hold credentials that let them sign telephone calls. In that > environment, the credentials need to reflect more than just the identity = of the signer: > they need to reflect number assignment itself. > > Personally, I agree that in this world I would not want to require > holders of large number blocks (carriers) to have a cert per TN. And I > totally agree that in that world, it would make sense for carrier > policies to involve mutual trust that is based on the subject of > certificates rather than the TNAuthList. But in STIR we're defining > what goes on the wire, and in the certs, rather than the particulars > of operator policy. We're providing mechanisms that will help in the > messier cases, which may not need to be exercised in cases that look more= like traditional PSTN operator handoffs. > > Yes, STIR treats a more complex world operationally than the > effectively closed network of the PSTN, which RFC3325 tries to > emulate. But it is the world that is coming, as far as I can tell. > > Jon Peterson > Neustar, Inc. > > On 7/29/15, 11:50 AM, "Alex Bobotek" wrote: > > >Arguably the most important thing STIR can do is to help service > >providers make intelligent policy decisions. An endpoint (aka the > >recipient's phone) policy decision based solely on STIR validation > >results will not be anywhere near as effective as one based on a > >large network or even crowd-sourced view. Network-based inputs such > >as complaints, submissions of unwanted voicemail, call volumetrics, > >calling graphs, reputation of the originating service provider, > >reputation of the originating TN, account history, call completion > >records and call durations are important. Privacy considerations > >make many of these inputs difficult to crowd source. And these > >inputs are difficult to provide to an endpoint even with new > >standards, but could be conveyed either as an aggregate score or individ= ual parameters. > >Endpoint policy enforcement should of course be supported, but we > >should recognize that network-based enforcement is in practice the > >most widely adopted and effective policy enforcement > > implementation (e.g., in email and SMS spaces). > > > >Therefore STIR should provide network operators with > >* a validated identity of the originating service provider, and > >* a validated originating service provider assertion of the > >originating TN. (Note: this might be provided to networks but not > >endpoints in cases where caller ID is masked.) This provides much > >needed technical information and accountability for technical and > >non-technical enforcement. > > > >Operational considerations are the primary barrier to STIR > >implementation > >-- what's easy to create in a lab may take many years and thousands > >of servers to be implemented in a complex telco production environment. > >STIR should consider these as dominant drivers. It is much more > >practical for a telco to manage a dozen or so of its private-public > >key pairs than to create and manage a per-TN (> 100M TNs in the case > >of some > >carriers) certificate infrastructure. Adding a per-call database dip > >or per-TN cache is a huge impact. > > > >Public key distribution to carriers can be accomplished using some > >existing lookup-based registry, and/or via attached certificates. > >Using a registry already accessible to policy/routing engines is IMHO > >more practical in a service provider environment. > > > >Regards, > > > >Alex > > > > > > > >> -----Original Message----- > >> From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard > >> Barnes > >> Sent: Wednesday, July 29, 2015 6:15 AM > >> To: Stephen Farrell > >> Cc: Henning Schulzrinne ; > >> stir@ietf.org; Gorman, Pierce A [CTO] ; > >> PFAUTZ, PENN L ; Richard Shockey > >> > >> Subject: Re: [stir] On OCSP, TNs, and Privacy > >> > >> On Wed, Jul 29, 2015 at 5:34 AM, Stephen Farrell > >> > >> wrote: > >> > > >> > Hi Richard, > >> > > >> > On 28/07/15 23:57, Richard Barnes wrote: > >> >> You are correct that if we build a putative security solution > >> >> based on public keys passed DNS, it will not be an IETF protocol. > >> >> It will not become an RFC because it will not meet the IETF's > >> >> security > >>standards. > >> > > >> > Eh, that's not accurate. DKIM [1] is an Internet Standard (i.e. > >> > not a Proposed Standard) that does exactly that and that is in > >> > widespread use and that does not require DNSSEC. > >> > That is ok in that context because a bad signature is the same as > >> > a missing signature. > >> > > >> > If this WG wanted to use a DKIM-like solution and could justify > >> > the lack of 3rd party cryptographic binding between the TN and > >> > the public key, that could be entirely analogous. > >> > > >> > I'm not saying the WG should do that, but it could. > >> > >> Yeah, I guess what I'm saying is that I don't really see that > >>justification in this case. Doing it right is cheap, so we should. > >> > >> --Richard > >> > >> > > >> > Cheers, > >> > S. > >> > > >> > [1] https://tools.ietf.org/html/rfc6376 > >> > >> _______________________________________________ > >> 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 ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Fri Jul 31 09:42:25 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14261B2E65 for ; Fri, 31 Jul 2015 09:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HIYjUB3ieoCH for ; Fri, 31 Jul 2015 09:42:22 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id C9E601B2E59 for ; Fri, 31 Jul 2015 09:42:12 -0700 (PDT) From: Henning Schulzrinne To: "Gorman, Pierce A [CTO]" Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAJs4gIAABZ6AgAAApgCAAAEaoIAAUo6AgAAO0ACAACgVAIAAB5mAgACyDgCAAD2nAIAAXZOAgAFZjYCAAHWDgIABLYmAgAADsyo= Date: Fri, 31 Jul 2015 16:42:09 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net>, <9d00e5dc922741449bbdff104b95fedd@PLSWE13M08.ad.sprint.com> In-Reply-To: <9d00e5dc922741449bbdff104b95fedd@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 5:kHYGDryUpfmMkbE0wayGH1AUgS4pXPHr8hPALcjMQJplFrek619EY75Jq1ZQuO6Dg95uJtzJAIeQt/RQpWUb1nDO8sykftOMvOqZbuufUc/WOnpiYeVVFgu+sDoIj+zFechkiiABMFy4OWcShM10aw==; 24:8D7QE/kFP678GvZeWc1bilSJ847BBD5t5yVm92ImlZu1DPR5wzfvS/2hGz+iyFbBZLtMRVY8MdYqnPprPE0KQhNTMjNj+nkvdaOd9bw4574=; 20:ON058Y8gU7AzB6UWOnQNXNmsQ1LJgPQKe3pO7xF/G5nHvvJ9kyy+gDmDqaLQTeezBs5zdosMOzmXKozjg49Nog== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0633; cy1pr09mb0633: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(90715002)(15975445007)(50986999)(19580395003)(33656002)(93886004)(76576001)(99286002)(66066001)(2950100001)(46102003)(74316001)(106116001)(87936001)(62966003)(54356999)(77096005)(2900100001)(77156002)(102836002)(2656002)(86362001)(92566002)(40100003)(5003600100002)(5001960100002)(19580405001)(110136002)(122556002)(5002640100001)(5001920100001)(189998001)(76176999)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 16:42:09.7400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 16:42:25 -0000 Just today, I came across http://www.usatoday.com/story/money/columnist/tompor/2015/07/23/irs-scam-ca= lls-and-threats-heat-up-summer/30575555/ which provides some real-life context for our work. I'm sure the victims wo= uld appreciate your advice just to be smarter. Henning ________________________________________ From: Gorman, Pierce A [CTO] Sent: Friday, July 31, 2015 12:26 PM To: Alex Bobotek; Peterson, Jon; Richard Barnes; Stephen Farrell Cc: stir@ietf.org; PFAUTZ, PENN L; Richard Shockey; Henning Schulzrinne Subject: RE: [stir] On OCSP, TNs, and Privacy Jon, 1. I'll do my best to help STIR get implemented when it is either required = by mandate or just to remain relevant. 2. I personally think STIR will be an expensive, painful, and futile game o= f wack-a-rat (especially thanks to buying computing resources in the cloud = using a credit card and the MODERN WG assuming they will be "successful" in= their attempts to bypass traditional policy development and automate provi= sioning of TNs over the Inernet at the user and non-carrier levels). 3. I think it would be cheaper and more effective for carriers to remind th= eir customers not to trust anyone who calls them that they don't personally= know (and maybe not some of them either). The real danger to consumers is not telephone calls with an unauthenticated= calling ID. The real threat is from the monumental tsunami of bad behavio= r on non-voice Internet-based communications. Firewalls, SPAM filters, vir= us protection software, honey-pots and AUTHENTICATION and encryption protoc= ols have regularly failed to prevent phishing, pharming, intrusion, and tru= ly staggering amounts of theft and misuse of credit card, identity, and oth= er personal information, including the most recent egregious example of the= cyberattack on the US Federal Government's Office of Personnel Management = which acquired sensitive information on every single US federal employee (i= ncluding Henning?). I'm not wishing for the days of the 1980s telephone network. I'm looking f= orward to the days when folks finally realize the Internet is the Wild West= of the 1880s. I know none of this is helpful in your quest to develop a useless protocol,= but saying it anyway. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com From nobody Fri Jul 31 09:44:52 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A568D1B2E59 for ; Fri, 31 Jul 2015 09:44:51 -0700 (PDT) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 6rRTT1SOcufq for ; Fri, 31 Jul 2015 09:44:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF8C1B2D67 for ; Fri, 31 Jul 2015 09:44:49 -0700 (PDT) Received: from BY2FFO11OLC016.protection.gbl (10.1.14.33) by BY2FFO11HUB041.protection.gbl (10.1.14.82) with Microsoft SMTP Server (TLS) id 15.1.231.11; Fri, 31 Jul 2015 16:44:29 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2FFO11OLC016.mail.protection.outlook.com (10.1.15.61) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Fri, 31 Jul 2015 16:44:29 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6VGcCsi048475; Fri, 31 Jul 2015 11:44:28 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm2.corp.sprint.com with ESMTP id 1vxgn2ybpa-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2015 11:44:28 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 31 Jul 2015 12:44:27 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Fri, 31 Jul 2015 11:44:27 -0500 From: "Gorman, Pierce A [CTO]" To: Henning Schulzrinne Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3wbvkAgAAgjQCAAJs4gIAABZ6AgAAApgCAAALIAIAAUOCAgAAO0ACAACgVAIAAB5iAgACyDgCAAD2oAIAAXZOAgADkMYCAADO1wIABnOsAgABb74D//6xoEA== Date: Fri, 31 Jul 2015 16:44:26 +0000 Message-ID: <5df30a39092446a4a7d8a6bdf6b3b2ea@PLSWE13M08.ad.sprint.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net>, <9d00e5dc922741449bbdff104b95fedd@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC016; 1:Xdh9h3bBOkNjrqUv0MKr38oFaYdc3zGO1B6AWSMZGQokKF3jn40/rHS98nDHzErgyoy1e4+z3mIvRyVQ9CL7EQ3mxqfMciIv6C0AVv5NG9lQzvZ8gjUm2yZ1Xd5BhdTrL0fly/KIxpg8sRNIhyfVTMv+wZ49yr03BeuC7pqpVkzI7bDoTJqL4c8Z+9tCpsJGAPRV9ApARjPNHFg7LgnOpQ9NQ9u7ciN3cTrWy9THywHJGRruzuwhmpTDzq6RgrrAS8Iw+SKH3SR/mqIyMCd0qo8YYqtk889i9TRWhF9JjGSsc/JkQi0i1Q1c+AkXm6bh X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(189002)(13464003)(377454003)(199003)(90715002)(108616004)(6806004)(5001960100002)(106116001)(97756001)(92566002)(106466001)(2656002)(19580405001)(19580395003)(93886004)(24736003)(110136002)(87936001)(86362001)(46102003)(2950100001)(2900100001)(77156002)(5250100002)(62966003)(15975445007)(102836002)(54356999)(23726002)(76176999)(47776003)(50466002)(50986999)(189998001)(5003600100002)(46406003)(33646002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB041; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB041; 2:MT/rikwf3vBjEeSV0H7dsZ8VE/ETianX/oYinTwEj2qWH8y9UsxGuj+BnkY69sbsk/A6nzBFo+KoeMULdqax7WTcKS7qTehIRv00wK5umd320WAii0vR2auZkZ1aeOL1+pH34MQ+JHCesvSTxwQXaO/AJLBGwZhKJIZO9UxH0WM=; 3:phUiaszhnMMBK4KgWu1oL3fnA7nv+M9cDCG8li+Uy4U78V6wMq6gna14xNeb9pHGgpLdRwkHoh1MRtiKMJDdYSVH0+zTp3aZNtUP4X7/MrjAx/bShbQgtwGkJ8QGtBT9tGyMMe+FJRES93eQNfGSya/C9ShiI6GMMH1f7/K4NIMzaGjjVUE0CTjEt+6PgIyFvyB/+lziCfv80V1z//BWE9wM18NTEC8NW2PRGhHHyVph/eIhPR55puFAjo6qQfjd; 25:fAeGMrAN/tlx6WP6GGB+/iPAgDbc/wMz58E5EV/a446Ekecw7buADu6Y/NBvJ/5tbXHKF0pXn4KVgurGLxLg/uTF7pahGp28ADvKwUsUjPeqIAs78yuFw0axIgjBnzsXx39+MuMDaN2+kD383TzBzPHtxGcv2tpYW8mFmHi4TTAetuzugTLCHWjHVz14MV913MuRe2ddfO8eUgZXLBLzOXAA8CX8v7Arv9Ho1n+TW9ziLJknmYvSdDS0Ta8n3S930hZxVCarI1+KzBMUVHlj3w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB041; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB041; 20:HA++f/JjONuhfIj9bpfQcaKpWOuKrZEV4aeZMShL7POr8kwkPOOCJ+xSvUj1NJKaqrG1NYvfrIIKhjUkUqtPo1sgSSCvyBrExCXBbyPeyw2a3OBKN1w+0W5ifjJnaepm2Cs3z4RP1s3fhpiGy0khk8zQbU9trp6Svz0q2tgiNsBXE6pu+F0/IRMR8KyckCzGWiKI8BEyE11UqBmA1aCwujJmA7G6Fc3ry91OVU+OQoL+C8L81J35Taipcj/v8uxP; 4:RXhvaSo27tR4VhBMXGc1g0c3qCx5Fg6GLe92/grL0x1DEalXP51MDGecBfWwdcRorq7joqZl1p3Sk9aeEDGRdsVQ/4Upq7yMyqRc5bdxPxa7c8Wi7RCKEAyjD+g704iVn/8IdPygA9WzHv22N21yg9hSSXoVPCYPXPFt7UgWhE4YtlrZ9w8e3NFqywfiYuJ2RQnipcXga1pqkVs/G7YOvpVBpbQ5nSjvJV7GQx0DhyclWO2apWWGs2KRQEznGK5wjY8/3BIxG7HXB8H6qavl8wyjZ3Q2j3RQBVoZNPmy6ZQ= BY2FFO11HUB041: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2FFO11HUB041; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB041; X-Forefront-PRVS: 0654257CF5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB041; 23:1tQVgOEX9f2bn/q4zgCeY28AV4sy3zWAklzlEHca?= =?us-ascii?Q?MHC7Ha68qvur5hy+H0V+lKcuFwsSZCiIDQ62CQ/+NLUO1/2z9yIyTK/h35Zd?= =?us-ascii?Q?8k3xUQu0ctTS/rComt2sx8gor/t1bYgKMyJz2AwJUpnlUtMgC3ny+DNTJsGW?= =?us-ascii?Q?mPaE0SzpvNv9RmfmGHSdfYtshpfAQGmTa2FarFoSxUId9nGQmOsp8e44MMMX?= =?us-ascii?Q?Q58rV8j/YLGaWCVrNzloR6OW/VHvRF4zBTj4pmVsR7VrNI0SmHSMPRTPNGkO?= =?us-ascii?Q?/zSDCG6mcFPuDOfAvNRpukq2QApXCn4hruNhmXQTnlw3hULTGgsbh2FVQLsO?= =?us-ascii?Q?81Ml9WCyxgIGm+3Y95CHkHUifimsCq7Zo/CzBcCPRlcg2Sp1w80zH2+SZuhY?= =?us-ascii?Q?9hJJfO69e4qY5A7Vhvt7VPss4tUa4Ai1Zu6PQgy250+iXUA6Wgy/1JdHTirv?= =?us-ascii?Q?aQtfRe2iv8OzWMjyOsBPC8mEOYovgyvlRWTqGHj3V0+q3/FeDN1OQ5f2aJEg?= =?us-ascii?Q?+fymUjgIGowBdO/vPqRHesxwfsIBtmbWTRGI4RkHaMuD0wY4ijcn8vG//g6v?= =?us-ascii?Q?f+XN0P4lBc5km2EJvQh0yB87fAGknyq08K7ypnceVwTLgK/ZnqVRRb/wfnnj?= =?us-ascii?Q?0Dqkq7yUUwPD1qEwHAPGEe/9beka0/MqQqyZvvwafDxa11yE/J0LxR0feAD7?= =?us-ascii?Q?OqaLtwdA7t4szX15GFlOHsuIlgle2wGcaVtSiJYQ0MWUrJfE1KycguPo38kh?= =?us-ascii?Q?b1aeN59H3uMSHi50kYPdlgm1FUCwp6qritTpZ68kklw9+erwSFepNjJAsi/0?= =?us-ascii?Q?dUpkbGFHpGdRZ9D3UeocO7AslPss/yt10YXwXW/0uYglCmUALZnZxHVeSvna?= =?us-ascii?Q?VjbiNsOuIdNPt7j2nVi89ce5CJ3SA6OJ82HP9ooaXOptILpacHt7cRyY8RFd?= =?us-ascii?Q?OCvHAWnYyNBDA1+KA6NwJzD3rb0vgg6yk8JOkWiKwqFSy7p11UicB472b+oh?= =?us-ascii?Q?69i7RPkNinUnTT/QPpjNWRWw8x0dOiLUBmwxzACr1YQAAx6nCP0KuqwMkt4L?= =?us-ascii?Q?MqIfYNxemBYd8ss4mFvhbms2i/AF?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB041; 5:qKeI13c/TgfWbiftu1R1rlj/K9EvuTR3uTQLUohOgtIyWqlsBnZbRM3Y2HpC/Sg9tHdttuAx2ZL4N+IdR5b48bx7Rbdc8ikRDpxx4Tup4cjhMD3KqtMDvuzc6ayGY2Wr8uho7Ku4wWtXGXw0x+yHQA==; 24:nbkdBBb0ABfuoOhDf9n0TDgzZ3Gixbro1SkO6PQHgp+QUZpcpQKiXsjkH8MWZCrWhj8FYGuAtv0NoMoR/K3QjFk47o6XbYVKdTAbYbgaanE= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2015 16:44:29.7107 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB041 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 16:44:51 -0000 Henning, What in an authenticated Calling ID will prevent these calls from happening= ? (By the way, I've received one of the IRS variety and another on my work= phone that looked like it was the US but was most likely from India.) Pierce -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: July 31, 2015 11:42 AM To: Gorman, Pierce A [CTO] Cc: stir@ietf.org Subject: Re: [stir] On OCSP, TNs, and Privacy Just today, I came across http://www.usatoday.com/story/money/columnist/tompor/2015/07/23/irs-scam-ca= lls-and-threats-heat-up-summer/30575555/ which provides some real-life context for our work. I'm sure the victims wo= uld appreciate your advice just to be smarter. Henning ________________________________________ From: Gorman, Pierce A [CTO] Sent: Friday, July 31, 2015 12:26 PM To: Alex Bobotek; Peterson, Jon; Richard Barnes; Stephen Farrell Cc: stir@ietf.org; PFAUTZ, PENN L; Richard Shockey; Henning Schulzrinne Subject: RE: [stir] On OCSP, TNs, and Privacy Jon, 1. I'll do my best to help STIR get implemented when it is either required = by mandate or just to remain relevant. 2. I personally think STIR will be an expensive, painful, and futile game o= f wack-a-rat (especially thanks to buying computing resources in the cloud = using a credit card and the MODERN WG assuming they will be "successful" in= their attempts to bypass traditional policy development and automate provi= sioning of TNs over the Inernet at the user and non-carrier levels). 3. I think it would be cheaper and more effective for carriers to remind th= eir customers not to trust anyone who calls them that they don't personally= know (and maybe not some of them either). The real danger to consumers is not telephone calls with an unauthenticated= calling ID. The real threat is from the monumental tsunami of bad behavio= r on non-voice Internet-based communications. Firewalls, SPAM filters, vir= us protection software, honey-pots and AUTHENTICATION and encryption protoc= ols have regularly failed to prevent phishing, pharming, intrusion, and tru= ly staggering amounts of theft and misuse of credit card, identity, and oth= er personal information, including the most recent egregious example of the= cyberattack on the US Federal Government's Office of Personnel Management = which acquired sensitive information on every single US federal employee (i= ncluding Henning?). I'm not wishing for the days of the 1980s telephone network. I'm looking f= orward to the days when folks finally realize the Internet is the Wild West= of the 1880s. I know none of this is helpful in your quest to develop a useless protocol,= but saying it anyway. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Fri Jul 31 10:04:13 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06561A892E for ; Fri, 31 Jul 2015 10:04:11 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3O4GbE7odVP9 for ; Fri, 31 Jul 2015 10:04:06 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08321A896A for ; Fri, 31 Jul 2015 10:04:05 -0700 (PDT) Received: from BL2FFO11FD042.protection.gbl (10.173.160.31) by BL2FFO11HUB040.protection.gbl (10.173.160.246) with Microsoft SMTP Server (TLS) id 15.1.231.11; Fri, 31 Jul 2015 17:04:05 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com; Received: from preapdm3.corp.sprint.com (144.230.32.82) by BL2FFO11FD042.mail.protection.outlook.com (10.173.161.138) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Fri, 31 Jul 2015 17:04:04 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6VH3gju014285; Fri, 31 Jul 2015 13:04:04 -0400 Received: from prewe13m08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by preapdm3.corp.sprint.com with ESMTP id 1vxgn2yjnh-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2015 13:04:04 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 31 Jul 2015 13:04:02 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Fri, 31 Jul 2015 12:03:59 -0500 From: "Gorman, Pierce A [CTO]" To: Henning Schulzrinne Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3wbvkAgAAgjQCAAJs4gIAABZ6AgAAApgCAAALIAIAAUOCAgAAO0ACAACgVAIAAB5iAgACyDgCAAD2oAIAAXZOAgADkMYCAADO1wIABnOsAgABb74D//6xoEIAAAPyA Date: Fri, 31 Jul 2015 17:03:58 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net>, <9d00e5dc922741449bbdff104b95fedd@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD042; 1:QBvkevxkZ7k3buWDvNnude6Sj7JPAFy+RGyC74sEndwFuXPinTCvriQJe3Fjp90PnxSaLIaCfCQLCD8WRDGOsdiVX2obLCIGi64fjGSfq5b5YU6OIkT5LxOsOjA1QEtHiX11HeMGKi1v0Eg3T9hW9s2xSvSvt2N3ay2RdMzQbQZIhyMSNZQVDp9zgPsoP+mSZNJKeuVu9NLgkuM2Y9zgEVAGQ4zMm9MnnQke5aDGdG0IKd1av93Ug6h1P6ui81ILNtLOVyJuQ9NKBvGg5CVV1bgxExI6/c3z2+8MTSt6HlOnL3tBGW+xU1WZEIsFyhck X-Forefront-Antispam-Report: CIP:144.230.32.82; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(13464003)(90715002)(377454003)(189002)(199003)(77156002)(50986999)(19580395003)(33646002)(46406003)(19580405001)(54356999)(15975445007)(50466002)(76176999)(62966003)(97756001)(23726002)(6806004)(102836002)(87936001)(86362001)(2656002)(24736003)(46102003)(5001960100002)(5003600100002)(110136002)(189998001)(5250100002)(47776003)(92566002)(106116001)(2900100001)(108616004)(106466001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB040; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB040; 2:rd1Yv1LQCd4dnnKcHFWfR4aDUT28NEftsILYKsUtJfwWtoE+XbI3U5zSMygs2ZW8G+u1A5bj1dumYGRqPZnJ6llQhmwt4bUf/79vUzxQI1mZvSPza4jVVIZFrXfi59MLzZ7Asig21b3VDLYimkePfT9oUJWdbfOZEw58ne6uuuM=; 3:DKSHmjtDB0HloWS4VN6C4yJB4KaMEiDw1wuR0B+55vgzN/9pIsmUUDjuddtJNaXhdev7K31rdNsBQsQm4swXVA9S4Orgznk8r+1NeRPVHwfi1txeuXD1CTz4jMcQUuehNf4A5P4KrHZyCZ4tCx0msjQJRZEQohQwtA0Hf6cUB6x2v8oklJgKUepgeVfW5NVEc6CSvNljV2MvWOVuMXCo5aEPM+h3wo5+TO92OqMwkUw=; 25:Srrkf3Q7ZBykRdxhDKjeUa6IfuP9hjgravs03/+6zgsoUFSftviZdqzMCiv4xWBPxLUj+W/W26Hoxh3W4o1P2wKsvXuKI3CUZPxD+6MIsVaRfI55IM6YHMqUDcWFD0KqJF+K15teQaKIchLb+vjUNQwz0PwT0MAz00Kf3WGeg+/Tnt91lryyroTyYp2EWHHrnNeFIX0Kqe4o76HsSw+G+X7EFWZ3BJKayyP2lXMw95piuTk8q4YbRQhe8iIvfshuAVhX7qvOe0Jnd5Te0PHs1w==; 20:pw88WjBxEoatLYQEmUuJgyE88RBvr+DaeYFP61s/OtBptbq1g2jJh0KzfgQJO987jN+eOxlvMhdn8+usXwk2Xz46ixWxej2g2FyR7/qt3ASCduwvlrdY8FObFYYg6oHe7Dxus3to1psArrb+uA2ZssGLlej5v+XaVg+SmemxdYQA48+TYRLFcXYLVwjtZnu0oDJ+F47pnG+5t4VznO1DRyRXSEKMhst1ija9J2UFk4LvyVMUnXXtdQO/fEgd801j X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB040; BL2FFO11HUB040: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BL2FFO11HUB040; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB040; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB040; 4:chMdKcdAjWwchIesqr/oo2ai1kdi1iQoBmaScfkfuFraB3FGbj+Ik8Ll26Q6Y66YS8f/yVcnwfOBwEKdMV9xnvv+g/v1rrB2GQDvEjUYZ8s8CkWa+US1GXG49Z9Gba/fCrq280lgK3h9RNEjfZJGmsuIT5733jyCJy253qsoWuWzpQrTo0rmkOMhdTNIICTuPWYswW7JERTaAWD9aRX4AYDMF7GPW/fJ/iTpXh4Q08eEDf/2Tko6X69pPwp5iyCcw57/prr/d3HBzoYymxSVbyS/epZJzFGN5W/ar/CVWRM= X-Forefront-PRVS: 0654257CF5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB040; 23:u2MPaSIYwJwH+Qc1/j1kvoD5NRRh6Bt2zhf50NUk?= =?us-ascii?Q?AZzlsRHDVmuaPJb65F2qpEtfRffOYOallpeUNszh1vSPITNdo+zw0KDZWbGE?= =?us-ascii?Q?+0GUvDOewVv7Ks7ETb7fsqE0p1zvTo63/VmwLheB23jBRoIoLzQkP/OJYJla?= =?us-ascii?Q?9navNYdhbDaWFO3bKiWorNuU+E8YEm8of+sXbft60VrOfq0HqvoprmfpKojK?= =?us-ascii?Q?2qoM3t4Pgga4XguPavZjS973js4ozPCi2IDsTFTTFcpY+KMN63Z5UOJgEti3?= =?us-ascii?Q?63c8YvN9Wu7DfK5vCvNhDbgCqXjBgHND/OIDIqRLe7Akljalxxfl8/ajUD//?= =?us-ascii?Q?HvGLi6dsnUQ1N4bG30MhaKyEDbDuuEkXWdxFaOHZeQIDOmNfHdxhBZL2jWp8?= =?us-ascii?Q?tCA9VOlqPkLDgNdP5whQ1TWiu+r2rTFp2JGCk6wQZw+YlG8UPvPEHfGK34m6?= =?us-ascii?Q?oQh1+IxAah3W6lp2/352BdGCgEEoLemtsd5C23+UU1cABDSQrjzK9pOygwOw?= =?us-ascii?Q?w646hkKOux8WJBYEtYEigi0C0o7pmDjZXPG9pT0ofl8LVCNWfRkKJWALsVZl?= =?us-ascii?Q?WAvWgv3FwgBCdo+m92yOuklMMPmqP9YHwVPrK5Va3peTizrtVRwpytJ0pMoQ?= =?us-ascii?Q?LX4ojvF91Dohj8Dwp4LUt/rmroaGMSaiVU5rYQ+uKPbZg7n/r3UVrh80NT8T?= =?us-ascii?Q?Rk0RjGzN6lvIF6AWzk9JR/sDqSMjn+6818qoEq+PvOkKWK5N/1TyhpYPWH3n?= =?us-ascii?Q?zd2tRO6T1kMLdPzxZp1PhZ0cRYuui+vl3ylR0L5HzezptcET1It6sBnBaXZR?= =?us-ascii?Q?GNENDscgKXiGRE7PRwa1PyDBEkGUILO04mQPEA5Bj6cxlVVcszF5j/XVezG5?= =?us-ascii?Q?5cSFJRRBDR1TMPdxu4K2IUcR04/oN9Va1cGBYIHOkqFjk23T9Jr9b+lm90Sk?= =?us-ascii?Q?SSdfYqmfL+KxitPkLt8ERB0KyogvwKDRfRs73jwDIUrCDl+DOqlyYqVSJ5Q+?= =?us-ascii?Q?tIukRGfduEdlgJP7i3mMkK0O3S4qewnPgJk01mc4FBTKMMqFkrlfFhtx77Vp?= =?us-ascii?Q?t3dfziQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB040; 5:npZgTO2kIgdyIfSlF29yPk3kNg6jKBCk/2IU6Rqe+4Y0G0Mfr72NCxC7Vly7uhvZT+uVjegJGj3uXC9n61zgJF8Atkp5ZK6/RnuA127YCpq1rDdQ2tLyrmuIf8aE3Bnn0RdtlJ9APB7LX3xDRFDbnw==; 24:cJJfmGRJOIpn/S+PGslzSsAnSqNfphuQ5GGkr5nhDUAj3HKsd0fvSAqG4U8IelTEeq4bjCNafCkqsS4jmMdvWllHhAiJtKsdVpyRFcgUgTM= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2015 17:04:04.6773 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB040 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:04:12 -0000 I am serious about my role and effort to get STIR implemented in our networ= k. When it comes time, for whatever reasons, I will be a staunch advocate = of getting it done (not kidding). Just because I personally don't like it = doesn't mean I won't work hard to get it done anyway. This won't the first= example of such an effort. OK to get back on target and try to be helpful (really). In our network I would favor a centralized and cached approach to applying = call admission policy using STIR and other information. I don't assume and= would not want user equipment dipping and validating anything. (A few hund= red semi-centralized platforms doing signaling and processing is fun enough= , let alone multiplying a handful of messages by 10s of millions during the= busy hour). I would prefer the network provided the endpoint an in-call-s= etup indication of authenticated, or not. Some policy questions (that I know won't be answered here - but that I will= risk proposing anyway) is what should be the safe-harbor practice(s) for c= arriers which block calls based on a user opt-in of call blocking on non-au= thenticated calling ID? Should they signal to the user that the call was b= locked and provide them the telephone number? Should they place a record i= n their monthly bill? Should they do something akin to a 3-way call where = they accept the call, place it on hold, setup a leg to the called party, an= d let them decide to accept the risk of answering an unauthenticated call? No answers required. Just food for thought and by way of response to folks= who think implementing STIR will be "cheap". Perhaps they'd like to setup= a fund to help pay for the specialized call signaling treatment, media anc= horing, fault and performance management and reporting, and billing capture= , development and operational costs? (And yes, all that and without preven= ting bad behavior and presumably without being able to charge a premium for= the placebo service.) Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com -----Original Message----- From: Gorman, Pierce A [CTO] Sent: July 31, 2015 11:44 AM To: 'Henning Schulzrinne' Cc: stir@ietf.org Subject: RE: [stir] On OCSP, TNs, and Privacy Henning, What in an authenticated Calling ID will prevent these calls from happening= ? (By the way, I've received one of the IRS variety and another on my work= phone that looked like it was the US but was most likely from India.) Pierce -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: July 31, 2015 11:42 AM To: Gorman, Pierce A [CTO] Cc: stir@ietf.org Subject: Re: [stir] On OCSP, TNs, and Privacy Just today, I came across http://www.usatoday.com/story/money/columnist/tompor/2015/07/23/irs-scam-ca= lls-and-threats-heat-up-summer/30575555/ which provides some real-life context for our work. I'm sure the victims wo= uld appreciate your advice just to be smarter. Henning ________________________________________ From: Gorman, Pierce A [CTO] Sent: Friday, July 31, 2015 12:26 PM To: Alex Bobotek; Peterson, Jon; Richard Barnes; Stephen Farrell Cc: stir@ietf.org; PFAUTZ, PENN L; Richard Shockey; Henning Schulzrinne Subject: RE: [stir] On OCSP, TNs, and Privacy Jon, 1. I'll do my best to help STIR get implemented when it is either required = by mandate or just to remain relevant. 2. I personally think STIR will be an expensive, painful, and futile game o= f wack-a-rat (especially thanks to buying computing resources in the cloud = using a credit card and the MODERN WG assuming they will be "successful" in= their attempts to bypass traditional policy development and automate provi= sioning of TNs over the Inernet at the user and non-carrier levels). 3. I think it would be cheaper and more effective for carriers to remind th= eir customers not to trust anyone who calls them that they don't personally= know (and maybe not some of them either). The real danger to consumers is not telephone calls with an unauthenticated= calling ID. The real threat is from the monumental tsunami of bad behavio= r on non-voice Internet-based communications. Firewalls, SPAM filters, vir= us protection software, honey-pots and AUTHENTICATION and encryption protoc= ols have regularly failed to prevent phishing, pharming, intrusion, and tru= ly staggering amounts of theft and misuse of credit card, identity, and oth= er personal information, including the most recent egregious example of the= cyberattack on the US Federal Government's Office of Personnel Management = which acquired sensitive information on every single US federal employee (i= ncluding Henning?). I'm not wishing for the days of the 1980s telephone network. I'm looking f= orward to the days when folks finally realize the Internet is the Wild West= of the 1880s. I know none of this is helpful in your quest to develop a useless protocol,= but saying it anyway. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Fri Jul 31 10:09:40 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF651B2F36 for ; Fri, 31 Jul 2015 10:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mACb4IV8PZ8L for ; Fri, 31 Jul 2015 10:09:36 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 07D161B2F05 for ; Fri, 31 Jul 2015 10:09:35 -0700 (PDT) From: Henning Schulzrinne To: "Gorman, Pierce A [CTO]" Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAJs4gIAABZ6AgAAApgCAAAEaoIAAUo6AgAAO0ACAACgVAIAAB5mAgACyDgCAAD2nAIAAXZOAgAFZjYCAAHWDgIABLYmAgAADsyqAAAEvAIAAAos8 Date: Fri, 31 Jul 2015 17:09:33 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net>, <9d00e5dc922741449bbdff104b95fedd@PLSWE13M08.ad.sprint.com> , <5df30a39092446a4a7d8a6bdf6b3b2ea@PLSWE13M08.ad.sprint.com> In-Reply-To: <5df30a39092446a4a7d8a6bdf6b3b2ea@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 5:hAiB2SXALYNi4Vlc2Q+2S8IcqRfrJr4vriDX9p/mgV3B7sxETsrn+hRfzxwFsmxcI9jDH1mRpnDmkn+tUXHTiDzmSfIffUYAcGnd6gBV9hwKJOygVEKjFbaToemZftn1xJ7de6x2rk1eb5FpRz4GWw==; 24:5sw4tfUvzmjN0yC6odNVOyDQ6ilY61rBC9SyN9jKzZ+Uoe22DYlXUifGvta3947zxG0wAh/ZgK8NeyFn+adpQdjGqZtSJf7H3UukBF876qA=; 20:tBMn+88sgI5z78AvyNrZbNphJa07aCh07nAOJGyo9ZBxw25mpL9SukyL8MZN0AUhfm2MSiENLsR4ZPkKdh2PKQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0634; cy1pr09mb0634: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(90715002)(377454003)(93886004)(15975445007)(2950100001)(33656002)(189998001)(92566002)(77096005)(5002640100001)(19580405001)(76576001)(40100003)(2900100001)(5001960100002)(122556002)(76176999)(106116001)(86362001)(19580395003)(102836002)(50986999)(5003600100002)(62966003)(77156002)(54356999)(46102003)(87936001)(66066001)(110136002)(2656002)(99286002)(74316001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 17:09:33.7716 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:09:39 -0000 The article doesn't go into details, but two ways: (1) We know that some of the fraudulent callers spoof local law enforcement= or IRS numbers to increase the chances of being believed. STIR wouldn't pr= event the calls, but reduce the chance of success. (2) As we have discussed, call filtering only works reliably if the filter = can trust the caller ID. (Otherwise, if call filtering becomes more common,= the bad guys will use even more spoofing than today.) Thus, I see the STIR work as a necessary ingredient to make call filtering = effective, which will in turn make the job of the bad guys much harder and = more expensive. (If they have to get a legitimate new number for every call= or every ten calls, their business model is likely to break down.) Henning ________________________________________ From: Gorman, Pierce A [CTO] Sent: Friday, July 31, 2015 12:44 PM To: Henning Schulzrinne Cc: stir@ietf.org Subject: RE: [stir] On OCSP, TNs, and Privacy Henning, What in an authenticated Calling ID will prevent these calls from happening= ? (By the way, I've received one of the IRS variety and another on my work= phone that looked like it was the US but was most likely from India.) Pierce -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: July 31, 2015 11:42 AM To: Gorman, Pierce A [CTO] Cc: stir@ietf.org Subject: Re: [stir] On OCSP, TNs, and Privacy Just today, I came across http://www.usatoday.com/story/money/columnist/tompor/2015/07/23/irs-scam-ca= lls-and-threats-heat-up-summer/30575555/ which provides some real-life context for our work. I'm sure the victims wo= uld appreciate your advice just to be smarter. Henning ________________________________________ From: Gorman, Pierce A [CTO] Sent: Friday, July 31, 2015 12:26 PM To: Alex Bobotek; Peterson, Jon; Richard Barnes; Stephen Farrell Cc: stir@ietf.org; PFAUTZ, PENN L; Richard Shockey; Henning Schulzrinne Subject: RE: [stir] On OCSP, TNs, and Privacy Jon, 1. I'll do my best to help STIR get implemented when it is either required = by mandate or just to remain relevant. 2. I personally think STIR will be an expensive, painful, and futile game o= f wack-a-rat (especially thanks to buying computing resources in the cloud = using a credit card and the MODERN WG assuming they will be "successful" in= their attempts to bypass traditional policy development and automate provi= sioning of TNs over the Inernet at the user and non-carrier levels). 3. I think it would be cheaper and more effective for carriers to remind th= eir customers not to trust anyone who calls them that they don't personally= know (and maybe not some of them either). The real danger to consumers is not telephone calls with an unauthenticated= calling ID. The real threat is from the monumental tsunami of bad behavio= r on non-voice Internet-based communications. Firewalls, SPAM filters, vir= us protection software, honey-pots and AUTHENTICATION and encryption protoc= ols have regularly failed to prevent phishing, pharming, intrusion, and tru= ly staggering amounts of theft and misuse of credit card, identity, and oth= er personal information, including the most recent egregious example of the= cyberattack on the US Federal Government's Office of Personnel Management = which acquired sensitive information on every single US federal employee (i= ncluding Henning?). I'm not wishing for the days of the 1980s telephone network. I'm looking f= orward to the days when folks finally realize the Internet is the Wild West= of the 1880s. I know none of this is helpful in your quest to develop a useless protocol,= but saying it anyway. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Fri Jul 31 10:16:48 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A321B2E9E for ; Fri, 31 Jul 2015 10:16:47 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 28pmD-o-3LV4 for ; Fri, 31 Jul 2015 10:16:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0108.outbound.protection.outlook.com [207.46.100.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B4D1B2E85 for ; Fri, 31 Jul 2015 10:16:44 -0700 (PDT) Received: from BY2FFO11OLC008.protection.gbl (10.1.14.31) by BY2FFO11HUB027.protection.gbl (10.1.14.113) with Microsoft SMTP Server (TLS) id 15.1.231.11; Fri, 31 Jul 2015 17:16:44 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com; Received: from preapdm1.corp.sprint.com (144.230.32.80) by BY2FFO11OLC008.mail.protection.outlook.com (10.1.14.255) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Fri, 31 Jul 2015 17:16:40 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6VH9Cu2049125; Fri, 31 Jul 2015 13:16:39 -0400 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by preapdm1.corp.sprint.com with ESMTP id 1vxgn3ypxp-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2015 13:16:39 -0400 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 31 Jul 2015 13:16:38 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Fri, 31 Jul 2015 12:16:38 -0500 From: "Gorman, Pierce A [CTO]" To: Henning Schulzrinne Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3wbvkAgAAgjQCAAJs4gIAABZ6AgAAApgCAAALIAIAAUOCAgAAO0ACAACgVAIAAB5iAgACyDgCAAD2oAIAAXZOAgADkMYCAADO1wIABnOsAgABb74D//6xoEIAAW0CA//+sfWA= Date: Fri, 31 Jul 2015 17:16:37 +0000 Message-ID: <510302dd38b54bc2981f5093b850d597@PLSWE13M08.ad.sprint.com> References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net>, <9d00e5dc922741449bbdff104b95fedd@PLSWE13M08.ad.sprint.com> , <5df30a39092446a4a7d8a6bdf6b3b2ea@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC008; 1:yTANrz24vyfT9a63K+payUN7rAdb7eMPL+uYI2j3smfrbzIfr2rxDaRrYCnf0XRrApzZqmp5hFbuJ0ZW9QYKJAfpfF16lj0+cPsidm8i96uRdHKeiXlpPwihUypvfdiSvZRCdyrYEckd92H+AuA1dE+5ITktmxbzRK0102geYyu8M6egXj2PlX7iHGiCxnwuKVS0EGQS5184MHP235TJnTcmdVyYz++ZTfy5axJMHcJHCS5EmgG+JKp0lE6LwXtndraI+9a+o7tg6DvufJLUaX0KQcj/1UaJpyM7hjIFihJfmReptfxu6Dzt7u+MqSWP X-Forefront-Antispam-Report: CIP:144.230.32.80; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(90715002)(377454003)(189002)(13464003)(199003)(102836002)(47776003)(19580405001)(6806004)(19580395003)(2900100001)(15975445007)(5250100002)(106466001)(2950100001)(2656002)(108616004)(93886004)(5001960100002)(189998001)(87936001)(86362001)(5003600100002)(76176999)(54356999)(110136002)(50986999)(50466002)(97756001)(23726002)(46102003)(24736003)(62966003)(92566002)(77156002)(33646002)(46406003)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB027; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB027; 2:xo3/ZI/tnrGQW5oWLTNZMeBvs7uitn+PYu5CFhp9BLEiplyEPGtfm9Em7/TxnHFdH/RnehVtsSvdUdF4wIHclF9XXXtmmGpAbt6PsXlwkUWzFX6LIFGghbPLY1mFU5mpQZ4BDEnCUQkJFXrmEgH/XNBKTeePFaN8fzIyoK83qN0=; 3:9er6BPvnbZSG4J1V9hqbG7f3TikmKS0A9hbpCA6V8PYLECgQnDAZUdnpY4gQ0xJl+yok8VXiRekzVnoXHru+WnqpEFX+KBNChhJvTixZii1OGTpPjJzz/CDTUyyVrNWnZVWA/axs/F0YqjCtOooPClOuXsObsNxqTg8pFYEpULxN6ph/P3+3zF6J5/ojHfQPBuEMI97EP3fo1njKxWDR/OvDaB3LDwAgSbt+o9CrNo8=; 25:4Y7vUk8GQRZ7RRuEO/RC/B5IoYT1X2MqdUT/CfaaHyvGnKbz7lDWlGNrE0eUHgkcCkZvh+Sn3OHwi1CFM+I6T3QQyxyVNVfI5ATRwlP55mIMveMk434EGdIe4CfaObMFWDge6zuYEtcWRhKJ/PtKjl4N5hVlMkU5AVfySMQvkDby+tl79T8HtUoZScO7JKcnNh3C8jcdrsBuDVevJSbMM8GWdovh9I8AFslO3tT30tfgRxKR+ZADoHSU7YSEm91jV+J54ns7/lTS6UgfGmNxCw==; 20:GiupO1Mm/fgTpJsmNI3iybCqaMGCvhSbxradXDCSvEvCJPkLhaLHCK4C41GpJu3dAAO+u4zOxBM8f3YMJLVp5SDFCgbL9iyuIYFbGHUs9u+ReQp3WjIzS7Dxf9yUfhvTRT2tC5hHmCY1y11zCy7KZaZX5Mk5PcqOUf2KaROCxc5mIbYKCL5HI6FECk1ElkkbsmbnFc0FpxPnS0rHJp6xvsf2eP5Bgr40wBp2GqCVMOv7M6cWs9EPyS7USvLCNDwe X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB027; BY2FFO11HUB027: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2FFO11HUB027; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB027; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB027; 4:pNSRTDOn3X3M7DsWn1l6tJXuEylrQnacKVwBZGY+L7ksW3xrrsLxlqifmbpN5lGGVu2szjdtIKS8y4KibeVKtEacO6D+y+cBvX7glg7WQE5gxLVrem1RKSNzOrhOL3XFgqo3OJKkLyLoouz94aTVmfng+vVt4MLI2Frs8HxNXEtm0ykQSKtSmtBfMFze7EbuXH2+1zVG95h4t+lR4Ha7bUZtWS4+TLUNaoUzj/7e8lp0zk+xFOoFYHGO9n7aSOob/57EKEsIFScm/ivqQio/TCd/AEvN6MrhTk5P8CN568A= X-Forefront-PRVS: 0654257CF5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB027; 23:zHh6fYI22Mj4MYSwrbOqPlphIKAuEJMSBu5zWrXv?= =?us-ascii?Q?lLCftEDUjlGIMaoJ0T6uQSQRA6Uq/Di9gb1hEYec9k+A5mBN+7Z68yCSl5US?= =?us-ascii?Q?qTCNuDxZuLCojzoccokOwqE4jUl8oLiGr6qLbxEgOSLnvGHH5IiEbSMvqQKe?= =?us-ascii?Q?RdraJ5qeBexWHKZ61jUHyi+Y+GPesmuuLHfrCMInaolNDaoJ1/MgUsU3XcEj?= =?us-ascii?Q?18HHDeDv2L7r1EARWwLr0TEFciOrrZI7z/uKSKxJIz9JiFkWzjPvD49A/sEF?= =?us-ascii?Q?Wpnf07Eo9NjHZlmPl13P2nVHzsbyd8MssZke9QEca7nNSBo07VHo66pFyXrX?= =?us-ascii?Q?xkHX/DOAv0H2L4KW0A6OIhhn/FiGMDI620U9d/C6HgRXXQwHg849qNtLvHsY?= =?us-ascii?Q?edm+h8bDe42Gqqq5i1evb7g+WdDbC1DCQuAMsxMB/BxW7LXgyYU4HfSe6bPI?= =?us-ascii?Q?yDDXTAkkI5wo5mSLt16Cifu1qS7Ut/9XxVtIlo27vRixVm5rR5YNqe27Nrs1?= =?us-ascii?Q?BGAwO4ExeRjg2viAAcAmlBsFri/EUHH7LngbOxbBzZ8SWCivdMy2JXNPoH43?= =?us-ascii?Q?uamwQ4hP7qtvR98PrAR6ssc2LhpbRUGIXPW2aL4uxtSIjd4V428/0tEHSb6x?= =?us-ascii?Q?7lAZH0LDLtdPIgYLmYmcAx8x8Jp0WyAlolZlNJmcCAshLrFgqapVVoV2Qxgg?= =?us-ascii?Q?AZK+dExa70eBJsQozuqdAcDZBlxS7kCrpS8T58ER8GPCCmYZVnkIYwoaAdl9?= =?us-ascii?Q?WJJVBm970YlHXa/qf6BCmoLBi3hBas3Ayr5VAAOK+qZ38oJDCFmkkGhiLiJx?= =?us-ascii?Q?B/PAoibm7UFTM3N+m22fXzkzUPqsQR8Z41S0fyeU9KSOEKTr6eMuev+La5sL?= =?us-ascii?Q?ve9L+WakqbX6/5g1t40yFDza1uR7UGS2tjhGNiH10+a53npnH86c9XVgB2LJ?= =?us-ascii?Q?i5tv3RkzoXXINtvAFP38dqCR4Y4mwQzwUguEQv9LRD+jNGmWzoWnjWOTK0SM?= =?us-ascii?Q?yLvyPWQYSX9CMY3nFiKSAykNT3bvD3SbfcPekwwH0p4rpCjnBYc3h/eV0kRn?= =?us-ascii?Q?VRMGHRFeCQxawKmZtLXUSmvi7GVj?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB027; 5:fvG5gEnstEccMt08+esxsSm+SRpAuhLNpfj3DQ9xdc2/vwCkR3tbKhd/Vqjc9e98wUJqouFrn+oXNG+LC1+gwjz69AWs5dI+J7xf89dbkwqYbwZ2mCqULLi2ixVoPlJ5Gwt7KRFINvo23VbFSmailg==; 24:4YNzpAVi2z+3kQk2VpnsCHgl8btth3GyUk4n6Xkp/pPD7MfkO5iKsbFvlcLTj9kdJKXLDr7FPlrAPBsh4/LrdpE1jRagY1pc9sjD08CBYUg= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2015 17:16:40.6400 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB027 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:16:47 -0000 If/when you're successful in MODERN, your last paragraph will be wrong star= ting at, "make the job of the bad guys much harder...". I think MODERN will make it trivial for them to cheaply get all the authent= icated numbers they want and impossible to track what got done with them. I think you're right about spoofing cutting down on spoofing law enforcemen= t and IRS numbers but how much will that matter? I don't know know my loca= l law enforcement telephone numbers or any IRS numbers. And FWIW, there is= a huge regional IRS processing center in Kansas City so I could get an aut= henticated call from just about anybody in the 816 area code and for all I = would know they really were with the IRS. Respectfully, Pierce Gorman -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: July 31, 2015 12:10 PM To: Gorman, Pierce A [CTO] Cc: stir@ietf.org Subject: Re: [stir] On OCSP, TNs, and Privacy The article doesn't go into details, but two ways: (1) We know that some of the fraudulent callers spoof local law enforcement= or IRS numbers to increase the chances of being believed. STIR wouldn't pr= event the calls, but reduce the chance of success. (2) As we have discussed, call filtering only works reliably if the filter = can trust the caller ID. (Otherwise, if call filtering becomes more common,= the bad guys will use even more spoofing than today.) Thus, I see the STIR work as a necessary ingredient to make call filtering = effective, which will in turn make the job of the bad guys much harder and = more expensive. (If they have to get a legitimate new number for every call= or every ten calls, their business model is likely to break down.) Henning ________________________________________ From: Gorman, Pierce A [CTO] Sent: Friday, July 31, 2015 12:44 PM To: Henning Schulzrinne Cc: stir@ietf.org Subject: RE: [stir] On OCSP, TNs, and Privacy Henning, What in an authenticated Calling ID will prevent these calls from happening= ? (By the way, I've received one of the IRS variety and another on my work= phone that looked like it was the US but was most likely from India.) Pierce -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: July 31, 2015 11:42 AM To: Gorman, Pierce A [CTO] Cc: stir@ietf.org Subject: Re: [stir] On OCSP, TNs, and Privacy Just today, I came across http://www.usatoday.com/story/money/columnist/tompor/2015/07/23/irs-scam-ca= lls-and-threats-heat-up-summer/30575555/ which provides some real-life context for our work. I'm sure the victims wo= uld appreciate your advice just to be smarter. Henning ________________________________________ From: Gorman, Pierce A [CTO] Sent: Friday, July 31, 2015 12:26 PM To: Alex Bobotek; Peterson, Jon; Richard Barnes; Stephen Farrell Cc: stir@ietf.org; PFAUTZ, PENN L; Richard Shockey; Henning Schulzrinne Subject: RE: [stir] On OCSP, TNs, and Privacy Jon, 1. I'll do my best to help STIR get implemented when it is either required = by mandate or just to remain relevant. 2. I personally think STIR will be an expensive, painful, and futile game o= f wack-a-rat (especially thanks to buying computing resources in the cloud = using a credit card and the MODERN WG assuming they will be "successful" in= their attempts to bypass traditional policy development and automate provi= sioning of TNs over the Inernet at the user and non-carrier levels). 3. I think it would be cheaper and more effective for carriers to remind th= eir customers not to trust anyone who calls them that they don't personally= know (and maybe not some of them either). The real danger to consumers is not telephone calls with an unauthenticated= calling ID. The real threat is from the monumental tsunami of bad behavio= r on non-voice Internet-based communications. Firewalls, SPAM filters, vir= us protection software, honey-pots and AUTHENTICATION and encryption protoc= ols have regularly failed to prevent phishing, pharming, intrusion, and tru= ly staggering amounts of theft and misuse of credit card, identity, and oth= er personal information, including the most recent egregious example of the= cyberattack on the US Federal Government's Office of Personnel Management = which acquired sensitive information on every single US federal employee (i= ncluding Henning?). I'm not wishing for the days of the 1980s telephone network. I'm looking f= orward to the days when folks finally realize the Internet is the Wild West= of the 1880s. I know none of this is helpful in your quest to develop a useless protocol,= but saying it anyway. Best regards, Pierce Gorman Core Network Planning O: 913-439-4368 pierce.gorman@sprint.com ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Fri Jul 31 10:36:15 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7873D1B3143 for ; Fri, 31 Jul 2015 10:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rSgtYTWhE7Q0 for ; Fri, 31 Jul 2015 10:36:11 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAD01B3147 for ; Fri, 31 Jul 2015 10:36:05 -0700 (PDT) From: Henning Schulzrinne To: "Gorman, Pierce A [CTO]" Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAJs4gIAABZ6AgAAApgCAAAEaoIAAUo6AgAAO0ACAACgVAIAAB5mAgACyDgCAAD2nAIAAXZOAgAFZjYCAAHWDgIABLYmAgAADsyqAAAEvAIAAAos8gAAGc4CAAAQ/yg== Date: Fri, 31 Jul 2015 17:36:02 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net>, <9d00e5dc922741449bbdff104b95fedd@PLSWE13M08.ad.sprint.com> , <5df30a39092446a4a7d8a6bdf6b3b2ea@PLSWE13M08.ad.sprint.com> , <510302dd38b54bc2981f5093b850d597@PLSWE13M08.ad.sprint.com> In-Reply-To: <510302dd38b54bc2981f5093b850d597@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 5:9y5NgGyfDnY21jU9fmJF1eG73Jge26bxx0+EnEmaSLNbCgTq62DB5IH2/iNUkgFccI6CoQoN0Ca/Tqkwg337T5BMYFJw4/1UpHk3Cv41/4PsDilYitiiT8f9QRI+I3lu7TJL9i4zyTJVAmfloLY8VQ==; 24:qGpTHWwOJ+OMYeTFpLHNm4nYwGSheLUl5k/8OmGm+PvCyUIuAN8M3sbLJEk58FgjXup+ovR+g6/MTG49KYqyhXIIDXc5SgkpGfWZFnhwgTE=; 20:d2zcWOl+oV5VFzEbe9+Xc4XYwNAI6vUak1fW6YYbrMyCWD//7DBM/4/nIX+tN9rL0ia6nRywCHJJNnAH6syT5w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0633; cy1pr09mb0633: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(50986999)(19580395003)(33656002)(93886004)(76576001)(99286002)(66066001)(2950100001)(46102003)(74316001)(106116001)(87936001)(110136002)(62966003)(77096005)(54356999)(2900100001)(77156002)(102836002)(92566002)(86362001)(2656002)(122556002)(40100003)(5003600100002)(5001960100002)(19580405001)(5002640100001)(5001920100001)(189998001)(76176999)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 17:36:02.4146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:36:13 -0000 I don't want to get into policy issues and this isn't the MODERN list, but = "availability" and "cheap" aren't necessarily coupled. Because of issues of= number utilization and "hoarding" in the 800 number space, a number of peo= ple in the policy space are well aware of these issues. ________________________________________ From: Gorman, Pierce A [CTO] Sent: Friday, July 31, 2015 1:16 PM To: Henning Schulzrinne Cc: stir@ietf.org Subject: RE: [stir] On OCSP, TNs, and Privacy If/when you're successful in MODERN, your last paragraph will be wrong star= ting at, "make the job of the bad guys much harder...". I think MODERN will make it trivial for them to cheaply get all the authent= icated numbers they want and impossible to track what got done with them. I think you're right about spoofing cutting down on spoofing law enforcemen= t and IRS numbers but how much will that matter? I don't know know my loca= l law enforcement telephone numbers or any IRS numbers. And FWIW, there is= a huge regional IRS processing center in Kansas City so I could get an aut= henticated call from just about anybody in the 816 area code and for all I = would know they really were with the IRS. Respectfully, Pierce Gorman From nobody Fri Jul 31 10:38:03 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6303D1A9240 for ; Fri, 31 Jul 2015 10:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 NItYy7Pu9rrx for ; Fri, 31 Jul 2015 10:38:00 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 101B81A8943 for ; Fri, 31 Jul 2015 10:37:59 -0700 (PDT) From: Henning Schulzrinne To: "Gorman, Pierce A [CTO]" Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQyLm9jDx9v6dEgU+gQ3M/hLpcZ53wK+0AgAAgjACAAJs4gIAABZ6AgAAApgCAAAEaoIAAUo6AgAAO0ACAACgVAIAAB5mAgACyDgCAAD2nAIAAXZOAgAFZjYCAAHWDgIABLYmAgAADsyqAAAEvAIAAAos8gAAGc4CAAAV7AA== Date: Fri, 31 Jul 2015 17:37:57 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net>, <9d00e5dc922741449bbdff104b95fedd@PLSWE13M08.ad.sprint.com> , <5df30a39092446a4a7d8a6bdf6b3b2ea@PLSWE13M08.ad.sprint.com> , <510302dd38b54bc2981f5093b850d597@PLSWE13M08.ad.sprint.com> In-Reply-To: <510302dd38b54bc2981f5093b850d597@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 5:h0Ux0C1gxWLwrKutHsbAdnLA/L8HiX2HsBsBVv0r2/a09Czo3E7LfqZEOfCXzJo1ihXq4xXuvq8v7tr3IH/fCOkbMv0iYCMYLzIlle6q/AO1E/PtY57YZC8sUzqKX1M1jGUf19/JNkj+9pqcjs99mw==; 24:qc1aOhiHxyLyG3yIKhD0vrlSFE68hZo/xKh1eCGpZMElOZs1WMb+B0pwaHjXCtQNKI2oQrGuyl+ezQokBbkEQDSGoDdcQjd2lfUKSJEhX/k=; 20:F28V80SR2HQj+q6BIf6l0M8CAEeTt40bGaqOUU7CMphEtMbU2N6xRGw5Cbjw0qa1DHPfL2lxHCYPxgF/GQQ/Fg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0633; cy1pr09mb0633: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(50986999)(19580395003)(33656002)(93886004)(76576001)(99286002)(66066001)(2950100001)(46102003)(74316001)(106116001)(87936001)(110136002)(62966003)(77096005)(54356999)(2900100001)(77156002)(102836002)(92566002)(86362001)(2656002)(122556002)(40100003)(5003600100002)(5001960100002)(19580405001)(5002640100001)(5001920100001)(189998001)(76176999)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 17:37:57.8832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:38:01 -0000 Usually, it's the mapping to CNAM that fools people, not the number itself. ________________________________________ From: Gorman, Pierce A [CTO] Sent: Friday, July 31, 2015 1:16 PM To: Henning Schulzrinne Cc: stir@ietf.org Subject: RE: [stir] On OCSP, TNs, and Privacy If/when you're successful in MODERN, your last paragraph will be wrong star= ting at, "make the job of the bad guys much harder...". I think MODERN will make it trivial for them to cheaply get all the authent= icated numbers they want and impossible to track what got done with them. I think you're right about spoofing cutting down on spoofing law enforcemen= t and IRS numbers but how much will that matter? I don't know know my loca= l law enforcement telephone numbers or any IRS numbers. And FWIW, there is= a huge regional IRS processing center in Kansas City so I could get an aut= henticated call from just about anybody in the 816 area code and for all I = would know they really were with the IRS. Respectfully, Pierce Gorman= From nobody Fri Jul 31 10:44:08 2015 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F781AC398 for ; Fri, 31 Jul 2015 10:44:06 -0700 (PDT) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 AAlR6Xsj1Z8x for ; Fri, 31 Jul 2015 10:44:04 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81961A89B5 for ; Fri, 31 Jul 2015 10:44:03 -0700 (PDT) Received: from BY2FFO11HUB005.protection.gbl (10.1.14.163) by BY2FFO11HUB024.protection.gbl (10.1.14.138) with Microsoft SMTP Server (TLS) id 15.1.231.11; Fri, 31 Jul 2015 17:43:44 +0000 Received: from BY2FFO11OLC006.protection.gbl (10.1.14.34) by BY2FFO11HUB005.protection.gbl (10.1.14.163) with Microsoft SMTP Server (TLS) id 15.1.231.11; Fri, 31 Jul 2015 17:43:41 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2FFO11OLC006.mail.protection.outlook.com (10.1.14.199) with Microsoft SMTP Server (TLS) id 15.1.231.11 via Frontend Transport; Fri, 31 Jul 2015 17:43:41 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t6VHfrBk027627; Fri, 31 Jul 2015 12:43:40 -0500 Received: from prewe13m07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsapdm2.corp.sprint.com with ESMTP id 1vxgn2yw8f-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2015 12:43:40 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 31 Jul 2015 13:43:38 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.1044.021; Fri, 31 Jul 2015 12:43:38 -0500 From: "Gorman, Pierce A [CTO]" To: Henning Schulzrinne Thread-Topic: [stir] On OCSP, TNs, and Privacy Thread-Index: AQHQySguMNJNzNJ3I0aaqMAOBi3eBJ3wbvkAgAAgjQCAAJs4gIAABZ6AgAAApgCAAALIAIAAUOCAgAAO0ACAACgVAIAAB5iAgACyDgCAAD2oAIAAXZOAgADkMYCAADO1wIABnOsAgABb74D//6xoEIAAW0CA//+sfWCAAFtygP//rExQ Date: Fri, 31 Jul 2015 17:43:37 +0000 Message-ID: References: <4B1956260CD29F4A9622F00322FE0531011D3D1D5043@BOBO1A.bobotek.net> <8bcb891a0db145d6882b17374210fd21@PLSWE13M08.ad.sprint.com> <0f678e7a59904ae5b2a2dabce1a4e0a2@PLSWE13M08.ad.sprint.com> <38726EDA2109264987B45E29E758C4D60586269A@MISOUT7MSGUSRDD.ITServices.sbc.com> <55B89E36.30305@cs.tcd.ie> <4B1956260CD29F4A9622F00322FE0531011D3D1D5047@BOBO1A.bobotek.net> <4B1956260CD29F4A9622F00322FE0531011D3D1D5048@BOBO1A.bobotek.net>, <9d00e5dc922741449bbdff104b95fedd@PLSWE13M08.ad.sprint.com> , <5df30a39092446a4a7d8a6bdf6b3b2ea@PLSWE13M08.ad.sprint.com> , <510302dd38b54bc2981f5093b850d597@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC006; 1:kG8zzuzZXoDguVig3g0L9dwqVeZDuyBlReo4PKslBGbvVc6vQFPIvSADzkdikGm4FK1lJRPr+jnXflmoNRcPDc5tTZV4sVIk955tsEvvTjfzlS6FMLztvXm4pnZu6nhO4rzgHon0fcIoUA+2TJR6+XBf1FrxVXyj9+3JNd7UzLYmin9IXAhY08RUWpV4pJV4YPaBaJmU6b02HWNp+4s1kB1n4pjYNfKg/0GVyy1cZZi30JBM5KL4KHEbmCRFCUnU5YqglLGeIEvUgI1lH9T805FR4/BSJb3GEUjjEl0MrH/ozOmQ1DZLqQ0VVq8yx/Yu X-Forefront-Antispam-Report: CIP:144.230.172.38; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(189002)(199003)(13464003)(377454003)(46406003)(106466001)(102836002)(97756001)(6806004)(19580405001)(19580395003)(5250100002)(23726002)(47776003)(62966003)(77156002)(24736003)(46102003)(2950100001)(2900100001)(110136002)(189998001)(50986999)(87936001)(5003600100002)(5001960100002)(76176999)(5001920100001)(106116001)(108616004)(33646002)(93886004)(2656002)(92566002)(86362001)(54356999)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB005; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB005; 2:sN8ZZ/q/86lJIAtH+TgrU3u6jLytMWzdvTw0bHh7/KjVArDg1OiBvE/12s+TbFWCPKfwtCcR5gI8v8deMlQYbnTN5NfHqLXfmBg8tnqNLarJ3GnpCPIYp0sKGLWQgDFuMu3yFoVKU/Pw+gWJPOKwOJTAEepjoe8c/3/o7d7ON6o=; 3:aProJ6bHSdU0BcL3U4NTMw71enHag06mwGzP6yVSGuB/E6PPKJBiMZDxbI6LcX/jbkmaa3RH8eLtPe367BElfyn74nzSS0CNd2lv6U1IPGH+4AmhQsU+/GO23XdPwRpC/4WtWCLUVkLY0zYTJnnUYGNLogiloQ5RqH8NmMD5qr7BjRVfkBqfYAXFfMG8BhsMSQOM7EOiH/7oqShPosz6k9s+9hHzyR3av1ybZ+iJre3uMzkxG22hU42sPW1uHHM0; 25:rP7tOdRKl9q3l5m9HM/WWSP6JztKmtPQH8MYtuMQnTU6FK9DzXu34KLSZpC2j6CoH/oNfxUR+AHEXddUG+y/RzZUX8JPYCyQ2nxpzN6NeDa64fKeNUg6ARbVsUCM2yM8voloCko+xu3072tcH21n6zrjCimzNO2qeFqh0XLpWfbjVaiuLuY+OrU5YOStViOFKcobMXr921poShBxsKwrXbD7cAP9D6R4pVUsf9e7IG1EsptAEZPPGuDZHkkTxIQ8+EmGT3ZoypxvNdwsJ7hjWA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB005; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB024; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB005; 20:29X1wIwNzlHmNpCyKBhanYdxuS523ilfvvhhYltilSTVVKGseLbzzEkjVksYarJlRMnwiK5VhY1eI7gGvlgdP6qE9/KThAaaR/BeiUr3SIDbQCD53qsMOQuLsOVQXfhNSaVpBBmCOI7/U6/fgJD2nWDkNCnXGRWdNB/ilndOjbmTfddbB1iP4wgP+46YUFrmD5bHOZOPeI08UUT4vy7JV+jNHYV0cr6WovwG25Z4Je8fqwPZCh9PHfyd7gpMtH7f; 4:oj8uqqYBJBh6gTcFONUo4DPl3gPpDOcLumwZdXTUBg/IZXYccDzuI9xefItypiH4Pv49U8PCOmHqZ0PvsnOh1G976KxvtE+NcQhgG5LWiUxVtGEGor383RKpBWz0eaQ3SQs14/0jj/oObJNwiL0YiumdSdnza3NC5z8kHKLPKmvw/C/NhUgXbm5xvcj7DAR9BYjNzXOgtyTSLJ3s/9FttqToKG15K4pv3xxSOyfXVtl3irRWv+yxAjNMI/fWvz4MfoLixVvVHJDfbKwEMSL4/1RfDPqN0Ix24GqkO+PrLQ0= BY2FFO11HUB005: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2FFO11HUB005; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB005; X-Forefront-PRVS: 0654257CF5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2FFO11HUB005; 23:n0a8O1H8K7q9DP/JwwhqmS+MnwwF70E2l7curG2e?= =?us-ascii?Q?VcUZv45aluHEiU6MPi3qkVhkJPFA5LWxYqQqHYeLNRhtPUEhuX9CMe6JxHtI?= =?us-ascii?Q?nlNd8BS9/UsPVWxO/CAklhpMWy4qH86BcvjqGcv8PhBC/9bzmXTaWNdgpiRW?= =?us-ascii?Q?FmwwovJD2GKc0Q39AewhZ+FxgMliT7b+L+nmITXTgrEKg5SCzFmwh3ZWgT+h?= =?us-ascii?Q?xC7o80rFx6u0gbIzFCgO+BuKslmAev5qIiBgHhBA1n0BKFuQ1JkZhISbmJZe?= =?us-ascii?Q?+PXR8cg1l0XW7uJ56FG4od/kFoRwowNbLlkjE22Rsv0GQcp9L/DnhPbyv4ba?= =?us-ascii?Q?C/yJDpR/ZICZ9wJWEmUHkezZWvxkWQNhHIatevIZGw982xTFN9osxNUq0M7z?= =?us-ascii?Q?HhjBYLDuBRyM+vBL0J3f0PvSgc4gLJgbjzN5RRl6u+zJdhSG5u2IB49PGpgE?= =?us-ascii?Q?KKMvn5rcmtp71Ycl5KChB0FuraRxuOEtZVg4A5T3F1vpxPfI51itUlXpJ1+m?= =?us-ascii?Q?xqExILeyTdM0nGTFppiCSa2PXxWrGCXurdW5uKPy9cLtWcxqdTRNJR8YSoYS?= =?us-ascii?Q?dBE3r/4ekv9EaWyo2UHyAoFEZBwgtU8rO+IXBh+tJajzPmzjRN9/g0ROQDw0?= =?us-ascii?Q?O7fJ5h1CMvbKd6g3j8O/oD6IbvFZSTTKg9L/hwgAhJXmVNAH0IOMtPpxBCv3?= =?us-ascii?Q?R8CFn2Kp9vPPcVN4MRLy4lwOu93mVwJjioagyVun25sRAaZw4ugjXH0XVR3i?= =?us-ascii?Q?xDKTHwrXhYfvMx0NoB3Wb4dleSy7cdJrZKXdxrtz9JxthdB+8dsdV9a7FV3H?= =?us-ascii?Q?3xvP/ouTHTfHR+m3WqIJ7N7yxCZBeH8PR8xgIpLknbKaXhzMQ4+VPdb3UiLQ?= =?us-ascii?Q?ogDn52+3nFrVTXvytnTXfdTtbK9EyZ+9SHY6uVJ0aSjDkG6DfvwjznEulnSj?= =?us-ascii?Q?YPDz6HcbzJasnOZlwPaRwrSbR25L9SRzi+E+xSmo2PQJDEduLlsDZlCv0ZKz?= =?us-ascii?Q?bjxvzRIBG4nCZS1pdMyBM2nNKtaND1Giq2Jg5Vv8jNUNSKj2QrzLN4She31f?= =?us-ascii?Q?SqvlY9VCVY5UqXkvIPn5xNcRuQPh?= X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB005; 5:jmZ6HRXJHVGPRMfjukt/JLPugQog9YJfG60TG3aLjXZffEvP2+faskwXd7VY4iXjAdxCd9KyFaywmCksnHhAIilP2wvQomiZwAqthAZYy7Qod+//cH5du6x3Gpqr4XwyO5etd1MjaVuh4DLqh2LtSQ==; 24:yMcEHCNgGIAx5paxB9bU1r8qjjwBnxS/Cz7gUr6jDLCCSkuYfOPr3PI3cPeClFiHWSXCsIu6hScXO1RlzMtkj1wdMe6pLfcL/YAsZqq9dE4= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2015 17:43:41.5595 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB005 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11HUB024; 2:pReEHJ/xKFVi3gyarabnthkun09wln76CLNf1FlahEtHahHGjPG4DJpV0pf0mvzGe/feQ2suKoq35OUfsoXC1zIayVR1FF5xfvslOedYer1Rd/MrJF9wLUUaL2iU8Gq6bWumTzxe4DdegNTxrJs60s5SGpAZPzZJC+T8LyJMnHM=; 3:As4jVR2pXGlTI6JatDIQeyhfJ6dJC+pacLeQmHSEjHV2OJSteTCPipQ1sA8w/UqxcVA7k0PgpHAdDigQts5/a620/vPQJqKiR2wLnYZJY3AUQ8YBCSqMTwOz66vx/Hd9NTfJrf7FZqw0kafUkDveJJ084sx0y7LWJvHEfwHFhNNDNggTNF5HQ9bw5P6IN/+4z/eG1QfkMaJrF9DfKrih3g1KUjPEm9lI6UGoJS48cRbitiWWaFAwvNKnUR9dcenw; 25:LUdoHNVTVX4u7XQ35TZdPrqMo3hKx37O/jQzxMY/hzQGWm7tZB4h5OEnCsIdRhB9+KCrWEYhPW9m3IB52q4t635CnGwdNtGrw5O6Ofstxd7e7OL2HrpVUOJnGC/A7/IkAbpeAUnPJ/z6cjL8rS9Uf8CG45xFGZWcSuAigsBn/qU6T6ELLr7GQtRW4tTKW6fEtVT0UEIA4sjOHiINZ3+sQ4fu2sQolMablTWbt+Sp91RUcRTTznvX8YwnU9b3NBD9BLgWMCztTEbXCFIpBvXApg==; 23:s5Ph3vglqBHcKO0go+BwQqzGHUop5duYg/f1murcLZCykNZun7Rv3KsaQ85UsqwbCS6t8DLZDCo0XmB6yFe3uldIQhrk8SWv46YbqnaJ4dAyi9dBKCfS5f7U8Vf66W2zZMo3kbB4PP5bn7qZczR9QY0FVDk+fM+XA7XLP6oJ3ZAj1yhQ76APk67Pm8cqZRJT X-OriginatorOrg: sprint.com Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] On OCSP, TNs, and Privacy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:44:06 -0000 Agree - and getting a handle on authenticated CNAM information is another c= an of worms we've discussed before and actually adds to my frustration. I'll throw Richard Shockey under the bus (a little) by saying his excellent= comments caused me to feel the need to vent some pent up frustration. I'll quit fussing (for now) and try to limit my comments to items I will ho= pe are helpful for protocol development. Respectfully, Pierce Gorman -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: July 31, 2015 12:38 PM To: Gorman, Pierce A [CTO] Cc: stir@ietf.org Subject: Re: [stir] On OCSP, TNs, and Privacy Usually, it's the mapping to CNAM that fools people, not the number itself. ________________________________________ From: Gorman, Pierce A [CTO] Sent: Friday, July 31, 2015 1:16 PM To: Henning Schulzrinne Cc: stir@ietf.org Subject: RE: [stir] On OCSP, TNs, and Privacy If/when you're successful in MODERN, your last paragraph will be wrong star= ting at, "make the job of the bad guys much harder...". I think MODERN will make it trivial for them to cheaply get all the authent= icated numbers they want and impossible to track what got done with them. I think you're right about spoofing cutting down on spoofing law enforcemen= t and IRS numbers but how much will that matter? I don't know know my loca= l law enforcement telephone numbers or any IRS numbers. And FWIW, there is= a huge regional IRS processing center in Kansas City so I could get an aut= henticated call from just about anybody in the 816 area code and for all I = would know they really were with the IRS. Respectfully, Pierce Gorman ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.