From nobody Wed Jan 8 03:41:56 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B131D120073 for ; Wed, 8 Jan 2020 03:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lastpresslabel-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfjpiyBIYXs4 for ; Wed, 8 Jan 2020 03:41:51 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 AA54B1200B4 for ; Wed, 8 Jan 2020 03:41:51 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id f129so2151579wmf.2 for ; Wed, 08 Jan 2020 03:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lastpresslabel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Wzooq8GJZL8U3kwdvcA5HOjS+qUoNTxcbZCq+8u1mU4=; b=Ej3s05VicFvYrrL/wAYpHBc1pEffGiURUvuDJAlloJBb0USB7UkYeWV8mE7Fuv35yS ENvqpoc9a3YRr12roFipmghcRrpl4L3eJ2EjlY0qSEzpYTtDmXKuGtioOxBl2Ie5fMRN n93IxsjbjBXLJKSJRRoonpZEua0TnyAnZVfsuQUzydfSXCm4iVvZhbemrFGQJhmyOPjS xKTyPMWq6SX+lvHU+5gptXVCDNEVDxJRSAnmGMy3N8WlnurgDCP8TbfwmM6qgoHNjELm 7crHPwuY6SxD52/euHhe8xAf6hy6jMRpynO7L8HCbP3mDDrByICI+mmufUZHTByoZAab AE6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Wzooq8GJZL8U3kwdvcA5HOjS+qUoNTxcbZCq+8u1mU4=; b=La3Ny0XJxb1AfFqRB6kPUkEfAwNSk6RQJllgewc0d/vLMWt+4j8c+9HzlCLmurdCKL czFmA41qBsoyo5Qnfq+ISLWUZG900A0I8mHIpBDKoNYEp6mzHwK2nEOH16eKbSaqKjjU CucRYppEVizGdiQ0YlKANq+7U/KngKByax5thvsJ0zjlVYblO+1EYCv11b1HF/8+5dVy EsbNJO/BT65zyF7t/AvIDCvro1VYxnOBy3eOvcujLXm/VBLb+Vus8d17Jv/wGmzpir83 cnrHbl9LbFMgCR/0pUyzBvZE3A/a5ljVCQF1G/TyIJrviLb6ipAEOcbxodnZJcRZVJb9 9rDA== X-Gm-Message-State: APjAAAW6IWr6HBdqF4eAlSXjD/wNO+7aMIvxsluzaKmkTNd3YNe1ljdV Xy1L38cVum2L8d+yDAOxfp6IYg== X-Google-Smtp-Source: APXvYqxL1f6nagzLOrsFqGcAfTOfZ2q6VhqaailV+aNzAa/oID5xb6cWJTxGFL9wj9tdXLisSGo8qg== X-Received: by 2002:a1c:9814:: with SMTP id a20mr3253918wme.94.1578483710137; Wed, 08 Jan 2020 03:41:50 -0800 (PST) Received: from broadband.bt.com ([2a00:23c6:f08b:3401:6806:cedb:9439:5820]) by smtp.gmail.com with ESMTPSA id i11sm4022295wrs.10.2020.01.08.03.41.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 03:41:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Dominique Lazanski In-Reply-To: <20f2cbe7-f9dc-d84b-1184-f62ca1601307@cs.tcd.ie> Date: Wed, 8 Jan 2020 11:42:22 +0000 Cc: "model-t@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20f2cbe7-f9dc-d84b-1184-f62ca1601307@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Model-t] Poll for model-t chat in late-Jan/Feb X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 11:41:55 -0000 Happy New Year! > On 19 Dec 2019, at 16:54, Stephen Farrell = wrote: >=20 >=20 > Hi all, >=20 > Just a reminder. [1] So far Feb 14th 1600 UTC is ahead > but the numbers are small relative to how many people > turned up at 7am in Singapore:-) Just wondering if this date has been confirmed? Looking forward to moving forward on this work. >=20 > If you can fill in the poll before the end of tomorrow > (Friday) that'd be great. >=20 > Cheers, > S. >=20 > [1] https://dudle.inf.tu-dresden.de/model-t-2020-1/ >=20 > On 16/12/2019 12:11, Stephen Farrell wrote: >>=20 >> Hiya, >>=20 >> I've setup a poll [1] to see if there's a good time >> for a model-t chat in late Jan/early Feb. All times >> there are in UTC. >>=20 >> If you'd like to take part, please try fill that in >> before this Friday so we can schedule a time before >> folks disappear for the holidays. If all of those >> times are awful for you, but you'd like to take part >> please do let me know offlist. >>=20 >> Ideally, people who said they'd produce some inputs >> (or update stuff), would have done that a couple of >> weeks before the call and we could then craft an >> agenda around whatever people have contributed and >> subsequent list discussion. IOW - if you said you'd >> produce something, please try do that before mid-Jan, >> bearing in mind unfinished somethings are perfectly >> fine for now:-) >>=20 >> Cheers, >> S. >>=20 >> [1] https://dudle.inf.tu-dresden.de/model-t-2020-1/ >>=20 >>=20 > <0x5AB2FAF17B172BEA.asc>--=20 > Model-t mailing list > Model-t@iab.org > https://www.iab.org/mailman/listinfo/model-t From nobody Wed Jan 8 04:00:13 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8B912001E for ; Wed, 8 Jan 2020 04:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 kivEtPhQ3vZY for ; Wed, 8 Jan 2020 04:00:08 -0800 (PST) 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 86A4F120019 for ; Wed, 8 Jan 2020 04:00:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8BA75BE50; Wed, 8 Jan 2020 12:00:06 +0000 (GMT) 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 sS1kyXlcl5sO; Wed, 8 Jan 2020 12:00:06 +0000 (GMT) Received: from [134.226.36.133] (unknown [134.226.36.133]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 26243BE47; Wed, 8 Jan 2020 12:00:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578484806; bh=IOetKg7rUS0dkCiRTbvI31ria6UUHXPuntbyxk0+McA=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=rSw5ymh9gJ1rowPnQPR05n6HiMIjCjhEVjQg846dTFbHXB1yGP4J/OAnbJelpfGkV 4G+JXL9oaaShIq4nGtQqG8p5HQgZqqlwGf8gTKdggU1xxW549sBFUZ/6i4nX0qF12X i00RSJy2dnBT1YbBhi41dv6EZ0WxtOeNtl0q0hIM= To: Dominique Lazanski Cc: "model-t@iab.org" References: <20f2cbe7-f9dc-d84b-1184-f62ca1601307@cs.tcd.ie> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <200b2b45-ca19-f7e6-a7df-b75ad5b66932@cs.tcd.ie> Date: Wed, 8 Jan 2020 12:00:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ihrm9ekqgSctT0DB7MoQQ48HnmzTC24md" Archived-At: Subject: Re: [Model-t] Poll for model-t chat in late-Jan/Feb X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 12:00:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ihrm9ekqgSctT0DB7MoQQ48HnmzTC24md Content-Type: multipart/mixed; boundary="2OPcdAZpEhcCZGjbkzKPQFYLeaEU32xSM"; protected-headers="v1" From: Stephen Farrell To: Dominique Lazanski Cc: "model-t@iab.org" Message-ID: <200b2b45-ca19-f7e6-a7df-b75ad5b66932@cs.tcd.ie> Subject: Re: [Model-t] Poll for model-t chat in late-Jan/Feb References: <20f2cbe7-f9dc-d84b-1184-f62ca1601307@cs.tcd.ie> In-Reply-To: --2OPcdAZpEhcCZGjbkzKPQFYLeaEU32xSM Content-Type: multipart/mixed; boundary="------------280079376D5E9CABEA6684CF" Content-Language: en-US This is a multi-part message in MIME format. --------------280079376D5E9CABEA6684CF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 08/01/2020 11:42, Dominique Lazanski wrote: > Happy New Year! Likewise! >=20 >> On 19 Dec 2019, at 16:54, Stephen Farrell = wrote: >> >> >> Hi all, >> >> Just a reminder. [1] So far Feb 14th 1600 UTC is ahead >> but the numbers are small relative to how many people >> turned up at 7am in Singapore:-) >=20 > Just wondering if this date has been confirmed? Sorry, meant to do that before the holidays but I guess I missed it;-) Friday Feb 14th 1600 UTC is the winner of the poll, so let's go with that. I'll setup a webex thing and send details here. Be great if folks could post updates to existing work or links to new work (or wise thoughts:-) to the list in the meantime. (Jari and I have done a bit of work on our draft, the -01 version [1] we posted in December was mostly just minor tidying up, we're not quite ready to post a -02 with some more substantive changes, but hope to have that done before the call). Agenda suggestions are welcome - I'll send out a draft agenda a couple of weeks before the call based on whatever's been discussed on the list as a starting point. Cheers, S. [1] https://tools.ietf.org/html/draft-arkko-farrell-arch-model-t-01 >=20 > Looking forward to moving forward on this work. >=20 >> >> If you can fill in the poll before the end of tomorrow >> (Friday) that'd be great. >> >> Cheers, >> S. >> >> [1] https://dudle.inf.tu-dresden.de/model-t-2020-1/ >> >> On 16/12/2019 12:11, Stephen Farrell wrote: >>> >>> Hiya, >>> >>> I've setup a poll [1] to see if there's a good time >>> for a model-t chat in late Jan/early Feb. All times >>> there are in UTC. >>> >>> If you'd like to take part, please try fill that in >>> before this Friday so we can schedule a time before >>> folks disappear for the holidays. If all of those >>> times are awful for you, but you'd like to take part >>> please do let me know offlist. >>> >>> Ideally, people who said they'd produce some inputs >>> (or update stuff), would have done that a couple of >>> weeks before the call and we could then craft an >>> agenda around whatever people have contributed and >>> subsequent list discussion. IOW - if you said you'd >>> produce something, please try do that before mid-Jan, >>> bearing in mind unfinished somethings are perfectly >>> fine for now:-) >>> >>> Cheers, >>> S. >>> >>> [1] https://dudle.inf.tu-dresden.de/model-t-2020-1/ >>> >>> >> <0x5AB2FAF17B172BEA.asc>--=20 >> Model-t mailing list >> Model-t@iab.org >> https://www.iab.org/mailman/listinfo/model-t >=20 --------------280079376D5E9CABEA6684CF Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------280079376D5E9CABEA6684CF-- --2OPcdAZpEhcCZGjbkzKPQFYLeaEU32xSM-- --Ihrm9ekqgSctT0DB7MoQQ48HnmzTC24md Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4VxEQACgkQWrL68XsX K+oY3g//YQboG0rKGBk+ocHxRAlEtgJr16NebyaM/W6CeCAgJXY/n+Ad49SLL4WF uvx9xM9rrZCBRECL2uAlZ2P1Rj2UYwDKHq2tgxK3ccdScvpoF87z506FP2jAy5aT MSfingrV03d3OB8KYZnzDBpYSy5b16AaRjtOOEiOZlRUOSf8N9HoganoUQ8ulPsK clL2DP7VoKP7ay9iu64mcG+cIkNQOqpdixUBg8NqY+yKMR10XSOAFH7gCUp9b5vL /98WJCi9mtiME00U3xbVf/4Iu+rqWV8UbpnbqxsvzXfxGWryG0vtfiUpZAEo7577 SWglGtncHyUjC93cDfSQoSh7n0uUIGIsbKN/UF73+qav5gH7o7RXaZlN7Dc6WafS sYogmL041hBythI0CB3/PQgxSHWvuHM+iPAWtiAEMGxAavIe60xcfDBqM2QTTeGh ECI+rfHEOP9yg2rBxdCT8jjNGB0xUhxohX3vICZ89HOEykCFvCWSZ8usGy/m4vJG Oe7P6BXjX5Ax98KfVqKCdA3xPo09ye3CJvneMqmYW9+y9s3sAeYqSG7i+YmqWDnh zBcBwIXrbiXduLol4xs1AHsk9bUbXtsGKNSE3xLvkpUdZVCdn0QQKRgbupOMZnsn +sOqNrBf6sgfg9uX8v1uiutXo8UHGBvfnNHO+b7pS/EAvH1BT/k= =R7Lu -----END PGP SIGNATURE----- --Ihrm9ekqgSctT0DB7MoQQ48HnmzTC24md-- From nobody Wed Jan 8 04:40:37 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C56112011C for ; Wed, 8 Jan 2020 04:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 fNIA1LFn9Y6Q for ; Wed, 8 Jan 2020 04:40:33 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2064.outbound.protection.outlook.com [40.107.243.64]) (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 8A936120111 for ; Wed, 8 Jan 2020 04:40:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d80XI4y1gJx4ZrUU7NTDz2rRH8H7Dc2yOvzQoeXVuF90zzLgelIdd8owlswccAJxLZrSbQlvamtA3ItFcxcjRjZaGr0OQDE6FlvmYqgnHyvgp5bNSUAeQwxRZ5dAlaVLPeY1PrX8C+dORt4nyZ+21ElWKCQ2kpzLho8I/klHZjNLvJKX/J7j05PB1dyVI6V89i78EFNK9nd778BYfMQHZV2DReHkQx/KS+5V9b1Ml1bccQK/BfMcET0SwpFfr6oLnzf0NHPzYnKc92vLeXyVPLBzVnkTEFa5RvRAjhllJWAFVeEK2oKN5DbcIRTTffVQPyu1Qe4hGK+79JjKcUJjFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=beRjqUUpgyO+3mOJyImucqmqw+HUgyLAepLhDQmK/OU=; b=eL5uRCDptB2/VvdOytsWqeC4Dq07YZ8m0hixFpsfdFZ7SZ8AEL/kVnYLmcbXQ2Jd+oFok8N3F2mudDBGLXTwqZa1N1c5qZABShNWm3heFMAGrHx/gcOS9IJQTZ39uRCr3w8n4S2G2+R14sMTVVb3l7Sw6E/wHTE55EbWk2rqN8PQSCVEoJ0q0N3rTd7BAbBW0gTbwOQ5BkTjjrsXg96ZLxT6yLHmyCOUuDp2ZgnpmlUrEE65mCr/1q9RmsUVEZndPObzmVyn7xgrt6lEG9dwDwcCjnBu6JWgTRXMAq5FN6kQexEavvyrkyIFZWzBH3MYrBiCtA06TKrcFTpNXqk6pg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=beRjqUUpgyO+3mOJyImucqmqw+HUgyLAepLhDQmK/OU=; b=WgsRRe6FxMoEwnZHEafJ+kCIfIaDBCvQyNBgc8YS2o206RwjHZ80Qk/WvPzcRw60OAc50ZaeynlNsL+bsGcy7rgKd9qZr4/oUfbKqtL4whwn35A4nsL2RPC1FddP2Qs+JDKEaV0XbCpabkppsPlDwaoeCsRs+0sI7aajrjDlSqM= Received: from BL0PR06MB4772.namprd06.prod.outlook.com (52.132.0.222) by BL0SPR01MB0025.namprd06.prod.outlook.com (52.132.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10; Wed, 8 Jan 2020 12:40:31 +0000 Received: from BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::bcb1:34ae:3c82:185c]) by BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::bcb1:34ae:3c82:185c%6]) with mapi id 15.20.2602.015; Wed, 8 Jan 2020 12:40:31 +0000 From: Robin Wilton To: "model-t@iab.org" Thread-Topic: linkability Thread-Index: AQHVxiDQg7WzjYejmUuhOwd7i/9I0A== Date: Wed, 8 Jan 2020 12:40:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-originating-ip: [185.206.225.246] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0650821d-be13-4445-b801-08d79437f312 x-ms-traffictypediagnostic: BL0SPR01MB0025: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(39850400004)(376002)(346002)(396003)(199004)(189003)(3480700007)(8936002)(91956017)(76116006)(66616009)(66476007)(66556008)(8676002)(64756008)(66446008)(81166006)(81156014)(7116003)(966005)(316002)(36756003)(66946007)(86362001)(26005)(53546011)(6512007)(2616005)(6486002)(186003)(6506007)(5660300002)(33656002)(478600001)(71200400001)(2906002)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0SPR01MB0025; H:BL0PR06MB4772.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:3; MX:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: faOPSx4r+A8wvxSLzx2pwjyCF0bmLrxobvMjrHK8AMdUg5ZYUWpw7JpVns9CKXiLpYU4VO04u9fWfWDU9Aw2PbF0Z+IkYvSHRRwYWnTw5ci00zQucsQXyz/B4HZaJUg5wLOGKz3HuiDnuROFE76vtxaCZDM1CCWy7xIH1gF9slayZuw00CuhdZzcjyaXl217EESsnUCC2MjWcmSEH2O46Z7JV/XHcq9iVU9/aeutnVNtL49KoedDDzadim8RhumX9Cz2jaxttGMQg/r4pILFjmp7QoEEg35+xUW/rIPIf+soY3+s4Nmv1H4awTrZdX4XPjMi5XOXhO7wZ3sBz/V76dBvd323hHnjkNoKTRFvyvX4uz+HU1MzBLzusADNzE0CU128y8oJY25Ln/ewg/xdqZeRb6tKomcGSwVJlzTcNvddcaEEhi5Gm3vCErVJslOui4SxTPXP43GVaQg4A330zAShVNH8/oZ+wStRwe52bdG+PqsC09iy79bCgsIz4ePJuqve6JRwlzP4wylqkjTgXA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; boundary="Apple-Mail=_A1B2F54C-3F8F-412C-BC03-001311F7FF18"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 0650821d-be13-4445-b801-08d79437f312 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 12:40:31.7383 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: K+OXU58B2ltx7FK+Nlghv4SXB/uh7IMKPV5jVaxtHbyDQ5YrCUtN6S9keuYzULCq X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0SPR01MB0025 Archived-At: Subject: Re: [Model-t] linkability X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 12:40:36 -0000 --Apple-Mail=_A1B2F54C-3F8F-412C-BC03-001311F7FF18 Content-Type: multipart/alternative; boundary="Apple-Mail=_8F7A1B2A-C3F0-4907-8C30-E91B0B3D9924" --Apple-Mail=_8F7A1B2A-C3F0-4907-8C30-E91B0B3D9924 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > From: Eric Rescorla > Subject: Re: [Model-t] A couple of questions from our discussion in = Singapore > Date: 15 December 2019 at 23:51:37 GMT > To: Jari Arkko > Cc: model-t@iab.org >=20 >=20 >=20 >=20 > On Sun, Dec 15, 2019 at 4:34 AM Jari Arkko > wrote: >=20 > I=E2=80=99m trying to update our draft to cover various different = issues. There were a couple of things that we discussed in Singapore and = earlier but I can=E2=80=99t quite recall what they exactly were: >=20 > * I think Melinda brought up a point about decentralised apps and = source of trust in them. What was that exactly about? >=20 > * Martin brought up a point about how some level of trust is needed = for any system. Could you expand on that so that I would understand the = issue? >=20 > * Dkg and Ekr mentioned linkability at the summer SAAG meeting. I = wasn=E2=80=99t sure how that is related to the issues we=E2=80=99re = discussion, can someone enlighten me? >=20 > It's been so long that I don't remember, but linkability seems like a = pretty serious privacy issue. Indeed, it's the basis of Web tracking. >=20 > -Ekr I think it was just a relatively high-level observation that = linkability, as a privacy risk, was not addressed when the original = threat model was being compiled, and that it would merit inclusion in = any revised version (or, at least, in the discussion of what a revised = version should cover). HTH, Robin >=20 >=20 > Jari >=20 >=20 > -- > Model-t mailing list > Model-t@iab.org > https://www.iab.org/mailman/listinfo/model-t = --Apple-Mail=_8F7A1B2A-C3F0-4907-8C30-E91B0B3D9924 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


From: Eric Rescorla <ekr@rtfm.com>
Subject: = Re: [Model-t] A = couple of questions from our discussion in Singapore
Date: 15= December 2019 at 23:51:37 GMT
To: = Jari Arkko <jari.arkko@piuha.net>
Cc: = model-t@iab.org




On Sun, Dec 15, 2019 at 4:34 AM Jari = Arkko <jari.arkko@piuha.net> wrote:

I=E2=80=99m trying to update our draft to cover various different = issues. There were a couple of things that we discussed in Singapore and = earlier but I can=E2=80=99t quite recall what they exactly were:

* I think Melinda brought up a point about decentralised apps and source = of trust in them. What was that exactly about?

* Martin brought up a point about how some level of trust is needed for = any system. Could you expand on that so that I would understand the = issue?

* Dkg and Ekr mentioned linkability at the summer SAAG meeting. I = wasn=E2=80=99t sure how that is related to the issues we=E2=80=99re = discussion, can someone enlighten me?

It's been so long that I = don't remember, but linkability seems like a pretty serious privacy = issue. Indeed, it's the basis of Web tracking.

-Ekr

I think it was just a relatively high-level = observation that linkability, as a privacy risk, was not addressed when = the original threat model was being compiled, and that it would merit = inclusion in any revised version (or, at least, in the discussion of = what a revised version should cover).

HTH,
Robin




Jari


--
Model-t mailing list
Model-t@iab.org
https://www.iab.org/mailman/listinfo/model-t
=

= --Apple-Mail=_8F7A1B2A-C3F0-4907-8C30-E91B0B3D9924-- --Apple-Mail=_A1B2F54C-3F8F-412C-BC03-001311F7FF18 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEj23cReEsy27C3Qkk0vvfsXu+VHkFAl4Vzb8ACgkQ0vvfsXu+ VHno1Q//Wo7YuqnUNMtbaRTsJVxDBp5OZornBQHTIJnlnvfpQ0Kk+mouQ1XD3heN DL7c48EqjNmsNTPS+6RnsJlxb4DZXOT6GiwxHr2WobEXvdD+NSH5zA+a01Nxz8zL tT8EXct/GO00rabmC4Jm/8LAv3eK3E8Quuztwc+/vBL+OVbc9lWI9ufGLKTtlMA7 n4wfh768Qm9q619qFDkmUqqviD01P39txBQ+yjagg69SoBwwWgXx7JUJ1MyVoB2s utlRN4RvY8nRxnnPILDOEOXTK3UGUqnEeq/zFybMqxuCyJhZ7TdtlXrIlTfAZF1/ +LFQU3q25W0Wafy0blkLu/LFW+fWu2bVxayom7ph3l0BYsSSoeHbooN1caSzWEo1 DWTbOR7jWd4Lmo0y9Sq3KuXcrJadkCPr/uojBUZ4ZJiwwpcTrvSR7wLCzWNNomHw aW73fm9UO5tB2ru5V/8k+99bbQylDg4YX2SHh9Mi/aqOIJ3SDEcCinjPeC/pndME b797ejWllDFoOqWM8OePbE9eosvbQ3/Ye/eRHfcELqhdqM3E5JiMmny9uo7qE4Gf tf0pHFtat2fxC9Y4J4g8TdHz0HlG64z2OcaeTNh9D6VTTv5KEGXnnLrltvHJDwW/ 07nq0Hrr9rNADhmWqhAC5NlLCFtPlGmeUTN4FNslT52vfyX7/a8= =OMlF -----END PGP SIGNATURE----- --Apple-Mail=_A1B2F54C-3F8F-412C-BC03-001311F7FF18-- From nobody Wed Jan 8 04:55:28 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB1C120271 for ; Wed, 8 Jan 2020 04:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 mw6l7ahMDXJw for ; Wed, 8 Jan 2020 04:55:25 -0800 (PST) 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 B93E212011C for ; Wed, 8 Jan 2020 04:55:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DC986BE2F; Wed, 8 Jan 2020 12:55:22 +0000 (GMT) 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 IDRqBG7HQZoj; Wed, 8 Jan 2020 12:55:22 +0000 (GMT) Received: from [134.226.36.133] (unknown [134.226.36.133]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A10B3BE2E; Wed, 8 Jan 2020 12:55:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578488122; bh=Mrc8RIPs3xFntiKm4CvRoxADt9bobsC7M6D4MnZXIOk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=XDF0hmUHv/Ge0GbonB9mVBBp5b/XnR1QlQVCRZW4QNOv+kiz/rZLQToRAKp3dfx1T XIPkmOALJlB9oeu3lCwLSKYVs2HilqngBz0sJ1yra70sj9A9+Bzno116gTPVE2z8Ih wtCuaY+ybenWt80AbRf5Ui1tJIwE3bBfdr6Xbs0Y= To: Robin Wilton , "model-t@iab.org" References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <30d47a1b-c968-e05f-a1dd-1b7c9b8dadc4@cs.tcd.ie> Date: Wed, 8 Jan 2020 12:55:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cloOLf2oQUwLV90lamtqUyhLFIRMKgiNL" Archived-At: Subject: Re: [Model-t] linkability X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 12:55:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cloOLf2oQUwLV90lamtqUyhLFIRMKgiNL Content-Type: multipart/mixed; boundary="JP83ThEffdaZSE12evjaLs4opM9XUIfwP"; protected-headers="v1" From: Stephen Farrell To: Robin Wilton , "model-t@iab.org" Message-ID: <30d47a1b-c968-e05f-a1dd-1b7c9b8dadc4@cs.tcd.ie> Subject: Re: [Model-t] linkability References: In-Reply-To: --JP83ThEffdaZSE12evjaLs4opM9XUIfwP Content-Type: multipart/mixed; boundary="------------81E585354E383E36DDB759F8" Content-Language: en-US This is a multi-part message in MIME format. --------------81E585354E383E36DDB759F8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/01/2020 12:40, Robin Wilton wrote: > I think it was just a relatively high-level observation that > linkability, as a privacy risk, was not addressed when the original > threat model was being compiled, and that it would merit inclusion in > any revised version (or, at least, in the discussion of what a > revised version should cover). Good point. That is discussed in 6973 [1] in various places but (with a quick scan) I didn't see a crisp bit of text one could offer to protocol designers as guidance for what to do about linkability. (I.e. a snippet of text one could imaging as a part of a BCP72 update.) If anyone has suggested text be great to see that... Cheers, S. [1] https://tools.ietf.org/html/rfc6973 --------------81E585354E383E36DDB759F8 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------81E585354E383E36DDB759F8-- --JP83ThEffdaZSE12evjaLs4opM9XUIfwP-- --cloOLf2oQUwLV90lamtqUyhLFIRMKgiNL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4V0TkACgkQWrL68XsX K+qXoQ//fgT+HJ4ntJm3Qw0pA0G2AZCE1G5c2zbro4ELisgoTw5RuCYgUn0kkfA3 5TP3eKFRroEd3mPGHkaorvy4kIa6rXCrehFUBeT2byrvKPsgMQ1xLEWBlXWS79Ck DcX3kn5EjkQ55iY8XIqR1JaovBHQtA/iRdbT8XqP4nPhw+oT3TGLMo3hhKUS5vcX sK8Dczaxc1fJsGFgPshPlCjUC80ORAk1uWVlKHeyk9qUp2u97tbGfBfYAF7Vg9oy GB+O6qPTt99lm4Y/6H+skSow8DZtRUHEF74RHneEGn/bK+GI3y9y7780ftJ/rRiZ vAqJYqrAr70wDI9Yf1RYKe9HENOMvJ9BELhrH8R1Y1G+XrXLVhYYc7VpPhPRezuh hSYmH6k+QiiMIXDsabD2NHUlt8xA5kNO4nXac1atvKY4rr9H6rjnr7Id2lSr8OCF OLtqAPLBrlp2qNviLyn41y+wLZR6BY3hhsh68EBLWuEtyCmyju88JOAs+I9ZlbID QYWSSHFOBeRw9uuesxCr1nj8fEGWQp9xiR2Ub0q9f82/57VCe3ShVYBOuqFCsKIs IKqBA7ukI+hIKactpWlN+vj3NuLpM3Goh0EWavo1ggSxjzPXyCv3IiumZxIJk1Jc gCGFPI4CN978tJgEV56De4VFeBiYJ+RZoeQN8b+C+vcs/+/grPI= =3h0h -----END PGP SIGNATURE----- --cloOLf2oQUwLV90lamtqUyhLFIRMKgiNL-- From nobody Wed Jan 8 04:55:38 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AD4120855 for ; Wed, 8 Jan 2020 04:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0doD-HPgycRD for ; Wed, 8 Jan 2020 04:55:29 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF6712011C for ; Wed, 8 Jan 2020 04:55:28 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id j26so3156027ljc.12 for ; Wed, 08 Jan 2020 04:55:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KCYx3a2Gzi2arhjP7U61BcCfIihlMqIwEO8tJM63L5c=; b=u5/FOZm2ZogxS8WP4wn8xybxB7rarxYqTWTyOdKBGHpdNsKbDMJ4WouNun3ccu5GnN ua0hkHD84YJ8GSL67Sq3YwTaLqag0DotntXrwU+IcthoTaL96eu7fvjzRcUh+O1PRBC2 UM5vWp2YZoSNKokDDFWZyDHbwISCwYncswLPUc6AbFDBuilefZmCTC5NikbHzh1Gfp7M 7RTtw0+6fyoMkP0DYYMHUUde0lfKWIq6fhuBE95eoEU8FAQmKOvrUEJHLr5ZT5DeqrTA dhrRIKLDlL6eogdwunuX6AX0n9ndKZyuZMCopWnZiN42MRsoZh8JSzLYBkcsUt1pH96u Gcqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KCYx3a2Gzi2arhjP7U61BcCfIihlMqIwEO8tJM63L5c=; b=HbcuNLJ5+jFHkkrEFIujOMk+hkHRoiMn4zKPp9MKP/uZm9PJppw62xhN3FcTKQenRN 4Y0Wg+3D70Exz8+3TehtVyTm94Cq1mtgQQDtuvfJLGkxaVefIWzIgTYYokWAcaK47Grf RLUbYEvnj8WsyfA6vIEUjw4UlsWeBgvDpKFgtB998XGUgzMiuQ5CcE0OkFIX02fWV/xr fCwFzSEwXpT+mCcZnk7Bua1+anFZl6XEQkhENHCK/0mb5zsnwgSh/lSLDsKMARnqZKFQ fevg/NtyR2hde7xvkLrOi9/yC2tqi7JdQDdSNMLJqy9g3sc2K6OftzAXOkQvv99vwp9a krBQ== X-Gm-Message-State: APjAAAV0/WeK4cL4RCyjxkdRO9Qpa+LD206xCTeBAh+3l0f+LqDYqGkx UnG0shiAg56hSjf6179BApD950oXxGa5KJE9xDtdcg== X-Google-Smtp-Source: APXvYqzIiKrToS/lMm/9JfEmUIr2ZoKZ6QlnlyhTh+uaziiNSXWa6VNVmyw+CWEYiOmHamWypduPcFom2Il/kjgGNrI= X-Received: by 2002:a05:651c:239:: with SMTP id z25mr2968095ljn.48.1578488127260; Wed, 08 Jan 2020 04:55:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 8 Jan 2020 04:54:51 -0800 Message-ID: To: Robin Wilton Cc: "model-t@iab.org" Content-Type: multipart/alternative; boundary="0000000000001b9c93059ba06896" Archived-At: Subject: Re: [Model-t] linkability X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 12:55:35 -0000 --0000000000001b9c93059ba06896 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2020 at 4:40 AM Robin Wilton wrote: > > > > *From: *Eric Rescorla > *Subject: **Re: [Model-t] A couple of questions from our discussion in > Singapore* > *Date: *15 December 2019 at 23:51:37 GMT > *To: *Jari Arkko > *Cc: *model-t@iab.org > > > > > On Sun, Dec 15, 2019 at 4:34 AM Jari Arkko wrote: > >> >> I=E2=80=99m trying to update our draft to cover various different issues= . There >> were a couple of things that we discussed in Singapore and earlier but I >> can=E2=80=99t quite recall what they exactly were: >> >> * I think Melinda brought up a point about decentralised apps and source >> of trust in them. What was that exactly about? >> >> * Martin brought up a point about how some level of trust is needed for >> any system. Could you expand on that so that I would understand the issu= e? >> >> * Dkg and Ekr mentioned linkability at the summer SAAG meeting. I wasn= =E2=80=99t >> sure how that is related to the issues we=E2=80=99re discussion, can som= eone >> enlighten me? >> > > It's been so long that I don't remember, but linkability seems like a > pretty serious privacy issue. Indeed, it's the basis of Web tracking. > > -Ekr > > > I think it was just a relatively high-level observation that linkability, > as a privacy risk, was not addressed when the original threat model was > being compiled, and that it would merit inclusion in any revised version > (or, at least, in the discussion of what a revised version should cover). > 3552 doesn't really cover privacy much at all. -Ekr > HTH, > Robin > > > > >> Jari >> >> >> -- >> Model-t mailing list >> Model-t@iab.org >> https://www.iab.org/mailman/listinfo/model-t >> > > -- > Model-t mailing list > Model-t@iab.org > https://www.iab.org/mailman/listinfo/model-t > --0000000000001b9c93059ba06896 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 8, 2020 at 4:40 AM Robin = Wilton <wilton@isoc.org> wrote= :


From: Eric Rescorla <ekr@rtfm.com>
Subject: Re: [Model-t] = A couple of questions from our discussion in Singapore
=
Date: 15 December 2019 at 23:51:37 GMT
To: Ja= ri Arkko <jari= .arkko@piuha.net>




On Sun, Dec 15, 2019 at 4:34 AM Jari Ar= kko <jari.arkk= o@piuha.net> wrote:

I=E2=80=99m trying to update our draft to cover various different issues. T= here were a couple of things that we discussed in Singapore and earlier but= I can=E2=80=99t quite recall what they exactly were:

* I think Melinda brought up a point about decentralised apps and source of= trust in them. What was that exactly about?

* Martin brought up a point about how some level of trust is needed for any= system. Could you expand on that so that I would understand the issue?

* Dkg and Ekr mentioned linkability at the summer SAAG meeting. I wasn=E2= =80=99t sure how that is related to the issues we=E2=80=99re discussion, ca= n someone enlighten me?

It's been s= o long that I don't remember, but linkability seems like a pretty serio= us privacy issue. Indeed, it's the basis of Web tracking.

-Ekr

I think it was just a relatively high-level observation that linkability,= as a privacy risk, was not addressed when the original threat model was be= ing compiled, and that it would merit inclusion in any revised version (or,= at least, in the discussion of what a revised version should cover).
=

3552 doesn't really cover = privacy much at all.

-Ekr

--0000000000001b9c93059ba06896-- From nobody Wed Jan 8 05:58:42 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4458312004C for ; Wed, 8 Jan 2020 05:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 u92vAVMyS1a6 for ; Wed, 8 Jan 2020 05:58:38 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2055.outbound.protection.outlook.com [40.107.223.55]) (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 308FC120044 for ; Wed, 8 Jan 2020 05:58:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fL60HPGs1qNdRN7h7e0GUCrrMWV8KPmqsDvfdKn2rHcL+/zl18g6GUb7UZPV6StN/kHLw98iqJk/seNCuwAHQjeiSmeSUNvIqg76v/yFqTVkqVSk/higzr+fHJNFnLepEyz2K+gZ2OxQMa99S+R8wQQQB7Qy1fUL/JBxGVz2ZWH9OIE1MCwGf+4InA1HxNGQwD1n3zN+V9ylWDlolj3fNJTxoyCJclF+s4r1alD7bqp/eur/fAGun3K4/2UAMZmzbfhqmZZQg+AdgJIYC2+oVo4Gb6uyCgKYeeqrVWHLImXKxygLaa+uGCixlEgnmMSTtJ8PIkILhM/dywXe/2nYnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oaXJ9L5VMrzGSQ8dQJv7Nizn1FbUv07JI+jwhfm9rl4=; b=K1pIXXx1qlGX630vT1oNMKg1zPKmFQoucCdJaSAYjTIlz254FGZwDeGAyMy0Duv1Becy7Qje7KlTQcojS8bpY+v075fN8i6RaHv4W+pgx26p1N9Gr6MDz8DEQcyriYLl9yFnFivfPHbD8w63/KNqJ643xaKlqP+ex8lYR6f5sFP8cTK+KSvRruYX7os/tH6oR0HcrPeEpqaNFMlwF8PG+Z63W8Po0MtR3ADHn52PjH3ePMBBdXjG4+9l/D985xA/nXouFiU+AqHQZRFkyMuCLsoHFmiIPF3X0Pv/on9DhoxXe8qKt8x3+yAT/MgYDT+TAb8ZW9aXlk+7t3vZwTBD/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oaXJ9L5VMrzGSQ8dQJv7Nizn1FbUv07JI+jwhfm9rl4=; b=j2jNLx0F2pxLNMfIcapVyvBPJlJ1Px/69hck3Fde/dgVCgdWiEGhRKlrKIOhpJ2C8nTPT5Bt1+K7zKJAThl98Yq12p2vzWWHkg30RzLnHnbqG+Pz1GMjhiGL4oN0O3/50peNsKn51Ss0UBJyZO4mFdJ9qQS345tNec0x4LYcv/k= Received: from BL0PR06MB4772.namprd06.prod.outlook.com (52.132.0.222) by BL0PR06MB4370.namprd06.prod.outlook.com (10.167.241.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Wed, 8 Jan 2020 13:58:35 +0000 Received: from BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::bcb1:34ae:3c82:185c]) by BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::bcb1:34ae:3c82:185c%6]) with mapi id 15.20.2602.015; Wed, 8 Jan 2020 13:58:35 +0000 From: Robin Wilton To: Eric Rescorla CC: "model-t@iab.org" Thread-Topic: [Model-t] linkability Thread-Index: AQHVxiDReEBwPMV+sEuPAAtZcTlfAqfguV+AgAARzIA= Date: Wed, 8 Jan 2020 13:58:35 +0000 Message-ID: <05B068D7-E025-499C-A76B-45C0A5A59584@isoc.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-originating-ip: [185.206.225.246] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a5a55eca-560f-4fc5-6f46-08d79442dac0 x-ms-traffictypediagnostic: BL0PR06MB4370: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39840400004)(346002)(376002)(366004)(136003)(129404003)(199004)(189003)(91956017)(33656002)(76116006)(316002)(2906002)(6512007)(66946007)(2616005)(64756008)(186003)(66556008)(66446008)(26005)(66476007)(66616009)(66574012)(5660300002)(8936002)(86362001)(81166006)(8676002)(6916009)(4326008)(966005)(6506007)(478600001)(36756003)(6486002)(81156014)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR06MB4370; H:BL0PR06MB4772.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: h546hYqOvrypt5PtXuaJOTDJ6373X8HsvxKx4K2UD/vW6i19/e4Qc43YQNGKvhIZTMIAeQhme0YdIEw5LWKiHdEjiLjlltqJrxLMXOOv5x5L+Hf6cNGsN/YJBMs3Mf9B/cYYoBU3aYHkmB2fjADVNhLzP5pMTEWa7hyPZKZ14ORrJgOacGdmEugjKZQbh4n2QpRZHJL6S6EWxp52EMOTIdelZwzpCPn0EEEtp7YD9Jwcu7TUK+6JV3/l17XhPaS1nF8N2VV3zgo8YxwcmFiBoPy3OuQJlDk2CqARMEQi44btjqCKELJlU7vlLn+W+hrUC6HXIoFbl+nd+4NWp8GLTL6unZpxB8D4AAmUKQJgisQF/GWlhGvw7bJuxzaHhrLS10YZdsKxK+3ytpI8yVoRE3d5maIeeyE2EBPYfHtbV4+SB1QcEswex5wg8fGwZgwwNcXHeJPIccF+XTZyVIEuXW9Znazi4TvT2j9Ov+BGgB0MEN4cc8wh1lDkCHpxQzqCnfZOoCAnsx/Oaxn0VskuWjVqCP0E+95qhtwc2S1LGI1GNEAre4EkAGe8Gvmw6PMv x-ms-exchange-transport-forked: True Content-Type: multipart/signed; boundary="Apple-Mail=_47BA7F9A-0967-493E-9CCA-718146B0F8E2"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: a5a55eca-560f-4fc5-6f46-08d79442dac0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 13:58:35.4033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zZHXM5xrYTSE3Xkw4LDogafS6sXDe0bJckeVroBWKbFkPRPUsU4QfRjL3qGrcOkF X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4370 Archived-At: Subject: Re: [Model-t] linkability X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 13:58:42 -0000 --Apple-Mail=_47BA7F9A-0967-493E-9CCA-718146B0F8E2 Content-Type: multipart/alternative; boundary="Apple-Mail=_14EA1B48-42E7-4B91-8CF6-866D7D2D4123" --Apple-Mail=_14EA1B48-42E7-4B91-8CF6-866D7D2D4123 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Ekr - Between your reply (re 3552) and Stephen=E2=80=99s (re 6973), it seems = to me that we need a way to ensure that linkability is adequately = reflected in both places, but without duplicating or giving conflicting = guidance. Here=E2=80=99s a suggested approach. Looking first at 6973, I see that Marit Hansen was one of the authors. = Marit was also co-author of probably the seminal paper on linkability, = with Andreas Pfitzmann ( https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf = ), = so her contribution to 6973 is highly likely to have been guided by = concerns about linkability as a privacy threat. Section 5.2.1 of 6973 ("Correlation = =E2=80=9D) = is probably the closest that RFC comes to describing linkability as an = issue, particularly this paragraph: > Correlation is closely related to identification. Internet = protocols > can facilitate correlation by allowing individuals' activities to = be > tracked and combined over time. The use of persistent or > infrequently replaced identifiers at any layer of the stack can > facilitate correlation. For example, an initiator's persistent use > of the same device ID, certificate, or email address across = multiple > interactions could allow recipients (and observers) to correlate = all > of the initiator's communications over time. 6973 goes on to recommend data minimisation as a possible mitigation, = but a pretty qualified one. I think this principle also surfaced in the = discussions around RFC7258 (Pervasive Monitoring Is An Attack), but = again, with qualifications: > IETF standards already provide mechanisms to protect Internet > communications and there are guidelines [RFC3552 = ] for applying these > in protocol design. But those standards generally do not address = PM, > the confidentiality of protocol metadata, countering traffic > analysis, or data minimisation. In all cases, there will remain = some > privacy-relevant information that is inevitably disclosed by > protocols. IIRC, one approach discussed was to ensure that the data/metadata = required by a given layer of the protocol stack should only be = accessible to the nodes responsible for implementing that layer=E2=80=A6 = but of course, the semantics of data at the application layer may well = mean that the user=E2=80=99s actions can be correlated/linked despite = anything that happens further down the stack. Bottom line: 6973 is relatively recent (2013) and addresses correlation = to a certain extent, but it may be hard to go further with practical = advice for protocol designers. One option might be to look more closely = at context. Nissenbaum=E2=80=99s paper = on = Privacy as Contextual Integrity is now 15+ years old, but still = meaningful. We could encourage protocol designers to consider the = (usually implicit) context in which potentially linkable data items are = being used, and what measures might be taken to prevent (or track) their = use outside that context. Looking next at 3552; you=E2=80=99re right, it doesn=E2=80=99t mention = privacy as such - and since it=E2=80=99s the Security Considerations = guidance, and Privacy Considerations giudance has its own home = elsewhere, that=E2=80=99s fine. However, =E2=80=9Ccontext=E2=80=9D might = provide a bridge between the two: if you see privacy as contextual = integrity (i.e. that data disclosed in one context shouldn=E2=80=99t = show up in another one), then violating contextual integrity implies a = violation of confidentiality: you=E2=80=99re taking data that was = disclosed to one party, and making it accessible to another. So perhaps 3552 can briefly note that breaking a confidentiality = mechanism is almost certainly a context/privacy violation, and then hand = off to 6973 for the detail. Hope this helps, Robin --Apple-Mail=_14EA1B48-42E7-4B91-8CF6-866D7D2D4123 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Ekr - 

Between your reply (re 3552) and Stephen=E2=80=99s (re 6973), = it seems to me that we need a way to ensure that linkability is = adequately reflected in both places, but without duplicating or giving = conflicting guidance. Here=E2=80=99s a suggested approach.


Looking first at 6973, I see that Marit Hansen was one of the = authors. Marit was also co-author of probably the seminal paper on = linkability, with Andreas Pfitzmann
( https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.= pdf ), so her contribution to 6973 is highly likely to have = been guided by concerns about linkability as a privacy threat.

Section 5.2.1 of 6973 = ("Correlation=E2=80=9D) is probably the closest that RFC = comes to describing linkability as an issue, particularly this = paragraph:

  =
Correlation is closely related to identification.  Internet protocols
   can facilitate correlation by allowing individuals' activities to be
   tracked and combined over time.  The use of persistent or
   infrequently replaced identifiers at any layer of the stack can
   facilitate correlation.  For example, an initiator's persistent use
   of the same device ID, certificate, or email address across multiple
   interactions could allow recipients (and observers) to correlate all
   of the initiator's communications over time.

6973 goes on to = recommend data minimisation as a possible mitigation, but a pretty = qualified one. I think this principle also surfaced in the discussions = around RFC7258 (Pervasive Monitoring Is An Attack), but again, with = qualifications:

 IETF standards already provide =
mechanisms to protect Internet
   communications and there are guidelines [RFC3552] for applying these
   in protocol design.  But those standards generally do not address PM,
   the confidentiality of protocol metadata, countering traffic
   analysis, or data minimisation.  In all cases, there will remain some
   privacy-relevant information that is inevitably disclosed by
   protocols.

IIRC, one approach discussed was = to ensure that the data/metadata required by a given layer of the = protocol stack should only be accessible to the = nodes responsible for implementing that layer=E2=80=A6 but of course, = the semantics of data at the application layer may well mean that the = user=E2=80=99s actions can be correlated/linked despite anything that = happens further down the stack.

Bottom line: 6973 is relatively recent (2013) and addresses correlation = to a certain extent, but it may be hard to go further with practical = advice for protocol designers. One option might be to look more closely = at context. Nissenbaum=E2=80=99s paper on Privacy as Contextual Integrity is now 15+ = years old, but still meaningful. We could encourage protocol designers = to consider the (usually implicit) context in which potentially linkable = data items are being used, and what measures might be taken to prevent = (or track) their use outside that context.


Looking next at 3552; you=E2=80=99re right, it doesn=E2=80=99t = mention privacy as such - and since it=E2=80=99s the Security = Considerations guidance, and Privacy Considerations giudance has its own = home elsewhere, that=E2=80=99s fine. However, =E2=80=9Ccontext=E2=80=9D = might provide a bridge between the two: if you see privacy as contextual = integrity (i.e. that data disclosed in one context shouldn=E2=80=99t = show up in another one), then  violating contextual integrity = implies a violation of confidentiality: you=E2=80=99re taking data that = was disclosed to one party, and making it accessible to = another.

So = perhaps 3552 can briefly note that breaking a confidentiality mechanism = is almost certainly a context/privacy violation, and then hand off to = 6973 for the detail.


Hope this = helps,
Robin

= --Apple-Mail=_14EA1B48-42E7-4B91-8CF6-866D7D2D4123-- --Apple-Mail=_47BA7F9A-0967-493E-9CCA-718146B0F8E2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEj23cReEsy27C3Qkk0vvfsXu+VHkFAl4V4AkACgkQ0vvfsXu+ VHnBqRAAoDkumU4wkcMUfJz9KNpneReGYKpScDXawaE5bJYYrfA30zkI6ueS2xVI W0RhTdvjZvyzTxiSbHU8G03dNPFFiiZ7VWqYeUu+7QQ7dzrrk4lbZXnIUEMMLMgi jQguKmkpxB2lMlu3867y6w8v4Wf4XmBusphmah1Qhg0z8XWJQRH+LS9HmVpMA5an 3CEaHOHzNNu351b/+Deh/ck2+384U6Gg9nFqrmUIxx6T9t1RG31aDhHYa5oqlZQ7 j0qlTqs0xNtjJd7R0LsxrUMyh0NTruOTiOlvvA6Xw9NSILsq7EYwtRJCFbG3jW0p DYsEbjvCLAuWd4ABdYUKTsWNOX1LOmM4CYRG2I4OgU4LDxCyUKD8v/FsXNBdMLqL ip+Ej+3ok6KUeM+3xwE7540eZ2mZLWQkQ8fvA9mNDJPbdFlgaP3lIwjwNW2Yx64t 8674RQ+ku1LExLx2/8DIyqsgj4xrpyc4DgMbRbWloLzAeiYX+YSWZN5LecZmmh5A xAOrR2fbXCZIwzi1XdyPqkQ3b0a+IQZ3TOY+GSWGgmKSRXpNs+sUtEgRjh99oNlp 5Qi/q0VjYkJy9lD+M8dMVV60ZmRx11qH0quJfU/726me4HS0HJAnQ3UCUdHn6Mr4 vDL414hrPLtmsNJtdEsJFogVhhvMucAuVgnQxlHjzDg9h47vg2w= =EC3N -----END PGP SIGNATURE----- --Apple-Mail=_47BA7F9A-0967-493E-9CCA-718146B0F8E2-- From nobody Fri Jan 24 03:50:08 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E761200E6 for ; Fri, 24 Jan 2020 03:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ-0HjO5542T for ; Fri, 24 Jan 2020 03:49:58 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id C9667120044 for ; Fri, 24 Jan 2020 03:49:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F12C46601B7; Fri, 24 Jan 2020 13:49:55 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAkLnfGbrkag; Fri, 24 Jan 2020 13:49:54 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 1D8EB660135; Fri, 24 Jan 2020 13:49:54 +0200 (EET) From: Jari Arkko Content-Type: multipart/alternative; boundary="Apple-Mail=_54E228B8-94C2-46F6-A765-C9416EB4DF3F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 24 Jan 2020 13:49:53 +0200 Cc: Stephen Farrell To: model-t@iab.org, architecture-discuss@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 11:50:02 -0000 --Apple-Mail=_54E228B8-94C2-46F6-A765-C9416EB4DF3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The IAB are considering starting up a programme on Internet trust model evolution as described in the link at the bottom of this email. We'd like to get feedback on that idea and the text. As you may be aware, in 2019 a number of documents were published on this topic and discussions held (on the mailing list, SAAG, side meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual meeting coming up on February 14th. To be clear, any output from this program would be text offered=20 to the IETF for consideration - it is not within the IAB's remit, nor=20 that of an IAB program, to modify a BCP. Nonetheless, an IAB=20 program offers a good venue for this work, as it perhaps allows=20 for more focus on the evolving architecture aspect within this space. The plan is for the new program to be entirely open for participation, similar to how the current work has already been. That is, the mailing list is open for all interested to join, meetings are open and listed in the public agendas. The IAB will find a chair or chairs for the group to stay organised. There's no specific deadline for this, but the IAB will consider this further in the next few weeks, so if you could take a few minutes=20 to share your thoughts on this that'd be great. = https://github.com/intarchboard/model-t-charter/blob/master/model-t-charte= r-00.md = https://www.iab.org/mailman/listinfo/model-t = Stephen & Jari --Apple-Mail=_54E228B8-94C2-46F6-A765-C9416EB4DF3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

The IAB are considering starting up a = programme on Internet
trust model evolution as described = in the link at the bottom of this
email.

We'd like to get feedback on that idea and the text. As you = may
be aware, in 2019 a number of documents were published = on
this topic and discussions held (on the mailing list, = SAAG, side
meeting at IETF-106, workshops, etc). There=E2=80= =99s also a virtual
meeting coming up on February 14th.

To be clear, any output from this program = would be text offered 
to the IETF for consideration = - it is not within the IAB's remit, nor 
that of an = IAB program, to modify a BCP. Nonetheless, an IAB 
program offers a good venue for this work, as it perhaps = allows 
for more focus on the evolving architecture = aspect within this space.

The plan is for = the new program to be entirely open for participation,
similar to how the current work has already been. That is, = the mailing
list is open for all interested to join, = meetings are open and listed
in the public agendas. The = IAB will find a chair or chairs for the
group to stay = organised.

There's no specific deadline for = this, but the IAB will consider this
further in the = next few weeks, so if you could take a few minutes 
to share your thoughts on this that'd be great.

https://github.com/intarchboard/model-t-charter/blob/master/mod= el-t-charter-00.md
https://www.iab.org/mailman/listinfo/model-t

Stephen & = Jari

= --Apple-Mail=_54E228B8-94C2-46F6-A765-C9416EB4DF3F-- From nobody Fri Jan 24 05:49:53 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96EC120137; Fri, 24 Jan 2020 05:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6FDF3UiAguD; Fri, 24 Jan 2020 05:49:44 -0800 (PST) Received: from secgw1.intern.tuwien.ac.at (secgw1.intern.tuwien.ac.at [IPv6:2001:629:1005:30::71]) (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 5418E1200F4; Fri, 24 Jan 2020 05:49:43 -0800 (PST) Received: from totemomail (localhost [127.0.0.1]) by secgw1.intern.tuwien.ac.at (8.14.7/8.14.7) with ESMTP id 00ODnaWv011233; Fri, 24 Jan 2020 14:49:36 +0100 Received: from localhost ([127.0.0.1]) by totemomail (Totemo SMTP Server) with SMTP ID 719; Fri, 24 Jan 2020 14:49:36 +0100 (CET) Received: from edge13b.intern.tuwien.ac.at (edge13b.intern.tuwien.ac.at [IPv6:2001:629:1005:30::67]) by secgw1.intern.tuwien.ac.at (8.14.7/8.14.7) with ESMTP id 00ODnZDW011218 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 24 Jan 2020 14:49:35 +0100 Received: from mbx13c.intern.tuwien.ac.at (2001:629:1005:30::63) by edge13b.intern.tuwien.ac.at (2001:629:1005:30::67) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jan 2020 14:49:35 +0100 Received: from [10.0.0.11] (193.154.92.83) by mbx13c.intern.tuwien.ac.at (2001:629:1005:30::63) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jan 2020 14:49:35 +0100 To: Jari Arkko , , CC: Stephen Farrell References: From: Joachim Fabini Autocrypt: addr=joachim.fabini@tuwien.ac.at; keydata= xsFNBFzP9YwBEADLSwTOJGpr6+y+UQ2tko4lnJLfcazo3MHJq6w8CoOAeBhgvxHvksx48RpB JOculUcAP+Sr/dAsVJRvbrd3ZVFl5X+5rq5HqZtEER64JkZN3ZWwuZJ2cIPe8UrmPUCCSdDm Q2Ss3jWRYq+5bg9xG9pgRdfXQj4EzocE5+vnq1TEx5skuAK2pmntE29gCO8ICIO0qOtlNMyz UNPyb/wvVR/+8Umj5xO3kJrEjq7NpYCPP+I2nmRmrCVNQ+ruQGjHFbFzLCzeQj/Ln+vHJy3C O5qbBs/8aae2+7g/N642ODgXv78mg6k4r/yA2uCoeqirj9P6d/8qyhdU247oe+96FLwd4ly5 cHjmS5FEBhNsZKB3yPwod8phWwMZhPDro+ttkTRjL9CTmXspLFPlYwDqkuyEVMOHh24toFVI 0QukzYWLrMwY3ae0ni8DM5fcTQaFDWr4rqRcfGRhA66xxT4uUAX20q1VzWBO2fVUr0eB3Hwr FjCS7URAlsPFebuevgt1/pjSbcRk20TXPp//1qwh8GU03C6qy5iHB8coAsCwZec3S92YEdgM obdYgVhLPHOMd89IfldRASAConvQzI8WkiabzkMpL0donUUErNQ9RVFQ1NRoLJYIx2D0CMFN RW01q0xZFEKci+r/S2/YUkhXTXD4cEx4y3A4WCJPi0teSUW8owARAQABzSxKb2FjaGltIEZh YmluaSA8am9hY2hpbS5mYWJpbmlAdHV3aWVuLmFjLmF0PsLBgAQTAQgAKgIbIwUJCWYBgAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCXM/2+wIZAQAKCRCbDicB0srp1dEXEACLpHerJzi7 684Ixo6sgwQ0TM/oVV7unXIqFZuuZLMf4r609La++l0BXSmj6LtrIqZVXoFVRwIutEADmaKZ k2kc2zVaKWN/BM4/o8r0db/jOdElv8bbqsui1HYCA1KIKu2nNEMQd1axH0mzBUEFQaIoEPQP mQszQhKHw1ZgAjrsyvU7ZH9aHTboPvLURIAH0CBfgvnm+feFxl/rMBSLu5CJpff9cWA1inKX 1eEexy2tFR80NUSaLauRLC9j9Xe2q+7DLNAT16+5dgRt16bXlkUh4IMpG5k6vpyFu12vSfcB VHJZEKld9APoHoHdjgq7QSeyENfZU+XeAzT/U0fDvF7v392/Fnw7UfVNi5TW2DjiR1cf5ahG YNzfJlIRmiFAkGAxjA6LV6tidpr+KtKvgTh00JZoHVpd4f26/bRTuHXzZh/G36r1bo3qYaQQ mebj6HocdFofh4dN08zv9tiYfrn9uAScZ8JeNQQWb1fg8a2a3nnGLAQiqyFKiuklczA/wkcV ZklezqdO/8nhEhSmiGOLiVwCCdMOBwwBhhJc3iXNYt+pp/v+X/T6m10wwJrwF0JVaPsKqk/m XwCw3jCjcu6iBHPwxS5qmCyJJmBwqq8RtA+Bjdp4J1CIJN3cb+fDoteXBJHYSWYFNGSa9wC4 kSGpw/5LyucT7vSCSolwdC0YVc7BTQRcz/WMARAAyMkUJLJo7g0HwerlxK2kzncvpN0ACN+b Dq89kxJPpbUivE/5I8CTpYQUVBEIq7mvk5/vZj7NWiOdBqW7yx3pmnSuzVtIy7+SB9nVm4mZ InnHij8g1IQ5267C2x1jv93PdbGXFFeEHHg0h/4GjN//3ScyhKt0vf6tDPjGwkUe5tvpvTx7 NiCW2D5hk+tQf5FcvKhwFYCKC6b9DaIb19QgjuANo/g6is/n5M4CYiX+Pqx5j+J6NjG9hMLc 4GTSQur8Ix7LZ3G78z7zB1AdiJMCyeaqrYKTVWNsz1DB5MRiGl9Wz5Q9LZu070neMuoOHD+0 Aaud5JbI8YozvxwTbNN8/fV6byVWvCCmtd8ZZDKfQXgav2HvtejFlm0ix9MTl87+OUGbpLtm WIS/2qZtamrTVfv5dVlCM9ziHkkhV75nMr6X6h+tAaedboC7xIWR8bAC4HGk3KN1cmwjgy4D G87X+tYNmzhAQHioHEEvfklNXOIvU5coDzpdp/n9OxQxPlA5qC+BDSixQqsu5iTcPaA0iGij Ja3A7Wg69ybigctY22ICCvyUv8WgRoCWcHNfjI3sJULLk+SfygEALfgWQ9xKQI+L0M5h+Tq4 2RUpYVC2HKGtzQZ7YhSQcHu9NobA/4qVJcCF+tZXV5mPeMg5LHpmNhfSQRYgbk2KBvaqJw2D MbsAEQEAAcLBZQQYAQgADwUCXM/1jAIbDAUJCWYBgAAKCRCbDicB0srp1YnTD/0Qao7t3YNk Rc04ed1slc22Ned54huNF10TD5+QVSjfdjiMrlUNYznjqnMEdWDaHKclQS7WaBJO2GetSPFr Etk/IJ0bM+C9GjYh+kfqA0X45X8KC4/XLoARd4I+B4uLk+i0UbhlnL9sibVaIGG6IC6S1HGN M0yA9RJ0FPXl4/QV5JAkLNSDKCiyeFjACqExLk7HHNACrLO8Jr7IH8RDE3rlIEgdWxwTIs+9 GeLvMdtasnfEloZCsGb2proOu1QhMZlqoftLhtMzW+4lEmJnUAfxHZRivpjjlQVtWIQ03t6f txnqh4plL3gJsGV+y4ty4emTN9MJsDAyphkqKPqv29hJTyHoeixSG7G0KT/gO+JqTWm/7wwU d7xOW+WtjsXhNM5k5aJtTGpGAwC6QkKnodu+WUkYxpXJKU4cmEBguFQPCwTlFzh7+Jo98Vbh N9cJUQ5iJau00lDU3qJIcbsD06ccy1EoBjIiqAH59DnumrnP99J6iNj8yCxStc1TjA3dRReu +iOGwyoUlp48c3UlpK4BkSegtd2CA37xkiesebEUoRYiAld410PETVlHCQX/kBa6iAx4oEoG lS4E9h1XOCVa0fnJZfwq00WHUbT+P3E3/svKw63HccEuLHBETuowX1ECcGf7s6E9aaexLqbV jVz9rWWAUFG680+ewfjVKZjb5Q== Message-ID: <27d65034-22be-e2b1-bdb1-f2cbc05ec663@tuwien.ac.at> Date: Fri, 24 Jan 2020 14:49:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US X-ClientProxiedBy: mbx13a.intern.tuwien.ac.at (2001:629:1005:30::61) To mbx13c.intern.tuwien.ac.at (2001:629:1005:30::63) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by secgw1.intern.tuwien.ac.at id 00ODnZDW011218 Archived-At: Subject: Re: [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 13:49:52 -0000 Jari, Stephen, all, I support the IAB initiative. As a detailed reply to some aspects mentioned in the draft charter: imo - it's needed that these threat/trust model activities find a home. The IAB taking the lead can help in covering a wide variety of perspectives (including aspects that some may consider research). - the potential impact of the threat model on future activities is too high to handle it within a closed group and/or side-meetings. Being open for public participation and becoming more visible (by listing the sessions in the program) can help to include perspectives of all affected parties. - the major challenge (imho) is an appropriate scope of the new model while keeping it simple, usable and relevant for most of us (as your draft and the charter both mention). Various areas/stakeholders/systems may have conflicting views and priorities at architectural/structural/protocol/security/privacy levels. - An unbiased discussion/review on (explicit and, in particular, implicit) prerequisites that RFC3552 relies on and if/how they changed within the last 17 years may be a good start (fitting topic 2 of the expected outputs). At a technical level the term "compromised" (*) may benefit from a refined perspective and definition. It sounds simple, but thinking of group communications (multicast, broadcast) it becomes a challenge. thanks Joachim PS: (*): or "compromisable"? The safe (realistic) assumption is to consider any system to be vulnerable. On 24/01/2020 12:49, Jari Arkko wrote: >=20 > The IAB are considering starting up a programme on Internet > trust model evolution as described in the link at the bottom of this > email. >=20 > We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on > this topic and discussions held (on the mailing list, SAAG, side > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th. >=20 > To be clear, any output from this program would be text offered=C2=A0 > to the IETF for consideration - it is not within the IAB's remit, nor=C2= =A0 > that of an IAB program, to modify a BCP. Nonetheless, an IAB=C2=A0 > program offers a good venue for this work, as it perhaps allows=C2=A0 > for more focus on the evolving architecture aspect within this space. >=20 > The plan is for the new program to be entirely open for participation, > similar to how the current work has already been. That is, the mailing > list is open for all interested to join, meetings are open and listed > in the public agendas. The IAB will find a chair or chairs for the > group to stay organised. >=20 > There's no specific deadline for this, but the IAB will=C2=A0consider t= his > further in the next few weeks, so if you could=C2=A0take a few minutes=C2= =A0 > to share your thoughts on this=C2=A0that'd be great. >=20 > https://github.com/intarchboard/model-t-charter/blob/master/model-t-cha= rter-00.md > https://www.iab.org/mailman/listinfo/model-t >=20 > Stephen & Jari >=20 >=20 --=20 --------------------------------------- Dr. Joachim Fabini Senior Scientist Institute of Telecommunications TU Wien Gusshausstrasse 25/E389 A-1040 Vienna, Austria Tel: +43 1 58801-38813 mailto: Joachim.Fabini@tuwien.ac.at --------------------------------------- From nobody Fri Jan 24 11:46:57 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC56312087B for ; Fri, 24 Jan 2020 11:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MQfZxA25MpW for ; Fri, 24 Jan 2020 11:46:52 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 45BB612011E for ; Fri, 24 Jan 2020 11:46:52 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id 4so1644304pgd.6 for ; Fri, 24 Jan 2020 11:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Az2Kkbjs2kzUtVWge3eLMIk1jN0NnpaYkKw/6D/hvAE=; b=epazG/oqJLxe5Zes4PBGz/QqxgulCiU17ConJMS3r5f/8E+q4ctzBchEqcC+5x3uU5 Kx6nguBKB+tWSmN6mkTsBzBVPINDgYz7emHsPQqsJY96Qsm1qIIVboUbU6kjBK3BwJLE IeVEVYCRN4OZPzOXlhm8qf13d6O3ccIRLnEatGRgcvFf+eddRCbxG/LyhkEJrlXZiu8f 9NHOKkQLkWMTGw4jXJM40uviKHo9ah3+u1KutCcEarr0eUVqsfZKH89CqvqvaLtrJedL WLG45+a7XX9/iTOnO5gcc96YnKL55TjXbN3TbMuwEiMju+Y3XaQ36nySJJfHJEUy1O0h ojMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Az2Kkbjs2kzUtVWge3eLMIk1jN0NnpaYkKw/6D/hvAE=; b=XGl9CrxFVG76O8pL+m9PlWRlR3BElGe0id0w1uHYeWs3cTW3S8+z7KthAbSRWUrAca bNkQM+SUwccFm51XD5FaqqhPmH6JVqKFM16K+DnIOpWKCDc/dOHo0P583iwE5dbYfHD5 xh46Mluuf8lhMxlSN4/LpZlfPvOT1yvMecCtih6mEldcdOgfJ+mm7A5lp2U7pUyzE5R6 MsNMmQ+cgmkOl5DPw1ONqB0traNouh7BML8D7BAe5shYSJwbag3A6EKyCPlYW0yhCHIr mXDl2WlRlj2Sw4yT59X2lanfut/zgnD7m8t9QMKH1b87YRjMKIgj/LBauuXU4Cd5f5DF pJ+A== X-Gm-Message-State: APjAAAVbniD8XMe6CwRUVchooHnhlCnm8TtVzvpHi9J1s20DfnZyuQMw 94Tk5C4gaHZxUD9ND+9FhWbcc8vo X-Google-Smtp-Source: APXvYqzy7HU6gQc6/gBl4/JL/F9NWhA/w2Vf+gMptDEgYWnQ6YaKeYuMF2vz8R1t3ItrtA0xkWlb5A== X-Received: by 2002:a65:4c82:: with SMTP id m2mr5656645pgt.432.1579895211390; Fri, 24 Jan 2020 11:46:51 -0800 (PST) Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id 136sm7343202pgg.74.2020.01.24.11.46.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jan 2020 11:46:50 -0800 (PST) To: Jari Arkko , model-t@iab.org, architecture-discuss@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 25 Jan 2020 08:46:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 19:46:55 -0000 Hi, I'm confused. What we have in RFC3552 is very intentionally guidance for RFC writers on what they need to cover in their RFCs. Its specific purpos= e was to get rid of "Security considerations are not discussed in this memo= =2E"=20 Its purpose was not primarily to define an abstraction like a "trust mode= l" or a "threat model" (the draft charter seems a bit vague about which of t= hose it means). I really do not want to see the pragmatic purpose of RFC3552 lost in the effort to define these abstractions. I don't think that is the intention,= but the text seems to imply that RFC3552 was mainly a description of a generic threat model, which it wasn't. I am not against an IAB effort to analyse how the threat and trust models= (plural) have evolved since the security workshop [RFC2316] that ultimate= ly led to RFC3552. That seems like a good idea. An update of "Guidelines for= Writing RFC Text on Security Considerations" also seems like a good idea.= But the draft charter text seems to conflate these two separate lines of action. Incidentally, while writing the above it occurred to me why the phrase "IAB program" has always slightly disturbed me. Really the proposal is a virtual IAB workshop (whereas RFC2316 came from three days in a room together in Murray Hill, NJ). A good idea, but not a program. Regards Brian On 25-Jan-20 00:49, Jari Arkko wrote: >=20 > The IAB are considering starting up a programme on Internet > trust model evolution as described in the link at the bottom of this > email. >=20 > We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on > this topic and discussions held (on the mailing list, SAAG, side > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th. >=20 > To be clear, any output from this program would be text offered=C2=A0 > to the IETF for consideration - it is not within the IAB's remit, nor=C2= =A0 > that of an IAB program, to modify a BCP. Nonetheless, an IAB=C2=A0 > program offers a good venue for this work, as it perhaps allows=C2=A0 > for more focus on the evolving architecture aspect within this space. >=20 > The plan is for the new program to be entirely open for participation, > similar to how the current work has already been. That is, the mailing > list is open for all interested to join, meetings are open and listed > in the public agendas. The IAB will find a chair or chairs for the > group to stay organised. >=20 > There's no specific deadline for this, but the IAB will=C2=A0consider t= his > further in the next few weeks, so if you could=C2=A0take a few minutes=C2= =A0 > to share your thoughts on this=C2=A0that'd be great. >=20 > https://github.com/intarchboard/model-t-charter/blob/master/model-t-cha= rter-00.md > https://www.iab.org/mailman/listinfo/model-t >=20 > Stephen & Jari >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Fri Jan 24 12:03:55 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D901209AC for ; Fri, 24 Jan 2020 12:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZsfKJzo7APK for ; Fri, 24 Jan 2020 12:03:49 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 56DC312098A for ; Fri, 24 Jan 2020 12:03:49 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id v201so1961230lfa.11 for ; Fri, 24 Jan 2020 12:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HcV+gfYMBzK6IBaq6FqQOOYlUYk47nORjhgCERFbyM4=; b=Cyv3NcTznk8Qws0KlrPIj7grcEo4IETDyHgM5LOrDC4dwvhPMIAE5Cqmb9ZV2dCBMk 6jIujoCRpY0aq8B4bFaWwpPIknC6GFTp5/FSL5Zvl4Qhd8I8hjsxYtMbN/T5hUei96cn /AdHUJ/fWUnCa8dYM5UiIVe/4PdnPYpPl1KjFonl0+/70tkgC5xuA8IMv+onQ4LD+v2A KoiUoDcBnF69gFHve3B4fJrxm/Ht9Bear2lq6ApaP8yHYGRNFFsy21wGB6+brzR+CH7O yZsVKaIsp4wCgH1NGUauWIqR2ggL8G+t9SF4KUFhy9jpcbE7TqNELR99deSbyJzem8RO d+gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HcV+gfYMBzK6IBaq6FqQOOYlUYk47nORjhgCERFbyM4=; b=XIOybm4wxNx7WeXkHULEUhGZA3QTJqgm3hyO0/fsYiK05co0WrI8rUCDsSQu6F8cfx SjhOWZJHbwHCHG1tWCHZgRo+oOWDvC5YcvkwUGvzLncVACINiDNAkUZMCUaClBXIK39X hBdE7/qGXkZgOzM71b77QcA6tJF7+v1EuBBkLB8DY1SwATAnEG5io+DZvpEGRC6K8RY8 M/Qhlbk44VWcc/beuqVUjhfHNXhis92Hb1KDa6OoW6M9MCeecgwOxZJ2MBVERZ5J/AdS FxRtOn5G+LuIM+7Gt1y6KzsRn5syXPLG60m+oMFVQ4SxF4A8Yy+xQM8CfWoE2WLjlZ10 +pkA== X-Gm-Message-State: APjAAAUpIZYq2L92/LOSj3KNyz3k5wR8591thXntH1a56enbSXBs7Dpi 20GpqngShTn7SqYNz8ry6L0HgFz0c2xKqAFZque5Cg== X-Google-Smtp-Source: APXvYqwgpeO9Pt8sru2nXD+c3/UzapxNmLMnnce0Kbr2DUAeMPk6m62O1VyMfpfDulnapFHQp/0VdYSDUrIJtELVUuQ= X-Received: by 2002:a05:6512:64:: with SMTP id i4mr2138908lfo.55.1579896227417; Fri, 24 Jan 2020 12:03:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 24 Jan 2020 12:03:11 -0800 Message-ID: To: Brian E Carpenter Cc: Jari Arkko , model-t@iab.org, architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000006ae7b9059ce841c8" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 20:03:53 -0000 --0000000000006ae7b9059ce841c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian's comments match my recollection. Specifically, we didn't think we were *defining* a threat model as much as documenting a consensus model that already existed. Incidentally, it's not clear to me what a "trust model" is. This is not a term that appears in 3552 nor is it a real term of art that I am familiar with. Taking a step back, I remain unpersuaded that the 3552 threat model is really out of data. The two main deficiencies I have heard floated are: 1. That it doesn't take into account traffic analysis and pervasive monitoring. 2. That the assumption that endpoints are uncompromised is unrealistic. I can see some merit in the first point, but this seems to really be more a matter of emphasis: 3552 already specifies a Dolev-Yao style attacker, which means that it can observe all communications. So really what has happened is that we have a clearer picture of just how realistic that is and what you can do with that kind of access. I can see some kind of update, but again it's less about threat model than about modern examples. As far as the second point goes, I think that when you are thinking about comsec protocols it's still true that you can't do much if you don't trust the endpoints. I think 3552 could be a bit better about recognizing that there are malicious actors in the system, though obviously that's implicit in the discussion of DoS. Anyway, this doesn't seem like much of an update to the threat model. What does feel dated in 3552 (at least to me) is the emphasis on a bunch of very old school protocols and the more or less total elision of the Web. In particular, if we're talking in terms of threat model, the idea that you have a lot of different untrusted programs running on your machine (i.e., in the JS VM) and that you need to secure them from each other really is new and could use some documenting. It's worth noting, however, that (a) that's largely about implementation and (b) that that system strives to achieve the kind of "each endpoint its own isolated unit" ideal that 3552 asumes. -Ekr On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > I'm confused. What we have in RFC3552 is very intentionally guidance for > RFC writers on what they need to cover in their RFCs. Its specific purpos= e > was to get rid of "Security considerations are not discussed in this > memo." > Its purpose was not primarily to define an abstraction like a "trust mode= l" > or a "threat model" (the draft charter seems a bit vague about which of > those > it means). > > I really do not want to see the pragmatic purpose of RFC3552 lost in the > effort to define these abstractions. I don't think that is the intention, > but the text seems to imply that RFC3552 was mainly a description of a > generic threat model, which it wasn't. > > I am not against an IAB effort to analyse how the threat and trust models > (plural) have evolved since the security workshop [RFC2316] that ultimate= ly > led to RFC3552. That seems like a good idea. An update of "Guidelines for > Writing RFC Text on Security Considerations" also seems like a good idea. > But the draft charter text seems to conflate these two separate lines of > action. > > Incidentally, while writing the above it occurred to me why the phrase > "IAB program" has always slightly disturbed me. Really the proposal is > a virtual IAB workshop (whereas RFC2316 came from three days in a room > together in Murray Hill, NJ). A good idea, but not a program. > > Regards > Brian > > On 25-Jan-20 00:49, Jari Arkko wrote: > > > > The IAB are considering starting up a programme on Internet > > trust model evolution as described in the link at the bottom of this > > email. > > > > We'd like to get feedback on that idea and the text. As you may > > be aware, in 2019 a number of documents were published on > > this topic and discussions held (on the mailing list, SAAG, side > > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > > meeting coming up on February 14th. > > > > To be clear, any output from this program would be text offered > > to the IETF for consideration - it is not within the IAB's remit, nor > > that of an IAB program, to modify a BCP. Nonetheless, an IAB > > program offers a good venue for this work, as it perhaps allows > > for more focus on the evolving architecture aspect within this space. > > > > The plan is for the new program to be entirely open for participation, > > similar to how the current work has already been. That is, the mailing > > list is open for all interested to join, meetings are open and listed > > in the public agendas. The IAB will find a chair or chairs for the > > group to stay organised. > > > > There's no specific deadline for this, but the IAB will consider this > > further in the next few weeks, so if you could take a few minutes > > to share your thoughts on this that'd be great. > > > > > https://github.com/intarchboard/model-t-charter/blob/master/model-t-chart= er-00.md > > https://www.iab.org/mailman/listinfo/model-t > > > > Stephen & Jari > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > -- > Model-t mailing list > Model-t@iab.org > https://www.iab.org/mailman/listinfo/model-t > --0000000000006ae7b9059ce841c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian's comments match my recollection. Specifica= lly, we didn't think we were *defining* a threat model as much as docum= enting a consensus model that already existed. Incidentally, it's not c= lear to me what a "trust model" is. This is not a term that appea= rs in 3552 nor is it a real term of art that I am familiar with.
=
Taking a step back, I remain unpersuaded that the 3552 threa= t model is really out of data. The two main deficiencies I have heard float= ed are:

1. That it doesn't take into account t= raffic analysis and pervasive monitoring.
2. That the assumption = that endpoints are uncompromised is unrealistic.

I= can see some merit in the first point, but this seems to really be more a = matter of emphasis: 3552 already specifies a Dolev-Yao style attacker, whic= h means that it can observe all communications. So really what has happened= is that we have a clearer picture of just how realistic that is and what y= ou can do with that kind of access. I can see some kind of update, but agai= n it's less about threat model than about modern examples.
As far as the second point goes, I think that when you are thi= nking about comsec protocols it's still true that you can't do much= if you don't trust the endpoints. I think 3552 could be a bit better a= bout recognizing that there are malicious actors in the system, though obvi= ously that's implicit in the discussion of DoS. Anyway, this doesn'= t seem like much of an update to the threat model.

What does feel dated in 3552 (at least to me) is the emphasis on a bu= nch of very old school protocols and the more or less total elision of the = Web. In particular, if we're talking in terms of threat model, the idea= that you have a lot of different untrusted programs running on your machin= e (i.e., in the JS VM) and that you need to secure them from each other rea= lly is new and could use some documenting. It's worth noting, however, = that (a) that's largely about implementation and (b) that that system s= trives to achieve the kind of "each endpoint its own isolated unit&quo= t; ideal that 3552 asumes.

-Ekr

=

= On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi,=

I'm confused. What we have in RFC3552 is very intentionally guidance fo= r
RFC writers on what they need to cover in their RFCs. Its specific purpose<= br> was to get rid of "Security considerations are not discussed in this m= emo."
Its purpose was not primarily to define an abstraction like a "trust m= odel"
or a "threat model" (the draft charter seems a bit vague about wh= ich of those
it means).

I really do not want to see the pragmatic purpose of RFC3552 lost in the effort to define these abstractions. I don't think that is the intentio= n,
but the text seems to imply that RFC3552 was mainly a description of a
generic threat model, which it wasn't.

I am not against an IAB effort to analyse how the threat and trust models (plural) have evolved since the security workshop [RFC2316] that ultimately=
led to RFC3552. That seems like a good idea. An update of "Guidelines = for
Writing RFC Text on Security Considerations" also seems like a good id= ea.
But the draft charter text seems to conflate these two separate lines of action.

Incidentally, while writing the above it occurred to me why the phrase
"IAB program" has always slightly disturbed me. Really the propos= al is
a virtual IAB workshop (whereas RFC2316 came from three days in a room
together in Murray Hill, NJ). A good idea, but not a program.

Regards
=C2=A0 =C2=A0Brian

On 25-Jan-20 00:49, Jari Arkko wrote:
>
> The IAB are considering starting up a programme on Internet
> trust model evolution as described in the link at the bottom of this > email.
>
> We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on
> this topic and discussions held (on the mailing list, SAAG, side
> meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th.
>
> To be clear, any output from this program would be text offered=C2=A0<= br> > to the IETF for consideration - it is not within the IAB's remit, = nor=C2=A0
> that of an IAB program, to modify a BCP. Nonetheless, an IAB=C2=A0
> program offers a good venue for this work, as it perhaps allows=C2=A0<= br> > for more focus on the evolving architecture aspect within this space.<= br> >
> The plan is for the new program to be entirely open for participation,=
> similar to how the current work has already been. That is, the mailing=
> list is open for all interested to join, meetings are open and listed<= br> > in the public agendas. The IAB will find a chair or chairs for the
> group to stay organised.
>
> There's no specific deadline for this, but the IAB will=C2=A0consi= der this
> further in the next few weeks, so if you could=C2=A0take a few minutes= =C2=A0
> to share your thoughts on this=C2=A0that'd be great.
>
> https://github= .com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md
> https://www.iab.org/mailman/listinfo/model-t >
> Stephen & Jari
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss
>

--
Model-t mailing list
Model-t@iab.org https://www.iab.org/mailman/listinfo/model-t
--0000000000006ae7b9059ce841c8-- From nobody Fri Jan 24 12:22:18 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8975120858 for ; Fri, 24 Jan 2020 12:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 A9DYKz0whmsC for ; Fri, 24 Jan 2020 12:22:11 -0800 (PST) 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 13DF312099C for ; Fri, 24 Jan 2020 12:22:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 77803BE20; Fri, 24 Jan 2020 20:22:07 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 bjOesnX3O1bB; Fri, 24 Jan 2020 20:22:05 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 308BCBDCF; Fri, 24 Jan 2020 20:22:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579897325; bh=drW5tHtfG+FZtA+si0PKrtKJ2lG/IkFiFYJoLtCqSIg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AYtgyWV64XmawGFAcARB3EqkIgJg8R/kJPmCXm00jzxSrhKONAzoRkJuO29SU8qPX 7rNg3KDDpeMeKbrTxtSVzQ3iFQ1iq/ZglTl5SuKzPhcPCZjaPBs8GZuFZ+Ep6w04Cj vLYjasmSzYaOtrYYWyHzQVbkA7J3+8esdnlIoPx8= To: Eric Rescorla , Brian E Carpenter Cc: architecture-discuss@ietf.org, model-t@iab.org References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 24 Jan 2020 20:22:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9moab8tQIcFis3ak8beZLk3LF8zL26CUf" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 20:22:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9moab8tQIcFis3ak8beZLk3LF8zL26CUf Content-Type: multipart/mixed; boundary="guGERX3toLMsQMfHoSUHsooiYhny92aEc"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , Brian E Carpenter Cc: architecture-discuss@ietf.org, model-t@iab.org Message-ID: Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution References: In-Reply-To: --guGERX3toLMsQMfHoSUHsooiYhny92aEc Content-Type: multipart/mixed; boundary="------------326BFE266DA53FDAA8728883" Content-Language: en-US This is a multi-part message in MIME format. --------------326BFE266DA53FDAA8728883 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 24/01/2020 20:03, Eric Rescorla wrote: > Incidentally, it's not clear to me what a "trust > model" is. This is not a term that appears in 3552 nor is it a real ter= m of > art that I am familiar with. Crap! Checking back to the initial text, that was my fault - must've been some form of Freudian typo though 'cause I also don't know what a "trust model" might be. Please read s/trust model/threat model/ everywhere relevant, and apologies for the slip up. I've modified [1] to fix at least that, Sorry again, S. [1] https://github.com/intarchboard/model-t-charter/blob/master/model-t-chart= er-00.md --------------326BFE266DA53FDAA8728883 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------326BFE266DA53FDAA8728883-- --guGERX3toLMsQMfHoSUHsooiYhny92aEc-- --9moab8tQIcFis3ak8beZLk3LF8zL26CUf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4rUewACgkQWrL68XsX K+ondw/+JftYaMoMKBOW0+8VgoDbbpSr509trCqeCUsdSWSVxpmmBfF3rw0tdlKX R7opKRZGuOslJTkgP2j1z7OlKgAwN2nmpIGjHal7JFPS71VuibzaHtTgzLMi8SZu AdJ+D/livTiMyRtpWfR2rP3ATw3fjT/b432e25so09EvctEsva4yb2saGejh0H7V XiIpjfcP8fc6QW0+yOLO5mQ7jW0UesU0Crd4keO3B+gAs3HGmleyG9idBPlIahF4 FCdvP69ZFR8jaCxsvpKYSyli5CzLKeIXcL/OSU51HmWsMeC3fPaQVl+618GCbd8B gnjWvJ/uC5dnin4rzjrG3/XjhaN3ypnYI63xVqfZafvXxLLL68rz1gOte6BUGFdE J+pmOwSUd5bnb5gk0YpeQ97ZLfyCpm1EXBGTcS5q85cucyIN0/PWUAP+d1yrwRpE CC/L/WybeFJDac5s6QDeKr4HcyA1sxR26hQPWfSMFHpRSsnEfH+xxGuYuCw8yX3y vtIBFSBAZJmCq17vp8Jn8/tzSwAZ52WTlZKuei9e+Hu1Afz6bBI6HGNfKWqPF342 8kGarfOoShQ6nHUSmmt28pSU42QJBQYMewV3tAufmK5ShHt/30FBJshsmC1Anpon kXKl5tx2R2ZA4+iaCANhadMdhZNCZ+GBthzmDQu8u/lyxSK1wMI= =DtlX -----END PGP SIGNATURE----- --9moab8tQIcFis3ak8beZLk3LF8zL26CUf-- From nobody Fri Jan 24 12:25:49 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FDD1209F5 for ; Fri, 24 Jan 2020 12:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhykA5oQSuHr for ; Fri, 24 Jan 2020 12:25:42 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711111209E9 for ; Fri, 24 Jan 2020 12:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23260; q=dns/txt; s=iport; t=1579897541; x=1581107141; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=qOCPSnh35USgOSN7RiLO9iMol9DUtjCA5bDmOCuvYJk=; b=cBOQ5lS33mb97ZE03Lw1p/nQkKyMnbxevCTb7lpegTeieryM3lyEJYh9 xurHiancj2ddP5HXBUQmYuYsGlM0+mpRBKggqvOpxdZCJ/egyyiy0nPpG 2kX+rQitFTubZ2bxO535ycbKr5t+dIxYIWS5MXmitGx5wB1XcXewU14mA o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCBwBkUite/xbLJq1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBJYFwVSASKoQSiQOIN4EBhjyCJI9wgWcCBwEBAQkDAQEYAQw?= =?us-ascii?q?KAQGDCnFFAoJGOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQIBAQEhSwsFCws?= =?us-ascii?q?OBAYVEgMCAiEGHwMOBhODJgGCSgMOIA+tEnWBMoVKgk0NghAKBoE4gVOKXoI?= =?us-ascii?q?AgREnIIFOEjcHLj6CG0kBAYEeEgESAVUJglEygiwElzSXYESCQ4JMgRyDWop?= =?us-ascii?q?MhCkbgkiMKIwMkCqHGoIkjFeDLgIEBgUCFYFpIio9cTMaCBsVOyoBgkE+Ehg?= =?us-ascii?q?NV4cGMBcVgzuFFIU+AkADMAKLIoIyAQE?= X-IronPort-AV: E=Sophos;i="5.70,358,1574121600"; d="asc'?scan'208,217";a="22534795" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jan 2020 20:25:38 +0000 Received: from [10.61.171.81] ([10.61.171.81]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 00OKPb4e019325 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Jan 2020 20:25:38 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9FB7251E-477E-443A-AA64-AEBB2602FE0A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Fri, 24 Jan 2020 21:25:37 +0100 In-Reply-To: Cc: Brian E Carpenter , architecture-discuss@ietf.org, model-t@iab.org To: Eric Rescorla References: X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.171.81, [10.61.171.81] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 20:25:46 -0000 --Apple-Mail=_9FB7251E-477E-443A-AA64-AEBB2602FE0A Content-Type: multipart/alternative; boundary="Apple-Mail=_302D8F54-40AB-4EF2-9505-7537A093C282" --Apple-Mail=_302D8F54-40AB-4EF2-9505-7537A093C282 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, I appreciate your specificity. It really helps to focus the discussion. I would say that the world is a more complex place than it was when 3552 = was written. That is not to say that the document is out of date, but = rather that it is reasonable to explore what confidentiality means in = various contexts and how that relates to integrity. Also, I do think it=E2=80=99s worthy addressing a slightly different = threat model: when the endpoint that you purchased may be a threat to = you, and whether there is something to be done about that. I gave an = example on another list of an Internet toy that has an undisclosed = microphone and camera that invade=E2=80=99s a child=E2=80=99s privacy. We discussed another case in which there needs to be auditing of train = signaling systems. And there are very complex cases involving medical = devices that are probably worthy of discussion. Does any of this require an update to 3552? I think that would be = premature to say. But they=E2=80=99re probably worthy of discussion. Eliot > On 24 Jan 2020, at 21:03, Eric Rescorla wrote: >=20 > Brian's comments match my recollection. Specifically, we didn't think = we were *defining* a threat model as much as documenting a consensus = model that already existed. Incidentally, it's not clear to me what a = "trust model" is. This is not a term that appears in 3552 nor is it a = real term of art that I am familiar with. >=20 > Taking a step back, I remain unpersuaded that the 3552 threat model is = really out of data. The two main deficiencies I have heard floated are: >=20 > 1. That it doesn't take into account traffic analysis and pervasive = monitoring. > 2. That the assumption that endpoints are uncompromised is = unrealistic. >=20 > I can see some merit in the first point, but this seems to really be = more a matter of emphasis: 3552 already specifies a Dolev-Yao style = attacker, which means that it can observe all communications. So really = what has happened is that we have a clearer picture of just how = realistic that is and what you can do with that kind of access. I can = see some kind of update, but again it's less about threat model than = about modern examples. >=20 > As far as the second point goes, I think that when you are thinking = about comsec protocols it's still true that you can't do much if you = don't trust the endpoints. I think 3552 could be a bit better about = recognizing that there are malicious actors in the system, though = obviously that's implicit in the discussion of DoS. Anyway, this doesn't = seem like much of an update to the threat model. >=20 > What does feel dated in 3552 (at least to me) is the emphasis on a = bunch of very old school protocols and the more or less total elision of = the Web. In particular, if we're talking in terms of threat model, the = idea that you have a lot of different untrusted programs running on your = machine (i.e., in the JS VM) and that you need to secure them from each = other really is new and could use some documenting. It's worth noting, = however, that (a) that's largely about implementation and (b) that that = system strives to achieve the kind of "each endpoint its own isolated = unit" ideal that 3552 asumes. >=20 > -Ekr >=20 >=20 > On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter = > = wrote: > Hi, >=20 > I'm confused. What we have in RFC3552 is very intentionally guidance = for > RFC writers on what they need to cover in their RFCs. Its specific = purpose > was to get rid of "Security considerations are not discussed in this = memo." > Its purpose was not primarily to define an abstraction like a "trust = model" > or a "threat model" (the draft charter seems a bit vague about which = of those > it means). >=20 > I really do not want to see the pragmatic purpose of RFC3552 lost in = the > effort to define these abstractions. I don't think that is the = intention, > but the text seems to imply that RFC3552 was mainly a description of a > generic threat model, which it wasn't. >=20 > I am not against an IAB effort to analyse how the threat and trust = models > (plural) have evolved since the security workshop [RFC2316] that = ultimately > led to RFC3552. That seems like a good idea. An update of "Guidelines = for > Writing RFC Text on Security Considerations" also seems like a good = idea. > But the draft charter text seems to conflate these two separate lines = of > action. >=20 > Incidentally, while writing the above it occurred to me why the phrase > "IAB program" has always slightly disturbed me. Really the proposal is > a virtual IAB workshop (whereas RFC2316 came from three days in a room > together in Murray Hill, NJ). A good idea, but not a program. >=20 > Regards > Brian >=20 > On 25-Jan-20 00:49, Jari Arkko wrote: > > > > The IAB are considering starting up a programme on Internet > > trust model evolution as described in the link at the bottom of this > > email. > > > > We'd like to get feedback on that idea and the text. As you may > > be aware, in 2019 a number of documents were published on > > this topic and discussions held (on the mailing list, SAAG, side > > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > > meeting coming up on February 14th. > > > > To be clear, any output from this program would be text offered > > to the IETF for consideration - it is not within the IAB's remit, = nor > > that of an IAB program, to modify a BCP. Nonetheless, an IAB > > program offers a good venue for this work, as it perhaps allows > > for more focus on the evolving architecture aspect within this = space. > > > > The plan is for the new program to be entirely open for = participation, > > similar to how the current work has already been. That is, the = mailing > > list is open for all interested to join, meetings are open and = listed > > in the public agendas. The IAB will find a chair or chairs for the > > group to stay organised. > > > > There's no specific deadline for this, but the IAB will consider = this > > further in the next few weeks, so if you could take a few minutes > > to share your thoughts on this that'd be great. > > > > = https://github..com/intarchboard/model-t-charter/blob/master/model-t-chart= er-00.md = > > https://www.iab.org/mailman/listinfo/model-t = > > > > Stephen & Jari > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss = > > >=20 > -- > Model-t mailing list > Model-t@iab.org > https://www.iab.org/mailman/listinfo/model-t = > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss = --Apple-Mail=_302D8F54-40AB-4EF2-9505-7537A093C282 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

I appreciate = your specificity.  It really helps to focus the = discussion.

I = would say that the world is a more complex place than it was when 3552 = was written.  That is not to say that the = document is out of date, but rather that it is reasonable to explore = what confidentiality means in various contexts and how that relates to = integrity.

Also,= I do think it=E2=80=99s worthy addressing a slightly different threat = model: when the endpoint that you purchased may be a threat to you, and = whether there is something to be done about that.  I gave an = example on another list of an Internet toy that has an undisclosed = microphone and camera that invade=E2=80=99s a child=E2=80=99s = privacy.

We = discussed another case in which there needs to be auditing of train = signaling systems.  And there are very complex cases involving = medical devices that are probably worthy of discussion.

Does any of this require = an update to 3552?  I think that would be premature to say. =  But they=E2=80=99re probably worthy of discussion.

Eliot

On 24 Jan 2020, at 21:03, Eric Rescorla <ekr@rtfm.com> = wrote:

Brian's comments match my = recollection. Specifically, we didn't think we were *defining* a threat = model as much as documenting a consensus model that already existed. = Incidentally, it's not clear to me what a "trust model" is. This is not = a term that appears in 3552 nor is it a real term of art that I am = familiar with.

Taking a step back, I remain unpersuaded that the 3552 threat = model is really out of data. The two main deficiencies I have heard = floated are:

1. = That it doesn't take into account traffic analysis and pervasive = monitoring.
2. That the assumption that endpoints = are uncompromised is unrealistic.

I can see some merit in the first = point, but this seems to really be more a matter of emphasis: 3552 = already specifies a Dolev-Yao style attacker, which means that it can = observe all communications. So really what has happened is that we have = a clearer picture of just how realistic that is and what you can do with = that kind of access. I can see some kind of update, but again it's less = about threat model than about modern examples.

As far as the second point goes, I = think that when you are thinking about comsec protocols it's still true = that you can't do much if you don't trust the endpoints. I think 3552 = could be a bit better about recognizing that there are malicious actors = in the system, though obviously that's implicit in the discussion of = DoS. Anyway, this doesn't seem like much of an update to the threat = model. 

What= does feel dated in 3552 (at least to me) is the emphasis on a bunch of = very old school protocols and the more or less total elision of the Web. = In particular, if we're talking in terms of threat model, the idea that = you have a lot of different untrusted programs running on your machine = (i.e., in the JS VM) and that you need to secure them from each other = really is new and could use some documenting. It's worth noting, = however, that (a) that's largely about implementation and (b) that that = system strives to achieve the kind of "each endpoint its own isolated = unit" ideal that 3552 asumes.

-Ekr


On Fri, Jan 24, 2020 at 11:47 AM Brian = E Carpenter <brian.e.carpenter@gmail.com> = wrote:
Hi,

I'm confused. What = we have in RFC3552 is very intentionally guidance for
RFC = writers on what they need to cover in their RFCs. Its specific = purpose
was to get rid of "Security considerations are not = discussed in this memo." 
Its purpose = was not primarily to define an abstraction like a "trust model"
or a "threat model" (the draft charter seems a bit vague = about which of those
it means).

I really do not want to see the pragmatic purpose of RFC3552 = lost in the
effort to define these abstractions. I don't = think that is the intention,
but the text seems to imply = that RFC3552 was mainly a description of a
generic threat = model, which it wasn't.

I am not against an = IAB effort to analyse how the threat and trust models
(plural) have evolved since the security workshop [RFC2316] = that ultimately
led to RFC3552. That seems like a good = idea. An update of "Guidelines for
Writing RFC Text on = Security Considerations" also seems like a good idea.
But = the draft charter text seems to conflate these two separate lines of
action.

Incidentally, while = writing the above it occurred to me why the phrase
"IAB = program" has always slightly disturbed me. Really the proposal is
a virtual IAB workshop (whereas RFC2316 came from three days = in a room
together in Murray Hill, NJ). A good idea, but = not a program.

Regards
  =  Brian

On 25-Jan-20 00:49, Jari Arkko = wrote:
> 
> The IAB = are considering starting up a programme on Internet
> = trust model evolution as described in the link at the bottom of this
> email.
> 
> We'd = like to get feedback on that idea and the text. As you may
> be aware, in 2019 a number of documents were published = on
> this topic and discussions held (on the mailing = list, SAAG, side
> meeting at IETF-106, workshops, = etc). There=E2=80=99s also a virtual
> meeting coming = up on February 14th.
> 
> To be = clear, any output from this program would be text offered 
> to the IETF for consideration - it is not within the = IAB's remit, nor 
> that of an IAB program, to = modify a BCP. Nonetheless, an IAB 
> program = offers a good venue for this work, as it perhaps allows 
> for more focus on the evolving architecture aspect = within this space.
> 
> The = plan is for the new program to be entirely open for participation,
> similar to how the current work has already been. That = is, the mailing
> list is open for all interested to = join, meetings are open and listed
> in the public = agendas. The IAB will find a chair or chairs for the
> = group to stay organised.
> 
> There's = no specific deadline for this, but the IAB will consider this
> further in the next few weeks, so if you could take = a few minutes 
> to share your thoughts on = this that'd be great.
> 
> https://github..com/intarchboard/model-t-charter/blob/master/mo= del-t-charter-00.md
> https://www.iab.org/mailman/listinfo/model-t
> 
> Stephen & Jari
> 
> 
> = _______________________________________________
> = Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss<= br class=3D"">> 

-- 
Model-t = mailing list
Model-t@iab.org
https://www.iab.org/mailman/listinfo/model-t
_______________________________________________
Architecture-discuss mailing = list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss<= /div>

= --Apple-Mail=_302D8F54-40AB-4EF2-9505-7537A093C282-- --Apple-Mail=_9FB7251E-477E-443A-AA64-AEBB2602FE0A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4rUsEACgkQh7ZrRtnS ejM1NggA2r3oAAi2x9j8jeKVFF7xKLSF/wdqSH18rYomJRtw7JRrRqFJRRvV6BQe /HMaCDUWcYwIkLhud4X9sQQYHdIerzns0T2qcOUA1e9VaNyJPsH2rK6Dv16IKRLe hr9KoAS3BPNq4klRnDdm7Vqq8feydzxa+I0jRRLzppMqKXbvTBNxk+RfKu4yEeaO OPYyeUnzZH6vzVn5jn/RB1RXQmSLtGlIps8CmlwiASo0Ns6IIjyNs8cePTO0RgO8 rfZ4fDO7EaErs0F2UKji+KpIiQwbsCKAU3EO15ewPUg1T5U1brNHTYRVaytu2o3d ATvNfEsYRxmkFm3zcoUabmRWA/9ItQ== =Qip7 -----END PGP SIGNATURE----- --Apple-Mail=_9FB7251E-477E-443A-AA64-AEBB2602FE0A-- From nobody Fri Jan 24 12:36:28 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842CB120090 for ; Fri, 24 Jan 2020 12:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U04EaFvC440M for ; Fri, 24 Jan 2020 12:36:21 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 02D83120858 for ; Fri, 24 Jan 2020 12:36:21 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id z9so2896351oth.5 for ; Fri, 24 Jan 2020 12:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=szcwpKI+94ZldwtQcSE9NSE712HPSzRQdXfA/6GL+kA=; b=R4CEpB5kV/N0WyzoaKz5Q8IdkHLoQkUsM9WhVfMwizI0PMYRYrQPKFIKVhK2GpBUQe qIsDCVpVCi3lBsTTXtIp8o1mBfmGXJ6gDEl3PXmXrrOSSYnvCvSJYgkTamhsNqMb/dWc 8wba/GKKIbeQkjMUEnzJiWX+XD3yTSGI2ETxfjgnBXTpiFO43GXDc6gl0ISDJKwXrxMV QHVK0i8PYHHN+vNSxA7K6Z3O5PnxbDCQpMw5a4cg2IoG1uuTAeN7fCwqZkc6/jdXbSdu U9YrAa3hxQIqpd/kvA7ub0y57Yq9p8LKCGfUHGo1XjNsN9neus3SZQunbK0d4PRNOz7K /fZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=szcwpKI+94ZldwtQcSE9NSE712HPSzRQdXfA/6GL+kA=; b=DlkNXaWOMy1CBSt8gU/5QbkzCrAai260MpII3sX6QgqVaQEi25AXuvydxJx/V8lKEt 9matZhzOf7n/WWK2dRlsP6Ctmvojlf8toa20Ip3fe2j2TEtdUVjB5G6zo94JLYjvRkID Uwq+8JvF7LOplGyccGyoYH4vI7x3TOQIi6K5iGfYS6H4vTA5geEFWEoI4y1pZqieryiU RpAY3Nl9LF1mQLVu4QPAqQJegHSMithyWUigdFKLT8mpXEtrqy8M4dYKa8nkRDIN1mT9 JMxh73IzTkO0zVIXL/aC9S87LIlD83aSdue7ywKGy9gypAXlNLrYROxGOkCFlU9o5BKh ICaQ== X-Gm-Message-State: APjAAAUuxC1NjQuVbCaW0kP7ND9IH1+3DyAmKWJe5Wh0anVZdq6rliNV qt9BHObKo5Q79rw6prAQ+sgZKsmjPOKx52F2SBw= X-Google-Smtp-Source: APXvYqzdFTtkp3j04Ycp5SbKGT4j0tUwbP4N/FYWieXOTb758Vd6CbkQog6UonvOpu9fYE4ZjSqqDcbhtCa6/ysfMdk= X-Received: by 2002:a9d:6f0a:: with SMTP id n10mr4229965otq.54.1579898180165; Fri, 24 Jan 2020 12:36:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Fri, 24 Jan 2020 12:35:54 -0800 Message-ID: To: Eric Rescorla Cc: Brian E Carpenter , Jari Arkko , architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="000000000000cf64ed059ce8b57b" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 20:36:24 -0000 --000000000000cf64ed059ce8b57b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2020 at 12:03 PM Eric Rescorla wrote: > Brian's comments match my recollection. Specifically, we didn't think we > were *defining* a threat model as much as documenting a consensus model > that already existed. Incidentally, it's not clear to me what a "trust > model" is. This is not a term that appears in 3552 nor is it a real term = of > art that I am familiar with. > > Taking a step back, I remain unpersuaded that the 3552 threat model is > really out of data. The two main deficiencies I have heard floated are: > > 1. That it doesn't take into account traffic analysis and pervasive > monitoring. > 2. That the assumption that endpoints are uncompromised is unrealistic. > > I can see some merit in the first point, but this seems to really be more > a matter of emphasis: 3552 already specifies a Dolev-Yao style attacker, > which means that it can observe all communications. > So really what has happened is that we have a clearer picture of just how > realistic that is and what you can do with that kind of access. I can see > some kind of update, but again it's less about threat model than about > modern examples. > One of the changes I'm interested in seeing is a shift away from seeing this in terms of a single communication channel, which I believe is inherent in this text: By contrast, we assume that the attacker has nearly complete control of the communications channel over which the end-systems communicate. This means that the attacker can read any PDU (Protocol Data Unit) on the network and undetectably remove, change, or inject forged packets onto the wire. This includes being able to generate packets that appear to be from a trusted machine. Thus, even if the end-system with which you wish to communicate is itself secure, the Internet environment provides no assurance that packets which claim to be from that system in fact are. One of the biggest shifts in the pervasive surveillance case is that the attacker is both likely to be present on any alternative communication channel and likely has sufficient context over time to cross-correlate communications. We're moving from an omnipotent attacker to one that is also both omnipresent and eternal. While that may have been obvious to those specifying RFC 3552, it is hard to read in the current document for those who were once more na=C3=AFve. That doesn't really mean RFC 3552 is wrong, just that explaining the implications in the current context may be useful. As far as the second point goes, I think that when you are thinking about > comsec protocols it's still true that you can't do much if you don't trus= t > the endpoints. I think 3552 could be a bit better about recognizing that > there are malicious actors in the system, though obviously that's implici= t > in the discussion of DoS. Anyway, this doesn't seem like much of an updat= e > to the threat model. > > Here, I think the point is really to move the IETF away from thinking in terms of host requirements. I agree with you that there are pieces to this that are very similar whether you think of JS code in a sandboxed tab or about an IoT device or about TOPS-20 device connected to an IMP. But if you assume that the PC running the browser hosting that tab is the unit of analysis, you might have a very bad time. Again, not really a change in the threat model, but a change in the context. This may be a way of saying that I agree with your point below. regards, Ted > What does feel dated in 3552 (at least to me) is the emphasis on a bunch > of very old school protocols and the more or less total elision of the We= b. > In particular, if we're talking in terms of threat model, the idea that y= ou > have a lot of different untrusted programs running on your machine (i.e., > in the JS VM) and that you need to secure them from each other really is > new and could use some documenting. It's worth noting, however, that (a) > that's largely about implementation and (b) that that system strives to > achieve the kind of "each endpoint its own isolated unit" ideal that 3552 > asumes. > > -Ekr > > > On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Hi, >> >> I'm confused. What we have in RFC3552 is very intentionally guidance for >> RFC writers on what they need to cover in their RFCs. Its specific purpo= se >> was to get rid of "Security considerations are not discussed in this >> memo." >> Its purpose was not primarily to define an abstraction like a "trust >> model" >> or a "threat model" (the draft charter seems a bit vague about which of >> those >> it means). >> >> I really do not want to see the pragmatic purpose of RFC3552 lost in the >> effort to define these abstractions. I don't think that is the intention= , >> but the text seems to imply that RFC3552 was mainly a description of a >> generic threat model, which it wasn't. >> >> I am not against an IAB effort to analyse how the threat and trust model= s >> (plural) have evolved since the security workshop [RFC2316] that >> ultimately >> led to RFC3552. That seems like a good idea. An update of "Guidelines fo= r >> Writing RFC Text on Security Considerations" also seems like a good idea= . >> But the draft charter text seems to conflate these two separate lines of >> action. >> >> Incidentally, while writing the above it occurred to me why the phrase >> "IAB program" has always slightly disturbed me. Really the proposal is >> a virtual IAB workshop (whereas RFC2316 came from three days in a room >> together in Murray Hill, NJ). A good idea, but not a program. >> >> Regards >> Brian >> >> On 25-Jan-20 00:49, Jari Arkko wrote: >> > >> > The IAB are considering starting up a programme on Internet >> > trust model evolution as described in the link at the bottom of this >> > email. >> > >> > We'd like to get feedback on that idea and the text. As you may >> > be aware, in 2019 a number of documents were published on >> > this topic and discussions held (on the mailing list, SAAG, side >> > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual >> > meeting coming up on February 14th. >> > >> > To be clear, any output from this program would be text offered >> > to the IETF for consideration - it is not within the IAB's remit, nor >> > that of an IAB program, to modify a BCP. Nonetheless, an IAB >> > program offers a good venue for this work, as it perhaps allows >> > for more focus on the evolving architecture aspect within this space. >> > >> > The plan is for the new program to be entirely open for participation, >> > similar to how the current work has already been. That is, the mailing >> > list is open for all interested to join, meetings are open and listed >> > in the public agendas. The IAB will find a chair or chairs for the >> > group to stay organised. >> > >> > There's no specific deadline for this, but the IAB will consider this >> > further in the next few weeks, so if you could take a few minutes >> > to share your thoughts on this that'd be great. >> > >> > >> https://github..com/intarchboard/model-t-charter/blob/master/model-t-cha= rter-00.md >> >> > https://www.iab.org/mailman/listinfo/model-t >> > >> > Stephen & Jari >> > >> > >> > _______________________________________________ >> > Architecture-discuss mailing list >> > Architecture-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/architecture-discuss >> > >> >> -- >> Model-t mailing list >> Model-t@iab.org >> https://www.iab.org/mailman/listinfo/model-t >> > -- > Model-t mailing list > Model-t@iab.org > https://www.iab.org/mailman/listinfo/model-t > --000000000000cf64ed059ce8b57b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 24, 2020 at 12:03 PM Eric Res= corla <ekr@rtfm.com> wrote:
Brian's comments match my recollection. Spe= cifically, we didn't think we were *defining* a threat model as much as= documenting a consensus model that already existed. Incidentally, it's= not clear to me what a "trust model" is. This is not a term that= appears in 3552 nor is it a real term of art that I am familiar with.

Taking a step back, I remain unpersuaded that the 3552= threat model is really out of data. The two main deficiencies I have heard= floated are:

1. That it doesn't take into acc= ount traffic analysis and pervasive monitoring.
2. That the assum= ption that endpoints are uncompromised is unrealistic.

=
I can see some merit in the first point, but this seems to really be m= ore a matter of emphasis: 3552 already specifies a Dolev-Yao style attacker= , which means that it can observe all communications.
=
So really what has happened is that we have a clearer picture of just = how realistic that is and what you can do with that kind of access. I can s= ee some kind of update, but again it's less about threat model than abo= ut modern examples.

One of the = changes I'm interested in seeing is a shift away from seeing this in te= rms of a single communication channel, which I believe is inherent in this = text:

   By contrast,=
 we assume that the attacker has nearly complete control
   of the communications channel over which the end-systems communicate.
   This means that the attacker can read any PDU (Protocol Data Unit) on
   the network and undetectably remove, change, or inject forged packets
   onto the wire.  This includes being able to generate packets that
   appear to be from a trusted machine.  Thus, even if the end-system
   with which you wish to communicate is itself secure, the Internet
   environment provides no assurance that packets which claim to be from
   that system in fact are.
=C2=A0
One of the big= gest shifts in the pervasive surveillance case is that the attacker is both= likely to be present on any alternative communication channel and likely h= as sufficient context over time to cross-correlate communications.=C2=A0 We= 're moving from an omnipotent attacker to one that is also both omnipre= sent and eternal.=C2=A0 While that may have been obvious to those specifyin= g RFC 3552, it is hard to read in the current document for those who were o= nce more na=C3=AFve. =C2=A0 That doesn't really mean RFC 3552 is wrong,= just that explaining the implications in the current context may be useful= .

As far as the second point goes, I think = that when you are thinking about comsec protocols it's still true that = you can't do much if you don't trust the endpoints. I think 3552 co= uld be a bit better about recognizing that there are malicious actors in th= e system, though obviously that's implicit in the discussion of DoS. An= yway, this doesn't seem like much of an update to the threat model.


Here, I think = the point is really to move the IETF away from thinking in terms of host re= quirements. I agree with you that there are pieces to this that are very si= milar whether you think of=C2=A0 JS code in a sandboxed tab or about an IoT= device or about TOPS-20 device connected to an IMP.=C2=A0 But if you assum= e that the PC running the browser hosting that tab is the unit of analysis,= you might have a very bad time.=C2=A0 Again, not really a change in the th= reat model, but a change in the context.=C2=A0 This may be a way of saying = that I agree with your point below.

regards,

Ted
=C2=A0
What does fee= l dated in 3552 (at least to me) is the emphasis on a bunch of very old sch= ool protocols and the more or less total elision of the Web. In particular,= if we're talking in terms of threat model, the idea that you have a lo= t of different untrusted programs running on your machine (i.e., in the JS = VM) and that you need to secure them from each other really is new and coul= d use some documenting. It's worth noting, however, that (a) that's= largely about implementation and (b) that that system strives to achieve t= he kind of "each endpoint its own isolated unit" ideal that 3552 = asumes.

-Ekr


On Fri, Jan 24, 202= 0 at 11:47 AM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi,

I'm confused. What we have in RFC3552 is very intentionally guidance fo= r
RFC writers on what they need to cover in their RFCs. Its specific purpose<= br> was to get rid of "Security considerations are not discussed in this m= emo."
Its purpose was not primarily to define an abstraction like a "trust m= odel"
or a "threat model" (the draft charter seems a bit vague about wh= ich of those
it means).

I really do not want to see the pragmatic purpose of RFC3552 lost in the effort to define these abstractions. I don't think that is the intentio= n,
but the text seems to imply that RFC3552 was mainly a description of a
generic threat model, which it wasn't.

I am not against an IAB effort to analyse how the threat and trust models (plural) have evolved since the security workshop [RFC2316] that ultimately=
led to RFC3552. That seems like a good idea. An update of "Guidelines = for
Writing RFC Text on Security Considerations" also seems like a good id= ea.
But the draft charter text seems to conflate these two separate lines of action.

Incidentally, while writing the above it occurred to me why the phrase
"IAB program" has always slightly disturbed me. Really the propos= al is
a virtual IAB workshop (whereas RFC2316 came from three days in a room
together in Murray Hill, NJ). A good idea, but not a program.

Regards
=C2=A0 =C2=A0Brian

On 25-Jan-20 00:49, Jari Arkko wrote:
>
> The IAB are considering starting up a programme on Internet
> trust model evolution as described in the link at the bottom of this > email.
>
> We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on
> this topic and discussions held (on the mailing list, SAAG, side
> meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th.
>
> To be clear, any output from this program would be text offered=C2=A0<= br> > to the IETF for consideration - it is not within the IAB's remit, = nor=C2=A0
> that of an IAB program, to modify a BCP. Nonetheless, an IAB=C2=A0
> program offers a good venue for this work, as it perhaps allows=C2=A0<= br> > for more focus on the evolving architecture aspect within this space.<= br> >
> The plan is for the new program to be entirely open for participation,=
> similar to how the current work has already been. That is, the mailing=
> list is open for all interested to join, meetings are open and listed<= br> > in the public agendas. The IAB will find a chair or chairs for the
> group to stay organised.
>
> There's no specific deadline for this, but the IAB will=C2=A0consi= der this
> further in the next few weeks, so if you could=C2=A0take a few minutes= =C2=A0
> to share your thoughts on this=C2=A0that'd be great.
>
> https://github= ..com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md > https://www.iab.org/mailman/listinfo/model-t >
> Stephen & Jari
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss
>

--
Model-t mailing list
Model-t@iab.org https://www.iab.org/mailman/listinfo/model-t
--
Model-t mailing list
Model-t@iab.org https://www.iab.org/mailman/listinfo/model-t
--000000000000cf64ed059ce8b57b-- From nobody Fri Jan 24 12:51:26 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F8F120858 for ; Fri, 24 Jan 2020 12:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDGcVMeRRCFb for ; Fri, 24 Jan 2020 12:51:18 -0800 (PST) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 ADCDA120090 for ; Fri, 24 Jan 2020 12:51:18 -0800 (PST) Received: by mail-vk1-xa2a.google.com with SMTP id o187so1024452vka.2 for ; Fri, 24 Jan 2020 12:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yrSrtigg4k7RLwed//yyNsKSqLbNzbDjSQNJA8wwlvY=; b=vPO1g3wi06cnn3cgxkYWmDuMAPp6hfHnu1+AYcsySq8jnLDtTzzBAmci1I44yv3U3e tmb4GTHhYARHnCQ7Nmho7bzV3N4yOwn+6Ugv54bIdLDyAKk63jE7p1kH9linfPNE09Nz fzS4kkvmJNEXoDh7Tk38CHbYRKN/R6Hl1vlFHA2Zz4b+kIEcK5+mSPkqCkXGa2bz/0Ft POEHA/knwRrlWPYkvEytmsBTnB6gQ2yku5Lhq26mtjceSGA623s73EzenrtmfBQNjfdH pg2b0QQHVFxuJGPfOIiD0C8OYIR30m4LgnLh2CMfAfC3Uecx01J578M3KSCvVxxsumFx GOsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yrSrtigg4k7RLwed//yyNsKSqLbNzbDjSQNJA8wwlvY=; b=mb/755eEyHLdp0xoWDpe8MeklpTlpreR5NKDi+gmDUgTeLhEA5ctW1h7TwOFpnbVO5 BpxKmu8tIqfQkgtSPwyF5sjf+Tdj7Y7pRBk6PfXcdOyJDZlTVZEf9aaIDqDo03pUst1G ZYW1pImZSUlVD8zv4lvdzPwE3CoDMv0MymY7t2BBxhP3BC8cZypnI7PFsZZdseoxt8+a 2w4JarAsqDo+vA1aLVHHLOTTSK/5GxpzwL0nKwKqyiiPLbFSRY55J29h2xlQK9MqBArL qTRCY3m3DXfLgd/8+/KCgRe3Kuo6jH7t1RAwlCJUU2Kezq9toOGWpJcTMeOgmCPFyNW2 Y6jA== X-Gm-Message-State: APjAAAXhazB0cFNdT7RxdnQ82HhmBABPcas3QImePy5/r9Urgt+S/Chz txCWG+spvHUdFKl0VjKYzuP2euSH+nJZIdtiyf8= X-Google-Smtp-Source: APXvYqySmj6ZH8OHaVEYLTAJTPx1bRpkQl75PUDevmSrdBdah5aEHJ0Uuk87ql29NJOqlUPK+9dTzam77sClaUzthjU= X-Received: by 2002:a1f:bd87:: with SMTP id n129mr3339771vkf.23.1579899077298; Fri, 24 Jan 2020 12:51:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Fri, 24 Jan 2020 12:51:06 -0800 Message-ID: To: Eric Rescorla Cc: Brian E Carpenter , architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="000000000000488df8059ce8eb55" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 20:51:22 -0000 --000000000000488df8059ce8eb55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable EKR said: "What does feel dated in 3552 (at least to me) is the emphasis on a bunch of very old school protocols and the more or less total elision of the Web. In particular, if we're talking in terms of threat model, the idea that you have a lot of different untrusted programs running on your machine (i.e., in the JS VM) and that you need to secure them from each other really is new and could use some documenting. It's worth noting, however, that (a) that's largely about implementation and (b) that that system strives to achieve the kind of "each endpoint its own isolated unit" ideal that 3552 asumes." [BA] I agree that RFC 3552 does feel dated with respect to today's Web. In a number of cases, it has become clear that the term "endpoint" is too general, and that we may need to define much more precisely what endpoint elements (e.g. JS applications, native browser code, trusted hardware modules, etc.) are trusted with what data. On Fri, Jan 24, 2020 at 12:04 PM Eric Rescorla wrote: > Brian's comments match my recollection. Specifically, we didn't think we > were *defining* a threat model as much as documenting a consensus model > that already existed. Incidentally, it's not clear to me what a "trust > model" is. This is not a term that appears in 3552 nor is it a real term = of > art that I am familiar with. > > Taking a step back, I remain unpersuaded that the 3552 threat model is > really out of data. The two main deficiencies I have heard floated are: > > 1. That it doesn't take into account traffic analysis and pervasive > monitoring. > 2. That the assumption that endpoints are uncompromised is unrealistic. > > I can see some merit in the first point, but this seems to really be more > a matter of emphasis: 3552 already specifies a Dolev-Yao style attacker, > which means that it can observe all communications. So really what has > happened is that we have a clearer picture of just how realistic that is > and what you can do with that kind of access. I can see some kind of > update, but again it's less about threat model than about modern examples= . > > As far as the second point goes, I think that when you are thinking about > comsec protocols it's still true that you can't do much if you don't trus= t > the endpoints. I think 3552 could be a bit better about recognizing that > there are malicious actors in the system, though obviously that's implici= t > in the discussion of DoS. Anyway, this doesn't seem like much of an updat= e > to the threat model. > > What does feel dated in 3552 (at least to me) is the emphasis on a bunch > of very old school protocols and the more or less total elision of the We= b. > In particular, if we're talking in terms of threat model, the idea that y= ou > have a lot of different untrusted programs running on your machine (i.e., > in the JS VM) and that you need to secure them from each other really is > new and could use some documenting. It's worth noting, however, that (a) > that's largely about implementation and (b) that that system strives to > achieve the kind of "each endpoint its own isolated unit" ideal that 3552 > asumes. > > -Ekr > > > On Fri, Jan 24, 2020 at 11:47 AM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Hi, >> >> I'm confused. What we have in RFC3552 is very intentionally guidance for >> RFC writers on what they need to cover in their RFCs. Its specific purpo= se >> was to get rid of "Security considerations are not discussed in this >> memo." >> Its purpose was not primarily to define an abstraction like a "trust >> model" >> or a "threat model" (the draft charter seems a bit vague about which of >> those >> it means). >> >> I really do not want to see the pragmatic purpose of RFC3552 lost in the >> effort to define these abstractions. I don't think that is the intention= , >> but the text seems to imply that RFC3552 was mainly a description of a >> generic threat model, which it wasn't. >> >> I am not against an IAB effort to analyse how the threat and trust model= s >> (plural) have evolved since the security workshop [RFC2316] that >> ultimately >> led to RFC3552. That seems like a good idea. An update of "Guidelines fo= r >> Writing RFC Text on Security Considerations" also seems like a good idea= . >> But the draft charter text seems to conflate these two separate lines of >> action. >> >> Incidentally, while writing the above it occurred to me why the phrase >> "IAB program" has always slightly disturbed me. Really the proposal is >> a virtual IAB workshop (whereas RFC2316 came from three days in a room >> together in Murray Hill, NJ). A good idea, but not a program. >> >> Regards >> Brian >> >> On 25-Jan-20 00:49, Jari Arkko wrote: >> > >> > The IAB are considering starting up a programme on Internet >> > trust model evolution as described in the link at the bottom of this >> > email. >> > >> > We'd like to get feedback on that idea and the text. As you may >> > be aware, in 2019 a number of documents were published on >> > this topic and discussions held (on the mailing list, SAAG, side >> > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual >> > meeting coming up on February 14th. >> > >> > To be clear, any output from this program would be text offered >> > to the IETF for consideration - it is not within the IAB's remit, nor >> > that of an IAB program, to modify a BCP. Nonetheless, an IAB >> > program offers a good venue for this work, as it perhaps allows >> > for more focus on the evolving architecture aspect within this space. >> > >> > The plan is for the new program to be entirely open for participation, >> > similar to how the current work has already been. That is, the mailing >> > list is open for all interested to join, meetings are open and listed >> > in the public agendas. The IAB will find a chair or chairs for the >> > group to stay organised. >> > >> > There's no specific deadline for this, but the IAB will consider this >> > further in the next few weeks, so if you could take a few minutes >> > to share your thoughts on this that'd be great. >> > >> > >> https://github..com/intarchboard/model-t-charter/blob/master/model-t-cha= rter-00.md >> >> > https://www.iab.org/mailman/listinfo/model-t >> > >> > Stephen & Jari >> > >> > >> > _______________________________________________ >> > Architecture-discuss mailing list >> > Architecture-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/architecture-discuss >> > >> >> -- >> Model-t mailing list >> Model-t@iab.org >> https://www.iab.org/mailman/listinfo/model-t >> > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000488df8059ce8eb55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
EKR said:=C2=A0

"= What does feel dated in 3552 (at least to me) is the emphasis on a bunch of= very old school protocols and the more or less total elision of the Web. I= n particular, if we're talking in terms of threat model, the idea that = you have a lot of different untrusted programs running on your machine (i.e= ., in the JS VM) and that you need to secure them from each other really is= new and could use some documenting. It's worth noting, however, that (= a) that's largely about implementation and (b) that that system strives= to achieve the kind of "each endpoint its own isolated unit" ide= al that 3552 asumes."

[BA] I agree that RFC 3= 552 does feel dated with respect to today's Web.=C2=A0 In a number of c= ases, it has become clear that the term "endpoint" is too general= , and that we may need to define much more precisely what endpoint elements= (e.g. JS applications, native browser code, trusted hardware modules, etc.= ) are trusted with what data.

On Fri, Jan 24, 2020 at 12:04 PM E= ric Rescorla <ekr@rtfm.com> wrote= :
Brian's comments match my recollection. Specifically, we didn&#= 39;t think we were *defining* a threat model as much as documenting a conse= nsus model that already existed. Incidentally, it's not clear to me wha= t a "trust model" is. This is not a term that appears in 3552 nor= is it a real term of art that I am familiar with.

Taking a step back, I remain unpersuaded that the 3552 threat model is rea= lly out of data. The two main deficiencies I have heard floated are:
<= div>
1. That it doesn't take into account traffic analysi= s and pervasive monitoring.
2. That the assumption that endpoints= are uncompromised is unrealistic.

I can see some = merit in the first point, but this seems to really be more a matter of emph= asis: 3552 already specifies a Dolev-Yao style attacker, which means that i= t can observe all communications. So really what has happened is that we ha= ve a clearer picture of just how realistic that is and what you can do with= that kind of access. I can see some kind of update, but again it's les= s about threat model than about modern examples.

A= s far as the second point goes, I think that when you are thinking about co= msec protocols it's still true that you can't do much if you don= 9;t trust the endpoints. I think 3552 could be a bit better about recognizi= ng that there are malicious actors in the system, though obviously that'= ;s implicit in the discussion of DoS. Anyway, this doesn't seem like mu= ch of an update to the threat model.

What doe= s feel dated in 3552 (at least to me) is the emphasis on a bunch of very ol= d school protocols and the more or less total elision of the Web. In partic= ular, if we're talking in terms of threat model, the idea that you have= a lot of different untrusted programs running on your machine (i.e., in th= e JS VM) and that you need to secure them from each other really is new and= could use some documenting. It's worth noting, however, that (a) that&= #39;s largely about implementation and (b) that that system strives to achi= eve the kind of "each endpoint its own isolated unit" ideal that = 3552 asumes.

-Ekr


On Fri, Jan 24= , 2020 at 11:47 AM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi,

I'm confused. What we have in RFC3552 is very intentionally guidance fo= r
RFC writers on what they need to cover in their RFCs. Its specific purpose<= br> was to get rid of "Security considerations are not discussed in this m= emo."
Its purpose was not primarily to define an abstraction like a "trust m= odel"
or a "threat model" (the draft charter seems a bit vague about wh= ich of those
it means).

I really do not want to see the pragmatic purpose of RFC3552 lost in the effort to define these abstractions. I don't think that is the intentio= n,
but the text seems to imply that RFC3552 was mainly a description of a
generic threat model, which it wasn't.

I am not against an IAB effort to analyse how the threat and trust models (plural) have evolved since the security workshop [RFC2316] that ultimately=
led to RFC3552. That seems like a good idea. An update of "Guidelines = for
Writing RFC Text on Security Considerations" also seems like a good id= ea.
But the draft charter text seems to conflate these two separate lines of action.

Incidentally, while writing the above it occurred to me why the phrase
"IAB program" has always slightly disturbed me. Really the propos= al is
a virtual IAB workshop (whereas RFC2316 came from three days in a room
together in Murray Hill, NJ). A good idea, but not a program.

Regards
=C2=A0 =C2=A0Brian

On 25-Jan-20 00:49, Jari Arkko wrote:
>
> The IAB are considering starting up a programme on Internet
> trust model evolution as described in the link at the bottom of this > email.
>
> We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on
> this topic and discussions held (on the mailing list, SAAG, side
> meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th.
>
> To be clear, any output from this program would be text offered=C2=A0<= br> > to the IETF for consideration - it is not within the IAB's remit, = nor=C2=A0
> that of an IAB program, to modify a BCP. Nonetheless, an IAB=C2=A0
> program offers a good venue for this work, as it perhaps allows=C2=A0<= br> > for more focus on the evolving architecture aspect within this space.<= br> >
> The plan is for the new program to be entirely open for participation,=
> similar to how the current work has already been. That is, the mailing=
> list is open for all interested to join, meetings are open and listed<= br> > in the public agendas. The IAB will find a chair or chairs for the
> group to stay organised.
>
> There's no specific deadline for this, but the IAB will=C2=A0consi= der this
> further in the next few weeks, so if you could=C2=A0take a few minutes= =C2=A0
> to share your thoughts on this=C2=A0that'd be great.
>
> https://github= ..com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md > https://www.iab.org/mailman/listinfo/model-t >
> Stephen & Jari
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss
>

--
Model-t mailing list
Model-t@iab.org https://www.iab.org/mailman/listinfo/model-t
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000488df8059ce8eb55-- From nobody Fri Jan 24 13:50:50 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784A91209F4 for ; Fri, 24 Jan 2020 13:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8qiiotwQNIw for ; Fri, 24 Jan 2020 13:50:46 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 44DF8120052 for ; Fri, 24 Jan 2020 13:50:46 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.146.21]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00OLoSRb012568 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jan 2020 13:50:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579902640; x=1579989040; i=@elandsys.com; bh=DhGKZtqi50C9nRfgT6l2jPVydTqTFqtpZDqTuLWca08=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=H3RfR8TZt8NVM/vNtaRJlalIpzXZl6XdNL244SWAvC3NRuG01gltzfOSCOWcT3zot gfqrwat/RN1iSByYAjJP7RW4ZTMyob9xp6dlHssBEsh7NT8xVuVMTZFzO6F410UHcM 07x6P7YbEPt6D8MFd6FACjqnb6SW6pkLhraeSng0= Message-Id: <6.2.5.6.2.20200124131650.14570c78@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 24 Jan 2020 13:50:15 -0800 To: Jari Arkko , model-t@iab.org From: S Moonesamy Cc: Stephen Farrell In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 21:50:47 -0000 Hi Jari, At 03:49 AM 24-01-2020, Jari Arkko wrote: >There's no specific deadline for this, but the IAB will consider this >further in the next few weeks, so if you could take a few minutes >to share your thoughts on this that'd be great. The technical summary of RFC 3552 is as follows: "What does this protocol do and why does the community need it?" The Abstract states that the document provides guidelines to RFC authors on how to write a good security consideration section. In the draft charter, that document is interpreted as the Internet threat model for protocol design whereas the title in the draft charter is about the Internet threat model. Is the proposed IAB program about (re)defining the Internet threat model [1]? The draft charter mentions "information centralisation". There isn't any direct link between that topic and what is in RFC 3552. If the Internet is considered in terms of end-points, that topic would not fit in. This topic also does not fit in if the discussion is intended to be about IETF protocols. My preference would be to have the initial discussion of an RFC 3552 update within the IETF instead of this venue. This would avoid the awkwardness of having to offer text to the IETF. Regards, S. Moonesamy 1. The threat model for a few IETF protocols go beyond what is in Section 3 of RFC 3552. From nobody Fri Jan 24 17:56:18 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80C812082D for ; Fri, 24 Jan 2020 17:56:11 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvOh0kFj6fom for ; Fri, 24 Jan 2020 17:56:09 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 BF450120B39 for ; Fri, 24 Jan 2020 17:56:09 -0800 (PST) Received: from xse118.mail2web.com ([66.113.196.118] helo=xse.mail2web.com) by mx105.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1ivAgA-0007iA-8q for model-t@iab.org; Sat, 25 Jan 2020 02:56:07 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 484JyB4qdWzp8Q for ; Fri, 24 Jan 2020 17:56:02 -0800 (PST) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1ivAg6-0001Oy-I9 for model-t@iab.org; Fri, 24 Jan 2020 17:56:02 -0800 Received: (qmail 14932 invoked from network); 25 Jan 2020 01:56:02 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.58.46.251]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Jan 2020 01:56:01 -0000 To: Ted Hardie , Eric Rescorla Cc: model-t@iab.org, Jari Arkko , Brian E Carpenter , architecture-discuss@ietf.org References: From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> Date: Fri, 24 Jan 2020 17:56:02 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2F492A55B3B95B4109930A8F" Content-Language: en-US X-Originating-IP: 66.113.196.118 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.118/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.118/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Xm17NJf4el5vffImWwWrhCpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDXz6Yli32IJdAuJ3ivsC2SsRX qYbtEQV1z/L435ZRxFTxiUqMifo0zC43a0dWqwF0+rYZvu7UEJiU3s27VgKHO7lwS3dBJTnTxDoD vBGGxph9w6EwXICYy0ePXtGEMhqrwBb733ZN4jAbrTI5wHo5JWU6UgOqKJ9sMwhVoOBGSAIboXtx P9OF0EfNs5TqNq2Yhy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8afR67T7N272aMX0YT5C7M3LjaRl54bVHhcrn+4P4o71nAAWOaz793tHcq/taxNDIJX dU571qBU/d2sq9m7FB7Hi+1NfYHqPsPJFYdy6TE9/mkvZ+pWP1s35neRYWMQUWZErSs0X3oyoTc8 j/o7qulxPKLS7175HyAMV35+tExNnGre/hsBBxzR0ZxLcHZ9dOib4S6KBsMMYBTUOK2r9R/O8i35 x+eYNOZ0ZpShFWKZEgEH5tktsnhMr4gG+2qXrJ2xnHvb770xV80F4GW31KBP9R/2gMGq0KWAzmMf +ibVDpdplkxcBm4XM6d7s4Bx3w1WbaUe4g0kgaInvdEp64qlVpe//bVkg87Xe61e30HXuSERbInM iTBIUBbQ/Dy6Ip4D1rnEhdYtY/lMQX5s39oH5ijcGdSK77ViXbmzTYWgl82XucjoLWQ7++7jcUS/ T5w= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 01:56:16 -0000 This is a multi-part message in MIME format. --------------2F492A55B3B95B4109930A8F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/24/2020 12:35 PM, Ted Hardie wrote: > As far as the second point goes, I think that when you are > thinking about comsec protocols it's still true that you can't do > much if you don't trust the endpoints. I think 3552 could be a bit > better about recognizing that there are malicious actors in the > system, though obviously that's implicit in the discussion of DoS. > Anyway, this doesn't seem like much of an update to the threat mode= l. > > > Here, I think the point is really to move the IETF away from thinking > in terms of host requirements. I agree with you that there are pieces > to this that are very similar whether you think of=C2=A0 JS code in a > sandboxed tab or about an IoT device or about TOPS-20 device connected > to an IMP.=C2=A0 But if you assume that the PC running the browser host= ing > that tab is the unit of analysis, you might have a very bad time.=C2=A0= > Again, not really a change in the threat model, but a change in the > context.=C2=A0 This may be a way of saying that I agree with your point= below. Phrasing that as "don't trust the endpoints" is probably inappropriate. My personal worry is the cascading impact of end-point compromise. Take the example of a large network. Large network means multiple routers. If the multiple is high enough, we have strong risks that one of those will be compromised at some point. If we merely "trust the endpoints", then a single compromise of one of the endpoints means the game is over. But it does not have to be so. In an ideal world, implementations of the routing protocol should be able to detect aberrant behavior and isolate the compromised node. In practice, that's really hard. But there are still general principles like "least amount of privilege" or "need to know basis" that could help. I would really like that protocol designers think about that too, instead of merely asserting trust in the endpoints.= And I would really like to get rid of the assumption about isolated networks being secure... -- Christian Huitema --------------2F492A55B3B95B4109930A8F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 1/24/2020 12:35 PM, Ted Hardie wrote:

As far as the second point goes, I think that when you are thinking about comsec protocols it's still true that you can't do much if you don't trust the endpoints. I think 3552 could be a bit better about recognizing that there are malicious actors in the system, though obviously that's implicit in the discussion of DoS. Anyway, this doesn't seem like much of an update to the threat model.


Here, I think the point is really to move the IETF away from thinking in terms of host requirements. I agree with you that there are pieces to this that are very similar whether you think of  JS code in a sandboxed tab or about an IoT device or about TOPS-20 device connected to an IMP.  But if you assume that the PC running the browser hosting that tab is the unit of analysis, you might have a very bad time.  Again, not really a change in the threat model, but a change in the context.  This may be a way of saying that I agree with your point below.


Phrasing that as "don't trust the endpoints" is probably inappropriate. My personal worry is the cascading impact of end-point compromise. Take the example of a large network. Large network means multiple routers. If the multiple is high enough, we have strong risks that one of those will be compromised at some point. If we merely "trust the endpoints", then a single compromise of one of the endpoints means the game is over. But it does not have to be so. In an ideal world, implementations of the routing protocol should be able to detect aberrant behavior and isolate the compromised node. In practice, that's really hard. But there are still general principles like "least amount of privilege" or "need to know basis" that could help. I would really like that protocol designers think about that too, instead of merely asserting trust in the endpoints.

And I would really like to get rid of the assumption about isolated networks being secure...

-- Christian Huitema

--------------2F492A55B3B95B4109930A8F-- From nobody Sat Jan 25 09:58:17 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00B2120048 for ; Sat, 25 Jan 2020 09:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX8x-rGWilZ5 for ; Sat, 25 Jan 2020 09:58:10 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E30120059 for ; Sat, 25 Jan 2020 09:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5232; q=dns/txt; s=iport; t=1579975089; x=1581184689; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=MHVGZLB2YwMloGKtvfsM2b0yls7IiDU5qHSXBdcigm0=; b=YWDUeVzbpPys8BXKky2ityE/3H9sgy0DinSumMyQYrkFDHojhCqn2fjW pHfyVYb5LeyjlwYf8VHatN73UAm45j5iySbPeKXx0jFs3s3nDtRa5vY5O cKAaCDqdJykFx7LlSVO265MCdxkj1kViGE4zbnu0cK1t8HklcObsQ3ZIF 8=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAwD9gCxe/xbLJq1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBfYEYVSASKo0XiBIlky2ICwIHAQEBCQMBAS8BAYRAAoJGOBM?= =?us-ascii?q?CAw0BAQQBAQECAQUEbYVDhV4BAQEBAgF5BQsLBBQuVwYTgyYBglsgqiaCJ4V?= =?us-ascii?q?KhGMQgTiBU4h4gW2CAIE4DBSCHi4+iAuCLASNchmJKYhwjzSCQ4JMgRySTxu?= =?us-ascii?q?OcIwMpj+DLgIEBgUCFYFpIoFYMxoIGxVlAYJBPhIYDZQkbwEOjRFAAzCOKgE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.70,362,1574121600"; d="asc'?scan'208,217";a="22509684" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jan 2020 17:58:05 +0000 Received: from [10.61.171.81] ([10.61.171.81]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 00PHw4mK021104 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 25 Jan 2020 17:58:05 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2E0DD6A3-D239-4CDD-AA6B-D714DD4F25C5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Sat, 25 Jan 2020 18:58:04 +0100 In-Reply-To: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> Cc: Ted Hardie , Eric Rescorla , architecture-discuss@ietf.org, model-t@iab.org To: Christian Huitema References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.171.81, [10.61.171.81] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 17:58:12 -0000 --Apple-Mail=_2E0DD6A3-D239-4CDD-AA6B-D714DD4F25C5 Content-Type: multipart/alternative; boundary="Apple-Mail=_46788426-AAE0-4B30-8333-71B80983E56E" --Apple-Mail=_46788426-AAE0-4B30-8333-71B80983E56E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 25 Jan 2020, at 02:56, Christian Huitema = wrote: >=20 >=20 > Phrasing that as "don't trust the endpoints" is probably = inappropriate. >=20 Why? They are the source of just about all compromise attacks. > My personal worry is the cascading impact of end-point compromise. = Take the example of a large network. Large network means multiple = routers. If the multiple is high enough, we have strong risks that one = of those will be compromised at some point. If we merely "trust the = endpoints", then a single compromise of one of the endpoints means the = game is over. But it does not have to be so. In an ideal world, = implementations of the routing protocol should be able to detect = aberrant behavior and isolate the compromised node. In practice, that's = really hard. >=20 We sell product that does this today. But it is hard, which is why = people pay us. Of course, it gets harder with encryption, but we even = have product for that. I prefer the other approach: tell us what good = behavior looks like (manufacturer usage descriptions). > But there are still general principles like "least amount of = privilege" or "need to know basis" that could help. >=20 Indeed. > I would really like that protocol designers think about that too, = instead of merely asserting trust in the endpoints. >=20 How much is this the protocol and how much is the application? The = protocols most apps are using today are, ermmm, HTTP. Eliot --Apple-Mail=_46788426-AAE0-4B30-8333-71B80983E56E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

On 25 Jan 2020, at 02:56, Christian Huitema <huitema@huitema.net> wrote:


Phrasing that as "don't trust the endpoints" is probably inappropriate.


Why?  They are the source of just about all compromise attacks.

My personal worry is the cascading impact of end-point compromise. Take the example of a large network. Large network means multiple routers. If the multiple is high enough, we have strong risks that one of those will be compromised at some point. If we merely "trust the endpoints", then a single compromise of one of the endpoints means the game is over. But it does not have to be so. In an ideal world, implementations of the routing protocol should be able to detect aberrant behavior and isolate the compromised node. In practice, that's really hard.

We sell product that does this today.  But it is hard, which is why people pay us.  Of course, it gets harder with encryption, but we even have product for that.  I prefer the other approach: tell us what good behavior looks like (manufacturer usage descriptions).

But there are still general principles like "least amount of privilege" or "need to know basis" that could help.

Indeed.

I would really like that protocol designers think about that too, instead of merely asserting trust in the endpoints.


How much is this the protocol and how much is the application?  The protocols most apps are using today are, ermmm, HTTP.

Eliot
--Apple-Mail=_46788426-AAE0-4B30-8333-71B80983E56E-- --Apple-Mail=_2E0DD6A3-D239-4CDD-AA6B-D714DD4F25C5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4sgawACgkQh7ZrRtnS ejPhhwf+ORR05p1brRtkXimar2aDLnR5BsZUpKU6ISnpcMNgw2SarsF2YlXPXqIa hBJ2iPczL5Xmo6bTxbAKjVhTWJyOjJvXRZAuvv6rzv5YG8SVCJQthk4rTy1mmhbi /x3GzpsqFzijfZMm9l/00t5leCHOO7jHiTWB4FwTZh9/B4DzeDnJloafiAqdaIpR IL7N38wwB63BsAmxYfNs31F1Zpg73EuF5KeQdh90CUfIGpn0nxaCBVwh78TOo0P/ mih0ONd1v/8UWne3gjxVUDYHVf8REuWuspMRlxML+kkoA5Lddc5lP3ZXZ/ZHyMbp pzliqFNz7RpzLJ1E5TyftcMFWXkcKw== =EjvB -----END PGP SIGNATURE----- --Apple-Mail=_2E0DD6A3-D239-4CDD-AA6B-D714DD4F25C5-- From nobody Sat Jan 25 23:37:24 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424FB12008D for ; Sat, 25 Jan 2020 23:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQbuawLeqDbU for ; Sat, 25 Jan 2020 23:37:18 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 3C7C912001B for ; Sat, 25 Jan 2020 23:37:18 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id h23so7318982ljc.8 for ; Sat, 25 Jan 2020 23:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nJ+2sH6Ku6+ZEBXMaY+ZBK+Rg8pgD0aCC6wgz27G68Y=; b=pLQcheJrxL0KKpTqZGvkhurXmEqUM0RsCe4AsoAmyNgJG/vydkCuztvuiRgG/6Hemt 600fKQs8IeggEQFU3loUw2dE3uZ1Sq9bJHrpiGiKsk7hueKfmxB39ZvsxObssxAjuxej lSjnKBs2C6eJUUbTdDnmdRchQQayadCHsD+STlhoUQ+3NP0Wh1W4vxn9QLzTXLEmIcLl m0EGe2cEOg7ZTq6lEDafqLtnvS3d8ryvYjUcDxB/ehv95ip2Zf22FePwe+KZ1M8c6J5h ohFebSx3Ah0FtHjaisn/iH0UNU/DkQYqWfGXsYwPvGmp0UoVhOwguMzkEXj8yo0POvYF UNsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nJ+2sH6Ku6+ZEBXMaY+ZBK+Rg8pgD0aCC6wgz27G68Y=; b=Izks1aoQFQdZj9uKRsFRIfLUBI59yTX+WKWNofTs91Cm8f2nqLqyTSHljx9u7INxXm BAp1SbMXE02nqBMAN/XhmH58BQhkgnkIuZpHBfnOdT/PIT0gX4oVptjUy3WS03+SF29D O7RzXWEveZyw8QBj1q/b5aUO1THWYGObOs/dpe5zyJjjPp9Zw5jl22b9qO7sKOrddDzt z38bjwncIVBwzAkbpb7yhVx88ncMio9kPy+ANLsEWdh5YmMC/60xzD5J5al7CjR86tKn z79oO+/4sHqh1rlEEE4SHB3O6/NX0a3BWF3Y39cOr5PUR1IAjxbIa5Ju4YtR7YSSzOcf dOmQ== X-Gm-Message-State: APjAAAXVJZYh9YHoGPUC8CbDCRku/lUcQT9oQZy4COKy9YB9xH6ekvzU p9JlqjRuHsBsTX2u26vB7yIzShBkeswCeqlN5hW03g== X-Google-Smtp-Source: APXvYqwETYtdkryvbWSHtFG+kmJSqEe7bYcaLM89AzWDkIC7/YJiyMNrJ/Td+7qzEjJMP5lWogNXXP2s5NH5mm83uN4= X-Received: by 2002:a05:651c:448:: with SMTP id g8mr6949631ljg.35.1580024236474; Sat, 25 Jan 2020 23:37:16 -0800 (PST) MIME-Version: 1.0 References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> In-Reply-To: From: Eric Rescorla Date: Sat, 25 Jan 2020 23:36:39 -0800 Message-ID: To: Eliot Lear Cc: Christian Huitema , Ted Hardie , architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="0000000000005a13c0059d060f22" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 07:37:21 -0000 --0000000000005a13c0059d060f22 Content-Type: text/plain; charset="UTF-8" It's probably useful to put the text in 3552 in context, which was primarily about designing COMSEC protocols. Our ability to build two party protocols which survive one of the parties being compromised is fairly limited. We *do* have some praxis for building N party protocols which gracefully degrade when some of the nodes are compromised (for instance consensus protocols). Of course, the exact properties of those protocols can be difficult to succinctly state. I'm not quite sure I understand what you mean when you say "They are the source of just about all compromise attacks." I'm not saying it's not true, but perhaps you could elaborate. -Ekr On Sat, Jan 25, 2020 at 9:58 AM Eliot Lear wrote: > > > On 25 Jan 2020, at 02:56, Christian Huitema wrote: > > > Phrasing that as "don't trust the endpoints" is probably inappropriate. > > > Why? They are the source of just about all compromise attacks. > > My personal worry is the cascading impact of end-point compromise. Take > the example of a large network. Large network means multiple routers. If > the multiple is high enough, we have strong risks that one of those will be > compromised at some point. If we merely "trust the endpoints", then a > single compromise of one of the endpoints means the game is over. But it > does not have to be so. In an ideal world, implementations of the routing > protocol should be able to detect aberrant behavior and isolate the > compromised node. In practice, that's really hard. > > We sell product that does this today. But it is hard, which is why people > pay us. Of course, it gets harder with encryption, but we even have > product for that. I prefer the other approach: tell us what good behavior > looks like (manufacturer usage descriptions). > > But there are still general principles like "least amount of privilege" or > "need to know basis" that could help. > > Indeed. > > I would really like that protocol designers think about that too, instead > of merely asserting trust in the endpoints. > > > How much is this the protocol and how much is the application? The > protocols most apps are using today are, ermmm, HTTP. > > Eliot > --0000000000005a13c0059d060f22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's probably useful to put the text in 3552 in c= ontext, which was primarily about designing COMSEC protocols. Our ability t= o build two party protocols which survive one of the parties being compromi= sed is fairly limited. We *do* have some praxis for building N party protoc= ols which gracefully degrade when some of the nodes are compromised (for in= stance consensus protocols). Of course, the exact properties of those proto= cols can be difficult to succinctly state.

I'm= not quite sure I understand what you mean when you say "They are the = source of just about all compromise attacks." I'm not saying it= 9;s not true, but perhaps you could elaborate.

-Ek= r


On Sat, Jan 25, 2020 at 9:58 AM Eliot Lear <lear@cisco.com> wrote:


On 25 Jan 2020, at 02:= 56, Christian Huitema <huitema@huitema.net> wrote:


Phrasing that as "don't trust the endpoints" is pr= obably inappropriate.


Why?=C2=A0 = They are the source of just about all compromise attacks.

My personal worry is the cascading impact = of end-point compromise. Take the example of a large network. Large network means multiple routers. If the multiple is high enough, we have strong risks that one of those will be compromised at some point. If we merely "trust the endpoints", then a single compromise of one of the endpoints means the game is over. But it does not have to be so. In an ideal world, implementations of the routing protocol should be able to detect aberrant behavior and isolate the compromised node. In practice, that's really hard.

We sell product that does this today.=C2=A0 = But it is hard, which is why people pay us.=C2=A0 Of course, it gets harder= with encryption, but we even have product for that.=C2=A0 I prefer the oth= er approach: tell us what good behavior looks like (manufacturer usage desc= riptions).

But there are still general principles like "least amount of privilege" or "need to know basis" that could help.

Indeed.
=

I would really like that protocol designers think about that too, instead of merely asserting trust in the endpoints.

=

How much is this the protocol and how much is the appli= cation?=C2=A0 The protocols most apps are using today are, ermmm, HTTP.

Eliot
--0000000000005a13c0059d060f22-- From nobody Sun Jan 26 01:44:17 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7878120018 for ; Sun, 26 Jan 2020 01:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.502 X-Spam-Level: X-Spam-Status: No, score=-12.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_SCAM=1.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-tqFhR633re for ; Sun, 26 Jan 2020 01:44:09 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD4B12001A for ; Sun, 26 Jan 2020 01:44:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12445; q=dns/txt; s=iport; t=1580031849; x=1581241449; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=gVDMRgcq3YygyADpK+ahQPoSuY4H3p2qoJaxNk9vKHY=; b=HnqVmND3+F7WG/+l1xdNPmOtjjAFp5Bgq6qWPvT2FJUtwAeUmKxKV8XB fvGBzM18xwnBiQKlRSavdSAUPpCZfRNxNEB7pUg/1N0twHChxvOowjftH ipO9XvxYexp22a0cX79ze7RAipJaXYgoSo4QeKPhn+DRlcwQFtz4SsUaV 4=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjAwAkXi1e/xbLJq1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuDFVQBIBIqhBSJA4g5gQGSLIgLAgcBAQEJAwEBJQoBAYRAAoJ?= =?us-ascii?q?GOBMCAw0BAQQBAQECAQUEbYULAQUBJQyFXgEBAQECASNWBQsLDgoqAgJXBhM?= =?us-ascii?q?UBYMNAYJbIA+pB3WBMoQ1AYEUhGgKBoE4gVOIeIFtggCBEScggU5JBy4+gmQ?= =?us-ascii?q?BAYE8gzcygiwEhWOIDwuJN4hwjzSCQ4JMgRyDWo51G4JIjCgni2WXRI57gy4?= =?us-ascii?q?CBAYFAhWBaSKBWDMaCBsVZQGCQRMrEhgNjA+DKIRBFxWDO4pSAkADMA2LaIJ?= =?us-ascii?q?DAQE?= X-IronPort-AV: E=Sophos;i="5.70,365,1574121600"; d="asc'?scan'208,217";a="22534129" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jan 2020 09:44:06 +0000 Received: from [10.61.171.81] ([10.61.171.81]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00Q9i5dI031990 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 26 Jan 2020 09:44:06 GMT From: Eliot Lear Message-Id: <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CD420CE8-71BB-456B-A0DC-7DED7143036E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Sun, 26 Jan 2020 10:44:05 +0100 In-Reply-To: Cc: architecture-discuss@ietf.org, model-t@iab.org To: Eric Rescorla References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.171.81, [10.61.171.81] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 09:44:12 -0000 --Apple-Mail=_CD420CE8-71BB-456B-A0DC-7DED7143036E Content-Type: multipart/alternative; boundary="Apple-Mail=_7350C2A6-1291-42F2-99E4-65F29C318364" --Apple-Mail=_7350C2A6-1291-42F2-99E4-65F29C318364 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, I apologize for the length of this missive. I=E2=80=99ve included = examples that are either from real life or plausible to the point of = inevitability. > On 26 Jan 2020, at 08:36, Eric Rescorla wrote: >=20 > It's probably useful to put the text in 3552 in context, which was = primarily about designing COMSEC protocols. Our ability to build two = party protocols which survive one of the parties being compromised is = fairly limited. Indeed. > We *do* have some praxis for building N party protocols which = gracefully degrade when some of the nodes are compromised (for instance = consensus protocols). Of course, the exact properties of those protocols = can be difficult to succinctly state. They are, and they are hard to build, and they have their own failure = modes.(*). But I really wasn=E2=80=99t going there, at least not = directly. Let=E2=80=99s look at three specific examples that I=E2=80=99ve= mentioned: 1. Train signaling system needs to be audited both live and = retrospectively in the case of accidents. This has to happen in such a = way that the auditor sees precisely what was sent by one endpoint and = received by the other. 2. The case of =E2=80=9Cparent doesn=E2=80=99t want Internet toy to = send video of child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s= an analog to the privacy analysis on Alexa[1] and the now infamous NEST = episode[2]). 3. CPAP machine or an AED/pace maker provide a control interface to the = doctor but the patient or his next of kin wants the data. Each example has a slightly different threat model, in addition to what = you stated in 3552. In the first case, we add mistakes on the part of = the operator (certainly the most common at this point**), and endpoint = compromises. In the second case, it is the manufacturer themselves that = is the threat, for failing to have disclosed what they are doing. The third case is more difficult. Let=E2=80=99s say a patient died. = Did the patient die (a) of natural causes, (b) due to a mistake made by = the patient or a care giver at home, (c) due to a mistake made by the = healthcare professional on the other end, or (d) due to an cyberattack? = It may be impossible for the next of kin to know if there is no network = audit capability. Yes, this is a messy case, which makes it a good one = to explore. The program can explore COMSEC, UX, and higher level issues as well, = like economics. That latter one is actually important because if in the = end the use cases above are going to get trumped by economics on the = part of manufacturers, what=E2=80=99s the point of specifying mechanism? = This also goes to another point about which the IAB has had concern: = concentration and control points. That can be explored as well here. = This does look to relax the assumption you laid down in 3552 about = endpoints, but I don=E2=80=99t think it dramatically changes things. Also, when you wrote 3552, there was really only the theoretical notion = of a cyberwar, ruling out attacks with infinite or near infinite = resources. That=E2=80=99s now an every day reality. In RFC 7958, we = sort of ruled them back in, but I think it=E2=80=99s worth exploring a = bit more what that means. A program for that is a very good idea. >=20 > I'm not quite sure I understand what you mean when you say "They are = the source of just about all compromise attacks." I'm not saying it's = not true, but perhaps you could elaborate. >=20 With apologies, I was shamelessly stating the obvious: the vast source = of bugs are on end devices, not because middle boxes are better designed = (some are, some aren=E2=80=99t), but because of sheer numbers. Well, if = endpoints are where the problems are, that=E2=80=99s where we need to = spend time as a community. Eliot (*) My favorite example of a consensus protocol that had =E2=80=9Cgood = intentions" was BSD timed. =E2=80=9CIt was a dark and stormy night=E2=80=9D= , when every participant had an unstable ticker in a different way, = leading to time storms. (**) For a very interesting read for anyone interested in IoT, I highly = recommend =E2=80=9CFamous British Railway Disasters, Ian Allan Pub, = 2000. https://www.amazon.com/British-Railway-Disasters/dp/0711024707 [1] Malkin, et. al., =E2=80=9CPrivacy Attitudes Toward Smark Speaker = Users=E2=80=9D, Proceedings of Privacy Enhancing Technologies, 2019. [2] = https://arstechnica.com/gadgets/2019/02/googles-nest-security-system-shipp= ed-with-a-secret-microphone/ --Apple-Mail=_7350C2A6-1291-42F2-99E4-65F29C318364 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

I apologize = for the length of this missive.  I=E2=80=99ve included examples = that are either from real life or plausible to the point of = inevitability.

On 26 Jan 2020, at 08:36, Eric Rescorla = <ekr@rtfm.com> = wrote:

It's probably = useful to put the text in 3552 in context, which was primarily about = designing COMSEC protocols. Our ability to build two party protocols = which survive one of the parties being compromised is fairly limited. =

Indeed.

We *do* have some praxis for building N party protocols which = gracefully degrade when some of the nodes are compromised (for instance = consensus protocols). Of course, the exact properties of those protocols = can be difficult to succinctly = state.

They are, = and they are hard to build, and they have their own failure modes.(*). = But I really wasn=E2=80=99t going there, at least not directly. =  Let=E2=80=99s look at three specific examples that I=E2=80=99ve = mentioned:

1.  Train signaling system = needs to be audited both live and retrospectively in the case of = accidents.  This has to happen in such a way that the auditor sees = precisely what was sent by one endpoint and received by the = other.

2.  The case of = =E2=80=9Cparent doesn=E2=80=99t want Internet toy to send video of = child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s an analog = to the privacy analysis on Alexa[1] and the now infamous NEST = episode[2]).

3. CPAP machine or an = AED/pace maker provide a control interface to the doctor but the patient = or his next of kin wants the data.

Each example has a slightly different threat = model, in addition to what you stated in 3552. In the first case, we add = mistakes on the part of the operator (certainly the most common at this = point**), and endpoint compromises.  In the second case, it is the = manufacturer themselves that is the threat, for failing to have = disclosed what they are doing.  

The third case is more difficult.  Let=E2=80=99= s say a patient died.  Did the patient die (a) of natural causes, = (b) due to a mistake made by the patient or a care giver at home, (c) = due to a mistake made by the healthcare professional on the other end, = or (d) due to an cyberattack?  It may be impossible for the next of = kin to know if there is no network audit capability.  Yes, this is = a messy case, which makes it a good one to explore.

The program can explore COMSEC, UX, and = higher level issues as well, like economics.  That latter one is = actually important because if in the end the use cases above are going = to get trumped by economics on the part of manufacturers, what=E2=80=99s = the point of specifying mechanism?   This also goes to another = point about which the IAB has had concern: concentration and control = points.  That can be explored as well here. This does look to relax = the assumption you laid down in 3552 about endpoints, but I don=E2=80=99t = think it dramatically changes things.

Also, when you wrote 3552, there was = really only the theoretical notion of a cyberwar, ruling out attacks = with infinite or near infinite resources.  That=E2=80=99s now an = every day reality.  In RFC 7958, we sort of ruled them back in, but = I think it=E2=80=99s worth exploring a bit more what that means.  A = program for that is a very good idea.


I'm not quite sure I understand what you mean when you say = "They are the source of just about all compromise attacks." I'm not = saying it's not true, but perhaps you could elaborate.


With apologies, I was shamelessly stating the obvious: = the vast source of bugs are on end devices, not because middle boxes are = better designed (some are, some aren=E2=80=99t), but because of sheer = numbers.  Well, if endpoints are where the problems are, that=E2=80=99= s where we need to spend time as a community.

Eliot

(*) My = favorite example of a consensus protocol that had =E2=80=9Cgood = intentions" was BSD timed.  =E2=80=9CIt was a dark and stormy = night=E2=80=9D, when every participant had an unstable ticker in a = different way, leading to time storms.
(**) For a very = interesting read for anyone interested in IoT, I highly recommend = =E2=80=9CFamous British Railway Disasters, Ian Allan Pub, 2000.  https://www.amazon.com/British-Railway-Disasters/dp/0711024707<= /a>
= --Apple-Mail=_7350C2A6-1291-42F2-99E4-65F29C318364-- --Apple-Mail=_CD420CE8-71BB-456B-A0DC-7DED7143036E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4tX2UACgkQh7ZrRtnS ejNajwf+OrBXbEPRwiDg0fvCIUuZGcbDDYYn/r5GmioA3fwwssYj6qWKGdQEf2yh Z6Bi0Rs/P0VHdniintOkkPzeUHMrIdVvVzSYNFJZHeqjtUUkD0yuGHBzbCxZhuPJ tSaBGhZz3agoSzU6Q8LNiXtbBLqnAKqrVrqlHeKEGoR/1l/mYiO6RHX+bIXy/B9y 1EyhMYhuj8EaBdDGmm/FeelcukdCnym1AYr4dlf550DkURCFNND0hSFKbmvZ8nkC wmGYiNSZ5JY/84GOnh56exi24uSOXgWdMkzBGX/XQHz7DMRk6qBK+JKGfn6rejjA xzuqRi8SWSDjcLUnZtMM/8U/KpcqzA== =glaq -----END PGP SIGNATURE----- --Apple-Mail=_CD420CE8-71BB-456B-A0DC-7DED7143036E-- From nobody Sun Jan 26 05:05:58 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F41112006B for ; Sun, 26 Jan 2020 05:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_SCAM=1.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQpYZPf_wpk8 for ; Sun, 26 Jan 2020 05:05:53 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 3E084120058 for ; Sun, 26 Jan 2020 05:05:53 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id g64so5884781otb.13 for ; Sun, 26 Jan 2020 05:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ss5xAP5CgqNU5svEZ4fcsdryAr555dl+LZvYEUVD5po=; b=nMAFiyUNizlyqKyE0fBUXsMhuGa2DYD63BCHrsC8hQcfiVWSqjsVLC47NybDbb6IGd YO/VXl/9grJoiMosMehqdSr/+0YSh08Hs5r6HX53BhjACoIq6RWh4j4y61nm8xT2YObK VonnB1Xy1qayYkI/fqyG/Voxc9Z/Z7Kk8tArlH20+0zg8SAEFcSmVV7RF8Tkrl3Mz/rE oCmCk2LpsWypd7UMF/Omc/yEwYnX1rLSb8p5VtIHsdC1wSUsOP3sCE916AdPOFY5g7KU 3vv77nFw7jytgQQTO5ktuq/uawYM6zInALZgeoQnyHeVmuKeJZUk1tt7yRCMES02bVZ9 Yd/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ss5xAP5CgqNU5svEZ4fcsdryAr555dl+LZvYEUVD5po=; b=AX2mlHCmNGfC1SRTBPJTmS8GorT1Grdudh3YbEEbRHeoOJ6RnU49UOu+IIeFMNlzYq +UuNQd1cbNvRUd1HR/NKoAfCPAQTh2k4vvsF1tQtnKeFzpm9LdqXXflqo2oNoM5NeFpT LO5m54R25BLqTu6Pfj0vFRnaDIU0fMAmr62iWomJVccLQhadOyfggulrxTdBdBYrwfAu OzXniLdeiUBjGIvT+6f8HD7ls7Jlay5IElaFRah4HhHnIyOdZ+9o/O3iUr84jw/InrQF XODDzm6aieYtLHtmncsJ59IWgrhOUxjQCVexiXCshN4dCR77eZHfP+HB4ZpQJDV8TDk1 OZFA== X-Gm-Message-State: APjAAAVXKB0qY401rm2JB5hiCBNi7Q/q/WsMj3Zn9h2e+J+TL8NNDapQ 10m09WHOGwzdAc8sTnUCYSmJNiqDwrECqmxPuAc= X-Google-Smtp-Source: APXvYqz3Zvz2S8nAVmCqvS3PgZ1oMvIelImiHAbX2zJL0hBO13JObEGTIwihrq6IjPpei85ttJEg9YR7cAGSKTqoOdc= X-Received: by 2002:a9d:6c52:: with SMTP id g18mr9322339otq.356.1580043952555; Sun, 26 Jan 2020 05:05:52 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Sun, 26 Jan 2020 05:05:51 -0800 (PST) In-Reply-To: <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> From: Guntur Wiseno Putra Date: Sun, 26 Jan 2020 20:05:51 +0700 Message-ID: To: Eliot Lear Cc: Eric Rescorla , "architecture-discuss@ietf.org" , "model-t@iab.org" Content-Type: multipart/alternative; boundary="000000000000858ada059d0aa6e7" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 13:05:55 -0000 --000000000000858ada059d0aa6e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss, Networks of Interests: Trusts and Distrusts...? In trying to follow the fluxes of the discussion, I begin with such basic understandings below: Networks of Interests: Trust and Distrust... - when the interests are understood by either/all parties involved there are (networks of) trusts. - when the interests are not understood/accepted by either/all parties involved there are (networks of) suspicions/threats/distrusts. For the Internet: As it is about networks of computers, of communications, so it is about identifying critical points of security: those threats and trusts --actual and potential (1) Two levels/layers to consider of analyzing the securities of the networks of communications: technical architecture --which is about design environment, (about "arstechnica"?)-- and the architecture's deployment environments... RFC 2316 and 3552 is considered as they are references of information and best current practice of the Internet engineering (2). The ITU of the UN report "Leveraging Tech..." and the Internet Society Report "Consolidation in the Internet Economy" as kinds of analytical tools to mapping a context (of problems, thus about real social conditions). (3) (1) The identifications depends on interpretations and evaluations (approaches and perspectives). (2) https://www.rfc-editor.org/info/rfc2316; https://www.rfc-editor.org/info/rfc3552 (3) The ITU of the UN report =E2=80=9CFast-forward Progress: Leveraging tec= h to achieve the global goals=E2=80=9D https://www.itu.int/en/sustainable-world/Documents/Fast-forward_progress_re= port_414709%20FINAL.pdf 2019 ISOC Global Internet Report "Consolidation in the Internet Economy" https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/= InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf Regard, Guntur Wiseno Putra Pada Minggu, 26 Januari 2020, Eliot Lear menulis: > Hi Eric, > > I apologize for the length of this missive. I=E2=80=99ve included exampl= es that > are either from real life or plausible to the point of inevitability. > > On 26 Jan 2020, at 08:36, Eric Rescorla wrote: > > It's probably useful to put the text in 3552 in context, which was > primarily about designing COMSEC protocols. Our ability to build two part= y > protocols which survive one of the parties being compromised is fairly > limited. > > > Indeed. > > We *do* have some praxis for building N party protocols which gracefully > degrade when some of the nodes are compromised (for instance consensus > protocols). Of course, the exact properties of those protocols can be > difficult to succinctly state. > > > They are, and they are hard to build, and they have their own failure > modes.(*). But I really wasn=E2=80=99t going there, at least not directly= . Let=E2=80=99s > look at three specific examples that I=E2=80=99ve mentioned: > > 1. Train signaling system needs to be audited both live and > retrospectively in the case of accidents. This has to happen in such a w= ay > that the auditor sees precisely what was sent by one endpoint and receive= d > by the other. > > 2. The case of =E2=80=9Cparent doesn=E2=80=99t want Internet toy to send= video of child=E2=80=9D, > when the camera is undisclosed (it=E2=80=99s an analog to the privacy ana= lysis on > Alexa[1] and the now infamous NEST episode[2]). > > 3. CPAP machine or an AED/pace maker provide a control interface to the > doctor but the patient or his next of kin wants the data. > > Each example has a slightly different threat model, in addition to what > you stated in 3552. In the first case, we add mistakes on the part of the > operator (certainly the most common at this point**), and endpoint > compromises. In the second case, it is the manufacturer themselves that = is > the threat, for failing to have disclosed what they are doing. > > The third case is more difficult. Let=E2=80=99s say a patient died. Did= the > patient die (a) of natural causes, (b) due to a mistake made by the patie= nt > or a care giver at home, (c) due to a mistake made by the healthcare > professional on the other end, or (d) due to an cyberattack? It may be > impossible for the next of kin to know if there is no network audit > capability. Yes, this is a messy case, which makes it a good one to > explore. > > The program can explore COMSEC, UX, and higher level issues as well, like > economics. That latter one is actually important because if in the end t= he > use cases above are going to get trumped by economics on the part of > manufacturers, what=E2=80=99s the point of specifying mechanism? This a= lso goes > to another point about which the IAB has had concern: concentration and > control points. That can be explored as well here. This does look to rel= ax > the assumption you laid down in 3552 about endpoints, but I don=E2=80=99t= think it > dramatically changes things. > > Also, when you wrote 3552, there was really only the theoretical notion o= f > a cyberwar, ruling out attacks with infinite or near infinite resources. > That=E2=80=99s now an every day reality. In RFC 7958, we sort of ruled t= hem back > in, but I think it=E2=80=99s worth exploring a bit more what that means. = A program > for that is a *very* good idea. > > > I'm not quite sure I understand what you mean when you say "They are the > source of just about all compromise attacks." I'm not saying it's not tru= e, > but perhaps you could elaborate. > > > With apologies, I was shamelessly stating the obvious: the vast source of > bugs are on end devices, not because middle boxes are better designed (so= me > are, some aren=E2=80=99t), but because of sheer numbers. Well, if endpoi= nts are > where the problems are, that=E2=80=99s where we need to spend time as a c= ommunity. > > Eliot > > (*) My favorite example of a consensus protocol that had =E2=80=9Cgood in= tentions" > was BSD timed. =E2=80=9CIt was a dark and stormy night=E2=80=9D, when ev= ery participant > had an unstable ticker in a different way, leading to time storms. > (**) For a very interesting read for anyone interested in IoT, I highly > recommend =E2=80=9CFamous British Railway Disasters, Ian Allan Pub, 2000. > https://www.amazon.com/British-Railway-Disasters/dp/0711024707 > [1] Malkin, et. al., =E2=80=9CPrivacy Attitudes Toward Smark Speaker User= s=E2=80=9D, > Proceedings of Privacy Enhancing Technologies, 2019. > [2] https://arstechnica.com/gadgets/2019/02/googles-nest- > security-system-shipped-with-a-secret-microphone/ > --000000000000858ada059d0aa6e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

Networks of Interests: Trusts= and Distrusts...?


In trying to fol= low the fluxes of the discussion, I begin with such basic understandings be= low:

Networks of Interests: Trust and Distrust...

- when the interests are understood by either/all parties involved there ar= e (networks of) trusts.

- when the interests are not understood/accepted by either/all parties invo= lved there are (networks of) suspicions/threats/distrusts.

For the Internet:

As it is about networks of computers, of communications, so it is about ide= ntifying=C2=A0 critical points of security: those threats and trusts --actu= al and potential (1)

Two levels/layers to consider of analyzing the securities of the networks o= f communications: technical architecture --which is about design environmen= t, (about "arstechnica"?)-- and the architecture's deployment= environments...

RFC 2316 and 3552 is considered as they are references of information and b= est current practice of the Internet engineering (2).

The ITU of the UN report "Leveraging Tech..." and the Internet So= ciety Report "Consolidation in the Internet Economy" as kinds of = analytical tools to mapping a context (of problems, thus about real social = conditions). (3)

(1) The identifications depends on interpretations and evaluations (approac= hes and perspectives).

(2) https://www.rfc-edi= tor.org/info/rfc2316; https://www.rfc-editor.org/info/rfc3552


(3) The ITU of the UN report =E2=80=9CFast-forward Progress: Leveraging tec= h to achieve the global goals=E2=80=9D
https://www.itu.int/en/sustainable-worl= d/Documents/Fast-forward_progress_report_414709%20FINAL.pdf

2019 ISOC Global Internet Report "Consolidation in the Internet Econom= y"
https://future.internetsociety.org/2019/wp-content/uploads/site= s/2/2019/04/InternetSociety-GlobalInternetReport-ConsolidationintheInternet= Economy.pdf



= Regard,
Guntur Wiseno Putra


Pada Minggu, 26= Januari 2020, Eliot Lear <lear@cisco.= com> menulis:
Hi Eric,

I = apologize for the length of this missive.=C2=A0 I=E2=80=99ve included examp= les that are either from real life or plausible to the point of inevitabili= ty.

On 26 Jan 2020, at 08:36, Er= ic Rescorla <ekr@rtfm.= com> wrote:

It's probably us= eful to put the text in 3552 in context, which was primarily about designin= g COMSEC protocols. Our ability to build two party protocols which survive = one of the parties being compromised is fairly limited.
<= /blockquote>

Indeed.

=
We *do* have some praxis for building N party pr= otocols which gracefully degrade when some of the nodes are compromised (fo= r instance consensus protocols). Of course, the exact properties of those p= rotocols can be difficult to succinctly state.

They are, and they are hard to build, and they have their = own failure modes.(*). But I really wasn=E2=80=99t going there, at least no= t directly.=C2=A0 Let=E2=80=99s look at three specific examples that I=E2= =80=99ve mentioned:

1.=C2=A0 Train signaling system need= s to be audited both live and retrospectively in the case of accidents.=C2= =A0 This has to happen in such a way that the auditor sees precisely what w= as sent by one endpoint and received by the other.

2.=C2=A0 The case of =E2=80=9Cparent doesn=E2=80=99t want Internet toy to = send video of child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s = an analog to the privacy analysis on Alexa[1] and the now infamous NEST epi= sode[2]).

3. CPAP machine or an AED/pace maker pro= vide a control interface to the doctor but the patient or his next of kin w= ants the data.

Each example has a slightly differe= nt threat model, in addition to what you stated in 3552. In the first case,= we add mistakes on the part of the operator (certainly the most common at = this point**), and endpoint compromises.=C2=A0 In the second case, it is th= e manufacturer themselves that is the threat, for failing to have disclosed= what they are doing. =C2=A0

The third case is mor= e difficult.=C2=A0 Let=E2=80=99s say a patient died.=C2=A0 Did the patient = die (a) of natural causes, (b) due to a mistake made by the patient or a ca= re giver at home, (c) due to a mistake made by the healthcare professional = on the other end, or (d) due to an cyberattack?=C2=A0 It may be impossible = for the next of kin to know if there is no network audit capability.=C2=A0 = Yes, this is a messy case, which makes it a good one to explore.
=
The program can explore COMSEC, UX, and higher level is= sues as well, like economics.=C2=A0 That latter one is actually important b= ecause if in the end the use cases above are going to get trumped by econom= ics on the part of manufacturers, what=E2=80=99s the point of specifying me= chanism? =C2=A0 This also goes to another point about which the IAB has had= concern: concentration and control points.=C2=A0 That can be explored as w= ell here. This does look to relax the assumption you laid down in 3552 abou= t endpoints, but I don=E2=80=99t think it dramatically changes things.

Also, when you wrote 3552, there was really only the t= heoretical notion of a cyberwar, ruling out attacks with infinite or near i= nfinite resources.=C2=A0 That=E2=80=99s now an every day reality.=C2=A0 In = RFC 7958, we sort of ruled them back in, but I think it=E2=80=99s worth exp= loring a bit more what that means.=C2=A0 A program for that is a very good idea.


I'm not quite sure I understand what you mean when= you say "They are the source of just about all compromise attacks.&qu= ot; I'm not saying it's not true, but perhaps you could elaborate.<= /div>


With apologies,= I was shamelessly stating the obvious: the vast source of bugs are on end = devices, not because middle boxes are better designed (some are, some aren= =E2=80=99t), but because of sheer numbers.=C2=A0 Well, if endpoints are whe= re the problems are, that=E2=80=99s where we need to spend time as a commun= ity.

Eliot

(*) My favorit= e example of a consensus protocol that had =E2=80=9Cgood intentions" w= as BSD timed. =C2=A0=E2=80=9CIt was a dark and stormy night=E2=80=9D, when = every participant had an unstable ticker in a different way, leading to tim= e storms.
(**) For a very interesting read for anyone interested = in IoT, I highly recommend =E2=80=9CFamous British Railway Disasters, Ian A= llan Pub, 2000. =C2=A0https://www.amazon.com/British= -Railway-Disasters/dp/0711024707
[1] Malkin, et. al., = =E2=80=9CPrivacy Attitudes Toward Smark Speaker Users=E2=80=9D, Proceedings= of Privacy Enhancing Technologies, =C2=A02019.
--000000000000858ada059d0aa6e7-- From nobody Mon Jan 27 01:54:34 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A17120132 for ; Mon, 27 Jan 2020 01:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_SCAM=1.999, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDIfTmfJ3Fep for ; Mon, 27 Jan 2020 01:54:30 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 131F012001B for ; Mon, 27 Jan 2020 01:54:30 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 39E4A6A272; Mon, 27 Jan 2020 10:54:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1580118868; bh=dbjMyVBx2W0rKbGVZy2bqeKa19hGd/Ge4qqn/cMgMhg=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=9ytS+fjNCyiY+XO4HXqIub60BZaz8lsxFCMnXgFdoGZOZSS0T/mH8KRiKWX/jviMo WJnXQ8h6JMptiHkiFx3uJqA0bkO5bcrqZW+GYZKKoU06vw8QvuxfGOM331UWSwujGh Jk5ak5kmD9+aT6L/XH8nnPnerZcfuQkRxfDjDv+coCFt1ZUKqyjJ5iKIkjvWY+MwkM dN1czgfqG3axalrPzflcJ3fQVIGkTF5FoHjGfgI5k226gnSLCiNsntwUBcYVQR26Ly gtRm/YAwMfNbaeqUSmZLWudJ3Egr1rQrIXiT3uNjSXrEzYLZbZPfehKtfoZTBqZ9fq qfh6h9ZL/AZgw== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 22B8B3C0424; Mon, 27 Jan 2020 10:54:28 +0100 (CET) Date: Mon, 27 Jan 2020 10:54:27 +0100 (CET) From: Vittorio Bertola To: Eliot Lear Cc: architecture-discuss@ietf.org, model-t@iab.org Message-ID: <509170201.60518.1580118868021@appsuite-gw1.open-xchange.com> In-Reply-To: <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev3 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 09:54:33 -0000 =20 =20

Il 26/01/2020 10:44 Eliot Lear <lear@cisco.com> ha scritto:

They are, and they are hard to build, and they have their own failure = modes.(*). But I really wasn=E2=80=99t going there, at least not directly. =  Let=E2=80=99s look at three specific examples that I=E2=80=99ve menti= oned:

1.  Train signaling system needs to be audited both live and ret= rospectively in the case of accidents.  This has to happen in such a w= ay that the auditor sees precisely what was sent by one endpoint and receiv= ed by the other.

2.  The case of =E2=80=9Cparent doesn=E2=80=99t want Internet to= y to send video of child=E2=80=9D, when the camera is undisclosed (it=E2=80= =99s an analog to the privacy analysis on Alexa[1] and the now infamous NES= T episode[2]).

3. CPAP machine or an AED/pace maker provide a control interface to t= he doctor but the patient or his next of kin wants the data.

Each example has a slightly different threat model, in addition to wh= at you stated in 3552. In the first case, we add mistakes on the part of th= e operator (certainly the most common at this point**), and endpoint compro= mises.  In the second case, it is the manufacturer themselves that is = the threat, for failing to have disclosed what they are doing.  

The third case is more difficult.  Let=E2=80=99s say a patient d= ied.  Did the patient die (a) of natural causes, (b) due to a mistake = made by the patient or a care giver at home, (c) due to a mistake made by t= he healthcare professional on the other end, or (d) due to an cyberattack? =  It may be impossible for the next of kin to know if there is no netwo= rk audit capability.  Yes, this is a messy case, which makes it a good= one to explore.

The program can explore COMSEC, UX, and higher level issues as well,= like economics.  That latter one is actually important because if in = the end the use cases above are going to get trumped by economics on the pa= rt of manufacturers, what=E2=80=99s the point of specifying mechanism? &nbs= p; This also goes to another point about which the IAB has had concern: con= centration and control points.  That can be explored as well here. Thi= s does look to relax the assumption you laid down in 3552 about endpoints, = but I don=E2=80=99t think it dramatically changes things.
Part of the issue is, when you have to write "security considerations", = what do you mean by "security". If that means "security of the protocol", I= can see why you end up with a theoretical approach that defines the securi= ty of the endpoints as out of scope. However, if that means "security of th= e applications that will be built over the protocol", or "security of the u= sers of the protocol", and if security includes privacy and data protection= (or even human rights, as the people in HRPC would argue), then the scope = becomes much broader. Given the desired focus on prioritizing end-user need= s, the meaning should be the latter.

In that case, in the almost 20 years that have passed since RFC 3552, th= e scenario has changed significantly. For example, 20 years ago end-users w= ere, at least in theory, fully in control of what ran on their endpoints, w= hich basically consisted of personal computers; nowadays, most end-users ac= cess the Internet via smartphones, where their control is much more limited= - and let alone IoT devices; both smartphones and IoT devices are categori= es of endpoints that did not exist at the time. 20 years ago there was no "= cloud" or "edge computing", and even if the cloud is just someone else's co= mputer, still the location of personal information over the network has sig= nificantly changed. 20 years ago the Internet was the Internet, i.e. a perm= issionless innovation network of networks where lots of people produced con= tent and services even on a very small scale; nowadays, apart from email an= d the web, many of the most popular services consist of walled gardens, and= even network infrastructure is remarkably centralised, not in topological = terms but in terms of ownership and control.

I think that it would be good to discuss how these things impact the sec= urity of the user, and how they should be considered when writing new proto= cols. Perhaps, after the discussion, we could conclude that they do not aff= ect protocol design. But I think that in some cases they could, and so the = discussion would be useful.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open=
-Xchange
vittorio.b=
ertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Ital=
y
=20 From nobody Tue Jan 28 03:33:51 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60214120024 for ; Tue, 28 Jan 2020 03:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpZOD3NaZfXA for ; Tue, 28 Jan 2020 03:33:46 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2BAC12001B for ; Tue, 28 Jan 2020 03:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9936; q=dns/txt; s=iport; t=1580211226; x=1581420826; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=g2IFCPFvMfy6H/Xk+gZlDj9RF4gQu3lnR3qCqEwddjk=; b=aXnTh6yiGgqFRc5Ty2aBEZAJku65PKaUGB0xKlxgrONJMkQp24EyWu7l FvkO9oqDrFi/K7jjO4296wwBw61vZDhDWmOWTPE50W5TpPo2Y0qFm5j/r 2bIoDvcBVGZg1pz1Y/RhnsQlCyUn7v+BarVbHRV9QTR6kfZuakH+a9t8D o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAwC5GzBe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuEChIqhBSJA4gVJZMtiAsCBwEBAQkDAQEvAQGEQAKCSjgTAgM?= =?us-ascii?q?NAQEEAQEBAgEFBG2FQ4VeAQECAgEjVgULIyMHAgJXBhODJgGCWyCrYHWBMoV?= =?us-ascii?q?KhGkQgTiBU4plggCBEScMFIFOUGyHWTKCLASXNJgkgkOCTIEckk8bljeERaY?= =?us-ascii?q?/gy4CBAYFAhWBaSKBWDMaCBsVZQGCQT4SGA2OKRcVjg9AAzCLay2CFAEB?= X-IronPort-AV: E=Sophos;i="5.70,373,1574121600"; d="asc'?scan'208,217";a="22687500" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jan 2020 11:33:43 +0000 Received: from ams3-vpn-dhcp4134.cisco.com (ams3-vpn-dhcp4134.cisco.com [10.61.80.37]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00SBXhf0001230 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jan 2020 11:33:43 GMT From: Eliot Lear Message-Id: <2B1BEC89-D6DF-4E7A-9171-63257BDCFFA6@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_27B9B0D0-26F5-4F1A-9EBB-93BBB904C3AE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 28 Jan 2020 12:33:42 +0100 In-Reply-To: <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> Cc: "architecture-discuss@ietf.org" , model-t@iab.org To: Stephen Farrell References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.80.37, ams3-vpn-dhcp4134.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Model-t] Yes, building blocks ; -) Re: not building blocks (was: Re: [arch-d] Possible new IAB program on Internet trust model evolution) X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 11:33:49 -0000 --Apple-Mail=_27B9B0D0-26F5-4F1A-9EBB-93BBB904C3AE Content-Type: multipart/alternative; boundary="Apple-Mail=_62297430-9B3C-4C58-8CCD-8CA14841E0FF" --Apple-Mail=_62297430-9B3C-4C58-8CCD-8CA14841E0FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Last message of the day for me, promise. Thanks for your patience.] Hi Stephen, I know I=E2=80=99ve said this in the past, but I hope we=E2=80=99re = actually agreeing more than disagreeing here. See below. > On 28 Jan 2020, at 11:02, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 28/01/2020 06:44, Eliot Lear wrote: >> =46rom an IAB program standpoint, the real question here is this: = what >> are the architectural building blocks that are required? > I'm not sure I agree. ISTM you envisage a programme that > tries to establish that existing IETF consensus as to the > use of e2e encryption needs to be changed, which I don't > think is a goal here. Personally, I think of this as a > place to work on whether or not it's possible to extend > (not replace) the 3552 threat model to cater for changes > since 3552 was written. (I do think that's an interesting > question and it's unclear to me if the answer is "yes" or > "would like to, but it's not usefully feasible.") 3552 a great document! It provides great guidance for a very common = usage pattern. As such, we should tread very carefully, but tread we = must, no? I do not suggest we replace it, but rather examine = assumptions and its applicability. Christian=E2=80=99s comment is apt: = do we assume that devices are safe because they are disconnected? >=20 > Now, it's of course valid to point out that comsec (as > ekr may put it) if applied e2e doesn't by itself meet > all requirements stated in your examples, to which I'd > maybe argue to extend the Internet threat model with > some statement along the lines of: "if an endpoint > does need to see traffic content or significant meta- > data, then you need to design your protocol so that that > endpoint is an endpoint at which relevant cryptographic > mechanisms are validly terminated, according to the > expectations of the cryptographic protocol(s) in use (e.g. > TLS, IPsec). I really don=E2=80=99t know what expectations a protocol has, but if = part of an existing code base / specification can reasonably satisfy = clear and well justified requirements, I would rather beg, borrow, and = steal than rewrite, so as to capitalize on past experience. That=E2=80=99= s not to say we should change any existing protocol, but rather depend = on the parts we can leverage. > So I don't think, for the purposes of this exercise, > we're considering existing widely deployed protocols as > malleable building blocks, whether that protocol is > TLS or some (deployed) train signalling system. Building blocks must be stable and not malleable so that others can = depend on their behavior. I hope we don=E2=80=99t look at any single = example to design those blocks, which is why I raised several; I hope = others would raise others, as Watson did; and I would suggest that this = program take a walk before run approach. In summary (otherwise known as burying the lede), my suggestion is to = test / validate these sorts of examples, maybe decompose as required a = bit of what we have =E2=80=9Con the truck=E2=80=9D into various = components that could prove useful, pick from the best, create the rest, = and then demonstrate value.(*) Eliot (*) There is probably a separate more general question hiding here as to = how we build protocols, and what is the right granularity for their = constituent parts. --Apple-Mail=_62297430-9B3C-4C58-8CCD-8CA14841E0FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[Last message of the day for me, promise.  Thanks for = your patience.]

Hi = Stephen,

I know = I=E2=80=99ve said this in the past, but I hope we=E2=80=99re actually = agreeing more than disagreeing here.  See below.

On 28 Jan 2020, at 11:02, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 28/01/2020 06:44, Eliot = Lear wrote:
=46rom an = IAB program standpoint, the real question here is this: what
are the architectural building blocks that are required?
I'm not sure I agree. ISTM you envisage a = programme that
tries to establish that existing IETF = consensus as to the
use of e2e encryption needs to be = changed, which I don't
think is a goal here. Personally, I = think of this as a
place to work on whether or not it's = possible to extend
(not replace) the 3552 threat model to = cater for changes
since 3552 was written. (I do think = that's an interesting
question and it's unclear to me if = the answer is "yes" or
"would like to, but it's not = usefully feasible.")

3552 a great document! It provides great guidance for a = very common usage pattern. As such, we should tread very carefully, but = tread we must, no?  I do not suggest we replace it, but rather = examine assumptions and its applicability.  Christian=E2=80=99s = comment is apt: do we assume that devices are safe because they are = disconnected?


Now, it's of course valid to point out that comsec (as
ekr may put it) if applied e2e doesn't by itself meet
all requirements stated in your examples, to which I'd
maybe argue to extend the Internet threat model with
some statement along the lines of: "if an endpoint
does need to see traffic content or significant meta-
data, then you need to design your protocol so that that
endpoint is an endpoint at which relevant cryptographic
mechanisms are validly terminated, according to the
expectations of the cryptographic protocol(s) in use (e.g.
TLS, IPsec).

I really don=E2=80=99t know what expectations a = protocol has, but if part of an existing code base / specification can = reasonably satisfy clear and well justified requirements, I would rather = beg, borrow, and steal than rewrite, so as to capitalize on past = experience.  That=E2=80=99s not to say we should change any existing protocol, but rather depend on the parts we = can leverage.

So I don't think, for the = purposes of this exercise,
we're considering existing = widely deployed protocols as
malleable building blocks, = whether that protocol is
TLS or some (deployed) train = signalling system.

Building = blocks must be stable and not malleable so that others can depend on their = behavior.  I hope we don=E2=80=99t look at any single example to = design those blocks, which is why I raised several; I hope others would = raise others, as Watson did; and I would suggest that this program take = a walk before run approach.

In summary (otherwise known as burying the lede), my = suggestion is to test / validate these sorts of examples, maybe = decompose as required a bit of what we have =E2=80=9Con the truck=E2=80=9D= into various components that could prove useful, pick from the best, = create the rest, and then demonstrate value.(*)

Eliot

(*) There is probably a separate more = general question hiding here as to how we build protocols, and what is = the right granularity for their constituent parts.
= --Apple-Mail=_62297430-9B3C-4C58-8CCD-8CA14841E0FF-- --Apple-Mail=_27B9B0D0-26F5-4F1A-9EBB-93BBB904C3AE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4wHBYACgkQh7ZrRtnS ejMuyQf9EgBdP6un6pm/icAMIzoi7OiRTDDJPHlTjY2oyw6OCmdXddtXWlHxUHKC 7HyVyGjxp/D2cgvz+wAznrCOj+LO6YMwXDOHi3Gfj45axu57a0cGODiyIdmAeX6i VRoCvJYTuI5tbPS2FRq5gdTs3Oxch4mkMhRg8lVhIHIX63Hw3JqJ4RNrXSXMB9fn IKGuswAYihmDKgXhjQc1squiKOuyaLJZTjxP6VdFFmTpn2XYNvVUTyDYqfHLNRFa f/GMd73M0DGViA0u/Iki7fxRGeqMW5kCSEdYssZ+9VbaT/P05i+ak6lvxEUOleic KMrmzVUL/O/is86UbTiwObuJJaI0DA== =0POA -----END PGP SIGNATURE----- --Apple-Mail=_27B9B0D0-26F5-4F1A-9EBB-93BBB904C3AE-- From nobody Tue Jan 28 06:36:33 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C00D1208FC for ; Tue, 28 Jan 2020 06:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_SCAM=1.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZFFkeehQHNX for ; Tue, 28 Jan 2020 06:36:22 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 7C6851208AA for ; Tue, 28 Jan 2020 06:36:21 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id z9so12163472oth.5 for ; Tue, 28 Jan 2020 06:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QcEIZrHARenQsSkTQtm8ihAzX67XWsrmL73q1ifHG9Y=; b=nyyKYaTfRQ+GWUdb5pi++gFcoCn/imujy1j26YTr0GUf0sbQmA1MAD0Cu0YlTFm9jQ yUiWbEQA57bybjFX6iuAM6f0Gxto8bCud/JnYDbNP4ZTsHO1wBXOBzkEAhQaLgdb/Gmp jvXuktQbDwu40HznstWdU+3iW2EAWO1cP25Z6MIC2VbWr4FaVrvIAAysTUiLfUcMANeX FOKtftm2CuKt8wPBsHDPshEbnyj0sMvn2I5FVdulZODkitTwgUPC1jBLUTAbTom/AnVU GrDTMqas0NDAV28DFE2mD5KihxMEFRChbePhIewS4vcfhr8LA7vv69rf5gi2AqzTNk4w ODtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QcEIZrHARenQsSkTQtm8ihAzX67XWsrmL73q1ifHG9Y=; b=UozhaYgBznYX3Dzju1/pjeekPXb7ZsapvgLP2lZXtLElgZpLJIqG222O1qlGmDgWcb uqCXnAH7yCw/J4OldFv1F2sQxHWwGtGY8BHR1pgZIEjEBvdBeTxeUS4dLQnx28U18dI6 wOSF5oCPHhOMidlt4w2anQpnAFrYFYZhpCioPmnSay0QCbqDQ1UTcdJiQdolNGuhdv+P pL28mmNWhj3eAqdj0n3P+kcGhJIZyTnYXz6171bQ25fN3I07NeHjMwV9rbzHVrWXlXNm pCc0t+BzLM6Cx5+ECUZM4MdZy7TYkD3Sldxf1Gm0o/OCHQQLpHhb0izz3EONJAoRmb76 z9Zw== X-Gm-Message-State: APjAAAXCpRSUAp351OteY9QDkb4awO6NNc9EtIYKJp+9jwhbN6EsXhIk +4zFJVC1Au90gs8VQ49oeOVben/h8Rt5x396P2w= X-Google-Smtp-Source: APXvYqwQ9u5GsnJpGZ2q7/Ad8NLtP2Xb8xSrcwqFjBGXINSccZ58Qg10RvIMqu/W+juimB7CEVEQVTNDpUaAY4dtOFs= X-Received: by 2002:a9d:dc1:: with SMTP id 59mr16928287ots.250.1580222180791; Tue, 28 Jan 2020 06:36:20 -0800 (PST) MIME-Version: 1.0 References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> In-Reply-To: From: Kathleen Moriarty Date: Tue, 28 Jan 2020 09:35:44 -0500 Message-ID: To: Eliot Lear Cc: Watson Ladd , architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="000000000000c09d75059d3425af" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 14:36:26 -0000 --000000000000c09d75059d3425af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 28, 2020 at 1:44 AM Eliot Lear wrote: > Hi Watson, > > On 28 Jan 2020, at 02:35, Watson Ladd wrote: > > > > On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear wrote: > >> Let=E2=80=99s look at three specific examples that I=E2=80=99ve mentio= ned: >> >> 1. Train signaling system needs to be audited both live and >> retrospectively in the case of accidents. This has to happen in such a = way >> that the auditor sees precisely what was sent by one endpoint and receiv= ed >> by the other. >> >> 2. The case of =E2=80=9Cparent doesn=E2=80=99t want Internet toy to sen= d video of >> child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s an analog t= o the privacy >> analysis on Alexa[1] and the now infamous NEST episode[2]). >> >> 3. CPAP machine or an AED/pace maker provide a control interface to the >> doctor but the patient or his next of kin wants the data. >> > > I've got a few more examples from real life: > > 4: We need to see who is sending pictures of Winnie the Pooh. > > 5: We don't want pictures of the inside of our detention centers to appea= r > online. > > 6: I want to see everyone's credit card number at the coffee shop I run. > > Any discussion of tapping network communications because endpoints can't > be trusted needs to take these cases seriously. > > > > Absolutely. What I am suggesting is a relatively new twist on an old > problem(*). It=E2=80=99s important to understand the economic and policy= aspects > of how/whether to avoid [4] and [5], how to avoid [6] while at the same > time addressing use cases I mentioned. > > So=E2=80=A6 today=E2=80=99s new information comes courtesy of the EFF. > > > https://www.eff.org/deeplinks/2020/01/ring-doorbell-app-packed-third-part= y-trackers > > Here we have yet another IoT device that, from at least one person=E2=80= =99s > perspective is invading home privacy. And again, it is the device itself > that is the threat. In this case, it=E2=80=99s probably a more manageabl= e threat, > because one can simply not get a NEST. Try not getting a CPAP machine. > > And this brings us around to what layer to solve the problem at. Some of > this may need to be dealt with at layer 9 rather than at lower layers. W= e > should have that discussion too. > > > > Increasingly corporate networks are moving away from network layer access > controls and using user authentication over TLS, so-called BeyondCorp > model, including checking endpoint posture through management. > > > The endpoint being the focus for attacks is very important. As we shore the endpoint up further, attacks may reduce in number, but will likely increase in severity due to state sponsored actors. Work in RATS, TEEP, SUIT, and MUD should be considered in terms of how assurance of systems is provided and also looking at the use cases to ensure there are sometimes when you don't want that level of attestation. User ownership of data is another area. These build on zero-trust/BeyondCorp/data-centric models and are examples of active work in the IETF on the end point. They also have the potential to shift management and architectural models within the enterprise. Best regards, Kathleen > I don=E2=80=99t think this solves the railroad case. Do you? Just to cl= arify the > example: > > According to their logs, two separate signals received =E2=80=9Cset your= lights > to green=E2=80=9D at the same time, causing two trains to crash into each= other. > According to the signal controller=E2=80=99s logs, it sent =E2=80=9Cset y= our lights to > green=E2=80=9D to only one signal. What happened? > > All of the cases we are discussing have slightly different flavors of > threats. From an IAB program standpoint, the real question here is this: > what are the architectural building blocks that are required? Keep in > mind, some of those blocks could be code and some could be policy. > > One goal should be code reuse. It is probably best that the people > building the train signal *not* reinvent everything, but rather benefit > as much as they can from the experience and results that you, EKR, and a > great many other people have brought to society. > > Eliot > > (*) It=E2=80=99s also important to not fall into old tribal communication > patterns, while recognizing the realities of the concerns raised by you, > Watson, and me. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --=20 Best regards, Kathleen --000000000000c09d75059d3425af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 28, 2020 at 1:44 AM Eliot= Lear <lear=3D40cisco.com@= dmarc.ietf.org> wrote:
Hi Watson,
=
On 28 Jan 2020, at 02:35, Watson Ladd &l= t;watsonbladd@gm= ail.com> wrote:



On Sun, = Jan 26, 2020 at 1:44 AM Eliot Lear <lear@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0 Let= =E2=80=99s look at three specific examples that I=E2=80=99ve mentioned:
=

1.=C2=A0 Train signaling system needs to be audited bot= h live and retrospectively in the case of accidents.=C2=A0 This has to happ= en in such a way that the auditor sees precisely what was sent by one endpo= int and received by the other.

2.=C2=A0 The case o= f =E2=80=9Cparent doesn=E2=80=99t want Internet toy to send video of child= =E2=80=9D, when the camera is undisclosed (it=E2=80=99s an analog to the pr= ivacy analysis on Alexa[1] and the now infamous NEST episode[2]).

3. CPAP machine or an AED/pace maker provide a control inte= rface to the doctor but the patient or his next of kin wants the data.

I've got a few more= examples from real life:

4: We need to see who is= sending pictures of Winnie the Pooh.

5: We don= 9;t want pictures of the inside of our detention centers to appear online.<= /div>

6: I want to see everyon= e's credit card number at the coffee shop I run.

Any discussion of tapping network communicatio= ns because endpoints can't be trusted needs to take these cases serious= ly.=C2=A0


Absol= utely.=C2=A0 What I am suggesting is a relatively new twist on an old probl= em(*).=C2=A0 It=E2=80=99s important to understand the economic and policy a= spects of how/whether to avoid [4] and [5], how to avoid [6] while at the s= ame time addressing use cases I mentioned.

So=E2= =80=A6 today=E2=80=99s new information comes courtesy of the EFF.


Here we have yet another IoT device that, from at least o= ne person=E2=80=99s perspective is invading home privacy.=C2=A0 And again, = it is the device itself that is the threat.=C2=A0 In this case, it=E2=80=99= s probably a more manageable threat, because one can simply not get a NEST.= =C2=A0 Try not getting a CPAP machine.

And this br= ings us around to what layer to solve the problem at.=C2=A0 Some of this ma= y need to be dealt with at layer 9 rather than at lower layers.=C2=A0 We sh= ould have that discussion too.



Increasingly corporate networks are moving aw= ay from network layer access controls and using user authentication over TL= S, so-called BeyondCorp model, including checking endpoint posture through = management.

The endpoint being the focus for attacks is very important.=C2= =A0 As we shore the endpoint up further, attacks may reduce in number, but = will likely increase in severity due to state sponsored actors.=C2=A0 Work = in RATS, TEEP, SUIT, and MUD should be considered in terms of how assurance= of systems is provided and also looking at the use cases to ensure there a= re sometimes when you don't want that level of attestation.=C2=A0 User = ownership of data is another area.=C2=A0 These build on zero-trust/BeyondCo= rp/data-centric models and are examples of active work in the IETF on the e= nd point.=C2=A0 They also have the potential to shift management and archit= ectural models within the enterprise.

Best regards= ,
Kathleen=C2=A0
I don=E2= =80=99t think this solves the railroad case.=C2=A0 Do you?=C2=A0 Just to cl= arify the example:

According to their logs, two se= parate signals received =C2=A0=E2=80=9Cset your lights to green=E2=80=9D at= the same time, causing two trains to crash into each other.=C2=A0 Accordin= g to the signal controller=E2=80=99s logs, it sent =E2=80=9Cset your lights= to green=E2=80=9D to only one signal.=C2=A0 What happened?

<= /div>
All of the cases we are discussing have slightly different flavor= s of threats.=C2=A0 From an IAB program standpoint, the real question here = is this: what are the architectural building blocks that are required?=C2= =A0 Keep in mind, some of those blocks could be code and some could be poli= cy.

One goal should be code reuse. It is probably = best that the people building the train signal not reinvent everythi= ng, but rather benefit as much as they can from the experience and results = that you, EKR, and a great many other people have brought to society.
=

Eliot

(*) It=E2=80=99s also im= portant to not fall into old tribal communication patterns, while recognizi= ng the realities of the concerns raised by you, Watson, and me.
<= br>
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss


--

Best regards,
Kathleen
--000000000000c09d75059d3425af-- From nobody Tue Jan 28 07:16:20 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E96A120124 for ; Tue, 28 Jan 2020 07:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.635 X-Spam-Level: ** X-Spam-Status: No, score=2.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_SCAM=1.999, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7gIGtlXyIIa for ; Tue, 28 Jan 2020 07:16:14 -0800 (PST) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (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 0AC4012023E for ; Tue, 28 Jan 2020 07:16:14 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by mailb1.tigertech.net (Postfix) with ESMTP id 486VZ56rC6z22kld for ; Tue, 28 Jan 2020 07:16:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 486VZ56Tmfz1nyXc; Tue, 28 Jan 2020 07:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1580224573; bh=AS8X3yB4C40Zm3JG2J3nrwqwmjGRhDSQxHaTMZ7cybg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=oIG+MUGdrTVEQs1hpmkgBaFnansUzbWiE++M+Y+Tqjismo/xoxH3sT1AqGVgLNU6N 7wRU1GPpCS0VJaHF0M+VEW1yq1weV+jyavVAL0Beks1ZVlDwT+zIdxgD9+eQ+OX5PF MGZq3/d2uNP4/tCw244vMEzjCBp+QVF99bvHgOfg= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 486VZ51y9rz1ny8c; Tue, 28 Jan 2020 07:16:13 -0800 (PST) To: Eliot Lear Cc: architecture-discuss@ietf.org, model-t@iab.org References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> From: "Joel M. Halpern" Message-ID: <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> Date: Tue, 28 Jan 2020 10:16:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 15:16:15 -0000 I am a bit concerned by the emphasis on what appear to be application policy, business policy, or government policy. To the degree that these are decoupled from the technology we define, my impression is that the IETF is neither skilled at nor influential with regard to these topics. We can spend a lot of time and energy on them. They are interesting topics. But are they really our business? Yours, Joel On 1/28/2020 1:44 AM, Eliot Lear wrote: > Hi Watson, > >> On 28 Jan 2020, at 02:35, Watson Ladd > > wrote: >> >> >> >> On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear > > wrote: >> >>   Let’s look at three specific examples that I’ve mentioned: >> >> 1.  Train signaling system needs to be audited both live and >> retrospectively in the case of accidents.  This has to happen in >> such a way that the auditor sees precisely what was sent by one >> endpoint and received by the other. >> >> 2.  The case of “parent doesn’t want Internet toy to send video of >> child”, when the camera is undisclosed (it’s an analog to the >> privacy analysis on Alexa[1] and the now infamous NEST episode[2]). >> >> 3. CPAP machine or an AED/pace maker provide a control interface >> to the doctor but the patient or his next of kin wants the data. >> >> >> I've got a few more examples from real life: >> >> 4: We need to see who is sending pictures of Winnie the Pooh. >> >> 5: We don't want pictures of the inside of our detention centers to >> appear online. >> >> 6: I want to see everyone's credit card number at the coffee shop I run. >> >> Any discussion of tapping network communications because endpoints >> can't be trusted needs to take these cases seriously. > > > Absolutely.  What I am suggesting is a relatively new twist on an old > problem(*).  It’s important to understand the economic and policy > aspects of how/whether to avoid [4] and [5], how to avoid [6] while at > the same time addressing use cases I mentioned. > > So… today’s new information comes courtesy of the EFF. > > https://www.eff.org/deeplinks/2020/01/ring-doorbell-app-packed-third-party-trackers > > Here we have yet another IoT device that, from at least one person’s > perspective is invading home privacy.  And again, it is the device > itself that is the threat.  In this case, it’s probably a more > manageable threat, because one can simply not get a NEST.  Try not > getting a CPAP machine. > > And this brings us around to what layer to solve the problem at.  Some > of this may need to be dealt with at layer 9 rather than at lower > layers.  We should have that discussion too. > > >> >> Increasingly corporate networks are moving away from network layer >> access controls and using user authentication over TLS, so-called >> BeyondCorp model, including checking endpoint posture through management. > > I don’t think this solves the railroad case.  Do you?  Just to clarify > the example: > > According to their logs, two separate signals received  “set your lights > to green” at the same time, causing two trains to crash into each other. >  According to the signal controller’s logs, it sent “set your lights to > green” to only one signal.  What happened? > > All of the cases we are discussing have slightly different flavors of > threats.  From an IAB program standpoint, the real question here is > this: what are the architectural building blocks that are required? >  Keep in mind, some of those blocks could be code and some could be policy. > > One goal should be code reuse. It is probably best that the people > building the train signal *not* reinvent everything, but rather benefit > as much as they can from the experience and results that you, EKR, and a > great many other people have brought to society. > > Eliot > > (*) It’s also important to not fall into old tribal communication > patterns, while recognizing the realities of the concerns raised by you, > Watson, and me. > > From nobody Tue Jan 28 08:21:01 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E411D120A14; Tue, 28 Jan 2020 08:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdvSTlfS1Jyp; Tue, 28 Jan 2020 08:20:53 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0055120A06; Tue, 28 Jan 2020 08:20:53 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1iwTbe-000Ico-Hz; Tue, 28 Jan 2020 11:20:50 -0500 Date: Tue, 28 Jan 2020 11:20:45 -0500 From: John C Klensin To: "Joel M. Halpern" , Eliot Lear cc: architecture-discuss@ietf.org, model-t@iab.org Message-ID: <78E09CC1706F7D66D5F8DE1E@PSB> In-Reply-To: <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 16:20:56 -0000 --On Tuesday, January 28, 2020 10:16 -0500 "Joel M. Halpern" wrote: > I am a bit concerned by the emphasis on what appear to be > application policy, business policy, or government policy. To > the degree that these are decoupled from the technology we > define, my impression is that the IETF is neither skilled at > nor influential with regard to these topics. We can spend a > lot of time and energy on them. They are interesting topics. > But are they really our business? Joel, I've been trying, not very successfully, to follow this very lively discussion, but two observations which I hope are not out of context: (1) I think that "neither skilled nor influential ... [and therefore] not our business" leads us down a path whose destination is irrelevancy. Even for link encryption (and perhaps more so when the scope is broadened), we should probably recognize that mounting pressures from law enforcement (both associated with governments some of us like if they like any governments at all and those they don't like or who are viewed with more suspicion) could easily lead to regulations for government access to keys or other backdoors or even to outright bans on public use of cryptography. Even noting that arguments from the technical community had major influence on killing the Clipper Chip effort and that making those arguments was very far from "not our business", it seems to me that good engineering requires that we not put our heads in the sand and pretend that the world is different then it actually is or might be becoming when we design protocols. In particular, that may mean that, in some places, we should be writing specifications less in terms of "if you want to have privacy, you MUST do X" and more in terms of "...SHOULD do X unless that is not feasible but, if it isn't, then the fallback approach SHOULD include Y and Z". In the real world, "feasible" may include political of other constraints, not just constraints imposed by physics. We may not always be able to figure out good alternatives to our preferred recommendations, but I suggest that making a balanced and good faith effort to understand the problems and the environments in which we expect our protocols will be used will lead to better design even when we don't have good solutions. Or, to put it more negatively, if we fail to understand and try to account for those environments, we risk being put in a position in which _we_ are the ones responsible for Internet fragmentation and/or for protocol work moving to bodies other than the IETF because regulators make conforming implementations of IETF protocols illegal or commercial firms discover that conforming implementations cannot be developed and sold. (2) If I correctly understand the issues that Eliot, Watson, and Kathleen are exploring, the key involves the rather classic security issues of authorization and authentication --who should have access to particular information and how do we tell they are who they claim to be? In a way, maintaining and enforcing a non-trivial list of authorized parties but keeping everyone and everything else out (the example of some doctors and the patients themselves is very helpful for thinking about this) is a lot harder than keeping everyone out except those who control the endpoints (whatever that means). But most of that problem is technical and, if we don't have the expertise (I'm tempted to say "any more") that is a problem for us. In both cases, it seems to me that an IAB Program (or at least one or more serious workshops) are exactly the right model for addressing these problems for at least two reasons: The IAB is in a much better position than, say, an IETF WG, to recruit specific expertise to cover perspectives and areas of expertise that are not widely available in the IETF. It is also perfectly reasonable for such a program to produce recommendations about issues that need to be considered even if they have no good solutions or even if they are convinced that there are no solutions out there. I can only hope that the IAB will hold itself to a very high standard of including multiple perspectives (even perspectives with which IAB members and their perception of IETF consensus are in significant disagreement) and a broad range of expertise in the Program and that the community will hold the IAB accountable if they do not. If the way the IAB were to recruit Program members involved asking for volunteers from within the IETF community and then further narrowing the Program's perspective by selecting people from among those volunteers who agreed with the IAB's own views, the Program would likely be a waste of time or worse. john From nobody Tue Jan 28 08:50:45 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C291200D7 for ; Tue, 28 Jan 2020 08:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvBlAGbQNMrJ for ; Tue, 28 Jan 2020 08:50:40 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 14DD71200DE for ; Tue, 28 Jan 2020 08:50:39 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id l136so10981114oig.1 for ; Tue, 28 Jan 2020 08:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SRb/egMzVdOTxvAMMVZoAOxEQLeBQjT63w6Pj3H8Guo=; b=XnA3rOpEGlLCGxJ5LizuYC9Lo5NSGdCUXxsA3Qix+cv5cEzXVOozZCZ1jAEQt8vf3W yFEuOY4vQCapEgyhc83YbNYEE+c/ooDVK5CFul6eX9y8w4nYv4g4ouRrUEhxRlW1+y0J 2WeIZn5VVQw06Pwso/qRLGePsqJOYEgleTgTDIFL0ARs0XT8zBbLc3lNOkPsJA/rAoUt XWi0IftufhKlK3c+PBej8ANiU4A2XIIrRDvOuGp8GaBj3fROxs1ySVhSUE3lqkgWbcdZ U6FSzyEf9L1AZh/PWWGH6poPSSscwjLNbZkj48Awda1eJaR621XtyKPk1tEbhrCP8cN5 QQkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SRb/egMzVdOTxvAMMVZoAOxEQLeBQjT63w6Pj3H8Guo=; b=dKH6+SsWNkqiloS3SN73WDesxIokJbMhDK9owU6R1VbOPTUR17LKpbjsmDYm8F//e+ hV39DfbDo6+XcNdscVa4R07/hIxLXMebyIYGScFipFRM48OpK0/tqaXR5eYxMFpzyrWr ZdN7pkdxVbKakN0kmsQn+X/x1iPdPPHmXAWOZkK6XeuhCs9XC8yE0zpcEXYUkLqU3vsM mPapT8fuB47DGCWR9El+czkj/Wwjq5q6rxjmHnkHnAUL9A8JRBjmqKWHMbVYAtKC5I/U 9uojrUM9OEF8nLx8PKFfYuNwinzf2hj7+ydNKXicanDjcrP5pcojMkQqH7YndaEXxPVl whag== X-Gm-Message-State: APjAAAVHTjyfI7ZktnikUoWWGkkmf8KrAC7LVuWmQuxrzPZ+Dq8LcesI INzKZ8+7Jmu6lCOa1ftPQ+DYo58PSZsqlwslhhfuXZCb X-Google-Smtp-Source: APXvYqy6X86IIaM+SILpTaPA+OKTKBuvjt+BffdwCRvFwRG89+3u+UaR3r8hOJq09opRgLdLPqNconSXtD0D5Jtgubg= X-Received: by 2002:a54:4f04:: with SMTP id e4mr3268167oiy.111.1580230238340; Tue, 28 Jan 2020 08:50:38 -0800 (PST) MIME-Version: 1.0 References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> <78E09CC1706F7D66D5F8DE1E@PSB> In-Reply-To: <78E09CC1706F7D66D5F8DE1E@PSB> From: Kathleen Moriarty Date: Tue, 28 Jan 2020 11:50:02 -0500 Message-ID: To: John C Klensin Cc: "Joel M. Halpern" , Eliot Lear , architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="000000000000050a88059d3606a6" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 16:50:43 -0000 --000000000000050a88059d3606a6 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 28, 2020 at 11:21 AM John C Klensin wrote: > > > --On Tuesday, January 28, 2020 10:16 -0500 "Joel M. Halpern" > wrote: > > > I am a bit concerned by the emphasis on what appear to be > > application policy, business policy, or government policy. To > > the degree that these are decoupled from the technology we > > define, my impression is that the IETF is neither skilled at > > nor influential with regard to these topics. We can spend a > > lot of time and energy on them. They are interesting topics. > > But are they really our business? > > Joel, > > I've been trying, not very successfully, to follow this very > lively discussion, but two observations which I hope are not out > of context: > > (1) I think that "neither skilled nor influential ... [and > therefore] not our business" leads us down a path whose > destination is irrelevancy. Even for link encryption (and > perhaps more so when the scope is broadened), we should probably > recognize that mounting pressures from law enforcement (both > associated with governments some of us like if they like any > governments at all and those they don't like or who are viewed > with more suspicion) could easily lead to regulations for > government access to keys or other backdoors or even to outright > bans on public use of cryptography. Even noting that arguments > from the technical community had major influence on killing the > Clipper Chip effort and that making those arguments was very far > from "not our business", it seems to me that good engineering > requires that we not put our heads in the sand and pretend that > the world is different then it actually is or might be becoming > when we design protocols. In particular, that may mean that, > in some places, we should be writing specifications less in > terms of "if you want to have privacy, you MUST do X" and more > in terms of "...SHOULD do X unless that is not feasible but, if > it isn't, then the fallback approach SHOULD include Y and Z". > In the real world, "feasible" may include political of other > constraints, not just constraints imposed by physics. We may > not always be able to figure out good alternatives to our > preferred recommendations, but I suggest that making a balanced > and good faith effort to understand the problems and the > environments in which we expect our protocols will be used will > lead to better design even when we don't have good solutions. > > Or, to put it more negatively, if we fail to understand and try > to account for those environments, we risk being put in a > position in which _we_ are the ones responsible for Internet > fragmentation and/or for protocol work moving to bodies other > than the IETF because regulators make conforming implementations > of IETF protocols illegal or commercial firms discover that > conforming implementations cannot be developed and sold. > > (2) If I correctly understand the issues that Eliot, Watson, and > Kathleen are exploring, the key involves the rather classic > security issues of authorization and authentication --who should > have access to particular information and how do we tell they > are who they claim to be? In a way, maintaining and enforcing a > non-trivial list of authorized parties but keeping everyone and > everything else out (the example of some doctors and the > patients themselves is very helpful for thinking about this) is > a lot harder than keeping everyone out except those who control > the endpoints (whatever that means). But most of that problem > is technical and, if we don't have the expertise (I'm tempted to > say "any more") that is a problem for us. > A number with expertise in this area are engaged in the SACM, RATS, TEEP, and SUIT working groups. More were starting to come for SMART, but that was shutdown. Personally, I think engaging those who have expertise in this area is important and some draft authors who came for SMART should be engaged. They are on the front lines of malware and other system level attacks. Best regards, Kathleen > In both cases, it seems to me that an IAB Program (or at least > one or more serious workshops) are exactly the right model for > addressing these problems for at least two reasons: The IAB is > in a much better position than, say, an IETF WG, to recruit > specific expertise to cover perspectives and areas of expertise > that are not widely available in the IETF. It is also perfectly > reasonable for such a program to produce recommendations about > issues that need to be considered even if they have no good > solutions or even if they are convinced that there are no > solutions out there. I can only hope that the IAB will hold > itself to a very high standard of including multiple > perspectives (even perspectives with which IAB members and their > perception of IETF consensus are in significant disagreement) > and a broad range of expertise in the Program and that the > community will hold the IAB accountable if they do not. If the > way the IAB were to recruit Program members involved asking for > volunteers from within the IETF community and then further > narrowing the Program's perspective by selecting people from > among those volunteers who agreed with the IAB's own views, the > Program would likely be a waste of time or worse. > > john > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > -- Best regards, Kathleen --000000000000050a88059d3606a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 28, 2020 at 11:21 AM John= C Klensin <john-ietf@jck.com&g= t; wrote:


--On Tuesday, January 28, 2020 10:16 -0500 "Joel M. Halpern"
<jmh@joelhalper= n.com> wrote:

> I am a bit concerned by the emphasis on what appear to be
> application policy, business policy, or government policy.=C2=A0 To > the degree that these are decoupled from the technology we
> define, my impression is that the IETF is neither skilled at
> nor influential with regard to these topics. We can spend a
> lot of time and energy on them.=C2=A0 They are interesting topics.
> But are they really our business?

Joel,

I've been trying, not very successfully, to follow this very
lively discussion, but two observations which I hope are not out
of context:

(1) I think that "neither skilled nor influential ... [and
therefore] not our business" leads us down a path whose
destination is irrelevancy.=C2=A0 Even for link encryption (and
perhaps more so when the scope is broadened), we should probably
recognize that mounting pressures from law enforcement (both
associated with governments some of us like if they like any
governments at all and those they don't like or who are viewed
with more suspicion) could easily lead to regulations for
government access to keys or other backdoors or even to outright
bans on public use of cryptography.=C2=A0 Even noting that arguments
from the technical community had major influence on killing the
Clipper Chip effort and that making those arguments was very far
from "not our business", it seems to me that good engineering
requires that we not put our heads in the sand and pretend that
the world is different then it actually is or might be becoming
when we design protocols.=C2=A0 =C2=A0In particular, that may mean that, in some places, we should be writing specifications less in
terms of "if you want to have privacy, you MUST do X" and more in terms of "...SHOULD do X unless that is not feasible but, if
it isn't, then the fallback approach SHOULD include Y and Z".
In the real world, "feasible" may include political of other
constraints, not just constraints imposed by physics.=C2=A0 We may
not always be able to figure out good alternatives to our
preferred recommendations, but I suggest that making a balanced
and good faith effort to understand the problems and the
environments in which we expect our protocols will be used will
lead to better design even when we don't have good solutions.=C2=A0
Or, to put it more negatively, if we fail to understand and try
to account for those environments, we risk being put in a
position in which _we_ are the ones responsible for Internet
fragmentation and/or for protocol work moving to bodies other
than the IETF because regulators make conforming implementations
of IETF protocols illegal or commercial firms discover that
conforming implementations cannot be developed and sold.

(2) If I correctly understand the issues that Eliot, Watson, and
Kathleen are exploring, the key involves the rather classic
security issues of authorization and authentication --who should
have access to particular information and how do we tell they
are who they claim to be?=C2=A0 In a way, maintaining and enforcing a
non-trivial list of authorized parties but keeping everyone and
everything else out (the example of some doctors and the
patients themselves is very helpful for thinking about this) is
a lot harder than keeping everyone out except those who control
the endpoints (whatever that means).=C2=A0 =C2=A0But most of that problem is technical and, if we don't have the expertise (I'm tempted to say "any more") that is a problem for us.
A number with expertise in this area are engaged in the SACM, = RATS, TEEP, and SUIT working groups.=C2=A0 More were starting to come for S= MART, but that was shutdown.=C2=A0 Personally, I think engaging those who h= ave expertise in this area is important and some draft authors who came for= SMART should be engaged.=C2=A0 They are on the front lines of malware and = other system level attacks.

Best regards,
Kathleen


In both cases, it seems to me that an IAB Program (or at least
one or more serious workshops) are exactly the right model for
addressing these problems for at least two reasons:=C2=A0 The IAB is
in a much better position than, say, an IETF WG, to recruit
specific expertise to cover perspectives and areas of expertise
that are not widely available in the IETF.=C2=A0 It is also perfectly
reasonable for such a program to produce recommendations about
issues that need to be considered even if they have no good
solutions or even if they are convinced that there are no
solutions out there.=C2=A0 I can only hope that the IAB will hold
itself to a very high standard of including multiple
perspectives (even perspectives with which IAB members and their
perception of IETF consensus are in significant disagreement)
and a broad range of expertise in the Program and that the
community will hold the IAB accountable if they do not.=C2=A0 If the
way the IAB were to recruit Program members involved asking for
volunteers from within the IETF community and then further
narrowing the Program's perspective by selecting people from
among those volunteers who agreed with the IAB's own views, the
Program would likely be a waste of time or worse.

=C2=A0 =C2=A0 john

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss


--

Best regards,
Kathleen
--000000000000050a88059d3606a6-- From nobody Tue Jan 28 10:46:38 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E731F12003F for ; Tue, 28 Jan 2020 10:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HK_SCAM=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSZ0bVDC_Kgm for ; Tue, 28 Jan 2020 10:46:35 -0800 (PST) Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) (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 8DC9C120033 for ; Tue, 28 Jan 2020 10:46:35 -0800 (PST) Received: by mail-pj1-x1042.google.com with SMTP id gv17so1506882pjb.1 for ; Tue, 28 Jan 2020 10:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0SrB4nT6nvVgikt51fyxXvGZBYxHZY3MRaweNo0Zyto=; b=ce1X36c1m/BCYnbO2YGeW5Vll7NhcxbVtDj6ExZsF13yviF1KA0bv5VRfummhklHcH CU8i9Zuz9Cd7dmc5souq3YYmev4S2rTpfdim8prE587E7faw/iYfQbJSXrQoDn+b+QsV IWy8wRlXoC3vz66Chi3cjKtoVGYVAReJshgn03LCOmlogLHWdzR2oWqQuYAu2RQFJpRV vEL6uNh5VBbP6tv0aBEyrf5AnvwO9/SBB6l+SEomci6UEMtPzfYHtzHs34rRgJ+DmlUm n+vZIcZk9kBYRUXyF1Af3SI//PsvlEy9B04I782qy33zUDlB/krqzMYz9XTbLQXpM4ip pVdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0SrB4nT6nvVgikt51fyxXvGZBYxHZY3MRaweNo0Zyto=; b=M5NYASeNyIuxsR8cRSiqu65JX26ZJi1rIwC3rhf7cJTdTUeGkml3QENjT9X+nwlUhs ovRPX29WA4qcvsUqJoe2OfGaT1al3rnbhetrTbyYDFQPO2S8FBI8NZGhRukwmv9vzZpj IiP895wd1R3qQcZUtXjhAi+/6UwH9oC8r0BBSU55QyP2sNRA1iHNrL7pYHgelBZ7AKdC vk3sqbueanBVanOWHtT+7p+CfufzXpzq93BFQre5WGIyWWI5JWlDeWdbRp8s3H0PN1gX H1nfosHLeLt19/o71mzQQeHjpWBUCT6J2jKVYpKys3v84aX3PMo4AXKeukeGFmviK2I3 ix7Q== X-Gm-Message-State: APjAAAW3oS2ztwVQfqTe2SQzQXExNfy+HIoJi/0Om9cXhJcHyKbUHNKV 4Gdr1Rxv4765AZROQOT3/Whv7VUW X-Google-Smtp-Source: APXvYqynwVjckXfblZmG9skSugL53pDbqHTVUMN56FW40SXdwE25Tzfc6G8liP2mTgPCStWHK51y2w== X-Received: by 2002:a17:90a:8a08:: with SMTP id w8mr6338953pjn.125.1580237194672; Tue, 28 Jan 2020 10:46:34 -0800 (PST) Received: from [10.1.2.245] ([43.251.155.206]) by smtp.gmail.com with ESMTPSA id i127sm21165952pfe.54.2020.01.28.10.46.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jan 2020 10:46:34 -0800 (PST) To: "Joel M. Halpern" , Eliot Lear Cc: architecture-discuss@ietf.org, model-t@iab.org References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6d587cdf-5d93-2c38-0160-ddd2a41a5c41@gmail.com> Date: Wed, 29 Jan 2020 07:46:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 18:46:37 -0000 On 29-Jan-20 04:16, Joel M. Halpern wrote: > I am a bit concerned by the emphasis on what appear to be application=20 > policy, business policy, or government policy. To the degree that thes= e=20 > are decoupled from the technology we define, my impression is that the = > IETF is neither skilled at nor influential with regard to these topics.= =20 > We can spend a lot of time and energy on them. They are interesting=20 > topics. But are they really our business? Joel, I think they are part of the threat model (exactly as we have argue= d in RFC1984, RFC2804 and RFC7258). In that sense they are absolutely our b= usiness. Just in the last few days, key escrow has been back in the news, for exam= ple. Ultimately, technology influences policy, so our choices are not without impact. Regards Brian >=20 > Yours, > Joel >=20 > On 1/28/2020 1:44 AM, Eliot Lear wrote: >> Hi Watson, >> >>> On 28 Jan 2020, at 02:35, Watson Ladd >> > wrote: >>> >>> >>> >>> On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear >> > wrote: >>> >>> =C2=A0 Let=E2=80=99s look at three specific examples that I=E2=80= =99ve mentioned: >>> >>> 1.=C2=A0 Train signaling system needs to be audited both live and= >>> retrospectively in the case of accidents.=C2=A0 This has to happe= n in >>> such a way that the auditor sees precisely what was sent by one >>> endpoint and received by the other. >>> >>> 2.=C2=A0 The case of =E2=80=9Cparent doesn=E2=80=99t want Interne= t toy to send video of >>> child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s an a= nalog to the >>> privacy analysis on Alexa[1] and the now infamous NEST episode[2]= ). >>> >>> 3. CPAP machine or an AED/pace maker provide a control interface >>> to the doctor but the patient or his next of kin wants the data. >>> >>> >>> I've got a few more examples from real life: >>> >>> 4: We need to see who is sending pictures of Winnie the Pooh. >>> >>> 5: We don't want pictures of the inside of our detention centers to=20 >>> appear online. >>> >>> 6: I want to see everyone's credit card number at the coffee shop I r= un. >>> >>> Any discussion of tapping network communications because endpoints=20 >>> can't be trusted needs to take these cases seriously.=20 >> >> >> Absolutely. =C2=A0What I am suggesting is a relatively new twist on an= old=20 >> problem(*). =C2=A0It=E2=80=99s important to understand the economic an= d policy=20 >> aspects of how/whether to avoid [4] and [5], how to avoid [6] while at= =20 >> the same time addressing use cases I mentioned. >> >> So=E2=80=A6 today=E2=80=99s new information comes courtesy of the EFF.= >> >> https://www.eff.org/deeplinks/2020/01/ring-doorbell-app-packed-third-p= arty-trackers >> >> Here we have yet another IoT device that, from at least one person=E2=80= =99s=20 >> perspective is invading home privacy. =C2=A0And again, it is the devic= e=20 >> itself that is the threat. =C2=A0In this case, it=E2=80=99s probably a= more=20 >> manageable threat, because one can simply not get a NEST. =C2=A0Try no= t=20 >> getting a CPAP machine. >> >> And this brings us around to what layer to solve the problem at. =C2=A0= Some=20 >> of this may need to be dealt with at layer 9 rather than at lower=20 >> layers. =C2=A0We should have that discussion too. >> >> >>> >>> Increasingly corporate networks are moving away from network layer=20 >>> access controls and using user authentication over TLS, so-called=20 >>> BeyondCorp model, including checking endpoint posture through managem= ent. >> >> I don=E2=80=99t think this solves the railroad case. =C2=A0Do you? =C2= =A0Just to clarify=20 >> the example: >> >> According to their logs, two separate signals received =C2=A0=E2=80=9C= set your lights=20 >> to green=E2=80=9D at the same time, causing two trains to crash into e= ach other.=20 >> =C2=A0According to the signal controller=E2=80=99s logs, it sent =E2=80= =9Cset your lights to=20 >> green=E2=80=9D to only one signal. =C2=A0What happened? >> >> All of the cases we are discussing have slightly different flavors of = >> threats. =C2=A0From an IAB program standpoint, the real question here = is=20 >> this: what are the architectural building blocks that are required?=20 >> =C2=A0Keep in mind, some of those blocks could be code and some could= be policy. >> >> One goal should be code reuse. It is probably best that the people=20 >> building the train signal *not* reinvent everything, but rather benefi= t=20 >> as much as they can from the experience and results that you, EKR, and= a=20 >> great many other people have brought to society. >> >> Eliot >> >> (*) It=E2=80=99s also important to not fall into old tribal communicat= ion=20 >> patterns, while recognizing the realities of the concerns raised by yo= u,=20 >> Watson, and me. >> >> >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Tue Jan 28 11:23:16 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C79120047 for ; Tue, 28 Jan 2020 11:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGIOVZ99dkWC for ; Tue, 28 Jan 2020 11:23:11 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1134A120044 for ; Tue, 28 Jan 2020 11:23:10 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2D00454804A; Tue, 28 Jan 2020 20:23:05 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 26E0B440059; Tue, 28 Jan 2020 20:23:05 +0100 (CET) Date: Tue, 28 Jan 2020 20:23:05 +0100 From: Toerless Eckert To: Stephen Farrell Cc: Eliot Lear , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org Message-ID: <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Model-t] [arch-d] not building blocks (was: Re: Possible new IAB program on Internet trust model evolution) X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 19:23:14 -0000 Stephen, I totally do not get how you read Eliots text as being about TLS. I read Eliot/Watsons mails to be in the same direction as what i was pointing out yesterday. Let me try to abstract maybe better: In the past, we have primarily looked at the security implications of individual protocols, communicating mostly between two endpoints and attacks against this communication by observers, MitM, or malicious endpoints. Of course, we went beyond that but not systematically to the point that instead of concentrating only on the communication channels, we would instead concentrate also on the properties of modules whose complete external behavior is defined through a set of interfaces. And then define security properties observing that superset of interfaces. Once you have this model, Watson/Eliots examples are easy translated into propagation properties between these interfaes. My yesterdays mail points was more about the problem of having modules that are small enough or implemented in a way that at least specific properties can be verified instead of just having to trust the module vendor. Or having interfaces that allows another module to verify/control behavior. Of course, the fun difference with this model is that in the most simple of cases, you could try to view a complete router as one of those modules, because vendors of such gear have a great interest to well define and expose all interfaces of such a device, wheras a typical communications endpoint such as an application server in a data-center is more often than not built around a business model where exposure/ definition of all interfaces would expose bad business practices. Hence also political approaches like GDPR to start addressing that problem. Cheers Toerless On Tue, Jan 28, 2020 at 10:02:43AM +0000, Stephen Farrell wrote: > > Hiya, > > On 28/01/2020 06:44, Eliot Lear wrote: > > From an IAB program standpoint, the real question here is this: what > > are the architectural building blocks that are required? > I'm not sure I agree. ISTM you envisage a programme that > tries to establish that existing IETF consensus as to the > use of e2e encryption needs to be changed, which I don't > think is a goal here. Personally, I think of this as a > place to work on whether or not it's possible to extend > (not replace) the 3552 threat model to cater for changes > since 3552 was written. (I do think that's an interesting > question and it's unclear to me if the answer is "yes" or > "would like to, but it's not usefully feasible.") > > Now, it's of course valid to point out that comsec (as > ekr may put it) if applied e2e doesn't by itself meet > all requirements stated in your examples, to which I'd > maybe argue to extend the Internet threat model with > some statement along the lines of: "if an endpoint > does need to see traffic content or significant meta- > data, then you need to design your protocol so that that > endpoint is an endpoint at which relevant cryptographic > mechanisms are validly terminated, according to the > expectations of the cryptographic protocol(s) in use (e.g. > TLS, IPsec). Changing the security properties of widely > deployed cryptographic protocols is not likely to be a > useful approach to attempt, as there are too many > deleterious side-effects of such proposed changes." > > So I don't think, for the purposes of this exercise, > we're considering existing widely deployed protocols as > malleable building blocks, whether that protocol is > TLS or some (deployed) train signalling system. > > Cheers, > S. > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) > sub RSA 4096/36CB8BB6 2017-12-22 > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Tue Jan 28 11:33:59 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC2312006B for ; Tue, 28 Jan 2020 11:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 vf4fwvXAYgzW for ; Tue, 28 Jan 2020 11:33:55 -0800 (PST) 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 6B793120059 for ; Tue, 28 Jan 2020 11:33:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 34CF6BE39; Tue, 28 Jan 2020 19:33:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 vB9iCe6W59HG; Tue, 28 Jan 2020 19:33:51 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F837BE2E; Tue, 28 Jan 2020 19:33:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1580240031; bh=gNIaoq2gQPozLAH1XZUrLMf6mRLk6DXGkQwNndQjBi4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OXRA3mvv6LdK8PeDyyHRMCKH35du0a3PyicGxWG/XMBj4JyIaxoPAGMhwbiyM9Yex Yb3c90C6j8dRp6u5M1YjmASb/LoYjxTmwtMfL3Qo0NO5sBFrZEaUHz2yitmh6bUViI vlQ6jBV8zukAm8rsHExAaO3qD0yJE2T+4eGsQ3NY= To: Kathleen Moriarty , John C Klensin Cc: model-t@iab.org, architecture-discuss@ietf.org References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> <78E09CC1706F7D66D5F8DE1E@PSB> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <9cec50fa-cb7c-ef75-95b3-c85f9f255c6d@cs.tcd.ie> Date: Tue, 28 Jan 2020 19:33:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Yl1LipH1FYBCGBTpZ0kDSSYYMp1HPIyQf" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet threat model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 19:33:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Yl1LipH1FYBCGBTpZ0kDSSYYMp1HPIyQf Content-Type: multipart/mixed; boundary="DAzfZbsTA95unbNNEUI7pK2PiaWMgf1L9"; protected-headers="v1" From: Stephen Farrell To: Kathleen Moriarty , John C Klensin Cc: model-t@iab.org, architecture-discuss@ietf.org Message-ID: <9cec50fa-cb7c-ef75-95b3-c85f9f255c6d@cs.tcd.ie> Subject: Re: [arch-d] [Model-t] Possible new IAB program on Internet threat model evolution References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> <78E09CC1706F7D66D5F8DE1E@PSB> In-Reply-To: --DAzfZbsTA95unbNNEUI7pK2PiaWMgf1L9 Content-Type: multipart/mixed; boundary="------------5F55455BB80CAAD27DFAE213" Content-Language: en-US This is a multi-part message in MIME format. --------------5F55455BB80CAAD27DFAE213 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John, Kathleen, Just on comments related to participation: "Participation in this program is open to all interested parties, and considered analysis of diverse inputs is important" is what [1] already says. If you think some rewording is needed be good to know what, or if it's just a case of that text not having been noticed, then we're good I guess. Cheers, S. PS: I fixed the typo in the subject line that was my fault in the first place:-) [1] https://github.com/intarchboard/model-t-charter/blob/master/model-t-chart= er-00.md --------------5F55455BB80CAAD27DFAE213 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------5F55455BB80CAAD27DFAE213-- --DAzfZbsTA95unbNNEUI7pK2PiaWMgf1L9-- --Yl1LipH1FYBCGBTpZ0kDSSYYMp1HPIyQf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4wjJ4ACgkQWrL68XsX K+rJCA/+NVGfNeVb2hSTBYXt0VxAV/9NVqGOVZ8aEJThfplAf8fa49Y6h3K0DoPc zeLFv9Oq4CXlbVdMtI+YlmKAS99gNyQjzcM0npby2l5PqTmW1D0jzDCLT5YozDvL v+juAg26s+m2hTaXmqq1P1geQ6tT+g2uETBNQRQ6oeXciQ8slyRmWo77gdNU33Tn IpmQokAO5T51HSNX9oUPI8bZKscw2R0LbHq2oEI9Q7h6XYqB+viLxlMv/ama1J94 qACANiZxGKi+KzvsJGd28MHbq5h4ImI4712mdgqIbCBs7jsbH+a4soUNvIvBqB92 7LPtI5TCFJ7vH2XCAVsm7NzPfdG+sho6vrTKnUnmAEOvx+7IjuWJ2xP6o6oycadf L9zUZY90KtyM/LTZfAvUMgwkLJQ8/Jmb9YFjxpZDCrmIs4k+KcorrJQXtD4Ht8RF dqSkSmk3Km9rNvrdCECmz24U/SbcX+gtFFrQPM6sjyTOrS/pFJNTDstW85oa4MQW 6p11JvuoGQTe/h//YosijsE69tDgKM2q6eekI47OShHFxkYG0R9JaSpyV8ZSblq/ +V9F9ktTWUjxKFYeWVr5b8zNicm880V7MKSTg7aPfv51yhoqs8SvSWEuQEKmKIb8 O5MSeKM5yJzUrlHcXmL0iF+LJ4pRV0ye+ZN2EqOhXMi7iQNk3CU= =PVri -----END PGP SIGNATURE----- --Yl1LipH1FYBCGBTpZ0kDSSYYMp1HPIyQf-- From nobody Tue Jan 28 11:39:22 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37ACF120044 for ; Tue, 28 Jan 2020 11:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 2D3hMUyDuRQp for ; Tue, 28 Jan 2020 11:39:17 -0800 (PST) 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 E7DAA120024 for ; Tue, 28 Jan 2020 11:39:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1BF47BE20; Tue, 28 Jan 2020 19:39:15 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 uj_TMlJ7erSR; Tue, 28 Jan 2020 19:39:12 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A01B3BDCF; Tue, 28 Jan 2020 19:39:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1580240352; bh=Wg2AcaYs3/k4+9JtzMGkjUwQnIl+FEqaRz80j5n1O3U=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=sPnWa5HvTyPPdIb/6nRwQ5yWTJwjkwPyEPPa8qr+HhiKPEPqHDN6isP6bdZtBfdET Xkcm2Ssldc6ddlzbaxQVgus/UN9I1iLKgWdLNV2uAiabpsvVyAH29H8cSHJzUGIcTr NMAPrU5ZHaJXI6ENiRuY2496ekalQp5wHgF8xMRM= To: Toerless Eckert Cc: Eliot Lear , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Tue, 28 Jan 2020 19:39:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rdtr0Cl7sTrpaKKxkSDxvIXIPgwQbLbqN" Archived-At: Subject: Re: [Model-t] [arch-d] not building blocks (was: Re: Possible new IAB program on Internet trust model evolution) X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 19:39:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rdtr0Cl7sTrpaKKxkSDxvIXIPgwQbLbqN Content-Type: multipart/mixed; boundary="8DFszHmDSUM9b2H8Y4iU2G4vLrfG2QUhj"; protected-headers="v1" From: Stephen Farrell To: Toerless Eckert Cc: Eliot Lear , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org Message-ID: Subject: Re: [arch-d] not building blocks (was: Re: [Model-t] Possible new IAB program on Internet trust model evolution) References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> --8DFszHmDSUM9b2H8Y4iU2G4vLrfG2QUhj Content-Type: multipart/mixed; boundary="------------C20916BFF6EC90EF4FE22867" Content-Language: en-US This is a multi-part message in MIME format. --------------C20916BFF6EC90EF4FE22867 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya Offlist for two reasons... On 28/01/2020 19:23, Toerless Eckert wrote: > Stephen, >=20 > I totally do not get how you read Eliots text as being about TLS. He and I have chatted about this before - one of the options he maybe like for his train example is a NULL encryption ciphersuite to be standardised/recommended (as opposed to defined) for TLS1.3. I think that'd be a bad plan. >=20 > I read Eliot/Watsons mails to be in the same direction as what i was > pointing out yesterday. 2nd reason for offlist is that I'm not getting what you mean below, but I'm pushed for time right now, so maybe reading it later will make it clear;-) In any case, it'll be a while 'till I get to respond, sorry. Cheers, S. >=20 > Let me try to abstract maybe better: >=20 > In the past, we have primarily looked at the security implications > of individual protocols, communicating mostly between two endpoints > and attacks against this communication by observers, MitM, or > malicious endpoints. >=20 > Of course, we went beyond that but not systematically to the point that= > instead of concentrating only on the communication channels, we would > instead concentrate also on the properties of modules whose complete > external behavior is defined through a set of interfaces. And then > define security properties observing that superset of interfaces. >=20 > Once you have this model, Watson/Eliots examples are easy translated > into propagation properties between these interfaes. >=20 > My yesterdays mail points was more about the problem of having > modules that are small enough or implemented in a way that at > least specific properties can be verified instead of just having to > trust the module vendor. Or having interfaces that allows another > module to verify/control behavior.=20 >=20 > Of course, the fun difference with this model is that in the most > simple of cases, you could try to view a complete router as one > of those modules, because vendors of such gear have a great interest > to well define and expose all interfaces of such a device, wheras a typ= ical > communications endpoint such as an application server in a data-center > is more often than not built around a business model where exposure/ > definition of all interfaces would expose bad business practices. > Hence also political approaches like GDPR to start addressing > that problem. >=20 > Cheers > Toerless >=20 > On Tue, Jan 28, 2020 at 10:02:43AM +0000, Stephen Farrell wrote: >> >> Hiya, >> >> On 28/01/2020 06:44, Eliot Lear wrote: >>> From an IAB program standpoint, the real question here is this: what >>> are the architectural building blocks that are required? >> I'm not sure I agree. ISTM you envisage a programme that >> tries to establish that existing IETF consensus as to the >> use of e2e encryption needs to be changed, which I don't >> think is a goal here. Personally, I think of this as a >> place to work on whether or not it's possible to extend >> (not replace) the 3552 threat model to cater for changes >> since 3552 was written. (I do think that's an interesting >> question and it's unclear to me if the answer is "yes" or >> "would like to, but it's not usefully feasible.") >> >> Now, it's of course valid to point out that comsec (as >> ekr may put it) if applied e2e doesn't by itself meet >> all requirements stated in your examples, to which I'd >> maybe argue to extend the Internet threat model with >> some statement along the lines of: "if an endpoint >> does need to see traffic content or significant meta- >> data, then you need to design your protocol so that that >> endpoint is an endpoint at which relevant cryptographic >> mechanisms are validly terminated, according to the >> expectations of the cryptographic protocol(s) in use (e.g. >> TLS, IPsec). Changing the security properties of widely >> deployed cryptographic protocols is not likely to be a >> useful approach to attempt, as there are too many >> deleterious side-effects of such proposed changes." >> >> So I don't think, for the purposes of this exercise, >> we're considering existing widely deployed protocols as >> malleable building blocks, whether that protocol is >> TLS or some (deployed) train signalling system. >> >> Cheers, >> S. >> >=20 > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) >> sub RSA 4096/36CB8BB6 2017-12-22 >> >=20 >=20 >=20 >=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 >=20 --------------C20916BFF6EC90EF4FE22867 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------C20916BFF6EC90EF4FE22867-- --8DFszHmDSUM9b2H8Y4iU2G4vLrfG2QUhj-- --rdtr0Cl7sTrpaKKxkSDxvIXIPgwQbLbqN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4wjeAACgkQWrL68XsX K+o0thAAkTDAwfnDUlG1IsLnk3ARqE0zIH04NUZ9uN+z5dzmIR1jQqyBEk1S32HE cExHvoRCt8a2ElqXz+xzdK2J5TUQ/JiHcNCyS45X7KrV+ANZ+kRSv9oWd7HBkoUf 1/jLTO8T5ahjp1IaYPTUGGrrwNRmCLSbclD+j6EP97k0FHft4yIC6LxdVIHuJCkI oh37dqDPfSBvkN3zHDt83/Pf4t2B++zVcOeney+IKyASLjFs5zQECZWIDIYc2ZHd nDYJNoqGTI3Ja72mgnD1yeXxAGEDdvm3cu7hsWDTUpI4Vb141axS3bVY8u2pBzDq 7urDES09pypweceP1FlLTSPj6TK3miCbMo7KobBetLWBiXy04tdsa8UmrBccEs1P tK1H+pn2pXmQtK9TwmEudwtaKqhdPcUrHPLltX6IOxDQstIozSaK2jtBxmUmqG0C VjPY4Tdbw8lNLfp9PIhIvnniLc7h0Gwfkbr5wJ5jlLdcQsHtcT9AKcZ+Wke8z/0D CVrC9ZAGMVAfBagxovxCfZ6R6/SzkvUy1zBmSUMESAUqKJmBgunlWHb9GNZgvF9R SgLNsytGLRMyqjDbHaeYE6CL4SRMVmwJjh5r/W2VUnKoqWvdQ9wAYxJ11VX+Mj3w 3BznhmAZk++xp91k1muSF4jN+J7KX1/slCPR0XB9UMO/DIqv3xQ= =CH4V -----END PGP SIGNATURE----- --rdtr0Cl7sTrpaKKxkSDxvIXIPgwQbLbqN-- From nobody Tue Jan 28 11:46:51 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5B1120024 for ; Tue, 28 Jan 2020 11:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEdcOUkOXBzC for ; Tue, 28 Jan 2020 11:46:42 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A12120033 for ; Tue, 28 Jan 2020 11:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29004; q=dns/txt; s=iport; t=1580240802; x=1581450402; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ALpnn1WB9+Q+BsQ3Ic7jr2bENzynhqpvCPJGH953nH4=; b=Z8vYlMT55XRXo3cTgl1TYQmX23NCV9iQUWK/TOy32bWf6TR4bHeXS2X8 p/NMoxlkv5OHI6UEgPHZpdZpMiYYq9LYBtxbvDyut+jwouWn7OBgKJofb ut3f9zISUq/tBK1c5+aWYq6mRe0lHnej5EgudPocBkj0fPwEudNyuKJO4 U=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAQBtjjBe/xbLJq1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4ElU4EddRIqhBSJA4g7hz2SFIFjBAIHAQEBCQMBARg?= =?us-ascii?q?BCgwBAYN7RQKCSjgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECAQEBIUsLBQs?= =?us-ascii?q?LEgYgAQIHAgInIg4GExuDCwGCWyAPrS11gTKFSoRxCgaBOIFTiSaBP4IAgRE?= =?us-ascii?q?nIIFOfj6CZAEBgSccAQEIgyYygiwEjg6JJpgkgkOCTIEckk8bgkiMT4tlpj+?= =?us-ascii?q?DLgIEBgUCFYFpIoFYMxoIGxU7KgGCQT4SGA2OVYhPhUBAAzCMAoIyAQE?= X-IronPort-AV: E=Sophos;i="5.70,375,1574121600"; d="asc'?scan'208,217";a="22644635" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jan 2020 19:46:39 +0000 Received: from ams3-vpn-dhcp4134.cisco.com (ams3-vpn-dhcp4134.cisco.com [10.61.80.37]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00SJkcsT030850 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jan 2020 19:46:39 GMT From: Eliot Lear Message-Id: <26E2222F-93B0-4E3C-9C4F-F75A119BB109@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_05435614-0E6D-4AF7-81F1-361A8ED88299"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 28 Jan 2020 20:46:38 +0100 In-Reply-To: Cc: Toerless Eckert , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org To: Stephen Farrell References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.80.37, ams3-vpn-dhcp4134.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Model-t] [arch-d] not building blocks (was: Re: Possible new IAB program on Internet trust model evolution) X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 19:46:46 -0000 --Apple-Mail=_05435614-0E6D-4AF7-81F1-361A8ED88299 Content-Type: multipart/alternative; boundary="Apple-Mail=_5E61AF67-2A6D-4568-9286-52AAC88F86FA" --Apple-Mail=_5E61AF67-2A6D-4568-9286-52AAC88F86FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Jan 2020, at 20:39, Stephen Farrell = wrote: >=20 >=20 > Hiya >=20 > Offlist for two reasons... >=20 > On 28/01/2020 19:23, Toerless Eckert wrote: >> Stephen, >>=20 >> I totally do not get how you read Eliots text as being about TLS. >=20 > He and I have chatted about this before - one of the > options he maybe like for his train example is a NULL > encryption ciphersuite to be standardised/recommended > (as opposed to defined) for TLS1.3. I think that'd be > a bad plan. That is not my preferred solution, Stephen. While industrial automation = doesn=E2=80=99t really require encryption for most uses, I don=E2=80=99t = think it can hurt, so long as the necessary auditing can take place. = Let=E2=80=99s focus on the problem first. If we can agree on that, then = let=E2=80=99s move on from there. Eliot >=20 >>=20 >> I read Eliot/Watsons mails to be in the same direction as what i was >> pointing out yesterday. >=20 > 2nd reason for offlist is that I'm not getting what you > mean below, but I'm pushed for time right now, so maybe > reading it later will make it clear;-) In any case, it'll > be a while 'till I get to respond, sorry. >=20 > Cheers, > S. >=20 >>=20 >> Let me try to abstract maybe better: >>=20 >> In the past, we have primarily looked at the security implications >> of individual protocols, communicating mostly between two endpoints >> and attacks against this communication by observers, MitM, or >> malicious endpoints. >>=20 >> Of course, we went beyond that but not systematically to the point = that >> instead of concentrating only on the communication channels, we would >> instead concentrate also on the properties of modules whose complete >> external behavior is defined through a set of interfaces. And then >> define security properties observing that superset of interfaces. >>=20 >> Once you have this model, Watson/Eliots examples are easy translated >> into propagation properties between these interfaes. >>=20 >> My yesterdays mail points was more about the problem of having >> modules that are small enough or implemented in a way that at >> least specific properties can be verified instead of just having to >> trust the module vendor. Or having interfaces that allows another >> module to verify/control behavior. >>=20 >> Of course, the fun difference with this model is that in the most >> simple of cases, you could try to view a complete router as one >> of those modules, because vendors of such gear have a great interest >> to well define and expose all interfaces of such a device, wheras a = typical >> communications endpoint such as an application server in a = data-center >> is more often than not built around a business model where exposure/ >> definition of all interfaces would expose bad business practices. >> Hence also political approaches like GDPR to start addressing >> that problem. >>=20 >> Cheers >> Toerless >>=20 >> On Tue, Jan 28, 2020 at 10:02:43AM +0000, Stephen Farrell wrote: >>>=20 >>> Hiya, >>>=20 >>> On 28/01/2020 06:44, Eliot Lear wrote: >>>> =46rom an IAB program standpoint, the real question here is this: = what >>>> are the architectural building blocks that are required? >>> I'm not sure I agree. ISTM you envisage a programme that >>> tries to establish that existing IETF consensus as to the >>> use of e2e encryption needs to be changed, which I don't >>> think is a goal here. Personally, I think of this as a >>> place to work on whether or not it's possible to extend >>> (not replace) the 3552 threat model to cater for changes >>> since 3552 was written. (I do think that's an interesting >>> question and it's unclear to me if the answer is "yes" or >>> "would like to, but it's not usefully feasible.") >>>=20 >>> Now, it's of course valid to point out that comsec (as >>> ekr may put it) if applied e2e doesn't by itself meet >>> all requirements stated in your examples, to which I'd >>> maybe argue to extend the Internet threat model with >>> some statement along the lines of: "if an endpoint >>> does need to see traffic content or significant meta- >>> data, then you need to design your protocol so that that >>> endpoint is an endpoint at which relevant cryptographic >>> mechanisms are validly terminated, according to the >>> expectations of the cryptographic protocol(s) in use (e.g. >>> TLS, IPsec). Changing the security properties of widely >>> deployed cryptographic protocols is not likely to be a >>> useful approach to attempt, as there are too many >>> deleterious side-effects of such proposed changes." >>>=20 >>> So I don't think, for the purposes of this exercise, >>> we're considering existing widely deployed protocols as >>> malleable building blocks, whether that protocol is >>> TLS or some (deployed) train signalling system. >>>=20 >>> Cheers, >>> S. >>>=20 >>=20 >> pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) = >>> sub RSA 4096/36CB8BB6 2017-12-22 >>>=20 >>=20 >>=20 >>=20 >>=20 >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>=20 >>=20 > <0x5AB2FAF17B172BEA.asc> --Apple-Mail=_5E61AF67-2A6D-4568-9286-52AAC88F86FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 28 Jan 2020, at 20:39, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya

Offlist for two = reasons...

On 28/01/2020 = 19:23, Toerless Eckert wrote:
Stephen,

I= totally do not get how you read Eliots text as being about TLS.

He and I have chatted about this before - one of = the
options he = maybe like for his train example is a NULL
encryption ciphersuite to be = standardised/recommended
(as opposed to defined) for TLS1.3. I think that'd = be
a bad = plan.

That is = not my preferred solution, Stephen.  While = industrial automation doesn=E2=80=99t really require encryption for most = uses, I don=E2=80=99t think it can hurt, so long as the necessary = auditing can take place.  Let=E2=80=99s focus on the problem first. =  If we can agree on that, then let=E2=80=99s move on from = there.

Eliot


I read Eliot/Watsons = mails to be in the same direction as what i was
pointing = out yesterday.

2nd reason for offlist is that I'm not getting what = you
mean below, = but I'm pushed for time right now, so maybe
reading it later will make it = clear;-) In any case, it'll
be a while 'till I get to respond, sorry.

Cheers,
S.


Let me try to abstract = maybe better:

In the past, we have = primarily looked at the security implications
of = individual protocols, communicating mostly between two endpoints
and attacks against this communication by observers, MitM, = or
malicious endpoints.

Of = course, we went beyond that but not systematically to the point that
instead of concentrating only on the communication channels, = we would
instead concentrate also on the properties of = modules whose complete
external behavior is defined = through a set of interfaces. And then
define security = properties observing that superset of interfaces.

Once you have this model, Watson/Eliots examples are easy = translated
into propagation properties between these = interfaes.

My yesterdays mail points was = more about the problem of having
modules that are small = enough or implemented in a way that at
least specific = properties can be verified instead of just having to
trust = the module vendor. Or having interfaces that allows another
module to verify/control behavior. 

Of course, the fun difference with this model is that in the = most
simple of cases, you could try to view a complete = router as one
of those modules, because vendors of such = gear have a great interest
to well define and expose all = interfaces of such a device, wheras a typical
communications= endpoint such as an application server in a data-center
is = more often than not built around a business model where exposure/
definition of all interfaces would expose bad business = practices.
Hence also political approaches like GDPR to = start addressing
that problem.

Cheers
   Toerless

On Tue, Jan 28, 2020 at 10:02:43AM +0000, = Stephen Farrell wrote:

Hiya,

On = 28/01/2020 06:44, Eliot Lear wrote:
=46rom an IAB program standpoint, the real = question here is this: what
are the architectural building = blocks that are required?
I'm not sure I = agree. ISTM you envisage a programme that
tries to = establish that existing IETF consensus as to the
use of = e2e encryption needs to be changed, which I don't
think is = a goal here. Personally, I think of this as a
place to = work on whether or not it's possible to extend
(not = replace) the 3552 threat model to cater for changes
since = 3552 was written. (I do think that's an interesting
question= and it's unclear to me if the answer is "yes" or
"would = like to, but it's not usefully feasible.")

Now, it's of course valid to point out that comsec (as
ekr may put it) if applied e2e doesn't by itself meet
all requirements stated in your examples, to which I'd
maybe argue to extend the Internet threat model with
some statement along the lines of: "if an endpoint
does need to see traffic content or significant meta-
data, then you need to design your protocol so that that
endpoint is an endpoint at which relevant cryptographic
mechanisms are validly terminated, according to the
expectations of the cryptographic protocol(s) in use (e.g.
TLS, IPsec). Changing the security properties of widely
deployed cryptographic protocols is not likely to be a
useful approach to attempt, as there are too many
deleterious side-effects of such proposed changes."

So I don't think, for the purposes of this = exercise,
we're considering existing widely deployed = protocols as
malleable building blocks, whether that = protocol is
TLS or some (deployed) train signalling = system.

Cheers,
S.


pub =   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <stephen.farrell@cs.tcd.ie>
sub   RSA 4096/36CB8BB6 2017-12-22





_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss


<0x5AB2FAF17B= 172BEA.asc>

= --Apple-Mail=_5E61AF67-2A6D-4568-9286-52AAC88F86FA-- --Apple-Mail=_05435614-0E6D-4AF7-81F1-361A8ED88299 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4wj54ACgkQh7ZrRtnS ejM8HwgAvh4fMUL6JrUlJCisdShcGHgzdeYUmRvc+nmI2bzv8JLSgJMnc3F5Mx28 TduIdvSpXHpDosqZHQSdh9Z7nys0w5SX4P9eAcn5IKnt/EtcsOqUrz30Fsmtyy5T F8nZFpmeUPA57MLPrIZwvUD7RFidphLnVYvBBv+MuosNzIPQ6eD1oWdbru0dim9B 5nFUllz2ZX2ByvrZS5b12HRG+LNhnytRIIrggoPcmN8NwMgQzursPuSeZhYEJgBU kKxNNlSiXA2G5P2VItxeSs8OA5VFjb9+DE8t1A0o33t6YqNrkZsjidT21JByHbiW VcK3VNk+g0vu3T6HQf46cjuiMK9y8w== =QIkG -----END PGP SIGNATURE----- --Apple-Mail=_05435614-0E6D-4AF7-81F1-361A8ED88299-- From nobody Tue Jan 28 11:48:24 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A0E120047 for ; Tue, 28 Jan 2020 11:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 q11hXYnfQ8rt for ; Tue, 28 Jan 2020 11:48:21 -0800 (PST) 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 A2172120045 for ; Tue, 28 Jan 2020 11:48:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CED39BE39; Tue, 28 Jan 2020 19:40:06 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 nY_tNlMAusRF; Tue, 28 Jan 2020 19:40:05 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 442C3BE2E; Tue, 28 Jan 2020 19:40:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1580240405; bh=pG1b8Du94+uuXokxWJ8jkQKZv1ag4EoCTNGQoyW7y68=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=0beyzcSSW1p3qysfdWgWYGPiPqF7gkbVZrPKP0ITfOe69aA0SnO8yzq+QUeOcnfHB bjm/3D3YKs6PDaa4nLQ0IkvQJ7fZ76C/eyi5EdLxQd+k0EIk+CP6/1XTaOpEpjZCZX lM1rZb97FxfJhMEDgB7+rIkDS4COpPkJI6v19IwE= From: Stephen Farrell To: Toerless Eckert Cc: Eliot Lear , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <9aedcfe1-dec5-d999-a82f-2c8e21dae578@cs.tcd.ie> Date: Tue, 28 Jan 2020 19:40:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OZRC1pEGCirNLllBa69AS9z5M0rYkgjX1" Archived-At: Subject: Re: [Model-t] [arch-d] not building blocks (was: Re: Possible new IAB program on Internet trust model evolution) X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 19:48:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OZRC1pEGCirNLllBa69AS9z5M0rYkgjX1 Content-Type: multipart/mixed; boundary="TnUzCaqXwwSNhTD7QMzB4blTaIjrBfRxW"; protected-headers="v1" From: Stephen Farrell To: Toerless Eckert Cc: Eliot Lear , Watson Ladd , "architecture-discuss@ietf.org" , model-t@iab.org Message-ID: <9aedcfe1-dec5-d999-a82f-2c8e21dae578@cs.tcd.ie> Subject: Re: [arch-d] not building blocks (was: Re: [Model-t] Possible new IAB program on Internet trust model evolution) References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <6efc8e84-90fc-aadc-ce3a-784051a9f6b3@cs.tcd.ie> <20200128192305.GR14549@faui48f.informatik.uni-erlangen.de> In-Reply-To: --TnUzCaqXwwSNhTD7QMzB4blTaIjrBfRxW Content-Type: multipart/mixed; boundary="------------E36D456075787F6C0247EB7D" Content-Language: en-US This is a multi-part message in MIME format. --------------E36D456075787F6C0247EB7D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28/01/2020 19:39, Stephen Farrell wrote: > Offlist for two reasons... oops, sorry all, but no major harm done S. --------------E36D456075787F6C0247EB7D Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------E36D456075787F6C0247EB7D-- --TnUzCaqXwwSNhTD7QMzB4blTaIjrBfRxW-- --OZRC1pEGCirNLllBa69AS9z5M0rYkgjX1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4wjhQACgkQWrL68XsX K+pDQxAAln7tgMRHdwko/G15eQSkYB9+bBA/+gmJHwbizvVeUn5dHdfzSaSUOXxz BVa0bs10cfEsVZrpwf3npBuB6rJf4BLP4x2UQH+NrcDOkmPWuvC/bb1RuJpRdae3 /tjcMtqLQ+gi4m7Mj6PCFQjZhFU6CgzXbjVLbtsG640bvGW3SBJCfe289Zjx2v2r UmTbFiDF3XYqd+tWXr+jnrwPVuFB5aQ9uW6a3deS8rK/94cmbHqRs2e2R9VRg71C drymhleC/PDJ8FifnIUkiCj4qqsQApwIu9mH505iJ06QPks8PQdBehoLAOb+97bM utwvr3Ptz3VUZkyHbpW+VyE5GLMjVkOvClwZDda6yktG+SFRtt3cbVgctKRgEbCQ ALjI5dGs0BlpANnpIkIV6W82Mgk+YmNT9lYxqI2L5T8f5JRkQl0sdxqdwDQ9l17V FVMYKpbphRmDoWauUDkV16SgeKzaaWxdlQxC7Gp1zbrCm1wJQiUv4R0FFjzWc6Ny R6znylaBH3wjC5yeROQzT133O4VmBouUZhBTlH8szD41a9n2VooFo8FvRb6XxRD2 sbZ2ZUiDfcfzeG4d7ScUR+tHYQEF4x3kT6wd3UunbjNjNNpqp9Hk8wquveHDpnUL /roTao7vYlY5nPOGvbpsa3hRe7pxdI1NYtqm4WD1fGEEurxBqCo= =whcO -----END PGP SIGNATURE----- --OZRC1pEGCirNLllBa69AS9z5M0rYkgjX1-- From nobody Tue Jan 28 12:12:09 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FAA1200B2; Tue, 28 Jan 2020 12:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jevY6aIVDPdO; Tue, 28 Jan 2020 12:12:04 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 776EE120099; Tue, 28 Jan 2020 12:12:04 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.75.85]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00SKBpsf022954 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jan 2020 12:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1580242323; x=1580328723; i=@elandsys.com; bh=IjnsAWJ9xe1yCMIBIK3V69nHQ6tQdUwakkqjgVhw9s0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=q9oyPVMQCfnLQOBSdimLzzeaM9h9++Nw5T8J/vXHGSA4+VqrQbrLfIbWgU1zlpTGo vN+wsdTmt5TLF4PWFE7qgr4KIk+mUTwomoIWvIHCTiDs1V7XZaqjF5fPvzL3KLFxAs C3GAdWy6P2mz/Uhgqtfgav+rbIYQT0QHh7mDB+YQ= Message-Id: <6.2.5.6.2.20200128115720.10bc9178@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 Jan 2020 12:11:32 -0800 To: "Joel M. Halpern" , model-t@iab.org From: S Moonesamy Cc: architecture-discuss@ietf.org In-Reply-To: <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 20:12:05 -0000 Hi Joel, At 07:16 AM 28-01-2020, Joel M. Halpern wrote: >I am a bit concerned by the emphasis on what appear to be >application policy, business policy, or government policy. To the >degree that these are decoupled from the technology we define, my >impression is that the IETF is neither skilled at nor influential >with regard to these topics. We can spend a lot of time and energy >on them. They are interesting topics. But are they really our business? I'll reply to the question first. The answer is no. Application policy might be decoupled from, for example, regulations. However, regulations can have an impact on how the application works. I agree that the IETF is neither skilled nor does it have any influence on those topics. That is applicable if the intention of this (IAB) effort is to have something similar to what is done in an IETF WG. Regards, S. Moonesamy From nobody Tue Jan 28 12:53:08 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFC51200C4 for ; Tue, 28 Jan 2020 12:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhZO1Xh8uWsH for ; Tue, 28 Jan 2020 12:53:03 -0800 (PST) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 822421200B2 for ; Tue, 28 Jan 2020 12:53:03 -0800 (PST) Received: by mail-oi1-x232.google.com with SMTP id q81so11795228oig.0 for ; Tue, 28 Jan 2020 12:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+rh7/3QBdFMgeZ37UdrpO6c7ctzkJ6qWxCd485/gYog=; b=N2oaTB6OJoRz1tJZoZZNlixme6zCnSdKVlWp5clZfcKiSFDnif2Fpo+NTct0SjOii0 hL43JeSq4dFy2Cce/Kqj/Mm/DIeVKz2ebxzIJ07cciieTVaTwZUTOOKLCqtK/yJvqmQT PTmpKV5aJ3up7dH6VLiPZpLmJ8g7gId5fmZPPygn+WemLg8L36a/TQ7fX6wsff6YEDqG cnGqJj7a9hbhr95F7cGrfTy78qZD2EEb1fBWHHojPujcOUI6BHP3TaxCran/if9u87Sb p5vqxvPwWlZzJDql83YvyAC/pH/RnPSxI/gty0NU8YzHKAyGQTEe+CGGUlYKq+5HwGTV imDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+rh7/3QBdFMgeZ37UdrpO6c7ctzkJ6qWxCd485/gYog=; b=pz3IDvOiy9K05zjQfsYPxfZbR7QuGQAM5mCNkuJ+rThxPcsCZLtNrl28wRdYSsEDUY LWN+BVwbWirOvtMGb+cxujjp/M34+RawWxeQcXVT6OypO68hFCgqRGFFb/tADJlY69tP Y3BoJfclA0TGtkSRByIgcqlSV6ULUPx0gXbfcE9nrzzuDpIUPv5IUW+OjBR/A5jhsQTq tstJC5rTMSVG/ZvYg4kptTS3fic7TcK+IT+0Wo8R1sC8qJhuZcXQ1Zar54A0HPM6nL9p tb2/awHBUU0dpbuW+BhoatcQPCFO5szPjKvO+2eK4BpUFmfQItTrtfNs9QFqNAP1v3oU ziVg== X-Gm-Message-State: APjAAAUUUPAyeXoxh+GLXcaTiGzgJMXeOj8aZ27ZWnnSkLkCW3nUAe5e 6N7xvvd8/fffxlm2BO9zBq970on11gyRxyQYHRr8tOJn X-Google-Smtp-Source: APXvYqwltWrsScejYSbI4Ky3lXg2Y2e7R65iNh4J1bFSmJTmac+lmYRq1P41Ci5JcWfb1BcqZewVnuATXGku7/EZtQY= X-Received: by 2002:aca:32c3:: with SMTP id y186mr4331228oiy.114.1580244782811; Tue, 28 Jan 2020 12:53:02 -0800 (PST) MIME-Version: 1.0 References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <66867749-85fd-8c1e-16b5-b261239a9ba3@joelhalpern.com> <78E09CC1706F7D66D5F8DE1E@PSB> <9cec50fa-cb7c-ef75-95b3-c85f9f255c6d@cs.tcd.ie> In-Reply-To: <9cec50fa-cb7c-ef75-95b3-c85f9f255c6d@cs.tcd.ie> From: Kathleen Moriarty Date: Tue, 28 Jan 2020 15:52:26 -0500 Message-ID: To: Stephen Farrell Cc: John C Klensin , model-t@iab.org, architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000f00e41059d3968ea" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet threat model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 20:53:06 -0000 --000000000000f00e41059d3968ea Content-Type: text/plain; charset="UTF-8" On Tue, Jan 28, 2020 at 2:33 PM Stephen Farrell wrote: > > John, Kathleen, > > Just on comments related to participation: "Participation > in this program is open to all interested parties, and > considered analysis of diverse inputs is important" is > what [1] already says. If you think some rewording is > needed be good to know what, or if it's just a case of > that text not having been noticed, then we're good I > guess. > That's very good, but I'm not sure how that community is feeling, it would be good to make sure they know their participation is welcome. Perhaps a message about this posted to SMART to redirect to this list would be helpful. Best regards, Kathleen > Cheers, > S. > > PS: I fixed the typo in the subject line that was my > fault in the first place:-) > > [1] > > https://github.com/intarchboard/model-t-charter/blob/master/model-t-charter-00.md > -- Best regards, Kathleen --000000000000f00e41059d3968ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 28, 2020 at 2:33 PM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

John, Kathleen,

Just on comments related to participation: "Participation
in this program is open to all interested parties, and
considered analysis of diverse inputs is important" is
what [1] already says. If you think some rewording is
needed be good to know what, or if it's just a case of
that text not having been noticed, then we're good I
guess.

That's very good, but I'= m not sure how that community is feeling, it would be good to make sure the= y know their participation is welcome. Perhaps a message about this posted = to SMART to redirect to this list would be helpful.

Best regards,
Kathleen


Cheers,
S.

PS: I fixed the typo in the subject line that was my
fault in the first place:-)

[1]
https://github.com/= intarchboard/model-t-charter/blob/master/model-t-charter-00.md


--

Best regards,
Kathleen
--000000000000f00e41059d3968ea-- From nobody Tue Jan 28 14:50:24 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DF81200FB for ; Tue, 28 Jan 2020 14:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_SCAM=1.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3gjPg-kqAdw for ; Tue, 28 Jan 2020 14:50:20 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 DE5F31200EF for ; Tue, 28 Jan 2020 14:50:19 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id p6so9223287vsj.11 for ; Tue, 28 Jan 2020 14:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pvZ1P5DZNl1I9cVSXz4OEbwS0CK10QqOU/MyprSpfSA=; b=idVaEIYwCtUg1Cq3IaU1ex6DUwo+/gI57FOD6vuGMMvPnXEYJFW3MeueAkglO8y/Mb 8donCNSQ1UbliZ91y4GrNFBDTcReNtYyx6MiQDy8T8OHo26xpSJ10fY+g97x1WsNUNgn zeVtrZMjBQzV3O7mEjWN27yOe6X6GZW2JC1lidz5oltYj8n+GRBlYoy8HRwaeSaYMOJA TwKW4jtSIJbxnBeLCwlpBw68Ysc+W2mLK680Z+e2YEjTXthYjnCe3wb18va9fAkGNGPZ 79eKcXnol337O4mGevyqwSwi1qRVHS4r8/O3GV/S2hOpEPibAR/gYEHGSSnM7NVvWOnb AZ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pvZ1P5DZNl1I9cVSXz4OEbwS0CK10QqOU/MyprSpfSA=; b=H1LgemB72GxuN+FSJL0u0S5BiEiGjOKOtt5D/spw5ZIoLBwPlt35W3owJZ1+7IG+PH npLtZMyGw57fe5ooLGYbJrGOn2V+thqqgm7qQMCy+erMnid2utQUMPUnlqWnkS/Rm01v nKF03gMq+QKKxgoJ3WCqXgQXr/UAMqrsL+8nIZ3dj6pqqJiZN2gOkbvnYv3pX8GHpJna vdnNk0UCpBg7j339kMLV/Jsf/SzEgrU+jo0mDeXzlnnY4XWvHqHes9K5ABhryqnAEsAt DpN6uh/qvYD7BbRrVEG5ceSdElKa8nQ7/SGQVvKRfrVl8tCwIRoTxNt4nYSV6HJLUIio 3IyA== X-Gm-Message-State: APjAAAWxkmL+lyvPRfwFRRV0Tk3nuHOo9Q6BlE7pcwSQV+zPCC4ekmiQ qfRaE+bmeu/6HoYE7Q3Fpdksy/LlPSGHF190DZs= X-Google-Smtp-Source: APXvYqyQNVpMsiVqbSKLjy6pBtaR3jEFUoLdnRj7mdc/TDbyetrSHiA3UvZX7c58hCRTb2nalJYVRFEwB9zCeiDsrV0= X-Received: by 2002:a67:f1ca:: with SMTP id v10mr15299209vsm.180.1580251818630; Tue, 28 Jan 2020 14:50:18 -0800 (PST) MIME-Version: 1.0 References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> In-Reply-To: From: Bernard Aboba Date: Tue, 28 Jan 2020 14:50:08 -0800 Message-ID: To: Eliot Lear Cc: architecture-discuss@ietf.org, model-t@iab.org Content-Type: multipart/alternative; boundary="0000000000004e21b9059d3b0c86" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 22:50:22 -0000 --0000000000004e21b9059d3b0c86 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eliot -- The examples you describe are difficult to capture within protocol-specific threat models (RFC 3552) or privacy considerations (RFC 6973). For practicality, those analyses need to maintain a narrow focus, yet at the same time we understand that systemic privacy and security issues can only be understood when analyzing the system that a protocol is embedded in. As a result, even protocols that successfully address the original threat models can be the source of major systemic vulnerabilities. For example, we could not have expected the authors of RFC 1945 (HTTP 1.0) to have anticipated the security and privacy problems arising from today's social media implementations - some of which were discussed during the Internet Privacy Workshop summarized in RFC 6462. However, I do think that you're on to something important that is worth IAB consideration. It strikes me that in a number of the examples you cite the "endpoint" is not acting in the interest of the "end user", at least in the sense described in draft-iab-for-the-users. As was noted in Section 4.2: In contrast, the Internet of Things (IoT) has not yet seen the emergence of a natural role for representing the needs of the end user. Perhaps as a result of this, that ecosystem and its users face serious challenges. For example, consider how some of the IoT behavior you describe might be handled within a permission model implemented in a browser or a mobile device: 1. Would a user grant permission to access to camera or microphone? In the example of the device that did not advertise that it contained a microphone, presumably, the answer would be "no" (although the microphone was not initially enabled so perhaps permission might not have been requested). 2. Would the user grant permission to access personal information such as location? In the example of the device with embedded trackers, again the user would probably not have granted access to location and other data (although we know that location can easily be obtained in circumvention of browser or mobile device protections). On Mon, Jan 27, 2020 at 10:44 PM Eliot Lear wrote: > Hi Watson, > > On 28 Jan 2020, at 02:35, Watson Ladd wrote: > > > > On Sun, Jan 26, 2020 at 1:44 AM Eliot Lear wrote: > >> Let=E2=80=99s look at three specific examples that I=E2=80=99ve mentio= ned: >> >> 1. Train signaling system needs to be audited both live and >> retrospectively in the case of accidents. This has to happen in such a = way >> that the auditor sees precisely what was sent by one endpoint and receiv= ed >> by the other. >> >> 2. The case of =E2=80=9Cparent doesn=E2=80=99t want Internet toy to sen= d video of >> child=E2=80=9D, when the camera is undisclosed (it=E2=80=99s an analog t= o the privacy >> analysis on Alexa[1] and the now infamous NEST episode[2]). >> >> 3. CPAP machine or an AED/pace maker provide a control interface to the >> doctor but the patient or his next of kin wants the data. >> > > I've got a few more examples from real life: > > 4: We need to see who is sending pictures of Winnie the Pooh. > > 5: We don't want pictures of the inside of our detention centers to appea= r > online. > > 6: I want to see everyone's credit card number at the coffee shop I run. > > Any discussion of tapping network communications because endpoints can't > be trusted needs to take these cases seriously. > > > > Absolutely. What I am suggesting is a relatively new twist on an old > problem(*). It=E2=80=99s important to understand the economic and policy= aspects > of how/whether to avoid [4] and [5], how to avoid [6] while at the same > time addressing use cases I mentioned. > > So=E2=80=A6 today=E2=80=99s new information comes courtesy of the EFF. > > > https://www.eff.org/deeplinks/2020/01/ring-doorbell-app-packed-third-part= y-trackers > > Here we have yet another IoT device that, from at least one person=E2=80= =99s > perspective is invading home privacy. And again, it is the device itself > that is the threat. In this case, it=E2=80=99s probably a more manageabl= e threat, > because one can simply not get a NEST. Try not getting a CPAP machine. > > And this brings us around to what layer to solve the problem at. Some of > this may need to be dealt with at layer 9 rather than at lower layers. W= e > should have that discussion too. > > > > Increasingly corporate networks are moving away from network layer access > controls and using user authentication over TLS, so-called BeyondCorp > model, including checking endpoint posture through management. > > > I don=E2=80=99t think this solves the railroad case. Do you? Just to cl= arify the > example: > > According to their logs, two separate signals received =E2=80=9Cset your= lights > to green=E2=80=9D at the same time, causing two trains to crash into each= other. > According to the signal controller=E2=80=99s logs, it sent =E2=80=9Cset y= our lights to > green=E2=80=9D to only one signal. What happened? > > All of the cases we are discussing have slightly different flavors of > threats. From an IAB program standpoint, the real question here is this: > what are the architectural building blocks that are required? Keep in > mind, some of those blocks could be code and some could be policy. > > One goal should be code reuse. It is probably best that the people > building the train signal *not* reinvent everything, but rather benefit > as much as they can from the experience and results that you, EKR, and a > great many other people have brought to society. > > Eliot > > (*) It=E2=80=99s also important to not fall into old tribal communication > patterns, while recognizing the realities of the concerns raised by you, > Watson, and me. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000004e21b9059d3b0c86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eliot --

The examples = you describe are difficult to capture within protocol-specific threat model= s (RFC 3552) or privacy considerations (RFC 6973).=C2=A0 For practicality, = those analyses need to maintain a narrow focus, yet at the same time we und= erstand that systemic privacy and security issues can only be understood wh= en analyzing the system that a protocol is embedded in.=C2=A0 As a result, = even protocols that successfully=C2=A0address the original threat models ca= n be the source=C2=A0of major systemic vulnerabilities. For example, we cou= ld not have expected the authors of RFC 1945 (HTTP 1.0) to have anticipated= the security and privacy problems arising from today's social media im= plementations - some of which were discussed during the Internet Privacy Wo= rkshop summarized in RFC 6462.=C2=A0

However, I do= think that you're on to something important that is worth IAB consider= ation.=C2=A0

It strikes me that in a number of the= examples you cite the "endpoint" is not acting in the interest o= f the "end user", at least in the sense described in draft-iab-fo= r-the-users.=C2=A0 As was noted in Section 4.2:

In contrast, the Inter= net of Things (IoT) has not yet seen the emergence of a natural role for representing the needs of the end user. Perhaps as a result of this, that ecosystem and its users face serious challenges.

For example, consider= how some of the IoT behavior you describe might be handled within a permis= sion model implemented in a browser or a mobile device:=C2=A0

1. Would a user grant permission to access to camera o= r microphone?=C2=A0 =C2=A0In the example of the device that did not adverti= se that it contained a microphone, presumably, the answer would be "no= " (although the microphone was not initially enabled so perhaps permis= sion might not have been requested).=C2=A0
2. Would=C2=A0the user= grant=C2=A0permission to access personal information such as location?=C2= =A0 In the example of the device with embedded trackers, again the user wou= ld probably not have granted access to location and other data (although we= know that location can easily be obtained in circumvention of browser or m= obile device protections).


On Mon, Jan 27, = 2020 at 10:44 PM Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:
Hi Watson,

On 28 Jan 2020, at= 02:35, Watson Ladd <watsonbladd@gmail.com> wrote:


I've got a few more examples from real life:




So=E2=80=A6 today=E2=80=99s new information comes courtesy= of the EFF.


Here we have yet another IoT device= that, from at least one person=E2=80=99s perspective is invading home priv= acy.=C2=A0 And again, it is the device itself that is the threat.=C2=A0 In = this case, it=E2=80=99s probably a more manageable threat, because one can = simply not get a NEST.=C2=A0 Try not getting a CPAP machine.

=
And this brings us around to what layer to solve the problem at.= =C2=A0 Some of this may need to be dealt with at layer 9 rather than at low= er layers.=C2=A0 We should have that discussion too.



Increasingly corporate = networks are moving away from network layer access controls and using user = authentication over TLS, so-called BeyondCorp model, including checking end= point posture through management.

I don=E2=80=99t think this solves the railroad case.=C2=A0 Do you?=C2= =A0 Just to clarify the example:

According to thei= r logs, two separate signals received =C2=A0=E2=80=9Cset your lights to gre= en=E2=80=9D at the same time, causing two trains to crash into each other.= =C2=A0 According to the signal controller=E2=80=99s logs, it sent =E2=80=9C= set your lights to green=E2=80=9D to only one signal.=C2=A0 What happened?<= /div>

All of the cases we are discussing have slightly d= ifferent flavors of threats.=C2=A0 From an IAB program standpoint, the real= question here is this: what are the architectural building blocks that are= required?=C2=A0 Keep in mind, some of those blocks could be code and some = could be policy.

One goal should be code reuse. It= is probably best that the people building the train signal not rein= vent everything, but rather benefit as much as they can from the experience= and results that you, EKR, and a great many other people have brought to s= ociety.

Eliot

(*) It=E2= =80=99s also important to not fall into old tribal communication patterns, = while recognizing the realities of the concerns raised by you, Watson, and = me.

_____________________________________________= __
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000004e21b9059d3b0c86-- From nobody Wed Jan 29 01:48:44 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504FA120130 for ; Wed, 29 Jan 2020 01:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdvk8Ufd3p8n for ; Wed, 29 Jan 2020 01:48:36 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C0E12086A for ; Wed, 29 Jan 2020 01:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9988; q=dns/txt; s=iport; t=1580291316; x=1581500916; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=afumTtU1ff+fMfKCgGo7KUZObPySDVgTD0fuDqnYhzc=; b=VVsduxouV7rPicGLwyuIpuvTxRqEYgWL8DEgC99QbGhQTLvOqJqKmAfi TMQsX4yXLWg3u9YydgcDwbVdipO2wQ0uV7rVlY3Z2J7UZ5wguXzW8VvOk Q6de/6z+0VCbbhvfHlU7rJ9pvKp0qL3BYja8+9GZo416SvU+7TCxI0MYH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrGACNVDFe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXsCgSOBcFQBIBIqhBSJA4d0JYlhiUyGEYF6CQEBAQwBAS8BAYR?= =?us-ascii?q?AAoJMOwMNAgMNAQEEAQEBAgEFBG2FQ4VeAQEBAQIBI1YFCwsYKgICITYGExQ?= =?us-ascii?q?HgwsBgkoDDiCrXnWBMoVKgk8NgiCBOAGMOYIAgTgMFIIeLj6CG4U+MoIsBI1?= =?us-ascii?q?YATKSGY4+MkSCQ4JMj0KEKRuWOoRFmWiMV4MuAgQGBQIVgXwDDIFYMxoIGxV?= =?us-ascii?q?lAYJBPhIYDY4pFxWOD0ADMI5HAQE?= X-IronPort-AV: E=Sophos; i="5.70,377,1574121600"; d="scan'208,217"; a="22732074" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jan 2020 09:48:33 +0000 Received: from ams3-vpn-dhcp4134.cisco.com (ams3-vpn-dhcp4134.cisco.com [10.61.80.37]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00T9mW5M019746 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Jan 2020 09:48:33 GMT From: Eliot Lear Message-Id: <16390A67-B502-4278-B93E-2642025F356D@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E6E548D7-8843-48BF-88A9-1E7BB8B41791" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Wed, 29 Jan 2020 10:48:32 +0100 In-Reply-To: Cc: architecture-discuss@ietf.org, model-t@iab.org, Toerless Eckert To: Bernard Aboba References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.80.37, ams3-vpn-dhcp4134.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 09:48:39 -0000 --Apple-Mail=_E6E548D7-8843-48BF-88A9-1E7BB8B41791 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bernard and thanks for your valuable thoughts. > On 28 Jan 2020, at 23:50, Bernard Aboba = wrote: >=20 > Eliot -- >=20 > The examples you describe are difficult to capture within = protocol-specific threat models (RFC 3552) or privacy considerations = (RFC 6973). For practicality, those analyses need to maintain a narrow = focus, yet at the same time we understand that systemic privacy and = security issues can only be understood when analyzing the system that a = protocol is embedded in. As a result, even protocols that successfully = address the original threat models can be the source of major systemic = vulnerabilities. For example, we could not have expected the authors of = RFC 1945 (HTTP 1.0) to have anticipated the security and privacy = problems arising from today's social media implementations - some of = which were discussed during the Internet Privacy Workshop summarized in = RFC 6462.=20 I really cannot say what, if any, protocol changes I would suggest at = this point to handle some of the cases I mentioned. Assuming there is = interest in this approach, I would suggest a bit of a collection and a = culling. I want to address one related point: Joel doesn=E2=80=99t think the = program should get up into layer 9 too much, and I would say that it = would be necessary to do so to figure out where we as a community want = to make some Lessiguesque law, and when perhaps we need to leave that to = others, but see below. >=20 > However, I do think that you're on to something important that is = worth IAB consideration.=20 >=20 > It strikes me that in a number of the examples you cite the "endpoint" = is not acting in the interest of the "end user", at least in the sense = described in draft-iab-for-the-users. As was noted in Section 4.2: >=20 > In contrast, the Internet of Things (IoT) has not yet seen the > emergence of a natural role for representing the needs of the end > user. Perhaps as a result of this, that ecosystem and its users = face > serious challenges. >=20 > For example, consider how some of the IoT behavior you describe might = be handled within a permission model implemented in a browser or a = mobile device:=20 >=20 > 1. Would a user grant permission to access to camera or microphone? = In the example of the device that did not advertise that it contained a = microphone, presumably, the answer would be "no" (although the = microphone was not initially enabled so perhaps permission might not = have been requested).=20 > 2. Would the user grant permission to access personal information such = as location? In the example of the device with embedded trackers, again = the user would probably not have granted access to location and other = data (although we know that location can easily be obtained in = circumvention of browser or mobile device protections). >=20 Very well put. I think that leads us into a bit of futuristic scenario planning about = how that permission model would work, what the control points are, then = how they interact, etc. The L9 discussions come in the form, I think, = of incentive modeling to address the for-the-users point. But that=E2=80=99= s for later. For now, what are the problems? To Toerless=E2=80=99 point: > Yes, i think we can agree that we would like all Internet end-to-end > transport must not even allow for a misconfigured option to use null > encryption, but i think when TLS 1.3 was standardized, there should = have > been a better solution than to completely oppress the needs of those > other use-cases. And my suggestion is that we take three steps back before we even go = there. Let=E2=80=99s not treat this like an IETF working group, but = pause and take deep breaths and work the problem space just a bit. Eliot --Apple-Mail=_E6E548D7-8843-48BF-88A9-1E7BB8B41791 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Bernard and thanks for your valuable thoughts.

On 28 = Jan 2020, at 23:50, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Eliot = --

The examples you = describe are difficult to capture within protocol-specific threat models = (RFC 3552) or privacy considerations (RFC 6973).  For practicality, = those analyses need to maintain a narrow focus, yet at the same time we = understand that systemic privacy and security issues can only be = understood when analyzing the system that a protocol is embedded = in.  As a result, even protocols that successfully address the = original threat models can be the source of major systemic = vulnerabilities. For example, we could not have expected the authors of = RFC 1945 (HTTP 1.0) to have anticipated the security and privacy = problems arising from today's social media implementations - some of = which were discussed during the Internet Privacy Workshop summarized in = RFC 6462. 

I really cannot say what, if any, protocol changes I = would suggest at this point to handle some of the cases I mentioned. =  Assuming there is interest in this approach, I would suggest a bit = of a collection and a culling.

I = want to address one related point: Joel doesn=E2=80=99t think the = program should get up into layer 9 too much, and I would say that it = would be necessary to do so to figure out where we as a community want = to make some Lessiguesque law, and when perhaps we need to leave that to = others, but see below.


However, = I do think that you're on to something important that is worth IAB = consideration. 

It strikes me that in a number of the examples you cite the = "endpoint" is not acting in the interest of the "end user", at least in = the sense described in draft-iab-for-the-users.  As was noted in = Section 4.2:

   In =
contrast, the Internet of Things (IoT) has not yet seen the
   emergence of a natural role for representing the needs of the end
   user.  Perhaps as a result of this, that ecosystem and its users face
   serious challenges.

For example, consider how some of the = IoT behavior you describe might be handled within a permission model = implemented in a browser or a mobile device: 

1. Would a user grant permission to access to camera or = microphone?   In the example of the device that did not = advertise that it contained a microphone, presumably, the answer would = be "no" (although the microphone was not initially enabled so perhaps = permission might not have been requested). 
2. = Would the user grant permission to access personal information = such as location?  In the example of the device with embedded = trackers, again the user would probably not have granted access to = location and other data (although we know that location can easily be = obtained in circumvention of browser or mobile device = protections).



Very well = put.

I think that leads us into a = bit of futuristic scenario planning about how that permission model = would work, what the control points are, then how = they interact, etc.  The L9 discussions come in the form, I = think, of incentive modeling to address the for-the-users point. =  But that=E2=80=99s for later.  For now, what are the = problems?

To Toerless=E2=80=99 = point:

Yes, i think we can agree that we would like all Internet = end-to-end
transport must not even allow for a = misconfigured option to use null
encryption, but i think = when TLS 1.3 was standardized, there should have
been a = better solution than to completely oppress the needs of those
other use-cases.

And my = suggestion is that we take three steps back before we even go there. =  Let=E2=80=99s not treat this like an IETF working group, but pause = and take deep breaths and work the problem space just a = bit.

Eliot

= --Apple-Mail=_E6E548D7-8843-48BF-88A9-1E7BB8B41791-- From nobody Wed Jan 29 09:48:14 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEBF120123 for ; Wed, 29 Jan 2020 09:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heiKb9Ou6_Jj for ; Wed, 29 Jan 2020 09:48:09 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD8312011B for ; Wed, 29 Jan 2020 09:48:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4A22B6601DF; Wed, 29 Jan 2020 19:48:07 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJioIbG64MsG; Wed, 29 Jan 2020 19:48:06 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id AFC78660135; Wed, 29 Jan 2020 19:48:05 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Wed, 29 Jan 2020 18:48:04 +0100 Cc: model-t@iab.org, architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 17:48:12 -0000 Brian, > I really do not want to see the pragmatic purpose of RFC3552 lost in = the > effort to define these abstractions. I don't think that is the = intention, > but the text seems to imply that RFC3552 was mainly a description of a > generic threat model, which it wasn=E2=80=99t. I agree of course. This is a small part of 3552. We are only considering trends in the world that may affect that small part. > Incidentally, while writing the above it occurred to me why the phrase > "IAB program" has always slightly disturbed me. Really the proposal is > a virtual IAB workshop (whereas RFC2316 came from three days in a room > together in Murray Hill, NJ). A good idea, but not a program. Perhaps, but it is worth stating that at least from my perspective the concept of an IAB program has differed depending on the topic at hand, and perhaps more importantly, has evolved over time. Right now the topics under consideration are mostly entirely open. This is fitting for = the two topics that we have brought up, but it is also at least in my = impression a shift in thinking, for openness obviously but also maybe bit of short = term goal of addressing a specific issue vs. very long-running programs. The experiences from the latter haven=E2=80=99t always been promising. Jari From nobody Wed Jan 29 09:53:40 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DE812087C for ; Wed, 29 Jan 2020 09:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZObDfHYA7pzU for ; Wed, 29 Jan 2020 09:53:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 76318120873 for ; Wed, 29 Jan 2020 09:53:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9914B6601DF; Wed, 29 Jan 2020 19:53:33 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IVR3-4cS8rQ; Wed, 29 Jan 2020 19:53:32 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id DBD38660135; Wed, 29 Jan 2020 19:53:31 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <6.2.5.6.2.20200124131650.14570c78@elandnews.com> Date: Wed, 29 Jan 2020 18:53:30 +0100 Cc: model-t@iab.org, Stephen Farrell Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20200124131650.14570c78@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Model-t] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 17:53:38 -0000 SM, > My preference would be to have the initial discussion of an RFC 3552 = update within the IETF instead of this venue. This would avoid the = awkwardness of having to offer text to the IETF. I think both me and Stephen are open to all kinds of organisational = models :-) so it wouldn=E2=80=99t be too hard to convince us that we = need something else instead. But we have heard the feedback that not = having any organisation hurts the effort. Creating an IAB program is = quite easy for us, some of the people who care about this topic are in = the IAB and discussed it originally in the IAB. And if it gets a = background/justification document done and makes a proposal, I think = that should be considered a success. I don=E2=80=99t feel particular = awkwardness with offering text to the IETF, they can obviously do = whatever they want with that. YMMV but clearly, final decisions lie with = the IETF community no matter what. Jari From nobody Wed Jan 29 09:59:54 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D57120837 for ; Wed, 29 Jan 2020 09:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhyFXJlZmjn8 for ; Wed, 29 Jan 2020 09:59:43 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id B2B4D1208B4 for ; Wed, 29 Jan 2020 09:59:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D34DB6601DF; Wed, 29 Jan 2020 19:59:42 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c17HkwnHBIeu; Wed, 29 Jan 2020 19:59:40 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 6667E660135; Wed, 29 Jan 2020 19:59:40 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <16390A67-B502-4278-B93E-2642025F356D@cisco.com> Date: Wed, 29 Jan 2020 18:59:39 +0100 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <385267B3-5524-44A1-825B-EC5AD22EE8E0@piuha.net> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <16390A67-B502-4278-B93E-2642025F356D@cisco.com> To: model-t@iab.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 17:59:48 -0000 It occurs to me that Stephen and I made some assumptions that were not = made explicit, and this has lead to some of the questions we=E2=80=99ve = received. Perhaps it would be useful to be more explicit. In particular, = we really want to extend the threat model, not take away anything that = already exists, or start to reconsider the hugely important role of = comsec.=20 Maybe this change would better describe the scope: OLD: The model-t program provides an open venue for analysis of the Internet threat model and has as a goal to produce a potential update to BCP72 that defines an Internet threat model that better matches today's reality. NEW: The model-t program provides an open venue for analysis of the Internet threat model and has as a goal to produce a potential update to BCP72 that defines an Internet threat model that better matches today's reality. Specifically, the intent is to document why an update = is needed and provide a suggested update that could be considered by the IETF. A potential BCP72 update would likely extend the set of threats considered. Reducing the protection offered by current comsec mechanisms is a non-goal. Similarly, re-consideration of the parts of BCP72 that are outside the very narrow part on Internet threat model is not in scope. Jari From nobody Wed Jan 29 11:14:41 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95477120954 for ; Wed, 29 Jan 2020 11:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nVvtGFfcMfc for ; Wed, 29 Jan 2020 11:14:37 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF8E12095D for ; Wed, 29 Jan 2020 11:14:34 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B044C548005; Wed, 29 Jan 2020 20:14:28 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A7859440059; Wed, 29 Jan 2020 20:14:28 +0100 (CET) Date: Wed, 29 Jan 2020 20:14:28 +0100 From: Toerless Eckert To: Jari Arkko Cc: model-t@iab.org, architecture-discuss@ietf.org Message-ID: <20200129191428.GT14549@faui48f.informatik.uni-erlangen.de> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <16390A67-B502-4278-B93E-2642025F356D@cisco.com> <385267B3-5524-44A1-825B-EC5AD22EE8E0@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <385267B3-5524-44A1-825B-EC5AD22EE8E0@piuha.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 19:14:39 -0000 Thanks, Jari Now i read from the text you a) want more security not less, but that you b) do not want to expand the scope outside the Internet thread model, which i read from BCP72 section 3/3.1 as being about secure point to point transport connections (*), maybe with secure discovery/naming of the peer, but not including any multi-hop transitive security of distributed applications such as web-proxies. Right ? section 3.1 doesn't really shine on defining a clear model to scope the Internet thread model. How about the transitive security of systems like DNS or BGP ? And if thats in scope, then why not web proxies or other distributed applications ? (there are feasible answers, but those answers would have to be part of a BCP72bis better explanation of the thread model, and if the answers are as i think, then so too would be security considerations of SDN controllers). I think the charter scope you would like to see would be easier explained by providing also two examples: something in-scope and missing in BCP72, and an example that just barely is outside the scope of your intended charter. Cheers Toerless On Wed, Jan 29, 2020 at 06:59:39PM +0100, Jari Arkko wrote: > It occurs to me that Stephen and I made some assumptions that were not made explicit, and this has lead to some of the questions we???ve received. Perhaps it would be useful to be more explicit. In particular, we really want to extend the threat model, not take away anything that already exists, or start to reconsider the hugely important role of comsec. > > Maybe this change would better describe the scope: > > OLD: > > The model-t program provides an open venue for analysis of the > Internet threat model and has as a goal to produce a potential update > to BCP72 that defines an Internet threat model that better matches > today's reality. > > NEW: > > The model-t program provides an open venue for analysis of the > Internet threat model and has as a goal to produce a potential update > to BCP72 that defines an Internet threat model that better matches > today's reality. Specifically, the intent is to document why an update is > needed and provide a suggested update that could be considered by the > IETF. A potential BCP72 update would likely extend the set of threats > considered. Reducing the protection offered by current comsec > mechanisms is a non-goal. Similarly, re-consideration of the parts > of BCP72 that are outside the very narrow part on Internet threat > model is not in scope. > > Jari > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Wed Jan 29 13:17:47 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7D0120048 for ; Wed, 29 Jan 2020 13:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 gQ_TskJEmCxA for ; Wed, 29 Jan 2020 13:17:40 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760082.outbound.protection.outlook.com [40.107.76.82]) (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 95B07120047 for ; Wed, 29 Jan 2020 13:17:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MdKzXCLpwTW3rcEyQfENAKsUNcmRaxX2Vu4IXB1IxUXwryE4vL/n5dr/ju42iKnQgjDQ4x3hh/uUZBZxg7FnYJDRFH8CXauwGdkimEjbem6E0/7ERa0+pTO0K7Cd0+ZBGtO4sTXynINfD+lR/NO1SwkMwDnB+ds/KUmrR4WEeTlH+gq+1x2NDFb9ZSnve3TznFEOmCAL0dSDr4y64vEKQiTQxhPKcNmfY8mtKCswSS1PVEmIDJAUlwr9rDIDAWclN9etUY9tg8O+yX9CHIzP1eLBUxWc8H6wW6tM3vI34nCsdVI+fgtOYelBSoaxLSc9AMJX65OGoGw4THAUVOlP2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+R4UbNOEb9SCinrTMmtEyg12OOrsLSB9AIjuEmf+CLQ=; b=YEwdx/szug7WTVEuun7bxTQ3PfLPwNhh+GlxnFm1TDXJj5zBs9l3OdiU8twC8Aa+mnag6vi7esdI0NbYM0HWBAxueFuSu9Qp0JT/vkRnpvEy4kZ8//VH/7lBAZBCPsbloNwWyPkvF9eIAiFTdBTMKPss897Lulwxdonbp5GTVb6BxBYpmm7S/btoCNDnQcDpyMKG44zyxJxUfvZdwXmcs2Sirj8evp8eNUFZgUE8kqPF4FIuE8fAL5SYdW4AmZU9lTK+2r4xN2huQBW3GaSBdchZjxEkXhLmxKRRJA1jivtXDOJkrYbmPFCUtOZl+oOqN0ItRRNk7lGnhMhoBdlsTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+R4UbNOEb9SCinrTMmtEyg12OOrsLSB9AIjuEmf+CLQ=; b=s5ddc7E6yBu+UwhEVnsXdbxgYcuLZraCved0CFQxcZkQuPctXezmtLC7cXHEtanO750RxuFhCU4MXhgKyFtKnZcaJrM0f9Wpu9NJw1BEjChWSQDtL2ceqly0Z4ALeOMQ5wXtWBZvO3ktyVBrvXKvSJ28qxS0IuvrzgOFSvxzqJk= Received: from BL0PR06MB4772.namprd06.prod.outlook.com (52.132.0.222) by BL0PR06MB4914.namprd06.prod.outlook.com (10.167.240.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.26; Wed, 29 Jan 2020 21:17:38 +0000 Received: from BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::bcb1:34ae:3c82:185c]) by BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::bcb1:34ae:3c82:185c%6]) with mapi id 15.20.2665.026; Wed, 29 Jan 2020 21:17:38 +0000 From: Robin Wilton To: Eliot Lear , Bernard Aboba CC: "architecture-discuss@ietf.org" , "model-t@iab.org" , Toerless Eckert Thread-Topic: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution Thread-Index: AQHV1thkVQ/MZmJpQkC8KjQJYwIVSqgCJFli Date: Wed, 29 Jan 2020 21:17:38 +0000 Message-ID: References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> , <16390A67-B502-4278-B93E-2642025F356D@cisco.com> In-Reply-To: <16390A67-B502-4278-B93E-2642025F356D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-originating-ip: [95.175.104.159] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9e33f99b-01fe-4ab0-faa1-08d7a500ab04 x-ms-traffictypediagnostic: BL0PR06MB4914: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(199004)(189003)(33656002)(5660300002)(7696005)(498600001)(66574012)(76116006)(91956017)(66476007)(26005)(186003)(9686003)(55016002)(66446008)(2906002)(64756008)(66556008)(66946007)(8676002)(6506007)(71200400001)(81156014)(81166006)(53546011)(8936002)(54906003)(110136005)(52536014)(86362001)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR06MB4914; H:BL0PR06MB4772.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YFc+X9c6hTTqGQ+zd/XU/G5vltjTPlanvAVQVNzbBKIRjeV3fGGfOGSdIK8B8bQsVaPLPB3gJG4EqtbKSG+JNGgp/ury/M6P9UqOud11vriyCaWXXsC7li4A3Xvece9Sh5mifoWv8A3ld1tXgFemQbDjcNtLiptY/F1MR+gVCUF4fBrBIMM4RdYLNBkfzFC3gs2Za7w7wMI17qPgHN9j7/b38+OryZPpE1rSnpFQkPqUzffz3cGERVB/B9Qt/Edx+KFuJvslu0AVQrLI/TiV4ZC03VnqZDFk6h88O3q2M/iu7qj+/NBwcf1LEqJpNbHp9tWGajw+/A12BX8+Af3EMc7EYhFTjiOEdkxARCBlnwrFDwoMvMLiuz7uJQlJuLW2NpdX6+5jVo7W9wbYGgdNo/G3VwmoIpSk/1b4J958atwdcYw7RAfy5CumEhcn4Q/5 x-ms-exchange-antispam-messagedata: 4bKvFSBJ1pvZjYcm4IEq6aQ0VJKZf0+5EgORHHWw/GY8opyUD+cQwwz3lWZzLhy89DLmaKakfkCD30fwrxnTgitGPcurCVat7zzvwciHvnN56Yp3CDeIx9NeZvQ2nxekvx5cdzfi/4/YsGPszXNp6g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR06MB4772046AA2FD38C48F5C75BBBF050BL0PR06MB4772namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 9e33f99b-01fe-4ab0-faa1-08d7a500ab04 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 21:17:38.3658 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nv9bTGDUo3vovCjTC0g7P6S6hMK1fomBlNoB5LjE/wX3IXGN7M1YAIiqRWsBZT61 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4914 Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 21:17:46 -0000 --_000_BL0PR06MB4772046AA2FD38C48F5C75BBBF050BL0PR06MB4772namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks, both. As I read your comments, one phrase kept presenting itself to= me... =93user agency=94. What is it, in the system, that is giving effect to the = user=92s intention and preferences. I=92m not even going to try and guess w= hich layer(s) that thing (or those things) reside, at this point, and I ent= irely agree that this is an opportunity to take a few deep breaths and cons= ider the problem space. Best wishes, Robin ________________________________ From: Eliot Lear Sent: Wednesday, January 29, 2020 9:48:32 AM To: Bernard Aboba Cc: architecture-discuss@ietf.org ; model-t@= iab.org ; Toerless Eckert Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust = model evolution Hi Bernard and thanks for your valuable thoughts. On 28 Jan 2020, at 23:50, Bernard Aboba > wrote: Eliot -- The examples you describe are difficult to capture within protocol-specific= threat models (RFC 3552) or privacy considerations (RFC 6973). For practi= cality, those analyses need to maintain a narrow focus, yet at the same tim= e we understand that systemic privacy and security issues can only be under= stood when analyzing the system that a protocol is embedded in. As a resul= t, even protocols that successfully address the original threat models can = be the source of major systemic vulnerabilities. For example, we could not = have expected the authors of RFC 1945 (HTTP 1.0) to have anticipated the se= curity and privacy problems arising from today's social media implementatio= ns - some of which were discussed during the Internet Privacy Workshop summ= arized in RFC 6462. I really cannot say what, if any, protocol changes I would suggest at this = point to handle some of the cases I mentioned. Assuming there is interest = in this approach, I would suggest a bit of a collection and a culling. I want to address one related point: Joel doesn=92t think the program shoul= d get up into layer 9 too much, and I would say that it would be necessary = to do so to figure out where we as a community want to make some Lessiguesq= ue law, and when perhaps we need to leave that to others, but see below. However, I do think that you're on to something important that is worth IAB= consideration. It strikes me that in a number of the examples you cite the "endpoint" is n= ot acting in the interest of the "end user", at least in the sense describe= d in draft-iab-for-the-users. As was noted in Section 4.2: In contrast, the Internet of Things (IoT) has not yet seen the emergence of a natural role for representing the needs of the end user. Perhaps as a result of this, that ecosystem and its users face serious challenges. For example, consider how some of the IoT behavior you describe might be ha= ndled within a permission model implemented in a browser or a mobile device= : 1. Would a user grant permission to access to camera or microphone? In th= e example of the device that did not advertise that it contained a micropho= ne, presumably, the answer would be "no" (although the microphone was not i= nitially enabled so perhaps permission might not have been requested). 2. Would the user grant permission to access personal information such as l= ocation? In the example of the device with embedded trackers, again the us= er would probably not have granted access to location and other data (altho= ugh we know that location can easily be obtained in circumvention of browse= r or mobile device protections). Very well put. I think that leads us into a bit of futuristic scenario planning about how = that permission model would work, what the control points are, then how the= y interact, etc. The L9 discussions come in the form, I think, of incentiv= e modeling to address the for-the-users point. But that=92s for later. Fo= r now, what are the problems? To Toerless=92 point: Yes, i think we can agree that we would like all Internet end-to-end transport must not even allow for a misconfigured option to use null encryption, but i think when TLS 1.3 was standardized, there should have been a better solution than to completely oppress the needs of those other use-cases. And my suggestion is that we take three steps back before we even go there.= Let=92s not treat this like an IETF working group, but pause and take dee= p breaths and work the problem space just a bit. Eliot --_000_BL0PR06MB4772046AA2FD38C48F5C75BBBF050BL0PR06MB4772namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks, both. As I read your comments, one phrase kept presenting itself to= me...
=93user agency=94. What is it, in the system, that is giving effect to the = user=92s intention and preferences. I=92m not even going to try and guess w= hich layer(s) that thing (or those things) reside, at this point, and I ent= irely agree that this is an opportunity to take a few deep breaths and consider the problem space.

Best wishes,
Robin
From: Eliot Lear <lear@c= isco.com>
Sent: Wednesday, January 29, 2020 9:48:32 AM
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: architecture-discuss@ietf.org <architecture-discuss@ietf.org&= gt;; model-t@iab.org <model-t@iab.org>; Toerless Eckert <tte@cs.fa= u.de>
Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet= trust model evolution
 

On 28 Jan 2020, at 23:50, Bernard Aboba <bernard.aboba@gmail.com> wrot= e:

Eliot --

The examples you describe are difficult to capture within p= rotocol-specific threat models (RFC 3552) or privacy considerations (RFC 69= 73).  For practicality, those analyses need to maintain a narrow focus= , yet at the same time we understand that systemic privacy and security issues can only be understood when analyzing= the system that a protocol is embedded in.  As a result, even protoco= ls that successfully address the original threat models can be the sou= rce of major systemic vulnerabilities. For example, we could not have expected the authors of RFC 1945 (HTTP 1.0) to = have anticipated the security and privacy problems arising from today's soc= ial media implementations - some of which were discussed during the Interne= t Privacy Workshop summarized in RFC 6462. 

I really cannot say what, if any, protocol changes I would suggest at this = point to handle some of the cases I mentioned.  Assuming there is inte= rest in this approach, I would suggest a bit of a collection and a culling.=

I want to address one related point: Joel doesn=92t think the program = should get up into layer 9 too much, and I would say that it would be neces= sary to do so to figure out where we as a community want to make some Lessi= guesque law, and when perhaps we need to leave that to others, but see below.


However, I do think that you're on to something important t= hat is worth IAB consideration. 

It strikes me that in a number of the examples you cite the= "endpoint" is not acting in the interest of the "end user&q= uot;, at least in the sense described in draft-iab-for-the-users.  As = was noted in Section 4.2:

   In contrast, the Internet of Thi=
ngs (IoT) has not yet seen the
   emergence of a natural role for representing the needs of the end
   user.  Perhaps as a result of this, that ecosystem and its users face
   serious challenges.

For example, consider how some of the IoT behavior you desc= ribe might be handled within a permission model implemented in a browser or= a mobile device: 

1. Would a user grant permission to access to camera or mic= rophone?   In the example of the device that did not advertise th= at it contained a microphone, presumably, the answer would be "no"= ; (although the microphone was not initially enabled so perhaps permission might not have been requested). 
2. Would the user grant permission to access pers= onal information such as location?  In the example of the device with = embedded trackers, again the user would probably not have granted access to= location and other data (although we know that location can easily be obtained in circumvention of browser or mobile device protec= tions).



Very well put.

I think that leads us into a bit of futuristic scenario planning about= how that permission model would work, what the control points are, then how they interact, etc.  The L9 discu= ssions come in the form, I think, of incentive modeling to address the for-= the-users point.  But that=92s for later.  For now, what are the = problems?

To Toerless=92 point:

Yes, i think we can agree that we woul= d like all Internet end-to-end
transport must not even allow for a misconfigured option to use null
encryption, but i think when TLS 1.3 was standardized, there should have been a better solution than to completely oppress the needs of those
other use-cases.

And my suggestion is that we take three steps back before we even go t= here.  Let=92s not treat this like an IETF working group, but pause an= d take deep breaths and work the problem space just a bit.

Eliot

--_000_BL0PR06MB4772046AA2FD38C48F5C75BBBF050BL0PR06MB4772namp_-- From nobody Wed Jan 29 20:42:21 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1852F12006B for ; Wed, 29 Jan 2020 20:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id easD3IZO-LoG for ; Wed, 29 Jan 2020 20:42:13 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 0EC4A120071 for ; Wed, 29 Jan 2020 20:42:13 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id i1so2233721oie.8 for ; Wed, 29 Jan 2020 20:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OJqZacWtpuJza1KTqLi0ZSy1hP2aitzufnhGbBOyWFk=; b=dHa2rSa40szLrn+sBAJ4zyp86cYqSEjlnH8YQeL6o83DkwdlSX4iDUorLNoRdcZDLH mU3aTUqOZm2B4jPa6QjhhX0hbkRrFczV60BiTc2zgTCLv4wY1WSWgpmJp5j+TwkEMiUk rae56Rhyg0uKNZEEMp07pKSjNZDcwOBvDGESFnEjrUBox7J6Tn2ven+79fciNrg+TzBR UUKza72hqBgZrRONsW6pbQglUkKJuApbe4j5g4T9bHU7KI8Dx8Tmd9cakZp16zjdkM5t hx620M8qWBDXi6Eb8uJAm+qEsr3OCuLVgshdBUPUqMIEeOPNI6FU4KfbXSL/fgeNkTtl grzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OJqZacWtpuJza1KTqLi0ZSy1hP2aitzufnhGbBOyWFk=; b=mbp+iFd/XQVndggkwomHFVFwTU7T6tF8LgHsxZ4MNnAj0Rtp0LEiuPBoDQxObL5tt1 puLYC69JRjSc2c3otY5gUrTS8hQ7DGvNJCdL+yxZrlNolwgOlB5jge0Le+d9BzwnuZCK OyAQPja16cDNrLoqffm3SfUOBydY+vxXrMs1+TdC2Svskp80XqoSnDZZ/dpWxqAdyPiT h+P90RCicrLOR8dCb48X8905OVFKDuBb5qOmGzc9/TlGxUGQ5XsfcOVek6V6wcrIW3vK jJrOP7udPPPQcAxjwo7NpVuQz9g+4n18s2WeXn2tuRSQT/Vrl/4Pvi2KJGQW/YN5dtSz B1JA== X-Gm-Message-State: APjAAAV6XdXIp5vI8KcGbgi5IOG3sM0wWHc3vHZeXk1ASOY5KAsEhVgZ Gmi/h5NozNzralKAYXetx9pp7trSM0NPoTdONFM= X-Google-Smtp-Source: APXvYqzQBrKyyjFqOr+jS6qNRVd/Hde8CRDpp820mLx+mHuqaZCK1YizVfprAOjtI+CujKIa2RIt6XuJC7n8YVcdHjQ= X-Received: by 2002:a54:4396:: with SMTP id u22mr1749677oiv.128.1580359332329; Wed, 29 Jan 2020 20:42:12 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Wed, 29 Jan 2020 20:42:11 -0800 (PST) In-Reply-To: References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <16390A67-B502-4278-B93E-2642025F356D@cisco.com> From: Guntur Wiseno Putra Date: Thu, 30 Jan 2020 11:42:11 +0700 Message-ID: To: Robin Wilton Cc: Eliot Lear , Bernard Aboba , Toerless Eckert , "architecture-discuss@ietf.org" , "model-t@iab.org" Content-Type: multipart/alternative; boundary="0000000000009efe48059d541407" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 04:42:16 -0000 --0000000000009efe48059d541407 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Mr. Wilton and architecture-discuss, "User", "agency", "intentions" and "preferences" and "system": do phrases made by those words refer to, exemplified by the Web operation, networks of languages...? "The Internet works because of interoperability between different computers, despite different hardware, operating systems, local language context, and software supplier. Users of the web sign on to the use of these languages when they use the Internet". (Tim Berners-Lee, "Stack of Specifications" in "Design Issues: Architectural and Philosophical Points) That was ever to be part of the discussion: Re: [arch-d] Fwd: New Version Notification for draft-iab-for-the-users-01.txt (December 15th 2019) (2) Note: (1) https://w3.org/DesignIssues/Stack.html That to which I so far understand that: In network societies, an individual/person is a synthesis, or a conflict domain, of networks of things/languages with/for/to/among which s/he celebrates/affirmes her/his life/existence... (2) https://mailarchive.ietf.org/arch/msg/architecture-discuss/7LSyY0nB_HyPPRdB= kLpfmd5joeQ Regard, Guntur Wiseno Putra Pada Kamis, 30 Januari 2020, Robin Wilton menulis: > Thanks, both. As I read your comments, one phrase kept presenting itself > to me... > =E2=80=9Cuser agency=E2=80=9D. What is it, in the system, that is giving = effect to the > user=E2=80=99s intention and preferences. I=E2=80=99m not even going to t= ry and guess which > layer(s) that thing (or those things) reside, at this point, and I entire= ly > agree that this is an opportunity to take a few deep breaths and consider > the problem space. > > Best wishes, > Robin > ------------------------------ > *From:* Eliot Lear > *Sent:* Wednesday, January 29, 2020 9:48:32 AM > *To:* Bernard Aboba > *Cc:* architecture-discuss@ietf.org ; > model-t@iab.org ; Toerless Eckert > *Subject:* Re: [Model-t] [arch-d] Possible new IAB program on Internet > trust model evolution > > Hi Bernard and thanks for your valuable thoughts. > > On 28 Jan 2020, at 23:50, Bernard Aboba wrote: > > Eliot -- > > The examples you describe are difficult to capture within > protocol-specific threat models (RFC 3552) or privacy considerations (RFC > 6973). For practicality, those analyses need to maintain a narrow focus, > yet at the same time we understand that systemic privacy and security > issues can only be understood when analyzing the system that a protocol i= s > embedded in. As a result, even protocols that successfully address the > original threat models can be the source of major systemic vulnerabilitie= s. > For example, we could not have expected the authors of RFC 1945 (HTTP 1.0= ) > to have anticipated the security and privacy problems arising from today'= s > social media implementations - some of which were discussed during the > Internet Privacy Workshop summarized in RFC 6462. > > > I really cannot say what, if any, protocol changes I would suggest at thi= s > point to handle some of the cases I mentioned. Assuming there is interes= t > in this approach, I would suggest a bit of a collection and a culling. > > I want to address one related point: Joel doesn=E2=80=99t think the progr= am should > get up into layer 9 too much, and I would say that it would be necessary = to > do so to figure out where we as a community want to make some Lessiguesqu= e > law, and when perhaps we need to leave that to others, but see below. > > > However, I do think that you're on to something important that is worth > IAB consideration. > > It strikes me that in a number of the examples you cite the "endpoint" is > not acting in the interest of the "end user", at least in the sense > described in draft-iab-for-the-users. As was noted in Section 4.2: > > In contrast, the Internet of Things (IoT) has not yet seen the > emergence of a natural role for representing the needs of the end > user. Perhaps as a result of this, that ecosystem and its users face > serious challenges. > > > For example, consider how some of the IoT behavior you describe might be > handled within a permission model implemented in a browser or a mobile > device: > > 1. Would a user grant permission to access to camera or microphone? In > the example of the device that did not advertise that it contained a > microphone, presumably, the answer would be "no" (although the microphone > was not initially enabled so perhaps permission might not have been > requested). > 2. Would the user grant permission to access personal information such as > location? In the example of the device with embedded trackers, again the > user would probably not have granted access to location and other data > (although we know that location can easily be obtained in circumvention o= f > browser or mobile device protections). > > > > Very well put. > > I think that leads us into a bit of futuristic scenario planning about ho= w > that permission model would work, what the control points are, *then* how > they interact, etc. The L9 discussions come in the form, I think, of > incentive modeling to address the for-the-users point. But that=E2=80=99= s for > later. For now, what are the problems? > > To Toerless=E2=80=99 point: > > Yes, i think we can agree that we would like all Internet end-to-end > transport must not even allow for a misconfigured option to use null > encryption, but i think when TLS 1.3 was standardized, there should have > been a better solution than to completely oppress the needs of those > other use-cases. > > > And my suggestion is that we take three steps back before we even go > there. Let=E2=80=99s not treat this like an IETF working group, but paus= e and take > deep breaths and work the problem space just a bit. > > Eliot > > --0000000000009efe48059d541407 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Mr. Wilton and architecture-discuss,=C2=A0

"User", "agency", "intentions" and &qu= ot;preferences" and "system": do phrases made by those words= =C2=A0refer to, exemplified by the Web operation, networks of languages...= ?

"The Internet works because of interoperability between different comp= uters, despite different hardware, operating systems, local language contex= t, and software supplier. Users of the web sign on to the use of these lang= uages when they use the Internet".
=C2=A0(Tim Berners-Lee, &= quot;Stack of Specifications" in "Design Issues: Architectural an= d Philosophical Points)=C2=A0

That was ever to be part of the discussion:
Re: [arch-d] Fwd: New Version Notification for draft-iab-for-the-users-01.t= xt (December 15th 2019) (2)





Note:=C2=A0=

That to which I so far understand that:=C2=A0
In network = societies, an individual/person is a synthesis, or a conflict domain, of ne= tworks of things/languages with/for/to/among which s/he celebrates/affirmes= her/his life/existence...=C2=A0

(2)=C2=A0https://mailarchive.ietf.org/arch/msg/architecture-di= scuss/7LSyY0nB_HyPPRdBkLpfmd5joeQ=C2=A0 =C2=A0


Regard,
Guntur Wiseno Putra

Pada Kamis, 30= Januari 2020, Robin Wilton <wilton@i= soc.org> menulis:
Thanks, both. As I read your comments, one phrase kept presenting itself to= me...
=E2=80=9Cuser agency=E2=80=9D. What is it, in the system, that is giving ef= fect to the user=E2=80=99s intention and preferences. I=E2=80=99m not even = going to try and guess which layer(s) that thing (or those things) reside, = at this point, and I entirely agree that this is an opportunity to take a few deep breaths and consider the problem space.

Best wishes,
Robin
From: Eliot Lear <lear@cisco.com>
Sent: Wednesday, January 29, 2020 9:48:32 AM
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: architecture-discuss@ietf.org <architecture-discuss@ietf.org>= ; model-t@iab.org = <model-t@iab.org>; Toerless Eckert <tte@cs.fau.de>
Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet= trust model evolution
=C2=A0
Hi Bernard= and thanks for your valuable thoughts.

On 28 Jan 2020, at 23:50, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Eliot --

The examples you describe are difficult to capture within protocol-spe= cific threat models (RFC 3552) or privacy considerations (RFC 6973).=C2=A0 = For practicality, those analyses need to maintain a narrow focus, yet at th= e same time we understand that systemic privacy and security issues can only be understood when analyzing= the system that a protocol is embedded in.=C2=A0 As a result, even protoco= ls that successfully=C2=A0address the original threat models can be the sou= rce=C2=A0of major systemic vulnerabilities. For example, we could not have expected the authors of RFC 1945 (HTTP 1.0) to = have anticipated the security and privacy problems arising from today's= social media implementations - some of which were discussed during the Int= ernet Privacy Workshop summarized in RFC 6462.=C2=A0

I really cannot say what, if any, protocol changes I would suggest at this = point to handle some of the cases I mentioned.=C2=A0 Assuming there is inte= rest in this approach, I would suggest a bit of a collection and a culling.=

I want to address one related point: Joel doesn=E2=80=99t think the pr= ogram should get up into layer 9 too much, and I would say that it would be= necessary to do so to figure out where we as a community want to make some= Lessiguesque law, and when perhaps we need to leave that to others, but see below.


However, I do think that you're on to something important that is = worth IAB consideration.=C2=A0

It strikes me that in a number of the examples you cite the "endp= oint" is not acting in the interest of the "end user", at le= ast in the sense described in draft-iab-for-the-users.=C2=A0 As was noted i= n Section 4.2:

   In c=
ontrast, the Internet of Things (IoT) has not yet seen the
   emergence of a natural role for representing the needs of the end
   user.  Perhaps as a result of this, that ecosystem and its users face
   serious challenges.

For example, consider how some of the IoT behavior you describe might = be handled within a permission model implemented in a browser or a mobile d= evice:=C2=A0

1. Would a user grant permission to access to camera or microphone?=C2= =A0 =C2=A0In the example of the device that did not advertise that it conta= ined a microphone, presumably, the answer would be "no" (although= the microphone was not initially enabled so perhaps permission might not have been requested).=C2=A0
2. Would=C2=A0the user grant=C2=A0permission to access personal inform= ation such as location?=C2=A0 In the example of the device with embedded tr= ackers, again the user would probably not have granted access to location a= nd other data (although we know that location can easily be obtained in circumvention of browser or mobile device protec= tions).



Very well put.

I think that leads us into a bit of futuristic scenario planning about= how that permission model would work, what the control points are, then=C2=A0how they interact,=C2=A0etc.=C2=A0 The L9 discussions come= in the form, I think, of incentive modeling to address the for-the-users p= oint.=C2=A0 But that=E2=80=99s for later.=C2=A0 For now, what are the probl= ems?

To Toerless=E2=80=99 point:

Yes, i think we can agree that we would like all = Internet end-to-end
transport must not even allow for a misconfigured option to use null
encryption, but i think when TLS 1.3 was standardized, there should have been a better solution than to completely oppress the needs of those
other use-cases.

And my suggestion is that we take three steps back before we even go t= here.=C2=A0 Let=E2=80=99s not treat this like an IETF working group, but pa= use and take deep breaths and work the problem space just a bit.

Eliot

--0000000000009efe48059d541407-- From nobody Wed Jan 29 22:48:47 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA341200C7 for ; Wed, 29 Jan 2020 22:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2sZc0Rh_iEo for ; Wed, 29 Jan 2020 22:48:42 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22DF1200C5 for ; Wed, 29 Jan 2020 22:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=568; q=dns/txt; s=iport; t=1580366922; x=1581576522; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HeNBIjft5V5acj+IxncyVEwJiavy7bf9AZ3PVR34dDY=; b=fqShJXvZttaRYyGoILpDI1fes+WPhBye2WECHqmSh5E6g54pjgWXrqEA GPMRtEZub30Dz49Yi2UcTJ2iFjU4yqc2MB9WFWDySof/286SXiUgY90Qp teXFHRGJANP84/NQNeMeYzNobfmA7tywtp0CU3aYP6dn7M3iadJwFG8yc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAwAIezJe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuDaiASKoQUiQOHcyWbOAkBAQEMAQEvAQGEQAKCTjgTAgMNAQE?= =?us-ascii?q?EAQEBAgEFBG2FQ4VeAQEBAQIBI1YFCwsYAgImAgJXBhODJoJcIKs/dYEyijm?= =?us-ascii?q?BDiqMOoIAgTgMFIIeLj6ESYMQMoIsBKAmjzSCQ4JMk24bgjgQjCsni2amRIM?= =?us-ascii?q?uAgQGBQIVgWkigVgzGggbFWUBgkE+EhgNjlWOD0ADMI4pAQE?= X-IronPort-AV: E=Sophos;i="5.70,380,1574121600"; d="scan'208";a="22709939" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jan 2020 06:48:38 +0000 Received: from [10.61.193.95] ([10.61.193.95]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 00U6mbrZ025607 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Jan 2020 06:48:37 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Eliot Lear In-Reply-To: Date: Thu, 30 Jan 2020 07:48:37 +0100 Cc: Bernard Aboba , "architecture-discuss@ietf.org" , "model-t@iab.org" , Toerless Eckert Content-Transfer-Encoding: quoted-printable Message-Id: <9D008EE8-7796-4A19-A4FE-6189C279A6A1@cisco.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <16390A67-B502-4278-B93E-2642025F356D@cisco.com> To: Robin Wilton X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Outbound-SMTP-Client: 10.61.193.95, [10.61.193.95] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 06:48:45 -0000 Hi Robin > On 29 Jan 2020, at 22:17, Robin Wilton wrote: >=20 > Thanks, both. As I read your comments, one phrase kept presenting = itself to me... > =E2=80=9Cuser agency=E2=80=9D. What is it, in the system, that is = giving effect to the user=E2=80=99s intention and preferences. Good point. I was going to write out an example of how this would play out, but I am = beginning to wonder if an I-D would do better, so as to memorialize a = bit better the discussion. This assumes it=E2=80=99s where the IAB = wants to go. Eliot From nobody Wed Jan 29 23:11:29 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F751200D6 for ; Wed, 29 Jan 2020 23:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crvhlMcubOao for ; Wed, 29 Jan 2020 23:11:24 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 51EF81200C3 for ; Wed, 29 Jan 2020 23:11:24 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id 77so2198314oty.6 for ; Wed, 29 Jan 2020 23:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jXwtvzOk5ivW5PZqMIRRDHtmq7PrFrNuhiRI6rNkKCw=; b=nLqybvRXR1s2l15wXrfiqVAIJs0Mj06miEMhfbupWaqpM17gnB3iE7AEmpFAoRxGbh 8p7146J2mga9iBnJveX+FBQBPRxEb5ghelEqtXlZ5i3H2JBGf7jQDN84OkNbNX/aHzS5 DIg88iH40wMFOvM90eTzX/n8oCovN9BkmiJErbNfxYQQqkM5khwIpogT8wjYKiGtDAym YQlEjZBPLNXvQBTbp4MUH3r0B2In4F8xareRaA4ptzB0QtS2nWkWEJOg0+8j4u+332X/ 5VoZ3mq5l17sAX7BFWKp3usEeuKFDlyb90oz5DJoPWishv10erJOTY/BFP+VDT1gTtaf FcUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jXwtvzOk5ivW5PZqMIRRDHtmq7PrFrNuhiRI6rNkKCw=; b=mjJzRoyFoT2LZIVf1lacHrdkzz50pkRaykRag2It6eX8knpsv7n7KppL2t+EQeHUEd 0HWqfX7yxgPgOPzlMav4n9GiNato4TKQ50g8V1S1faWGTDXLh1/EeDDpdqOC6NN4mYkN qZPOQWBaIQ5ThTWyqVdtNfEM53DdlCdeVmHICFZfHyNU0XDTK2nBBElpqjihhbTj7DZE NZLZ+sOYOz4AQcTFr8wgINY66cUMoS/Fuc6uEtamyVigeCv89MjNl6DYSxjE4fdcvfpB grJyh7XJnFJ/J7lL3QP2JSypuMF8a/NIiQh4VqNeuQC7u5o928mDoDyK+fdVbHqxLsf0 0GGA== X-Gm-Message-State: APjAAAV7gVBvddRjyF7aknMTlstTpssOunfFEQsjpBB0yG5cBgs+1hD1 p0W9l2opfZITx9e2wT3uyIf0zkTg7Zmm2DmP9rc= X-Google-Smtp-Source: APXvYqz8jARkvGjXceGTRQbjHDxJF6M3/Qa6zhxlVA0ryanc1la752ISiduUAx8VJghYF0z3Bohb/T+mYPJomQE19I4= X-Received: by 2002:a9d:170a:: with SMTP id i10mr2479698ota.284.1580368283618; Wed, 29 Jan 2020 23:11:23 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Wed, 29 Jan 2020 23:11:23 -0800 (PST) In-Reply-To: <9D008EE8-7796-4A19-A4FE-6189C279A6A1@cisco.com> References: <6a1a019b-8666-269c-56ca-ebae4b69e9e8@huitema.net> <96A32815-C313-4C08-90FF-DDAFAD591287@cisco.com> <16390A67-B502-4278-B93E-2642025F356D@cisco.com> <9D008EE8-7796-4A19-A4FE-6189C279A6A1@cisco.com> From: Guntur Wiseno Putra Date: Thu, 30 Jan 2020 14:11:23 +0700 Message-ID: To: Eliot Lear Cc: Robin Wilton , Toerless Eckert , "model-t@iab.org" , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="00000000000028d2be059d562a3d" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 07:11:25 -0000 --00000000000028d2be059d562a3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss, To add the note I made in the previous message: An Individual/person, by network society with ICTs as a structural matrix, is a momentous synthesis, or a conflict domain --there may be still existed conflicts accompanying her/his choices of acts--, of networks of things/languages with/for/to/among which s/he celebrates/affirmes her/his life/existence... I am referring to notions on "Network Society" and "Networks of Languages" worked in: - "Informationalism, Technology and Network Society" (Manuel Catells) https://annenberg.usc.edu/sites/default/files/2015/04/28/Informationalism%2= C%20Networks%20and%20the%20Network%20Society.pdf - here, it may deserve to note that in its forweword to "Leveraging Tech..." report Antonio Gueterez beginned with the term "networked society" "Our networked society is changing the way we live. The impact and implications of the digital revolution are becoming more evident with each passing hour. The 2030 Agenda for Sustainable Development recognizes the great potential of global connectivity to spur human progress. It challenges us to ensure universal and affordable Internet access for all". https://www.itu.int/en/sustainable-world/Documents/Fast-forward_progress_re= port_414709%20FINAL.pdf - J. F. Lyotard, "The Postmodern Conditions: a Report on Knowledge" section "Elementary Nature of Social Ties: Posmodern Perspective" as there was mentioned about society defined by "networks of language" Regard, Guntur Wiseno Putra Pada Kamis, 30 Januari 2020, Eliot Lear menulis: > Hi Robin > > > On 29 Jan 2020, at 22:17, Robin Wilton wrote: > > > > Thanks, both. As I read your comments, one phrase kept presenting itsel= f > to me... > > =E2=80=9Cuser agency=E2=80=9D. What is it, in the system, that is givin= g effect to the > user=E2=80=99s intention and preferences. > > Good point. > > I was going to write out an example of how this would play out, but I am > beginning to wonder if an I-D would do better, so as to memorialize a bit > better the discussion. This assumes it=E2=80=99s where the IAB wants to = go. > > Eliot > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --00000000000028d2be059d562a3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear architecture-discuss,



To add the note I made in the previous message:


An Individual/person, by network society with ICTs as a structural matrix, = is a momentous synthesis, or a conflict domain --there may be still existed= conflicts accompanying her/his choices of acts--, of networks of things/la= nguages with/for/to/among which s/he celebrates/affirmes her/his life/exist= ence...


I am referring to notions on "Network Society" and "Networks= of Languages" worked in:


- "Informationalism, Technology and Network Society" (Manuel Cate= lls)

https://annenb= erg.usc.edu/sites/default/files/2015/04/28/Informationalism%2C%20Networks%2= 0and%20the%20Network%20Society.pdf

- here, it may deserve to note that in its forweword to "Leveraging Te= ch..." report Antonio Gueterez beginned with the term "networked = society"

"Our networked society is changing the way we live. The impact and imp= lications=20
of the digital revolution are becoming more evident with each passing hour.= =20

The 2030 Agenda for Sustainable Development recognizes the great potential= =20
of global connectivity to spur human progress. It challenges us to ensure= =20
universal and affordable Internet access for all".

https://www.itu.int/en/sustainable-worl= d/Documents/Fast-forward_progress_report_414709%20FINAL.pdf

- J. F. Lyotard, "The Postmodern Conditions: a Report on Knowledge&quo= t; section "Elementary Nature of Social Ties: Posmodern Perspective&qu= ot; as there was mentioned about society defined by "networks of langu= age"



Regard,
Guntur Wiseno Putra


Pada Kamis, 30 Janua= ri 2020, Eliot Lear <lear@cisco.com> menulis:
Hi Robin

> On 29 Jan 2020, at 22:17, Robin Wilton <wilton@isoc.org> wrote:
>
> Thanks, both. As I read your comments, one phrase kept presenting itse= lf to me...
> =E2=80=9Cuser agency=E2=80=9D. What is it, in the system, that is givi= ng effect to the user=E2=80=99s intention and preferences.

Good point.

I was going to write out an example of how this would play out, but I am be= ginning to wonder if an I-D would do better, so as to memorialize a bit bet= ter the discussion.=C2=A0 This assumes it=E2=80=99s where the IAB wants to = go.

Eliot

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.= org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--00000000000028d2be059d562a3d-- From nobody Thu Jan 30 07:32:30 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E19B120168 for ; Thu, 30 Jan 2020 07:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPietd5Nr6vQ for ; Thu, 30 Jan 2020 07:32:22 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8FFD120112 for ; Thu, 30 Jan 2020 07:32:21 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id q8so3781558ljj.11 for ; Thu, 30 Jan 2020 07:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j4nCUOGO355Rg8aizbNf0dL09lv/yafEyTjrX7icBAU=; b=m4TwXyftWbb07OTNJyENFAj7lbRZogp0uZu779O0SG5nKdgd6mfXsl49ZTX2CRqAiP jlTtCOf6fXP1IWsreKT5yYPft5yv0U7K7ydHCyC38vHXy65eil0TSXIHQAnXZz5W9NqZ Lps6QIA9rLm3lspmSFnWlHxR8rk6EQwyM03ocwHCCK+/muwxRZZIsQ3/vKrnwPqFB3ND W1+49rOA+E6nB/BTywNpmCJWK7ylcJqniHKlCiu13gSuR50mQZoofQFQ8QLayF7HHmSH uBADcGfAV7J93thMMj6aYtFXCZouRRNIcZOoaxYTVaPVbBQ/sbooZQXOivq7a9NlgKRL hNeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j4nCUOGO355Rg8aizbNf0dL09lv/yafEyTjrX7icBAU=; b=YNc6bR1LgPGX1c1vTnIpiv3IGtHoxJWEcE0zIIWQxn+eeU2UhG6rtcX+kp0woVDGxl G5COGwutc+jbGIL31D9YwOqSIDfxtwZaCZB3EAgVYvoaUMLg2fZAAGsvw0/caucYAhtu RAtW0MJ5Et3WEAz3qM1K79cEowPR7O6qtb21D3k9xSfCsEy0DSi1Dzz32A37iyMkUVfk 4Et0nOQreGknOXesshNc2IPdxSpOnQrqNhg7Vu3KXDK3HUXs7OPYvYcZ1d2xEvjx4Ui3 ZwX8M4pl0alk+7JDTP9YBYy54SY+OSq5XDAjjxeElanorl4cIoe4hr5C/NpH7eX/C62V ppnA== X-Gm-Message-State: APjAAAWfR9+3nMYD/+1PoyLSHYXKQpP5BlxOP7YBg30BQmvauXsB5eV5 Lum2pM0SrqCfWRckEecBpKOVOBdxnllcgz1c0AWfsA== X-Google-Smtp-Source: APXvYqykCM3n6eRC652luis3NmHyg9/PKJeRQVjD/CRUuPRbvdJxmTYGZM2aj/p/dvPEoV4pLnLyYS9yZRbvpHiNo6k= X-Received: by 2002:a2e:b5a5:: with SMTP id f5mr3132179ljn.162.1580398339850; Thu, 30 Jan 2020 07:32:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Thu, 30 Jan 2020 07:31:42 -0800 Message-ID: To: Jari Arkko Cc: model-t@iab.org, architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000a69801059d5d2930" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 15:32:24 -0000 --000000000000a69801059d5d2930 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > There is relatively broad agreement that the roles and trustwortiness > of different endpoints in a protocol exchange are important > considerations. In specific cases there may be quite different > perspectives on the tradeoffs involved, e.g., to what extent privacy, > information centralisation, or the needs of enterprise networks should > be considered as the highest priority. And no doubt, other equally > valid perspectives exist. Actually, it's not clear to me that *any* of these are valid things to put in a threat model. Recall what 3552 says a threat model is: A THREAT MODEL describes the capabilities that an attacker is assumed to be able to deploy against a resource. It should contain such information as the resources available to an attacker in terms of information, computing capability, and control of the system. The purpose of a threat model is twofold. First, we wish to identify the threats we are concerned with. Second, we wish to rule some threats explicitly out of scope. Nearly every security system is vulnerable to a sufficiently dedicated and resourceful attacker. But none of the things you list are really part of a threat model. Rather, they are weights one applies to various design considerations, but that's a consideration but that's a form of analysis that happens *after* you have a threat model, not part of the threat model itself. For instance, I don't think anyone thinks that privacy threats (e.g., traffic analysis) aren't part of our threat model (and they're clearly part of the 3552 threat model). Now, as a matter of protocol design, we have often opted not to do much about these threats for practical reasons, but that's a different matter. As Brian said, the purpose of 3552 is to force protocol designers to describe the security properties of their protocols and the purpose the threat model section is to provide a common starting point for that analysis. IOW, it is an essentially tutorial function So to the extent to which an update for 3552 is needed, its purpose should be to make clear considerations which aren't otherwise obvious from the text in 3552. But that's not about a new threat model or about balancing but rather about documentation. -Ekr On Fri, Jan 24, 2020 at 3:50 AM Jari Arkko wrote: > > The IAB are considering starting up a programme on Internet > trust model evolution as described in the link at the bottom of this > email. > > We'd like to get feedback on that idea and the text. As you may > be aware, in 2019 a number of documents were published on > this topic and discussions held (on the mailing list, SAAG, side > meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual > meeting coming up on February 14th. > > To be clear, any output from this program would be text offered > to the IETF for consideration - it is not within the IAB's remit, nor > that of an IAB program, to modify a BCP. Nonetheless, an IAB > program offers a good venue for this work, as it perhaps allows > for more focus on the evolving architecture aspect within this space. > > The plan is for the new program to be entirely open for participation, > similar to how the current work has already been. That is, the mailing > list is open for all interested to join, meetings are open and listed > in the public agendas. The IAB will find a chair or chairs for the > group to stay organised. > > There's no specific deadline for this, but the IAB will consider this > further in the next few weeks, so if you could take a few minutes > to share your thoughts on this that'd be great. > > > https://github.com/intarchboard/model-t-charter/blob/master/model-t-chart= er-00.md > https://www.iab.org/mailman/listinfo/model-t > > Stephen & Jari > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000a69801059d5d2930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> There is relatively broad agreement that the roles an= d trustwortiness
> of different endpoints in a protocol exchange are = important
> considerations. In specific cases there may be quite diff= erent
> perspectives on the tradeoffs involved, e.g., to what extent = privacy,
> information centralisation, or the needs of enterprise net= works should
> be considered as the highest priority. And no doubt, o= ther equally
> valid perspectives exist. =C2=A0

Actually, it&#= 39;s not clear to me that *any* of these are valid
things to put in a th= reat model. Recall what 3552 says a threat
model is:

=C2=A0 =C2= =A0A THREAT MODEL describes the capabilities that an attacker is assumed=C2=A0 =C2=A0to be able to deploy against a resource.=C2=A0 It should cont= ain such
=C2=A0 =C2=A0information as the resources available to an attac= ker in terms of
=C2=A0 =C2=A0information, computing capability, and cont= rol of the system.=C2=A0 The
=C2=A0 =C2=A0purpose of a threat model is t= wofold.=C2=A0 First, we wish to identify the
=C2=A0 =C2=A0threats we are= concerned with.=C2=A0 Second, we wish to rule some threats
=C2=A0 =C2= =A0explicitly out of scope.=C2=A0 Nearly every security system is vulnerabl= e
=C2=A0 =C2=A0to a sufficiently dedicated and resourceful attacker.
=
But none of the things you list are really part of a threat model.
<= br>Rather, they are weights one applies to various design considerations,but that's a consideration but that's a form of analysis that hap= pens
*after* you have a threat model, not part of the threat model itsel= f.
For instance, I don't think anyone thinks that privacy threats (e= .g.,
traffic analysis) aren't part of our threat model (and they'= ;re clearly
part of the 3552 threat model). Now, as a matter of protocol= design,
we have often opted not to do much about these threats for prac= tical
reasons, but that's a different matter.

As Brian said, = the purpose of 3552 is to force protocol designers
to describe the secur= ity properties of their protocols and the purpose
the threat model secti= on is to provide a common starting point for
that analysis. IOW, it is a= n essentially tutorial function So to the
extent to which an update for = 3552 is needed, its purpose should be to
make clear considerations which= aren't otherwise obvious from the text
in 3552. But that's not = about a new threat model or about balancing
but rather about documentati= on.

-Ekr




On Fri, Jan 24, 2020 at 3:50 AM Jari Arkko &= lt;jari.arkko@piuha.net> wro= te:
<= br>The IAB are considering starting up a programme on Internet
trust mod= el evolution as described in the link at the bottom of this
email.
We'd like to get feedback on that idea and the text. As you may
be= aware, in 2019 a number of documents were published on
this topic and d= iscussions held (on the mailing list, SAAG, side
meeting at IETF-106, wo= rkshops, etc). There=E2=80=99s also a virtual
meeting coming up on Febru= ary 14th.

To be clear, any output from this program would be text of= fered=C2=A0
to the IETF for consideration - it is not within the IAB'= ;s remit, nor=C2=A0
that of an IAB program, to modify a BCP. Nonetheless= , an IAB=C2=A0
program offers a good venue for this work, as it perhaps = allows=C2=A0
for more focus on the evolving architecture aspect within t= his space.

The plan is for the new program to be entirely open for p= articipation,
similar to how the current work has already been. That is,= the mailing
list is open for all interested to join, meetings are open = and listed
in the public agendas. The IAB will find a chair or chairs fo= r the
group to stay organised.

There's no specific deadline = for this, but the IAB will=C2=A0consider this
further in the next few w= eeks, so if you could=C2=A0take a few minutes=C2=A0
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000a69801059d5d2930-- From nobody Fri Jan 31 21:07:10 2020 Return-Path: X-Original-To: model-t@ietfa.amsl.com Delivered-To: model-t@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B70120018 for ; Fri, 31 Jan 2020 21:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lkjse71VBMDw for ; Fri, 31 Jan 2020 21:07:06 -0800 (PST) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC6E120046 for ; Fri, 31 Jan 2020 21:07:06 -0800 (PST) Received: by mail-oi1-x234.google.com with SMTP id b18so9552479oie.2 for ; Fri, 31 Jan 2020 21:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sch8ub/dQod7KZ8ggFeUL9LyHaCtvPwqU/NqziGECJ0=; b=HvVkxhOlpZRUR4kti/t2m64zvSZY9p5SPresuXOSi5ZSzWol+hblrykAdRK2xNVQAu zETbvZiQIl6LxOBt+1AjtXR6VS5JGyKOFRXXVxFb5RyeMWA8/0b9q+dqMUbPgLYZRhAT doRiW5/PW1cxE2U5wDiKXFJW47TybArfmh+eRzNdtTWoFTxBVoOc0ErB6ONkNneufwiD oaWmTmrhFtHMG9nhrHB9X9FjlnbVOlDU/so7jKlg5PURxlOn3y8YhYk+wPt0kCRt/BIF y3O1ipJtMDgjimAdaL6PvHSHbK7RTuLXfblT2Xmi4vsSZUY3QUMDBl6JeEHTIXCdbwPi a+HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Sch8ub/dQod7KZ8ggFeUL9LyHaCtvPwqU/NqziGECJ0=; b=DlqSxrVAsar+gEEnGbC27YdYUFGr5vpoM1pmeGgwk2uSFBOiQMzww2LRJc820HqDJV qw/VEhUmdSrXn0s+TBTRR8jrVA+8aXyWEIAKKimKEDt7ZzHx+2nQiG3PIJmw429j4qDT 3aOLQgL8WSbD2a0LDayO462gUlqBveYMZSMg//l0pcd4So77psDc4nO/RJoNRDZQqdtk 7PadpagpJUNNuLj4Cy4l4EBaANv/2H0uMOsaoSfQpPddNkkewK/4ykIsb/XR9ruK5WJT 9C+BoorTolA39giUopSjBRzx0CNF2+9u96/InZbYThn8RRx1HfYk+ytH3P0hlyv67nV0 ieIQ== X-Gm-Message-State: APjAAAVJZCMTRR6TuQh/ZmPvao4AS4pD3EQerTwwF0ghiGQCGKv+bCHB ToVXUddM/mPGJ8F8heeC3HFVFa/OTyvAJNaTYos= X-Google-Smtp-Source: APXvYqyBasoZT0F1yA4t1BNYENYXg2BGKvSYtXqg9cP14SfDwbn6BHEQRbwti1XG6yvSn6IO5DlFMnmjRc4PcEBKEm0= X-Received: by 2002:aca:f587:: with SMTP id t129mr6733739oih.143.1580533625548; Fri, 31 Jan 2020 21:07:05 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Fri, 31 Jan 2020 21:07:04 -0800 (PST) In-Reply-To: References: From: Guntur Wiseno Putra Date: Sat, 1 Feb 2020 12:07:04 +0700 Message-ID: To: Eric Rescorla Cc: Jari Arkko , "architecture-discuss@ietf.org" , "model-t@iab.org" Content-Type: multipart/alternative; boundary="0000000000004e7382059d7ca917" Archived-At: Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution X-BeenThere: model-t@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 05:07:08 -0000 --0000000000004e7382059d7ca917 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss, Parts concerning with "the Internet security" today at Internet Society: Internet Society 2020 Action Plan - We believe deeply that the Internet must be open, globally-connected, secure, and trustworthy. - In 2020, we will continue to work towards realizing our vision by building, promoting, and defending a bigger and stronger Internet. II. Strengthening the Internet -- Promoting the Internet way of networking -- Extending encryption -- Securing global routing -- Increasing time security -- Leading by example with open standards and protocols https://www.internetsociety.org/action-plan/2020/ 2020 Action Plan Projects Strengthening the Internet - Internet Way of Networking - Encryption - Securing Global Routing (MANRS) - Time Security - Open Standards Everywhere https://www.internetsociety.org/action-plan/2020/projects/ Regard, Guntur Wiseno Putra Pada Kamis, 30 Januari 2020, Eric Rescorla menulis: > > There is relatively broad agreement that the roles and trustwortiness > > of different endpoints in a protocol exchange are important > > considerations. In specific cases there may be quite different > > perspectives on the tradeoffs involved, e.g., to what extent privacy, > > information centralisation, or the needs of enterprise networks should > > be considered as the highest priority. And no doubt, other equally > > valid perspectives exist. > > Actually, it's not clear to me that *any* of these are valid > things to put in a threat model. Recall what 3552 says a threat > model is: > > A THREAT MODEL describes the capabilities that an attacker is assumed > to be able to deploy against a resource. It should contain such > information as the resources available to an attacker in terms of > information, computing capability, and control of the system. The > purpose of a threat model is twofold. First, we wish to identify the > threats we are concerned with. Second, we wish to rule some threats > explicitly out of scope. Nearly every security system is vulnerable > to a sufficiently dedicated and resourceful attacker. > > But none of the things you list are really part of a threat model. > > Rather, they are weights one applies to various design considerations, > but that's a consideration but that's a form of analysis that happens > *after* you have a threat model, not part of the threat model itself. > For instance, I don't think anyone thinks that privacy threats (e..g., > traffic analysis) aren't part of our threat model (and they're clearly > part of the 3552 threat model). Now, as a matter of protocol design, > we have often opted not to do much about these threats for practical > reasons, but that's a different matter. > > As Brian said, the purpose of 3552 is to force protocol designers > to describe the security properties of their protocols and the purpose > the threat model section is to provide a common starting point for > that analysis. IOW, it is an essentially tutorial function So to the > extent to which an update for 3552 is needed, its purpose should be to > make clear considerations which aren't otherwise obvious from the text > in 3552. But that's not about a new threat model or about balancing > but rather about documentation. > > -Ekr > > > > > On Fri, Jan 24, 2020 at 3:50 AM Jari Arkko wrote: > >> >> The IAB are considering starting up a programme on Internet >> trust model evolution as described in the link at the bottom of this >> email. >> >> We'd like to get feedback on that idea and the text. As you may >> be aware, in 2019 a number of documents were published on >> this topic and discussions held (on the mailing list, SAAG, side >> meeting at IETF-106, workshops, etc). There=E2=80=99s also a virtual >> meeting coming up on February 14th. >> >> To be clear, any output from this program would be text offered >> to the IETF for consideration - it is not within the IAB's remit, nor >> that of an IAB program, to modify a BCP. Nonetheless, an IAB >> program offers a good venue for this work, as it perhaps allows >> for more focus on the evolving architecture aspect within this space. >> >> The plan is for the new program to be entirely open for participation, >> similar to how the current work has already been. That is, the mailing >> list is open for all interested to join, meetings are open and listed >> in the public agendas. The IAB will find a chair or chairs for the >> group to stay organised. >> >> There's no specific deadline for this, but the IAB will consider this >> further in the next few weeks, so if you could take a few minutes >> to share your thoughts on this that'd be great. >> >> https://github.com/intarchboard/model-t-charter/ >> blob/master/model-t-charter-00.md >> https://www.iab.org/mailman/listinfo/model-t >> >> Stephen & Jari >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > --0000000000004e7382059d7ca917 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

Parts concerning with "t= he Internet security" today at Internet Society:

Internet Society 2020 Action Plan

- We believe deeply that the Internet must be open, globally-connected, sec= ure, and trustworthy.

- In 2020, we will continue to work towards realizing our vision by buildin= g, promoting, and defending a bigger and stronger Internet.

=C2=A0II. Strengthening the Internet

-- Promoting the Internet way of networking

-- Extending encryption

-- Securing global routing

-- Increasing time security

-- Leading by example with open standards and protocols


https://www.i= nternetsociety.org/action-plan/2020/


2020 Action Plan Projects

Strengthening the Internet

- Internet Way of Networking
- Encryption
- Securing Global Routing (MANRS)
- Time Security
- Open Standards Everywhere


http= s://www.internetsociety.org/action-plan/2020/projects/

Regard,
Guntur Wiseno Putra

Pa= da Kamis, 30 Januari 2020, Eric Rescorla <ekr@rtfm.com> menulis:
> There is relatively broad agreement that the roles and trustw= ortiness
> of different endpoints in a protocol exchange are importan= t
> considerations. In specific cases there may be quite different> perspectives on the tradeoffs involved, e.g., to what extent privacy,=
> information centralisation, or the needs of enterprise networks sh= ould
> be considered as the highest priority. And no doubt, other equ= ally
> valid perspectives exist. =C2=A0

Actually, it's not= clear to me that *any* of these are valid
things to put in a threat mod= el. Recall what 3552 says a threat
model is:

=C2=A0 =C2=A0A THREA= T MODEL describes the capabilities that an attacker is assumed
=C2=A0 = =C2=A0to be able to deploy against a resource.=C2=A0 It should contain such=
=C2=A0 =C2=A0information as the resources available to an attacker in t= erms of
=C2=A0 =C2=A0information, computing capability, and control of t= he system.=C2=A0 The
=C2=A0 =C2=A0purpose of a threat model is twofold.= =C2=A0 First, we wish to identify the
=C2=A0 =C2=A0threats we are concer= ned with.=C2=A0 Second, we wish to rule some threats
=C2=A0 =C2=A0explic= itly out of scope.=C2=A0 Nearly every security system is vulnerable
=C2= =A0 =C2=A0to a sufficiently dedicated and resourceful attacker.

But = none of the things you list are really part of a threat model.

Rathe= r, they are weights one applies to various design considerations,
but th= at's a consideration but that's a form of analysis that happens
= *after* you have a threat model, not part of the threat model itself.
Fo= r instance, I don't think anyone thinks that privacy threats (e..g.,traffic analysis) aren't part of our threat model (and they're cle= arly
part of the 3552 threat model). Now, as a matter of protocol design= ,
we have often opted not to do much about these threats for practicalreasons, but that's a different matter.

As Brian said, the pur= pose of 3552 is to force protocol designers
to describe the security pro= perties of their protocols and the purpose
the threat model section is t= o provide a common starting point for
that analysis. IOW, it is an essen= tially tutorial function So to the
extent to which an update for 3552 is= needed, its purpose should be to
make clear considerations which aren&#= 39;t otherwise obvious from the text
in 3552. But that's not about a= new threat model or about balancing
but rather about documentation.
=
-Ekr




On Fri, Jan 24, 2020 at 3:50 AM Jari Arkko <jari.arkko@piuha.net<= /a>> wrote:
<= div>

The IAB are considering starting up a programme on Internettrust model evolution as described in the link at the bottom of this
em= ail.

We'd like to get feedback on that idea and the text. As you= may
be aware, in 2019 a number of documents were published on
this t= opic and discussions held (on the mailing list, SAAG, side
meeting at IE= TF-106, workshops, etc). There=E2=80=99s also a virtual
meeting coming u= p on February 14th.

To be clear, any output from this program would = be text offered=C2=A0
to the IETF for consideration - it is not within t= he IAB's remit, nor=C2=A0
that of an IAB program, to modify a BCP. N= onetheless, an IAB=C2=A0
program offers a good venue for this work, as i= t perhaps allows=C2=A0
for more focus on the evolving architecture aspec= t within this space.

The plan is for the new program to be entirely = open for participation,
similar to how the current work has already been= . That is, the mailing
list is open for all interested to join, meetings= are open and listed
in the public agendas. The IAB will find a chair or= chairs for the
__________________________= _____________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinf= o/architecture-discuss
--0000000000004e7382059d7ca917--