Subject: [TLS] Tonight's Encrypted SNI Hangout Session

From: Bret Jordan <[email-masked]>
Date: Mon, 13 Nov 2017 21:28:23 +0800

All,

We had a great turnout tonight for the encrypted SNI hangout session.
Everyone seemed open and willing to work together to understand the
complexities that sit before us. Several interesting and important views
were expressed, and I feel that the meeting was ultimately a success. In
fact, I believe we should do more hangout sessions like this.

Take aways from the meeting:
1) We are starting to understand the problem that we are trying to solve

2) We need to ensure that any potential solution will in fact solve the
problems as we understand it and not make the problem worse

3) We need to compile a list of use cases and scenarios in a draft document
that talk about how the SNI (for good or for bad) is being used today and
what an encrypted SNI will mean for these use cases.

4) We need to make sure we get feedback and information from at least the
telco sector, large enterprise, financial sector, and the health care
sector.

I believe this information will help us better understand both sides of the
issue, shed light in to what it will mean, help us define the "why" we are
doing this, and ultimately feed and foster a better technological solution.
If you have or know of scenarios or use-cases where the SNI is being used
by network operators, system administrators, security engineers, products,
etc, please send them to me so I can start compiling them in to a draft
document.

Side question, it feels like this effort could represent a lot of work and
require a lot of dedicated cycles. Does it make sense to continue this
effort inside of the TLS WG?  If it does, will the WG give us the time,
mindshare, and cycles to focus on it (just asking the hard question)?

Once again, thanks all for attending the session tonight.

Bret

-- 

Sent from my TI-99/4A

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

---

From: Tom Ritter <[email-masked]>
Date: Mon, 13 Nov 2017 10:00:23 -0600

On 13 November 2017 at 07:28, Bret Jordan <[email-masked]> wrote:
> If you have or know of scenarios or use-cases where the SNI is being used by
> network operators, system administrators, security engineers, products, etc,
> please send them to me so I can start compiling them in to a draft document.

Are you also interested in collecting reports of where SNI is used to
censor? Or the list of network vendors that support filtering and
manipulating traffic based on the value?

In general, the bad uses of SNI are harder to enumerate because people
aren't willing to come to the WG and explain how they use SNI to
selectively break or censor the internet for their citizens/users. We
have a few confirmed cases, anecdotal evidence, and lots of evidence
of censors being technically applied by whatever means is available.

But when you pile up all the administrators who will come to the WG
and say "This really frustrates me and makes my job harder" you're
going to have a much bigger pile than the users (or even technical
advocates like myself) we can bring in and say "Plaintext SNI is
harming the Internet".

> mindshare, and cycles to focus on it (just asking the hard question)?

In August we adopted the draft, so the answer is "Yes".

-tom

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Nov 2017 19:55:33 +0200

> what an encrypted SNI will mean for these use cases.

What I think SNI is mainly (legimately) used for:

- Specify the certificate.
- Specify the next service (both before and after TLS termination).

Ideally, specifying certificate would be enough to specify the next
service. But we all know reality is not ideal, so it might not be.
In the converse direction, having multiple certificates all covering
the same next service is very common (e.g., it would requre special
setup with common webservers not to have it this way).

As to specifying certificate, there are many reasons why a server
might want multiple certificates:

- There are too many names to put into one certificate.
- Putting all the names into one certificate would be difficult to
  manage.
- The server wants to make some separation between the names.
- The names have different next service.

One can note that both uses are really just to save IP address space.
There are two main reasons why one would want to do that:

- Conserving address space (IPv4!!!).
- Avoiding adminstrative overhead of multiple IP addresses.

Easier way to partially solve this would be to reduce the granularity
of data. Does not work with all servers.

The more difficult way would be to actually encrypt the SNI value
(bound to the client public key to avoid a nasty attack that breaks
the entiere scheme). This would make SNI before-termination routing
more difficult, and absent something nontrivial, would increase the
server handshake cost by over a half.

However, much of the "encrypted SNI" discusion has been about different
thing, namely proxying. Which is whole another can of worms, and is
also a three-party protocol, not two-party.

-Ilari

---

From: David P <[email-masked]>
Date: Mon, 13 Nov 2017 13:45:51 -0500

New here.

What about a use case (for SNI) of different teams (or budgets) procuring certificates for different sites housed on either the same server, or at least in the same data center behind the same load balancing device?  And SNI being used at a gateway, or entry point to that enterprise’s WAN. 

Sent from my iPhone

> On Nov 13, 2017, at 12:55 PM, Ilari Liusvaara <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Nov 2017 21:11:11 +0200

On Mon, Nov 13, 2017 at 01:45:51PM -0500, David P wrote:
> What about a use case (for SNI) of different teams (or budgets) procuring
> certificates for different sites housed on either the same server, or at
> least in the same data center behind the same load balancing device? 
> And SNI being used at a gateway, or entry point to that enterprise’s WAN. 

AFAICT, that would fall into "too difficult to manage with one
certificate" and "next service before TLS termination".

And yes, genuine encrypted SNI could be somewhat nasty for routing
before terminating TLS. And if one tries to simply use public-key
encryption, AFAICT, all the known ways are either slower than
ECDH-ES or have much larger size overhead (heck, ECDH-ES itself is
either optimal size-wise or close to it). Also, DH-ES type schemes do
not work with PQC (which is starting to be a concern).

-Ilari

---

From: Christian Huitema <[email-masked]>
Date: Mon, 13 Nov 2017 11:54:59 -0800

> not work with PQC (which is starting to be a concern).

The current draft
(https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/)
studies this problem and describes classes of solutions. The solutions
are certainly imperfect, but they address the use case where a
"multiplexed server" receives requests for a hidden service, when the
SNI in the client hello describes a forwarding service. The draft does
not give examples of what the "multiplexed server"might be, but the
common implementation in our mind is a set of servers behind a load
balancer.

-- Christian Huitema

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 13 Nov 2017 22:40:30 +0000

Look at Christian’s draft, it captures the use-case(s) and trade-offs pretty well.

---

From: Bret Jordan <[email-masked]>
Date: Tue, 14 Nov 2017 09:16:02 +0800

What I think I am more worried about right now is jumping in to designing a
technological solution before we know and understand what is going to break
and is a solution going to actually solve the perceived problem(s) or make
them worse. Technological changes do not always make things better.

Open Questions:
1) Is encrypted SNI the best solution to address the perceived problem(s)?
2) Do we fully understand the problems we are trying to solve and
understand the best way of solving them?
3) Will this make things better or worse for the majority of use-cases?
4) Does it incur so much collateral damage that it hurts the average user?
5) If we make it client opt-in (which seems like a fundamental
requirement), does this single out the client for extra scrutiny by a well
funded threat actor or nation state?

Just some food for thought

Bret

Sent from my TI-99/4A

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Nov 2017 10:43:20 +0800

> On 14 Nov 2017, at 0:00, Tom Ritter <[email-masked]> wrote:
> 

I don’t think naming and shaming is a goal here.

> selectively break or censor the internet for their citizens/users.

I don’t think that’s true. I used to work for a vendor of a network firewall, and I can explain how this is done.

Inspecting the ClientHello to find the SNI for filtering is a weak way to do filtering. It’s also a light-weight way.  So if I want to filter Wikipedia, I match SNIs to "*.wikipedia.org” and I have my filtering. Depending on how many cycles I can spare, this is a cost-effective method. We have evidence that it’s been used for filtering, but sophisticated users can circumvent this - they can configure the browser to use TLS 1.0 and not send SNI at all.

More modern firewalls make a probing connection to the server, sending a ClientHello that is almost identical to the one sent by the real client and checking the returned certificate.  The names specified in that certificate are used for the filtering. That information is cached so that not every real ClientHello has to wait for a probing connection.  I don’t know if any vendor has made this scale to filter an entire country’s browsing, but this is considered to be more reliable than filtering by SNI.

> We
> harming the Internet”.

IMO the real game-changer will be having an encrypted part to the ClientHello. If all ClientHellos are different, this defeats caching.

---

From: Bret Jordan <[email-masked]>
Date: Tue, 14 Nov 2017 12:04:44 +0800

Great comments and feedback. Thank you.  

Bret 

Sent from my Commodore 128D

> On Nov 14, 2017, at 10:43 AM, Yoav Nir <[email-masked]> wrote:
> 
> 
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 14 Nov 2017 22:16:02 -0500

Please see https://www.ietf.org/id/draft-camwinget-tls-use-cases-00.txt 
for some example use case scenarios impacted by encrypted SNI.

As Ekr subsequently pointed out, it would be useful to make a 
distinction between conformant and non-conformant use case scenarios 
(which we plan to do in the next version).

Thanks

-- Flemming

On 11/13/17 8:16 PM, Bret Jordan wrote:
> What I think I am more worried about right now is jumping in to 
> designing a technological solution before we know and understand what 
> is going to break and is a solution going to actually solve the 
> perceived problem(s) or make them worse. Technological changes do not 
> always make things better.
>
> Open Questions:
> requirement), does this single out the client for extra scrutiny by a 
> well funded threat actor or nation state?
>

---

From: Sean Turner <[email-masked]>
Date: Thu, 16 Nov 2017 08:52:53 +0800

> On Nov 14, 2017, at 00:00, Tom Ritter <[email-masked]> wrote:
> 

The answer is definitely yes; but, the WG has already spent literally days of WG f2f time on this particular topic.  As Rich points out, Christian’s draft pretty much captures the use-case(s) and trade-offs that we’ve talked about over the last two years.  Now we just need to keep the discussions moving.

spt