Subject: [MLS] Revised MLS charter

From: Sean Turner <[email-masked]>
Date: Fri, 13 Apr 2018 14:09:20 -0400

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

---

From: Sean Turner <[email-masked]>
Date: Fri, 13 Apr 2018 14:52:30 -0400

Sorry I missed to minor edits from Jonathan Lennox didn’t get copied over:

o Scalability - Resource requirements have good scaling in the

The specifications developed by this working group will be
based on pre-standardization implementation and deployment
experience, generalizing the design described in:

Milestones:

Cheers,

spt

> On Apr 13, 2018, at 14:09, Sean Turner <[email-masked]> wrote:
> 
> All,
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Apr 2018 11:18:31 -0400

Hey Sean,

This looks good to me.  Ship it.

--Richard

On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner <[email-masked]> wrote:

> > 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.
> >
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Dave Cridland <[email-masked]>
Date: Wed, 18 Apr 2018 16:39:04 +0100

LGTM.

On 18 April 2018 at 16:18, Richard Barnes <[email-masked]> wrote:

>> o Off the Record - ​https://otr.cypherpunks..ca/Protocol-v3-4.1.1.html
>> <https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html>
>>

---

From: "Katriel Cohn-Gordon" <[email-masked]>
Date: Wed, 18 Apr 2018 16:42:39 +0100

+1

On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote:
>> On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner <[email-masked]> wrote:>>> Sorry I missed to minor edits from Jonathan Lennox didn’t get
>>> copied over:>>>
>>>  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)
>>> 
>>>  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,
>>>  While authentication is a key goal of this working group, it is not>>>  the objective of this working group to develop new authentication
>>>  technologies to associate identities with keys used in the
>>>  protocol,>>>  just as TLS does with X.509.
>>> 
>>>  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/
>>> 
>>>  o draft-omara-mls-architecture o draft-barnes-mls-protocol
>>>
>>>  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
>>>  > 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.>>>  > 
>>>  > Several Internet applications have a need for group key
>>>  > establishment>>>  > and message protection protocols with the following properties:
>>>  > 
>>>  >   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)
>>>  > 
>>>  > 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
>>>  > 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/
>>>  > 
>>>  > 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
> [email-masked]

Links:

  1. https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html

---

From: Cas Cremers <[email-masked]>
Date: Wed, 18 Apr 2018 17:13:54 +0000

Dear all,

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

Cas

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

> o Off the Record - https://otr.cypherpunks...ca/Protocol-v3-4.1.1.html
> as a thorough security analysis..
>
>
> > o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html
> *_______________________________________________*
> MLS mailing list
> [email-masked]
>
> https://www.ietf..org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>
>

---

From: Jon Millican <[email-masked]>
Date: Thu, 19 Apr 2018 05:33:16 +0000

Awesome, looks good to me.

Sent from my iPhone

On 18 Apr 2018, at 18:15, Cas Cremers <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Cas

On Wed, 18 Apr 2018, 16:42 Katriel Cohn-Gordon, <[email-masked]<mailto:[email-masked]>> wrote:
+1

On 18 April 2018 at 16:18, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
Hey Sean,

--Richard
On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
Sorry I missed to minor edits from Jonathan Lennox didn’t get copied over:

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=>

Milestones:

Cheers,

spt

> On Apr 13, 2018, at 14:09, Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
>
> All,
>
> 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=>
>

_______________________________________________
MLS mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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=

---

From: Emad Omara <[email-masked]>
Date: Thu, 19 Apr 2018 07:28:03 +0000

LGTM

On Thu, Apr 19, 2018 at 7:33 AM Jon Millican <[email-masked]> wrote:

> On 18 Apr 2018, at 18:15, Cas Cremers <[email-masked]> wrote:
>
> Dear all,
>
>> <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=>
>> <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=>
>> <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=>
>>
>>
>> <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=>
>>
>> <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=>
>> <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=>
>> <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=>
>> <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=>
>> >
>> <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=>
>>
>>
>> <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=>
>>
>> <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=>
>>
>> <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=>
>>

---

From: Raphael Robert <[email-masked]>
Date: Thu, 19 Apr 2018 10:31:18 +0200

Looks good to me, too!

Raphael

> On 19 Apr 2018, at 09:28, Emad Omara <[email-masked]> wrote:
> 
> LGTM
> 
> 
> On Thu, Apr 19, 2018 at 7:33 AM Jon Millican <[email-masked] <mailto:[email-masked]>> wrote:
> On 18 Apr 2018, at 18:15, Cas Cremers <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Dear all,
>> 
>> On Wed, 18 Apr 2018, 16:42 Katriel Cohn-Gordon, <[email-masked] <mailto:[email-masked]>> wrote:
>> +1
>> 
>> 
>>> On 18 April 2018 at 16:18, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> Hey Sean,
>>> 
>>> On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> 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=>
>>> 
>>> > On Apr 13, 2018, at 14:09, Sean Turner <[email-masked] <mailto:[email-masked]>> wrote:
>>> > 
>>> > All,
>>> > 
>>> > protocols to meet these needs.. While these protocols are similar,
>>> > 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=>
>>> > 
>>> [email-masked] <mailto:[email-masked]>
>>> 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=>
>> 
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> 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=>
>>> 
>> 
>>> [email-masked] <mailto:[email-masked]>
>> 
>>> 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=>
>> [email-masked] <mailto:[email-masked]>
>> 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=>
> 
>> [email-masked] <mailto:[email-masked]>
> 
>> 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= <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=>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>