Minutes interim-2019-mls-02: Thu 09:00
minutes-interim-2019-mls-02-201905160900-00

MLS Interim

Berlin, DE, May 16, 2019
Chairs’ Intro (Sullivan)

Note-taker + Jabber scribe: RLB

RLB: Recent history and plans:

    Draft-05 was intended to incorporate a bunch of more major changes, e.g.,
    the common framing that changes the authentication scheme Draft-06 and
    draft-07 will be more about optimization ACTION(Beurdouche): Let’s go
    through and mark sections as Ready For Analysis, post summary to the
    mailing list Beurdouche: We should publish a draft-06 that cleans up
    draft-05, immediately after the interim (👍) Agenda bash: Add overview of
    draft-05

Overview of draft-05 (Beurdouche)
Tree-hash

Should rename GroupState to express that it’s really just a commitment

Question: Do we need the transcript hash?

    Probably, it simplifies analysis
    And we should probably include more in the transcript
    Beurdouche: We can probably do something different than the confirmation
    MAC that would avoid the circular dependency problems

Common framing

Per-group info (group ID, epoch) in the clear

Per-sender info is encrypted with explicit nonce

    So 2 AEADs for now
    Might do “masking” as with QUIC later

Questions for feedback / analysis:

    Amount of metadata encryption
    Style of encryption (AEAD vs. masking)
    Does the authentication work?

Architecture: We should capture the discussion about security properties in
this document

    Joël: Might be hard to be super crisp about this in this doc
    Karthik/Cas: We are getting a better sense of the negative cases -- what
    shouldn’t happen

Federation

Major question is how a distributed delivery service can guarantee ordering

    Current assumption is that one DS “owns” a group

RLB: Need to say something about ordering, not sure where we should be in the
spectrum between “you need to do something” vs. “here’s a specific, concrete
implementation”

Joël: There will be alternative approaches needed. So even if we specify
something concrete, we should specify the general outline of what’s needed and
explicitly allow for alternative implementations.

Britta: Need this “API” for the sync service in order to support analysis

    How dependent are the guarantees on the transport properties?
    RLB: It seems like we should be independent of the transport
    Beurdouche: More worried about authn than confidentiality, e.g., re-use of
    authn keys in different contexts Cas: Synchronization is pretty independent
    of authn. Maybe we need to be clearer about security requirements around
    authn service, especially in the multi-AS case Britta: Would be helpful to
    have some examples of how people might want to deploy this, what sort of
    authn systems might be useful

Client/server interactions

    Joël: No idea how sync works in the client fanout case
    RLB: Clients would have to agree among themselves

Joël: Should we specify anything about discovery?

    RLB: We would need to define a user addressing scheme and discovery /
    authentication based on that

Client fanout: Open question - How can ordering be enforced in this mode?

    Igor: Are there DoS considerations here?

Current message syntax specifies, e.g., how to request a UserInitKey

    RLB: Might be better to use JSON for this, since it’s more familiar and we
    don’t need to fix stuff for crypto purposes

Message Franking / Deniability

Millican: Franking can live alongside a deniable transport. E.g., the FB
franking service authenticates the FB identities, not the device keys

Millican: Have had some discussion of doing sender-keys-style deniability --
distribute a signing key 1-1 over a deniable channel

Cas: Could also use the OTR trick of publishing the authn keys

RLB: How does franking fit in with the overall protocol picture?

    Millican: It can be done orthogonally, since a requirement of the first
    version was to use libsignal unmodified

So we can do MLS without regard to franking and it can be cleanly added later

Possibly follow-on work
Analysis (Cas)

Comparing to pairwise-based groups, there are some continuity / clarify
benefits for PCS

With ART / TreeKEM, when you heal, you heal exactly that group

With pairwise, when you heal, you heal a bunch of individual channels, which
then can be used, e.g., for forming new groups

Sender keys, however, is even weaker, because you heal outbound but not inbound

Still need to be able to rotate forward signature keys

    This can achieve some properties that are even better than Signal
    RLB: How do you move forward signature keys with PCS?
    See paper; you get a “PCS-like update” on the authentication data

Risk of information leakage, in particular, leaking which other groups you’re a
part of, how often you message in them

Want something that updates N groups in sub-linear scale in N

    Overlap with LazyUpdate
    Compositional approaches might be feasible, e.g., have a whole-corporation
    group over which you send a LazyUpdate that gets applied to each group that
    the sender is in

Joël: Some similar concerns with regard to FS (not just PCS). Want to have
updates spread around the tree

    When Alice updates, need one update per copath node
    Might make sense to have multiple trees where people are reordered relative
    to each other, then combine the root secrets to get the group secret

Millican: A degree of “PCS nihilism” w.r.t. very large groups

    Karthik: PCS is pretty OK actually, FS is the harder case

RLB: Split between base security protocol and deployment guidance

    Would probably want to document deployment cases
    And will likely need some additions to base protocol, e.g., LazyUpdate and
    signing key rotation

Summary:

    Big difference in PCS between pair-wise and group-wise
    Also differences between scoping to a single group, vs. multiple groups /
    subgroups Forward security after a compromise is hard (“PCFS”)

Security Analysis Update (Karthik)

Presentation

Transcript hash needs to cover more, e.g., sender identity

Hashing up the tree

    Different subtrees / transcripts can result in the same path secret
    We should throw some more stuff into the context for the KDF, e.g.:
    -- Tree hash of the other child
    -- Transcript hash up to prior index
    If we don’t have this, we don’t lose confidentiality, but we lose the
    property that keys at different points are independent

HPKE context also not used, maybe should be

Signature doesn’t cover enough

    In particular, doesn’t cover transcript
    If you have two groups with the same GroupID / epoch, you can forward
    between them For Handshake messages, confirmation MAC seems to fix this;
    application messages don’t get the benefit of this Two types of
    authentication: -- AEAD authenticates origin is in the group -- Signature
    authenticates specific origin

Adders can lie to added nodes

    Example:
    -- A (mal) adds B, provides a bogus tree
    -- B tries to remove A, then sends a message that it thinks A can’t read
    -- A can still read this message
    Weaker definition of authentication, since new member can only verify
    membership of people he’s heard from Konrad: For example, new joiner could
    send a ping, and get signed messages Jon: Or you could unicast a per-sender
    secret that gets KDF’ed into per-sender keys Karthik: Every node in the
    tree has a signature by the last member that modified it -- Might not have
    to have signatures on blank nodes, since they can’t be double-joined --
    Still has some risk of replay of old trees Cas: It would be nice if we
    could incur the cost only at add time -- E.g., sign the whole path and
    provide all the paths to the new joiner -- O(1) at send time, but O(N log
    N) at add time -- Even better with BLS! \ Raphael: Do we actually need to
    fix this? It’s yet another malicious insider problem -- Alternative:
    “expensive remove” = KEM to leaves directly TODO(Beurdouche): Make a PR
    with the version that Karthik presented (adding signatures on nodes)

Remove order of update and blank in Remove

    In the best case (sibling), this heals the tree immediately
    Less compelling for Add, since the new member should update anyway
    -- Could update just from common ancestor
    👍

Tree-Based Key Derivation (Joël)

Presentation

General principle: Every secret is used exactly once, then deleted

Derive sender ratchet roots as leaves of a tree

Still requires forward and backward reordering bounds

    Backward to bound key storage
    Forward to bound DoS from computation

How to handle failed decryptions?

    Unwind everything?
    Partial unwind?
    Unwind might not be bad if the order of operations is generate-decrypt-apply
    But we don’t need to require that, since it’s tolerable to pre-generate any
    subset of the tree -- as long as the consumption rule is followed

How much do we need to specify this?

    We should not specify any given storage modality
    Deletion schedule is important for ruling out bad possibilities, e.g., just
    keeping around the application secret Might not save space if values are
    pre-allocated

What should the HKDF context be?

    Within tree needs to be at least “left / right” or node index (👍 latter)
    Within ratchet nothing strictly necessary, generation might be nice (👍)
    Karthik: should have a clean API between key exchange layer and app layer
    -- (epoch, application_secret, state_commitment)
    -- Need state_commitment b/c signatures need to cover it
    Target merge in draft-07 (not quick-fix draft-06)

Multi-Device (Raphael)

In the “virtual client” case, self-remove / server-initiated remove could be
challenging Issue Review

mls-protocol

    #132 - closed
    #113 - Generally OK feeling
    #152 - Might cause issues with server enforcing ordering
    -- Maybe include both before/after epoch in handshake messages
    (flip through issues)

mls-architecture

    (flip through issues)