SNI requirement for HTTP/QUIC

[igorlord]

Per @martinthomson in #495, SNI is currently not required to be used in QUIC, while it is required to be used in HTTP/2. TLS 1.3 requires SNI to be implemented but apparently does not require it be to used.

This is a proposal to require SNI for QUIC.

The main reason for this is the scarcity of IPv4 addresses. As long as something is not required, someone will not implement it. As long as there are enough clients that do not use SNI, virtual service providers will continue to require a large number of IPv4 addresses. Since IPv4 address conservation is currently a high priority for the Internet, QUIC should strongly encourage (or, better, require) technologies that further this conservation goal.

[hardie]

On Mon, Sep 25, 2017 at 3:25 PM, Igor Lubashev ***@***.***> wrote: Per @martinthomson <https://github.com/martinthomson> in #495 <#495>, SNI is currently not required to be used in QUIC, while it is required to be used in HTTP/2. TLS 1.3 requires SNI to be implemented but apparently does not require it be to used. This is a proposal to require SNI for QUIC. The main reason for this is the scarcity of IPv4 addresses. As long as something is not required, someone will not implement it. As long as there are enough clients that do not use SNI, virtual service providers will continue to require a large number of IPv4 addresses. Since IPv4 address conservation is currently a high priority for the Internet, QUIC should strongly encourage (or, better, require) technologies that further this conservation goal. Nit: I believe you mean to require SNI, not SIN, though no doubt we'll

get the latter some way or another. Substantive: I believe that if we require SNI, we require some method of preserving the privacy of that SNI. I'm not sure that the TLS in TLS tunneling solution for encrypted SNI that https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00 puts forward is as neat in the QUIC case. If the fronting server isn't a QUIC service but is purely a TLS-in-TLS tunneling proxy, then it probably works as described. But if it is both a QUIC service and fronting for other QUIC-in-TLS-in-TLS services, then I think we need to carefully work through how the second aspects fits in with other QUIC assumptions about where the transport/application boundary fits. I think the dual service is something that we need to consider for some of the same reasons set out in sni-encyption-00 regarding replay attacks: if at attacker connecting to a fronting service doesn't connect to a hidden service behind it and thus gets a "blank service", it will make the server stand out as a fronting server. To avoid that, I suspect folks would like to present servers that are both fronting services and servers for an existing application protocol.

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#794>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVb5MQtFXGsG_sBF9SbxmdC55nGWG2aks5smChQgaJpZM4PjbM9> .

[martinthomson]

@hardie is correct in that QUIC makes TLS-in-TLS more difficult. Though that is not the only alternative available. It is not impossible to do TLS-in-TLS, but it would require some non-trivial effort.

But I think that we should first address the meta-comment. Do we want to change the character of QUIC such that it can/MUST support SNI encryption? That's a different question to the one that I think @igorlord had, which is probably just "should HTTP over QUIC require SNI?" The answer to each might be different.

[igorlord]

Nit: I believe you mean to require SNI, not SIN,

Thanks, fixed. (There are plenty SINs already; no need for requiring a new one.)

SNI privacy

SNI privacy looks like a TLS extension, and it could be developed separately from QUIC. @martinthomson has had enough wisdom to open #795 to make sure we at least discuss the topic.

A solution along the lines of tls-sni-encryption-00 would certainly benefit from a 1-RTT encrypted Finished (as is suggested in #785), since Finished could include bits to trigger "chained SNI" and TLS-in TLS negotiation. It would be a nice solution, since it would allow server side of the application to be relatively oblivious to the TLS tunneling that is going on.

An application-specific implementation, where the client talks first, could provide an application-specific way to trigger SNI chaining and TLS-in-TLS negotiation.

[igorlord]

"should HTTP over QUIC require SNI?"

This is a fine first question to answer, and I am happy to change this issue to address this specifically.

I think a generic question of whether a client is required to identify whose TLS certificate it is looking for, regardless of the app, is also interesting to settle.

[MikeBishop]

This was supposed to be closed by #1024.

[kovalensky]

In the issues section, it says that you can not send suggestions, and the iron must be forged while it is hot, so I will leave this idea for HTTP/3 here:

Since many system administrators filter QUIC traffic (many ways based on udp ports 80, 443), forcing the user to return to TCP, I would like to suggest a way to speed up the integration of QUIC on the Internet.
It consists in using an optional TXT record with the value or intervals of ports to which the server can accept QUIC connections.
Thus, QUIC ceases to depend on a single port, gaining scalability.
Thank you.

[LPardue]

Please see https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-03.

But this is not a problem that the base drafts need to solve, so there is really nothing more to discuss here.