I am concerned mainly for three reasons:
1. This not only breaks my proofs but also most likely other existing proofs for TLS as well, and should not bypass FATT process at TLS WG by any means. SEAT has just a mention of formal analysis in its charter and no real process. SEAT also does not have the blessing of many TLS experts. It makes pursuing such a work in SEAT almost surely to lead to failure. 2. As author of draft-fossati-seat-expat: Given that we have this post-handshake attestation solution without changes to TLS, where no property is so far breaking in our formal model, and no attack is otherwise currently known, I don't see the need to go to the extent of changes draft-fossati-seat-early-attestation is suggesting within handshake in SEAT. Google, Microsoft and SCONE are using post-handshake attestation in real-world use cases. 3. This is a discussion for TLS WG once it is submitted in TLS WG but my initial thoughts are: Given that formal analysis has already revealed several attacks [1,2] on intra-handshake attestation, adding even more complexity with a blender of Extended Key Update and PAKE (both specs are unstable currently) is likely to lead to failure. I can't say for sure but this complexity has the potential of leading the formal methods tools to a state of crashing or giving no results. So in an overall attempt to add the second root of trust in TLS, we might very well end up breaking the existing one as well. Some other data points: * Ekr's assessment in [3] * Yaron's claims in [4] * Yaron's claims refuted in my detailed assessment [5] to no response from authors Opinions? -Usama -------- Forwarded Message --------Subject: [Seat] Re: New Version Notification for draft-fossati-seat-early-attestation-00.txt
Date: Fri, 9 Jan 2026 16:09:10 +0100 From: Muhammad Usama Sardar <[email protected]>To: Yaron Sheffer <[email protected]>, [email protected] <[email protected]>, Tirumaleswar Reddy.K <[email protected]>, Ionut Mihalcea <[email protected]>, Thomas Fossati <[email protected]>, Yogesh Deshpande <[email protected]>
Hi authors,Thanks for putting together something which can be discussed and analyzed more concretely.
However, the current version of the draft is clearly out of scope of SEAT charter:
* Sec. 4.1 adds a new protocol message * Sec. 5.6 modifies the key schedule Both of these contradict [0] (*emphasis* my own): * The attested (D)TLS protocol extension will not modify the (D)TLS protocol itself. It may define (D)TLS extensions to support its goals but will not modify,*add*, or remove any existing *protocol messages* or *modify the key schedule*.Do authors see a possibility to make intra-handshake attestation secure within the SEAT charter? On a related note, we (i.e., I, Viacheslav Dubeyko and Jean-Marie Jacquet) have been doing extensive formal analysis of the possible binding mechanisms in intra-handshake attestation and our finding is that it cannot be made secure within the SEAT charter. We will share details of our results so far by tomorrow.
-Usama [0] https://datatracker.ietf.org/wg/seat/about/[1] https://www.researchgate.net/publication/398839141_Identity_Crisis_in_Confidential_Computing_Formal_Analysis_of_Attested_TLS
[2] https://mailarchive.ietf.org/arch/msg/seat/x3eQxFjQFJLceae6l4_NgXnmsDY/ [3] https://mailarchive.ietf.org/arch/msg/seat/-7g2IlmzQVcVfJc2nXW1h6Zbae0/ [4] https://mailarchive.ietf.org/arch/msg/seat/i0lMvu6HIO3-2V6012Ix8NkifwI/ [5] https://mailarchive.ietf.org/arch/msg/seat/LcQrSGf1Enmk5JyWQVVthgfGQdg/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
