[MLS] Authentication

Richard Barnes <rlb@ipv.sx> Thu, 06 September 2018 22:00 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 B82F1130F4A for <mls@ietfa.amsl.com>; Thu, 6 Sep 2018 15:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01] 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 ZjI1_Eg82PsP for <mls@ietfa.amsl.com>; Thu, 6 Sep 2018 15:00:55 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 4558C130F52 for <mls@ietf.org>; Thu, 6 Sep 2018 15:00:51 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id 13-v6so23654479ois.1 for <mls@ietf.org>; Thu, 06 Sep 2018 15:00:51 -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; bh=iQMAwjExDzYrkt91HThjXDZhzp6aLau3OFtzl4KlArU=; b=EVviScQYApb6U7YwYxe+xShY/Z4yIgwKfTqdE1Q7dkkqEI84TGfMATpX3TH9WsBdmE 5yFx/DCzkayAwm+7E2CMtLy8fmA+qnTddoXY2qte4toaFSIkjRAzJG2UdteewjUJC6X3 EOPAvaPGofXaihXNV3A1vXjn8+pAJkgaHpPNu52icshJrZSnNEklvkt0Y1piRhj1iSXs 6bbFBIazVqa2Tqtbjk4kucGzQ/axnWwnZA2CPVwLHxIjvAda1mNfcfOMMRRLLhsHpkHR x3FXxMr/uBVqRhB74qbOg4eO3q1g9SRkQ0o+0Wy6YV21Cb3nkYXqvMNNAyWyz6MUkdHP exlw==
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; bh=iQMAwjExDzYrkt91HThjXDZhzp6aLau3OFtzl4KlArU=; b=d4Oe0zuCYjPIEP+Fekpq3uGsEm+0KnVLMeL3f8ilb+YfAQ1D1oGqljnXksGFg6kJGA 7kVqtVXnuTz3WWkju+ywtCLAny+HPKsasxEEEnBYWsuC3vCjCH1ZxEJuAStgZ4r1YkbW kgL4cI32zdd5fOSYp+Bthxai973VBuFFq3UF9MQj5rlf4sRk6sjCu+nz4ymXhf7ttPvz joLQvu4aBasinsrVUB4NaM5Sk6lh2NQ3NYvO26DEZP8dua8Ok4Gli3tYAxE2mGtn4MMK ATBadn1UPy2D4OhTeCqLk62X8H5aQP7E8piJtW8sMayoC7wJFhKPiPVDTd4OYjeiQEf1 F6cg==
X-Gm-Message-State: APzg51D46TekrWB8FGvMcT7sgGC0rXbwiwMfuLq1tU2mD+kNNJFLlI98 NDJJdTnioKOQO6NWJeGtEuggKtsMuyErm47y6m9m7svF
X-Google-Smtp-Source: ANB0VdblpmNJyj4hpSksrFB3hsNe6nR25xiiuG5bfcVXEcktNVhLyInjXB9M5ihBk+ByzAaVEfIG4vFTZH8W72orUF8=
X-Received: by 2002:aca:3c45:: with SMTP id j66-v6mr4736304oia.118.1536271249818; Thu, 06 Sep 2018 15:00:49 -0700 (PDT)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 06 Sep 2018 18:00:38 -0400
Message-ID: <CAL02cgQeVdvpUrjbaQn67MoYMb1tzBZCPPsz3cvDpQxZ_kJijQ@mail.gmail.com>
To: mls@ietf.org
Content-Type: multipart/mixed; boundary="0000000000001fffb505753b068d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/2X4evZ7WfgtzAobr76eO6NzptXI>
Subject: [MLS] Authentication
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, 06 Sep 2018 22:00:58 -0000

Hey all,

I've been stewing about authentication for a little while, and I think I've
gotten to a point where I have coherent-enough thoughts to share with the
group.  (Though by no means final)  The attached PDF has some slightly
stream-of-consciousness thoughts about authentication for MLS, but it ends
up with (1) some crypto protocols with a degree of validation and (2) a
loose proposal and some questions for the WG.

Leaving the crypto details and protocol details for the PDF, the questions
for the WG are as follows:

1. Is there any reason to prefer one of the two constructions in the
document over the other?

2. The protocol enables agreement on a "roster" of participants.  Should
that roster include only identities of participants, or also their public
keys?

3. Can we rely on clients keeping around a copy of the roster, so that they
can then use it to authenticate future messages?

4. Should the roster be distributed by the MLS protocol, or should MLS just
provide a pointer?

5. Other than the roster, what information should we enforce group
agreement on?

The doc has some thoughts on the arguments on either side of all of these
questions.

The next step here is to generate a pull request that makes a concrete
proposal.  If folks have thoughts about the overall plausibility of the
analysis here, or thoughts on the design trade-offs highlighted above, that
would be helpful as I work on fleshing this out.  Hope to have a PR in
flight in time for the interim.

Thanks,
--Richard