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 >>> >>>
- [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Raphael Robert
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Hale, Britta (CIV)
- Re: [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Chelsea Komlo
- Re: [MLS] Hiding content type Hale, Britta (CIV)
- Re: [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Richard Barnes
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Chelsea Komlo
- Re: [MLS] Hiding content type Brendan McMillion
- Re: [MLS] Hiding content type Chelsea Komlo