[MLS] Exporters

Richard Barnes <rlb@ipv.sx> Mon, 19 August 2019 17:16 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 151F912004C for <mls@ietfa.amsl.com>; Mon, 19 Aug 2019 10:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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] 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 cZUJ6XD-iD4x for <mls@ietfa.amsl.com>; Mon, 19 Aug 2019 10:16:47 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 4081F120089 for <mls@ietf.org>; Mon, 19 Aug 2019 10:16:47 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id w4so2356860ote.11 for <mls@ietf.org>; Mon, 19 Aug 2019 10:16:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=lDiL+e/sOUvtJC+ps0ILLlppdFek4ofDZ2Rqo+IIDxQ=; b=kdHxBnTHI/V5RZ4jFq58FM/Ild9fKK1WaPPSfahT9i5TM+aQGK0+5o4XolaVLH2KQy a93QibVUhVmR2pkzRNjQVocY2e+XaRFoYENnY62agygc8nJGYZwEGES7byDiHsW05xsY MJLk65Pir4RgK88aTUP3CyTuIs/kEtxr2ZjCAbX1cMcpYFlh2BAxm+cNn6BZkbdEnTnr qekH4N5buBHEcO8clwNGEwTNTJlK9BFd2SJIOA4PGby/u0GKgfUuxk6nHPGz+eyLDfug RthJmi7ELUCmDtiOqxRbO3tuSUS54ZVoS9qhRoCaVdZCo7BetRI+7eut/3t89jEvCZjC lwog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=lDiL+e/sOUvtJC+ps0ILLlppdFek4ofDZ2Rqo+IIDxQ=; b=PndwdlpMswcvApohzX/FpzCcqA8C32WaZ9UWETOIIPD0T5FOPIvzc5PzM2+b5AQ6wR heGJEohnNBH/4Mnx76gyApYx0NyL1I5+x2QDpfvhxetWcy/tQc1jn64P/zCC2GvWA/no M9VYPF/tDd3KMnHTpsJXB5/HhFMk/rVQm0GztC6V9mVsavJdG2JZ3SpQH/7WmZoZg+QX WSgIBG5Qy2/G8DrKHSPbv37wj0nfHLemuSdEVjOiP9iYefLiyDGcP0hLLglDOsfbxnW/ rVh8VVxm6k1/B/iu3pnidlMDKv8VFUYIiYOKeGw0LCsA/SLauaDlrF6OaaVVuDBO8Wxi v7/g==
X-Gm-Message-State: APjAAAW3aE4pFC67uvOrRdazszlavg3gtSDniZUyGFGfAVr+2iobafxp u4greFstlOuY+PUeh8GYv07A2q0+vADcWI7+rLuH/A==
X-Google-Smtp-Source: APXvYqxydAKfqXnNEjX5WSk9xLwZGO7ZiB6FkElZwQaC50LSomJPtODNjf0kHKPvtOd7RZBNgtr6OjXfCDcjVGNm7MM=
X-Received: by 2002:a05:6830:1159:: with SMTP id x25mr645416otq.237.1566235006208; Mon, 19 Aug 2019 10:16:46 -0700 (PDT)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 19 Aug 2019 13:16:27 -0400
Message-ID: <CAL02cgQvNFJ_ceLtCajaCJqUZ88UDkxfXb6d4AYogrjYJ4DzUg@mail.gmail.com>
To: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002e3d0805907b81af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/p0OSPwUgIiMtEklyaY48SJJHyaM>
Subject: [MLS] Exporters
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: Mon, 19 Aug 2019 17:16:49 -0000

Hi Benjamin,

(Note: MLS list CC'ed)

Thanks for filing a PR starting work on defining an exporter for MLS [1].
In addition to the specific comments there, I wanted to raise some general
questions here on the mailing list.

Basically, what I'm wondering is at what point it makes sense to export
stuff from MLS -- effectively, what the "API" of an MLS epoch is.  It seems
like there are a couple of approaches you could take here:

1. "Group secret" -- For each epoch, MLS provides:
  - An authenticated list of (identity, signing key) pairs for members in
the group
  - A secret known to the members of the group

2. "Sender secrets" -- For each epoch, MLS provides the following for each
member of the group:
  - An authenticated identity
  - A symmetric key that the participant uses to send messages
  - A signing key

#1 is lower-level, and thus more flexible, but requires the application to
arrange things like per-sender keys.  #2 is closer to application
semantics, but makes life unnecessarily difficult for applications that
just need one key for the whole group.

Personally, I'm inclined toward a "#1+", in the following sense: We define
the exporter as the main way applications access key material, but since we
need a message protection scheme for handshake messages, we also define an
application that uses that scheme to send application data.  Which is maybe
just a fancy way of saying, "remove the `app_secret` and derive it from the
exporter".

If we can come to agreement on the right shape here, it would be good to
update the architecture document to reflect it.  In addition to making the
documents a bit clearer, I think we'd end up with more consistency in MLS
libraries.

--Richard

[1] https://github.com/mlswg/mls-protocol/pull/198