Re: [Model-t] draft-thomson-tmi

Vittorio Bertola <vittorio.bertola@open-xchange.com> Mon, 13 July 2020 08:56 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
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 DC1C53A0C58 for <model-t@ietfa.amsl.com>; Mon, 13 Jul 2020 01:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 Ooufam40p-sz for <model-t@ietfa.amsl.com>; Mon, 13 Jul 2020 01:56:20 -0700 (PDT)
Received: from mx3.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 7B3A73A0C3A for <model-t@iab.org>; Mon, 13 Jul 2020 01:55:22 -0700 (PDT)
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)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 9CB7D6A230; Mon, 13 Jul 2020 10:55:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1594630518; bh=BHGASo5g9oD5Mn6hwRvep2VMLKCrJEYY52laYEFust0=; h=Date:From:To:In-Reply-To:References:Subject:From; b=kfBY6mvWqY7P2nkD1+WFn4wuxtqEO7Wczf9GmyzYykg9v04LPB+9v7jbZGPy0IOFT ErjpVNPZuRy5VD80B1B6tFcekhqQNoBSSItvMGgXKwHFqlLgIWjrXg84ga7LVC8N8N AvV/TwIQVL4koZzZaFZsoUv6XsiwblwHm6OSDM41VZ5U2MMEjiaTokH7DepVeXW+gQ aCUimsSmP9c9fQKXPTKeqZkhSOoSeTk3g22+Jr2KB8A8EeoC5JzAQDxldPcbT6H15J jYsl4kTohNdBFZ+iUKG0YFkB/lllTW/jVqZDXOfJZyGcySwzi8FWqlkNWsOz7g3dbm +bgmAJSSuK4Sg==
Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (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 8E5FD3C0393; Mon, 13 Jul 2020 10:55:18 +0200 (CEST)
Date: Mon, 13 Jul 2020 10:55:18 +0200
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Martin Thomson <mt@lowentropy.net>, model-t@iab.org
Message-ID: <1164022876.4302.1594630518489@appsuite-gw2.open-xchange.com>
In-Reply-To: <422978b2-028d-48e1-85ed-ddaa36e36052@www.fastmail.com>
References: <422978b2-028d-48e1-85ed-ddaa36e36052@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.3-Rev17
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: <https://mailarchive.ietf.org/arch/msg/model-t/AVDmhcGRGpOB11XXhE8ajcIUiYQ>
Subject: Re: [Model-t] draft-thomson-tmi
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 <model-t.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/model-t>, <mailto:model-t-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/model-t/>
List-Post: <mailto:model-t@iab.org>
List-Help: <mailto:model-t-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/model-t>, <mailto:model-t-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2020 08:56:22 -0000


> Il 13/07/2020 06:32 Martin Thomson <mt@lowentropy.net> ha scritto:
> 
>  
> There have been a lot of discussions recently about the threat model, but I thought that I would contribute something concrete.
> 
> This is an attempt to capture what I believe to be the principles behind some of the more prominent recent protocol design efforts.  In some ways this is a broader take than that in RFC 8558, which was a discussion of transport protocols.  QUIC very much embodies these principles, but I could point to a number of other efforts across the IETF.  The principles I recommend are:
> 
>    1.  Prefer designs without intermediaries
> 
>    2.  Failing that, control which entities can intermediate the protocol, and
> 
>    3.  Limit actions and information that are available to intermediaries

I think that this really depends on who you are and how you see the world. There are people who are more afraid of the endpoints, given how hard it has become to be able to know and choose who you (the applications and devices you use) communicate with - so these people would like to become intermediaries, or install intermediaries, to regain control of their communications. Think of concepts like ad blockers, firewalls or network monitors: designing against intermediaries makes them impossible, and I don't think this is good for the Internet (or for anyone but the online advertising and tracking industry).

I would suggest that any analysis aimed at designing a threat model should start by considering both the threats that may come from intermediaries and the threats that may come from entities that control the endpoints; ideally, you would need to ensure that the end-user is protected as much as possible against abuses by both types of parties.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy