Re: [MLS] Hiding content type

Richard Barnes <rlb@ipv.sx> Sat, 25 July 2020 19:39 UTC

Return-Path: <rlb@ipv.sx>
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 4A6E33A09FC for <mls@ietfa.amsl.com>; Sat, 25 Jul 2020 12:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 Q1IYv3smXwzw for <mls@ietfa.amsl.com>; Sat, 25 Jul 2020 12:39:03 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 5F7043A09FB for <mls@ietf.org>; Sat, 25 Jul 2020 12:39:02 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id 11so11910521qkn.2 for <mls@ietf.org>; Sat, 25 Jul 2020 12:39:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VYAY0wgwy/sMHoCKFbwaMuQN6DIAeLmE4smQGz/ZHMM=; b=eK+lKO6QhJ2ql11rbOEM3RRLBS2Qrg/BHsK7k36lZfBnzANgiSoLaEpG4spdvU8Qda 7pO06+A0TbHrnYdg/rTQk2vSHbQtFxyRyoJ+guy++LIc3GsAZ38yEVHBRkDv0ECQupIU ciNVe/Rc7+QN/07efEawdl3MK7/KOvFrtQWIdo8r3BeWjTMmYdOOljOePnhC57BRnrxa bjoLXqTTnkMYO7hPIC5KRllQKQmeWpOsOS6Hm5V1iwzGtRBZdrgNgPR2mO9mwmUxZ8kx 89w/gi0C4KkRW+bsER0l/b/YoyZkGiTcozx5jvX4aUTI0xz6RnR1QN/ljz8NIKJbzPiC SVrQ==
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=VYAY0wgwy/sMHoCKFbwaMuQN6DIAeLmE4smQGz/ZHMM=; b=ndDKNtfMHDG5nlhFMOCHdwfn4T5b60XKzshsmUFFbNm5n9UDlODbu/pDTkSy1zVxQr v2yVTyFCljDyfedDSTlZsDfKf5/5LVRWiLAA7Cs+hJasEPj0QD6RXCTwRtVzNlixOvZl 7WROwlWklycICbLlyijV0kEyWC1lM5L1rbqCUsIzZxGRKjLjRf8l+KsqUPdXV3hfp0r1 YIY+EsWwXnW7pNlCHIFYE/2Rvl5QeLFh1LxcFs6KAD+DHUsdD43Mv/SXN4oiGAUVvb2T Eg9HaDHipEuEsqdIEY/u3sfkJklhdu5TBYegmNv+0VZZqC9wYQXgk3RtbyHxQhEtIPbW 8u2g==
X-Gm-Message-State: AOAM5339eq/2P1E85XG7vkZFxxm75Gd6mIMXZg9G2sda0jb9IugAErRd HTZkUOnDNOSNhrzQ6RQBIA5cBsQwd+WGOlPATu/Avw==
X-Google-Smtp-Source: ABdhPJzw/htNFYIyhDeNJ4GHDdgqweuvSkiFcrsSW+TR77Kj8Dl4rygJXI+ZorK0LgQA7ir2ozdNo/9j0nFiKoaTn0w=
X-Received: by 2002:a37:8fc6:: with SMTP id r189mr15869850qkd.159.1595705941917; Sat, 25 Jul 2020 12:39:01 -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>
In-Reply-To: <CABP-pSSQJ2dT2-mmvAYFYhvtVsRL9KWy71Zcfoxx8pMse2L=Kw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Sat, 25 Jul 2020 15:38:33 -0400
Message-ID: <CAL02cgRxXjoCQX3V7TTL9aW04ywFmwQvk3vRcMadQfpATfXwHg@mail.gmail.com>
To: Brendan McMillion <brendan@cloudflare.com>
Cc: "Hale, Britta (CIV)" <britta.hale@nps.edu>, Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d5957a05ab493d9a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/aNg3njWTffoIcX74YkF_Xli2zjk>
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: Sat, 25 Jul 2020 19:39:06 -0000

Just so we're clear, in your example, are you concerned about accidental or
adversarial collisions?  I hope we agree that we can fix the accidental
case just by making a longer epoch ID.  In the adversarial case, this seems
like a partial DoS at worst, since the members who incorrectly think they
are in the previous epoch will no longer be decrypting with the right keys.

As far as a positive example: Imagine a Generic Commit Sequencing Service
that provides a reliable broadcast/ledger over anonymous channels (e.g., as
an onion service), but will only broadcast/record one message for each
groupID/epoch.  If the groupID/epoch is opaque, then such a service can be
provided without learning anything about the groups it serves or their
evolution.


On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion <brendan@cloudflare.com>
wrote:

> Take for example, a broadcast channel that's ordered but lossy. A Commit
> gets sent where the new epoch id collides with the previous epoch id, but
> not all members get the Commit. So now the group is fractured and there's
> no way for members in the previous epoch to know that they missed a
> message. What the application developer needs to do to detect lost
> messages, is immediately re-implement the counter epoch id that you've just
> removed.
>
> That's an example of a system where this change is pointless / harmful. If
> you could provide an example of a system where the change is *helpful*,
> that would be more interesting.
>
> On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes <rlb@ipv.sx> wrote:
>
>> I'm honestly really confused by the worry about collisions here.  The
>> current epoch ID collides trivially -- it's just a counter!  And the group
>> ID is assumed to be public anyway.  So if your authentication scheme is
>> broken when you have a (group ID, epoch ID) collision, then your scheme is
>> already broken.
>>
>> If we're going to block this change on this basis, then we need to see
>> clearly articulated an authentication scheme that is secure in the current
>> model, but broken in the case where epoch IDs are derived off of the key
>> schedule.
>>
>> --Richard
>>
>> On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) <britta.hale@nps.edu>
>> wrote:
>>
>>> Ensuring the most conservative design by default seems advisable;
>>> however it is not clear that this proposal for hiding content type is
>>> actually doing that. Indeed, if an application is concerned about hiding
>>> the content type, would not that same type of application also be concerned
>>> about collisions?
>>>
>>>
>>>
>>> As Brendan notes, we are not talking about accidental collisions here.
>>> Pre-computation is entirely possible, such as by a malicious group member,
>>> so the window of attack is not limited to one epoch.
>>>
>>>
>>>
>>> If this is this PR particular is of particular interest to some, then it
>>> would be good to see a clarifying explanation as to the security it
>>> achieves (i.e. why this is “security by design” despite introducing such
>>> collision possibilities), or a concrete use-case. Alternatively, are we
>>> really limited to a 64-bit field, or can that length be adjusted to
>>> mitigate the introduced problems?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> A clarifying point for those following this thread: some references in
>>> the email chain state that this is encryption of the epoch ID. That is not
>>> the case. The proposal being discussed is about a hash thereof (hence
>>> discussion on collisions).
>>>
>>>
>>>
>>> Britta
>>>
>>>
>>>
>>>
>>>
>>> *From: *MLS <mls-bounces@ietf.org> on behalf of Brendan McMillion
>>> <brendan=40cloudflare.com@dmarc.ietf.org>
>>> *Date: *Monday, July 13, 2020 at 9:37 AM
>>> *To: *Richard Barnes <rlb@ipv.sx>
>>> *Cc: *Messaging Layer Security WG <mls@ietf.org>
>>> *Subject: *Re: [MLS] Hiding content type
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> The issue isn't with accidental collisions, it's with malicious ones. An
>>> attacker can purposefully (and quickly) generate commits that create
>>> duplicate epoch ids, and send them to a client to corrupt their group state.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> It's not just being more conservative, you're making changes
>>> specifically for very niche use-cases where I don't think the security of
>>> the whole system has been thought through. Maybe you have an example in
>>> mind, but I can't think of a system where this change provides any
>>> additional privacy.
>>>
>>>
>>>
>>> On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes <rlb@ipv.sx> wrote:
>>>
>>> On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion <
>>> brendan@cloudflare.com> wrote:
>>>
>>> With respect to using an opaque epoch id, I believe this was proposed in
>>> #245 <https://github.com/mlswg/mls-protocol/pull/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.
>>>
>>>
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes <rlb@ipv.sx> 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] https://github.com/mlswg/mls-protocol/pull/349
>>>
>>> _______________________________________________
>>> MLS mailing list
>>> MLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mls
>>>
>>>