Representing IP addresses in TLS Server Name Indication (SNI)

Introduction TLS clients often need to send a Server Name Indication (SNI) extension 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) 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 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.

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 .

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

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.

Alternative: New NameType One approach would be to introduce ip_address as a new name_type (or perhaps one for each of IPv6 and IPv4). For example, something like:

; opaque IPAddress<1..2^8-1>; ]]> While the cleanest approach, discussions with TLS library implementation maintainers indicate that this would be disruptive and have wide-reaching impact to long-stable APIs. It is likely that this extension point ossified long ago, and that middle-boxes and other software would also have problems here, as the SNI value is visible in-the-clear and some devices are known to inspect it.

Alternative: Shove an IP into Hostname Serializing an IP address into a string and shoving it into the HostName value (eg, just putting in "192.0.2.7" or "2001:db8::1") might work, but those are not valid host names. Just because they can be serialized on the wire doesn't mean they won't result in unforseen breakage when abused in this manner.

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

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 . 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 every few hours, as a very widespread example. There is no way to use CAA records 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 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.

Privacy Considerations The SNI extension is sent in cleartext on the network, and thus visible to a passive observer. Using 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.

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