Re: [MLS] Hiding content type

Chelsea Komlo <> Tue, 28 July 2020 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD8E13A08F8 for <>; Tue, 28 Jul 2020 14:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AllLd7w_XrlN for <>; Tue, 28 Jul 2020 14:37:45 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB2763A08E2 for <>; Tue, 28 Jul 2020 14:37:44 -0700 (PDT)
Received: by with SMTP id g8so886827wmk.3 for <>; Tue, 28 Jul 2020 14:37:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4D3Dz0HOCA392CvuK26OYpzj2bTaszEGu6jLOVWZpcA=; b=dZuVqZMsM312ZDhel8gLcMdZniT9zj0BzPJdn8Et2eJyaAgeOfKOX1RoC6QGtH4zw0 1ta53rx47wg4nH/PQr0nmf0j8L3xjcz9ec+34r/way47uOp6H8yAWxw93pBxYfJrt7UY 6GnvwetiNIRaaGXqn+MZJnNc/cnf/WUquLxaoFsAP8jXYRMTC4PzOKVGG0BbmmMwmr8W DViY3o1MBoaPknjZYo9p+M9/FIRLgszJb4sKYM+QAQYbZN/rSxe9aMOjkfw7YmOfxf/Q SFKLjmqQ3VKcTzWmqM8ksXXwcz3xI3phwA8O3khmVPlce7xRnlBlVahPnzqk/r/UfArX Vg7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4D3Dz0HOCA392CvuK26OYpzj2bTaszEGu6jLOVWZpcA=; b=PQ6gsTc+N4mx5tAu041PtOEK5WRzayEf7xeT7B2IcRMyotisxVMqBN93OQbAV1fRo3 04y95XYQeg1sgvVPoKLuxJ/88KBFg9FX86CVM7xGQlUVOSPUSOWT8eTa2/NJSPWb1lGt 4wlq1q4x1fnfjsPf92lbDU2fEhsMrBc450kQes92IrI/YbNE8lHED632r59v2+N9x1AR hoU84DhUiT9DOqHVfc6PE5mZ4GXe2Cu4GVq5ccd9fIDQefQLYhWMk89vznMueLPB2NBt 9j8cuAM23z9/WE0H0vWupYfYYjZrv5OfNYeR+SpoWlEj9iDbcH0+xurmDNFHnlpsWmMF vjNw==
X-Gm-Message-State: AOAM530zpgHDUQr6eQQ2/UwzKecYnI88qvyWSs2h/nRWS4Qd+68hBg9V KBIM5LdO+Y7EJfMAJIw3fDSt5owc3kCKGYGZesY=
X-Google-Smtp-Source: ABdhPJwPxYv3UY5NW6NW6pdE7JH80237cRU+4pkAcrAqTZ1OuLNRGOCbs5pF2QzATPk4/ih76XH27HoMEWGWluGZ338=
X-Received: by 2002:a05:600c:21c2:: with SMTP id x2mr5962850wmj.142.1595972263175; Tue, 28 Jul 2020 14:37:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Chelsea Komlo <>
Date: Tue, 28 Jul 2020 15:37:29 -0600
Message-ID: <>
To: Brendan McMillion <>
Cc: Richard Barnes <>, "Hale, Britta (CIV)" <>, Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="000000000000d1694105ab873f3a"
Archived-At: <>
Subject: Re: [MLS] Hiding content type
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jul 2020 21:37:48 -0000

On Tue, Jul 28, 2020 at 8:11 AM Brendan McMillion <brendan=> wrote:

> But in the former class, you would be forcing the application to invent
>> its own scheme for signaling this stuff, which risks them making decisions
>> that are suboptimal for metadata privacy.
> Making a metadata-resistant deployment of MLS would already be incredibly
> difficult because you'd have to design your application to use the network
> in a way that prevents useful traffic analysis. Someone who's capable of
> this should definitely be capable of choosing how messages are identified
> in their system.

While the network layer would need to protect against network-level traffic
analysis such as timing and frequency fingerprinting, this can be done in a
generalized way that is agnostic to the application (such as if a mix
network were used to route traffic between the client and the DS). Ideally,
MLS as a higher-level application would not leak additional information
when it is received by the DS after having been sent through such a

> The flip side, is that your construction is already suboptimal for
> metadata privacy because the epoch id only changes once per epoch. In the
> construction that I described, the opaque identifier changes with each
> message. You could also imagine a system where the identifier would change
> with time instead of with protocol messages (for example, where messages
> are distributed over Tor circuits).

It is true that message fields should be bitwise unlinkable to a network
observer (see [1] for more information on how this property is instantiated
in routing protocols). Time can be a dangerous dependency in distributed
systems though, so I would be careful there.