Re: [MLS] Revised MLS charter

[Cas Cremers <[e-mail]>]

Dear all,

I am also happy with the revisions. Good to go!

Cas

On Wed, 18 Apr 2018, 16:42 Katriel Cohn-Gordon, <[e-mail]> wrote:

> +1
>
>
> On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote:
>
> LGTM.
>
> On 18 April 2018 at 16:18, Richard Barnes <[e-mail]> wrote:
>
> Hey Sean,
>
> This looks good to me.  Ship it.
>
> --Richard
>
> On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>
>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>
> *_______________________________________________*
> MLS mailing list
> [e-mail]
>
> https://www.ietf..org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>
>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>