[Model-t] minimization review

Martin Thomson <mt@lowentropy.net> Tue, 05 April 2022 02:00 UTC

Return-Path: <mt@lowentropy.net>
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 2472D3A1DB1 for <model-t@ietfa.amsl.com>; Mon, 4 Apr 2022 19:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=tZeLBkyH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FgGHqSVg
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 uaZqXLxpqLef for <model-t@ietfa.amsl.com>; Mon, 4 Apr 2022 19:00:36 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09FB53A1DB0 for <model-t@iab.org>; Mon, 4 Apr 2022 19:00:35 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 083533200A64; Mon, 4 Apr 2022 22:00:34 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Mon, 04 Apr 2022 22:00:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; bh=6 MjfWG1OftYp3Xtwce+jlhvgCY09j7Xf4PvCb5/JnFM=; b=tZeLBkyHFNuV2kFJL +uYVwifbhlq79qeS0efOeexlo5Y/pzq8+sWgQX9DNaXTrr06Nu2DM7P3A5O7nL2N 96o5d7pf2rOrJ17KL9887M5eLpwK1ncBBA1OwzqNRP1nZfFgIAfHvOcW/713PNrj mhebskNOFIWBVWh8dATZOJfLlL7aInoFhwiJWrSZ3pLVV2K9/7ofMxJn0nlwX4QH tJ2vc1auYwEiUlWdcl/NdgUt7hXOEgDlwkWhiPPbpmxYyFRI06lyZllYSOXlRIKD rzMR+4cbEGFO1MIUkhPyn43AwnzTYNlGb8a4i9LduQylR/u08n8xjSdhOU4aTf2v nBxxw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=6MjfWG1OftYp3Xtwce+jlhvgCY09j7Xf4PvCb5/Jn FM=; b=FgGHqSVgXtlkC4WbaamcyWqWfTF/P7B2S+mB2e7HhnmDVQv08O+X3xXg7 p5lerLtx3jYNaFh2VdJXwPUPY3GnCHpmFmGSRpHXij/vMSohUsFkiXyVdP9N5Q5u ed6ZoCiUB7o3JSYW15HWEXt7QLzFI0zsC81ck/DLgWFBvYWMhhfYuVwLU0lCByGD iFwgwQvxH7TbT3GjMfaiHwITlDyYpRL55TZGYcxGJ7YT3+I7aD2fOuYGgtzE/p4F Ov8v2jcrLiw/b0H19zEZKngSaiqZEHiXzB4LM1vz31KdUl+Kv6q/lcCYqIdwDqZf TWbdp54b5RCRRbPNGBlPJyjjtunXA==
X-ME-Sender: <xms:wqJLYpKm_KQIdlZTvbvJFMnAK25z1yvOwMFJXO4QiMwDJznPEs1YfA> <xme:wqJLYlI0yK-XQeWe8Mm7FQHF_CfHc9oYngAWRY_QqJpjXA5weR5N2rqJ1IwFjyYNt UFRcLmdI8WGtnJfsYQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudejfedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesthdtredtreertdenucfhrhhomhepfdforghrthhi nhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuggftrf grthhtvghrnhepvefguddtgfejfeduueehkeehkeduueegheefgeevkeekgeelveevffeu udffheehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:wqJLYhtLOAbgPtQqpoHOxP6I0jPRhyMuNNqEdAmAC0jBWBEUvtGQVg> <xmx:wqJLYqaoOSU4zKak6j0oV06Yt4DGuaYcnxXIq-ll-N_iCO9di1FV2g> <xmx:wqJLYga3XVD7qAU8bpuMqq3r9kHLlRQBp8LK85fPsTCbRsVEfccBhQ> <xmx:wqJLYm3f6-6QNjc00zZVCTm-gsMlIbOzgpWr98uXuOTR2IvtX4q8Sw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1BF083C0465; Mon, 4 Apr 2022 22:00:34 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-385-g3a17909f9e-fm-20220404.001-g3a17909f
Mime-Version: 1.0
Message-Id: <f621a2ed-5cbb-4d77-aa8e-abbd167b7ad1@beta.fastmail.com>
Date: Tue, 05 Apr 2022 12:00:16 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Jari Arkko <jari.arkko@piuha.net>, model-t@iab.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/model-t/whlox2WupgOXpLGphbYzueQZuUA>
Subject: [Model-t] minimization review
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, 05 Apr 2022 02:00:43 -0000

Hi Jari,

I really like the essential simplicity of the idea behind this draft.  It's a little odd that we find ourselves in need of a statement like this, but - as far as I'm aware - this hasn't been stated so directly before.  So I'm supportive of publishing like this.

This version is definitely more focused than the last, which is an overall improvement.  I've a few comments, that I'll try to keep high-level.

. Comparison with communications security

Your comparison with communications security doesn't quite work for me.  It seems like the key distinction here is that communications security concerns itself primarily with limiting who can access information, where this is talking about limiting the amount of information.  That is, we're talking about the distinction between breadth (how far information is distributed) and depth (how much is distributed).

. Discussion points

Section 3.1 of the draft seems a little confused to me.  When you talk about Oblivious DNS, PPM, encryption at rest, end-to-end protections, and similar (these need citations), I don't think we're talking about minimization as much as we are back to communications security.  That is, this section seems to once again address the "who" part as opposed to the "how much" part.

A strong reason to prefer minimization approaches is that the scope of an exposure/leak/breach is limited.  This is, I think, the central thesis here.  That is, even where an entity might be trusted with data, mistakes and attacks happen. In that case, information that was never provided cannot be revealed.

To that end, this section could be much shorter and more direct.

If you want to draw on those examples, then you might talk about how a system might be designed to avoid having data exposed to any single entity.  That's a much more interesting statement for protocol designers.  But I'm not sure how much you want to draw on that thread as it leads to a fairly lengthy discussion of different design trade-offs, the role of metadata, and related things.  For example, we managed to design Web Push (RFC 8030) to avoid the need for data to be exposed to the intermediary, but the trade there was in metadata: the intermediary is likely able to observe who is communicating with whom.

. Related work

In Section 3.2 I don't think that the first paragraph of "stuff we talked about" is particularly useful if you want to ensure that the document is focused.  And as much as I like the reference to my work, it probably doesn't really advance your central thesis particularly well (the earlier reference might suffice).

I would combine the two path signals documents, or focus mainly on the newer one.  The original RFC 8558 is really talking about the commsec approach of limiting who gets information, but the new one really starts to dig into understanding the shape of the information that is provided.  That's a much stronger reference.

The work on wire image is one I'm less clear on.  If anything, that suggests a security considerations section for the document.  Along with the website fingerprinting reference, recognizing that information might leak inadvertently despite attempts to withhold it is an important point to include.  Data tends to be interconnected and correlated and so saying one thing can often allow for inferences about other things, just like the use of the spin bit in QUIC can reveal that you are behind a NAT or VPN.

Talking about this allows you to make an important point: minimization is not always successful.  For instance, in our work on minimization in geolocation (see RFC 6772) we discovered that the information you think you reveal and the information a determined adversary might be able to learn can be very different.  This topic area gets interesting - either in the "may you live in interesting times" sense or the "you can build an academic career on this" sense, I don't know which - so you probably don't want to say much more than other than include a carefully worded warning.

I hope this helps.  I'm supportive of the IAB saying something concrete here.  Even if it seems like it is obvious, sometimes the obvious needs to be said for it to be recognized.

Cheers,
Martin