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