Re: [MLS] Hiding content type

"Hale, Britta (CIV)" <britta.hale@nps.edu> Tue, 14 July 2020 14:38 UTC

Return-Path: <britta.hale@nps.edu>
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 0EE4E3A08A3 for <mls@ietfa.amsl.com>; Tue, 14 Jul 2020 07:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 a9yeZv3TAn48 for <mls@ietfa.amsl.com>; Tue, 14 Jul 2020 07:38:57 -0700 (PDT)
Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 11E323A0896 for <mls@ietf.org>; Tue, 14 Jul 2020 07:38:56 -0700 (PDT)
X-ASG-Debug-ID: 1594737536-0e39451ec704070001-bGA3T6
Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id vbwSxql3vPySq3iN; Tue, 14 Jul 2020 07:38:56 -0700 (PDT)
X-Barracuda-Envelope-From: britta.hale@nps.edu
Received: from synergos.ern.nps.edu (172.20.4.116) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Tue, 14 Jul 2020 07:38:55 -0700
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Tue, 14 Jul 2020 07:38:55 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kcT4rftgw4aG63FnHvmwcfnQuabzbze71Cwm/j6mMUTl6D7656uu70LBtGNP71+p/1xl11zZOYybUywBHihhWADsea/ZMl4dUAV+TeOrzSwWtOMtweVMILAx5Z5Tb9Q0n3lGfVvU1gZiMhdgUTqTVYBpZ6u44nHi7zM9FsbwRNedVkg7RmXeCfeApY11bc/KrHYgPmFCdegcGNM5zuqKJnw+bDWdHq8pbU2lR/wtxe5es1gvRCcjO4YYRtpo9Z4iZmZuIxHrUX8lKdbGMjWdKiX3k3mCY1hclpxH7vK3/TBhn9a6FnLvaMfPbHdQf1ny6O4esFQyeZRgIbdm0KSRsQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qpj0OJAZcFVZTub43HBlcV5KKSD+sJfe3VWs5Q6qqAA=; b=NdiWf5sHYzcf52P7NoRAkwPjbK13sDdpKh+2IV02vzKtEsWHb98/tTftGVCnS+Oewjk9oMX1aXFEhhkv8It3hLbJMI7zttYi7OfSi7/ocKOmd8D+ZqGpX+atAlIV8839ryvCM+AzmGudn45KTl4T4MXPvFNLynf72ejbuv0ZnX0Fd6zUCp8uSRPOxx0oIfMGuFEVBQm+423cP9A02wy6BQgkPRo4cAtGJGrzbQLlWusKcxeLNZOgwpJanm3UrsTYin0kBM6pzvcnz/iBB0rEgsFpAQaR6VbH2/33x3yx5EdO54qhkQ8tizlKu2if/07+YDSKlaYBFq/OTODtk3WPjw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none
Received: from DM5PR13MB1066.namprd13.prod.outlook.com (2603:10b6:3:78::16) by DM6PR13MB3692.namprd13.prod.outlook.com (2603:10b6:5:229::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.10; Tue, 14 Jul 2020 14:38:53 +0000
Received: from DM5PR13MB1066.namprd13.prod.outlook.com ([fe80::c5c2:1037:89ad:ad00]) by DM5PR13MB1066.namprd13.prod.outlook.com ([fe80::c5c2:1037:89ad:ad00%4]) with mapi id 15.20.3195.017; Tue, 14 Jul 2020 14:38:52 +0000
X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:5:229::7]
X-Barracuda-Apparent-Source-IP: 2603:10b6:5:229::7
From: "Hale, Britta (CIV)" <britta.hale@nps.edu>
To: Brendan McMillion <brendan=40cloudflare.com@dmarc.ietf.org>, "Richard Barnes" <rlb@ipv.sx>
CC: Messaging Layer Security WG <mls@ietf.org>
Thread-Topic: [MLS] Hiding content type
X-ASG-Orig-Subj: Re: [MLS] Hiding content type
Thread-Index: AQHWWR1miPCJW/kzdkaeKDSwZdPxN6kFmZ8AgAAQhICAAAtsAIAA+9iA
Date: Tue, 14 Jul 2020 14:38:52 +0000
Message-ID: <FCAAD638-E0F8-4A91-90F1-1A2F1233D88F@nps.edu>
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>
In-Reply-To: <CABP-pSR2UxWkKk6a_T9vN4cv89zCchNbN4YN=dS_qm5Ye4AjJA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.17.200615
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nps.edu;
x-originating-ip: [2601:647:cb00:2941:5de6:2854:de7d:b513]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4feed8c0-6a70-4f6e-6ea1-08d82803a151
x-ms-traffictypediagnostic: DM6PR13MB3692:
x-microsoft-antispam-prvs: <DM6PR13MB3692C3178A0B96E26A804C94FB610@DM6PR13MB3692.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ipPy8LISYadsGz7+Ts4MMMN9qDYVeOSRl+YBu/0ZajJ/Gbw92MgbvJ5uVGpsBAxHHP/HN77e9D33q9jyYImYwdkBIuxni0Dih726hqK1gcLACeyzE01IJZs1BUWnoVgVLRTN3PDOsBMLetKxqjqeJ/XO/kfVOpoHYTPkrZx5NzIel6nLZjSLs+e6ni575d5t7v8ivNODsTXthFadux8MbSOMduxRriocmof/SrosgrnWBb24iG5V/Mc/GrAYMWosonTk7gvcLf8iXzkfuxW8CmbR6JtE2oNxto3m2WY5/wAZF/hHE5dN9UTcqJbg2hkDBwRIlnGffTTjdNEdby9TUD1RLlTMaLv7xbMHAGs5xxNyw1z7WqGTK8l1q0P4AwoXiScxwcHibajThdmjj3isYg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR13MB1066.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(110136005)(8936002)(75432002)(2906002)(33656002)(86362001)(36756003)(4326008)(966005)(6512007)(2616005)(5660300002)(83380400001)(498600001)(6486002)(186003)(166002)(71200400001)(8676002)(91956017)(76116006)(64756008)(6506007)(66446008)(53546011)(66476007)(66556008)(66946007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 7lDc7WeZZUlqBaKdiUNEQL99mdJWCXyVAnpIdOFKFmD6Gu0TsaMxbukqXVJngfJrdGlPvPfBxtwhCYLn9nNLWAuPvn1KTJDXNc6jqa5mIpQA4hvdvc93EFMYzFAGKQLC1p6iUXexKScxM3WjW/ZRIkLZekcBkGjHfgAGC+2kxJHVIm4B/GEHXOsSM7ilCLN7MPMsJSyD8I3SBqFQtsVskQFcfcfTI6DxTFykKWZKEKPS6CnTomqjN7CsZvvM73PthoR/1rmZibqSvQ3UC4y5Cbwg6H92EjTEaMVD/PmDsrkrNVlNgeXHGCzV1lhVyxADI6F5xAjFa+pqHV3kNaQsgSOO6Q9aDtLsQCf7tgwYWhT5YCSR7Lg6ve7rRyUrpEyAikrPG+NyXGZ0TsKj99zMyGPDsBsu7TuW+6z6nKdaUxv5aA+/kB+Ec4nZ5HIOm2tfhqGFylg82F0dOo8zw4xTLPg1lbnrM8+trmMTFaOkYXFMRZgLfhYcFuP65rHVgtECN69ZFlMEnq8PDpV1IxsqCBNKQQvmZmymRr90vKtG4MHvODpwopdvZvbubfqpNnjI
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_FCAAD638E0F84A9190F11A2F1233D88Fnpsedu_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM5PR13MB1066.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4feed8c0-6a70-4f6e-6ea1-08d82803a151
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 14:38:52.7937 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6d936231-a517-40ea-9199-f7578963378e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tO5nfXpEBFTCS9Ss+5jfyUMdk+uHeOTGN5IsUHVppGHNrnZTcjPetX2l8Sz/s3iaHb+i9FKL08FGNjsFuZ/b5A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB3692
X-OriginatorOrg: nps.edu
X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117]
X-Barracuda-Start-Time: 1594737536
X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at nps.edu
X-Barracuda-Scan-Msg-Size: 17536
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83193 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/IZTIKW6Dvgq9a6CosVsy1zUV2js>
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: Tue, 14 Jul 2020 14:38:59 -0000

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<mailto: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<mailto:MLS@ietf.org>
https://www.ietf.org/mailman/listinfo/mls