Re: [MLS] Revised MLS charter
Richard Barnes <rlb@ipv.sx> Wed, 18 April 2018 15:18 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 5ED74127337 for <mls@ietfa.amsl.com>; Wed, 18 Apr 2018 08:18:36 -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 Ey-lOU7WNA7H for <mls@ietfa.amsl.com>; Wed, 18 Apr 2018 08:18:33 -0700 (PDT)
Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 F259B126BF3 for <mls@ietf.org>; Wed, 18 Apr 2018 08:18:32 -0700 (PDT)
Received: by mail-ot0-x22b.google.com with SMTP id h55-v6so2310071ote.9 for <mls@ietf.org>; Wed, 18 Apr 2018 08:18:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Myq9YQ8EHi08EqOJuj3TdoQxxW76BMNbIZBpl/XzvAE=; b=ybvtUVLBaqfvmZ2UJS7P2RqSzhrPgoC4x+eWc1JBLoq3kn3VSXoEPbPATXKQYu0SvL SwtNSCzOPdG1beK5B/wcKVuCdYeh2e9pO6TsTOmdDS3i0tebm4LR/DB7LWw59WpEP1iE K3zF6lrOLFg2QmzJdDvcT3avjy4gkqqRuF168dGEYq0DbY9iDfFMvICF1W/qgcvdUgsn x1x8XdPcyqWtt+VRuZILHjU1Fs7TWeaAheK+pcvtKqwEgyQTkh8jPHqz84ZiImAZCUQ9 IyZaGluudltkwzhQRz+tG4y7INOA7tToPS0Va9++FfIMz091MtsEPQpHaJs8XuDrkQgm 1gSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Myq9YQ8EHi08EqOJuj3TdoQxxW76BMNbIZBpl/XzvAE=; b=pm2/9fFySxoe+7S0f2quHOqHlZzm8X87V2WfMiwUGzdO6ThCTc/VOEFC0q8p//SL2u 8ibehKmafOTrzgThfzmrPaXYlllis1+47NzdDO6x1qUMETIYycw0lzcTEdFoIe8POJGS EP/AEiYhMR/g/ipo4rm0rQZrStkdGb0Bsa/WIIrUwFXCIu/+7FLpU3m4yZWz0u3eKHnu x5LUTm2yXuBdIq+RYxfjWao0v4g/D9vbMCvws2KQNA5jCG05mn+Tlui/5+rBMz8n3lzm 9j8XPDZTVsOL6gqFwOFBhaSgevKBBDMjfVgc5L/vi8F1P0KmBJzwnDf+ACg2KF5kGtxU gW7g==
X-Gm-Message-State: ALQs6tAUHsBF+0mDqlEhjhdKoJKlWrvWEzBw8tJZkdfQC3kc3063RXth dVvDHMxlSjkLGdtz4H1LfBBips938sxqTH1oLTc5hiwC
X-Google-Smtp-Source: AIpwx4+t1ggXBTLYxZ7+fVdK2TpAs71AF7Ih+CaU/0jqFcvG7Br3IMlXbV4xP0FyMZIdzWHaz6eaTIKdIu1Jtc+HG58=
X-Received: by 2002:a9d:5403:: with SMTP id j3-v6mr1644710oth.52.1524064712030; Wed, 18 Apr 2018 08:18:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.201.93.90 with HTTP; Wed, 18 Apr 2018 08:18:31 -0700 (PDT)
In-Reply-To: <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com>
References: <E66143BE-F9D8-4073-A83E-10B4344BF15D@sn3rd.com> <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 18 Apr 2018 11:18:31 -0400
Message-ID: <CAL02cgTugFZ18cJ_9Zi0syRT7kNk_Jjko9WEkOwpCSVMjJQYrg@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: mls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c69167056a20f788"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/dIOhG0btVo-5H7YK3S_k-T0XvoI>
Subject: Re: [MLS] Revised MLS charter
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 18 Apr 2018 15:18:36 -0000
Hey Sean, This looks good to me. Ship it. --Richard On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner <sean@sn3rd.com> wrote: > Sorry I missed to minor edits from Jonathan Lennox didn’t get copied over: > > Messaging Layer Security (MLS) Charter (DRAFT) > > Several Internet applications have a need for group key establishment > and message protection protocols with the following properties: > > o Message Confidentiality - Messages can only be read > by members of the group > o Message Integrity and Authentication - Each message > has been sent by an authenticated sender, and has > not been tampered with > o Membership Authentication - Each participant can verify > the set of members in the group > o Asynchronicity - Keys can be established without any > two participants being online at the same time > o Forward secrecy - Full compromise of a node at a point > in time does not reveal past messages sent within the group > o Post-compromise security - Full compromise of a node at a > point in time does not reveal future messages sent within the group > o Scalability - Resource requirements have good scaling in the > size of the group (preferably sub-linear) > > Several widely-deployed applications have developed their own > protocols to meet these needs. While these protocols are similar, > no two are close enough to interoperate. As a result, each application > vendor has had to maintain their own protocol stack and independently > build trust in the quality of the protocol. The primary goal of this > working group is to develop a standard messaging security protocol > so that applications can share code, and so that there can be shared > validation of the protocol (as there has been with TLS 1.3). > > It is not a goal of this group to enable interoperability / federation > between messaging applications beyond the key establishment, > authentication, and confidentiality services. Full interoperability > would require alignment at many different layers beyond security, > e.g., standard message transport and application semantics. The > focus of this work is to develop a messaging security layer that > different applications can adapt to their own needs. > > While authentication is a key goal of this working group, it is not > the objective of this working group to develop new authentication > technologies. Rather, the security protocol developed by this > group will provide a way to leverage existing authentication > technologies to associate identities with keys used in the protocol, > just as TLS does with X.509. > > In developing this protocol, we will draw on lessons learned from > several prior message-oriented security protocols, in addition to > the proprietary messaging security protocols deployed within > existing applications: > > o S/MIME - https://tools.ietf.org/html/rfc5751 > o OpenPGP - https://tools.ietf.org/html/rfc4880 > o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html > o Signal - https://signal.org/docs/ > > The intent of this working group is to follow the pattern of > TLS 1.3, with specification, implementation, and verification > proceeding in parallel. By the time we arrive at RFC, we > hope to have several interoperable implementations as well > as a thorough security analysis. > > The specifications developed by this working group will be > based on pre-standardization implementation and deployment > experience, generalizing the design described in: > > o draft-omara-mls-architecture > o draft-barnes-mls-protocol > > Note that consensus is required both for changes to the current > protocol mechanisms and retention of current mechanisms. In > particular, because something is in the initial document set does > not imply that there is consensus around the feature or around > how it is specified. > > Milestones: > May 2018 - Initial working group documents for architecture and key > management > Sept 2018 - Initial working group document adopted for message protection > Jan 2019 - Submit architecture document to IESG as Informational > Jun 2019 - Submit key management protocol to IESG as Proposed Standard > Sept 2019 - Submit message protection protocol to IESG as Proposed Standard > > Cheers, > > spt > > > On Apr 13, 2018, at 14:09, Sean Turner <sean@sn3rd.com> wrote: > > > > All, > > > > The charter tweaks made since the BOF include tweaking (and reordering) > some of the “property” bullets: > > - added message confidentiality > > - message authentication changed to message integrity and authentication > > > > I know that Ben Schwartz mentioned that we should look at our “full > compromise” definition, but in reviewing it the way it’s used in FS and PCS > property bullets it looks okay to me. But, maybe Ben can elaborate a bit. > > > > Anyway at this point, here’s what we’re working with: > > > > > > Messaging Layer Security (MLS) Charter (DRAFT) > > > > Several Internet applications have a need for group key establishment > > and message protection protocols with the following properties: > > > > o Message Confidentiality - Messages can only be read > > by members of the group > > o Message Integrity and Authentication - Each message > > has been sent by an authenticated sender, and has > > not been tampered with > > o Membership Authentication - Each participant can verify > > the set of members in the group > > o Asynchronicity - Keys can be established without any > > two participants being online at the same time > > o Forward secrecy - Full compromise of a node at a point > > in time does not reveal past messages sent within the group > > o Post-compromise security - Full compromise of a node at a > > point in time does not reveal future messages sent within the group > > o Scalability - Resource requirements that have good scaling in the > > size of the group (preferably sub-linear) > > > > Several widely-deployed applications have developed their own > > protocols to meet these needs. While these protocols are similar, > > no two are close enough to interoperate. As a result, each application > > vendor has had to maintain their own protocol stack and independently > > build trust in the quality of the protocol. The primary goal of this > > working group is to develop a standard messaging security protocol > > so that applications can share code, and so that there can be shared > > validation of the protocol (as there has been with TLS 1.3). > > > > It is not a goal of this group to enable interoperability / federation > > between messaging applications beyond the key establishment, > > authentication, and confidentiality services. Full interoperability > > would require alignment at many different layers beyond security, > > e.g., standard message transport and application semantics. The > > focus of this work is to develop a messaging security layer that > > different applications can adapt to their own needs. > > > > While authentication is a key goal of this working group, it is not > > the objective of this working group to develop new authentication > > technologies. Rather, the security protocol developed by this > > group will provide a way to leverage existing authentication > > technologies to associate identities with keys used in the protocol, > > just as TLS does with X.509. > > > > In developing this protocol, we will draw on lessons learned from > > several prior message-oriented security protocols, in addition to > > the proprietary messaging security protocols deployed within > > existing applications: > > > > o S/MIME - https://tools.ietf.org/html/rfc5751 > > o OpenPGP - https://tools.ietf.org/html/rfc4880 > > o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html > > o Signal - https://signal.org/docs/ > > > > The intent of this working group is to follow the pattern of > > TLS 1.3, with specification, implementation, and verification > > proceeding in parallel. By the time we arrive at RFC, we > > hope to have several interoperable implementations as well > > as a thorough security analysis. > > > > The specifications developed by this working group will be > > based on pre-standardization implementation and deployment > > experience, and generalizing the design described in: > > > > o draft-omara-mls-architecture > > o draft-barnes-mls-protocol > > > > Note that consensus is required both for changes to the current > > protocol mechanisms and retention of current mechanisms. In > > particular, because something is in the initial document set does > > not imply that there is consensus around the feature or around > > how it is specified. > > > > Milestones: > > May 2018 - Initial working group documents for architecture and key > management > > Sept 2018 - Initial working group document adopted for message protection > > Jan 2019 - Submit architecture document to IESG as Informational > > Jun 2019 - Submit key management protocol to IESG as Proposed Standard > > Sept 2019 - Submit message protection protocol to IESG as Proposed > Standard > > > > Cheers, > > > > spt > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls >
- [MLS] Revised MLS charter Sean Turner
- Re: [MLS] Revised MLS charter Sean Turner
- Re: [MLS] Revised MLS charter Richard Barnes
- Re: [MLS] Revised MLS charter Dave Cridland
- Re: [MLS] Revised MLS charter Katriel Cohn-Gordon
- Re: [MLS] Revised MLS charter Cas Cremers
- Re: [MLS] Revised MLS charter Jon Millican
- Re: [MLS] Revised MLS charter Emad Omara
- Re: [MLS] Revised MLS charter Raphael Robert
- Re: [MLS] Revised MLS charter Paul Rösler