Re: [quicwg/base-drafts] Make SNI more clearly mandatory (#3326)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -312,11 +317,14 @@ an explicit port.
 
 ## Connection Establishment {#connection-establishment}
 
-HTTP/3 relies on QUIC as the underlying transport.  The QUIC version being used
-MUST use TLS version 1.3 or greater as its handshake protocol.  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.
+HTTP/3 relies on QUIC version 1 as the underlying transport.  The use of other
+QUIC transport versions with HTTP/3 MAY be defined by future specifications.
+
+QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol.
+HTTP/3 clients MUST support a mechanism to indicate the target host to the
+server during the TLS handshake.  Unless an alternative mechanism for indicating
+the target host is used, clients MUST use the Server Name Indication (SNI)
+{{!RFC6066}} extension to TLS if the target host is a DNS name.

Yeah, I don't think that the WebRTC case applies here, though as a general caution it is worth bearing in mind.  ESNI might be modeled as an alternative that is OK on those terms, but if the information is deliberately withheld on the basis of privacy in a specific context, then this requirement could be problematic.  I would expect an update to this document to be necessary in that case.

> "If the server is identified by a DNS name, clients MUST send the Server Name Indication (SNI) ... extension to TLS unless an alternative mechanism for indicating the server is available"

This says something subtly different logically.  I had the ordered list:

1. if alternative, use that
2. if domain name, use SNI
3. else, don't bother

This says:

1. if domain name,
   a. if alternative, use that
   b. else, use SNI
2. else don't bother

I'm OK with that, but I want to recognize the subtle distinction.  On balance, it's a good distinction because it avoids levying requirements for identification of non-domain names, but I wanted to highlight that to be sure that we all agree that is the intent.

-- 
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/pull/3326#discussion_r364527949