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

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 <housley@vigilsec.com>
> Sean Turner <sean@sn3rd.com>
> John Mattsson <john.mattsson@ericsson.com>
> Raphael Robert <ietf@raphaelrobert.com>
> Konrad Kohbrok <konrad.kohbrok@datashrine.de>
> Xisen Tian <xisen.tian.mil@us.navy.mil>
> 
>   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/