| RFC 8844 | SDP UKS | January 2021 |
| Thomson & Rescorla | Standards Track | [Page] |
This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer. This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy.¶
This is an Internet Standards Track document.¶
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). Further information on Internet Standards is available in 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 athttps://www.rfc-editor.org/info/rfc8844.¶
Copyright (c) 2021 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 (https://trustee.ietf.org/license-info) 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
The use of Transport Layer Security (TLS)[TLS13] with the Session Description Protocol (SDP)[SDP] is defined in[FINGERPRINT]. Further use with Datagram Transport Layer Security (DTLS)[DTLS] and the Secure Real-time Transport Protocol (SRTP)[SRTP] is defined as DTLS-SRTP[DTLS-SRTP].¶
In these specifications, key agreement is performed using TLS or DTLS, withauthentication being tied back to the session description (or SDP) through theuse of certificate fingerprints. Communication peers check that a hash, orfingerprint, provided in the SDP matches the certificate that is used in the TLSor DTLS handshake.¶
WebRTC identity (seeSection 7 of [WEBRTC-SEC])and SIP identity[SIP-ID] both provide a mechanism that binds anexternal identity to the certificate fingerprints from a session description.However, this binding is not integrity protected and is therefore vulnerable to anidentity misbinding attack, also known as an unknown key-share (UKS) attack, where theattacker binds their identity to the fingerprint of another entity. Asuccessful attack leads to the creation of sessions where peers are confusedabout the identity of the participants.¶
This document describes a TLS extension that can be used in combination withthese identity bindings to prevent this attack.¶
A similar attack is possible with the use of certificate fingerprints alone. Though attacks in this setting are likely infeasible in existing deployments due to the narrow preconditions(seeSection 2.1), this document alsodescribes mitigations for this attack.¶
The mechanisms defined in this document are intended to strengthen the protocolby preventing the use of unknown key-share attacks in combination with other protocolor implementation vulnerabilities. RFC 8122[FINGERPRINT] is updated by thisdocument to recommend the use of these mechanisms.¶
This document assumes that signaling is integrity protected. However, asSection 7 of [FINGERPRINT] explains, many deployments that use SDP do notguarantee integrity of session signaling and so are vulnerable to other attacks.[FINGERPRINT] offers key continuity mechanisms as a potential means ofreducing exposure to attack in the absence of integrity protection.Section 2.2 provides some analysis of the effect of key continuity inrelation to the described attacks.¶
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[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
In an unknown key-share attack[UKS], a malicious participant in a protocolclaims to control a key that is in reality controlled by some other actor. Thisarises when the identity associated with a key is not properly bound to the key.¶
An endpoint that can acquire the certificate fingerprint of another entity canadvertise that fingerprint as their own in SDP. An attacker can use a copy of that fingerprint to cause a victim to communicate with another unaware victim, even though the first victim believes that it is communicating with the attacker.¶
When the identity of communicating peers is established by higher-layersignaling constructs, such as those in SIP identity[SIP-ID] or WebRTC[WEBRTC-SEC], this allows an attacker to bind their own identity to a sessionwith any other entity.¶
The attacker obtains an identity assertion for an identity it controls, butbinds that to the fingerprint of one peer. The attacker is then able to cause aTLS connection to be established where two victim endpoints communicate. Thevictim that has its fingerprint copied by the attack correctly believes that itis communicating with the other victim; however, the other victim incorrectlybelieves that it is communicating with the attacker.¶
An unknown key-share attack does not result in the attacker having access to anyconfidential information exchanged between victims. However, the failure inmutual authentication can enable other attacks. A victim might send informationto the wrong entity as a result. Where information is interpreted in context,misrepresenting that context could lead to the information being misinterpreted.¶
A similar attack can be mounted based solely on the SDPfingerprint attribute[FINGERPRINT] without compromising the integrity of the signaling channel.¶
This attack is an aspect of SDP-based protocols upon which the technique known asthird-party call control (3PCC)[RFC3725] relies. 3PCC exploits thepotential for the identity of a signaling peer to be different than the mediapeer, allowing the media peer to be selected by the signaling peer.Section 2.3 describes the consequences of the mitigations described here forsystems that use 3PCC.¶
The use of TLS with SDP depends on the integrity of session signaling. Assumingsignaling integrity limits the capabilities of an attacker in several ways. Inparticular:¶
The combination of these two constraints make the spectrum of possible attacksquite limited. An attacker is only able to switch its own certificatefingerprint for a valid certificate that is acceptable to its peer. Attackstherefore rely on joining two separate sessions into a single session.Section 4describes an attack on SDP signaling under these constraints.¶
Systems that rely on strong identity bindings, such as those defined in[WEBRTC] or[SIP-ID], have a different threat model, which admits thepossibility of attack by an entity with access to the signaling channel.Attacks under these conditions are more feasible as an attacker is assumed to beable both to observe and to modify signaling messages.Section 3 describes an attackthat assumes this threat model.¶
Systems that use key continuity (as defined inSection 15.1 of [ZRTP]or as recommended inSection 7 of [FINGERPRINT]) might be able to detect anunknown key-share attack if a session with either the attacker or the genuinepeer (i.e., the victim whose fingerprint was copied by an attacker) wasestablished in the past. Whether this is possible depends on how key continuityis implemented.¶
Implementations that maintain a single database of identities with an index ofpeer keys could discover that the identity saved for the peer key does not matchthe claimed identity. Such an implementation could notice the disparity betweenthe actual keys (those copied from a victim) and the expected keys (those of theattacker).¶
In comparison, implementations that first match based on peer identity couldtreat an unknown key-share attack as though their peer had used anewly configured device. The apparent addition of a new device could generateuser-visible notices (e.g., "Mallory appears to have a new device"). However,such an event is not always considered alarming; some implementations mightsilently save a new key.¶
Third-party call control (3PCC)[RFC3725] is a technique where a signalingpeer establishes a call that is terminated by a different entity. An unknownkey-share attack is very similar in effect to some 3PCC practices, so use of3PCC could appear to be an attack. However, 3PCC that follows RFC 3725 guidanceis unaffected, and peers that are aware of changes made by a 3PCC controller cancorrectly distinguish actions of a 3PCC controller from an attack.¶
3PCC as described in RFC 3725 is incompatible with SIP identity[SIP-ID], asSIP Identity relies on creating a binding between SIP requests and SDP. Thecontroller is the only entity that generates SIP requests in RFC 3725.Therefore, in a 3PCC context, only the use of thefingerprint attributewithout additional bindings or WebRTC identity[WEBRTC-SEC] is possible.¶
The attack mitigation mechanisms described in this document will prevent the useof 3PCC if peers have different views of the involved identities or the valueof SDPtls-id attributes.¶
For 3PCC to work with the proposed mechanisms, TLS peers need to be aware of thesignaling so that they can correctly generate and check the TLS extensions. Fora connection to be successfully established, a 3PCC controller needs either toforward SDP without modification or to avoid modifications tofingerprint,tls-id, andidentity attributes. A controller that follows the bestpractices in RFC 3725 is expected to forward SDP without modification, thusensuring the integrity of these attributes.¶
The identity assertions used for WebRTC(Section 7 of [WEBRTC-SEC]) and thePersonal Assertion Token (PASSporT) used in SIP identity ([SIP-ID],[PASSPORT]) are boundto the certificate fingerprint of an endpoint. An attacker can cause an identitybinding to be created that binds an identity they control to the fingerprint ofa first victim.¶
An attacker can thereby cause a second victim to believe that they arecommunicating with an attacker-controlled identity, when they are really talkingto the first victim. The attacker does this by creating an identity assertionthat covers a certificate fingerprint of the first victim.¶
A variation on the same technique can be used to cause both victims tobelieve they are talking to the attacker when they are talking to each other.In this case, the attacker performs the identity misbinding once for eachvictim.¶
The authority certifying the identity binding is not required to verify that the entity requesting the binding actually controls the keys associated with the fingerprints, and this might appear to be the cause of the problem. SIP and WebRTC identity providers are not required to perform this validation.¶
A simple solution to this problem is suggested by[SIGMA]. The identity ofendpoints is included under a message authentication code (MAC) during thecryptographic handshake. Endpoints then validate that their peer has providedan identity that matches their expectations. In TLS, the Finished messageprovides a MAC over the entire handshake, so that including the identity in aTLS extension is sufficient to implement this solution.¶
Rather than include a complete identity binding, which could besizable, a collision- and preimage-resistant hash of the binding is includedin a TLS extension as described inSection 3.2. Endpoints then needonly validate that the extension contains a hash of the identity binding theyreceived in signaling. If the identity binding is successfully validated, theidentity of a peer is verified and bound to the session.¶
This form of unknown key-share attack is possible without compromising signalingintegrity, unless the defenses described inSection 4 are used. In order toprevent both forms of attack, endpointsMUST use theexternal_session_idextension (seeSection 4.3) in addition to theexternal_id_hash(Section 3.2) so that two calls between the same parties can't bealtered by an attacker.¶
In the example shown inFigure 1, it is assumed that the attackeralso controls the signaling channel.¶
Mallory (the attacker) presents two victims, Norma and Patsy, with two separatesessions. In the first session, Norma is presented with the option tocommunicate with Mallory; a second session with Norma is presented to Patsy.¶
Norma Mallory Patsy (fp=N) ----- (fp=P) | | | |<---- Signaling1 ------>| | | Norma=N Mallory=P | | | |<---- Signaling2 ------>| | | Norma=N Patsy=P | | | |<=================DTLS (fp=N,P)=================>| | | (peer = Mallory!) (peer = Norma)
The attack requires that Mallory obtain an identity binding for her own identitywith the fingerprints presented by Patsy (P), which Mallory might have obtainedpreviously. This false binding is then presented to Norma ('Signaling1' inFigure 1).¶
Patsy could be similarly duped, but in this example, a correct binding betweenNorma's identity and fingerprint (N) is faithfully presented by Mallory. Thissession ('Signaling2' inFigure 1) can be entirely legitimate.¶
A DTLS session is established directly between Norma and Patsy. In order for this to happen, Mallory can substitute transport-level information in both sessions, though this is not necessary if Mallory is on the network path between Norma and Patsy.¶
As a result, Patsy correctly believes that she is communicating with Norma.However, Norma incorrectly believes that she is talking to Mallory. As stated inSection 2, Mallory cannot access media, but Norma might send information to Patsythat Norma might not intend or that Patsy might misinterpret.¶
external_id_hash TLS ExtensionTheexternal_id_hash TLS extension carries a hash of the identity assertionthat the endpoint sending the extension has asserted to its peer. Both peersinclude a hash of their own identity assertion.¶
Theextension_data for theexternal_id_hash extension contains aExternalIdentityHash struct, described below using the syntax defined inSection 3 of [TLS13]:¶
struct { opaque binding_hash<0..32>; } ExternalIdentityHash;¶Where an identity assertion has been asserted by a peer, this extension includesa SHA-256 hash of the assertion. An empty value is used to indicate support forthe extension.¶
Identity bindings might be provided by only one peer. An endpoint that does notproduce an identity bindingMUST generate an emptyexternal_id_hash extensionin its ClientHello or -- if a client provides the extension -- in ServerHello orEncryptedExtensions. An empty extension has a zero-lengthbinding_hash field.¶
A peer that receives anexternal_id_hash extension that does not match thevalue of the identity binding from its peerMUST immediately fail the TLShandshake with anillegal_parameter alert. The absence of an identity bindingdoes not relax this requirement; if a peer provided no identity binding, azero-length extensionMUST be present to be considered valid.¶
Implementations written prior to the definition of the extensions in thisdocument will not support this extension for some time. A peer that receives anidentity binding but does not receive anexternal_id_hash extensionMAY accepta TLS connection rather than fail a connection where the extension is absent.¶
The endpoint performs the validation of theexternal_id_hash extension in addition to the validation required by[FINGERPRINT] and any verification of the identity assertion[WEBRTC-SEC][SIP-ID]. An endpointMUST validate any external_session_id value that is present; seeSection 4.3.¶
Anexternal_id_hash extension with abinding_hash fieldthat is any length other than 0 or 32 is invalidandMUST cause the receiving endpoint to generate a fataldecode_error alert.¶
In TLS 1.3, anexternal_id_hash extension sent by a serverMUST be sent in theEncryptedExtensions message.¶
external_id_hash for WebRTC IdentityA WebRTC identity assertion(Section 7 of [WEBRTC-SEC]) is provided as a JSON[JSON] object that is encoded into a JSON text. The JSON text isencoded using UTF-8[UTF8] as described bySection 8.1 of [JSON].The content of theexternal_id_hash extension is produced by hashing theresulting octets with SHA-256[SHA]. This produces the 32 octets ofthebinding_hash parameter, which is the sole contents of the extension.¶
The SDPidentity attribute includes the base64[BASE64] encoding ofthe UTF-8 encoding of the same JSON text. Theexternal_id_hash extension isvalidated by performing base64 decoding on the value of the SDPidentityattribute, hashing the resulting octets using SHA-256, and comparing the resultswith the content of the extension. In pseudocode form, using theidentity-assertion-value field from the SDPidentity attribute grammar asdefined in[WEBRTC-SEC]:¶
external_id_hash = SHA-256(b64decode(identity-assertion-value))¶
identity attribute is decoded to avoid capturingvariations in padding. The base64-decoded identity assertion could includeleading or trailing whitespace octets. WebRTC identity assertions are notcanonicalized; all octets are hashed.¶Where the compact form of PASSporT[PASSPORT]is used, itMUST be expandedinto the full form. The base64 encoding used in the SIP Identity (or 'y')header fieldMUST be decoded then used as input to SHA-256. This produces the32-octetbinding_hash value used for creating or validating the extension. Inpseudocode, using thesigned-identity-digest parameter from theIdentity header field grammardefined[SIP-ID]:¶
external_id_hash = SHA-256(b64decode(signed-identity-digest))¶
An attack on DTLS-SRTP is possible because the identity of peers involved is notestablished prior to establishing the call. Endpoints use certificatefingerprints as a proxy for authentication, but as long as fingerprints are usedin multiple calls, they are vulnerable to attack.¶
Even if the integrity of session signaling can be relied upon, an attacker mightstill be able to create a session where there is confusion about thecommunicating endpoints by substituting the fingerprint of a communicatingendpoint.¶
An endpoint that is configured to reuse a certificate can be attacked if it iswilling to initiate two calls at the same time, one of which is with anattacker. The attacker can arrange for the victim to incorrectly believe thatit is calling the attacker when it is in fact calling a second party. Thesecond party correctly believes that it is talking to the victim.¶
As with the attack on identity bindings, this can be used to cause two victimsto both believe they are talking to the attacker when they are talking to eachother.¶
To mount this attack, two sessions need to be created with the same endpoint atalmost precisely the same time. One of those sessions is initiated with theattacker, the second session is created toward another honest endpoint. Theattacker convinces the first endpoint that their session with the attacker hasbeen successfully established, but media is exchanged with the other honestendpoint. The attacker permits the session with the other honest endpoint tocomplete only to the extent necessary to convince the other honest endpoint toparticipate in the attacked session.¶
In addition to the constraints described inSection 2.1, the attacker in thisexample also needs the ability to view and drop packets between victims.That is, the attacker needs to be on path for media.¶
The attack shown inFigure 2 depends on a somewhat implausible setof conditions. It is intended to demonstrate what sort of attack is possibleand what conditions are necessary to exploit this weakness in the protocol.¶
Norma Mallory Patsy (fp=N) ----- (fp=P) | | | +---Signaling1 (fp=N)--->| | +-----Signaling2 (fp=N)------------------------>| |<-------------------------Signaling2 (fp=P)----+ |<---Signaling1 (fp=P)---+ | | | | |=======DTLS1=======>(Forward)======DTLS1======>| |<======DTLS2========(Forward)<=====DTLS2=======| |=======Media1======>(Forward)======Media1=====>| |<======Media2=======(Forward)<=====Media2======| | | | |=======DTLS2========>(Drop) | | | |
In this scenario, there are two sessions initiated at the same time by Norma.Signaling is shown with single lines ('-'), DTLS and media with double lines('=').¶
The first session is established with Mallory, who falsely uses Patsy'scertificate fingerprint (denoted with 'fp=P'). A second session is initiatedbetween Norma and Patsy. Signaling for both sessions is permitted to complete.¶
Once signaling is complete on the first session, a DTLS connection isestablished. Ostensibly, this connection is between Mallory and Norma, butMallory forwards DTLS and media packets sent to her by Norma to Patsy. Thesepackets are denoted 'DTLS1' because Norma associates these with the firstsignaling session ('Signaling1').¶
Mallory also intercepts packets from Patsy and forwards those to Norma at thetransport address that Norma associates with Mallory. These packets are denoted'DTLS2' to indicate that Patsy associates these with the second signalingsession ('Signaling2'); however, Norma will interpret these as being associatedwith the first signaling session ('Signaling1').¶
The second signaling exchange ('Signaling2'), which is between Norma and Patsy, ispermitted to continue to the point where Patsy believes that it has succeeded.This ensures that Patsy believes that she is communicating with Norma. In theend, Norma believes that she is communicating with Mallory, when she is reallycommunicating with Patsy. Just like the example inSection 3.1, Mallorycannot access media, but Norma might send information to Patsy that Normamight not intend or that Patsy might misinterpret.¶
Though Patsy needs to believe that the second signaling session has beensuccessfully established, Mallory has no real interest in seeing that sessionalso be established. Mallory only needs to ensure that Patsy maintains theactive session and does not abandon the session prematurely. For this reason,it might be necessary to permit the signaling from Patsy to reach Norma in order to allowPatsy to receive a call setup completion signal, such as a SIP ACK. Once thesecond session is established, Mallory might cause DTLS packets sent by Norma toPatsy to be dropped. However, if Mallory allows DTLS packets to pass, it islikely that Patsy will discard them as Patsy will already have a successful DTLSconnection established.¶
For the attacked session to be sustained beyond the point that Norma detectserrors in the second session, Mallory also needs to block any signaling thatNorma might send to Patsy asking for the call to be abandoned. Otherwise, Patsymight receive a notice that the call has failed and thereby abort the call.¶
This attack creates an asymmetry in the beliefs about the identity of peers.However, this attack is only possible if the victim (Norma) is willing toconduct two sessions nearly simultaneously; if the attacker (Mallory) is on thenetwork path between the victims; and if the same certificate -- and thereforethe SDPfingerprint attribute value -- is used by Norma for both sessions.¶
Where Interactive Connectivity Establishment (ICE)[ICE]is used, Mallory also needs to ensure thatconnectivity checks between Patsy and Norma succeed, either by forwarding checksor by answering and generating the necessary messages.¶
The solution to this problem is to assign a new identifier to communicatingpeers. Each endpoint assigns their peer a unique identifier during callsignaling. The peer echoes that identifier in the TLS handshake, binding thatidentity into the session. Including this new identity in the TLS handshakemeans that it will be covered by the TLS Finished message, which is necessary toauthenticate it (see[SIGMA]).¶
Successfully validating that the identifier matches the expected value means thatthe connection corresponds to the signaled session and is therefore establishedbetween the correct two endpoints.¶
This solution relies on the unique identifier given to DTLS sessions using theSDPtls-id attribute[DTLS-SDP]. This field isalready required to be unique. Thus, no two offers or answers from the sameclient will have the same value.¶
A newexternal_session_id extension is added to the TLS or DTLS handshake forconnections that are established as part of the same call or real-time session.This carries the value of thetls-id attribute and provides integrityprotection for its exchange as part of the TLS or DTLS handshake.¶
Theexternal_session_id TLS extension carries the unique identifier that anendpoint selects. When used with SDP, the valueMUST include thetls-idattribute from the SDP that the endpoint generated when negotiating the session.This document only defines use of this extension for SDP; other methods ofexternal session negotiation can use this extension to include a unique sessionidentifier.¶
Theextension_data for theexternal_session_id extension contains anExternalSessionId struct, described below using the syntax defined in[TLS13]:¶
struct { opaque session_id<20..255>; } ExternalSessionId;¶For SDP, thesession_id field of the extension includes the value of thetls-id SDP attribute as defined in[DTLS-SDP](that is, thetls-id-value ABNF production). The value of thetls-idattribute is encoded using ASCII[ASCII].¶
Where RTP and RTCP[RTP] are not multiplexed, it is possible that thetwo separate DTLS connections carrying RTP and RTCP can be switched. This isconsidered benign since these protocols are designed to be distinguishable asSRTP[SRTP] provides key separation. Using RTP/RTCP multiplexing[RTCP-MUX] further avoids this problem.¶
Theexternal_session_id extension is included in a ClientHello, and if theextension is present in the ClientHello, either ServerHello (for TLS and DTLSversions older than 1.3) or EncryptedExtensions (for TLS 1.3).¶
EndpointsMUST check that thesession_id parameter in the extension that theyreceive includes thetls-id attribute value that they received in their peer'ssession description. Endpoints can perform string comparison by ASCII decodingthe TLS extension value and comparing it to the SDP attribute value or by comparingthe encoded TLS extension octets with the encoded SDP attribute value. Anendpoint that receives anexternal_session_id extension that is not identicalto the value that it expectsMUST abort the connection with a fatalillegal_parameter alert.¶
The endpoint performs the validation of theexternal_id_hash extension in addition to the validation required by[FINGERPRINT].¶
If an endpoint communicates with a peer that does not support thisextension, it will receive a ClientHello, ServerHello, or EncryptedExtensions message thatdoes not include this extension. An endpointMAY choose to continue a sessionwithout this extension in order to interoperate with peers that do not implementthis specification.¶
In TLS 1.3, anexternal_session_id extension sent by a serverMUST be sent inthe EncryptedExtensions message.¶
This defense is not effective if an attacker can rewritetls-id values insignaling. Only the mechanism inexternal_id_hash is able to defend againstan attacker that can compromise session integrity.¶
Use of session identifiers does not prevent an attacker fromestablishing two concurrent sessions with different peers andforwarding signaling from those peers to each other. Concatenatingtwo signaling sessions in this way creates two signaling sessions,with two session identifiers, but only the TLS connections from asingle session are established as a result. In doing so, theattacker creates a situation where both peers believe that they aretalking to the attacker when they are talking to each other.¶
In the absence of any higher-level concept of peer identity, anattacker who is able to copy the session identifier fromone signaling session to another can cause the peers to establish adirect TLS connection even while they think that they are connectingto the attacker. This differs from the attack described in theprevious section in that there is only one TLS connection rather thantwo. This kind of attack is prevented by systems that enable peerauthentication, such as WebRTC identity[WEBRTC-SEC] or SIP identity[SIP-ID]; however, these systems do not prevent establishingtwo back-to-back connections as described in the previous paragraph.¶
Use of theexternal_session_id does not guarantee that the identity of thepeer at the TLS layer is the same as the identity of the signaling peer. Theadvantage that an attacker gains by concatenating sessions is limited unless data isexchanged based on the assumption that signaling and TLS peers are the same. If asecondary protocol uses the signaling channel with the assumption that thesignaling and TLS peers are the same, then that protocol is vulnerable to attack.While out of scope for this document, a signaling system that can defend against session concatenationrequires that the signaling layer is authenticated and bound to any TLS connections.¶
It is important to note that multiple connections can be created within the samesignaling session. An attacker might concatenate only part of a session,choosing to terminate some connections (and optionally forward data) whilearranging to have peers interact directly for other connections. It is evenpossible to have different peers interact for each connection. This means thatthe actual identity of the peer for one connection might differ from the peer onanother connection.¶
Critically, information about the identity of TLS peers provides no assurancesabout the identity of signaling peers and does not transfer between TLSconnections in the same session. Information extracted from a TLS connectionthereforeMUST NOT be used in a secondary protocol outside of that connection ifthat protocol assumes that the signaling protocol has the same peers.Similarly, security-sensitive information from one TLS connectionMUST NOT beused in other TLS connections even if they are established as a result of thesame signaling session.¶
When combined with identity assertions, the mitigations in this document ensurethat there is no opportunity to misrepresent the identity of TLS peers. Thisassurance is provided even if an attacker can modify signaling messages.¶
Without identity assertions, the mitigations in this document prevent thesession splicing attack described inSection 4. Defense against sessionconcatenation (Section 5) additionally requires that protocol peers are not able toclaim the certificate fingerprints of other entities.¶
This document registers two extensions in the "TLS ExtensionType Values"registry established in[TLS13]:¶
external_id_hash extension defined inSection 3.2 has beenassigned a code point of 55; it is recommended and is marked as "CH, EE"in TLS 1.3.¶external_session_id extension defined inSection 4.3 hasbeen assigned a code point of 56; it is recommended and is marked as"CH, EE" in TLS 1.3.¶This problem would not have been discovered if it weren't for discussions withSam Scott,Hugo Krawczyk, andRichard Barnes. A solution similar to the one presented here was first proposed byKarthik Bhargavan, who provided valuable input on this document.Thyla van der Merwe assisted with a formal model of the solution.Adam Roach andPaul E. Jones provided significant review and input.¶