Draft: draft-ietf-mls-protocol

Commentary: Thanks to   :
Mailing list commentary: Reviewer : Review result : On the Right Track This is an early review of draft - ietf - mls - protocol-16 , which seeks to specify a key establishment protocol to provide scalable efficient asynchronous group key establishment . This document seems to define a component that could be used to build or operate over an Internet transport . The focus is on security algorithms and procedures . There are some issues that Major Issue : This would have been easier to understand if there was a section that described the transport requirements of the messages . This makes me wonder what transport service is actually needed ? - Can the underlying transport reorder messages ? Is loss tolerated or reliability required ? Are there any requirements on message size ? etc . A brief paragraph explicitly explaining the requirements would help . A later statement says , which appears to suggest any service can be used : " MLS is an encrypted messaging layer designed to be transmitted over arbitrary lower layer protocols ..... " I note draft - ietf - mls - architecture states : " MLS is not intended as a full instant messaging protocol but rather is intended to be embedded in concrete protocols , such as XMPP [ RFC6120 ] . " This could form a part of such an explanation , if it applies to this ID also ? Major Issue : The document targets PS , but the version I reviewed a " DISCLAIMER : This is a work - in - progress draft of MLS and has not yet seen significant security analysis . It should not be used as a basis for building production systems . " - Why is the final document proposed as a PS rather than EXP , if this is not for general deployment ? Or is this clause to be removed by ? Major Issue : From a transport perspective , there are issues in the statement providing insufficient guidance on selecting a rate : " Update messages SHOULD be sent at regular intervals of time as long as the group is active , and members that do n't update SHOULD eventually be removed from the group . It 's left to the application to determine an appropriate amount of time between Updates . " One possible way to address this is to state that the messages are either sent over a congestion - controlled transport or the maximum aggregate rate of messages falls within a specific guideline as defined in RFC8085 , or some other BCP with similar advice on rate selection . Minor : " Application messages MAY be padded to provide some resistance against traffic analysis techniques over encrypted traffic [ CLINIC ] [ HCJ16 ] . " - Padding is a well known technique - it can have benefits and also have drawbacks , e.g. in efficiency of transmission and for message - based transfers in reducing robustness to paths that have limited PMTU , where larger messages can be dropped . Minor : " A receiver MUST verify that there are no non - zero bytes in the padding field , and if this check fails , the enclosing MLSCiphertext MUST be rejected as malformed . " - I do n't doubt that this is useful , but it would be helpful to add a sentence to explain why these are required to be encoded as zero .
Paragraph (version A):
DISCLAIMER: This is a work-in-progress draft of MLS and has not yet
seen significant security analysis.  It should not be used as a basis
for building production systems.
Paragraph (version A):
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.  It's left to the application
to determine an appropriate amount of time between Updates.
Paragraph (version B):
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.  It's left to the application
to determine an appropriate amount of time between Updates.  In
general, however, applications should take care that they do not send
MLS messages at a rate that overwhelms the transport over which
messages are being sent.
Paragraph (version A):
The "padding" field is set by the sender, by first encoding the
content (via the "select") and the "auth" field, then appending the
chosen number of zero bytes.  A receiver identifies the padding field
in a plaintext decoded from "MLSCiphertext.ciphertext" by first
decoding the content and the "auth" field; then the "padding" field
comprises any remaining octets of plaintext.  The "padding" field
MUST be filled with all zero bytes.  A receiver MUST verify that
there are no non-zero bytes in the "padding" field, and if this check
fails, the enclosing MLSCiphertext MUST be rejected as malformed.
Paragraph (version B):
The "padding" field is set by the sender, by first encoding the
content (via the "select") and the "auth" field, then appending the
chosen number of zero bytes.  A receiver identifies the padding field
in a plaintext decoded from "MLSCiphertext.ciphertext" by first
decoding the content and the "auth" field; then the "padding" field
comprises any remaining octets of plaintext.  The "padding" field
MUST be filled with all zero bytes.  A receiver MUST verify that
there are no non-zero bytes in the "padding" field, and if this check
fails, the enclosing MLSCiphertext MUST be rejected as malformed.
This check ensures that the padding process is deterministic, so
that, for example, padding cannot be used as a covert channel.
Paragraph (version A):
The length of the "padding" field in "MLSCiphertextContent" can be
chosen at the time of message encryption by the sender.  Senders may
use padding to reduce the ability of attackers outside the group to
infer the size of the encrypted content.
Paragraph (version B):
The length of the "padding" field in "MLSCiphertextContent" can be
chosen at the time of message encryption by the sender.  Senders may
use padding to reduce the ability of attackers outside the group to
infer the size of the encrypted content.  Note, however, that the
transports used to carry MLS messages may have maximum message sizes,
so padding schemes SHOULD avoid increasing message size beyond any
such limits that exist in a given deployment scenario.