Skip to main content

Early Review of draft-ietf-mls-architecture-09
review-ietf-mls-architecture-09-secdir-early-nir-2022-10-08-00

Request Review of draft-ietf-mls-architecture
Requested revision No specific revision (document currently at 15)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2022-09-28
Requested 2022-09-21
Requested by Paul Wouters
Authors Benjamin Beurdouche , Eric Rescorla , Emad Omara , Srinivas Inguva , Alan Duric
I-D last updated 2022-10-08
Completed reviews Artart Last Call review of -13 by Valery Smyslov (diff)
Secdir Last Call review of -14 by Yoav Nir (diff)
Secdir Early review of -09 by Yoav Nir (diff)
Genart Early review of -09 by Meral Shirazipour (diff)
Opsdir Early review of -09 by Tim Wicinski (diff)
Artart Early review of -09 by Valery Smyslov (diff)
Artart Last Call review of -10 by Valery Smyslov (diff)
Secdir Last Call review of -10 by Yoav Nir (diff)
Intdir Telechat review of -10 by Tatuya Jinmei (diff)
Dnsdir Telechat review of -10 by David C Lawrence (diff)
Secdir Last Call review of -15 by Yoav Nir
Artart Last Call review of -15 by Valery Smyslov
Comments
It would be nice if we could get a few early reviews in time for the MLS interim meeting on the 29th
Assignment Reviewer Yoav Nir
State Completed
Request Early review on draft-ietf-mls-architecture by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/Sl4Q02sJlAuI8EkjlXz-cNuEhQc
Reviewed revision 09 (document currently at 15)
Result Has nits
Completed 2022-10-08
review-ietf-mls-architecture-09-secdir-early-nir-2022-10-08-00
The document describes the Message Layer Security (MLS) architecture, and
includes a very thorough and comprehensive analysis of the security and privacy
issues in section 7, including recommendations. Considering the length and the
breadth, it is not surprising that I cannot find anything missing.

A few nits:

The document uses terms that are not defined within the document:
* "MLSCiphertext" appears in section 7.1.1 without having been defined earlier.
That's probably acceptable because it is defined in the protocol document which
is a normative reference. Still, such terms are commonly redefined. *
"Anonymous credentials" are mentioned without having been defined in either
this document or in the protocol document. It *is* a term that is used
occasionally, but AFAICT the only IETF document that defines it is RFC 4949,
which is (a) not referenced here, and (b) defines it as a USG term, and (c)
says that Internet drafts "SHOULD NOT use this term"

Section 7.2.3 defines "deniability" and then says that "MLS does not make any
claims with regard to deniability". So why do we need that paragraph?

The document includes three instances of the adverb "extremely" and five of the
adverb "very", all in section 7, and I don't think they are necessary. Better
yet, some of them could be replaced with actual measures. For example, "MLS
avoids needing to send the full list of recipients ... because that list is
potentially extremely large in MLS." How large? 5? 1000? A billion?  In other
cases, "...clients have the extremely important role of deleting appropriate
keys..." just sounds like a new formulation of SHOULD. I don't think those
adverbs are necessary. Interestingly, the protocol document has only one
instance of "very" and it is expanded to a measure: "The use of variable-size
integers for vector lengths allows vectors to grow very large, up to 2^30
bytes."