RFC 8122

Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)

📅 published March 2017, from ietf

1. Introduction ✨

Okay so bestie, this is RFC 8122, and it's giving connection-oriented media over TLS in SDP 🎀💖 It came out in March 2017, it's a Standards Track document, and it's written by J. Lennox (Vidyo) and C. Holmberg (Ericsson). 🦋 It also obsoletes RFC 4572, which means the older version is officially retired. 💅

Here's the title block in plain terms:

  • Number and title: RFC 8122, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" ✨
  • Authors: J. Lennox (Vidyo) and C. Holmberg (Ericsson) 🫶
  • Category and status: Standards Track 👑
  • Date: March 2017 🌸
  • Obsoletes: RFC 4572 💜
  • Updates: nothing listed here 🙈

This doc is part of the series, so more parts are coming. Stay tuned, bestie! 🧚

Abstract

Okay, so the abstract basically says this: this document explains how to set up secure, connection-oriented media sessions over TLS using SDP 🔐 It gives SDP a new protocol identifier, TCP/TLS, and it defines an SDP fingerprint attribute. That fingerprint identifies the certificate the TLS session will present. 🎀

The whole vibe is that this lets media over TLS get set up securely, as long as the integrity of the session descriptions is assured 🔥 It also says it obsoletes RFC 4572 by clarifying how multiple fingerprints get used. 💅

Status of This Memo

This is an Internet Standards Track document. ✨ It's a product of the IETF and represents IETF community consensus. It got public review and was approved by the IESG. 👑 For more on Internet Standards, check Section 2 of RFC 7841. 🦋

Info about the current status, errata, and feedback is at http://www.rfc-editor.org/info/rfc8122. 💖

Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication. Please review these carefully, because they describe your rights and restrictions. 💅 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License. 🫶

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Changes from RFC 4572 . . . . . . . . . . . . . . . . . .   4
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
  3.1.  SDP Operational Modes . . . . . . . . . . . . . . . . . .   4
  3.2.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .   5
  3.3.  The Need for Self-Signed Certificates . . . . . . . . . .   6
  3.4.  Example SDP Description for TLS Connection  . . . . . . .   6
4.  Protocol Identifiers  . . . . . . . . . . . . . . . . . . . .   7
5.  Fingerprint Attribute . . . . . . . . . . . . . . . . . . . .   7
  5.1.  Multiple Fingerprints . . . . . . . . . . . . . . . . . .   9
6.  Endpoint Identification . . . . . . . . . . . . . . . . . . .  10
  6.1.  Certificate Choice  . . . . . . . . . . . . . . . . . . .  10
  6.2.  Certificate Presentation  . . . . . . . . . . . . . . . .  11
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1. Introduction ✨

Okay bestie, so the Session Description Protocol (SDP) [8] is the general-purpose format for describing multimedia sessions in announcements or invitations. 🎀 A lot of apps want to set up a media stream that uses a connection-oriented transport as part of a session. 💖 RFC 4145, "TCP-Based Media Transport in the Session Description Protocol (SDP)" [7], gives a general way to describe and set up those streams, but the only transport it directly supports is TCP. 🙈

Here's the thing: people in sessions usually want confidentiality, data integrity, and authentication for their media 🔐 So this document extends the TCP-Based Media spec so session descriptions can describe media sessions that use the Transport Layer Security (TLS) protocol [10]. 💅

TLS gives applications a channel with confidentiality and data integrity. ✨ But the TLS spec doesn't say how specific protocols should set up and use that channel. 🦋 In particular, TLS leaves it to the protocols running on top to figure out how to interpret and validate authentication certificates. 🧚 This document covers that for connection-oriented media transport. 🌈

Now the annoying part 😭 Endpoints exchanging media often can't get certificates signed by a well-known root certification authority (CA). CAs usually charge for signed certificates (especially host-based ones), and getting one takes real admin overhead, since the CA has to confirm they're issuing to the right party. 💀 Also, endpoint IP addresses and host names are often dynamic, for example from DHCP, and it's impractical to get a CA-signed certificate valid for the whole length of a DHCP lease. 🙈 For hosts like that, self-signed certificates are usually the only option. 🍓

So this spec defines a way to use self-signed certificates securely, as long as the integrity of the SDP description is assured 🫶 Endpoints can include a secure hash of their certificate, called the "certificate fingerprint", inside the session description. 🔥 If the fingerprint of the offered certificate matches the one in the session description, end hosts can trust even self-signed certificates. 👑

Here's the roadmap ✨ Section 3 covers the problem and threat model. Section 4 gives the basic mechanism for setting up TLS-based connection-oriented media in SDP. Section 5 describes the SDP fingerprint attribute, which (assuming SDP integrity is assured) lets you use self-signed certificates safely. Section 6 covers which X.509 certificates get presented and how they're used in TLS. Section 7 talks about more security considerations. 🌸

1.1. Changes from RFC 4572

This document obsoletes RFC 4572 [20] but stays backwards compatible with older implementations. 💖 Here's what changed from RFC 4572 [20] 👇

  • Clarifies that multiple fingerprint attributes can carry fingerprints (calculated with different hash functions) for a given certificate, and can carry fingerprints for multiple certificates. 🎀
  • Clarifies the fingerprint matching procedure when multiple fingerprints are provided. 🦋
  • Updates the preferred hash function to a stronger cipher suite, and removes the requirement to use the same hash function for calculating a certificate fingerprint and certificate signature. 🔥

2. Terminology ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 💅

3. Overview 🧚

Okay so this section is about the threat model that motivates TLS transport for connection-oriented media streams. 🦋 It also goes deeper into why end systems need to use self-signed certificates. 🫶

3.1. SDP Operational Modes 🌸

There are two main operational modes for multimedia sessions: advertised and offer-answer. 🎀 Advertised sessions are the simpler one. 💖 A server publishes, somehow, an SDP session description of a multimedia session it's making available. 🌈 The classic example is the Session Announcement Protocol (SAP) [15], where SDP session descriptions are periodically sent to a well-known multicast group. 📻

Traditionally these descriptions are for multicast conferences, but unicast sessions are possible too. (Obviously, connection-oriented media can't use multicast. 🙈) Recipients connect to the addresses published in the session description, and they may never have been known to whoever advertised the session. 👑

Alternatively, SDP conferences can run in offer-answer mode [4]. ✨ This mode lets two participants negotiate the session between themselves. 🔥 One participant offers the other a description of the session it wants, from its own perspective, and the other answers with the session it wants from its perspective. 💅 Both participants know about each other in this mode. 🫶 This is the mode the Session Initiation Protocol (SIP) [17] uses. 🦋

3.2. Threat Model 🕵️

okay so, people in multimedia conferences usually want three things for their media sessions: confidentiality, data integrity, and authentication 🎀. This section is basically the villain lineup 💀. It walks through the different kinds of attackers and how they try to ruin those guarantees, then shows how TLS can shut them down 💅.

The simplest attacker just listens in on the traffic for a multimedia session 👀. They could be on the same local-area or wireless network as one of the people in the conference. This kind of attacker doesn't threaten a connection's data integrity or authentication, and almost any operational mode of TLS can keep the media stream confidential 🔒.

Next up is an attacker who can send their own data traffic over the network, but can't change or redirect valid traffic 🙈. In SDP's 'advertised' operational mode, this barely counts as an attack, since media sessions are expected to be started from anywhere on the network 🌈. In SDP's offer-answer mode, though, it's way more serious. The attacker could start a connection to one or both endpoints of a session, pretending to be an endpoint or acting as a man in the middle to snoop on their chats 😭. To stop this, TLS uses endpoint certificates 🦋. As long as the certificates' private keys haven't been compromised, the endpoints have an externally trusted way to validate certificates, most commonly a mutually trusted certification authority 👑. Because each endpoint knows which certificate identity to expect, they can be sure that an attack like this hasn't happened ✨.

Finally, the most dangerous attacker can change or redirect session descriptions, like a compromised or malicious SIP proxy server 💀. TLS itself, and any mechanism that uses it, can't protect an SDP session from this one 🥀. So the SDP description itself has to be secured some other way. SIP, for example, defines how S/MIME [22] can be used to secure session descriptions 🫶.

3.3. The Need for Self-Signed Certificates 🧚

SDP session descriptions are made by any endpoint that needs to join a multimedia session 📞. In lots of cases, like SIP phones, these endpoints have dynamically configured IP addresses and host names, and they have to be deployed with almost zero configuration 🍓. For an endpoint like that, it's basically impossible, for practical purposes, to get a certificate signed by a well-known certification authority 😩.

If two endpoints have no prior relationship, self-signed certificates can't generally be trusted, because nothing guarantees that an attacker isn't running a man-in-the-middle attack 🚨. Here's the plot twist though 🌸: if the integrity of SDP session descriptions can be assured, those descriptions can count as a prior relationship themselves. Certificates can be securely described right inside the session description ✨. This is done by providing a secure hash of a certificate, also called a "certificate fingerprint", as an SDP attribute 💅. This mechanism is described in Section 5 🎀.

3.4. Example SDP Description for TLS Connection 🦋

Figure 1 shows an SDP offer that signals a T.38 fax session over TLS 📠. To keep things short, the main part of the session description is left out of the example, so you only see the 'm' line and its attributes 🙈. (This example is the same as the first one in RFC 4145 [7], except for the proto parameter and the fingerprint attribute.) Check out the later sections for explanations of the TLS-specific attributes in the example 💖.

Note: due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content.
 m=image 54111 TCP/TLS t38
 c=IN IP4 192.0.2.2
 a=setup:passive
 a=connection:new
 a=fingerprint:SHA-256 \
    12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
    3E:5D:49:6B:19:E5:7C:AB:4A:AD
 a=fingerprint:SHA-1 \
    4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

Figure 1: Example SDP Description Offering a TLS Media Stream

4. Protocol Identifiers 🌈

The 'm' line in SDP specifies, among other things, the transport protocol that the media in the session will use 📡. For a discussion of transport protocol identifiers, check out the "Media Descriptions" section of SDP [8] 💅.

This specification defines the protocol identifier 'TCP/TLS' 🎀. It tells you the media will use the Transport Layer Security protocol [10] over TCP 🔐. (Using TLS over other transport protocols isn't covered in this document.) The 'TCP/TLS' identifier only describes the transport protocol, not the upper-layer protocol 🍰. So an 'm' line that specifies 'TCP/TLS' MUST further qualify the protocol using an fmt identifier to indicate the application running over TLS 👑.

Media sessions described with this identifier follow the procedures defined in RFC 4145 [7] 🦋. They also use the SDP attributes defined in that specification, 'setup' and 'connection' ✨.

5. Fingerprint Attribute 💜

Parties to a TLS session show who they are by presenting authentication certificates during the TLS handshake 🤝. Authentication certificates are X.509 [2] certificates, as profiled by RFCs 3279 [5], 5280 [11], and 4055 [6] 📜.

To tie media streams to connections and stop unauthorized barge-in attacks on those media streams, endpoints MUST provide a certificate fingerprint 🚫. If the X.509 certificate presented for the TLS connection matches the fingerprint in the SDP, the endpoint can be confident that the author of the SDP is really the one who started the connection 💖.

A certificate fingerprint is a secure one-way hash of the Distinguished Encoding Rules (DER) form of the certificate 🔑. (Certificate fingerprints are widely supported by tools that handle X.509 certificates. For example, the command "openssl x509 -fingerprint" makes the command-line tool of the openssl package print a certificate fingerprint, and the certificate managers for Mozilla and Internet Explorer show them when you look at the details of a certificate 🛠️.)

A fingerprint shows up in SDP as an attribute (an 'a' line) 🌸. It has the name of the hash function used, followed by the hash value itself. The hash value is written as a sequence of uppercase hexadecimal bytes, separated by colons. The number of bytes is set by the hash function 🔢. (This is the syntax used by openssl and by the browsers' certificate managers. It's different from the syntax used for hash values in things like HTTP digest authentication [24], which uses unseparated lowercase hexadecimal bytes. Consistency with other applications of fingerprints was considered more important 🙈.)

The formal syntax of the fingerprint attribute is given in Augmented Backus-Naur Form [9] in Figure 2. This syntax extends the BNF syntax of SDP [8] 📐.

   attribute              =/ fingerprint-attribute

   fingerprint-attribute  =  "fingerprint" ":" hash-func SP fingerprint

   hash-func              =  "sha-1" / "sha-224" / "sha-256" /
                             "sha-384" / "sha-512" /
                             "md5" / "md2" / token
                             ; Additional hash functions can only come
                             ; from updates to RFC 3279

   fingerprint            =  2UHEX *(":" 2UHEX)
                             ; Each byte in upper-case hex, separated
                             ; by colons.

   UHEX                   =  DIGIT / %x41-46 ; A-F uppercase

Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute

Following RFC 3279 [5] as updated by RFC 4055 [6], the defined hash functions are 'SHA-1' [1] [16], 'SHA-224' [1], 'SHA-256' [1], 'SHA-384' [1], 'SHA-512' [1], 'MD5' [13], and 'MD2' [23], with 'SHA-256' preferred 🌟. A new IANA registry, named "Hash Function Textual Names" and specified in Section 8, allows new tokens to be added in the future. But they may only be added if they're included in RFCs that update or obsolete RFC 3279 [5] 📋.

Implementations compliant with this specification MUST NOT use the MD2 and MD5 hash functions to calculate fingerprints, or to verify received fingerprints that were calculated using them 🚷.

Note: The MD2 and MD5 hash functions are listed in this specification so that implementations can recognize them. Implementations that log unused hash functions might log occurrences of these algorithms differently from unknown hash algorithms 📝.

The fingerprint attribute can be either a session-level or a media-level SDP attribute. If it's a session-level attribute, it applies to all TLS sessions that don't have a media-level fingerprint attribute defined 🧩.

5.1. Multiple Fingerprints 🎀

Multiple SDP fingerprint attributes can be tied to one 'm' line 🍓. This can happen if several fingerprints were calculated for one certificate using different hash functions. It can also happen if one or more fingerprints for multiple certificates have been calculated 👯. This might be needed if multiple certificates will be used for media tied to an 'm' line, like when separate certificates are used for RTP and the RTP Control Protocol (RTCP), or when it isn't known which certificate will be used at the time the fingerprints are exchanged 🤷‍♀️. In those cases, one or more fingerprints MUST be calculated for each possible certificate 💅.

An endpoint MUST, as a minimum, calculate a fingerprint using both the 'SHA-256' hash function algorithm and the hash function used to generate the signature on the certificate, for each possible certificate 🔐. Including the hash from the signature algorithm keeps things interoperable with strict implementations of RFC 4572 [20] 🫶. Either of these fingerprints MAY be omitted if the endpoint includes a hash with a stronger hash algorithm that it knows the peer supports, if it's known that the peer doesn't support the hash algorithm, or if local policy requires stronger algorithms 💪.

If fingerprints for multiple certificates are calculated, the same set of hash functions MUST be used to calculate fingerprints for each certificate associated with the 'm' line 🧁.

An endpoint MUST select the set of fingerprints that use its most preferred hash function (out of those offered by the peer), and verify that each certificate used matches one fingerprint from that set ✅.

If a certificate doesn't match any fingerprint in that set, the endpoint MUST NOT establish the TLS connection 🚫💀.

Note: The SDP fingerprint attribute doesn't contain a reference to a specific certificate. Endpoints need to compare the fingerprint with a certificate hash in order to look for a match 🔍.

6. Endpoint Identification 🌷

6.1. Certificate Choice

okay so an X.509 certificate basically ties an identity to a public key 🔐 If the SDP describing your TLS session travels over something with integrity protection, then a certificate asserting any syntactically valid identity MAY be used 💅 For example, an SDP description sent over HTTP/TLS [14] or secured by S/MIME [22] MAY assert any identity in the certificate securing the media connection.

Security protocols that only give you hop-by-hop integrity protection (like the SIPS scheme [17] or SIP over TLS) are considered sufficiently secure to allow the mode where any valid identity is accepted 🦋 However, go check Section 7 for the security implications of that, because it's a whole thing 👀

Now, if the SDP is not integrity-protected, the certificate provided for a TLS connection MUST certify an appropriate identity for the connection 🎀 In these scenarios, the certificate presented by an endpoint MUST certify either the SDP connection address or the identity of the creator of the SDP message, as follows:

  • If the connection address for the media description is specified as an IP address, the endpoint MAY use a certificate with an iPAddress subjectAltName that exactly matches the IP in the connection-address in the session description's 'c' line. Similarly, if the connection address for the media description is specified as a fully qualified domain name, the endpoint MAY use a certificate with a dNSName subjectAltName matching the specified 'c' line connection-address exactly. (Wildcard patterns MUST NOT be used.)
  • Alternately, if the SDP session description of the session was transmitted over a protocol (such as SIP [17]) for which the identities of session participants are defined by Uniform Resource Identifiers (URIs), the endpoint MAY use a certificate with a uniformResourceIdentifier subjectAltName corresponding to the identity of the endpoint that generated the SDP. The details of what URIs are valid are dependent on the transmitting protocol. (For more details on the validity of URIs, see Section 7.

Identity matching is done using the matching rules from RFC 5280 [11] 🧚 If there's more than one identity of a given type in the certificate (like more than one dNSName), a match on any one of them is good enough ✨ And to make certificate caches work (more on that in Section 7), endpoints SHOULD consistently provide the same certificate for each identity they support 🌸

6.2. Certificate Presentation

In every case, an endpoint acting as the TLS server (aka the one taking the setup:passive role, in connection-oriented media terms) MUST present a certificate during TLS initiation, following the rules from Section 6.1 💖 If the certificate doesn't match the original fingerprint, the client endpoint MUST terminate the media connection with a bad_certificate error 🙈

If the SDP offer/answer model [4] is in use, the client (the endpoint with the setup:active role) MUST also present a certificate following the rules of Section 6.1 🫶 The server MUST request a certificate. If the client doesn't provide one, or the certificate doesn't match a provided fingerprint, the server endpoint MUST terminate the media connection with a bad_certificate error 😭

Heads up, though: with offer/answer, it's possible for a media connection to outrace the answer back to the offerer 🏎️ So if the offerer has offered a setup:passive or setup:actpass role, it MUST (as specified in RFC 4145 [7]) start listening for an incoming connection as soon as it sends its offer. But it MUST NOT assume the data over the TLS connection is valid until it has received a matching fingerprint in an SDP answer 🛑 If the fingerprint doesn't match the client's certificate once it finally arrives, the server endpoint MUST terminate the media connection with a bad_certificate error, same as the previous paragraph said 💅

If offer/answer isn't being used (like if the SDP was sent over the Session Announcement Protocol [15]), there's no secure channel for clients to share certificate fingerprints with servers 🥺 In that case, servers MAY request client certificates, which SHOULD be signed by a well-known certification authority, or MAY allow clients to connect without a certificate 🌈

7. Security Considerations ✨

Okay bestie, this entire document is about security 🔥 The problem it solves is covered in Section 1, and you can get a high-level overview in Section 3. For security stuff that applies to SDP in general, check out the SDP specification [8] 📖

Offering a TCP/TLS connection in SDP (or agreeing to one in the SDP offer/answer mode) does not create an obligation for an endpoint to accept any TLS connection with the given fingerprint 🙅‍♀️ Instead, the endpoint must go through the standard TLS negotiation procedure to make sure the TLS stream cipher and MAC algorithm that get picked actually meet the security needs of the higher-level application 🔐 (For example, an offered stream cipher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected in almost every application scenario 💀)

Like all SDP messages, the ones describing TLS streams ride inside an encapsulating application protocol (e.g., SIP, Media Gateway Control Protocol (MGCP), etc.) 🎀 The encapsulating protocol is responsible for keeping the SDP security descriptions intact. So the application protocol SHOULD either use its own security mechanisms (e.g., secure multiparts) or, alternatively, lean on a lower-layer security service (e.g., TLS or IPsec) 🛡️ That security service SHOULD provide strong message authentication as well as effective replay protection 💜

But integrity protection isn't always possible 😬 For those cases, end systems SHOULD keep a cache of certificates that other parties have previously presented using this mechanism 🗂️ If it's possible, users SHOULD be notified when an unsecured certificate from a previously unknown end system shows up, and SHOULD be strongly warned if a different unsecured certificate comes from a party they've talked to before 🚨 This way, even without integrity protection for SDP, this document's mechanism is equivalent to the Secure Shell (SSH) protocol [18]. SSH is vulnerable to man-in-the-middle attacks when two parties first communicate, but it can detect ones that happen later on 🕵️‍♀️ (Note that a precise definition of the "other party" depends on the application protocol carrying the SDP message.) Users SHOULD NOT, however, in any circumstances be notified about certificates described in SDP descriptions sent over an integrity-protected channel 🙅‍♀️

To help with interoperability and deployment, security protocols that only give hop-by-hop integrity protection (e.g., the SIPS scheme [17], SIP over TLS) are considered sufficiently secure to allow the mode where any syntactically valid identity is accepted in a certificate 🦋 This decision was made because SIPS is currently the integrity mechanism most likely to be used in deployed networks in the short to medium term 📡 But in this mode, SDP integrity is vulnerable to attacks by compromised or malicious middleboxes, e.g., SIP proxy servers 😱 End systems MAY warn users about SDP sessions that are secured only hop-by-hop, and definitions of media formats running over TCP/TLS MAY specify that only end-to-end integrity mechanisms be used 🌸

Depending on how SDP messages are transmitted, it isn't always possible to tell whether a subjectAltName in a remote certificate is actually expected for the remote party 🤔 Call forwarding, third-party call control, or session descriptions generated by endpoints controlled by the Gateway Control Protocol [21] can all make it hard in SIP to figure out which entity should have generated a remote SDP response 📞 So in general, when you're not using authenticity and integrity protection on the SDP descriptions, a certificate transmitted over SIP SHOULD assert the endpoint's SIP Address of Record as a uniformResourceIndicator subjectAltName 🪪 And when an endpoint gets a certificate over SIP asserting an identity (including an iPAddress or dNSName identity) other than the one it placed or received the call with, it SHOULD alert the user and ask for confirmation 🙋‍♀️ This applies whether the certificates are self-signed or signed by certification authorities. A certificate for "sip:bob@example.com" may be legitimately signed by a certification authority, but it may still not be acceptable for a call to "sip:alice@example.com" 💅 (This issue isn't specific to this spec, by the way. The same consideration applies to S/MIME-signed SDP carried over SIP 🫶)

This document does not define a mechanism for securely transporting RTP and RTCP packets over a connection-oriented channel 🎶 Check out RFC 7850 [19] for more details 📚

TLS isn't always the most appropriate choice for secure connection-oriented media 🤷‍♀️ In some cases, a higher- or lower-level security protocol may be appropriate.

This document improves security over RFC 4572 [20] ✨ It updates the preferred hash function from SHA-1 to SHA-256 and deprecates the usage of the MD2 and MD5 hash functions 🗑️ Slay.

By clarifying how multiple fingerprints are used and handled, the document also enables hash agility and incremental deployment of newer, more secure hash functions 🌈👑

8. IANA Considerations ✨

IANA has updated the registrations from RFC 4572 [20] so they point to this spec, which is super helpful for anyone tracing things back 🦋

This document defines an SDP proto value called TCP/TLS 💖. You'll find its format in Section 4. IANA registered it in the "proto" registry, which lives inside the "Session Description Protocol (SDP) Parameters" registry.

This document also defines an SDP attribute that works at both the session and media level, called fingerprint 🎀. Its format is in Section 5. IANA registered it in the "att-field (both session and media level)" registry, also inside "Session Description Protocol (SDP) Parameters".

Okay, now the SDP spec [8] says that anyone defining a new proto value, like TCP/TLS here, has to spell out the rules for how their media format (fmt) namespace gets managed 📚. For TCP/TLS, new formats SHOULD come with an associated MIME registration 💅. Reusing an existing MIME subtype for the format is encouraged 🌸. If there's no MIME subtype yet, it is RECOMMENDED to register a suitable one through the IETF process [12], by producing or referencing a Standards Track RFC that defines the transport protocol for that format 🫶.

IANA also updated the "Hash Function Textual Names" registry (originally made in [20]) so it refers to this document ✨.

The names of the hash functions used for certificate fingerprints are registered by IANA 🔐. Hash functions MUST be defined by Standards Track RFCs that update or obsolete RFC 3279 [5] 👑.

When you register a new hash function textual name, you MUST provide the following info 😭:

  • The textual name of the hash function.
  • The Object Identifier (OID) of the hash function as used in X.509 certificates.
  • A reference to the Standards Track RFC that updates or obsoletes RFC 3279 [5] and defines how the hash function is used in X.509 certificates.

Table 1 has the starting values for this registry 🍓.

     +--------------------+------------------------+-----------+
     | Hash Function Name |          OID           | Reference |
     +--------------------+------------------------+-----------+
     |       "md2"        |   1.2.840.113549.2.2   |  RFC 3279 |
     |       "md5"        |   1.2.840.113549.2.5   |  RFC 3279 |
     |      "sha-1"       |     1.3.14.3.2.26      |  RFC 3279 |
     |     "sha-224"      | 2.16.840.1.101.3.4.2.4 |  RFC 4055 |
     |     "sha-256"      | 2.16.840.1.101.3.4.2.1 |  RFC 4055 |
     |     "sha-384"      | 2.16.840.1.101.3.4.2.2 |  RFC 4055 |
     |     "sha-512"      | 2.16.840.1.101.3.4.2.3 |  RFC 4055 |
     +--------------------+------------------------+-----------+

          Table 1: IANA Hash Function Textual Name Registry

9. References 📖

9.1. Normative References

9.2. Informative References

Acknowledgments 🫶

This document got significant contributions from Cullen Jennings, Paul Kyzivat, Roman Shpount, and Martin Thomson 💜. Elwyn Davies did the Gen-ART review of the document 🌈. Thank you all, you're literally the best 👑.

Authors' Addresses 🦋

Jonathan Lennox Vidyo

Email: jonathan@vidyo.com

Christer Holmberg Ericsson

Email: christer.holmberg@ericsson.com

📦 where this page comes from