# 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"

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.

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.

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?

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?

Thanks for addressing my discuss points.

# É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

[I agree with John's observation and support Roman's DISCUSS.]

# 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