]> Early Attestation is Broken TU Dresden
muhammad_usama.sardar@tu-dresden.de
Security Secure Evidence and Attestation Transport Sheffer et al. published on 9th January, 2025 and despite being wildly out of scope of SEAT charter, the draft made its place -- getting two-thirds of meeting time -- in the agenda for upcoming SEAT interim meeting within hours of publishing. In comparison, our request to present fully within the charter was refused. In this document, we disprove the claim made in for backward compatibility with standard TLS . We argue that is a much more reaonsable way of achieving the goal within the scope of SEAT charter. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Evidence and Attestation Transport Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction We argue that:
  • is out of scope of SEAT WG charter.
  • Several claims in are broken. Specifically, we prove that proposed key schedule is inconsistent with .
  • breaks most -- if not all -- proofs done to date for TLS 1.3.
Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Out of Scope has:
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.
Contrary to the crystal clear statement of scope:
  • adds a new protocol message named "Attestation".
  • modifies the key schedule.
Both are subtle and error-prone. Such intesive changes 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. We recommend the authors of to submit the draft to TLS WG, where such changes are in scope.
Comparison with our draft In comparison, makes no changes to TLS and is fully in scope of SEAT charter.
Broken Claims Too many claims in are broken. We present one example which invalidates most of other claims. The key schedule proposed in is not consistent with . Using notations from : whereas this draft proposes:
Proof Using definition of salt1 : Therefore, it comes that: Hence, the key schedule in is inconsistent with .
Comparison with our draft In comparison, uses standard TLS key schedule without any changes.
Breaking Formal Proofs Because of above key schedule change, the draft breaks most -- if not all -- proofs done to date for TLS 1.3.
Comparison with our draft In comparison, we are making a careful effort to preserve security properties for our draft .
Security Considerations This draft helps make this world more secure by refuting the security claims in and by pushing against disruption of FATT process of TLS WG. Security is dependent on weakest link and we believe is the weakest link in the security of TLS. Hence, we view post-handshake attestation as the most appropriate option.
IANA Considerations This document has no IANA actions.
References Normative References The Transport Layer Security (TLS) Protocol Version 1.3 Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Intuit Arm Limited Arm Limited Linaro Nokia The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using remote attestation which is a process by which an entity produces Evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enable the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation Evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and to use them mutually. Remote Attestation with Exported Authenticators Linaro TU Dresden Nokia Intuit University of Applied Sciences Bonn-Rhein-Sieg Arm Limited This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in [RFC9261]. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. Secure Evidence and Attestation Transport (SEAT): Charter for Working Group Perspicuity of Attestation Mechanisms in Confidential Computing: Validation of TLS 1.3 Key Schedule
Acknowledgments We thank the authors of for putting together something, which is already long overdue. Since the proof in is based on the working done in , we thank all those acknowledged there: namely Arto Niemi, Hannes Tschofenig, Thomas Fossati, Eric Rescorla, and Ionut Mihalcea