rohan-wire
commented
1 year ago I have submitted PR #183 that addresses most of Roman's telechat COMMENTS, and all of the DISCUSS issues except for this one:
** 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?
I think this is application and possibly deployment specific. At the moment it is pretty simple, since the protocol only defines basic and x509 credentials. x509 is obviously stronger. But several of us are working on presenting VC/VP credentials in MLS. I could easily imagine a deployment where x509 credentials provide stronger overall security than vp credentials because revocation is better specified; and I can imagine a different deployment where vp credentials provide better anonymity and privacy protection than x509 credentials and the revocation point is moot because very short lifetimes are appropriate. @rdanyliw I propose to leave this text as is. If that isn't acceptable to you, could you please provide a bit more detail what you are looking for here?
rohanmahy
seanturner
ekr
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
(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.
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?