[km-fs-pcs] Re: draft-kohbrok-mls-tls-00 and draft-kohbrok-mls-two-party-profile-00 – Minor clarification questions

[Konrad Kohbrok <[e-mail]>]

Hi Gaëtan,

Thanks for the feedback on both MLS-TLS and the MLS two party profile! These are all valid points that we’ll need to address in the drafts.

The issues with MLS-TLS all seem pretty straight-forward to me. Regarding the points for two party profile: I think we’re at a point where it may make sense to turn this into an MLS component rather than just a usage profile. I have a few minutes to talk about the draft in the MLS WG meeting at IETF 126 and will ask for a discussion around that subject.

Cheers,
Konrad

> On 9. Jul 2026, at 18:26, Gaëtan Wattiau <gaetan.wattiau=[e-mail]> wrote:
> 
> Hello,
> 
> While implementng both drafts I collected a few small clarification points. Grouped them by draft:
> 
> draft-kohbrok-mls-tls-00
> 
>     • §3 / §6 record-layer AEAD and hash. The draft specifies the MLS-Exporter calls but never states which AEAD and hash the TLS record layer should use. Since §3 says MLS "replaces the TLS 1.3 handshake," there's no negotiated TLS cipher suite to inherit them from. Is the intent that the record layer simply adopts the AEAD and KDF hash of the MLS cipher suite? A sentence making that explicit would remove the ambiguity.
> 
>     • §6 MLS-Exporter context. The two exporter calls pass an empty context (MLS-Exporter("MLS-TLS s ap traffic", [], Length)​ and the client equivalent). Is the empty context intentional? Given §9's planned cross-protocol-attack mitigation, I'd have expected some context binding here, so it would help to confirm the empty value is deliberate rather than a placeholder.
> 
>     • §7 hash for the traffic-key derivation. §7 derives the record-protection keys "as described in Section 7.3 of [RFC8446]," which is an HKDF-Expand-Label step. Which hash function parameterizes that HKDF here? (Presumably the MLS cipher suite's hash, per point 1, but it isn't stated.)
> 
>     • Specify that the ratchet tree extension must be used. The ServerHello must contain the full ratchet tree, but this is an extension. The draft should specify that the extension is required.
> 
>     • Do you verify the Epoch Number in the EpochKeyUpdate message? This is not specified. I guess it's mainly there as a sanity check?
> 
> draft-kohbrok-mls-two-party-profile-00
> 
>     • §4 ConnectionUpdate commit contents. The draft says a ConnectionUpdate carries "an MLS commit with UpdatePath," but doesn't say whether any additional AAAD. should be bound into the commit (e.g. to tie it to the MLS-TLS context). Is any AAD expected?
> 
>     • §5 / §6 error handling. There's currently no error model: no distinction between recoverable and unrecoverable errors, and no defined behaviour when a party hits one (e.g. an invalid commit, an epoch mismatch, or a failed resumption). Some guidance on what a party should do on error, and whether/how it's signalled to the peer.
> 
> Thanks,
> 
> Gaëtan
> 
> 
> _______________________________________________
> km-fs-pcs mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]