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

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

Roman Danyliw 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:
----------------------------------------------------------------------

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


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