Re: [MLS] Revised MLS charter

Paul Rösler <paul.roesler@rub.de> Thu, 19 April 2018 08:36 UTC

Return-Path: <paul.roesler@rub.de>
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 3B91B126BF7 for <mls@ietfa.amsl.com>; Thu, 19 Apr 2018 01:36:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.de
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 pQtbEFCykE-r for <mls@ietfa.amsl.com>; Thu, 19 Apr 2018 01:36:02 -0700 (PDT)
Received: from out1.mail.ruhr-uni-bochum.de (out1.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:8:1001::8693:3595]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C26F126CBF for <mls@ietf.org>; Thu, 19 Apr 2018 01:36:02 -0700 (PDT)
Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out1.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 40RXPt0GDrz4y2F for <mls@ietf.org>; Thu, 19 Apr 2018 10:36:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1524126962; bh=+gdV8TZHjkG5SmSoeeBokEJYslODfkAbWOkfEoPI8zs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YBWGAm6ItYWjoG1KWJpTzPHi1rvjOWMghN5fLoI4H/3rM+D80+GxOvq5QNwdiYtH8 mZVg8TwTbGilX5w6fS07ymr0QKcoD5C+mv+l9NAjlvO+PRfRyka9WjAQy29c3Iwq/r ZMnJinulD7hhj9RxgdNuIs5yda1xtJs1AzbH6ay0=
Received: from out1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 40RXPs6dXMz4yg3 for <mls@ietf.org>; Thu, 19 Apr 2018 10:36:01 +0200 (CEST)
X-Envelope-Sender: <paul.roesler@rub.de>
X-RUB-Notes: Internal origin=134.147.42.227
Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out1.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 40RXPs6PRFz4yfK for <mls@ietf.org>; Thu, 19 Apr 2018 10:36:01 +0200 (CEST)
Received: from [192.168.1.156] (unknown [134.147.203.251]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 40RXPq4k0VzybJ for <mls@ietf.org>; Thu, 19 Apr 2018 10:35:59 +0200 (CEST)
To: mls@ietf.org
References: <mailman.2071.1524126689.4527.mls@ietf.org>
From: =?UTF-8?Q?Paul_R=c3=b6sler?= <paul.roesler@rub.de>
Openpgp: preference=signencrypt
Autocrypt: addr=paul.roesler@rub.de; prefer-encrypt=mutual; keydata= xsJuBFMPNo4RCACsEL23jO1k25wZhdphKuPdmEnxvjbtZavn1ZkALMxWJ4bYHPxNkpZWCT9h v0ZizDoosjlIvh0lK0nZgK0MLwjG/swrG/qUoZPIxStbXSVZPPwSdTaa+nzN0HD2y30zDExP 9WtchiEnGPB8WLCjkx5qscrBZV+PzI5akdK2CGBDthVvYzu4oLMZ89akJfM82ap9fGf0pfMh 4Qj4zIH6Vt6PIDn/r3d1GNW00RlEaq+MerAp3WkO+BwZ/2yCM+WJFG4w8tI3p+CjUlZehU2o WBxAmaLLHK3HOrCxiyGWZtIXy5plSfBjDomrlnlIiaDiC0N+MleHF8+IqxAo0XKySXn3AQDm UVBV0DpdIxm8dk2BCT5pMdnZFxzoBbSt57Tv9htwcwgAqpCy5Fhfcm5fVdhkeuaX86izCPfn 1k6FDt/3VUZ7lwcLJL9qYp1treUptfrUJ/DOeZN5LAyULj2Aijjy2Tni3RrDR9+1NvLTla4v bJpndEWI0nof1l8za+sfeQn8YnSylZLFt/Blx3MAe0MnNi9ZbGk50fdKjNsBwCwcZP/1Gyen s05rk2aaL07n5guCz/0bmlQFANCyi3lH+EcHJ0I4wYriBA4xJ3wDJmrCtjhsAtHNnc6pqvgE S2h2J7gAGa7A+ktFJhAxmVSx02GzakjNenx/SWMT2zlIZ/tu1T3wdX3SghUvX62p37FXPObF EbaEJZc9j4jUqnaJHbj/q717Gwf/S3mVyiMaIVzfbxmngGVfaf89vHRh7sWvkt9+TarR7Xen M2Bwi9wKgJ6pshkAnIe6VCGx4+JNH5SUiaxVr6TyrK9GcDkfCEwcVGwDBmeKdtv5Psb2Ho6t tTIWPwj/eQAJn283X18izF1xYYDFSct835R3hG6baP1FJZmMSm+CxV8C+uZXB/Yom/p4NblJ ujLJPGVampAZYs3ZVLrQBuxrXhGrDimFY9TLgO3ZN4gN4gQ3OvvBzmagwGMJdszTaRNE3JGE /qzvlvIs3KTLpQzybxZWwl7SO8b7A+i6+Yp9uN6thrpX7/TdnKcvnMezNYMRjuXvRGmaZ7c2 thgDF83fY80jUGF1bCBSw7ZzbGVyIDxtYWlsQHJvZXNsZXItcGF1bC5kZT7CfgQTEQgAJgIb IwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheABQJTDzbTAhkBAAoJEBbS1xKcazdGVrAA/3lK QI/T1aM6i6KysCui1/fluId0YmRRqypKMA+XAz2gAP4tLC5YbgGw9O9nMTivNqqPiLthcl/j SqJFkN9wvZOvIs7BTQRTDzaOEAgAlESVhuAL+WnQd/2DG4VxkkozWwDayzdpvP6L3agcf6bx ftRHlYPFGh6Ks5kwjTlo3+W9dX0PzM6rAaeTh1hJs1z793p/SKI6C184G/ReGSxZf4/sX1OL jpsrqyiCsWxth8wv8ha9hNLNInF3jA6fpJna7VVh4pE05Elc5BIkX+gXyGd4LtMUd+r3oEje b6hfHxdM0aOwv/ekJqY5o0MZdNjQ6bJ8o7YrKfp1mLG6dYXGa9z3nEmjbXJ/74YgZSpTtGg1 Do+uaOCU4AvD3uBvB85PWyIhasCoOniNh762HBhDDGu9GyRGXnQBIz/+gQNjuXTzUvACZ2Ah QscDlZ2qnwADBwgAhgobq3ALUCG7DeLpEK9uwZJMt9rGJfRwlj5YafXb66kCRuLOOgKzSjy+ 7f5OYQei+byxYc0+/JKTxhaIReLDP/iafm/E2b6n0kKrznrdCu/EwJ+q5MtyrLlUHeY7NEVj VZhYw9zaL6J5Ed4EJfbOYMzovQPkJ3rDLCqs/phYpg1Yd1+qGo1ODjLXC8ThBfvoSL/pLhvf HxLyPQATpuT4rVhNa3RsMceQ4jNVKL5SvJwuomrWgFUyteRQLt12M6DjmaUeTXHSntfqjQVy 8+1rC/k1UhV35yuGUMbDmPL5dcGWYvYXRqTBKC39NMXtICM8zTBTTlGhMp2Zcz+lka7LR8Jh BBgRCAAJBQJTDzaOAhsMAAoJEBbS1xKcazdGw7MBANgKvPttJHvY4OgwW4ieVk30QFrIMtKh DPr0iJcobzajAP9BuJfwsGAR/zE0lByRtCvJymNYhst5Hf9FitY4nBJ2Rg==
Message-ID: <d138577f-e6d5-fa6c-df50-287cd220db6f@rub.de>
Date: Thu, 19 Apr 2018 10:35:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <mailman.2071.1524126689.4527.mls@ietf.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/5CxWwQ5PEMQ_WcBzyEQHEPY4508>
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: Thu, 19 Apr 2018 08:36:06 -0000

LGTM!

On 19.04.2018 10:31, Raphael Robert <raphael@wire.com> wrote:
> 
> Looks good to me, too!
> 
> Raphael
> 
>> On 19 Apr 2018, at 09:28, Emad Omara <emadomara@google.com> wrote:
>>
>> LGTM
>>
>>
>> On Thu, Apr 19, 2018 at 7:33 AM Jon Millican <jmillican@fb.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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= <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 <mailto:MLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://mailarchive.ietf.org/arch/browse/mls/attachments/20180419/8484a515/attachment.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
> 
> 
> ------------------------------
> 
> End of MLS Digest, Vol 3, Issue 10
> **********************************
>