Skip to main content

Minutes IETF113: mls
minutes-113-mls-00

Meeting Minutes Messaging Layer Security (mls) WG
Date and time 2022-03-23 12:00
Title Minutes IETF113: mls
State Active
Other versions plain text
Last updated 2022-04-20

minutes-113-mls-00
# IETF 113 MLS WG session

## Agenda
### Administrivia

- Virtual Meeting Tips: QR code reminder; use queue tool if physically in the
room - Note Well - Note Taker - Robin Wilton - Jabber Scribe - Status
    - Timeline has been structured to ensure that the protocol and arhcitecture
    docs have to make parallel progress towards WGLC.

### MLS Protocol - Richard Barnes

I-D: https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/
- Draft 13 update:
    - Editorial work to re-order many sections, but no technical changes (just
    improved flow); - Streamlined syntax of vectors, using same idea as CTLS
    and QUIC - Split leafnodes from keypackages; keypackages is now used only
    to pre-publish information about an entity. Also allows key separation to
    be slightly improved. - Algorithm for updating the tree has been updated to
    remove "redundant" nodes, where redundancy = having only one child at
    multiple subordinate layers. - "Parent" hashes in the hierarchy now bind
    more data about siblings and children of siblings - but there are some
    subtleties to cater for at the "right hand edge" of the tree (see slides
    and draft). Performance his is not devastating for most use cases,
    according to simulation.
- Draft 14 update:

Open Issues/Pull Requests

   - Issues
        - 619; annotation and clean-up. ACTION: Please merge for AASVG
        - 618: ACTION: merge
        - 617: some ambiguity about deniability in the spec; language has been
        drafted to clarify who are valid signers of a message. - 605:
           - Add a MIME_type object to allow applications to express MIME type
           of application_data is wished. Richard Barnes' proposal is to close
           this on grounds that it is premature. - Rohan Mahy: this is basic
           protocol hygiene, not premature, and would bring MLS into line with
           other protocols at the cost of a single byte. - Richard: this is
           analogous to ALPN as an addition to TLS. - EKR: Interesting analogy,
           but MLS is designed to be embedded in other protocols, so this
           function could be left to the other protocol. - Rohan: Sending this
           data outside MLS could be seen as informational leakage... - EKR:
           distinguished between defining the message type (inside MLS) and
           defining the format for expressing the message type (and how to
           inspect/treat the contents) outside MLS. - DKG: ... and that won't
           always be data about MIME types. - Ben Kaduk: It is good to be able
           to uniquely determine the structure/format of the message contents,
           but whether that information needs to be inside our framing or the
           outermost layer of framing for what we convey seems subject to
           debate. - Rohan: If your messaging group/app only ever sends one
           type of application data, you can safely igore this parameter or
           leave it blank. We're only talking about a cost of one byte, and it
           increases agility among data types supported. - Jonathan Hoyland:
           How is this data accessed by the application, and how would
           inconsistencies/mismatches be handled? - Cullen Jennings:
           [paraphrased!] It's easier to add a field to an existing wrapper
           than to define new wrappers for each case. - EKR: this is an
           instance of a common problem, namely how to demux (de-multiplex,
           segregate, distinguish...) different types of traffic in an opaque
           transport layer. - Hoyland: If the information isn't used by the MLS
           layer it makes no sense to me to put it in the MLS layer. - Kaduk:
           [Paraphrased] The question about where best to represent this
           parameter arises because here, we're talking about the structure of
           MLS, not the full protocols that embed MLS. - DKG: One solution
           would be to have clear documentation of how to integrate MLS into
           your protocol (+1 from Kaduk). - Rohan: [Paraphrased] The goal here
           would be to reduce the amount of parsing an application needs to do
           to determine content type (i.e. parse a defined parameter, rather
           than inspect the contents and infer type). - Kaduk: Could clearly
           document what the app is expected to do; defining it here risks
           precluding better subsequent ideas.

Chair: calls for a show of hands. The question will be specific to merging
issue #605, raise hand for merge, do not raise to not merge. Show of hands was
50:50, issue is therefore deferred to the list.

GitHub: https://github.com/mlswg/mls-protocol

Security Research

### Architecture - Benjamin Beurdouche

I-D: https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/

GitHub: https://github.com/mlswg/mls-architecture

Open Issues/Pull Requests

- #75 Track Expected Types of Deployment
    - Ticket in Github lists a starter set
    - ACTION: closed
- #71 Current text does not define sufficiently strongly what constitutes
"being a member of the group"; as a result it does not reflect the properties
of the underlying key exchange.
    -  Barnes; membership != liveness or consent
    - Wilton; sought confirmation that any ambiguity is in the text, and not
    reflected in loss of security/transparency in the key exchange/protocol.
    Beurdouche confirmed.

### Federation - Raphael Robert

GitHub: https://github.com/mlswg/mls-federation

Resurrection plan, now that the protocol itsenf is close to WGLC, there are
several implementations and a  deployment. (Barnes: Two! RingCentral uses it
too!)

Chair: Draft already adopted. Editors are free to work on it with no further
re-opening process.