[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
- [MLS] Authentication Richard Barnes
- Re: [MLS] Authentication Raphael Robert