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

[Emad Omara <[e-mail]>]

Thanks Joel for the detailed feedback, this is very useful. I added some
responses below.

Emad

On Wed, Oct 24, 2018 at 4:56 AM Joel Alwen <[e-mail]> wrote:

> 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.
>
While I think in most cases DS and AS will be actually the same server or
maintained by the same party, but I agree with you if we have a separate
service for authentication it makes more sense to store the init key as
well.
What do you mean by "ordering" here?

>         - 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.
>
Good catch! we should fix this by either moving the init key storage to AS
or update that paragraph.

>
> - 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.
>
Will take about this in the IETF session.

>
> - 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.
>
Yes transcript here means the group metadata, but I agree which have a
clearer definition for what is group state and what is metadata

>
> - 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?
>
I think this is more of privacy protection than deniability, we usually use
deniability for peers deniability and not server

>
> - 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.)
>
I think that makes sense.

>
> - 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.)
>
Thinking about this more, I think PCS is the wrong term here, should be FS
instead, because if the media key is compromised then the attacher will
have access to that media.

>
> - 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.
>
Deniability is still one of MLS goals, however having it required vs
optional is still an open question. I will bring it up again in IETF to
make it clear.

>
> - 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
>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>