SNI encryption

[martinthomson]

In #794, @hardie observed that the current draft for SNI encryption proposes solutions that are - at best - a poor fit for the current QUIC design. Do we want to address this problem in the design?

Fixing the problem early might avoid foreclosing on potential solutions in the future. It's also possible that we could take advantage of the fact that we don't really have a whole bunch of deployment assumptions that we have to work around.

On the other hand, it might also be really, really hard. It's not like we haven't already tried to find a solution for TLS over TCP.

FWIW, I don't think that we get to resolve #794 until we have at least had a discussion about this issue.

[MikeBishop]

Secondary certificates seems like a good way to achieve this for HTTP/* over TLS. Put your CERTIFICATE_REQUEST for the real hostname in 0-RTT data. A more general possibility would be the "tls1.3" ALPN token, where you carry a TLS 1.3 session on Stream 1, with the ClientHello (in 0-RTT data if you can) and use of other streams is discouraged or prohibited.

[hardie]

On Wed, Oct 25, 2017 at 2:39 PM, Mike Bishop notifications@github.com wrote:

Secondary certificates seems like a good way to achieve this for HTTP/* over TLS. Put your CERTIFICATE_REQUEST for the real hostname in 0-RTT data. A more general possibility would be the "tls1.3" ALPN token, where you carry a TLS 1.3 session on Stream 1, with the ClientHello (in 0-RTT data if you can) and use of other streams is discouraged or prohibited.

I think that means that the ALPN token can't be used to select the protocol. When we get to the point of having multiple protocols, some subset of which might be present but served by different back end processes, that could pose a problem. Would you be okay with $PROTOCOL.tls1.3 as a pattern? That can still get you to the point where the server name is encrypted, even if the protocol is known to anyone able to observe the ALPN token.

Ted

[martinthomson]

The issue here is not whether we expose the use of a particular protocol. Those tend to have small cardinality, so don't tend to compromise K-anonymity much by their exposure. But I wouldn't shift the load to ALPN.

If any protocol can build similar capabilities to what is proposed for HTTP, then they benefit from the same advantages vis-a-vis SNI protection. If a generic capability is what is needed, I don't think that ALPN is where I would start looking, I'd build a QUIC extension in some form.

An extension would either replicate the HTTP/2 certificates functionality, or do QUIC-in-QUIC in some way (probably by putting TLS in a stream and then exporting new keys when it is done and using a key update to manage their installation). Christian and ekr have done some work here and have a few options in their TLS doc. Some, if not all, of the basic designs work for QUIC. None of them use ALPN, which would create an undesirable secondary signal.

(Also, every time someone suggests we make ALPN anything other than opaque, I cringe.)

[martinthomson]

Waiting for TLS to give us something.

[jmtilli]

I hope people here realize that this proposal of encrypting the SNI will make multiplexing connections on a NAT middlebox (see Issue #1456) practically impossible.

The IPv4 address exhaustion is a reality, and IPv6 adoption will probably be much slower than QUIC adoption, so QUIC should not contribute to the IPv4 address shortage problem by encrypting the only piece of information about the server (i.e. the DNS name) in addition to the IPv4 address.

In contrast, if SNI remains unencrypted, a NAT middlebox can share an IPv4 address for multiple servers and choose the correct server based on the SNI.

[ianswett]

My feeling is we've officially punted this to the TLS WG and I expect we'll do whatever they do, so the TLS WG is probably a better forum to discuss this, but as MikkelFJ said on the other issue, feel free to email the list.

I'm also not 100% clear on how you're using SNI in a NAT. Is there a full explanation somewhere?

[jmtilli]

The full explanation is easy. It's for incoming connections in a use case where multiple HTTP2/QUIC servers are multiplexed behind a single IPv4 server address. For example, IoT adoption might require more than 4 billion HTTP servers all around the world.

If the first QUIC packet sent will contain the SNI, the NAT will compare it against a full list of (SNI, internal IP) pairs. For example:

• device1.iot.company.com -> 10.0.1.100
• device2.iot.company.com -> 10.0.1.101
• device3.iot.company.com -> 10.0.1.102
• device4.iot.company.com -> 10.0.1.103

If the SNI is unencrypted and required to be always present, this scheme will work all the time.

The only problem is configuring the SNI -> internal IP mappings in the NAT box. If it's a carrier grade NAT, presumably the carrier will allow configuring wildcard matches against the domain names the customers own.

Outgoing connections will always work with NAT without any SNI matching.

[larseggert]

This discussion needs to happen in the TLS WG.

[ekr]

+1 to @larseggert, but more importantly, every proposed SNI encryption system would require opt-in from the site.

[martinthomson]

My assessment here is that this will either happen in TLS or not and we don't need to track it specially in QUIC. No solution that I'm aware of will require changes to QUIC to be used because it all happens entirely outside the protocol (e.g., in DNS) or entirely within TLS.

There's a small risk that the overzealous use of padding in some cases might make it hard for QUIC to benefit from this, or that the arrangement of the design is too narrow in applicability for it to apply to QUIC, but that seems unlikely given the actors. Those involved are motivated to have it work for QUIC.

So I'm going to close this. If we need some changes to QUIC to support a particular design, we can discuss the specific requirements as they come up. Most likely, any such discussion would need to be left to v2.

[mikkelfj]

There is one case I could see: An external DNS like solution affects the initial random ODCID so it isn't entirely random and routes to the appropriate target.

[martinthomson]

The specs wouldn't necessarily change there. It's basically a property of QUIC that the destination connection ID in a client's Initial packet is not controlled by the server, and therefore not really appropriate for use in routing packets in the same way that a connection ID that the server chooses is.

If a solution for encrypting SNI proposed new ways of selecting the destination connection ID (I haven't seen that suggested, but I'll concede that it's possible), then they would have to work within that constraint. Either that, or request changes from QUIC.