]> Extensions to TLS FATT Process TU Dresden
muhammad_usama.sardar@tu-dresden.de
Security Transport Layer Security This document applies only to non-trivial extensions of TLS, which require formal analysis. It proposes the authors provide a threat model and informal security goals in the Security Considerations section, as well as motivation and a protocol diagram in the draft. We also briefly present a few pain points of the team doing the formal analysis which -- we believe -- require refining the process:
  • Contacting FATT
  • Understanding the opposing goals
  • No response from some authors
  • Slots at meeting
  • Provide protection against FATT-bypass by other TLS-related WGs
  • Process not being followed
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 Transport Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction While the TLS FATT process marks a historic change in achieving high cryptographic assurances by tightly integrating formal methods in the working group (WG) process, the current FATT process has some practical limitations. Given a relatively smaller formal methods community, and a steep learning curve as well as very low consideration of usability in the existing formal analysis tools, this document proposes some solutions to make the FATT process sustainable. Specifically, the TLS FATT process does not outline the division of responsibility between the authors and the team doing the formal analysis (the latter is hereafter referred to as the "Verifier"). This document aims to propose some solutions without putting an extensive burden on either party. An argument is often presented by the authors that an Internet-Draft is written for the implementers. We make several counter-arguments here:
  • Researchers and protocol designers are also stakeholders of such specifications .
  • Even implementers may like to understand the security implications before blindly starting to implement it.
  • With the FATT process, this argument is clearly invalid. The Verifier may not be the same as the implementer.
This document outlines the corresponding changes in the way Internet-Drafts are typically written. For the Internet-Draft to be useful for the formal analysis, this document proposes that the draft should contain four main items, namely:
  • motivation,
  • a threat model,
  • informal security goals, and
  • a protocol diagram ().
Each one of these is summarized in . Future versions of this draft will include concrete examples. Responsibilities of the Verifier are summarized in .
Motivation A clear separation of responsibilities would help IRTF UFMRG to train the authors and verifiers separately to fulfill their own responsibilities. Moreover, we believe that the experiences can help improve the FATT process.
Scope The scope of this document is only non-trivial extensions of TLS, which require formal analysis.
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.
Protocol Diagram In the context of this document, a Protocol Diagram specifies the proposed cryptographically-relevant changes compared to the standard TLS protocol . This is conceptually similar to the Protocol Model in . However, while only recommends diagrams, we consider diagrams to be essential.
Verifier In this document, the Verifier refers to the person (team) doing the formal analysis.
Definition of Attack Any ambiguity originating from the threat model, informal security goals, and a Protocol Diagram is to be considered as an attack. The authors are, therefore, encouraged to be as precise as possible. The Verifier may propose text for consideration by authors/WG to disambiguate or propose a fix to the attack.
Pain Points of Verifier From the two extremes -- where Russ kindly provided all requested inputs and we were able to get it through (with a small change) without any formal analysis to where formal analysis revealed vulnerabilities and resulted in a separate WG to tackle this problem -- we summarize the pain points of the Verifier with the hope that we can refine the process. Note that we are not at all asserting that the authors have no pain points. They very likely have their own -- that is another indication that the process needs a refinement.
Provide Protection Against FATT-bypass by Other TLS-related WGs TLS-related WGs in particular those where the representation of TLS WG is a minority -- including the one (SEAT WG) that the author has defended himself as one of the six proponents -- MUST NOT be allowed to make changes to the TLS protocol beyond what is explicitly allowed in their charter. If rechartering of such WGs is absolutely unavoidable and includes non-trivial changes to the TLS protocol, it MUST only be done after agreement with the TLS WG. This will prevent the short-circuit path for FATT. If the WG does not have proper FATT-like process, TLS WG may request FATT review before WGLC. In short, our concern is: For example, makes key schedule level changes, breaks the SEAT WG charter and SEAT WG has no formal FATT-like process.
Process not being followed The process states:
When a document is adopted by the working group the chairs will make a determination whether the change proposed by the document requires review by the FATT to determine if formal protocol analysis is necessary for the change. For example a proposal that modifies the TLS key schedule or the authentication process or any other part of the cryptographic protocol that has been formally modeled and analyzed in the past would likely result in asking the FATT, whereas a change such as modifying the SSLKEYLOG format would not. The working group chairs will inform the working group of this decision.
However, such information has not been provided to the WG for at least the following 2 documents:
ML-KEM For the draft , the chairs acknowledge that the process was not followed:
Unfortunately, the chairs did not announce this decision on the list (this is something that should be corrected in the process).
However: The chairs further say :
The chairs made this decision because the mechanism in this draft fits into a well defined place in the TLS protocol and does not change the protocol itself.
We believe this argument does not stand, given the single data point that has gone through the FATT process -- . Both of the mentioned conditions apply equally to which indeed went through FATT process. The mechanism defined in "fits into a well defined place in the TLS protocol" and "did not change the protocol itself". So we request clarification of the matter in comparison to .
Key Update The process states:
The output of the FATT is posted to the working group by the FATT point person.
Based on authors' email, while it is great that FATT could find some threat, in our observation, the FATT process does not seem to be followed in spirit.
Contacting FATT The FATT process restricts the Verifier from contacting the FATT directly. We argue that the Verifier should be allowed to contact the FATT (at least the FATT person for a specific draft) because of the following reasons:
  • Formal methods community is small and within this small community, those with deep knowledge of TLS are quite limited.
  • The feedback we receive on the list is really limited.
  • Communication via chairs is a source of misunderstandings, as it has already happened with the chairs summarizing the intent of "Tamarin-like" to just "Tamarin".
Understanding the Opposing Goals The authors need to understand that the task of the Verifier is to find the subtle corner cases where the protocol may fail. This is naturally opposed to the goal of the authors -- that is, to convince the WG that the protocol is good enough to be adopted/published. In particular, some topics like remote attestation need more precise specifications because small changes or ambiguites may make a big difference.
No Response from Some Authors Some authors of adopted drafts do not respond for several months, despite repeated reminders .
Slots at Meeting So at least some time should be allocated in the meetings for discussion of formal analysis.
  • We requested a slot for 10 minutes (and 5 minutes if tight on schedule) for discussion of our questions about at IETF 124. It seemed that the slots were spread over the meeting time to show that there is no time left for our topic. In the end, the meeting ended one hour earlier where 10 minutes from that could have been utilized for discussion on formal analysis of . Given that the authors were informed about the issues, what the authors presented was not very helpful in terms of progressing the formal analysis work and proposing some solutions. Key schedule is a subtle topic and not something we can talk effectively on the mic without a proper diagram on display. It is unclear why formal analysis is such a low priority to the chairs.
  • If the authors are doing the formal analysis themselves, they should also present the current state of formal analysis for discussion. This will help the Verifier give any feedback and avoid any repititive effort.
Responsibilities of Authors This document proposes that the authors provide the following four items:
Motivation The motivation of the work (i.e., the proposed extension of TLS) needs to primarily come from the authors. The Verifier can ask questions to improve it, but he cannot just cook it up.
Threat Model A threat model outlines the assumptions and known weaknesses of the proposed protocol. The threat model could be the classical Dolev-Yao adversary. In addition, it could specify any keys (e.g., long-term keys or session keys) which may be compromised (i.e., available to the adversary).
Informal Security Goals Knowing what you want is the first step toward achieving it. Hence, informal security goals such as integrity, authentication, freshness, etc. should be outlined in the Internet-Draft. If the informal security goals are not spelled out in the Internet-Draft, it is safe to assume that the goals are still unclear to the authors.
Protocol Diagram A Protocol Diagram should clearly mention the initial knowledge of the protocol participants, e.g., which authentic public keys are known to the protocol participants at the start of the protocol. An example of a Protocol Diagram for is provided in Figure 5 in .
Document Structure While the needs may differ for some drafts, we propose the following baseline template, with an example of : TODO: Currently it is almost a copy of the guidance email to the authors. We will add details in next version.
Introduction
  • Problem statement: Say in general what the problem is.
  • For , we believe this should not include CATS. Anyone unfamiliar with CATS should be able to understand your problem.
Terminology
  • Define any terms not defined in RFC8446bis or point to other drafts from where the definition is used.
Motivation and design rationale
  • We really like how Russ motivates the problem statement in . Use it as a sample.
  • Here authors should address all the concerns from WG, including justification with compelling arguments and authentic references why authors think it should be done within TLS WG (and within handshake).
  • For , authors could put CATS here as a motivational use case.
Proposed solution (one or more sections)
  • Protocol design with Protocol Diagram: we work on the formal analysis of TLS 1.3 exclusively. Please contact someone else if your draft relates to older versions.
Security considerations
Threat model
Desired security goals As draft proceeds these desired security goals will become what the draft actually achieves.
Other security implications/considerations
Responsibilities of Verifier When the authors declare the version as ready for formal analysis, the Verifier takes the above inputs, performs the formal analysis, and brings the results back to the authors and the WG. Based on the analysis, the verifier may propose updates to the Security Considerations section or other sections of the Internet-Draft.
Security Considerations The whole document is about improving security considerations.
IANA Considerations This document has no IANA actions.
References Normative References TLS FATT Process IETF TLS WG 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 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. Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro 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 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 enables 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 mutually. Writing Protocol Models Internet Architecture Board The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system. This memo provides information for the Internet community. Identity Crisis in Confidential Computing: Formal Analysis of Attested TLS Guidelines for Writing Cryptography Specifications Cryptography Consulting LLC Cloudflare, Inc. This document provides guidelines and best practices for writing technical specifications for cryptography protocols and primitives, targeting the needs of implementers, researchers, and protocol designers. It highlights the importance of technical specifications and discusses strategies for creating high-quality specifications that cater to the needs of each community, including guidance on representing mathematical operations, security definitions, and threat models. Extended Key Update for Transport Layer Security (TLS) 1.3 Siemens Münster Univ. of Applied Sciences Nokia Siemens Zscaler TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh Diffie-Hellman exchange within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key Vigil Security, LLC This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC (once approved) obsoletes RFC 8773, which was an Experimental RFC. Formal analysis of draft-ietf-tls-pake Comments on draft-ietf-tls-extended-key-update 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. TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK). ML-KEM Post-Quantum Key Agreement for TLS 1.3 SandboxAQ This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment. Service Affinity Solution based on Transport Layer Security (TLS) China Telecom China Telecom Palo Alto Networks Palo Alto Networks This draft proposes a service affinity solution between client and server based on Transport Layer Security (TLS). An extension to Transport Layer Security (TLS) 1.3 to enable session migration. This mechanism is designed for modern network architectures, particularly for multi-homed servers that possess multiple network interfaces and IP addresses. Comparing to the existing solutions such as maintaining the customer- based connection status table in network devices, HTTP redirection and DNS redirection, this solution can avoid the waste of resources caused by saving a large amount of customer status data in the network devices, and realize the optimized scheduling of resources based on network conditions and computing resources in the computing- aware traffic steering scenario, so as to realize the reasonable operation of network resources, cloud resources and computing resources.
Appendix
Document History -02
  • Added document structure
  • FATT-bypass by Other TLS-related WGs
  • FATT process not being followed
-01
  • Pain points of Verifier
  • Small adjustment of phrasing