Minutes interim-2019-mls-02: Thu 09:00
minutes-interim-2019-mls-02-201905160900-00
| Meeting Minutes | Messaging Layer Security (mls) WG | |
|---|---|---|
| Title | Minutes interim-2019-mls-02: Thu 09:00 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2019-07-09 |
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)