[E2ee] Reducing Plaintext Metadata in E2EE Systems

Matthew Finkel <sysrqb@torproject.org> Thu, 29 July 2021 14:12 UTC

Return-Path: <sysrqb@torproject.org>
X-Original-To: e2ee@ietfa.amsl.com
Delivered-To: e2ee@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1485F3A2410 for <e2ee@ietfa.amsl.com>; Thu, 29 Jul 2021 07:12:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 J-W53aCqEkZC for <e2ee@ietfa.amsl.com>; Thu, 29 Jul 2021 07:12:40 -0700 (PDT)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 496143A2406 for <e2ee@ietf.org>; Thu, 29 Jul 2021 07:12:40 -0700 (PDT)
Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4GbCCq54VSzDq81 for <e2ee@ietf.org>; Thu, 29 Jul 2021 07:12:39 -0700 (PDT)
X-Riseup-User-ID: 2D3C77FE2E24DD0C856E5F1075E0824F708A82B3275CA88021CA5F15F64FF192
Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4GbCCn6X6pz5vcc for <e2ee@ietf.org>; Thu, 29 Jul 2021 07:12:35 -0700 (PDT)
Date: Thu, 29 Jul 2021 14:12:30 +0000
From: Matthew Finkel <sysrqb@torproject.org>
To: e2ee@ietf.org
Message-ID: <20210729141230.p62bwxrh6shysjkq@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/e2ee/orDuxJNhxV9cON_ZzP7KgG0EKAI>
Subject: [E2ee] Reducing Plaintext Metadata in E2EE Systems
X-BeenThere: e2ee@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <e2ee.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/e2ee>, <mailto:e2ee-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/e2ee/>
List-Post: <mailto:e2ee@ietf.org>
List-Help: <mailto:e2ee-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/e2ee>, <mailto:e2ee-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jul 2021 14:12:45 -0000

Hi all,

This draft is very valuable, thanks to the authors for writing it. I'd
like to call more attention to the importance of reducing plaintext
metadata. The current draft contains:

   Existing protocols are vulnerable to meta-data analysis, even though
   meta-data is often much more sensitive than content.  Meta-data is
   plaintext information that travels across the wire and includes
   delivery-relevant details that central servers need such as the
   account identity of end-points, timestamps, message size.  Meta-data
   is difficult to obfuscate efficiently.

The phrasing of this paragraph leads me to wonder if obfuscation of
metadata should be included as a desirable feature. I don't mean to
imply it's possible to eliminate leaking all metadata in all E2EE
systems, but there is often some low-hanging fruit, like IP addresses or
non-routing metadata, that an E2EE system can try to protect or
obfuscate; e.g., MASQUE/OHTTP/Tor for IP addresses, and [0][1] for
protecting some extraneous message headers. I can open a PR if this is
helpful.

Thanks,
Matthew Finkel

[0] https://datatracker.ietf.org/doc/html/draft-autocrypt-lamps-protected-headers
[1] https://signal.org/blog/sealed-sender/