[MLS] Re: Call for Adoption: draft-kohbrok-mls-two-party-profile-00 (closes 28 July 2026)

[Sean Turner <[e-mail]>]

chair hat on (IANAL either and I really do not want to start a thread about IPR, but I thought I’d chime on a couple of points)

The IETF does contemplate WG’s developing documents with IPR; see BCP 79 / RFC 8179 [1]. Basically, WG’s can adopt and work on documents with IPR - I mean it’s better if there is none, but if there is some then the WG needs to consider the disclosure(s).

I should also add that 1) I made somebody aware of the 3rd Party IPR disclosure and they are pretty good about updating disclosures, 2)  everybody needs "to take into account their own views of the validity, enforceability, or applicability of IPR in their evaluation of alternative technologies” [1].

Nick and I will huddle about this adoption soon. 

spt

[1] https://datatracker.ietf.org/doc/rfc8179/

> On Aug 4, 2026, at 17:41, Brendan McMillion <[e-mail]> wrote:
> 
> I'm not a lawyer either, but the patent's plain text covers exactly what you describe in your document. Which creates two problems:
> 
> - Cisco's terms for waiving patent protection on quicmls boil down to "I agree not to assert patent claims related to this one patent against you, as long as you agree not to assert any patent claims against me." These terms are generous, but I think they would still preclude most use of the standard.
> - Cisco has only waived patent protection against quicmls, not this, and it's unclear if they'd be willing to.
> 
> I unfortunately wouldn't have supported adoption if I had known this.
> 
> On Mon, Aug 3, 2026 at 9:38 PM Konrad Kohbrok <[e-mail] <mailto:[e-mail]>> wrote:
>> The current document is just vanilla MLS (plus a marker component) in a two party setting with a basic state machine. I’m not a lawyer, so I can’t say to which degree that patent applies.
>> 
>> As for our use cases: We would like to be able to connect two parties using MLS without the need for a coordinating third party in the middle. Based on that session, we want to derive key material for use in applications and other, higher-level protocols. The draft is currently focused on synchronous use cases with reliable delivery, but the idea is to expand in the future.
>> 
>> Konrad
>> 
>> > On 31. Jul 2026, at 18:28, Brendan McMillion <[e-mail] <mailto:[e-mail]>> wrote:
>> > 
>> > Hi Konrad
>> > 
>> > Can you say more about whether/why you want to continue this work, given that it seems to be wholly subsumed by the Cisco patent?
>> > 
>> > On Thu, Jul 30, 2026 at 7:13 AM Konrad Kohbrok <[e-mail] <mailto:[e-mail]>> wrote:
>> > Thanks for all of the feedback! I just published a new version of the draft that addresses at least some of the points.
>> > 
>> > - The draft introduces a component now, which allows us to properly identify the individual messages via SafeAAD. It also allows clients to negotiate/signal the use of the profile.
>> > - I introduced a proper state-machine. I’m sure I overlooked something, but it’s certainly a start. Maybe I’ll have Claude do a TLA+ model to make sure I didn’t miss any edge cases.
>> > 
>> > Originally, the draft was only meant to specify a profile, i.e. a way for two MLS clients to run a two-party group and have a deterministic way to agree on commit ordering. So the lack of an actual protocol was rather more of a feature than a bug. But I think it doesn’t work without some more explicit signalling, which is why we now have a component.
>> > 
>> > Cheers,
>> > Konrad
>> > 
>> > > On 29. Jul 2026, at 22:51, Richard Barnes <[e-mail] <mailto:[e-mail]>> wrote:
>> > > 
>> > > Out of an abundance of caution, I went ahead and filed a third-party IPR disclosure on draft-kohbrok-mls-two-party-profile.  It should be posted in a day or two.
>> > > 
>> > > While I'm here though, I have another complaint: The draft as it stands is basically content-free -- it doesn't specify anywhere near enough detail to describe a concrete protocol.  The structs are just renaming, and the behavior descriptions are high-level -- including around the conflict- resolution protocol, the most sensitive part of the whole thing.  I would expect some notion of the endpoints' state machines, specific sequences of allowable messages, etc.
>> > > 
>> > > The current doc is bare-bones even for a draft-00.  I'm not sure what those supporting this draft are supporting, other than a general vibe that we should do something two-party shaped.  Clearly adoption decisions need to be based on actual protocol proposals, not vibes.
>> > > 
>> > > So even aside from the requirements question, we need to have an actual protocol to consider.
>> > > 
>> > > --Richard
>> > > 
>> > > On Wed, Jul 29, 2026 at 10:33 AM Richard Barnes <[e-mail] <mailto:[e-mail]>> wrote:
>> > > With regard to 1: It's not confusion that I'm worried about.  The question is whether a new thing is needed given that the two-groups approach exists.  It would be helpful if you could comment on what requirements you perceive that drive the need for something different from the two-groups approach.
>> > > 
>> > > With regard to 2: Thanks for the reminder re patents.  For folks' awareness: Cisco disclosed IPR on draft-tian-quic-quicmls [1], which I expect also applies to other two-party MLS drafts.  The patent application referenced in their disclosure has since been issued as US12567972B2 [2].  In their disclosure draft-tian-quic-quicmls, Cisco declares their usual RAND terms.
>> > > 
>> > > None of which changes the requirements question of why the group should adopt the approach in this document, vs. something like SlimMLS.
>> > > 
>> > > --Richard
>> > > 
>> > > [1] https://datatracker.ietf.org/ipr/7137/
>> > > [2] https://patents.google.com/patent/US12567972B2/
>> > > 
>> > > 
>> > > On Wed, Jul 29, 2026 at 8:54 AM Raphael Robert <[e-mail] <mailto:[e-mail]>> wrote:
>> > > As Britta just noted, I don’t see a risk of confusion with 1.
>> > > 
>> > > As for 2.: I agree that having better efficiency is a desirable goal. The idea behind the draft is that it can be combined with other MLS extensions that help with efficiency. We presented SlimMLS at IETF126 that can help in that regard. We didn’t get to present Opportunistic Channels, that can also help with efficiency in the 2-party context. Combined, these two extensions should achieve similar efficiency to the (patent encumbered) Cisco + Cryspen approach. So, ideally, we get to reuse MLS code *and* also get better efficiency. 
>> > > That being said, we haven’t shown specifically how the two extensions help with efficiency in the two party case. I don’t think that would be required before adoption, but it’s certainly an interesting exercise and we’ll follow up on that.
>> > > 
>> > > Raphael
>> > > 
>> > >> On 28. Jul 2026, at 20:38, Richard Barnes <[e-mail] <mailto:[e-mail]>> wrote:
>> > >> 
>> > >> I agree with Rohan that more clarity on requirements is needed.  There are at least two other approaches that are adjacent:
>> > >> 
>> > >> 1. The “two groups” approach in draft-xue-mls-decentralized gets more PCS faster in situations where the cost is bearable. 
>> > >> 
>> > >> 2. In situations where you really want to be minimal, a substantial amount of the protocol can be stripped out.  Cryspen and Cisco did some initial experimentation and validation on this, which I don’t think was ever published.
>> > >> 
>> > >> In a way, the approach in the doc is the worst point on the spectrum between these options.  You get neither asynchrony nor minimality.  The only thing you save is reusing MLS code.
>> > >> 
>> > >> Maybe that’s the right value to conserve!  But it’s hard to tell without some clearer requirements. 
>> > >> 
>> > >> —Richard
>> > >> 
>> > >> On Thu, Jul 16, 2026 at 04:14 Rohan Mahy <[e-mail] <mailto:[e-mail]>> wrote:
>> > >> Hi,
>> > >> I think this adoption call is premature. What are the requirements and from where? If they are coming from another WG or BoF, is it in their (proposed) charter?
>> > >> 
>> > >> How is the feature discovered or negotiated? Which of the operational considerations in Section 7 of RFC9750 does this impact? 
>> > >> 
>> > >> The slides from IETF125 say "Vanilla MLS (for now)". Is this draft supposed to be a draft only for 2-party with vanilla MLS or is it going to morph into a collection of proposed knobs to make MLS more efficient in the 2-party case? It is not even clear what we are being asked to adopt. Why the rush? 
>> > >> 
>> > >> "If the initiator receives a ConnectionUpdate while waiting for an EpochKeyUpdate, it MUST ignore the ConnectionUpdate and resume waiting" - How long before it gives up?
>> > >> 
>> > >> Thanks,
>> > >> -rohan
>> > >> 
>> > >> On Tue, Jul 14, 2026 at 8:28 PM Nick Sullivan <[e-mail] <mailto:[e-mail]>> wrote:
>> > >> Hi all,
>> > >> 
>> > >> This starts a two week Call for Adoption for "A two-party profile for MLS", draft-kohbrok-mls-two-party-profile-00, by Konrad Kohbrok and Raphael Robert. It closes on Tuesday 28 July 2026.
>> > >> 
>> > >> https://datatracker.ietf.org/doc/draft-kohbrok-mls-two-party-profile/
>> > >> 
>> > >> The draft uses an MLS group of two as a continuous key agreement protocol, in the synchronous case, with rules to keep the two parties from desynchronizing when both update at once. It is at -00 with TODOs in a few sections, which is fine. The question is whether the group wants to work on it, not whether it is finished.
>> > >> 
>> > >> Please reply to the list either way and say why, and let us know if you would review or implement. Silence is not support. The call runs across the Vienna week, so if you talk about it there, send your view to the list too.
>> > >> 
>> > >> Authors and contributors: please confirm the IPR disclosures required by BCP 78 and BCP 79 have been filed.
>> > >> 
>> > >> Best,
>> > >> Nick (for the chairs)
>> > >> _______________________________________________
>> > >> MLS mailing list -- [e-mail] <mailto:[e-mail]>
>> > >> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> > >> _______________________________________________
>> > >> MLS mailing list -- [e-mail] <mailto:[e-mail]>
>> > >> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> > >> _______________________________________________
>> > >> MLS mailing list -- [e-mail] <mailto:[e-mail]>
>> > >> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> > > 
>> > > _______________________________________________
>> > > MLS mailing list -- [e-mail] <mailto:[e-mail]>
>> > > To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> > 
>> > _______________________________________________
>> > MLS mailing list -- [e-mail] <mailto:[e-mail]>
>> > To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> > _______________________________________________
>> > MLS mailing list -- [e-mail] <mailto:[e-mail]>
>> > To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> 
> _______________________________________________
> MLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]