TLS 1.3 and Certificate Identity for the Session Initiation Protocol

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 5 May 2027.¶

Copyright Notice

Copyright (c) 2026 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 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

1. Introduction

The use of TLS with SIP is defined principally by [RFC3261], which introduced TLS as a SIP transport, and by [RFC5922], which specifies how the identity of a SIP domain is represented in a certificate and matched by a peer. Both predate the current state of TLS and of certificate identity practice, and in two respects they now state requirements that cannot be followed.¶

[RFC3261] requires support for a specific cipher suite that uses static RSA key exchange. That suite does not exist in TLS 1.3 [RFC9846], and static RSA key exchange was removed from the protocol, so an implementation that supports only TLS 1.3 cannot conform to the requirement. Recommendations for the secure use of TLS are now maintained in [RFC9325], and earlier TLS versions have been deprecated [RFC8996].¶

[RFC5922] prefers that a SIP domain identity be carried in a subjectAltName entry of type uniformResourceIdentifier containing a "sip" URI, accepts a dNSName entry only when no matching URI entry is present, and permits the Subject common name to be examined when no subjectAltName extension appears at all. [RFC9525], which obsoletes the general service identity guidance that [RFC5922] was written against, establishes that service identity may be expressed only in the subjectAltName extension, that the common name is no longer valid for this purpose, and that the identifiers it covers are domain names, IP addresses, and SRV service names. Deployed general purpose TLS implementations verify dNSName entries and commonly do not examine URI entries at all.¶

There is also a reason not to leave these updates for later. Post-quantum key agreement is defined for TLS 1.3 and not for earlier versions, and [NIST.IR.8547] deprecates the key agreement algorithms in current use after 2030. SIP signaling carries call records whose confidentiality matters for years, and where SRTP keys travel in the session description it carries those too. A SIP implementation that cannot negotiate TLS 1.3 cannot protect any of that against later decryption. Making TLS 1.3 the baseline for SIP is the one change SIP needs in order to follow the transition; the algorithms themselves are selected in TLS, and this document says nothing about them.¶

This document updates [RFC3261] and [RFC5922] accordingly. It does not otherwise change the use of TLS with SIP, and it does not address the use of certificates to convey authority over telephone numbers [RFC8226].¶

2. Conventions

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.¶

3. Updates to RFC 3261: TLS Versions and Cipher Suites

Section 26.2.2 of [RFC3261] requires that proxy servers, redirect servers, and registrars support TLS and implement the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. That requirement is removed by this document.¶

An implementation that supports TLS as a SIP transport MUST support TLS 1.3 [RFC9846] and SHOULD negotiate it in preference to earlier versions. TLS 1.2 [RFC5246] MAY be supported for interoperability with deployed implementations. TLS versions 1.0 and 1.1 are already deprecated for [RFC3261] by [RFC8996], which updates it for that purpose, and MUST NOT be used.¶

Cipher suite selection follows [RFC9325]. Where TLS 1.2 is used, a cipher suite providing ephemeral key exchange and authenticated encryption MUST be selected; static RSA key exchange MUST NOT be used, as it provides no forward secrecy.¶

This document specifies no mandatory cipher suite. Interoperability at the cipher suite level is provided by TLS 1.3, which defines a small mandatory set within the protocol itself, and by the recommendations of [RFC9325] for earlier versions.¶

This document specifies no key agreement group or signature algorithm; they are selected by TLS negotiation. The certificates used for SIP over TLS where telephone number authority is involved are the subject of [I-D.wendt-stir-secure-sip-rtp].¶

4. Updates to RFC 5922: Certificate Identity for SIP Domains

This section replaces the rules in [RFC5922] for representing a SIP domain identity in a certificate, for finding such identities in a presented certificate, and for comparing them against the domain a peer intended to reach. The comparison model of [RFC5922] is retained, as are its procedures for what a peer does with the result of a comparison; only the identifiers used and the manner of comparing them are changed.¶

5. Requesting the Use of TLS

Two mechanisms exist for requesting that a SIP request be carried over TLS, and a third is deprecated. Deployments continue to combine them, which produces requests whose intent is ambiguous.¶

The "transport=tls" URI parameter MUST NOT be used to request TLS. Section 26.2.2 of [RFC3261] deprecated it, and [RFC5630] confirms that deprecation; the parameter remains in the grammar of [RFC3261] but carries no meaning for this purpose. A request is not carried over TLS by virtue of the parameter being present, and a peer receiving it is under no obligation as a result.¶

A SIPS URI in the Request-URI requests that the request be carried over TLS on every hop toward the target, as specified in [RFC5630]. Where that cannot be achieved, the request fails rather than being delivered without TLS. The requirement propagates: the Contact header field must also carry a SIPS URI, and subsequent requests within the dialog are subject to the same condition. A SIPS URI is therefore appropriate where a deployment requires TLS on every hop and prefers failure to insecure delivery.¶

A SIP URI carried over a TLS connection requests nothing about any other hop. The connection on which the request is carried is protected, and any requirement that other hops be protected comes from the local policy of the deployment or from a profile that specifies it, rather than from the URI. As stated in [RFC5630], this is the appropriate construction where TLS is used on a hop without invoking the requirements the SIPS scheme places on the remainder of the path.¶

A deployment MUST use one of these two constructions consistently. The scheme of the URI being resolved, the procedure used to resolve it as described in [RFC3263], and the scheme used in the Contact and Record-Route header fields refer to the same mechanism, and a request in which they differ is ambiguous. In particular, resolving a SIP URI using the service label defined for the SIPS scheme, or populating a SIPS URI while carrying the request over an unprotected hop, are both inconsistent.¶

Where a profile requires that TLS be used on a given interface, that requirement is stated by the profile and applies whether or not a SIPS URI is used.¶

6. Interaction with Resolution

Where a SIP URI is resolved to a host through NAPTR and SRV records [RFC3263], the name verified against the certificate is the domain of the URI that was resolved, and not the target name returned by the SRV record. This preserves the property established in [RFC5922] that the identity verified is the identity to which the request was addressed.¶

Verifying the SRV target name instead would allow a party able to influence resolution to direct a connection to a host holding a valid certificate for an unrelated domain, and to have that certificate accepted.¶

7. Security Considerations

The changes in this document narrow the set of identifiers a peer will accept as a SIP domain identity. Removing the Subject common name removes a source of identity that has no defined syntax for this purpose and that issuers populate inconsistently. Requiring a dNSName entry aligns SIP with the identifier type that deployed TLS implementations verify, reducing the likelihood that an implementation accepts a certificate on the basis of an identifier its peer did not intend as authoritative.¶

Removing the mandatory cipher suite of [RFC3261] removes a requirement to implement static RSA key exchange, which provides no forward secrecy. A recorded session protected by such a suite can be decrypted by an adversary that later obtains the server private key.¶

The considerations of [RFC9325] and [RFC9525] apply to implementations of this document.¶

8. IANA Considerations

This document has no IANA actions.¶

9. Acknowledgments

Thanks to Russ Housley for his review.¶

10. References

Author's Address