Representing IP addresses in TLS Server Name Indication (SNI)

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 28 January 2023.¶

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 (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

TLS [RFC8446] clients often need to send a Server Name Indication (SNI) extension [RFC6066], Section 3 as part of their ClientHello message. This helps servers select a certificate to return that includes a subjectAltName which includes the SNI value. Without SNI, multi-tenant services need need as many IP addresses as server certificates, which is not generally a problem with IPv6, but is complicated by, as well as contributes to, address scarcity in IPv4.¶

Certificate subjectAltName (SAN) [RFC5280], Section 4.2.1.6 values can encode IP addresses (with a defined form for "iPAddress" that encodes both IPv4 and IPv6 addresses as a sequence of octets). However, the ServerName structure for SNI only defines "host_name" as a "name_type" and encoding the hostname in Hostname, and it does not specify a way to encode IP addresses.¶

The lack of support for IP addresses in SNI values is less problematic in the case where a client is connecting to the IP address that it expects to see in the certificate. However, some specifications such as [I-D.draft-ietf-add-ddr] have clients require that a particular IP address is present in the SNI while connecting to a different IP address.¶

This specification does NOT change any behaviors for how clients to validate certificates.¶

2. Notational Conventions

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 [RFC2119].¶

3. Indicating IP Addresses in SNI

TLS clients connecting to a server and expecting to find a given IP address in a certificate subjectAltName MUST encode the iPAddress they expect to find in the certificate into the SNI HostName field. This encoding is done by converting the IP address into its reverse DNS address, as also done in [RFC8738].¶

Note that this encoding only applies to how IP addresses are represented in SNI and does *NOT* change how IP addresses are represented in certificate SANs.¶

Clients encode IPv6 "ip6.arpa" [RFC3596] names, using a reverse mapping of the IP address as the HostName field. For example, if the IP address being validated is 2001:db8::1, the SNI HostName field whould contain "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa".¶

Clients encode IPv4 addresses as "in-addr.arpa" [RFC1034] names, using a reverse mapping of the address octets. For example, if the IPv4 address being validated is 192.0.2.7, the SNI HostName field would contain "7.2.0.192.in-addr.arpa".¶

Servers receiving a SNI HostName field with one of these ".arpa" names implement this specification by returning a certificate with a subjectAltName containing the corresponding IP address as an iPAddress, when such a certificate is available. Servers MUST ignore malformed ip6.arpa and in-addr.arpa SNI values, such as those which do not contain 34 or 6 labels, respectively. In the corner-case where a server has both a certificate with an iPAddress SAN matching the supplied SNI as well as a dNSName SAN that matches the .arpa SNI string, the server SHOULD return the former (the cert corresponding to the iPAddress SAN).¶

Note that there is no way to represent IP address prefixes in certificates subjectAltNames.¶

4. Rejected Alternatives

(Note to editor: this section is to be removed moved to an appendix or removed prior to publication.)¶

Two other approaches have been considered but rejected.¶

  struct {
      NameType name_type;
      select (name_type) {
          case host_name: HostName;
          case ip_address: IPAddress;
      } name;
  } ServerName;
  enum {
      host_name(0), ip_address(1), (255)
  } NameType;
  opaque HostName<1..2^16-1>;
  opaque IPAddress<1..2^8-1>;

5. IANA Considerations

No IANA registry changes are needed with this approach?¶

(TODO: Do we need to update anything to indicate this special use of in-addr.arpa and ip6.arpa?)¶

(The first other alternative might need a new registry if we decided to take that approach.)¶

6. Security Considerations

Overloading the in-addr.arpa and ip6.arpa names has potential for confusion if there are implementations that have odd behaviors here, or which try and use certificates with dNSName subjectAltNames containing those as hostnames.¶

As an example, some middleboxes (such as security appliances) may use the SNI value as a hostname to resolve and direct connections towards and this may have odd results when it is a .arpa address.¶

CAB Forum is considering updating their guidance to clarify that the issuance of certificates on those names is prohibited [cabforum.servercert.153].¶

General issues may exist with using IP addresses in certificate subjectAltNames, but a detailed analysis of this is outside the scope of this specification. Beyond not supporting IP addresses in SNI fields, there may be issues in other areas:¶

• The lifespan of IP addresses may be highly variable. While the ownership of some IP addresses (such as well-known DNS public resolvers) may be quite static, many service providers issue IP addresses with very short lifetimes. Clients may rotate their IPv6 privacy addresses [RFC8981] every few hours, as a very widespread example.¶
• There is no way to use CAA records [RFC8659] to constrain certificates on IP addresses. While it may be wortth considering supporting CAA records within the in-addr.arpa and ip6.arpa name spaces to allow network operators to constrain certificate issuance on IP addresses under their control, that is outside of the scope of this specification.¶

Note that certificate Name Constraints [RFC5280], Section 4.2.1.10 do support IP addresses, but it is unclear how widely this is implemented by client validators. Private certificate authorities may wish to consider using Name Constraints to only allow issuance of IP address certificates to organizational IP space.¶

7. Privacy Considerations

The SNI extension is sent in cleartext on the network, and thus visible to a passive observer. Using [I-D.draft-ietf-tls-esni] Encrypted Client Hello to protect the SNI may help.¶

Similar issues that exist with hostname based SNI values (with being able to perform tracking and correlation) may exist with IP addresses in SNI as well.¶

There may also be protocol-specific risks when desired IP addresses are sent in-the-clear as SNI.¶

Note that in many cases, observers will also be able to see the IP address as the destination endpoint of connections.¶

8. Acknowledgments

Thank you to Kyle Rose, Jon Reed, Ben Kaduk, and others who provided valuable input towards this draft.¶

Authors' Addresses