Re: [MLS] Hiding content type

Chelsea Komlo <chelsea.komlo@gmail.com> Wed, 29 July 2020 00:11 UTC

Return-Path: <chelsea.komlo@gmail.com>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2A03A0C70 for <mls@ietfa.amsl.com>; Tue, 28 Jul 2020 17:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jSxjlK6o5yHt for <mls@ietfa.amsl.com>; Tue, 28 Jul 2020 17:11:41 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 AE8903A0C6F for <mls@ietf.org>; Tue, 28 Jul 2020 17:11:40 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id 9so1106241wmj.5 for <mls@ietf.org>; Tue, 28 Jul 2020 17:11:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UKXISD45bDNsPtSCdLkZEvkMfiWsmzzi7/jrtSEMM/g=; b=Me6i8rxCCLMVD7WUQwFfQwyARFVbb/Jr0oYcXYUEsHmu4UIf4Mj0OQJKWuegdxlRql EVCxn/lRPaP+/FoIcXsMqJtcHl4Ph/V1Lw+OgFmUfh9P46sDr0cNY6LE9jLz0f3/6fGx dxFlIhrpBEP5HiBg+JuCNVz+Qb8RWR5uTtkTcA/hszs21SYwz4b1jiRZZXyi9cWM5xqj yFbswdAYZVuxzbv1CNCgXJpZfHB0SNMnE7JhLcfS55vSxmFv9lm9Uf6B5rZFehiZghe/ RWk5XnkPyzcrQsw0irPoR6FkfsRnkDiIQc78Yz0CUdb3BxgjKgJxwrMVUT2eKuI6YExN 8Svw==
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=UKXISD45bDNsPtSCdLkZEvkMfiWsmzzi7/jrtSEMM/g=; b=NxrfAzUqkcVvZhkQcWlDOb5ZJ2oPsPGZud34AIBZDjE3LhLDiOven2X6lHJzpsuxrC pQSNw4m2XPS7gerWXx6232ytiiRO1LzUBgarZnDfDVWiIbhIGCzT7WzcVqdL6FOHh911 KAlQS8+XBwCsxsv3F0AVAqK1mCZM7b7mo7xmhjkndyDA1GEWNPPf2bTpZO/OrWI4uby3 Xeryqye2mDBs7BSGAQK9y4yiOMMP/mUstfg563eS8iMgmhuEeBF7nyLZAcHmWgH96Q6a GQvQ6ILaDLQ5okBBXfRJi37w1LnOiT5gMzArrkvtc/7AdAdhBkT86gKfhCPT7Lg4HL3n t0jA==
X-Gm-Message-State: AOAM5329JlkA+QhRjV6SadFmNkOARtW261dcMs1NR6hxTEFGBowh+75m icYex5CCfs3FMOmi8+G+W+T5pKr2WI112jOcSDs=
X-Google-Smtp-Source: ABdhPJxy75z/jETBrpGC0Eog7+NV5HAOdlBktgg0JlzgL5AD3EppT71vt5B1ELOcd7lrlwPTcmFlkpNM8IDBn3dub8I=
X-Received: by 2002:a05:600c:2157:: with SMTP id v23mr5832454wml.38.1595981498235; Tue, 28 Jul 2020 17:11:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAL02cgT4jBiJNCoRBsBc7hRWBX0qzmZjC8B8XmJnGcZXgEiCdg@mail.gmail.com> <CABP-pSTW=7jK2hRHLYwydOyrfimfqti0Rih=BoBpqBJDfqf4QQ@mail.gmail.com> <CAL02cgT0KWJ21m70q5cL7NKBB+-Cjvb63YpgnBGoisScNqQchQ@mail.gmail.com> <CABP-pSR2UxWkKk6a_T9vN4cv89zCchNbN4YN=dS_qm5Ye4AjJA@mail.gmail.com> <FCAAD638-E0F8-4A91-90F1-1A2F1233D88F@nps.edu> <CAL02cgQBge9V3YEtnxRPOxLuMWQzg_Y1XD_cmEX=q94ou6fe7w@mail.gmail.com> <CABP-pSSQJ2dT2-mmvAYFYhvtVsRL9KWy71Zcfoxx8pMse2L=Kw@mail.gmail.com> <CAL02cgRxXjoCQX3V7TTL9aW04ywFmwQvk3vRcMadQfpATfXwHg@mail.gmail.com> <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> <CAL02cgS4n_Y5=BiWfqN20PjyCwA1uubEEnh46ExDuYK=NMdZHA@mail.gmail.com> <CABP-pSRAP-9SZMgWrdD15SFJn5y7ya9yBHvtEnP+6KBbWtqHdQ@mail.gmail.com> <CAJoqpTJ=i0M9ztHPgdLXxz0Cp6Y-WdWmZ3QZ6wGN0hpsa1RWWA@mail.gmail.com> <CABP-pSTxOdeKK_OBuq-MhFb=HpZuMji4O_dFycBsTqijqxdHQQ@mail.gmail.com>
In-Reply-To: <CABP-pSTxOdeKK_OBuq-MhFb=HpZuMji4O_dFycBsTqijqxdHQQ@mail.gmail.com>
From: Chelsea Komlo <chelsea.komlo@gmail.com>
Date: Tue, 28 Jul 2020 18:11:25 -0600
Message-ID: <CAJoqpT+OjXXRyzwLxTOhmyKcdZ22yKjsUWJ+15O2NOm1K8sOjA@mail.gmail.com>
To: Brendan McMillion <brendan@cloudflare.com>
Cc: Richard Barnes <rlb@ipv.sx>, "Hale, Britta (CIV)" <britta.hale@nps.edu>, Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000453e7c05ab8966ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/vW3SU32pYR2HvyGfzepkIXHu64A>
Subject: Re: [MLS] Hiding content type
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2020 00:11:43 -0000

I realize this is off topic to the discussion of hiding content type/epoch
ids in MLS, but addressing the below for completeness. I'm happy to
continue this discussion in a separate thread if there is further interest.

On Tue, Jul 28, 2020 at 4:05 PM Brendan McMillion <brendan@cloudflare.com>
wrote:

> 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).
>
>
> In the specific case of a mix network, that's not true. The DS has at
> least these variables for traffic analysis:
>
> 1. Messages which are requested in quick succession (associating messages
> that are requested together with the same group)
>

The DS can observe access patterns, but the important point is whether it
can then use that information to deanonymize users.

In a mix network instantiated with protocols like Loopix [1], users
generate and send dummy packets (i.e, cover traffic that is dropped at
random points in the network) along with real packets, all which are
delayed by some random time period at each hop in the path. So performing
end-to-end correlation attacks in such systems is harder.

However, even when Tor is used, the question is at what point the DS *can*
learn enough to deanonymize users if it can only observe access patterns
and any exposed metadata (assuming it cannot perform end-to-end correlation
attacks). See next.


> 2. How many times a message is requested (associating a message with the
> number of participants in the group it was sent to)
>

Note this problem of access pattern observability is not unique to MLS and
without the use of PIR, access patterns will be observable by any content
provider even when traffic is routed through an anonymity network.


> 3. Messages requested over the same circuit (Tor and similar networks
> often reuse circuits for efficiency)
>

This is only an issue in circuit-switched networks like Tor (where users
maintain a long-lived connections), whereas mix networks like Loopix are
packet-switched, meaning every message is routed independently. Further,
applications using Tor can rotate through circuits more quickly, if desired
(Tor Browser does this).

[1]
https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/piotrowska