Re: [MLS] I-D Action: draft-ietf-mls-architecture-01.txt

[Joel Alwen <[e-mail]>]

Hi everyone,

I've read over the architecture draft and put together some thoughts
that came to mind. Some are just small typos while others are a bit more
substantial. Feel free to incorporate, ignore or talk to me about whatever!

- Joël


------------------------- Comments on MLS Architecture --------------------

- Abstract : "It is meant to protect against eavesdropping, tampering,
and message forgery." This omits PCS and FS which, IMO, is quite central
to what we are doing. Thus, already in the abstract, I'd add something
referring/hinting to FS and PCS (e.g. protecting against "past or future
device compromises" or something else along those lines). The same goes
for the Introduction as it currently also only talks about E2E security.
After all, for the security notions outlined in the abstract and intro
(i.e. basic E2E authentication and privacy) we could use MUCH simpler
protocols (e.g. a static group key decided upon during group setup. Even
just FS would be much easier E.g. a hash ratchet would do the trick.).
This, is why I believe much (most?) of what we are doing (on the
protocol level at least) is about getting PCS and FS on top of the usual
E2E security. Despite this, as far as I can tell the first mention of FS
and PCS are only in 2.3.5 under the heading "Membership and offline
members".


- It is not really clear to me why we require the Authentication Service
(AS) to issue credentials binding identities to keys. I believe this
should be optional. In particular, if users are able to ensure this
binding on their own (e.g. using an external authenticated channel to,
say, comparing key fingerprints or scan each others 2D barcodes) then it
does not seem necessary to have the AS provide these credentials. My
concern is that by not making this optional we are more restrictive than
really need be. Ultimately what the MS should do is provide *some*
mechanism for verifying the binding of identities to keys. Whether its
via certificates from an AS attesting to the binding or some other
mechanism performed by end users them selves seems less important to the
rest of the MLS protocol.

- I'm not a fan of having the DS do key storage for initial key material
but have the AS store member (public) key material. (I also think the AS
should store client public keys along with member identity (public)
keys.) In general, to me a natural logical separation is that the AS is
in charge of public key storage and dissemination while the DS handles
of storage (buffering) and dissemination of traffic. Additionally, some
issues with the current division of labor between the AS and DS that
could then be avoided are:
    - Its not clear why ordering for the storage of initial key material
should matter.
        - 3.1.5 "The DS must only persist data required for the delivery
of messages and avoid Personally Identifiable Information (PII) or other
sensitive metadata wherever possible." This sentence doesn't seem very
compatible to me with the DS also persistently maintaining initial keys;
especially together with credentials ultimately binding them to a member
(or at least client's) identity.

- At the meeting in Paris we very brief discussed that it could
eventually make sense to have "the server" maintain some of the group
state on behalf of clients (but, of course, without introducing any
trust in the server beyond the current "universal ordering" and "no-DOS"
assumptions). With that in mind it may eventually make sense to mention
this role as part of the DS's tasks. Alternatively, this could be
considered part of the AS's role or even a third service exclusive to
this purpose.

- 2.3.1 I'd specify that the initial *public* key material is stored
with the DS.

- 2.3.1 I don't see why the AS should be involved in binding the Client
keys to the Member keys. It should suffice for the Client public key to
be signed by owning member's keys. As far as I can tell this doesn't
involve the AS.

- I think a brief, 1 or 2 sentences clarifying key material names would
be helpful. Something like: a member has one pair of long term "identity
keys", a client has one pair of medium term "client keys" and many short
term "initial keys". For example, this could come right after the
concepts of Member's vs. Clients is introduced.

- 3.1.4 "affect the group state". IMO the transcript (i.e. chat history)
is part of group state. So appending a message to the transcript is a
group state change. I guess what is meant here is the group's metadata?
Given that this metadata is also referred to in other places (e.g.
3.1.5) would it make sense to include a sentence or two somewhere making
a bit clearer the terms "group state",  "group metadata" and "group's
private content" (as used in 3.2.2 for e.g.). In any case the difference
between "state" in 3.1.4 vs. "metadata" in 3.1.5 isn't too clear to me.

- 3.1.5.  "A Messaging Service provider that has control over both the
AS and the DS, will not be able to correlate encrypted messages
forwarded by the DS, with the initial public keys signed by the AS."
This seems like a very strong property to shoot for. (Also, given the
discussion in Paris, deniability didn't seem to be a serious goal of
MLS.) At the very least it would require the protocol packets not to be
linkable to long term identities (OK but we must be careful with
signatures) but also that the DS authenticate clients via (pseudonymous)
identities. After all, if the DS does not identify clients at all, say,
when they request packets buffered in some queue) then, at the very
least, traffic analysis becomes too easy to perform (or alternatively
DOS attacks become too easy if the queue is emptied). So just to be
sure, is deniability with respect to compromised AS and DS really what
we mean here?

- 3.1.7 typo: the word "messages" is repeated.

- 3.2.2 Message Integrity and Authentication: "and that one Client must
not be able to send a message which other Clients accept as being from
another Client." This seems weaker than what we want and get (from both
the ART and TreeKEM drafts). Instead, we want that "no coalition of
Clients can send a message which other Clients accept as being from a
Client not already part of that coalition." A similar change should be
made to the first sentence in 3.2.2.5 and 4.4.

- 3.2.2.1 "MLS provides additional protection regarding secrecy of past
messages and future messages." I suggest changing this to "...regarding
secrecy and authenticity of past..." Especially in the PCS case
authenticity is just as much a goal as privacy. But also for past
(undelivered) messages when compromising a sender we still expect (and
get) authenticity. In particular the sending keys are already deleted so
the attacker is expected to not be able to create an alternative
ciphertext for that AEAD encryption key. In more detail, authenticity
should also be mentioned (next to privacy) in the more detailed
paragraphs on FS and PCS in that subsection.

- 3.2.2.1 The PCS version described here is too strong. MLS really only
guarantees PCS if between time t and t' the attacker did not forge a
message on behalf of the compromised client. (Not only can a forged
message not be prevented by MLS, it also causes the compromised client's
state to come out of sync with the rest of the group.) So instead, one
solution is to say something like "MLS provides PCS security when the
attacker remains passive between times t and t'". Although this is a
somewhat stronger restriction on the adversary than we really need to
get PCS it is a clear, succinct yet still reasonable notion we do satisfy.)

- 3.2.2.1 "Regardless, MLS does not allow addition or removal of group
members without informing all other members." Out of curiosity is this
really true for ART and TreeKEM? Suppose A, B and C are in a group. A is
corrupt so she sends a add-member message to B informing B that D has
joined the group. We specified that the DS shouldn't "know" about group
membership so it should permit forwarding this only to B. A priori, now
B thinks D is in the group but C doesn't right? In fact, if B sends
message to the group (not maybe an update though) its not clear to me
that C will realize B thinks D is in the group... Worse, D will actually
be able to decrypt the message. In fact, if D gets their hands on a
messages sent by C they could also decrypt them (at least before an
update occurs) since they are protected only by the group key which D
knows. Any way, it might just be me, but I'm not too clear if, or at
least, to which extent or in which sense we really get this property.

- 3.2.2.3 "hence slightly weakening the PCS guarantees for attachments."
I'd probably phrase this as "hence potentially extending the time before
PCS guarantees take effect." rather than use the term "weaken" as its
the same security notion. (I believe that in crypto papers the terms
"stronger" and "weaker" are normally used to describe security games
that strictly imply (or are implie by) each other. But, the parameters t
and t' in PCS are not part of the definition of security game. Rather,
they are a function of the adversary and all inputs and random coins
used in the security game.)

- 3.2.2.5 My take on the discussion about deniability in Paris was that
there was a general consensus that deniability is not an interesting
goal for MLS because what we could achieve is too weak to be interesting
while notions strong enough to be worth it in practice are out of our
reach... but to be sure I'd recommend at least checking the notes from
the meeting to confirm.

- 4 First paragraph. Typo: "in" repeated twice.

- 4.1. Realistically we might want to also add leaking meta-data. E.g.
who talks when to whom and how much they say as well as when updates are
performed vs messages exchanged.

- 4.4 "It will also be able to send messages impersonating the
compromised Client until the Client updates its keying material (see
Section 3.2.2.1)." I think, at least if an update has been forged on
behalf of a compromised Client then even if the Client updates its key
material it still wont be able to send messages. In fact, in this cast
AFAIK A) forging can continue and B) the Client can no longer rejoin the
group; at least not without wiping its state completely and re-joining
from scratch. If this is true then we might consider adding a caveat to
the quoted sentence reflecting that updates only recover sending
capabilities if no update was forged in the meantime.





On 10/23/2018 01:12 AM, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Messaging Layer Security WG of the IETF.
>
>         Title           : The Messaging Layer Security (MLS) Architecture
>         Authors         : Emad Omara
>                           Benjamin Beurdouche
>                           Eric Rescorla
>                           Srinivas Inguva
>                           Albert Kwon
>                           Alan Duric
> 	Filename        : draft-ietf-mls-architecture-01.txt
> 	Pages           : 16
> 	Date            : 2018-10-22
>
> Abstract:
>    This document describes the architecture and requirements for the
>    Messaging Layer Security (MLS) protocol.  MLS provides a security
>    layer for group messaging applications with from two to a large
>    number of clients.  It is meant to protect against eavesdropping,
>    tampering, and message forgery.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-mls-architecture-01
> https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-architecture-01
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls