IETF 122 MLS WG

Agenda

Administrivia (5min)

• Note Well
• Scribe: Laura Bauman

Working Group I-Ds (and topics related to them)

Mitigations for Insider Replays

Who: Akshaya Kumar
Time: 15min
Topic: Mitigations for Insider Replays

draft
Who: Chairs
Time: 5min
Topic: Status of PRs received during AUTH48

Github: https://github.com/mlswg/mls-architecture
Datatracker:
https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/

• Chat Encryption should provide privacy and integrity from attacker
  outside the group. Provided with Symmetric Encryption.
• We also need integrity against attackers inside the group. We need
  sender authenticity against group insiders. Need Digital Signatures.
• Symmetric Signcryption Model based on these requirements to evaluate
  applications for vulnerabilities
• MLS aims to protect against attacks by insiders who know symmetric
  keys
• Encryption Key Derivation in MLS is done using a Ratchet tree -> key
  schedule -> secret tree
• key uniquely defined by [group, epoch, leafindex, generation]
• MLS uses sign then encrypt
• Intuition s should authenticate the key id so that group insider
  cannot re-encrypt using a different k and replay message
• The generation is not authenticated -> malicious insider can hop
  between generations
• Second attack: insider re-ordering attack
• Series of messages using sequential keys for different generations
• malicious insider can block the messages and interchange generations
  so messages appear in a different order
• Third attack: Insider INT-CTXT
• signature does not authenticate n so a malicious insider can block
  messages, decrypt and re-encrypt with different nonce. Group members
  are unable to detect this forgery. Less clear what the value of this
  attack is. Only an attack on CT integrity, not PT.

• Mitigations:

  • MLS-level

    • sign generation (include in ad) for attacks 1 & 2
    • sign (pn and r) and or n

  • Application-level

    • introduce a unique ctr included as part of message (1 &2)
    • app shouldn't use ctx bits for anything meaningful

Discussion

• [Rohan] Might be privacy implications of putting generation in ad.
• Akshaya Not immediately clear what those might be.
• [Rohan] gen is per sender. Might give an idea of which senders are
  sending messages based on gen (non-members could see)
• [Richard Barnes] privacy risk not there because generation
  wouldn't be on the wire

-arch

• chairs: we are in AUTH48 and we got PRs at the last second, need to
  get them approved
• Were there enough changes that we need to do another wg last call
• Don't think we need that, followed enough process.
• Anyone see problem with merging them? No.

-combiner

Who: Britta Hale
Time: 5min
Topic: Call for Input

Github: https://github.com/mlswg/mls-combiner
Datatracker: https://datatracker.ietf.org/doc/draft-ietf-mls-combiner/

• was adopted by WG last time
• Puts two different combiner versions
• hybrid combiner separates out two different schedules (pq and
  traditional)
• had a takeaway to expand the security consideration sections
• recently pushed a new draft version. does not include all promised
  updates cause it was the wrong version, but those will be coming
  soon
• think it is pretty straightforward and would like to do last call
  soon
• please read and provide feedback so we can move forward

-extensions

Who: Rohan Mahy
Time: 15min
Topic: Merge of the safe application API/AppDataUpdate/AppEphemera

Github: https://github.com/mlswg/mls-extensions
Datatracker: https://datatracker.ietf.org/doc/draft-ietf-mls-extensions/

• changes to mls-extensions
• was having a hard time getting extensions to work with existing
  framework
• there was confusion between extensions and application layer stuff
• An MLS extension --> something that changes the behavior of MLS

• Application logic need something else

  • Safe Application API for things that don't modify the behavior
    of MLS
  • cleaner, simpler, more concise

• Application "Components"

  • each component has an ID unique within an application used for
    domain separation, data separation

• Exposing MLS functions to app

  • a lot of extensions were based on being able to store state in
    group context
  • App Data Dictionary can list components and put in group
    context, group info, leafnode, key package
  • way to do safe labels
  • aad_items for safe AAD
  • content advertisement

• Attaching app data to MLS messages

  • AppDataUpdate updates App Data Dictionary in group context
  • entirely app specific
  • This presumes there is an API where the MLS stack asks the
    application mid-commit-processing how to apply these updates

• Application-defined proposals

  • AppEphemeral proposal type
  • opaque to MLS but included in transcipt
  • everyone gets the same app data with this commit
  • Doesn't affect MLS at all and Update Path is never required

• Safe AAD follows same pattern as app_data_dict

• Improved negotiation for both extensions and components

  • added two actual MLS extensions

    • supported_wire_formats
    • required_wire_formates

  • added component

    • app_componenst
    • safe_aad
    • content_media_types

• Remapping existing "extensions"

  • AppAck --> now usage of AppEphemeral
  • TargetedMessage WireFormat is an extension
  • SelfRemove is an extension
  • ContentAdvertisement uses a component
  • Last resort KeyPackages implemented as a component

Discussion

• [Richard] ready for WGLC. Hasn't been that involved in doc. Feels
  like the right framework and capturing right stuff now. Nice package
  of stuff and we've been looking at it long enough.
• [Mojitaba] like the whole idea. Heavy use of extensions right now.
  Will clean up a lot of our code so we don't have to abuse extensions
• [Raphael] in support
• [Sean] will get WGLC going within the next week

Non-Working Group I-Ds

-mahy-mls-pq

Who: Rohan Mahy
Time: 10min
Topic: Open issues with ML-KEM cipher suites

GitHub: https://github.com/rohanmahy/mahy-mls-xwing/
Datatracker: https://datatracker.ietf.org/doc/draft-mahy-mls-pq/

• Get new ciphersuites for plain and hybrid ML-KEM
• which combinations of KEMs do we want
• 5 combos (3 hybrid, 2 pure)
• Obvious choice is what is defined in LAMPS: QSF combiner
• Xwing is okay in mls (dont need kitchen sink combiner)
• [Mike] all stuff I am author of is QSF. Kitchen sink is for not
  ML-KEM things.
• [Richard] is this the right set of combinations here (which
  algorithms are we using). non-NIST hybrid, 2 NIST hybrid
• [Raphael] good starting point, no immediate objections. how long
  do we want to keep this open?
• [Rohan] should pull the trigger as soon as we have the codepoints
  for the HPKE stuff we rely on
• [Mike] how do represent the overall combined security of the
  hybrid. presentation in table is weird
• [Bas] post quantum security is 3 bits
• [Rohan] tried to avoid saying low and high level security
• [Bas] lowest security could use sha256 or sha128
• [Rohan] should we use SHA3 or SHA2. SHA3 already in ML-KEM but if
  not implemented in software hard to req
• [Mike] SHA3 not allowed as stand alone anyway
• [Rohan] let's just use sha384
• [Rohan] What KDF to use? Put XOF(SHAKE256) in as a placeholder
  also put in the iana function to register it, but Deirdre wrote a
  draft to do it so will change to reference her draft
• [Rohan] best effort to make some reasonable ciphersuites.
• Need to figure out KDF and KEM combiner (really Xwing or switch)
• think we should adopt this work
• chairs: anyone object? no. will look at more adoption calls.

-mahy-mls-sd-cwt-credential

Who: Rohan Mahy
Time: 10min
Topic: Selective Disclosure JWTs & CWTs

Github: https://github.com/rohanmahy/mls-sd-cwt-credential
Datatracker:
https://datatracker.ietf.org/doc/draft-mahy-mls-sd-cwt-credential

• web token credentials for MLS

• Selective Disclosure (SD) web tokens

  • CBOR Web Tokens (webauthn) and JSON Web Tokens
  • allow a holder to get a web token from an issuer and then safely
    blind or reveal some of its claims to a verifier
  • issuer dicates which claims can be blinded/disclosed
  • can also include decoys

• SD-JWT includes a regular JWT, 0 + disclosures, adn optional key
  binding

• SD-CWT is wrapped in a mandatory SD-KBT (key binding token)
• both of these include the holder's public key

• What can be discolsed?

  • no: any cwt claims that are part of validation of the cwt except
    the subject
  • yes: the subject

• disclosures formed using a per-disclosure salt and redacted by
  replacing with hash of disclosure

• key binding prevents copay and past or replay attacks

• SD-CWTs adn SD-JWTs as MLS credentials

  • need to add to Credential field

    • SDJwt has special syntax

  • works great with pseudonyms. can guarantee unlinkability by
    keeping separate per public key.

    • can't associate members from one group in another group
      based on public keys

  • SD-jwt uses a lot of base64. can use it as is or decomposed to
    make is smaller.

• encrypted disclosures in SD-CWT

  • allows a disclosure to be ephemerally AEAD encrypted
  • in mls allows a disclosure to be shared to group and not DS

-kiefer-mls-light

Who: Richard Barnes
Time: 15min
Topic: Proposed candidate for WG adoption

Github:
Datatracker: https://datatracker.ietf.org/doc/draft-kiefer-mls-light

• make MLS work better in practice for large groups

• Problem: download and memory

  • mls requires clients to download, validate, and store the
    group's ratchet tree

• In a 1,000 participant webex joining a meeting can be slow while
  waiting for download

• solution: light clients

  • able to joing and get confidentiality keys before all the auth
    information
  • light client: does not get ratchet tree before joining
    • cannot commit
    • cannot process a normal commit
    • can join the gropu with O(log N) download/memory

• outsource some stuff to ds to operate

  • if a mix of reg and light clients:
    • reg clients participate as normal
    • light clients will get commits and welcoms with annotations
      (just with slice of tree that client needs)
      • e.g. membership proof

• [Rohan] in implementation you tested, the fact that you needed the
  group context to validate problematic?

  • [Richard] no, group context was pretty small so it wasn't a
    problem. With more application stuff in there it could cause
    difficulties

• AnnotatedWelcome and AnnotatedCommit messages

• There is another draft: split commits

  • commit messages themselves are large (each member has to
    download all ciphertexts even though each is only going to use
    one)
  • this draft allows you download only the ciphertext you need and
    O9log N) size

• If light mls and split commits are used together they can work well
  together to provide a member that doesn't care about authentication
  of whole group with only log scale information. Really nice for
  really big groups (broadcast, iot management, etc)

• Authentication guarantees (big tradeoff with performance)

  • trades authenticity for confidentiality

    • confidentiality is much faster but authenticity info doesn't
      happen right away

  • don't know who is receiving data you send

  • can authenticate senders of data
  • this state is acceptable for several use cases
    • cases where the full member list isn't visible immediately
      anyway (limited visibility into authentication state of the
      group anwyay)
    • broadcast cases (receivers only care about sender
      authentication, but don't care about identities of all other
      recipients)

• need formal analysis that amended security properties still hold

• has been presented at past two IETFs

• now asking for adoption and think it is now pretty mature

  • we have some formal analysis already
  • we have it implemented in mlspp since nov 2024
  • deployment interest from webex, discored, others

• should we adopt and should we combin with the split commit draft?

Discussion

• [Raphael] think this is really values and many implementers need
  it. Fundamentally you have to go for a compromise. Authentication is
  being compromised here. Risk remains that people will perceive this
  as a variant of MLS. For me this falls into the category of
  opportunistic encryption not E2EE. It is more nuanced than that, but
  thinks it is problematic that it is being proposed as a variant in
  that sense. MLS has been covered by a lot of academic research and
  almost a brand. about to be rolled out by Apple + Google. Worries
  about perception with regular MLS. Split commits are not as
  problematic and thinks they should be separate
• [Britta] similar concerns on security. Understands that there are
  use cases where this would be useful, but concerned about security
  statements in the draft and name of the draft. Thinks the text makes
  the security tradeoffs sound minor and that MLS itself is not
  secure. Much clearer warning labels desired and naming should not be
  so enthusiastic like it is a better version of MLS. Actually a
  different approach, not just a "lighter" version. Need to be clear
  on the use cases it is ok in.
• [Rohan] I think we need to do both of these. Keep them separate.
  Split commit stuff is immediately useful and would work well with
  update bath proofs (experimental work I've been looking intoo).
  Proposed name "Partial MLS".
• [Mojtaba] we need this urgent and wants both of them. Okay with
  "light" name. Has already started adopting a similar idea. Not
  hurting MLS itself. Only for large groups and only a couple senders
  that need to be authenticated.
• Chairs: don't combine them, let's debate name, and do adoption call.

-xue-distributed-mls

Who: Mark Xue
Time: 15min
Topic: Distributed-MLS

Github: https://github.com/germ-mark/distributed-mls-id
Datatracker: https://datatracker.ietf.org/doc/draft-xue-distributed-mls

• distributed mls
• If you get a set of participants to agree on commit order then it is
  useful for shared cryptographic state over time
• we are reasoning about local state on these devices
• Disparate problem sets thinking about local state
• What can we do with MLS to get the properties we need for secure
  messaging

• Distirbuted MLS

  • no group consensus but

• DMLS

  • each participant operates their own MLS send gropu
  • localy control the evolution of the group

  • senders use their send gorup to encrypt app msgs

    • to recipients under control

  • [missed]

• senders introduce PCS updates relative to themselves

• other members incorporate senders' PCS updates
• sender group mode of operation of MLS gropus (1 per participant)
• mechanism to introduce PCS in own send group and incorporate across
  send groups with exporter PSK

Discussion

• [Richard] Good sign that we are seeing folks look at how to use
  MLS in different settings. Thinks it is not quite ready for adoption
  and needs more maturity.
• [Rich Salz] would like to explore groups with more than one
  person. group expected to stay together (liek all people in a
  vehicle). Cursious if you have an opinion on that and if this
  mechanism would work where individual clients may not all be
  avaialable at the same time, but they don't need eventual
  consistency among themselves sin the sender group
• [Britta] think that is an interesting composition with subtrees
  draft. The nice part about this is that it helps prevent protential
  conflict questions.
• [Richard] one of the interesting questions is hwo well do the
  security considerations we have for regular MLS and how to adapt
  them to this use case. Can we prove that these definitions are still
  satisfied.
• [Britta] the interesting thing si thtat the sender gets control
  about when updates are incorporated. In many ways it is very
  similar. On the flipside, no one of these groups gets held back from
  the others. So still to be fleshed out in more detail in the draft.
  The sender is the one most impacted so there is an incentive to
  apply commits and all that as quickly as possible.
• chairs: keep discussing on list and getting more feedback

Who: Raphael Robert
Time: 5min
Topic: Decentralized MLS

Github: https://github.com/phnx-im/dmls-spec
Datatracker: https://datatracker.ietf.org/doc/draft-kohbrok-mls-dmls/

• [Konrad kohbrok] different approach but same problem
• our approach is looking a bit more under the hood of mls
• in MLS there is a nice chain of epochs, delivery service makes sure
  there's one commit that ends one epoch and introduces next

• federated scenario with two servers and there is an interruption

  • group split so that one half keeps going ahead
  • what happens when we want the groups to consolidate and process
    all the messages sent on the other side of the netsplit
    • ould need to keep group state around. not great because that
      includes key material (not good for forward secrecy)

• academia paper Alwen et. al "Fork-Resilient Continusou Group Key
  Agreement" that gives better forward secrecy guarantees that allows
  us to keep key material around, but remove data needed to transition
  from epoch 1 to epoch 2

• PPRF to derive init_secrets

  • punctual prf to allow deriving multiple init secrets (multiple
    next epochs)
  • delete epoch secret after deriving needed secrets

• this would be an extension that modifies MLS, but the complexity
  comes from also merging commits from other fork and then trying to
  make both forks agree on group state again.

• Still at the point of having just written down the draft. Haven't
  really worked out a good way to merge the forks once you arrive
  there.
• wanted to give group a heads up that we are wokring on this, though
  it is a work in progress.

-knodel-e2ee-definition

Who: Gurshabad Grove
Time: 15min
Datatracker:
https://datatracker.ietf.org/doc/draft--knodel-e2ee-definition

• [Mallory] Not a new draft. The draft has been around for a couple
  years. The motivation was at the time very well supported by people
  that gave early reviews. The original motivation is that there
  doesn't seem to be an IETF wide definition of E2EE messaging.

• In general, we define E2EE a couple ways in the draft

  • Encryption
  • E2EE

• second way

  • list of requirements
    • what are authentication/integrity/confidentiality
      requirements
    • what are key features

• past discussion in the security area and on it's own mailing list

  • what do we include as absolutely core functionailites
    • e.g. maybe deniability doesn' tneed to be a core

• We also go through critical challenges/gaps that we know are issues
  in E2EE messaging where it will continually fall short

  • e.g. metadata

• we can pick up where list discussions left off

  • is key transparency or other state of the art techniques meeting
    our definition
  • should we relax definition to make sure they meet it?
  • Think suggestions on list are great and we should do them

• Want people to talk on mic

• Why come to MLS since draft has been around for a while?

  • if we continue in general security area
  • probably best fits here even though all the presentations today
    were very protocol specific
  • the gsma spec for RCS that folks have mentioned have referenced
    a pre-print of this draft, so it would be useful to have a
    consensus on a solid version of this draft

• reviews and discussion have been great

• chairs: show of hands on who has read the draft: [13 read, 3 no].
  Hasn't been much discussion on the list. Want to see more discussion
  on the list before adoption call.

Discussion

• [David Schinazi] very confused on why this is in MLS. Doesn't
  think this is in charter. But like TLS also has E2EE. History of
  this draft is complicated. Has been discussed in IAB and SAAG, but
  this seems very odd. This might not be the right place.
• [Felix Linker] I've read the draft and similar to David, what is
  the overall intent. What problem is the draft trying to solve?
• [Mallory] We talked to Paul (AD) about where this should go. I was
  suprised about him saying we should go to MLS. We talked to Sean +
  Nick about if it was in charter. They said it fits. Appreciate it
  doesn't fit well anywhere. Motivation, folks want to extend
  definition of what would be acceptable as E2EE that goes beyond what
  we accept as E2EE. Like proliferating metadata to be able to track
  messages: you aren't looking at messages but if you are looking at
  where messages are going that could be useful information and that
  goes counter to the problems we are trying to solve with E2EE. There
  persists this need to define what is in scope for an aplication to
  ensure E2EE is in place as a system. Elaborating those requirements
  is useful so that other requirements will be specified elsewhere.
• [Felix] a couple of systems may go in non-E2EE ways. I wonder
  whether a draft defining E2EE would help solve that. I think those
  implementers will just shrug and still say they want to track
  metadata
• [Mallory] not just people that are wanting to weaken E2EE. There
  are platforms themselves where there is temptation now with new
  features like AI. May not always be an external pressure, but also
  internal pressure to access this data. Think it is feasible to
  define what are best practices.
• Chairs: charter is focused on extensions for mls protocol. we
  invited Mallory to see if there is interest in adopting this or
  modifying charter
• [Britta] one issue we saw when this first came out when people
  wanted their own things to be defined as E2EE. What is the goal we
  are really trying to do here? It seems really vague in some ways.
  The definitions seem to be the same as what you would find in most
  blog posts today. Debate may rise again and not sure that is right
  for this WG. Maybe we should focus on MLS end to end encryption so
  we make progress and don't engage with all people with opinions on
  e2ee.
• [Richard] think the document would be more useful here if it was
  less normative. Potentially, there are ambiguities of e2ee in terms
  of various properties you might achieve. Maybe enumerating those
  different properties as a design guides. All of these topics appear
  in different working groups across IETF (TLS, PKI, onion routing,
  etc.). I think it may be useful to phrase this in a more general
  context and how we think about security in the IETF.
• [Rohan] I think having a referancable definition. I think it is
  topical. Don't think MLS is the right way to do this. Systems: MIMI
  WG? prob not. Don't think we should do it here. But totally ok with
  cross posts/reviews.
• [Mallory] happy to keep talking on list and we can go to paul to
  talk again
• chairs: there is a presentation in pearg on mls