Re: [MLS] Revised MLS charter
"Katriel Cohn-Gordon" <me@katriel.co.uk> Wed, 18 April 2018 15:42 UTC
Return-Path: <me@katriel.co.uk>
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 D38D31243F3 for <mls@ietfa.amsl.com>; Wed, 18 Apr 2018 08:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level:
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=xCPzjCkF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YGLnblhf
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 7G-4nsN5wLPV for <mls@ietfa.amsl.com>; Wed, 18 Apr 2018 08:42:41 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0851B120727 for <mls@ietf.org>; Wed, 18 Apr 2018 08:42:41 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 487B921C3B for <mls@ietf.org>; Wed, 18 Apr 2018 11:42:40 -0400 (EDT)
Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Wed, 18 Apr 2018 11:42:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject :x-me-sender:x-me-sender:x-sasl-enc; s=mesmtp; bh=+91HsuQDb+UQIO pNGSKf9hgDeIELH1zUEV3IG2LMQus=; b=xCPzjCkF+jgPaO+WZX8nqea1q7U9UV sfAgWDhhcNDoVdSvFlGC7vyFcVyT5fx7c506GGyGqFptxHV7MjGFthvhftO89hem PryIYTCgQHdfe8vIr+C/Ju7UUomnvOF7mMUosZfoZOsXpfB8mEaVNePzHRwXZ7v4 o2qfeAzEbz/s8=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=+91HsuQDb +UQIOpNGSKf9hgDeIELH1zUEV3IG2LMQus=; b=YGLnblhf1XdLe6A/Q1ziu7CB5 FE4NSehdrgLSeGW3HKzVdx5ByK1Gj0r0d+YUTrlVykvqQZ8XTydL5aGZ3p39QNGk xrjeUUSPTzYEBtu0vPGLzHv/Rc02C/W5e0XIagfjmxHL1u5KUkxb0HrUEgayG0tD algveWqDXlKZ7cRDvww3CrTKe2q/hlnIo2OWJpPooY4suB7nUmn7crKX930yozW5 1C+YfvRSyql+ZbRnBfgAt370CtZEnGkjPClr/wfb0/dK/b5gPQHtboE8uKtK2uB/ wWHPYsQ6ZI01zlSMS+5W4KIgdK9fPMQyvTvZ2mb+lCJm+YJdmS3yJBqp6n0bQ==
X-ME-Sender: <xms:cGfXWqzcxXvYJSBgiZE90-ow0-DX695XVkiwi8zIisr42eKz4GLNVQ>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0C57D9E382; Wed, 18 Apr 2018 11:42:39 -0400 (EDT)
Message-Id: <1524066159.11012.1342515920.44B1978A@webmail.messagingengine.com>
From: Katriel Cohn-Gordon <me@katriel.co.uk>
Cc: mls@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_1524066159110122"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-f3006b89
Date: Wed, 18 Apr 2018 16:42:39 +0100
References: <E66143BE-F9D8-4073-A83E-10B4344BF15D@sn3rd.com> <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com> <CAL02cgTugFZ18cJ_9Zi0syRT7kNk_Jjko9WEkOwpCSVMjJQYrg@mail.gmail.com> <CAKHUCzx9DVBBkKuwKrUzGVb6QpVP12LJD0URv4z4c2rip28K2A@mail.gmail.com>
In-Reply-To: <CAKHUCzx9DVBBkKuwKrUzGVb6QpVP12LJD0URv4z4c2rip28K2A@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/iuCsTFhpCVA3_0fuf2Z8puLAwIc>
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:42:44 -0000
+1 On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote: > LGTM. > > On 18 April 2018 at 16:18, Richard Barnes <rlb@ipv.sx> wrote: >> 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[1]>>> >>> 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 mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > _________________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls Links: 1. https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html
- [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