[km-fs-pcs] Re: DRAFT BOF Request

[Carlos Aguilar Melchor <[e-mail]>]

I would vote against it. I don't think there is consensus on what current
(or future) good property is the main reason for the group to exist. There
are many reasons to want MLS channels, not one:
  * membership integrity
  * PCS
  * Async handshakes and in general async nature of everything
  * log scaling
  * native agility
So explicitly putting one in the title will reduce focus unnecessarily.

BTW I would prefer MLS Channels to MLS Channel...

Carlos

On Thu, May 21, 2026 at 8:37 PM Russ Housley <[e-mail]> wrote:

> I got a comment off list.  The suggestion was for a more descriptive name,
> such as "Asynchronous Channel", "Flexible Transport Security", or similar.
> Thoughts?
>
> Russ
>
> > Name:  MLS Channel (mlschannel)
> >
> > Description
> >
> > Define a two-party protocol that uses MLS for the key management.  Once
> the key is established, the TLS Record protocol seems to meet the needs for
> protected traffic, so it will be used unless some unexpected shortcoming is
> discovered.
> >
> > MLS key management provides asynchronous key updates, forward secrecy
> (FS), and post-compromise security (PCS).  In addition, MLS supports
> asynchronous communication and both traditional cryptography and
> Post-Quantum Cryptography (PQC).  Further, the formal analysis tha was
> conducted on the MLS provides confidence in the design.
> >
> > Required Details
> >
> >   Status: WG forming
> >   Responsible AD: Deb Cooley
> >   BOF proponents:
> >
> > Russ Housley <[e-mail]>
> > Sean Turner <[e-mail]>
> > John Mattsson <[e-mail]>
> > Raphael Robert <[e-mail]>
> > Konrad Kohbrok <[e-mail]>
> > Xisen Tian <[e-mail]>
> >
> >   Number of people expected to attend: 150
> >   Length of session (1 or usually 2 hours): 1 hour
> >   Conflicts (whole Areas and/or WGs)
> >   Chair Conflicts: lamps, sidrops, stir, rswg
> >   Technology Overlap: mls, ipsecme, tls, quic
> >   Key Participant Conflict: <same as BOF proponents above>
> >
> > Information for IAB/IESG
> >
> > To allow evaluation of your proposal, please include the following items:
> >
> >   Any protocols or practices that already exist in this space:
> >
> > There are suggestions for use of MLS key management with IPsec for
> multicast traffic (draft-kohbrok-ipsecme-mls-gike) and the use of MLS key
> management with QUIC (draft-tian-quic-quicmls).  This work has a home in
> the IPSECME and QUIC working groups, respectively.  However, the use of MLS
> key management with the TLS Record protocol does not fit in the TLS working
> group because it requires the replacement of the entire handshake.  This
> BOF is to find a home for this security protocol work.
> >
> >   Which (if any) modifications to existing protocols or practices are
> required:
> >
> > No.
> >
> >   Which (if any) entirely new protocols or practices are required:
> >
> > Yes.  A new protocol that runs on new port numbers is envisioned.
> >
> >   Open source projects (if any) implementing this work:
> >
> > One proof-of-concept project so far:
> https://github.com/phnx-im/mls-tls-protocol
> >
> > Agenda
> >
> > 1. What has happened since the SECDISPATCH presentation at IETF 125.
> > 2. Use Cases
> > 3. Draft charter
> >
> > Links to the mailing list, draft charter if any (for WG-forming BoF),
> relevant Internet-Drafts, etc.
> >
> >   Mailing List: https://www.ietf.org/mailman/listinfo/km-fs-pcs
> >   Draft charter: TBD
> >   Relevant Internet-Drafts:
> >
> > https://datatracker.ietf.org/doc/draft-kohbrok-mls-tls/
> > https://datatracker.ietf.org/doc/draft-kohbrok-mls-two-party-profile/
> > https://datatracker.ietf.org/doc/draft-housley-tls-using-mls-handshake/
> > https://datatracker.ietf.org/doc/draft-tian-quic-quicmls/
> > https://datatracker.ietf.org/doc/draft-kohbrok-ipsecme-mls-gike/
> > https://datatracker.ietf.org/doc/draft-liu-agent-protocol-over-moq/
>
> _______________________________________________
> km-fs-pcs mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>