[MLS] Roman Danyliw's No Objection on draft-ietf-mls-protocol-17: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-mls-protocol-17: No Objection

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



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 2.
   Handshake Message:  A PublicMessage or PrivateMessage carrying an MLS
      Proposal or Commit object, as opposed to application data.

This definition of a handshake message is being defined in terms of a Proposal
or Commit object, neither of which are defined in this session.   Furthermore,
PublicMessage or PrivateMessage aren’t defined either as this point in the
text.  To improve clarity, consider defining these key terms.

** Section 2.  Editorial.
   The PublicMessage and PrivateMessage formats are defined in
   Section 6; they represent integrity-protected and confidentiality-
   protected messages, respectively.

The use of “respectively” in the text is suggesting that PrivateMessages don’t
have integrity protection which is not accurate.

** Section 3.1.  Typo. s/the the/the/

** Section 5.1.1.
(see the Cryptographic Dependencies section of
   the HPKE specification for more information).

Is this Section 4 of RFC9180?  If so, why not say that?

** Section 5.3.3.

   However, applications SHOULD NOT rely on the data in an
   application_id extension as if it were authenticated by the
   Authentication Service,

What would be the circumstance where the application_id extension would be
treated with equal standing as something from the AS?  Why can’t this be a
“MUST”?

** Section 12.2.

   A group member creating a commit and a group member processing a
   commit MUST verify that the list of committed proposals is valid
   using one of the following procedures, depending on whether the
   commit is external or not.

Unsaid is what to do if the proposal list is not valid.  Please clarify.

** Section 12.2

   *  It contains multiple Update and/or Remove proposals that apply to
      the same leaf.  If the committer has received multiple such
      proposals they SHOULD prefer any Remove received, or the most
      recent Update if there are no Removes.

Is this normative behavior required, or could it be left up to application? 
The mixing of updates/removes on the same node and the SHOULD guidance already
means that this “recovery from an invalid node” may not be consistent across
clients/DS-es.

Same observation on recovering from ReInit with any other proposals.

** Section 12.4.

   Due to the asynchronous nature of proposals, receivers of a Commit
   SHOULD NOT enforce that all valid proposals sent within the current
   epoch are referenced by the next Commit.  In the event that a valid
   proposal is omitted from the next Commit, and that proposal is still
   valid in the current epoch, the sender of the proposal MAY resend it
   after updating it to reflect the current epoch.

Is there any additional retry mechanism?  Let’s say the sender of the proposal
doesn’t see it reflect in the epoch after it sent proposal.  And then not in
the next epoch.  Does it try resending indefinitely?

** Section 15.1.
   If Alice asks
   Bob "When are we going to the movie?", then the answer "Wednesday"
   could be leaked to an adversary solely by the ciphertext length.

This setup seems a little simplistic.  If the application data is encrypted to
begin with, how does the adversary know the question being posed by Alice?