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/RFC9266To 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.
Indeed, this is one of the foundational principles of our design in draft-fossati-seat-expat. Thanks for the work.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 :)
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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
