Subject: Question regarding HTTP/2, SNI, and IP addresses

From: John Mattsson <[email-masked]>
Date: Fri, 18 Jun 2021 12:30:17 +0000

Hi,

It would be very kind if someone could confirm or refute the following for me:

RFC 7540:

”The TLS implementation MUST support the Server Name Indication (SNI) [TLS-EXT<https://datatracker.ietf.org/doc/html/rfc7540#ref-TLS-EXT>] extension to TLS.  HTTP/2 clients MUST indicate the target domain name when negotiating TLS.

Deployments of HTTP/2 that negotiate TLS 1.3 or higher need only support and use the SNI extension; deployments of TLS 1.2 are subject to the requirements in the following sections.”

Am I correct in my understanding that:

  *   HTTP/2 (RFC 7540) requires support of sending the target domain name in SNI for both TLS 1.2 and TLS 1.3.
  *   IP addresses cannot be sent in SNI.
  *   IP addresses are not domain names.
  *   Therefore, HTTP/2 with HTTPS requires domain names and cannot be used with IP addresses only.

Cheers,
John

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 18 Jun 2021 15:00:20 +0200

On Fri, Jun 18, 2021 at 12:30:17PM +0000,
 John Mattsson <[email-masked]> wrote 

>   *   IP addresses are not domain names.

Indeed. RFC 6066, section 3 is clear 'Literal IPv4 and IPv6 addresses
are not permitted in "HostName"."' I've seen at least one TLS server
violently shutting down the connection when it received a literal IPv6
address in SNI (but not for IPv4). But in practice, it seems the
robustness principle is widely applied and TLS servers accept literal
IP addresses in SNI.

Not really for this WG but it can be noted this is an issue for DoT
(RFC 7858) and DoH (RFC 8484) since it is common to refer to DNS
resolvers by IP address.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 22 Jun 2021 10:55:08 +1000

On Fri, Jun 18, 2021, at 22:30, John Mattsson wrote:
>  * IP addresses are not domain names..

The revision says:

> The TLS implementation MUST support the Server Name Indication (SNI) [TLS-EXT] extension to TLS. If the server is identified by a domain name [DNS-TERMS], clients MUST send the server_name TLS extension unless an alternative mechanism to indicate the target host is used.

-- https://httpwg.org/http2-spec/draft-ietf-httpbis-http2bis.html#section-9.2-2

Is that clearer?  There is also similar updates to the HTTP core documents.

The intent was never to prohibit the use of IP addresses as authority.  That you might interpret the text that way is just an error.

---

From: John Mattsson <[email-masked]>
Date: Wed, 23 Jun 2021 08:19:02 +0000

Hi Martin,

Thank for pointing me to the bis document. I think the text in draft-ietf-httpbis-http2bis makes things clear. I think the bis document will be very useful for the discussions in 3GPP. My updated understanding is then:

- IP addresses without domain names are ok to use in HTTP/2
- SNI is not required unless a domain name is used.
- For domain names, use of SNI is required for both TLS 1.2 and TLS 1.3

Cheers,
John

From: Martin Thomson <[email-masked]>
Date: Tuesday, 22 June 2021 at 03:08
To: [email-masked] <[email-masked]>
Subject: Re: Question regarding HTTP/2, SNI, and IP addresses

> The TLS implementation MUST support the Server Name Indication (SNI) [TLS-EXT] extension to TLS. If the server is identified by a domain name [DNS-TERMS], clients MUST send the server_name TLS exte…

-- https://protect2.fireeye.com/v1/url?k=b9a701cc-e63c388f-b9a74157-861fcb972bfc-24435a99407b9eb3&q=1&e=fb3a5f03-fc79-46c7-b7aa-641b06dd2dd0&u=https%3A%2F%2Fhttpwg.org%2Fhttp2-spec%2Fdraft-ietf-httpbis-http2bis.html%23section-9.2-2

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 23 Jun 2021 10:30:46 +0200

On Tue, Jun 22, 2021 at 10:55:08AM +1000,
 Martin Thomson <[email-masked]> wrote 
 a message of 20 lines which said:

> The intent was never to prohibit the use of IP addresses as
> authority.

What are the possible "alternative mechanisms"?

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Jun 2021 18:47:54 +1000

> What are the possible "alternative mechanisms"?

Specifically? ECH is what we were thinking, but it could be something else too.

The important part is that both endpoints agree on the name. Just like with ALPN and the choice of protocol. We don't get that for IP addresses, but only for lack of a mechanism really.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 23 Jun 2021 11:54:28 +0300

On Wed, Jun 23, 2021 at 10:30:46AM +0200, Stephane Bortzmeyer wrote:
> > > The TLS implementation MUST support the Server Name Indication
> > > (SNI) [TLS-EXT] extension to TLS. If the server is identified
> > > by a domain name [DNS-TERMS], clients MUST send the server_name
> > > TLS extension unless an alternative mechanism to indicate the
> > >target host is used.
> > 
 
I am not aware of any such mechanism in TLS (since this is HTTP/2,
QUIC is not relevant). I presume that the primary intent of that
language was to cover ESNI (which would have used its own extension
for SNI). However, ESNI was superceded by ECH (also known as ECHO),
which still uses server_name for application-visible transport-level
SNI. Secondarily, such language would be useful if someone ever wants
to transport HTTP/2 on top of something else than TLS.

-Ilari