[TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"

[Muhammad Usama Sardar <[e-mail]>]

Hi,

Sincere apologies, as I was thinking a bit higher in the layers, like 
close to transport and application layer. Thanks Nico also for 
clarifying that your intention was not nested TLS, unlike my assumption. 
Does the following revised framing seem correct?

    Link layer: use EAP-TLS with pure ML-KEM

    Transport layer: use standard TLS 1.3 with ML-KEM + ECDHE

    Application layer: use post-handshake attestation (see for example
    [2]) via standard TLS exporters

    Channel binding between transport and application layer: RFC9261/RFC9266

To me, that seems like a robust design which the adversaries will have a 
tough time to break. The response to LS may suggest this design, and the 
introduction of the draft may frame it similarly. I can't say for others 
but this will resolve some of my concerns.


On 08.04.26 02:50, Nico Williams wrote:
>>> The application (e.g., a browser), just does TLS as usual with
>>> RECOMMENDED=Y algorithms and gets hybrid PQ.
>> This is what confused me and that's why I asked [0]. There is nothing in
>> hybrid with RECOMMENDED = Y. Maybe you mean once
>> draft-usama-tls-ecdhe-mlkem-update is published?
> Well, right, that has to get fixed too.
Thanks for the support.
>>> ASIDE: Long ago I had wanted to be able to make use of network layer
>>>          cryptography at the application layer, thus I wrote RFC 5056 (On
>>>          Channel Bindings) to expand on RFC 2743's nebulous concept of
>>>          channel binding.
>> After reading this, I realized that Nicolas == Nico 😇 I happen to be your
>> fan for this work 😉 because I have been researching channel bindings
>> (RFC5056 and RFC9266) recently.
> Hope it helps :)
Indeed, this is one of the foundational principles of our design in 
draft-fossati-seat-expat. Thanks for the work.
>>> No, compromise of one layer will not compromise the other.  The two
>>> layers are independent.
>> I meant if server is compromised, then all keys of the server are
>> compromised, except if keys are stored in different storage mechanisms. As I
>> mentioned, our design of attested TLS provides an independent root of trust.
>> Maybe we can suggest IEEE 802.11 to do this, so that if their ML-KEM thingy
>> breaks, attestation can protect them.
> How does attestation protect against catastrophic cryptanalysis?

I am surely not claiming attestation is bullet-proof but it complements 
as a fully independent root of trust. The argument here is pretty 
similar to hybrid: as long as one of the two roots of trust is not 
broken, it is secure. See [2] for background and [3] for design details 
where TLS remains completely unmodified.Unsurprisingly, there are 
certain practical assumptions though. An upcoming paper formalizes those 
assumptions precisely.

Kind regards,

-Usama

[0] https://mailarchive.ietf.org/arch/msg/tls/zKFOBbA65wkZ7k2iQ6o_xmXarWk/

[1] https://mailarchive.ietf.org/arch/msg/tls/1Cj_Jb7eh9LVyIh42jyWcQD3IiU/

[2] 
https://www.researchgate.net/publication/396199290_Perspicuity_of_Attestation_Mechanisms_in_Confidential_Computing_Technical_Concepts

[3] 
https://datatracker.ietf.org/meeting/125/materials/slides-125-seat-seat-expat-00