Re: [E2ee] Reducing Plaintext Metadata in E2EE Systems

Mallory Knodel <mknodel@cdt.org> Tue, 19 October 2021 15:44 UTC

Return-Path: <mknodel@cdt.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 D9F233A0062 for <e2ee@ietfa.amsl.com>; Tue, 19 Oct 2021 08:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-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 (1024-bit key) header.d=cdt.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 xRMaI8jz1lBg for <e2ee@ietfa.amsl.com>; Tue, 19 Oct 2021 08:44:23 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 447BC3A00D2 for <e2ee@ietf.org>; Tue, 19 Oct 2021 08:44:23 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id n2so353246qta.2 for <e2ee@ietf.org>; Tue, 19 Oct 2021 08:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:content-language:from:to :references:subject:in-reply-to:content-transfer-encoding; bh=70zVKVbphcvqruDr6cchvltF4dnd9VI8ohAVqpuEN3Y=; b=Kli4hvGTZMdETa/Zw0XBhkSURCZuZWqxKwnnbncUo15dtkmS8d9txf/6ZLxkQpFJvo ZqXFrLcyTKWiwoaCymKAIxduYTy9xFcRhPaAhmIKXVJ/hlbuoyk5LeG2bpKkhstWb/O0 mp7rk2vMfw2zX9z9BVpU5jB6K7FMI0l4STdaM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:from:to:references:subject:in-reply-to :content-transfer-encoding; bh=70zVKVbphcvqruDr6cchvltF4dnd9VI8ohAVqpuEN3Y=; b=HufQO10sKkeeoWSkLzOKDnnAmpzimwTo1ncBFpw9MSXLzC4jlVIlMZ83pPavlEscfx v6kw+/Ilr/dXiHCJb2GlSkhWmmw4h5ZLsQFKQe9gdlchctg77/dAC5e7IsYa2y50qer7 /kTwZ03qedgon2cGcAHfeLvVZivDFT9D/yJ6Hn16gbc9biUM5u/AEkv+Y0OrBHU+xCsL 3Fx7wx5PqACsveSUQ9o4abDVy+BYPDmWJgxbbRKhYUPPHkMlTOyccAwvPMxbJHb+Yqtj JE9+elbOVHbXWWatkkJ6n2FnAywGyefENUfUXry6nd5lqTI8g9k75410fLZhSofM361Q R0qQ==
X-Gm-Message-State: AOAM533/gmeulK8/zxnNAuFh/rnYtwWq7jCujhKmbJmaD5UfbBgQ3k67 9eYZb0VygYwY676NU3WFS527QKpkcDh177lv
X-Google-Smtp-Source: ABdhPJwjtrWfwn46xjdHdSUOWY3lQ7pqHYGMSL5Q1mLgTL5oCso/wM6m4qHYBReEnypyKNNPipbt6w==
X-Received: by 2002:ac8:47d4:: with SMTP id d20mr779549qtr.210.1634658262105; Tue, 19 Oct 2021 08:44:22 -0700 (PDT)
Received: from [10.0.3.86] ([50.239.129.122]) by smtp.gmail.com with ESMTPSA id o13sm8230979qkl.102.2021.10.19.08.44.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Oct 2021 08:44:21 -0700 (PDT)
Message-ID: <a08d9340-406d-4ba4-af5d-bcf1ca1bfeaf@cdt.org>
Date: Tue, 19 Oct 2021 11:44:21 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Thunderbird/94.0
Content-Language: en-US
From: Mallory Knodel <mknodel@cdt.org>
To: Matthew Finkel <sysrqb@torproject.org>, e2ee@ietf.org
References: <20210729141230.p62bwxrh6shysjkq@localhost> <ae81d84b-3c1a-ed51-4f77-11e280a507c0@cdt.org>
In-Reply-To: <ae81d84b-3c1a-ed51-4f77-11e280a507c0@cdt.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/e2ee/Dt-TVfukGzOYDY_98LLaqsEHCRY>
Subject: Re: [E2ee] Reducing Plaintext Metadata in E2EE Systems
X-BeenThere: e2ee@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of the definition of end-to-end encryption." <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: Tue, 19 Oct 2021 15:44:28 -0000

Hi Matthew,

I added a section under Optional/desirable features that says:

Metadata obfuscation: Steps should be taken to minimize metadata such as 
user obfuscating IP addresses, reducing non-routing metadata, and 
avoiding extraneous message headers can enhance the confidentiality and 
security features of E2EE systems.

-Mallory

On 7/29/21 10:27 AM, Mallory Knodel wrote:
> Thanks a lot Matthew,
>
> I agree that this should be a goal. Not all of the features should or 
> could be part of every e2ee system, but the draft should demonstrate 
> the "trajectory" of where the technology goes ideally.
>
> Please do create a PR, I would be happy to review and merge.
>
> -Mallory
>
> On 7/29/21 10:12 AM, Matthew Finkel wrote:
>> 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/
>>
-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780