A quick follow-up with pointers:
* /Pre-handshake attestation/ protocols (including the widely used Intel's RA-TLS) do not provide /per-session Evidence freshness/. This is formally analyzed in [1], and was presented in detail at UFMRG in IETF 120 [2]. Examples include live firmware updates and Linux Integrity Measurement Architecture (IMA). * We have fully explored the design space. Hence, we believe having it as a milestone is not required. A comparison of /pre-/intra-/post-handshake/ /attestation/ approaches was presented at UFMRG [3] and RATS [4] in IETF 121, as well as RATS interim [8]. * The rationale why missing /PKI identity/ results in /diversion attacks/ (aka identity crisis) was presented at TLS in IETF 122 [5], and at RATS interim [6]. I will also present this in detail in UFMRG on Thursday. * We have presented potential solutions for /intra-handshake attestation/ at TLS WG in IETF 122 [5] and also implemented one of them (channel binder [7]), but that needs changes as deep as TLS key schedule to define new exporters in TLS. The need for channel binders is argued in [7]. I believe making changes in the TLS key schedule cannot be done outside of TLS WG. Hence, we keep the charter limited to /post-handshake attestation/. * Binding of Evidence to TLS session is very important otherwise /relay attacks/ are possible. This was presented at RATS interim [6]. * Regarding the proposed solution in /post-handshake attestation/, I think we don't need the Exported Authenticators (EA) to be linked to each other. What was the state of server yesterday (EA1) should be irrelevant to RP when it checks the state of server today (EA2). I believe it should only be ensured that exported authenticators are bound to the TLS session, and this is done already by the Authenticator keys of RFC9261. This is something we are exploring. * The WG will give due consideration to privacy in the design. * Confidential Computing Consortium (CCC) Attestation Special Interest Group (SIG) [9] will be added to liaison. The formal analysis is already an adopted project in the SIG.If the above does not capture your /technical/ questions/concerns, please clarify it. Please avoid raising /editorial/ concerns in this thread. We will update the charter based on the discussions and get back to you very soon.
We will continue discussion of the relevant parts in the relevant WGs/RG: thanks to secretariat for perfectly time-positioning the BoF and thanks to respective chairs for accommodating our proposals:
* TLS WG: Wednesday 16 hrs * UFMRG: Thursday 14:30 hrs * RATS WG: Friday 14:30 hrsAs an individual (i.e., not as proponent): I completely agree that RATS is unfortunately vague. I keep pushing for more clarity and precision in the RATS documents and in particular security considerations, but there is unfortunately only little that an individual can do in this consensus-driven process :(
Thank you, Usama [1] https://ieeexplore.ieee.org/document/10752524[2] https://datatracker.ietf.org/meeting/120/materials/slides-120-ufmrg-towards-formal-analysis-of-attested-tls
[3] https://datatracker.ietf.org/meeting/121/materials/slides-121-ufmrg-specifications-of-attested-tls-00
[4] https://datatracker.ietf.org/meeting/121/materials/slides-121-rats-security-considerations-of-attested-tls-00
[5] https://datatracker.ietf.org/meeting/122/materials/slides-122-tls-identity-crisis-00
[6] https://datatracker.ietf.org/meeting/interim-2025-rats-01/materials/slides-interim-2025-rats-01-sessa-identity-crisis-in-attested-tls-for-confidential-computing-01.pdf
[7] https://www.usenix.org/conference/atc25/presentation/weinhold[8] https://datatracker.ietf.org/meeting/interim-2025-rats-02/materials/slides-interim-2025-rats-02-sessa-attested-tls-00.pdf
[9] https://github.com/CCC-Attestation[10] https://datatracker.ietf.org/meeting/123/materials/slides-123-expat-design-space-of-attested-tls-01.pdf
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
