Subject: [quicwg/base-drafts] Confusing SNI recommendation in the HTTP/3 spec (#3324)

From: Ryan Hamilton <[email-masked]>
Date: Tue, 07 Jan 2020 14:26:46 -0800

In reading PR#3323, I noticed that we have the text (unchanged by that PR):

 HTTP/3 clients MUST indicate the target domain name during the TLS handshake.
 This may be done using the Server Name Indication (SNI) {{!RFC6066}} extension
 to TLS or using some other mechanism.

I read this as saying that in the absence of "some other mechanism" the SNI extension must be present. But as I read 6066, it prohibits IP literals:

   Literal IPv4 and IPv6 addresses are not permitted in "HostName".

As such, I'm not quite sure how to interpret the HTTP/3 MUST when the browser is requesting a URL with an IP literal as the host of the URL's. I could imagine two interpretations:
1. When HTTP/3 says "target domain name" that implicitly excludes IP literals, so no SN extension is expected.
2. When HTTP/3 says "target domain name" that implicitly includes IP literals, so an SNI extension is expected.
(Or probably more likely, 3. I'm misunderstanding something more deeply)

If 1 is the intended behavior it might be worth some text clarifying that. However, it seems like it would be "good" if QUIC handshakes *always* included the client's understanding of the hostname so I'd love the interpretation to be 2 (though that seems to conflict with 6066 so perhaps that's hard.)

Thoughts?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3324

---

From: David Benjamin <[email-masked]>
Date: Tue, 07 Jan 2020 15:42:45 -0800

For HTTP/1.1 and HTTP/2 over TLS, we do not send the IP literal in SNI. Chrome accidentally did for few releases, which broke Apache httpd. It got confused because IPv6 literals have colons. Of course, the compatibility issue does not apply to a new protocol like QUIC.

It would be nice for QUIC to mandate SNI, and, all else equal, avoiding random TLS inconsistencies is good. But this rule is odd and "you MUST send SNI whenever you are supposed to send SNI" is tautological. TLS 1.3 says something woefully noncommittal:

>    Additionally, all implementations MUST support the use of the
>   "server_name" extension with applications capable of using it.
>   Servers MAY require clients to send a valid "server_name" extension.
>   Servers requiring this extension SHOULD respond to a ClientHello
>   lacking a "server_name" extension by terminating the connection with
>   a "missing_extension" alert.

I dunno, everything is a mess. :-( If we were doing things anew, perhaps we'd have stuck the port number in there too. (As it stands, TLS does not authenticate the port, yet the port is part of the origin, and I doubt HTTP servers reliably check the port in the Host header.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3324#issuecomment-571825238

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jan 2020 16:29:35 -0800

Maybe the rule can be concretely:

1. if you have something else/better use that, otherwise
2. if you have a domain name, include SNI, and finally
3. if you don't have a domain name (including IP literals), do whatever.

The HTTP scheme permits a broader range of "host" identifiers than we usually contemplate, so the 3rd option has to catch more than just IP literals.

TLS was always necessarily lax because different applications have different constraints, but the idea was to ensure that for cases where you have the ability to use SNI that you used it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3324#issuecomment-571836314

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 07 Jan 2020 19:10:26 -0800

That sounds reasonable. How about some text like:

HTTP/3 clients MUST support a mechanism to indicate the target host to the server during the TLS handshake. This may be done using the Server Name Indication (SNI) {{!RFC6066}} extension to TLS or using some other mechanism. If the target host is valid for this mechanism (in the case of SNI this means the host is a domain name) the client MUST indicate the host using this mechanism.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3324#issuecomment-571871861

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jan 2020 21:46:45 -0800

> Literal IPv4 and IPv6 addresses are not permitted in "HostName".

PR opened.  @MikeBishop do you think that this is OK as editorial?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3324#issuecomment-571900727

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 08 Jan 2020 06:48:10 -0800

> > Literal IPv4 and IPv6 addresses are not permitted in "HostName".

Right. This is what I said in my first post on this issue :)

> PR opened. 

Thanks. Look great!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3324#issuecomment-572102185

---

From: Mike Bishop <[email-masked]>
Date: Wed, 08 Jan 2020 08:54:12 -0800

> @MikeBishop do you think that this is OK as editorial?

I think it's fine -- we're clarifying the requirement we already have.  Nothing we previously allowed is being prohibited, and nothing previously prohibited is now allowed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3324#issuecomment-572159203