Re: [MLS] Proposal: Proposals (was: Laziness)

Jon Millican <jmillican@fb.com> Thu, 19 September 2019 13:59 UTC

Return-Path: <prvs=4165350dc6=jmillican@fb.com>
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 6EDF5120090 for <mls@ietfa.amsl.com>; Thu, 19 Sep 2019 06:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=isRSpbad; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=GoexWPWX
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 kIX1MdhNQkVj for <mls@ietfa.amsl.com>; Thu, 19 Sep 2019 06:59:47 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124B912004C for <mls@ietf.org>; Thu, 19 Sep 2019 06:59:47 -0700 (PDT)
Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8JDwap7029007 for <mls@ietf.org>; Thu, 19 Sep 2019 06:59:45 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=aLOYuTAiahEf7MUqEpgb3wBDVVWSgCALNhl1gmv8yfA=; b=isRSpbadSGjVTiTcme0Bdnni2YhAT7ZXEakvm5SxSVWqDzFTAoD/25UEPbEwc2EKmwgU WJaXykSxLJXeqMyqb3AmXdaHS8TNxDKoXJCCDBAaB0hGYDnbYP0gAtn0Yp8bhv7Hsj2Z fJ+yg39YT7W4ccJlBs42cT/zKLr+FJbdQr8=
Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2v4as7g2h4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <mls@ietf.org>; Thu, 19 Sep 2019 06:59:45 -0700
Received: from ash-exopmbx101.TheFacebook.com (2620:10d:c0a8:82::b) by ash-exhub202.TheFacebook.com (2620:10d:c0a8:83::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 19 Sep 2019 06:59:44 -0700
Received: from ash-exhub201.TheFacebook.com (2620:10d:c0a8:83::7) by ash-exopmbx101.TheFacebook.com (2620:10d:c0a8:82::b) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 19 Sep 2019 06:59:43 -0700
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.36.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 19 Sep 2019 06:59:43 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RABlm7mx2iO4o5ykU6p6wHHjSz6bsvSyjUs7WF3l6iLfWHAeSFkN5g0M2xT3MJXJMnqL1la2Fs/ft5e7TZ5p38RntNbCfVqaW9AdQFRAc26c+RQF+cA080a3912JGGXZuPyYNuEuJ0CKct8Ym/L8GN1mNxVcwCwucTMfHbHvb1Yfaeuw7HbE2rz+LOGrKw7MuEG2KXC4LJyzz8F4+zBUWEeiIPf6ipIYzb5h9ZnBHBFkw9iyM+t+4by7Ee1OySh0OFs1GmdArYHf8+N/fYVOP8FgRvITgeDIVgB51FzA554tKd3Ks16wchvyVMSdkARhHhWDtAgp0yOLTcggzTzgZQ==
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=aLOYuTAiahEf7MUqEpgb3wBDVVWSgCALNhl1gmv8yfA=; b=JQo8XCqEHfX4DWHkANG01EqZi2HJfHehdGP8YWRGV2HdB0CBkhlWTod7B0KBmWG3K1ASID8uQpDYJgOm2mBjVzazIJaML7OQjhmjx5Us1dbcFBiJLTSvV13CoRbgrNZAunQaVj4lU2zGaPIDksJBB/yXgcmj7Bi4C29PB8sZrwjMDeKe9oEKJPx/svejxa2Afup2WjovDrmeEVTq367YkiVS+maqggAsvI77rsP2Lk3otCk3E1Q+TSCMeTPSx1SgLhLCVOSRU1u2Xhhv/KjQB8Is/0nKyn8NrwJP9fXBhnK3WkCdJMkZjoRsEVgs3XBQVTXnMKpM84gnf3UTcecgGg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aLOYuTAiahEf7MUqEpgb3wBDVVWSgCALNhl1gmv8yfA=; b=GoexWPWXQXxMmhwmTFGSRpBAbrauo5c+D3Pc6PYfgIQtJpDclHhaLEicisFvAbfc0tDVAKmCIZa7tRgKL+eZekxCboNzi3V3Ye/AiXLxNsVAw1kFY4+jnCQI5gBGHTbacxTAI0xZslv7kYKq7mnA61+6LjlhN6M94d/MzcPs70Q=
Received: from MN2PR15MB3405.namprd15.prod.outlook.com (20.179.21.203) by MN2PR15MB3280.namprd15.prod.outlook.com (20.179.20.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.26; Thu, 19 Sep 2019 13:59:42 +0000
Received: from MN2PR15MB3405.namprd15.prod.outlook.com ([fe80::74ac:89c2:b0d9:4099]) by MN2PR15MB3405.namprd15.prod.outlook.com ([fe80::74ac:89c2:b0d9:4099%3]) with mapi id 15.20.2284.009; Thu, 19 Sep 2019 13:59:42 +0000
From: Jon Millican <jmillican@fb.com>
To: "mls@ietf.org" <mls@ietf.org>
Thread-Topic: [MLS] Proposal: Proposals (was: Laziness)
Thread-Index: AQHVWTdobTpMInhPYUalq6nvDa7Ui6cIchsAgAAVaICAABFGAIAADluAgAACSICAAB07AIAAAumAgAAHi4CAACsVgIAAWwOAgAXuuwCABKrHgIAfUpaA
Date: Thu, 19 Sep 2019 13:59:42 +0000
Message-ID: <46673A73-0D73-4206-9DBE-009CA8B4F9B5@fb.com>
References: <CAL02cgSbgkYyMcm=w8+oF+R5GBKaaofV3_x_VF0rMc0jWhs+Kg@mail.gmail.com> <f9634330-93bb-df46-a37c-bdf19359c2e0@cs.tcd.ie> <AE4D69D4-F7BA-490C-887E-A557BAC656FC@wire.com> <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> <a76355f9-52bf-cdc8-5d34-43d7f647188d@cs.tcd.ie> <CAL02cgQ6m72u1ZU+qC2XHkxxMuA6+6+VMqcZfLmvmJYjf3H_8Q@mail.gmail.com> <f212ba04-87cd-c954-3072-9f4bf676d4d7@cs.tcd.ie> <CAL02cgSF_CWHkXY4dNjw53kzpHyL-5uBJxxHo1MtyAKcOYxjaA@mail.gmail.com> <752B7C91-19CF-45CF-8774-DED73A908A23@inria.fr> <CAL02cgQF42KDrXH8F0qt1_J0jhu0Cd18PNkN3+PsP1zW9uTLrg@mail.gmail.com> <9756C849-1248-4E2B-9509-07EAF59A0FC4@inria.fr> <6119dac1-2822-4756-b514-4bb500bbaf04@www.fastmail.com>
In-Reply-To: <6119dac1-2822-4756-b514-4bb500bbaf04@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c092:200::1:3050]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aa41e465-0d2d-40df-5453-08d73d099eea
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR15MB3280;
x-ms-traffictypediagnostic: MN2PR15MB3280:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR15MB328066FF30BDBD8BFCD6466BDA890@MN2PR15MB3280.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 016572D96D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(366004)(346002)(376002)(136003)(53754006)(199004)(189003)(14454004)(229853002)(2906002)(81156014)(316002)(7736002)(86362001)(8936002)(5640700003)(99286004)(5660300002)(6116002)(36756003)(2501003)(25786009)(6486002)(2616005)(486006)(5024004)(66446008)(446003)(46003)(14444005)(478600001)(561944003)(53546011)(606006)(6506007)(186003)(256004)(476003)(76176011)(33656002)(11346002)(76116006)(71200400001)(91956017)(64756008)(30864003)(66476007)(66556008)(6512007)(6436002)(81166006)(54896002)(966005)(2351001)(71190400001)(6246003)(66946007)(6306002)(236005)(6916009)(102836004)(8676002)(1730700003)(60764002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR15MB3280; H:MN2PR15MB3405.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 76Vu8nn/6RPYA4yRLNBj4n9k4HE+qz8ygkjCUpizdnXIG1cfQuMq1Qfsb+A1fNWfHD7M7duWrFevCCpIghWhPDrn5w+AMGaTexsWfHO/q4Wdh6/2fvo06DDDtsQssi9/cXvYI7iluPW0EgVqNKEPhnUzdDZ+av3LcpDoxGo62dG/g0WdHE9Kd1I4SXyBKBmqulSFWfQrjNcYulWyj+N+ntsnjHBhZJqFuVfowzUg95wu2o7shF0aCOEwvinQnltzqyTbgAUZ5zYx+/TYiNgyZdin3MakpouGBhR4WRJUFAn6D+gti9j2JReW+fEZAb1Z59x9UER42mbP/DGhGlseSQw5IHsyLnv46+BaKD6Igl+ORvN2NAjykCFTILwDmKlazSNjn+FLiXq3yDD5RKao6a6gLz3gYkUM4pjNZP4z2Qg=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_46673A730D7342069DBE009CA8B4F9B5fbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: aa41e465-0d2d-40df-5453-08d73d099eea
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 13:59:42.5482 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3qgCLa8kUHb5hZxGPDLFs1RAE6prBgQAS5cQOFGfcrEDw/AznohLMB2eXk+Mo1yWBhb/BcaA5IrFIAlhixYsaQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB3280
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-19_04:2019-09-19,2019-09-19 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 impostorscore=0 phishscore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 mlxlogscore=999 clxscore=1011 malwarescore=0 mlxscore=0 bulkscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909190132
X-FB-Internal: deliver
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/5Z_qfPLjzxl7GvBDh35zT3G-w_Y>
Subject: Re: [MLS] Proposal: Proposals (was: Laziness)
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: Thu, 19 Sep 2019 13:59:50 -0000

Sorry for jumping onto this thread quite late, but just a couple comments to add:

>  Can Update Proposals be issued by anyone but the member itself? If we say yes, the analysis will be more straight forward, but it is also more limited. If we say no, the question remains who can issue them. They could be issued by the server or another member. Right now I don’t see why another member should be allowed to do so, but I could think of reasons why the server should be allowed to do so (multi-device context). We should again be very careful w.r.t the ghost user scenario in order to avoid the possibility that the server can sneak in a malicious participant that way.

I don't see a good reason for anyone other than a leaf-owner to ever issue an update to that leaf. If we treat multi-device as a special case of group, then the server would also not need to do this – it could instead just issue adds and removes as devices change.


> Server add/remove is important in many practical use cases: you buy a new phone and log in; the server wants to remove your old phone from all groups it's in, and add the new phone.

To stress this point, server-controlled group membership is a practical necessity in many cases. I can’t think of any significant messaging service that does not allow account resets, and I believe the majority will allow multi-device/group threads to continue when this happens. For example, membership of a thread in Messenger is based on user account rather than device – if a device is attached to a given user account, then it is inherently in any threads that this user account is also in. Logging into an account is not a cryptographic process attached to some other device, but authenticating to an online service (e.g. username + password). I believe Wire follows the same model. In this world, a device which logs into an account needs to be able to not only receive future messages to that account’s threads (which could be achieved at the application level without server-add), but also to send messages to any of these threads (potentially before any other device in the thread has come online) – which would be more challenging to implement at the application level. For this reason, I’d strongly favour server add in the protocol.

Jon


From: MLS <mls-bounces@ietf.org> on behalf of Katriel Cohn-Gordon <me@katriel.co.uk>
Date: Friday, 30 August 2019 at 17:41
To: "mls@ietf.org" <mls@ietf.org>
Cc: Messaging Layer Security WG <mls@ietf.org>
Subject: Re: [MLS] Proposal: Proposals (was: Laziness)

This abstraction seems sensible. Server add/remove is important in many practical use cases: you buy a new phone and log in; the server wants to remove your old phone from all groups it's in, and add the new phone. Since we of course don't want to give the server the ability to actually effect this change, only to propose it, it seems to me that we already need a way to disconnect proposals and commits anyway. Once that's the case, it doesn't seem too big a leap to cleanly factor all operations into that structure.

My main worry would be complicating the analysis. However, it seems like if the separation is clean enough then it might not actually make the analysis too bad, because there is a clean property (that Karthik described) for each epoch change. So, on balance, I think I'm in favour of this proposal.

--katriel

On Tue, 27 Aug 2019, at 6:23 PM, Karthik Bhargavan wrote:

Hi Richard,

On 23 Aug 2019, at 18:48, Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:

Just to confirm I understand, the key exchange protocol in this conception would be something like, at each epoch:

1. KEM a secret to some set of people whom you believe to be the current members of the group
2. Send that KEM'ed value out to the group together with a description of the current membership
3. KDF the KEM'ed secret together with the prior epoch secret to get the new epoch secret
4. Use the new epoch secret to generate a confirmation over the current state of the group
Where the KEM in (1) would be something like TreeKEM or just "encrypt to a list of public keys".  Then the proposals would just be a way for people to sync up on who the current members of the group are (by leaf key).

This is essentially correct, of course with a bunch of details to guarantee that everyone gets the same keys.
It remains mostly unchanged from what we have currently.

The major thing I would be worried about in such a split is how it would deal with authority over changes, which affect the authentication properties of the protocol.  The current Proposals proposal maintains the property that everyone agrees on the proposals and can verify that they were proper, e.g., only the holder of a leaf can update that leaf.  If we sever the connection between the proposals and the top-level transcript entirely, then I'm not sure how you would continue to assure that, say, the sender of a Commit didn't just swap out Joe's leaf key for the NSA.

The changes would be signed by the sender, as usual. The only question is whether this signature is enough, without binding the signature to the key exchange transcript or current epoch secret.
Note that the tree synchronization protocol has its own transcript on how the tree has changed over time, and certainly we could require each update to sign this “state history” transcript.
We should of course impose the requirement that only the "holder of the signature key corresponding to a leaf” can update that leaf.
In fact, the tree update protocol can ensure that only members of a subtree can change the root of that subtree.
This is what we guarantee now anyway. I don’t see that substantially changing in the decoupled design.


I agree that there is degree of separation here (since, e.g., it's easy to imagine swapping in a "list of keys" KEM for TreeKEM).  But it seems like a fairly high degree of coupling is necessary to maintain authentication.

So, what would be the authentication property you would want for a tree change?
The tree changing sender must know the signature key for a member *and must also know the current epoch secret*?

Perhaps what you are pointing out is that we cannot remove signatures from the key exchange protocol, and so we’d end up needing two signatures; one for tree synchronization and the other for authenticating the key exchange.
Actually, we also need a third signature for the message protection. How and when we can share these signatures is an optimization problem, but they serve different purposes.

-Karthik


--Richard



On Fri, Aug 23, 2019 at 1:22 PM Karthik Bhargavan <karthikeyan.bhargavan@inria.fr<mailto:karthikeyan.bhargavan@inria.fr>> wrote:
Hello All,

It seems to me that one way to think about “laziness” would be to cleanly separate the MLS key exchange into two different protocols.
The first is a “classic” authenticated synchronization protocol where members of a group can create and modify a shared data structure (in this case, the group membership tree).
The second is a novel key establishment protocol where some member of the group generates a fresh group secret that will be delivered only to the current members computed from the (current) group state.
Currently the first and second protocols are tightly interleaved: every time the group data structure is modified by some member (or admin), that member must also generate and distribute the fresh group secret.
The laziness proposal can be thought of as detaching the two protocols: the key establishment protocol can follow group modifications with some delay.

So rather than trying to add “laziness” to the existing protocol, should we try to do this detachment in a principled way by defining two independent sub-protocols?
It would have the advantage that we may be able to consider other designs for synchronization and key establishment, which may well be orthogonal concerns.

In our model of MLS, we can already factor out the protocol in this way, but it makes the security invariants a bit harder to express in a user-friendly way.
Still, I would prefer to compose proofs for simpler sub-protocols rather than try to prove security for a single complex protocol with lots of options.

Best,
-Karthik


On 23 Aug 2019, at 10:48, Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv..sx>> wrote:



On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> wrote:

Hiya,

On 23/08/2019 15:10, Richard Barnes wrote:
>
> I'm not clear on what you mean by "meaningfully handled by members".
>

I'm assuming that MLS protocol data will likely be
handled by a library. ISTM more likely that such a
library might default to, or be carelessly used to,
honor anything the server proposes if this is an MLS
protocol feature rather than an application layer
feature. That'd be an example of not meaningfully
handling this:-) We have seen similar kinds of
failure with applications and TLS libraries in the
past where certs aren't checked etc.

Oh I see.  That would actually be a pretty difficult policy to implement, at least without turning off authentication altogether, at least in the envisioned protocol.  By which I mean:

- Right now, clients are expected to maintain a list of members' signing keys
- So signers are just indicated by their index in that list
- The obvious way to add non-member signers is to reserve a block of indices (say 0xFFFFFFxx) that can correspond to application-specific entities
- Then clients need to get configured with which server keys go with which reserved indices

Assuming we go in that direction, the natural, "I don't care about server-initiated stuff" library design would be to just not implement any special handling for those reserved indices, in which case you'll reject anything from the server.  I would expect a library that does anything else to have an API for the configuration required in the last point.

The obvious screw-up case would be, "Treat a signature from the reserved block as trusted".  But that's actually a little hard to implement; because the public keys aren't provided, you would have to also not do any signature verification at all, which means you're now totally open to the world.  Hopefully that would raise some red flags for developers.

So it's not impossible to screw up, but not trivial either.  At least if you want to maintain authentication for group members.  If you turn that off too, I don't think we can save you.

--Richard



I do accept the argument that it can happen at the
application layer if not defined in the MLS protocol,
but doing this kind of thing at the application layer
seems safer to me.

It's also not clear to me that all MLS applications
would need this feature. (That may be true, I just
don't know.) If they don't, then again, it seems to
be more conservative to leave it to applications.

I agree that there are sharp edges however this kind
of thing is done though.

Cheers,
S.
_______________________________________________
MLS mailing list
MLS@ietf.org<mailto:MLS@ietf.org>
https://www.ietf.org/mailman/listinfo/mls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=gabsgG53OsRWJChybmvBPhP4Bww6dRbrbur9MZMqSbA&s=jPen3uhkJSug-XGStQZg7vWn_ys1LeXbX5NwQS0CwCg&e=>
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls