Guidance for External Pre-Shared Key (PSK) Usage in TLSVigil Security, LLChousley@vigilsec.comCloudflare Ltd.jonathan.hoyland@gmail.comAalto Universitymohit@iki.fiCloudflarecaw@heapingbits.net
security
tlsThis document provides usage guidance for external Pre-Shared Keys (PSKs)
in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
It lists TLS security properties provided by PSKs under certain
assumptions, then it demonstrates how violations of these assumptions lead
to attacks. Advice for applications to help meet these assumptions is
provided. This document also discusses PSK use cases and provisioning processes.
Finally, it lists the privacy and security properties that are not
provided by TLS 1.3 when external PSKs are used.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Conventions and Definitions
. Notation
. PSK Security Properties
. Shared PSKs
. PSK Entropy
. External PSKs in Practice
. Use Cases
. Provisioning Examples
. Provisioning Constraints
. Recommendations for External PSK Usage
. Stack Interfaces
. PSK Identity Encoding and Comparison
. PSK Identity Collisions
. Privacy Considerations
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionThis document provides guidance on the use of external Pre-Shared Keys (PSKs)
in Transport Layer Security (TLS) 1.3 . This guidance also
applies to Datagram TLS (DTLS) 1.3 and
Compact TLS 1.3 . For readability, this document uses
the term "TLS" to refer to all such versions.External PSKs are symmetric
secret keys provided to the TLS protocol implementation as external inputs.
External PSKs are provisioned out of band.This document lists
TLS security properties provided by PSKs under certain assumptions and
demonstrates how violations of these assumptions lead to attacks. This
document discusses PSK use cases, provisioning processes, and TLS stack
implementation support in the context of these assumptions.
This document
also provides advice for applications in various use cases to help meet
these assumptions.There are many resources that provide guidance for password generation and
verification aimed towards improving security. However, there is no such
equivalent for external PSKs in TLS. This document aims
to reduce that gap.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.
NotationFor purposes of this document, a "logical node" is a computing presence that
other parties can interact with via the TLS protocol. A logical node could
potentially be realized with multiple physical instances operating under common
administrative control, e.g., a server farm. An "endpoint" is a client or server
participating in a connection.PSK Security PropertiesThe use of a previously established PSK allows TLS nodes to authenticate
the endpoint identities. It also offers other benefits, including
resistance to attacks in the presence of quantum computers;
see for related discussion. However, these keys do not provide
privacy protection of endpoint identities, nor do they provide non-repudiation
(one endpoint in a connection can deny the conversation); see
for related discussion.PSK authentication security implicitly assumes one fundamental property: each
PSK is known to exactly one client and one server and they never switch
roles. If this assumption is violated, then the security properties of TLS are
severely weakened as discussed below.Shared PSKsAs discussed in , to demonstrate their attack, describes
scenarios where multiple clients or multiple servers share a PSK. If
this is done naively by having all members share a common key, then
TLS authenticates only group membership, and the security of the
overall system is inherently rather brittle. There are a number of
obvious weaknesses here:
Any group member can impersonate any other group member.
If a PSK is combined with the result of a fresh ephemeral key exchange, then compromise of a group member that knows
the resulting shared secret will enable the attacker to passively read traffic (and actively modify it).
If a PSK is not combined with the result of a fresh ephemeral key exchange, then compromise of any group member allows the
attacker to passively read all traffic (and actively modify it), including past traffic.
Additionally, a malicious non-member can reroute handshakes between honest group members
to connect them in unintended ways, as described below. Note that a partial mitigation for
this class of attack is available: each group member includes the Server Name Indication (SNI) extension
and terminates the connection on mismatch between the presented SNI value and the
receiving member's known identity. See for details.To illustrate the rerouting attack, consider three peers, A, B, and C,
who all know the PSK. The attack proceeds as follows:
A sends a ClientHello to B.
The attacker intercepts the message and redirects it to C.
C responds with a second flight (ServerHello, ...) to A.
A sends a Finished message to B.
A has completed the handshake, ostensibly with B.
The attacker redirects the Finished message to C.
C has completed the handshake with A.
In this attack, peer authentication is not provided. Also, if C supports a
weaker set of ciphersuites than B, cryptographic algorithm downgrade attacks
might be possible. This rerouting is a type of identity misbinding attack
. Selfie attack is a special case of the rerouting
attack against a group member that can act as both a TLS server and a client. In the
Selfie attack, a malicious non-member reroutes a connection from the client to
the server on the same endpoint.Finally, in addition to these weaknesses, sharing a PSK across nodes may negatively
affect deployments. For example, revocation of individual group members is not
possible without establishing a new PSK for all of the members that have not been revoked.PSK EntropyEntropy properties of external PSKs may also affect TLS security properties. For example,
if a high-entropy PSK is used, then PSK-only key establishment modes provide expected
security properties for TLS, including establishment of the same
session keys between peers, secrecy of session keys, peer authentication, and downgrade
protection. See for an explanation of these properties.
However, these modes lack forward security. Forward security may be achieved by using a
PSK-DH mode or by using PSKs with short lifetimes.In contrast, if a low-entropy PSK is used, then PSK-only key establishment modes
are subject to passive exhaustive search attacks, which will reveal the
traffic keys. PSK-DH modes are subject to active attacks in which the attacker
impersonates one side. The exhaustive search phase of these attacks can be mounted
offline if the attacker captures a single handshake using the PSK, but those
attacks will not lead to compromise of the traffic keys for that connection because
those also depend on the Diffie-Hellman (DH) exchange. Low-entropy keys are only
secure against active attack if a Password-Authenticated Key Exchange (PAKE) is used
with TLS. At the time of writing, the Crypto Forum Research Group (CFRG) is working on specifying
recommended PAKEs (see and for
the symmetric and asymmetric cases, respectively).External PSKs in PracticePSK ciphersuites were first specified for TLS in 2005. PSKs are now an integral
part of the TLS 1.3 specification . TLS 1.3 also uses PSKs for session resumption.
It distinguishes these resumption PSKs from external PSKs that have been provisioned out of band.
This section describes known use cases and provisioning processes for external PSKs with TLS.Use CasesThis section lists some example use cases where pairwise external PSKs (i.e., external
PSKs that are shared between only one server and one client) have been used for authentication
in TLS. There was no attempt to prioritize the examples in any particular order.
Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out of band
for communicating with known identities, wherein the identity to use is discovered via a different
online protocol.
Intra-data-center communication. Machine-to-machine communication within a single data center
or Point of Presence (PoP) may use externally provisioned PSKs; this is primarily for the purpose of supporting TLS
connections with early data. See for considerations when using early data
with external PSKs.
Certificateless server-to-server communication. Machine-to-machine communication
may use externally provisioned PSKs; this is primarily for the purposes of establishing TLS
connections without requiring the overhead of provisioning and managing PKI certificates.
Internet of Things (IoT) and devices with limited computational capabilities.
defines TLS and DTLS profiles for resource-constrained devices and suggests
the use of PSK ciphersuites for compliant devices. The Open Mobile Alliance Lightweight Machine-to-Machine (LwM2M) Technical Specification states that LwM2M servers MUST support the
PSK mode of DTLS.
Securing RADIUS with TLS. PSK ciphersuites are optional for this use case, as specified
in .
3GPP server-to-user equipment authentication. The Generic Authentication Architecture (GAA) defined by
3GPP mentions that TLS PSK ciphersuites can be used between server and user equipment for authentication .
Smart Cards. The German electronic Identity (eID) card supports authentication of a card holder to
online services with TLS PSK .
Quantum resistance. Some deployments may use PSKs (or combine them with certificate-based
authentication as described in ) because of the protection they provide against
quantum computers.
There are also use cases where PSKs are shared between more than two entities. Some examples below
(as noted by Akhmetzyanova, et al. ):
Group chats. In this use case, group participants may be provisioned an external PSK out of band for establishing
authenticated connections with other members of the group.
IoT and devices with limited computational capabilities. Many PSK provisioning examples are
possible in this use case. For example, in a given setting, IoT devices may all share the same PSK and use it to
communicate with a central server (one key for n devices), have their own key for communicating with a central server (n
keys for n devices), or have pairwise keys for communicating with each other (n2 keys for n devices).
Provisioning ExamplesThe exact provisioning process depends on the system requirements and threat
model. Whenever possible, avoid sharing a PSK between nodes; however, sharing
a PSK among several nodes is sometimes unavoidable. When PSK sharing happens,
other accommodations SHOULD be used as discussed in .Examples of PSK provisioning processes are included below.
Many industrial protocols assume that PSKs are distributed and assigned manually via one of the following
approaches: (1) typing the PSK into the devices or (2) using a trust-on-first-use (TOFU) approach with a device
completely unprotected before the first login took place. Many devices have a very limited UI. For example,
they may only have a numeric keypad or even fewer buttons. When the TOFU approach is not suitable,
entering the key would require typing it on a constrained UI.
Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.
Some secrets may be baked into hardware or software device components. Moreover, when this is done
at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of
scanning or import.
Provisioning ConstraintsPSK provisioning systems are often constrained in application-specific ways. For example, although one goal of
provisioning is to ensure that each pair of nodes has a unique key pair, some systems do not want to distribute
pairwise shared keys to achieve this. As another example, some systems require the provisioning process to embed
application-specific information in either PSKs or their identities. Identities may sometimes need to be routable,
as is currently under discussion for .Recommendations for External PSK UsageRecommended requirements for applications using external PSKs are as follows:
Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least
128 bits long, and SHOULD be combined with an ephemeral key exchange, e.g., by using the
"psk_dhe_ke" Pre-Shared Key Exchange Mode in TLS 1.3 for forward secrecy. As
discussed in , low-entropy PSKs (i.e., those derived from less
than 128 bits of entropy) are subject to attack and SHOULD be avoided. If only
low-entropy keys are available, then key establishment mechanisms such as PAKE that mitigate the risk of offline dictionary attacks
SHOULD be employed. Note that no such mechanisms have yet been standardized, and further
that these mechanisms will not necessarily follow the same architecture as the
process for incorporating external PSKs described in .
Unless other accommodations are made to mitigate the risks of PSKs known to a group, each PSK MUST be restricted in
its use to at most two logical nodes: one logical node in a TLS client
role and one logical node in a TLS server role. (The two logical nodes
MAY be the same, in different roles.) Two acceptable accommodations
are described in : (1) exchanging
client and server identifiers over the TLS connection after the
handshake and (2) incorporating identifiers for both the client and the
server into the context string for an external PSK importer.
Nodes SHOULD use external PSK importers
when configuring PSKs for a client-server pair when applicable. Importers make provisioning
external PSKs easier and less error-prone by deriving a unique, imported PSK from the
external PSK for each key derivation function a node supports. See the Security Considerations of
for more information.
Where possible, the main PSK (that which is fed into the importer) SHOULD be
deleted after the imported keys have been generated. This prevents an attacker
from bootstrapping a compromise of one node into the ability to attack connections
between any node; otherwise, the attacker can recover the main key and then
re-run the importer itself.
Stack InterfacesMost major TLS implementations support external PSKs. Stacks supporting external PSKs
provide interfaces that applications may use when configuring PSKs for individual
connections. Details about some existing stacks at the time of writing are below.
OpenSSL and BoringSSL: Applications can specify support for external PSKs via
distinct ciphersuites in TLS 1.2 and below. Also, they can then configure callbacks that are invoked for
PSK selection during the handshake. These callbacks must provide a PSK identity and key. The
exact format of the callback depends on the negotiated TLS protocol version, with new callback
functions added specifically to OpenSSL for TLS 1.3 PSK support. The PSK length is validated to be between 1-256 bytes (inclusive). The PSK identity may be up to 128 bytes long.
mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK
identity and value inline. Servers must implement callbacks similar to that of OpenSSL. Both PSK
identity and key lengths may be between 1-16 bytes long (inclusive).
gnuTLS: Applications configure PSK values as either raw byte strings or
hexadecimal strings. The PSK identity and key size are not validated.
wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.
PSK Identity Encoding and Comparison mandates that the PSK identity should be first converted to a character string and then
encoded to octets using UTF-8. This was done to avoid interoperability problems (especially when the identity is
configured by human users). On the other hand, advises implementations against assuming any structured
format for PSK identities and recommends byte-by-byte comparison for any operation. When PSK identities are configured
manually, it is important to be aware that visually identical strings may, in fact, differ due to encoding issues.TLS 1.3 follows the same practice of specifying
the PSK identity as a sequence of opaque bytes (shown as opaque identity<1..2^16-1>
in the specification) that thus is compared on a byte-by-byte basis.
also requires that the PSK identities are at
least 1 byte and at the most 65535 bytes in length. Although does not
place strict requirements on the format of PSK identities, note that
the format of PSK identities can vary depending on the deployment:
The PSK identity MAY be a user-configured string when used in protocols like
Extensible Authentication Protocol (EAP) . For example, gnuTLS treats
PSK identities as usernames.
PSK identities MAY have a domain name suffix for roaming and federation. In
applications and settings where the domain name suffix is privacy sensitive, this
practice is NOT RECOMMENDED.
Deployments should take care that the length of the PSK identity is sufficient
to avoid collisions.
PSK Identity CollisionsIt is possible, though unlikely, that an external PSK identity may clash with a
resumption PSK identity. The TLS stack implementation and sequencing of PSK callbacks
influences the application's behavior when identity collisions occur. When a server
receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks
execute the application's registered callback function before checking the stack's
internal session resumption cache. This means that if a PSK identity collision occurs,
the application's external PSK usage will typically take precedence over the internal
session resumption path.Because resumption PSK identities are assigned by the TLS stack implementation,
it is RECOMMENDED that these identifiers be assigned in a manner that lets
resumption PSKs be distinguished from external PSKs to avoid concerns with
collisions altogether.Privacy ConsiderationsPSK privacy properties are orthogonal to security properties described in .
TLS does little to keep PSK identity information private. For example,
an adversary learns information about the external PSK or its identifier by virtue of the identifier
appearing in cleartext in a ClientHello. As a result, a passive adversary can link two or
more connections together that use the same external PSK on the wire. Depending on the PSK
identity, a passive attacker may also be able to identify the device, person, or enterprise
running the TLS client or TLS server. An active attacker can also use the PSK identity to
suppress handshakes or application data from a specific device by blocking, delaying, or
rate-limiting traffic. Techniques for mitigating these risks require further analysis and are out
of scope for this document.In addition to linkability in the network, external PSKs are intrinsically linkable
by PSK receivers. Specifically, servers can link successive connections that use the
same external PSK together. Preventing this type of linkability is out of scope.Security ConsiderationsSecurity considerations are provided throughout this document. It bears
repeating that there are concerns related to the use of external PSKs regarding
proper identification of TLS 1.3 endpoints and additional risks when external
PSKs are known to a group.It is NOT RECOMMENDED to share the same PSK between more than one client and server.
However, as discussed in , there are application scenarios that may
rely on sharing the same PSK among multiple nodes.
helps in mitigating rerouting and Selfie-style reflection attacks when the PSK
is shared among multiple nodes. This is achieved by correctly using the node
identifiers in the ImportedIdentity.context construct specified in
. One solution would be for each endpoint
to select one globally unique identifier to use in all PSK handshakes. The
unique identifier can, for example, be one of its Media Access Control (MAC) addresses, a 32-byte
random number, or its Universally Unique IDentifier (UUID) .
Note that such persistent, global identifiers have privacy implications;
see .Each endpoint SHOULD know the identifier of the other endpoint with which it wants
to connect and SHOULD compare it with the other endpoint's identifier used in
ImportedIdentity.context. However, it is important to remember that endpoints
sharing the same group PSK can always impersonate each other.Considerations for external PSK usage extend beyond proper identification.
When early data is used with an external PSK, the random value in the ClientHello
is the only source of entropy that contributes to key diversity between sessions.
As a result, when an external PSK is used more than one time, the random number
source on the client has a significant role in the protection of the early data.IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn 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 WordsRFC 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.The Transport Layer Security (TLS) Protocol Version 1.3This 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 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Importing External Pre-Shared Keys (PSKs) for TLS 1.3Informative ReferencesContinuing to reflect on TLS 1.3 with external PSKCPace, a balanced composable PAKEDFINITY - ZurichEndress + Hauser Liquid Analysis - GerlingenIBM Research Europe - Zurich This document describes CPace which is a protocol that allows two
parties that share a low-entropy secret (password) to derive a strong
shared key without disclosing the secret to offline dictionary
attacks. The CPace protocol was tailored for constrained devices, is
compatible with any cyclic group of prime- and non-prime order.
Work in ProgressCompact TLS 1.3MozillaCiscoArm LimitedGoogle This document specifies a "compact" version of TLS and DTLS. It is
logically isomorphic to ordinary TLS, but saves space by trimming
obsolete material, tighter encoding, a template-based specialization
technique, and alternative cryptographic techniques. cTLS is not
directly interoperable with TLS or DTLS, but it should eventually be
possible for a single server port to offer cTLS alongside TLS or
DTLS.
Work in ProgressEAP-TLS with PSK Authentication (EAP-TLS-PSK)EricssonEricssonAalto UniversityCisco While TLS 1.3 supports authentication with Pre-Shared Key (PSK), EAP-
TLS with TLS 1.3 explicitly forbids PSK authentication except when
used for resumption. This document specifies a separate EAP method
(EAP-TLS-PSK) for use cases that require authentication based on
external PSKs.
Work in ProgressDigital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; 3G Security; Generic Authentication Architecture (GAA); System descriptionETSIversion 12.0.0SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE ProtocolsLightweight Machine to Machine Technical SpecificationOpen Mobile Allianceversion 1.0The OPAQUE Asymmetric PAKE ProtocolAlgorand FoundationNovi ResearchCloudflare, Inc. This document describes the OPAQUE protocol, a secure asymmetric
password-authenticated key exchange (aPAKE) that supports mutual
authentication in a client-server setting without reliance on PKI and
with security against pre-computation attacks upon server compromise.
In addition, the protocol provides forward secrecy and the ability to
hide the password from the server, even during password registration.
This document specifies the core OPAQUE protocol and one
instantiation based on 3DH.
Work in ProgressRemote Authentication Dial In User Service (RADIUS)This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]Extensible Authentication Protocol (EAP)This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]A Universally Unique IDentifier (UUID) URN NamespaceThis specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK]Transport Layer Security (TLS) Extensions: Extension DefinitionsThis document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]Transport Layer Security (TLS) Encryption for RADIUSThis document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK]Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of ThingsA common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared KeyThis 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).The Datagram Transport Layer Security (DTLS) Protocol Version 1.3This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.This document obsoletes RFC 6347.Selfie: reflections on TLS 1.3 with PSKMisbinding Attacks on Secure Device Pairing and BootstrappingTechnical Guideline TR-03112-7 eCard-API-Framework - ProtocolsBundesamt für Sicherheit in der Informationstechnikversion 1.1.5AcknowledgementsThis document is the output of the TLS External PSK Design Team, comprised of the following members:
Benjamin Beurdouche,
,
,
,
,
,
,
,
,
,
, and
.This document was improved by high-quality reviews by and .Authors' AddressesVigil Security, LLChousley@vigilsec.comCloudflare Ltd.jonathan.hoyland@gmail.comAalto Universitymohit@iki.fiCloudflarecaw@heapingbits.net