Re: [MLS] Hiding content type

Brendan McMillion <> Mon, 13 July 2020 14:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 853683A09BE for <>; Mon, 13 Jul 2020 07:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IPR1La5dT6bq for <>; Mon, 13 Jul 2020 07:57:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28DDA3A09E8 for <>; Mon, 13 Jul 2020 07:57:41 -0700 (PDT)
Received: by with SMTP id a32so10150103qtb.5 for <>; Mon, 13 Jul 2020 07:57:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LF6lrrU4ITBx/LDF52PGrxzhdb6RpjebhcO+/g/HhMA=; b=hGyuoPQwFc6PIrzB9fM427y32VUCMxY0squdZOiyjb0Im2rHCxCeaE+EjudIElmfCc 0V0U2JQA2FV1Eb96y5V8PJ/8FU57XHdjdo+8sW6FALuLw2SwXeJfZcXR5czIZTkWClRA 2dATR1r0ZgPtfbU3jtHaR5rFvkLCMqIq3MDjU=
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=LF6lrrU4ITBx/LDF52PGrxzhdb6RpjebhcO+/g/HhMA=; b=Kij4NSyHLGL2sNPXqm93uVtKa8j/Zu09Ou6UYmXNRt4Y9yHxiE3pYRQSR/KqEAmwe5 GUqJ1zCgJXi+a2x8CKMWsgzjHgOkglvr14DFMmzDWw9CEZbfpX9u5naE3wRxrw5cRTfP gdt2dRlIubmCH6pfUavdZJ6zrTISQcdnkQ3tiCUj8NdyeC7/ZBZaE0ua08VS5fH1PhSG yBTgjvkHu75CgAf5qGmLSn8S4DK8sZaIR07yzeGAjL0XAc1PMbB85s9LgdRNJhrTIv0C K22K4HPbNkW5mZSrg2XZT7ix5vT5v1IF7Ki+InyjZDce09M2izLT8ZtmIg/uIyRHSNl1 5dbw==
X-Gm-Message-State: AOAM530wmOx0/pZVsyWIOD53nlyrp1ekUJqd3Z2pKhO4/PqhLDoOasDD qyngb3odzeAlsY5QXPF2g2Uud2FFZK7X4aNyE6caZ5MjnA4=
X-Google-Smtp-Source: ABdhPJz/SvMQkxHNGOvZEXMdfouutVegcwdFnAQ+sltrzzoaTYfhXLxEH/mOoE85qyqgQh/ii4h8dzNgni8U8VdB7yo=
X-Received: by 2002:ac8:d86:: with SMTP id s6mr56225547qti.343.1594652259191; Mon, 13 Jul 2020 07:57:39 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Brendan McMillion <>
Date: Mon, 13 Jul 2020 09:57:28 -0500
Message-ID: <>
To: Richard Barnes <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="00000000000073487f05aa53e9f8"
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 14:57:43 -0000

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.

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.

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