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

Richard Barnes <rlb@ipv.sx> Fri, 23 August 2019 14:48 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 2DC801200E6 for <mls@ietfa.amsl.com>; Fri, 23 Aug 2019 07:48:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 PZpjaQTOQe7G for <mls@ietfa.amsl.com>; Fri, 23 Aug 2019 07:48:24 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 B9DEE12006E for <mls@ietf.org>; Fri, 23 Aug 2019 07:48:24 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id c7so9013673otp.1 for <mls@ietf.org>; Fri, 23 Aug 2019 07:48:24 -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=GACZjhn5sY4wL6MUY+neHQDp7etLDMrXGNHpwLtiu0E=; b=kBqbSDEoIv4dqA0qqqozf+YHiAt5+Wqhvszyeb18aMmr+uWP+9QuzGl8XV++XqZtem njw6rdLwKvYVhgbG4u6dwlQBZefQf2Bg0FqcF7Zp/62GsbUHagCZRpRlRyq75SSTnF0C JUDJEhjknfU1yz9V9Ii5kgCNJRPwBZ5nufZ6gfDl2msq3o7I8oN686Wwhpw911SY7Fyd 5SHEoXtqSOAK5rnXOfocLRtyLYaXhSkTEW2ewSdiCZwstvQAAhu1pHcL4eWo2rwdIs3X d2R+CT0JvtOm436lBO00GdMtuF6z7GawGgMe8H1fsx+D2Tsh0j4pfPzWY6Qnu9BEG0Ym Egjw==
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=GACZjhn5sY4wL6MUY+neHQDp7etLDMrXGNHpwLtiu0E=; b=QUUV9q9eE98KKjgQAywDdSZ258YgdptsF28Cjx2KyTpcaN2Bu6XFGS5vJKy6GWWmI0 5eL7uRL4OGVOdZHzd26YHi8tIXiYQXgTWu9H9u2mGxPKMFcPJQHikD5s8n04CifeJp6M ZxQ0cyg6QGAVVemWoIybl1FMOKmQUtx3JK2dOYrVaZHQmF+X/9OQby/+UWQpe27xxcGS og5Ch7Qjs6lyeTQXd9CTAAgPEeEwp7ZURSkrqBic8zBY3//31jmnlZ0j0wAmU0KBhpWZ VituLTrZraSvzZzugVPsa1B2TnjIhI6N8snWGjkeky5ikRf7xhgs/AcwpeJY+kgpLwka MgNA==
X-Gm-Message-State: APjAAAU4uenLBRMQm9ZZRK25hFCyZRpfuKZlg/JATWiCMDoQ54TCVZrm +/2ZhplODvMvMeAOIrBvFrV+Pl1WN0jh73L+sFjpjA==
X-Google-Smtp-Source: APXvYqwXQ2WIVh6xOgoH5G8NWgb0PEwd2rMw0fkTsR2gl+ZJQG3Z2+IqpFORO4sWjTHQ4bbdAlJy+4h8CpLr867wjmg=
X-Received: by 2002:a9d:7b44:: with SMTP id f4mr4299017oto.42.1566571703911; Fri, 23 Aug 2019 07:48:23 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <f212ba04-87cd-c954-3072-9f4bf676d4d7@cs.tcd.ie>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 23 Aug 2019 10:48:05 -0400
Message-ID: <CAL02cgSF_CWHkXY4dNjw53kzpHyL-5uBJxxHo1MtyAKcOYxjaA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Messaging Layer Security WG <mls@ietf.org>, Raphael Robert <raphael=40wire.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ed56ac0590c9e542"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/qZImi0Ty7l9G76KJKhy-F89hqQg>
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: Fri, 23 Aug 2019 14:48:26 -0000

On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell <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.
>