[MLS] draft-ietf-mls-architecture and draft-ietf-mls-mls-protocol review

Sofía Celi <cherenkov@riseup.net> Tue, 28 July 2020 04:09 UTC

Return-Path: <cherenkov@riseup.net>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A793A0BDF for <mls@ietfa.amsl.com>; Mon, 27 Jul 2020 21:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCRXkwZu5Ev6 for <mls@ietfa.amsl.com>; Mon, 27 Jul 2020 21:09:12 -0700 (PDT)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C339C3A0BDE for <mls@ietf.org>; Mon, 27 Jul 2020 21:09:12 -0700 (PDT)
Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4BG38S1sZhzDsf0 for <mls@ietf.org>; Mon, 27 Jul 2020 21:09:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1595909352; bh=YypRHAnjH/AwHbCfoJnxtBkkJC+b0n+GdjgI31UHmoM=; h=To:From:Subject:Date:From; b=JfADqmzbvQ6gpBJiPyfAQdELaKjpcDYnDRn901ZxZ5K9bg5sYGu0AVhOs8Tlkbeif EHAt+O8R9uUtxuN1wZf0KCbT/n59zf52yRqR3hwLC/Q1IQJKLqKWOD/A2c7zxsz5Hu IYZbeX40PZvxoi8A15bm8N+qIYsZND358Yk5gig8=
X-Riseup-User-ID: 2BE4E444CEED8FD6C4286212850B30AA8E91C25E083BA772231F969616D9C4BD
Received: from [127.0.0.1] (localhost [127.0.0.1]) by capuchin.riseup.net (Postfix) with ESMTPSA id 4BG38R3hZwz8sgc for <mls@ietf.org>; Mon, 27 Jul 2020 21:09:11 -0700 (PDT)
To: mls@ietf.org
From: =?UTF-8?Q?Sof=c3=ada_Celi?= <cherenkov@riseup.net>
Autocrypt: addr=cherenkov@riseup.net; keydata= mQINBF2PpxoBEADAIhbOpA23OBsXzg/aQakv88vaLv8Dxt2oR92Rz9cfxca736HKDeO19IFC F1Anu6ylQsJfoT4UUgbGIjJpHtQB3OVIcgvsMagfZ0lEHd1eG8H8K9wqSjwSphUJl9ra+tMW MEbSDVmeV6qvHeO63vrazXrgUKBf0jDae0HcK++AYiSeSpbTmN+zTsY3ZXy9H1sdNhMUlkGt jcpROrna2NaSL3YG8YNJHsN+zGPoaBbPo9gQALUvuxtg0yS/ecly2xomWIeH6qJ4yJonO/Ys WqAAC96n423BeC1cAyYjij8ydygnR3csTibUI/iPkoH8xstnTyrv3djyiunVuw1BQUNqmtLV v7meRZfIFbfnNatuuPYp7S5NnL58vUwY/BwlMb5OhyzdCckRcITAXiz8sp4LANx1lxIdbaQA 9NsYv32vem9Pd0wtdN5JTW3dajgJtPAC1yfR86rw9u/+BSW9KhRqNF0/a+hX/+Njdni9fkl9 EheZiFHNO+nXeGLy0kikhUXr5iLg8626fG9I8QYuNj05WIEntegvAW65YjGTYSCdVgLx2bvv oGwC/4/jWxNm8MTzv38f/9YAZ5u5DSG3dFKYAjwOhf1IgEMTEWj+bKDFvgpv5fdTFumLxNey M/v3viwuNjS1hscRbi6IO36v4sFce4K1C5GU93YIgao2j01M8QARAQABtB1yaXNldXAgPGNo ZXJlbmtvdkByaXNldXAubmV0PokCVAQTAQgAPhYhBPq5Ptx83RGY3P1FWJG7a0VvRC0CBQJd j6caAhsDBQkHhh+ABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEJG7a0VvRC0CEV0P/2UN rjx8LYmz/ydk2XO/uNWyobCtj/y9XBhZG9dpB8R43VC8OS5gv4Nw2ZLDrrpLQmaQ2dXjAeLL +9eCM++QT//VP2j2QS3YKbIcRreXSnl7DI6bMpD+Pu3JwiYHSyBs1zZT+VGm4nTS6QH588XJ VrslKyDYJFfzaHgkIGtxAWgqaHWAZHtjqh6PNEWMe2t571YYcVlk29cWsJ5ITsSPb+0Y0xJn u5HKQOc4TOdraedpLSFb5CZRlusNgWvhqmL4VyIcfjSEY0B8JVOgVpUeNTy0sZcDflYJ6uSN 9B1m79kb8STnVOtFS9gjnWbVwjAunqkkb/joRZhYfjeANVyYC4skh0uqJLFtqJw4r8s9+MrE p4lBy30lQ7mYYyqvRcwyEgoRRLHUvzV6cIHau/HV1pw0lwcbiXk3jP+TMf6OKOzg6lGJ/zX0 ZD+s0OAvHh8GM+5TDlgEM4Dwp6Q+9Jr1m9sp1QDQVbU7xrXXndXDd8RLEkiMDLovyyDtN6Jn HsW9PVMtu6sXvmbn0AHeHzHU/+bwB1LF4sx8O82tWKCgZlm270p+Bk6mjYmrlO4eQ11/AOF6 3ZlVoeXSaM4X0yoKa3ltdWaRoy9L0a4p7JuQYhBYIzjARbVjp9CmxctuQqW2qNSCJfagsUl8 mpcrs7xdhzfhzZHf8kQYWQcPYPPWLWqIuQINBF2PpxoBEACow9T4wPaQvKNG2LBnXeuLkDxf VGrZ/fDk0yfhG0174SjWXvDMIAgdNmfn2F4CM4F2FfPI32NZT34Td89fyWEWvP5/2I9HywyI QI/ubQvbqvm0l+DyzsdZNj4MBmNLy34Rg3K8uScgG7YbakzUplalbQKuzHrSW5OL5aBeKOG2 NGKJK7VZ4MzbdxhCLnXYvQwgnSkJ6B3AoBGv0LsLYzGUixzlMbNmYEhlQcK2scqprmFoX9rQ ymStV8b4Z37gkVmYeWGG2D9zl8gLj0u5Xw/KlF45JNxtMFBSL+Px7E1c+GJTWJxIENBhxRAu fxvbvduyJdXTObI51bqgV57510RjoLdzvVVqUpevmIdaMnavyUnDZOb8sBg3JG6NozZVzlXf S3FAvvK82zRShpd06ZNUbxPtNkruH/dT+6QV8gW3jX15gKGp2CtvhxLbi8ysV6zwtqxPkba2 03J0RAq2lVzxE/CSAP2qGPttElzHOPqhdmL6XjdmTw/WpF+qT8acB6Te8HZF+DriR/xG6EA1 MSdIK0vX4r5+U5bd0r7sh1ysSaYk/RI8hqxZZ4VGdPbVhFCOdT8AVcEXRoLsv+oN4x5WYJ9g 8G8Xw9+DvCNjFLxaGcL0ATHc8u8TyeegGRF3ZQNsRCqfVOLEYclYX+DqIly4ebCawAoIeWg2 GvN9cJAnFwARAQABiQI8BBgBCAAmFiEE+rk+3HzdEZjc/UVYkbtrRW9ELQIFAl2PpxoCGwwF CQeGH4AACgkQkbtrRW9ELQJX3g/8DAxtZTUJAlbKkluY30zITfcUwH4h9Rppxx/RvibZ1R4k 960OlvwyoRZ5rv2XiQA5VxOaVlh1tJErZnAyqgYwHr5CGQBjPEgkmRWBzme4W62uvCXOahxJ 4lNpr0TrVGRNOu223zYQcaN5S4Q5H2U9XNUFx8UF5leZIL6/Z6/bSGEW27vSuCxY6v8MkhQC 6l8T5RJqDsJmhwcVg9KDm8eGLkiu+kXS8iKl/Bw4o9257BI8hswBVRhN8kpHsecP2MGzKwn9 ccXWnOfM75qiq566UI26MY5priaGz5i+eCo26Rc0edm0IXxNs6rUZKVQUoxfMb/A/buJknYZ lUYXAgG2eDHEjlXvqNxQWHgfhIGqKFXDWuMt0sKP7Ta/lvGVPx9IHCTvkRZn9mtIN2/F9Lt5 sK3kezAlFw3BK6AIbD2v+g8TZnvKWSBidJHyhh7OEmKg3gXA3DxBpb7TU6iVUfG5e10RJUvQ qQNTSxv6mxJOgE3mEXizzj+tC6aEG/BzBwDsQpKquzUIKGCF2EGX9C7CZBhlsng/zmL3TFH6 EnY1tqV/lEg2/+gCLy/OE2dlE+EDZEtAiV183lzZNBs5Bg9NIz0Gq6a4ZkA8zDOFuxL2BFH2 EqrT33ladX2AIyKPMF50IwY4TMxGRlKhAjb4++pb55vBwVBLaTC09mvA+CuupPU=
Message-ID: <f34e27c3-31ae-6de3-53ee-bd231a174cf9@riseup.net>
Date: Mon, 27 Jul 2020 23:09:09 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/SJkwB9s6GKT0nfw-iS5XiE8neug>
Subject: [MLS] draft-ietf-mls-architecture and draft-ietf-mls-mls-protocol review
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 04:09:16 -0000

Dear, list,

Thank you so much for all your efforts into developing MLS.

After re-reading the architecture and protocol drafts, I have some
comments. Please, excuse me if I got anything wrong. Apologies as well
if this have been already discussed.

- While it is clear on the architecture draft that 'Client' refers to a
device that a user has, it is unclear on the protocol draft and might
generate confusion, specifically, by the definition:

"""
Client:
: An agent that uses this protocol to establish shared cryptographic
  state with other clients.  A client is defined by the
  cryptographic keys it holds.
"""

Might be good to clarify here the relationship with devices and users,
as this is something often enforced by messaging protocols, such as XMPP.

- It is unclear if any member can 'Add' another one. In the case of
'Remove', it is clear, as:

"""
Members are removed from the group in a similar way. Any member of the
group can send a _Remove_ proposal followed by a _Commit_ message, which
adds new entropy to the group state that's known to all except for the
removed member.
Note that this does not necessarily imply that any member is actually
allowed to evict other members; groups can enforce access control
policies on top of these basic mechanism.
"""

It might be good to add the same note to the 'Add' mechanism, as some
protocols might enforce only some members to be able to add others (an
admin, for example). I think this is clearer on the architecture draft.

- While there is a deletion schedule section, it should perhaps be
enforced on several sections where deletion is critical: reuse of
KeyPackages, key/nonce pair reuse, etc. It will be good to specially
refer where these values should be safely deleted, even in regars that,
on some occasions, key/nonce pairs, for example, should be kept in
memory for delayed messages.

- It will be good to enforce a time, as part of an structure to which
retention occurs:

"""
For usability, MLS clients might be required to keep the AEAD key
and nonce for a certain amount of time to retain the ability to decrypt
delayed or out of order messages, possibly still in transit while a
decryption is being done.
"""

This time, I think should be enforced by the application but could be
part of an struct and periodically be checked. After the times passes,
the values should be deleted.

- I'm not really sure of this section:

"""
Decryption is done by decrypting the metadata, then the message, and
then verifying the content signature.
"""

Wouldn't it be better to first verify the signature and then decrypt the
message? I can imagine that, as it is written, an application can show
the messages to the end users without verifying the identity (and I
assume integrity, as well).

- What happens if a proposal or message is invalid?

On these sections:

"""
An invited member receiving a _Welcome_ message can recognize group
creation if the number of entries in the `members` array is equal to the
number of leaves in the tree minus one.  A client receiving a _Welcome_
message SHOULD verify whether it is a newly created group, and if so,
SHOULD verify that the above process was followed by reconstructing the
_Add_ and _Commit_ messages, and verifying that the resulting transcript
hashes and epoch secret match those found in the Welcome message.

and

The sender of a _Commit_ MUST include all valid proposals that it has
received during the current epoch. Invalid proposals include, for
example, proposals with an invalid signature or proposals that are
semantically invalid, such as an _Add_ when the sender does not have the
application-level permission to add new users.
"""

What will be the correct behaviour when failure? Should the messages be
ignored or ask to be resent? I assumed ignored; but might be worth noting.


- Will it be better to use a MAC key?
On the section:

"""
To prevent counter manipulation by the server, the counter's integrity
can be ensured by including the counter in a signed message envelope.
"""

Might be better to somehow derive a MAC key and attach it to the counter...

- Security level:

On the section:

"""
requirements, clients can choose between two security levels (roughly
128-bit and 256-bit). Within the security levels clients can choose
between faster
"""

As I see that ed448 is used, it is worth noting that is security level
is of 224-bit, as stated over: https://tools.ietf.org/html/rfc8032#section-1

I'll keep on reviewing some other parts in the future in more detail.

I submitted two pull request with some grammar fixes as well and can put
these thoughts on issues on the repository.

Thanks!


-- 
Sofía Celi
@claucece
http://claucece.github.io/
Cryptographic research and implementation at many places, but mainly
Cloudflare
FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02