Subject: Re: [quicwg/base-drafts] SNI encryption (#795)

From: Juha-Matti Tilli <[email-masked]>
Date: Mon, 18 Jun 2018 11:45:28 +0000 (UTC)

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.

-- 
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/795#issuecomment-398027461

---

From: ianswett <[email-masked]>
Date: Mon, 18 Jun 2018 05:24:27 -0700

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?

-- 
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/795#issuecomment-398036461

---

From: Juha-Matti Tilli <[email-masked]>
Date: Wed, 20 Jun 2018 06:18:07 -0700

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.

-- 
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/795#issuecomment-398745019

---

From: Lars Eggert <[email-masked]>
Date: Wed, 20 Jun 2018 06:21:14 -0700

This discussion needs to happen in the TLS WG. 

-- 
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/795#issuecomment-398745956

---

From: ekr <[email-masked]>
Date: Wed, 20 Jun 2018 09:50:55 -0700

+1 to @larseggert, but more importantly, every proposed SNI encryption system would require opt-in from the site. With that said, those sites should just give the middlebox the SNI encryption key.

-- 
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/795#issuecomment-398820402