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

[David Benjamin <[e-mail]>]

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