Re: [MLS] Hiding content type

Richard Barnes <> Mon, 13 July 2020 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF60B3A1518 for <>; Mon, 13 Jul 2020 08:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 IbYKKbro9pBG for <>; Mon, 13 Jul 2020 08:57:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D3693A1489 for <>; Mon, 13 Jul 2020 08:56:56 -0700 (PDT)
Received: by with SMTP id z63so12631986qkb.8 for <>; Mon, 13 Jul 2020 08:56:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oSSFSkl31s4xC8gYy5d/0zsCV/0h35AkfZeX1Qmi6f8=; b=YIeM/oN3O12GzItPh4csnedv7re0Lr4LqPrYNaZhNpQpwJiKokq88KOdpLQ9lBTals FmuQMSROutD8PtiAJWF5XIjWxKU6Y4DIiBNs6lpWNpcmYD2UKNstzLKmlfGXi4ioVzu1 AcuxPiIE+GCJ2MmJmnL48KYajpjO42lCPVDzS/46wVAhKP0aK+WtyNqhoP5GbLLXXPsB qEk+5kHVepyXcFBpj7sS5HGNALm2Dn+McKFozl0Iw95+Vm5B6DNdnAcl1aWohNeNcYlb 5AUKqs0tgDc/mqejvc3hutYHKKlqXGg/JNWpNAjYQz8pdqKiiFcix8W6EIE7wJ8cSyL5 E4MQ==
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=oSSFSkl31s4xC8gYy5d/0zsCV/0h35AkfZeX1Qmi6f8=; b=puGL4NFN67HOan63mMWH/fr0pgL1fb6zNR92zYeXSHtDcNl7X/dKfPGd/MK+aocLVm K9TPxh9royUA1TkZ4OXiN/+tOQJUYtAr+8g2LTeLYbUNas+KCo93JjuFzpGlFrltYPa5 jRkTQVmYQIyoiMceCzc1xoiGuIJb68c9gYHWMxTbTJHOiyzZ4S7M5PALLXl5uwGlU+JZ 8npNQ7PME0Hvs5O/M6RzbxGKS+zLJFX7m/TPibfAdTg45jrrOzySWo0IFThemPoxKrFY XTNWmDUQOmuWZP5bfA0lL7+UaPpO/y2mlodotRkOWEzbllhR5GZif2RCJ+OmTU0RhbSQ 0Wcg==
X-Gm-Message-State: AOAM5316I48ob7gZBoTtB3C1od0kkSFq7NPl5b8OGXF7uxclxFkVSk0W D/Zvi/TGXwkqKU+p9Mt+qqXZGYGBVKEwW2G+92IFj9YM
X-Google-Smtp-Source: ABdhPJxiwFBKoeRykHUzHMf27OEzoqXsD3BhM8QOsG1SQeNTodkoLsQB9K/oxBxMybl2uQsMj+oJ7UL5woGywBs+3u8=
X-Received: by 2002:ae9:e517:: with SMTP id w23mr227344qkf.159.1594655815881; Mon, 13 Jul 2020 08:56:55 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Mon, 13 Jul 2020 11:56:35 -0400
Message-ID: <>
To: Brendan McMillion <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="00000000000071e8d805aa54bdf2"
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: Mon, 13 Jul 2020 15:57:09 -0000

On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion <>

> With respect to using an opaque epoch id, I believe this was proposed in
> #245 <> and consensus was
> against it because it makes it more difficult to implement the DS. It's
> also not clear to me what security properties you want from an opaque epoch
> id, because the current PR doesn't provide collision resistance and I'd
> expect this to be a source of confusion and bugs.

I think the discussion on #245 got derailed a bit by the focus on
non-linear epochs.  The point here is that even in a case where you have
linear history, I think there's intrinsic value in the epoch ID being
opaque because it gives intermediaries less opportunity for ossification.

As far as collision resistance, I'm not too worried about collisions among
64-bit random values, especially as the scope for collision is fairly
small, arguably just one epoch.

> With respect to encrypting the content type, it also seems to me that this
> would cause issues because different content types have different delivery
> guarantees. Specifically: messages are allowed to be unordered and lossy,
> proposals are allowed to be unordered but not lossy, and commits are both
> ordered and not lossy. In the deployment scenarios we've talked about, the
> DS essentially always needs to know the content type to provide this.
> Conversely, you don't get much additional privacy from encrypting the
> content type because an eavesdropper can see the epoch id change and infer
> which message was a commit, or see a dropped message getting re-sent and
> infer it was a proposal.

I don't disagree that there are different guarantees you need, but like I
said, I think the idea here is to be conservative by default.  There are
systems in which you can hide the metadata you're talking about with things
like mixnets and dropboxes.  Keeping the ciphertext as opaque as possible
keeps the door open to running MLS over those systems without MLS's own
metadata undermining their privacy properties.

FWIW, in the systems I'm looking at building, this PR does not make any
difference, because clients use separate channels for Proposals/Commits vs.
application data and the server doesn't check.


> On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes <> wrote:
>> Hi all,
>> Recall that PR#349 does two things (1) use an opaque epoch ID, and (2)
>> encrypt the content type of the message (application / proposal / commit)
>> [1].
>> There was some discussion on the call last week that encrypting the
>> content type might not be that useful, since an application that relies on
>> a server to assure ordering of commits will need to at least be able to
>> tell commits from other things.  Of course, even if the content type is
>> encrypted by default, the application can add it back in authenticated
>> data, or in some unauthenticated wrapper.
>> Net of those considerations, I'm personally still inclined to merge the
>> PR, to have a conservative baseline.  But those on the call thought it
>> would be useful to pose this to the group, so please speak up if you have
>> concerns.
>> --Richard
>> [1]
>> _______________________________________________
>> MLS mailing list