[MLS] Éric Vyncke's Discuss on draft-ietf-mls-architecture-10: (with DISCUSS and COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Tue, 31 January 2023 10:25 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mls@ietf.org
Delivered-To: mls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C45AC14F72F; Tue, 31 Jan 2023 02:25:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mls-architecture@ietf.org, mls-chairs@ietf.org, mls@ietf.org, me@katriel.co.uk, cas.cremers@cs.ox.ac.uk, thyla.van.der@merwe.tech, jmillican@fb.com, raphael@wire.com, sean@sn3rd.com, sean@sn3rd.com, tale@dd.org, jinmei@wide.ad.jp
X-Test-IDTracker: no
X-IETF-IDTracker: 9.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <167516072810.59588.736827594250525013@ietfa.amsl.com>
Date: Tue, 31 Jan 2023 02:25:28 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/klr27xnbsivP060m8cwmDZV2xA8>
X-Mailman-Approved-At: Tue, 31 Jan 2023 06:04:28 -0800
Subject: [MLS] Éric Vyncke's Discuss on draft-ietf-mls-architecture-10: (with DISCUSS and COMMENT)
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 31 Jan 2023 10:25:28 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-mls-architecture-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/



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


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