Subject: [MLS] recruiting reviewers: mls-architecture

From: Sean Turner <[email-masked]>
Date: Wed, 19 Sep 2018 11:11:54 -0400

At the MLS@IETF102, the chairs took an action it to identify additional reviewers. If you are interested in reviewing this draft now that it is a WG item, you can either contact the chairs ([email-masked]) or just submit the review directly to the list; note that the chairs are going to suggest that comments be sent to the list. To save list churn if you just have editorial comments you can send them directly to the authors ([email-masked]).  Note that we are hoping for 3-4 reviewers.

Finally, you can also submit issues and PRs in the repos:

mls-architecture:
https://github.com/mlswg/mls-architecture
And,
mls-protocol:
https://github.com/mlswg/mls-protocol

So let’s get this party started!

spt

---

From: Dave Cridland <[email-masked]>
Date: Wed, 19 Sep 2018 17:02:11 +0100

On Wed, 19 Sep 2018 at 16:12, Sean Turner <[email-masked]> wrote:

> At the MLS@IETF102, the chairs took an action it to identify additional
> reviewers. If you are interested in reviewing this draft now that it is a
> WG item, you can either contact the chairs ([email-masked]) or just
> submit the review directly to the list; note that the chairs are going to
> suggest that comments be sent to the list. To save list churn if you just
> have editorial comments you can send them directly to the authors (
> [email-masked]).  Note that we are hoping for 3-4
> reviewers.
>

I am, of course, never one to miss a party.

I've reviewed the Architecture draft, which looks good (two minor changes
submitted at PR #32).

I was, however, left wondering whether a third party can, observing a
message passed within a Group it is not a Member of, prove that a message
was sent by the Member.

I mostly think this is impossible. But I'm really not sure.

I'll try to get to the Protocol draft later, where the yawning gap[s in my
knowledge of cryptography will amuse everyone.

Dave.

>
> spt
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Dave Cridland <[email-masked]>
Date: Wed, 19 Sep 2018 20:25:32 +0100

> So let’s get this party started!
Further partying:

The third para of "Terminology" seems to have a truncated sentence, perhaps
just a missing period after "head of the subtree" here: "A subtree of a
tree is the tree given by the descendants of any node, the head of the
subtree The size of a tree or subtree [...]"

"Merkle Proofs" says that a proof is "the value of the leaf node, as well
as the values of each node in its copath". The ASCII-art diagram shows the
proof for A as being B and CD, yet I read the quoted portion as meaning it
should include A as well. Either I am being daft (possible) or the
ASCII-art diagram also mark A with an asterisk.

"Ratchet Trees for ART" doesn't appear to have a definition of the DH()
notation. I assume it's the DH operation as defined in the ciphersuites
section.

When discussing the ciphersuite "ART with P-256 and SHA-256", the document
appears to suggest that the identity KDF is "non-trivial" - is that right?
Or is it saying that the overall KDF is non-trivial? Or that it is trivial,
but it doesn't matter?

When discussing Blank Ratchet Tree Nodes, it's not clear (to me) whether
nodes always remains blank, or if subsequent Adds might revive them into
real values. So with a trivial tree:

  AB
 /   \
A    B

Removing B leads to

 A
 / \
A   _

Does adding C then lead to

  AC
 /  \
A    C

?

I will try to find the time to knock out a toy implementation of (probably)
ART, which might uncover other issues (but might simply remind everyone why
I should never write cryptographic code).

Dave.