Re: [MLS] Revised MLS charter

LGTM

On Thu, Apr 19, 2018 at 7:33 AM Jon Millican <jmillican@fb.com> wrote:

> Awesome, looks good to me.
>
> Sent from my iPhone
>
> On 18 Apr 2018, at 18:15, Cas Cremers <cas.cremers@cs.ox.ac.uk> wrote:
>
> Dear all,
>
> I am also happy with the revisions. Good to go!
>
> Cas
>
> On Wed, 18 Apr 2018, 16:42 Katriel Cohn-Gordon, <me@katriel.co.uk> wrote:
>
>> +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
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5751&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=bYpzIhi5-8x2q89JJ0lMiZvrqm8pZPt6-bL1-05NBbY&e=>
>> o OpenPGP - https://tools.ietf.org/html/rfc4880
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4880&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=yElQKvJ5NvqXsxDr_LIrIdPIvlPWNtLHZZ-_E9rxKTE&e=>
>> o Off the Record - https://otr.cypherpunks...ca/Protocol-v3-4.1.1.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__otr.cypherpunks.ca_Protocol-2Dv3-2D4.1.1.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=qGyXs2a-dgcAYhCd-GWdNKDY8YQtji3a7B0RvFWGQgM&e=>
>>
>>
>> o Signal - https://signal.org/docs/
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__signal.org_docs_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=-l5BfMBSgi5ehwgyJ5eVIGspDR043ZEXiE54CybEAAU&e=>
>>
>> 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
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5751&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=bYpzIhi5-8x2q89JJ0lMiZvrqm8pZPt6-bL1-05NBbY&e=>
>> > o OpenPGP - https://tools.ietf.org/html/rfc4880
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4880&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=yElQKvJ5NvqXsxDr_LIrIdPIvlPWNtLHZZ-_E9rxKTE&e=>
>> > o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__otr.cypherpunks.ca_Protocol-2Dv3-2D4.1.1.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=qGyXs2a-dgcAYhCd-GWdNKDY8YQtji3a7B0RvFWGQgM&e=>
>> > o Signal - https://signal.org/docs/
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__signal.org_docs_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=-l5BfMBSgi5ehwgyJ5eVIGspDR043ZEXiE54CybEAAU&e=>
>> >
>> > 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
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=rCkO6bjAuzkicAcC9xQwtwWMKhvoGkeNcRvXkyLozng&e=>
>>
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=rCkO6bjAuzkicAcC9xQwtwWMKhvoGkeNcRvXkyLozng&e=>
>>
>> *_______________________________________________*
>> MLS mailing list
>> MLS@ietf.org
>>
>> https://www.ietf..org/mailman/listinfo/mls
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=rCkO6bjAuzkicAcC9xQwtwWMKhvoGkeNcRvXkyLozng&e=>
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=rCkO6bjAuzkicAcC9xQwtwWMKhvoGkeNcRvXkyLozng&e=>
>>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=rCkO6bjAuzkicAcC9xQwtwWMKhvoGkeNcRvXkyLozng&e=
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>