Re: [MLS] Revised MLS charter

Dave Cridland <dave@cridland.net> Wed, 18 April 2018 15:39 UTC

Return-Path: <dave@cridland.net>
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 71CFA127522 for <mls@ietfa.amsl.com>; Wed, 18 Apr 2018 08:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net
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 yNGHnQkn6zwF for <mls@ietfa.amsl.com>; Wed, 18 Apr 2018 08:39:07 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 EF3A01243F3 for <mls@ietf.org>; Wed, 18 Apr 2018 08:39:06 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id r7-v6so3341827lfr.1 for <mls@ietf.org>; Wed, 18 Apr 2018 08:39:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7fWWUod0Lq3oqEMAt8IYc41LtJ+D5PiR4uIw3GLJCbI=; b=GrBedaTSlttMlICqYr7EAU08gN5jFEV40mI5wPE6/RcFuekP9dVz8WUGXRJk5QkxH3 B/o4ubdU39OJQvmbyOmTZkxsnrk4TynnkrOjq2o4uCMiQzU/v6jNI5oj2lTSX0V44IYQ qv5x36hJE/GkcYF/KJZ2JZ1Txi/u5sGXHoC9g=
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=7fWWUod0Lq3oqEMAt8IYc41LtJ+D5PiR4uIw3GLJCbI=; b=TvftoSoAncOH3743tH4AIHfwdBC/nbyX46+tjy6XHw0GJnizn2Mu0sZTT61TzHwAoo OnxwDRYYJD2W3KWuNLyklMjzWc4gxC7wIk2RmgLnp8PXeOUlRYPUhKvQmys992teke5z wDZcb6n8hond+Fg0Qgb2/v+QG6YWp9FQ5GVH3GgOnC2YpS8+q6miK8M+c67Gw6MNUb3m zTvfro6lIFv5ERnlxmRmICRNKVboHt9nQbapOGEa7JQ5HQK9yXXsNxFw/1C+fcA8PRZS qmiW9R1hMjPCJQiQrQS+nwt5ampw78fnydy3mYoKCsJ2gxxzQawgv3oVzHVSbb1dqGhj KBOA==
X-Gm-Message-State: ALQs6tB2ej1spSKeYxBcgBSUQOJxcIiv0XT6gINXegmYusXdvABcWS+b 8NkB08eRhVRMS6aTwvurdsUeNiq/Uxx666Y8jSa/FA==
X-Google-Smtp-Source: AIpwx4+vkSTMsVC9wIT9XmxJb0Fy8drnAqqbrn17RpHzuRILtm9rxn1kjNGSU+2xhW+yTZ4UUlzcnBNa0X5H2YNMB24=
X-Received: by 10.46.46.10 with SMTP id u10mr1756043lju.77.1524065944800; Wed, 18 Apr 2018 08:39:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.179.71.202 with HTTP; Wed, 18 Apr 2018 08:39:04 -0700 (PDT)
In-Reply-To: <CAL02cgTugFZ18cJ_9Zi0syRT7kNk_Jjko9WEkOwpCSVMjJQYrg@mail.gmail.com>
References: <E66143BE-F9D8-4073-A83E-10B4344BF15D@sn3rd.com> <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com> <CAL02cgTugFZ18cJ_9Zi0syRT7kNk_Jjko9WEkOwpCSVMjJQYrg@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
Date: Wed, 18 Apr 2018 16:39:04 +0100
Message-ID: <CAKHUCzx9DVBBkKuwKrUzGVb6QpVP12LJD0URv4z4c2rip28K2A@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: Sean Turner <sean@sn3rd.com>, mls@ietf.org
Content-Type: multipart/alternative; boundary="089e0823f834413639056a214191"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/TpT-_KCCauh8yS_iiZbBiFHGhVA>
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:39:10 -0000

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
>> <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 mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>
>