The Messaging Layer Security (MLS) Architecture
draft-ietf-mls-architecture-15

Notification list changed to me@katriel.co.uk, cremers@cispa.de, tjvdmerwe@gmail.com, jmillican@meta.com, ietf@raphaelrobert.com, sean@sn3rd.com, alan@duric.net from me@katriel.co.uk, cremers@cispa.de, tjvdmerwe@gmail.com, jmillican@meta.com, ietf@raphaelrobert.com, sean@sn3rd.com

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-mls-architecture-15, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-08-27):

From: The IESG
To: IETF-Announce
CC: cremers@cispa.de, draft-ietf-mls-architecture@ietf.org, ietf@raphaelrobert.com, jmillican@meta.com, me@katriel.co.uk, mls-chairs@ietf.org, mls@ietf.org, paul.wouters@aiven.io, sean@sn3rd.com, tjvdmerwe@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The Messaging Layer Security (MLS) Architecture) to Informational RFC


The IESG has received a request from the Messaging Layer Security WG (mls) to
consider the following document: - 'The Messaging Layer Security (MLS)
Architecture'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-08-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol)
  provides a Group Key Agreement protocol for messaging applications.
  MLS is meant to protect against eavesdropping, tampering, message
  forgery, and provide Forward Secrecy (FS) and Post-Compromise
  Security (PCS).

  This document describes the architecture for using MLS in a general
  secure group messaging infrastructure and defines the security goals
  for MLS.  It provides guidance on building a group messaging system
  and discusses security and privacy tradeoffs offered by multiple
  security mechanisms that are part of the MLS protocol (e.g.,
  frequency of public encryption key rotation).  The document also
  provides guidance for parts of the infrastructure that are not
  standardized by MLS and are instead left to the application.

  While the recommendations of this document are not mandatory to
  follow in order to interoperate at the protocol level, they affect
  the overall security guarantees that are achieved by a messaging
  application.  This is especially true in the case of active
  adversaries that are able to compromise clients, the delivery
  service, or the authentication service.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/



No IPR declarations have been submitted directly on this I-D.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-mls-architecture-13 (we had also previously reviewed draft-ietf-mls-architecture-10), which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-04-08):

From: The IESG
To: IETF-Announce
CC: cremers@cispa.de, draft-ietf-mls-architecture@ietf.org, ietf@raphaelrobert.com, jmillican@meta.com, me@katriel.co.uk, mls-chairs@ietf.org, mls@ietf.org, paul.wouters@aiven.io, sean@sn3rd.com, tjvdmerwe@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The Messaging Layer Security (MLS) Architecture) to Informational RFC


The IESG has received a request from the Messaging Layer Security WG (mls) to
consider the following document: - 'The Messaging Layer Security (MLS)
Architecture'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-04-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol)
  provides a Group Key Agreement protocol for messaging applications.
  MLS is meant to protect against eavesdropping, tampering, message
  forgery, and provide Forward Secrecy (FS) and Post-Compromise
  Security (PCS).

  This document describes the architecture for using MLS in a general
  secure group messaging infrastructure and defines the security goals
  for MLS.  It provides guidance on building a group messaging system
  and discusses security and privacy tradeoffs offered by multiple
  security mechanisms that are part of the MLS protocol (e.g.,
  frequency of public encryption key rotation).  The document also
  provides guidance for parts of the infrastructure that are not
  standardized by MLS and are instead left to the application.

  While the recommendations of this document are not mandatory to
  follow in order to interoperate at the protocol level, they affect
  the overall security guarantees that are achieved by a messaging
  application.  This is especially true in the case of active
  adversaries that are able to compromise clients, the delivery
  service, or the authentication service.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/



No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-mls-architecture-11
CC @evyncke

Thank you for the work put into this document, even if it took one year to clear the previous discuss points: what matters is the end goal.

The revised -11 has addressed my second DISCUSS point of my previous ballot and the latest -12 revision has addressed the first one:
https://mailarchive.ietf.org/arch/msg/mls/klr27xnbsivP060m8cwmDZV2xA8/

Thanks to Tatuya Jinmei, the Internet directorate reviewer (at my request), please consider this int-dir review with one nit worth considering:
https://datatracker.ietf.org/doc/review-ietf-mls-architecture-10-intdir-telechat-jinmei-2023-01-29/ and as noted I share Jinmei's view about the clarity of the I-D.

Special thanks to Sean Turner for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review has helped to improve the document,

Regards,

-éric

[Ballot comment]
Thank to Yoav Nir for the SECDIR review.

Thanks for addressing my DISCUSS and COMMENT feedback

==


** Section 7.4.2.1.  Please provide a reference for “mixnet”.

** Section 7.4.3.1.  Please provide a reference for “CRLite”.

** Section 7.5.

(a) Section 7.5. *RECOMMENDATION:* Additional steps should be taken to protect the
      device and the MLS clients from physical compromise.  In such
      settings, HSMs and secure enclaves can be used to protect
      signature keys.


(b) Section 7.3.4 RECOMMENDATION: Signature private keys should be compartmentalized from other secrets and preferably protected by an HSM or dedicated hardware features to allow recovery of the authentication for future messages after a compromise.

Why is the use of HSM to protect keys repeated twice?

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-mls-architecture-10
CC @evyncke

Thank you for the work put into this document.

The revised -11 has addressed my second DISCUSS point of my previous ballot:
https://mailarchive.ietf.org/arch/msg/mls/klr27xnbsivP060m8cwmDZV2xA8/

Alas, the first one is still valid and kept below.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Thanks to Tatuya Jinmei, the Internet directorate reviewer (at my request), please consider this int-dir review with one nit worth considering:
https://datatracker.ietf.org/doc/review-ietf-mls-architecture-10-intdir-telechat-jinmei-2023-01-29/ and as noted I share Jinmei's view about the clarity of the I-D.

Special thanks to Sean Turner for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 6

What is a `LeafNode` ? I.e., please define what it is before using the term ;-) Very similar issue in 5.1 for `GroupInfo`. And as noted by Jinmei "Commit" and "Proposal".

[Ballot comment]

## COMMENTS

### Section 2

In `The Service Provider presents ....` is it unclear to me what service it is about ? The MLS service or the messaging service ?

`she can use to send encrypted messages to Bob and Charlie` is the message also signed by Alice ? Hinted in section 3 but worth already warning the reader...

`join an existing group;` should "(by asking to be added)" be specified ? As per `leave a group`.

Does the MLS group intend to extend the MLS protocol itself to support group of moderators ? This sounds like a basic requirement to me (as a frequent videoconf user/moderator).

### Section 4.2

Why is "Partition-tolerant" mentioned in to the classes of DS ? It seems that it is useless to specify as a discriminator.

I find this section difficult to read, e.g., what are the "Commit" or "Proposal" messages ? It seems that the flow is not natural.

### Section 5.4

Perhaps a mere rendering issue, but RECOMMENDATION appears in bold and is in uppercase while it is not a normative 'RECOMMEND'. Strongly suggest to use lowercase.

## NITS

### Section 1

Isn't `enjoy some level of security` ambiguous or under specified ?

### Section 2

Please use the Oxford comma in `Alice, Bob and Charlie`


## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

Notification list changed to me@katriel.co.uk, cremers@cispa.de, tjvdmerwe@gmail.com, jmillican@meta.com, ietf@raphaelrobert.com, sean@sn3rd.com from me@katriel.co.uk, cas.cremers@gmail.com, tjvdmerwe@gmail.com, jmillican@meta.com, ietf@raphaelrobert.com, sean@sn3rd.com

Notification list changed to me@katriel.co.uk, cas.cremers@gmail.com, tjvdmerwe@gmail.com, jmillican@meta.com, ietf@raphaelrobert.com, sean@sn3rd.com from me@katriel.co.uk, cas.cremers@gmail.com, tjvdmerwe@gmail.com, jmillican@fb.com, ietf@raphaelrobert.com, sean@sn3rd.com

Notification list changed to me@katriel.co.uk, cas.cremers@gmail.com, tjvdmerwe@gmail.com, jmillican@fb.com, ietf@raphaelrobert.com, sean@sn3rd.com from me@katriel.co.uk, cas.cremers@cs.ox.ac.uk, thyla.van.der@merwe.tech, jmillican@fb.com, raphael@wire.com, sean@sn3rd.com

[Ballot comment]
Thanks for the work on this document.

Many thanks to Valery Smyslov for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/uoBsyBurn4jzZu_AGqADSa-Jpx0/, also reported below.

I have only had time to scan the document and haven't found any ART issues with it.
However, I hope Valery's review can be addressed before the document is moved forward.

1) It is not clear from the document if it is ever possible for clients
that support only version x of the protocol to join the group that was formed
using version y of the protocol, but in fact all the current members of this
group support both versions. It seems to me that this scenario is common in
situations when newer version of the protocol becomes available: during some
period of time some clients will support both new and old version, while the
rest will support only old version. If some upgraded clients form a group, they
will probably choose the newest version of the protocol, so the un-upgraded
clients won't be able to join it. I think that this scenario should be
addressed in the document.

2) It is still not clear for me whether the type of DS (Strongly Consistent vs
Eventually Consistent) affects clients that use this DS. In other words - does
clients' behaviour depend on the type of DS or not, and if yes, then how it is
handled in the protocol.

3) The issue of inability for a client to remove itself from the group by
itself seems unsolvable. I would like to see recommendations in the document
for clients wishing to exclude themselves in situations when other members for
some reasons don't cooperate in this process.

[Ballot comment]
Thanks for the work on this document.

Many thanks to Valery Smyslov's review: https://mailarchive.ietf.org/arch/msg/art/uoBsyBurn4jzZu_AGqADSa-Jpx0/, also reported below.

I have only had time to scan the document and haven't found any ART issues with it.
However, I hope Valery's review can be addressed before the document is moved forward.

1) It is not clear from the document if it is ever possible for clients
that support only version x of the protocol to join the group that was formed
using version y of the protocol, but in fact all the current members of this
group support both versions. It seems to me that this scenario is common in
situations when newer version of the protocol becomes available: during some
period of time some clients will support both new and old version, while the
rest will support only old version. If some upgraded clients form a group, they
will probably choose the newest version of the protocol, so the un-upgraded
clients won't be able to join it. I think that this scenario should be
addressed in the document.

2) It is still not clear for me whether the type of DS (Strongly Consistent vs
Eventually Consistent) affects clients that use this DS. In other words - does
clients' behaviour depend on the type of DS or not, and if yes, then how it is
handled in the protocol.

3) The issue of inability for a client to remove itself from the group by
itself seems unsolvable. I would like to see recommendations in the document
for clients wishing to exclude themselves in situations when other members for
some reasons don't cooperate in this process.

[Ballot comment]
Thanks to Valery Smyslov for his two ARTART reviews.  I would encourage the authors of this document to respond to the second one.

This is really well done and easy to read.  Nice work.  I have just a few things to raise for your consideration beyond what others have said already.

The Abstract says:

"This document describes a general secure group messaging infrastructure and its security goals."

...but it uses a number of terms that are defined in the MLS protocol document (Proposal, Commit, etc.).  That means this document isn't as generic as this text suggests.  This is not a blocker to publication -- the work is clearly very thorough -- but this sentence sets the wrong expectations, I think.  It really is more of a reader's guide or a companion specifically to the MLS protocol document.

Section 2, and in particular 2.1, defines "clients", "groups", and "members", but in a few spots it seems like they get crossed.  For instance, in Section 2:

* add one or more clients to an existing group;

That should be "members", not "clients", I think.

In Section 4.1:

"When a client wishes to establish a group or add clients to a group, ..."

Isn't it members that are part of groups, not clients?

[Ballot comment]
Similarly to Éric, I have a hard time thinking of this document as an “architecture”. I’m not sure what to call it — a reader’s guide to accompany the protocol specification, maybe? A commentary on the protocol spec? In any case, I reviewed it significantly differently from how I would review a regular architecture document. The mild criticism implied in saying “well this ain’t an architecture” notwithstanding I thought the document seemed useful and was well-written, interesting, and readable, taken for what it is, and I have no qualms about balloting NOOBJ.

Probably the single largest divergence from my usual review process was that I decided to read it with something analogous to willing suspension of disbelief — when the architecture document mentions some aspect or attribute of the protocol without explaining it, as long as I was able to guess at what it might be, I just moved forward. Likewise, while I might normally complain about acronyms that aren’t expanded on first use or glossed (for example “HSM”) I just let them slide.

Below are a few editorial/nit level things I noticed that you might want to address.


Section 6

“This section lists all of the dependencies of an MLS deployment that are external to the protocol specification, but would still need to be aligned within a given MLS deployment, or for two deployments to potentially interoperate.”

There doesn’t seem to be an “either“ part to go with that “or“.


Section 6

“Delivering messages sent to a group to all members in the group.”

Suggest, “Delivering messages to all members in the group.” As written it seems unnecessarily repetitious and repetitive.


Section 6

“A policy on how long to allow a member to stay in a group without updating its leaf keys before removing them.”

Suggest deleting “before removing them”. I assume “them” refers to the member, but the sentence structure makes it ambiguous. If that’s so, “before removing them“ seems redundant, isn’t that already covered by “how long to allow a member to stay in a group“?


Section 7.2.4

“application would have to be provide it”

Delete “be”.


Section 7.3.5

  “However, the signature private keys are mostly used by clients to
  send a message.  They also provide strong authentication guarantees
  to other clients”

The “however” doesn’t seem to follow from the previous paragraph, and the “they also” doesn’t seem to follow from the “however” sentence. You might want to review to see if this can be worded more clearly.

  "Overall there is no way to detect or prevent these compromises, as
  discussed in the previous sections, performing separation of the
  application secret states can help…”

As it stands, the second part doesn’t seem to follow from the first. I can't quite figure out if the correct fix is to replace the first, or second, comma with a period, but I reckon one of them could be.


Section 7.4.2.1

“Note that it is quite easy for legal requests to ask the service provider for the push-token…”

In protocol documents, we often use “legal“ to mean “permitted by the protocol, well-formed”. I assume in this paragraph, though, you’re talking about something like a subpoena or warrant, though. If so, perhaps rewrite to make that clear.


Section 7.4.3

“An attacker that can generate or sign new credentials may or may not have access to the underlying cryptographic material necessary to perform such operations. In that last case, it results in windows of time for which all emitted credentials might be compromised.”

I wasn’t able to made sense of this paragraph, sorry. In particular, AFAICT “that last case” must mean “an attacker… that [does] not have access to the underlying cryptographic material”. Which, I don’t get how such an attacker is then a threat much less the result described in the final clause.


Section 7.4.3.1

“Provide a Key Transparency and Out-of-Band authentication mechanisms”

Should be “mechanism”, singular, or the article “a” should be deleted — agreement in number.

[Ballot discuss]
Thanks for working on this specification.

After reading section 7, I would like to discuss why there is no explicit recommendation of using secure transport for MLS. This section and subsections point out various strong opinions to use secure transport. I there is any particular reason to support secure transport protocol then it should be mentioned. I kind of feel that the work "transport" here does not really only refer to Layer 4 transport protocols, needs some clarification.

I also support Roman's discuss that the recommendation on section 7.4.3.2 and section 7.1.2 are countering each other.

[Ballot discuss]
Thanks for working on this specification.

After reading section 7, I would like to discuss why there is no explicit recommendation of using secure transport for MLS. This section and subsection points various strong opinions to use secure transport.

I also support Roman's discuss that the recommendation on section 7.4.3.2 and section 7.1.2 are countering each other.

[Ballot comment]
- It took time for me to understand that the recommendation in section 7.1.4 refers to different set of transport protocols than those examples mentioned in beginning of section 7.1 :-), yes, I did not took the "unidirectional" word seriously. However, I think some clarification and/or reference to some FEC scheme for unidirectional transport here would be good.

[Ballot discuss]
** Section 7.3.5
      *RECOMMENDATION:* If the threat model of the system is against an
      adversary which can access the messages on the device without even
      needing to attack MLS, the application should delete plaintext
      messages and ciphertexts immediately after encryption or
      decryption.

How does this recommend work relative to making the system usable?  Specifically, how does the application fulfill its functional purpose if the plaintext should be deleted after encryption or decryption.  When does the user get a chance to read the message?  Or when does the autonomous client get a chance to parse the plaintext and take appropriate action on it?

** Section 7.4.3.2.  Combined, these two recommendations are providing an inconsistent recommendation:

(a) Section 7.4.3.1

      *RECOMMENDATION:* Always use encrypted group operation messages to
      limit privacy risks.


(b) Section 7.1.2.
      *RECOMMENDATION:* Never use the unencrypted mode for group
      operations without using a secure channel for the transport layer.

Recommendation-(a) is saying “always used encrypted group operation messages”, but Recommendation-(b) is allowing for unencrypted ones as long as transport security is used.

** Section 7.4.3.1

*RECOMMENDATION:* Select the strongest MLS Credential type
      available among the target members of an MLS group.

What is the metric for “strongest”? Is there an absolute the rank order of “strongest” to “weakest”?  Is this decision application specific?

[Ballot comment]
Thank to Yoav Nir for the SECDIR review.

** (Similar feedback as provided by Yoav Nir and Éric Vyncke) Based on just the title of this document, I assumed that it would introduce me to the general concepts and design of MLS.  It surprised me that the narrative style of text often assumed prior knowledge of foundational mechanisms of MLS (and used them without definition or citation), and at times made very specific and deep references to the protocol mechanisms (also without definition or citation).  draft-ietf-mls-protocol is cited as a normative reference so my comment is entirely on style.  As an editorial recommendation to make this content easier to digest, consider the following list of places where a bit more of an introduction might have helped the reader:

-- Provide an upfront description of the key MLS concepts: messages types (proposal, commit, welcome and application), epoch, generation counter and credential types.  This could be done with reminder text to Section 2 and 3 of draft-ietf-mls-protocol.

-- Provide cross-references into draft-ietf-mls-protocol when specific fields are behaviors are being commented on.  A non-comprehensive list:
o Section 4.2.1. content_type fields
o Section 4.2.2. ReInit proposal
o Section 5.1.  GroupInfo object
o Section 5.1.  MLS deletion schedule
o Section 5.4. external_senders extension
o Section 6. additional proposal types
o Section 6. required_capabilities extension
o Section 6. “If assisted joining is desired (meaning that the ratchet tree is not provided in Welcome messages)

o Section 6. application_id extension of a LeafNode.

o Section 6.  “reinitialization proposal”

o Section 7.4.3.1. authentication_secret

** Section 1.
  End-to-end security is a requirement for instant messaging systems
  and is commonly deployed in many such systems. 

This is a confusing statement.  The first clause says that E2E security is a requirement; and then the second clause it is “commonly deployed in many such systems” suggesting it is not fielded in certain systems?

** Section 2.
  *  In an MLS group using a PKI for authentication, the AS would
      comprise the certificate issuance and validation processes, both
      of which involve logic inside MLS clients as well as various
      servers.

Are these “various servers” different architectural elements than the AS, DS and client?  If so, can they be named?  Are they the usual PKI architectural elements of the CA, RA, etc?

** Section 2.  Don’t the clients have to talk to the AS in certain circumstances (per step one of the bulleted list)?  That link isn’t depicted in the main figure.

** Section 3.  Editorial.
In a system based on Key Transparency (KT) [KeyTransparency],

I don’t think this text is intended to say “KT as implemented by this very specific Google API pointed to in Github”.  Please make that clear. 

** Section 4.  Editorial.
  Unlike the Authentication Service which is trusted for authentication
  and secrecy, the Delivery Service is completely untrusted regarding
  this property.

“Authentication and secrecy” are two properties.  s/this property/these properties/

** Section 4.

  While privacy of group membership might be a problem
  in the case of a Delivery Service server fanout, the Delivery Service
  can be considered as an active, adaptive network attacker for the
  purpose of security analysis.

I don’t follow the relationship between there being privacy considerations about group membership across different DS servers and treating the DS as an active attacker.  Is the intent to say that the DS can be multiple servers and the attacker can be modeled as one?  If so, is this more appropriate: s/the Delivery Service can be considered as an active/the Delivery Service can be modeled as a single, active/?

** Section 4.1

  When a client wishes to establish a group or add clients to a group,
  it first contacts the Delivery Service to request KeyPackages for
  each other client, authenticates the KeyPackages using the signature
  keys, and then uses those to add the other clients to the group.

The last step of “then uses those to add the other clients to the group” should be clarified to explain in what way those KeyPackages are used to add clients to the group.

** Section 5. 
  MLS is designed as a large-scale group messaging protocol and hence
  aims to provide both performance and safety to its users

“Safety” in what sense?

** Section 5.4.  Editorial.
  While the Application messages will always be encrypted, having the
  handshake messages in plaintext has inconveniences in terms of
  privacy as someone could collect the signatures on the handshake
  messages and use them for tracking

Consider a different set of words to characterize the loss of privacy here (i.e., not characterize it as inconvenient).

** Section 5.4  I appreciate that RFC2119 is not cited by this document. 

-- Are the two blocks of text in this section prefaced with “RECOMMENDATION” intended to have similar semantics as RFC2119?  Why aren't they RFC2219?

-- Who are these “recommendations” directed at?

** Section 5.9. I appreciate that this is an informational document with RFC2119 key words. [I-D.mahy-mls-content-adv] needs to be normative as the text is making a recommendation to use it.

** Section 7
  Generally, MLS is designed under the assumption that the transport
  layer is present to protect metadata and privacy in general, while
  the MLS protocol is providing stronger guarantees such as
  confidentiality, integrity and authentication guarantees. 

Can this be re-phrased to be clearer on what it means to “protect metadata and privacy in general” vs. “providing stronger guarantees such as confidentiality, integrity and authentication guarantees”.  For example, couldn’t confidentiality be part of “protect[ing] metadata”?

** Section 7.
  As discussed above, MLS provides the highest level of security when
  its messages are delivered over a secure transport

What prior text describes the use of “secure transport”?

** Section 7.1
  Even though some of this metadata information does not consist of
  secret payloads

What is a “secret payload”?  Is the text intended to convey that s/secret payload/sensitive information/

** Section 7.1
      If the
      data is private, the infrastructure should use encrypted
      Application messages instead.

Should this read “If the data should be kept private”?

** Section 7.1.4.  Editorial.  Typo.

OLD
The confidentiality and authenticity properties of
  MLS prevent the DS reading or writing messages

NEW
The confidentiality and authenticity properties of MLS prevent the DS from reading or writing messages.

** Section 7.2.2
      *RECOMMENDATION:* Mandate key updates from clients that are not
      otherwise sending messages and evict clients which are idle for
      too long.

Is this recommendation needed?  Is seems very similar to Section 3.2 of the draft-ietf-mls-protocols where normative language is used:

  Update messages SHOULD be sent at regular intervals of time as long
  as the group is active, and members that don't update SHOULD
  eventually be removed from the group. 


** Section 7.3.1
While this is a very weak kind of compromise ...

What makes something a “very weak … compromise”?  What is meant by “weak”?

** Section 7.3.1.  Editorial.  Is the “Post-Compromise Secrecy” mentioned here a subset of the “Post-Compromise Security” explicitly defined in Section 7.2.2?

** Section 7.4.2.1.  Please provide a reference for “mixnet”.

** Section 7.4.2.1
  Note that it is quite easy for legal requests to ask the service
  provider for the push-token associated to an identifier and perform a
  second request to the company operating the push-notification system
  to get information about the device, which is often linked with a
  real identity via a cloud account, a credit card or other
  information.

Recommend weakening the language around how easy it is to satisfy “legal request”.  This ease will be specific to the jurisdiction.

** Section 7.4.3.
  In the past, some systems have had a centralized server generate
  signature key pairs and distribute them to clients. 

Can these past systems be cited?

** Section 7.4.3.1
  For example, cryptographic verification of
  credentials can be largely performed autonomously on the clients for
  the x509 Credential type. In contrast, when MLS clients use the
  basic Credential type, a larger degree of trust must be placed in a
  (likely) centralized authentication resource, or on out-of-band
  processes such as manual verification

“Autonomously” in what sense?  This text is trying to show a distinction between x509 and basic should could use additional clarity. Couldn’t the x509 credentials also have a dependency on a “centralized authentication resource” (aka, CA) and required communication to check a CRL? 

** Section 7.4.3.1.

(a)      *RECOMMENDATION:* Provide a key transparency mechanism for the
      Authentication Services to allow public verification of the
      credentials authenticated by this service.

(b)      *RECOMMENDATION:* Provide a Key Transparency and Out-of-Band
      authentication mechanisms to limit the impact of an Authentication
      Service compromise.

-- What is the difference between (a) and (b) regarding the recommendation to provide a key transparency mechanism?

-- Editorial. Why are “Key Transparency” and “Out-of-Band” capitalized as if they were proper nouns in (b), but in (a) this same approach isn’t used.

** Section 7.4.3.1.  Please provide a reference for “CRLite”.

** Section 7.5
  While non-permanent, non-invasive attacks can sometimes be equivalent
  to software attacks, physical attacks are considered outside of the
  MLS threat model.

Is it implied that the “non-permanent, non-invasive attacks” are physical?  That’s not explicit here.

** Section 7.5
  Compromise scenarios typically consist of a software adversary, which
  can maintain active adaptive compromise and arbitrarily change the
  behavior of the client or service.

Recommend against making generalized assumption on the techniques and tactics of particular adversaries.

** Section 7.5.

(a) Section 7.5. *RECOMMENDATION:* Additional steps should be taken to protect the
      device and the MLS clients from physical compromise.  In such
      settings, HSMs and secure enclaves can be used to protect
      signature keys.


(b) Section 7.3.4 RECOMMENDATION: Signature private keys should be compartmentalized from other secrets and preferably protected by an HSM or dedicated hardware features to allow recovery of the authentication for future messages after a compromise.

Why is the use of HSM to protect keys repeated twice?

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-mls-architecture-10
CC @evyncke

Thank you for the work put into this document.

I find it very difficult to understand as many concepts are not explained. Usually, I start reading the architecture I-D before the protocol one, and this document does not help understanding the architecture. We could even argue whether the I-D is about architecture or about security considerations.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Thanks to Tatuya Jinmei, the Internet directorate reviewer (at my request), please consider this int-dir review with one nit worth considering:
https://datatracker.ietf.org/doc/review-ietf-mls-architecture-10-intdir-telechat-jinmei-2023-01-29/ and as noted I share Jinmei's view about the clarity of the I-D.

Please note that Dave Lawrence is the DNS directorate reviewer (at my request) and you may want to consider this dnsdir review as well when Dave will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/reviewrequest/16998/

Special thanks to Sean Turner for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 6

What is a `LeafNode` ? I.e., please define what it is before using the term ;-) Very similar issue in 5.1 for `GroupInfo`. And as noted by Jinmei "Commit" and "Proposal".

### Section 7.1

Is it appropriate for an IETF RFC (even if informal) to qualify WireGuard and TOR as `secure channel` ? This DISCUSS point is only to generate discussion among the IESG during the telechat. This discuss point will be removed anyway after the discussion.

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-mls-architecture-10
CC @evyncke

Thank you for the work put into this document.

I find it very difficult to understand as many concepts are not explained. Usually, I start reading the architecture I-D before the protocol one, and this document does not help understanding the architecture. We could even argue whether the I-D is about architecture or about security considerations.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Thanks to Tatuya Jinmei, the Internet directorate reviewer (at my request), please consider this int-dir review with one nit worth considering:
https://datatracker.ietf.org/doc/review-ietf-mls-architecture-10-intdir-telechat-jinmei-2023-01-29/ and as noted I share Jinmei's view about the clarity of the I-D.

Please note that Dave Lawrence is the DNS directorate reviewer (at my request) and you may want to consider this dnsdir review as well when Dave will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/reviewrequest/16998/

Special thanks to Sean Turner for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 6

What is a `LeafNode` ? I.e., please define what it is before using the term ;-) Very similar issue in 5.1 for `GroupInfo`. And as noted by Jinmei "Commit" and "Proposal".

### Section 7.1

Can an IETF RFC (even if informal) qualify WireGuard and TOR as `secure channel` ? This DISCUSS point is only to generate discussion among the IESG during the telechat. This discuss point will be removed anyway after the discussion.

[Ballot comment]

## COMMENTS

### Abstract about 'scalable'

This document and its companion appear to demonstrate the security properties of MLS, but do they also cover the scalability ones ? E.g., in section 2, there is `or as large as thousands`, good number but not enough for an IETF full remote plenary. Later in section 5, it is `groups with tens of thousands of members`, i.e., a different order of magnitude.

### Section 2

In `The Service Provider presents ....` is it unclear to me what service it is about ? The MLS service or the messaging service ?

Is there a reason why sometimes AS/DS acronyms are used and at other places their expansions are used ?

`she can use to send encrypted messages to Bob and Charlie` is the message also signed by Alice ? Hinted in section 3 but worth already warning the reader...

`join an existing group;` should "(by asking to be added)" be specified ? As per `leave a group`.

Does the MLS group intend to extend the MLS protocol itself to support group of moderators ? This sounds like a basic requirement to me (as a frequent videoconf user/moderator).

### Section 4.2

Why is "Partition-tolerant" mentionned in to the classes of DS ? It seems that it is useless to specify as a discriminator.

I find this section difficult to read, e.g., what are the "Commit" or "Proposal" messages ? It seems that the flow is not natural.

### Section 5.4

Perhaps a mere rendering issue, but RECOMMENDATION appears in bold and is in uppercase while it is not a normative 'RECOMMEND'. Strongly suggest to use lowercase.

## NITS

### SEction 1

Isn't `enjoy some level of security` ambiguous or under specified ?

### Section 2

Please use the Oxford comma in `Alice, Bob and Charlie`


## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# GEN AD review of draft-ietf-mls-architecture-10

CC @larseggert

Thanks to Meral Shirazipour for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/M8UxyeH75I3l0lYx6DKtgipwPF0).

Thanks for putting together a very readable MLS overview!

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Terms `she` and `he`; alternatives might be `they`, `them`, `their`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-mls-protocol-16`, but `-17` is the latest
available revision.

### URLs

These URLs in the document did not return content:

* https://hal.laas.fr/INRIA/hal-02425229/document

### Grammar/style

#### Section 2.1, paragraph 3
```
tions rely on users verifying each others' key fingerprints for authenticati
                                  ^^^^^^^
```
Did you mean "other's"?

#### Section 4.2, paragraph 1
```
es; this can be detected only by out of band comparison (e.g., confirming tha
                                ^^^^^^^^^^^
```
Did you mean "out-of-band"?

#### Section 5.1, paragraph 7
```
he shared cryptographic material. However every service/infrastructure has c
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

#### Section 5.4, paragraph 8
```
ly not allowed at the protocol level but applications can elect to provide s
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 6, paragraph 54
```
layer. 7.1.3. DoS protection In general we do not consider Denial of Servic
                                ^^^^^^^
```
A comma is probably missing here.

#### Section 7.1.3, paragraph 1
```
ted traffic history combined with an access to all current keying material on
                                  ^^^^^^^^^
```
Uncountable nouns are usually not used with an indefinite article. Use simply
"access".

#### Section 7.1.3, paragraph 3
```
state is compromised at some time t1 but the group member subsequently perfo
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 7.2.1, paragraph 5
```
, the application would have to be provide it through some other mechanism.
                                  ^^^^^^^
```
Consider using either the past participle "provided" or the present participle
"providing" here.

#### Section 7.2.3, paragraph 1
```
thin the epoch of the compromise. However the MLS protocol does not provide
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

#### Section 7.3.1, paragraph 1
```
he attacker has compromised a client but the client signature keys are prote
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 7.3.3, paragraph 2
```
this is the case for signature keys but similar concern exists for the encr
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 7.4.2.1, paragraph 7
```
on client compromise, which helps recovering security faster in various case
                                  ^^^^^^^^^^
```
The verb "helps" is used with an infinitive.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
# Internet AD comments for draft-ietf-mls-architecture-10
CC @ekline

## Nits

### S5.5

* "to other member" -> "to every other member"?

### S7.2.4

* "would have to be provide it" ->
  "would have to provide it", or
  "would have to be provided [with] it"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mls-architecture-10, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-01-16):

From: The IESG
To: IETF-Announce
CC: cas.cremers@cs.ox.ac.uk, draft-ietf-mls-architecture@ietf.org, jmillican@fb.com, me@katriel.co.uk, mls-chairs@ietf.org, mls@ietf.org, paul.wouters@aiven.io, raphael@wire.com, sean@sn3rd.com, thyla.van.der@merwe.tech
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The Messaging Layer Security (MLS) Architecture) to Informational RFC


The IESG has received a request from the Messaging Layer Security WG (mls) to
consider the following document: - 'The Messaging Layer Security (MLS)
Architecture'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-01-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol)
  specification has the role of defining a Group Key Agreement
  protocol, including all the cryptographic operations and
  serialization/deserialization functions necessary for scalable and
  secure group messaging.  The MLS protocol is meant to protect against
  eavesdropping, tampering, message forgery, and provide further
  properties such as Forward Secrecy (FS) and Post-Compromise Security
  (PCS) in the case of past or future device compromises.

  This document describes a general secure group messaging
  infrastructure and its security goals.  It provides guidance on
  building a group messaging system and discusses security and privacy
  tradeoffs offered by multiple security mechanisms that are part of
  the MLS protocol (e.g., frequency of public encryption key rotation).

  The document also provides guidance for parts of the infrastructure
  that are not standardized by the MLS Protocol document and left to
  the application or the infrastructure architects to design.

  While the recommendations of this document are not mandatory to
  follow in order to interoperate at the protocol level, they affect
  the overall security guarantees that are achieved by a messaging
  application.  This is especially true in case of active adversaries
  that are able to compromise clients, the delivery service, or the
  authentication service.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/



No IPR declarations have been submitted directly on this I-D.

Request for posting confirmation emailed to previous authors: Alan Duric , Albert Kwon , Benjamin Beurdouche , Emad Omara , Eric Rescorla , Srinivas Inguva , mls-chairs@ietf.org

Notification list changed to me@katriel.co.uk, cas.cremers@cs.ox.ac.uk, thyla.van.der@merwe.tech, jmillican@fb.com, raphael@wire.com, sean@sn3rd.com from Katriel Cohn-Gordon <me@katriel.co.uk>, Cas Cremers <cas.cremers@cs.ox.ac.uk>, Thyla van der Merwe< thyla.van.der@merwe.tech>, Jon Millican <jmillican@fb.com>, Raphael Robert <raphael@wire.com>, sean@sn3rd.com

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus was broad. I will admit that I made a mistake not combining
the two WGLCs into one message; people read both but only responded to the
protocol WGLC message.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Again, surprisingly not much controversy even with the foreknowledge that the
mls-archictecture I-D was the framing to make sure the security protections
offered were achieved.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There is no formal expert review criteria for this document.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

This document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There is no formal language in this document.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. There are some minor tweaks that are flowing in, but it ticks the boxes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

After reviewing the list, it is not clear that most of the common issues apply
to this particular I-D.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational is the requested intended status. This an architecture document
so it is the right choice.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, I have personally verified with the authors that they have met the IPR
disclosure obligations in [BCP79].

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

During this check, one author graciously offered to move to a contributor. Now,
there are 5 authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are bunch of warnings related to missing references, which aren't missing.

There were two warning in -09. One was about referring to the MLS protocol I-D
with square brackets; I made them curved brackets. The other was about missing
the 2119 language; I made the one 2119 key word lowercase (like the rest of the
I-D).

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I believe the references are categorized appropriately.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

There is one normative reference and that is to the mls protocol document.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no IANA considerations as this document neither creates nor assigns
any code points.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no IANA registries defined in this document.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus was broad. I will admit that I made a mistake not combining
the two WGLCs into one message; people read both but only responded to the
protocol WGLC message.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Again, surprisingly not much controversy even with the foreknowledge that the
mls-archictecture I-D was the framing to make sure the security protections
offered were achieved.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There is no formal expert review criteria for this document.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

This document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There is no formal language in this document.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. There are some minor tweaks that are flowing in, but it ticks the boxes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

After reviewing the list, it is not clear that most of the common issues apply
to this particular I-D.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational is the requested intended status. This an architecture document
so it is the right choice.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, I have personally verified with the authors that they have met the IPR
disclosure obligations in [BCP79].

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

During this check, one author graciously offered to move to a contributor. Now,
there are 5 authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are bunch of warnings related to missing references, which aren't missing.

There were two warning in -09. One was about referring to the MLS protocol I-D
with square brackets; I made them curved brackets. The other was about missing
the 2119 language; I made the one 2119 key word lowercase (like the rest of the
I-D).

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I believe the references are categorized appropriately.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

There is one normative reference and that is to the mls protocol document.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no IANA considerations as this document neither creates nor assigns
any code points.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no IANA registries defined in this document.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus was broad. I will admit that I made a mistake not combining
the two WGLC into one message; people read both but only responded to the
protocol WGLC message.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Again, surprisingly not much controversy.

**FINISH** Something about this document havign to move with the protocol document. And this document xplaining how to get the most out of mls.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There is no formal expert review criteria for this document.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

This document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There is no formal language in this document.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?



10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

After reviewing the list, it is not clear that most of the common issues apply
to this particular I-D.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational is the requested intended status. This an architecture document
so it like the right choice.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, I have personally verified with the authors that they have met the IPR
disclosure obligations in [BCP79].

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

I have personally verified that all authors are willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are bunch of warnings related to missing references, which aren't missing.

There were two warning in -09. One was about referring to the MLS protocol I-D with square brackets; I made them curved brackets. The other was about missing the 2119 language; I made the one 2119 key word lowercase (like the rest of the I-D).

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I believe the references are categorized appropriately.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

There is one normative reference and that is to the mls protocol document.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no IANA considerations as this document neither creates nor assigns
any code points.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no IANA registries defined in this document.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Notification list changed to Katriel Cohn-Gordon <me@katriel.co.uk>, Cas Cremers <cas.cremers@cs.ox.ac.uk>, Thyla van der Merwe< thyla.van.der@merwe.tech>, Jon Millican <jmillican@fb.com>, Raphael Robert <raphael@wire.com>, sean@sn3rd.com from Katriel Cohn-Gordon <me@katriel.co.uk>, Cas Cremers <cas.cremers@cs.ox.ac.uk>, Thyla van der Merwe< thyla.van.der@merwe.tech>, Jon Millican <jmillican@fb.com>, Raphael Robert <raphael@wire.com> because the document shepherd was set

Notification list changed to Katriel Cohn-Gordon <me@katriel.co.uk>, Cas Cremers <cas.cremers@cs.ox.ac.uk>, Thyla van der Merwe< thyla.van.der@merwe.tech>, Jon Millican <jmillican@fb.com>, Raphael Robert <raphael@wire.com>

Request for posting confirmation emailed  to submitter and authors: Alan Duric , Emad Omara , Albert Kwon , Benjamin Beurdouche , Eric Rescorla , Srinivas Inguva