]> 8x8, Inc / Jitsi

jonathan.lennox@8x8.com

ART sdp fingerprints raw public keys This document defines how to negotiate the use of raw keys for TLS and DTLS with the Session Description Protocol (SDP). Raw keys are more efficient than certificates for typical uses of TLS and DTLS negotiated with SDP, without loss of security. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction When a Transport-Layer Security (TLS) or Datagram Transport-Layer Security (DTLS) connection is negotiated using the Session Description Protocol , certificates are validated using certificate fingerprints specified in the SDP , rather than by any information carried in the certificate. Typically these certificates are self-signed. The only information carried in these certificates that is used by the process are the public keys; the rest of the information is useless. This other information can be large, and once post-quantum public keys are needed, the self-signed signature in particular will be very large. TLS and DTLS now support using raw keys, rather than X.509 certificates, in circumstances such as these . This document defines how such raw key certificates can be negotiated in SDP.

Certificate overheads As an illustration of the overheads of self-signed certificates, the self-signed certificate in a WebRTC DTLS handshake negotiated by a recent version of Chrome is 282 bytes, of which only 91 bytes are the public key (the subjectPublicKeyInfo in id-ecPublicKey format ).

• TODO: calculate equivalent figures for a PQ X.509 certificate

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Protocol

The "raw-key-fingerprint" attribute. This document defines an SDP attribute, "raw-key-fingerprint". Its syntax is the same as the "fingerprint" attribute defined in , as specified in .

ABNF for the raw-key-fingerprint attribute

A raw key fingerprint is a secure one-way hash of the distinguished Encoding Rules (DER) form of the subjectPublicKeyInfo (SPKI) of the raw key, in the form specified in when the appropriate certificate_type value is RawPublicKey.

• The subjectPublicKeyInfo structure encodes the key type as well as its value, so the meaning of the key is unambiguous.

The one-way hash is performed using the hash function specified in the 'hash-func' field, which MUST be a hash function from the IANA table "Hash Function Textual Names" defined in , with 'SHA-256' preferred. As in , the hash functions 'MD2' and 'MD5' MUST NOT be used either for generating or verifying raw key fingerprints. Also as in , the raw key fingerprint is represented as upper-case hexadecimal bytes, separated by colons. The number of bytes is defined by the hash function.

SDP Offer/Answer procedures In SDP offer/answer , if the endpoint creating an SDP offer wishes to use raw public keys for TLS or DTLS, the offerer includes an SDP "raw-key-fingerprint" attribute describing its raw public key at the session level or the appropriate media levels. In an initial offer, it SHOULD also include a valid SDP "fingerprint" attribute for a self-signed X.509 certificate as defined in , unless it knows for certain through out-of-band means that the peer that will be performing the answer definitely supports raw keys. In its answer, the answerer then includes a "raw-key-fingerprint" with the fingerprint of its own raw public key. It MAY omit the SDP "fingerprint" attribute. Either the offerer or the answerer MAY include multiple "raw-key-fingerprint" attributes, for example if they want to provide a fingerprint hashed with multiple different hash functions, or if the media negotiated by the offer/answer might end up at one of several different endpoints which have different public keys. In subsequent offers, an offerer MUST send the "raw-key-fingerprint" value of the raw public key that it used in the TLS/DTLS session as long as that TLS/DTLS session remains. It MAY omit "fingerprint" attributes, and "raw-key-fingerprint" attributes for unused raw public keys, when the state of the connection attribute is "existing" and the value of the raw key fingerprint is unchanged. If it sends an offer with "connection:new", or the fingerprint changes, it SHOULD include both "fingerprint" and "raw-key-fingerprint" attributes under the same rules as it would use for an initial offer.

TLS/DTLS procedures for SDP Offer/Answer connections. The TLS client and server roles are negotiated for the session following the mechanisms defined in ; the endpoint in the "active" role will be the client. If raw keys have been offered in SDP, the initial ClientHello of the transaction MUST include both a ClientCertTypeExtension and a ServerCertTypeExtension including RawPublicKey as one of the types. If the client has already seen its peer's offer or answer including a "raw-key-fingerprint" SDP attribute, this MAY be the only type listed in the extensions; otherwise, if the client's offer or answer included a "fingerprint" attribute, the extension lists MUST also include X509. The server's ServerHello MUST then send a ClientCertTypeExtension and a ServerCertTypeExtension listing RawPublicKey as the type, as well as its own raw public key in the Certificate and a certificate request for the client. The client then sends its own raw key. Both client and server MUST verify that the raw key fingerprint signaled in SDP matches that of the raw public key received over TLS or DTLS, and terminate the TLS or DTLS connection with a bad_certificate error if it does not. Note that in some circumstances a ClientHello or ServerHello may arrive before an SDP answer; application data MUST NOT be sent over the TLS connection until the raw key fingerprint has been received and validated. If multiple raw key fingerprints are present, a certificate is valid if at least one raw key fingerprint matches the raw key using a hash function that the entity considers sufficiently secure. If a remote SDP offer or answer does not contain a "raw-key-fingerprint" attribute, or TLS does not contain a CertTypeExtension containing RawPublicKey, then the peer does not support (or does not wish to use) raw keys in fingerprints, and the standard procedures of MUST be used instead. If an SDP offer or answer is inconsistent with TLS messaging (e.g., a CertType of X509 is provided when SDP contained only "raw-key-fingerprint" attributes, or a CertType of RawPublicKey when SDP contained only "fingerprint" attributes), then the TLS connection MUST be terminated with a bad_certificate error.

• TODO: Do we want to support asymmetric cases, where one endpoint is willing to receive raw keys but cannot present one? This would be relatively straightforward for answerers, but would require an additional SDP attribute for an offerer to indicate its willingness to receive a raw key.

SDP Advertisements Older uses of SDP (such as RTSP ) use advertised SDP rather than offer/answer. In this mode, an entity presents an SDP description that other endpoints can then connect to freely, without providing a matching SDP description. When raw key fingerprints are used in this case, the SDP describes the TLS server. Clients connect using the standard TLS client/server procdure. Clients MUST validate that the raw key provided in the connection matches the raw key fingerprint in the SDP.

Possible follow-ons Two protocols have defined mechanisms by which SDP fingerprints can be signed to ensure their end-to-end security: PASSPorT and WebRTC Identity Providers . Unfortunately, the latter has seen no deployment as far as the author is aware; and the former, while widely implemented to authenticate calling party telephone numbers, has not seen much if any adoption of the mode that signs certificate fingerprints. Nonetheless, both of these mechanisms could easily be extended so as to secure raw key fingerprints as well.

• TODO: Should we actually define these extensions? Is it worth the trouble?

Design alternatives As an alternative to a new "a=raw-key-fingerprint" attribute, an alternative signaling mechanism would be to define new values for the "hash-func" field of the existing "a=fingerprint" attribute, e.g. the "hash-func" value "raw-key-SHA-256" in an "a=fingerprint" attribute would mean to use the mechanisms defined in this document. This would have the advantage of allowing existing mechanisms that use and transport "a=fingerprint" values (both existing code, and mechanisms such as those discussed in ) to support the raw key mechanism, without requiring new code to be written or new extension points to be defined. This would be at the cost of somewhat less clean signaling; and in particular, the definition of the "Hash function textual names" IANA registry would get complicated. This would require discussion during the consensus process as this mechanism is standardized.

Security Considerations The security of a TLS or DTLS connection negotiated using the mechanisms defined in this document is identical to that of a connection negotiated via the mechanism in . All the security considerations of that document also apply to this one. As identity information is normally not used from the SDP-negotiated certificates, this mechanism should have identical security properties to that of . As with fingerprints, the mechanism in this document is vulnerable to an attacker who can modify the signaled fingerprints and launch a meddler-in-the-middle attack. See for various proposed methods to prevent this attack.

IANA Considerations This document defines an SDP session and media-level attribute: 'raw-key-fingerprint'. Its format is defined in Section . This attribute should registered by IANA under the "att-field (both session and media level)" registry within the "Session Description Protocol (SDP) Parameters" registry.

References Normative References This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This 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. This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints. This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK] This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. [STANDARDS-TRACK] Informative References This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326. RTSP is an application-layer protocol for the setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".

Acknowledgments Thanks to Martin Thomson and Harald Alvestrand for their comments on this document.