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

Eric Rescorla <ekr@rtfm.com> Tue, 14 July 2020 12:44 UTC

Return-Path: <ekr@rtfm.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 D75D63A0BE7 for <model-t@ietfa.amsl.com>; Tue, 14 Jul 2020 05:44:57 -0700 (PDT)
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, 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 wPKH07JhJSXf for <model-t@ietfa.amsl.com>; Tue, 14 Jul 2020 05:44:56 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 04A543A0BDB for <model-t@iab.org>; Tue, 14 Jul 2020 05:44:56 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id s9so22423468ljm.11 for <model-t@iab.org>; Tue, 14 Jul 2020 05:44:55 -0700 (PDT)
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=f4fm/wR3rVRgmnyX0vPkrGr5bLSfhUXbMHPbGxQzvgA=; b=hy4iSdJ9M38SxWLnZXqyoeIR7oZubmeISt+tSd+XPvu92HHK1S+Gs9Jh1czTndO/JJ NklhsTpon3bLCzwDKDTHiPkizv4HTzLeytEjc4RO0h0ZVHX5OV6P01neyKJRqJjOH/TG 6/TjXKJFp2BQcXVNfk8/dbMiMAN9R0mn3WidiK5c6sFO0YP15ZyAW7f9Kk8mlWKNNzCJ 4NNDGlToSm4G8pX7LfiazDGRLpqAz04JdJnCjoyTBhrnoAEt+JQTPzueAJw5Kv8Xbpjp FAWtk8IZQuOQ8QO3XWymO0r9YjeV8bFhILid0LFNiFcbadEQIb8T0pHqzs9VSyTB12ET B6Kw==
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=f4fm/wR3rVRgmnyX0vPkrGr5bLSfhUXbMHPbGxQzvgA=; b=NI2+MsZ0xzkCYMoVknRDb7KC/rjMpQzo8vE/feXGDRnvWi5sRZ8q0HePuFR93PxWO6 zy9K7x/uhoh8mL76UqtDQkTGN++0vpEPl2ks+Aswxhl/XGur5eCHKgU6+Yb4rqopXR3P OIsZkpaledSzVHzDlAoQUB1zBQklaQVRklhTOkQ71qaf0AW3lBxg2kA/4TcZBA/A0eD5 Wi5WxqZARJyyJCnuzE73N/P6Im4nIWr4aUXuvF+333JyVQ9fWvXLVuo287ZoPc6Zj3Nv UX3apMZ5U+a4cLaNobb/s/pwt1qG4nRVgiYiuN8C3y56XXpXF1tzEOr/5BEUQlpZVJ+N whfg==
X-Gm-Message-State: AOAM5323Lad73fG9MKuv3OeXpszmz1g4K2gjD07o5WC+fkC6Q9JsjoqO hQBvWS8k6hXcWTgziMXtFkiZYFSQn9mUvFFfMWXV2UXCHXo=
X-Google-Smtp-Source: ABdhPJwba/Z7rCApp0mLDzGNxWTmlX+PjadTBbjjRI6uz+KHet+2K3Jfi79/k8pQp4lqIxhkEqtpv75lSkntU5sCJDc=
X-Received: by 2002:a05:651c:111:: with SMTP id a17mr2363401ljb.265.1594730694114; Tue, 14 Jul 2020 05:44:54 -0700 (PDT)
MIME-Version: 1.0
References: <422978b2-028d-48e1-85ed-ddaa36e36052@www.fastmail.com> <1164022876.4302.1594630518489@appsuite-gw2.open-xchange.com> <004e5fc9-e284-4c84-8a3c-7872ceb1d20b@www.fastmail.com> <a5838569-2b93-e982-1c9f-df773456c494@huitema.net>
In-Reply-To: <a5838569-2b93-e982-1c9f-df773456c494@huitema.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 14 Jul 2020 05:44:18 -0700
Message-ID: <CABcZeBOjcSJAt4G3q87ew3UNrLS2YkSN-+=TTUm6RVW22jfaLg@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Martin Thomson <mt@lowentropy.net>, model-t@iab.org
Content-Type: multipart/alternative; boundary="0000000000008910a205aa662c93"
Archived-At: <https://mailarchive.ietf.org/arch/msg/model-t/Lt25n_EHL52u_2eVepM638P_FSU>
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: Tue, 14 Jul 2020 12:44:58 -0000

On Mon, Jul 13, 2020 at 9:33 PM Christian Huitema <huitema@huitema.net>
wrote:

> On 7/13/2020 5:25 PM, Martin Thomson wrote:
>
> On Mon, Jul 13, 2020, at 18:55, Vittorio Bertola wrote:
>
> 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.
>
> I did not claim that this was addressing all of the problem.  I agree that not being able to trust endpoints that you bought and are responsible for maintaining is a real problem.  I disagree with the idea that more intermediation is any sort of solution.
>
> Yes. There is a privacy argument that it is important to be able to
> inspect what comes out of the device, in order to shine a big light on
> possible privacy abuses. There are also two classes of counter arguments:
> first, that weakening the data protection of these devices plays in the
> hands of a variety of bad actors; and second, that in the case of competent
> device makers, inspecting the traffic won't reveal much.
>
> Take the example of a cloud-backed security camera. Inspecting the traffic
> will show that it is sending streams of video images to the cloud service.
> That won't be a surprise, because that's exactly what the device is sold
> for: send the images to a remote service, so the users can check the
> security of their home from their cell phone in the office. At the same
> time, just knowing that will not tell you that the images are harvested to
> feed a facial recognition database, or that they are made available to the
> police. That kind of abuse happens in the back end. And yes, there are real
> life examples of door-bell cameras doing exactly that. And of course we
> could define the same scenarios for thermostats, light bulbs and many more.
>
> Asking the device makers for a way to inspect their traffic of such
> devices won't give you much, and the back doors required for enabling that
> are almost guaranteed to be abused by hackers. What you really want is some
> form of control on what happens to your data once they reach the cloud.
>
I agree that that would be good. Another approach is to have the devices be
open source so that one can determine what it is they do, rather than
attempting to reverse engineer it from the traffic.

-Ekr