Subject: [TLS] Encrypted SNI

From: Bret Jordan <[email-masked]>
Date: Tue, 3 Jul 2018 11:08:21 -0600

From a discussion on the PATIENT list found here: https://www.ietf.org/mail-archive/web/patient/current/msg00078.html <https://www.ietf.org/mail-archive/web/patient/current/msg00078.html>

From my personal perspective, we need to be careful with all of these efforts. It feels like the pendulum has swung so far to one side, the side of privacy-at-any-cost, that we are unknowingly increasing the risk to individuals and organizations by enabling threat actors and intrusions sets to attack networks and clients without any level of protection from the network. 

It also feels like a lot of these initiatives are being done without adequately involving and ensuring that enterprise networks and critical infrastructure can work with these changes. Question, do we know how these ideas and changes are going to impact an organizations ability to fulfill their requirements for regulatory compliance? 

If we continue down these paths, then I fear networks will be required to wrap all traffic in some other less secure protocol, outright deny some of these protocols, or be forced to fully proxy all traffic or take an approach that Google has done with their BeyondCorp design.  

The IETF work needs to do more outreach with enterprise networks and critical infrastructure and be fundamentally more inclusive. Privacy-at-any-cost is not a holistic design. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

### Copied content from the PATIENT discussion ####

On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty <kathleen.moriarty.ietf at gmail.com <mailto:kathleen.moriarty.ietf%20at%20gmail.com>> wrote:
On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla <ekr at rtfm.com <mailto:ekr%20at%20rtfm.com>> wrote:
>
>
> On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski <tony at yaanatech.co..uk>
> wrote:
>>
>> Your point is one that deserves further discussion, Eric - which seems
>> likely to scale rapidly going forward.  It is key.
>>
>> So how does draft-ietf-tls-sni-encryption it into the argument?
>
>
> As you suggest, SNI encryption is intended to conceal the SNI, which of
> course would make SNI inspection difficult.
>
> My evaluation of the current state of SNI encryption is that given the
> current technical state, it will not see particularly wide deployment, with
> the primary scenario being "at-risk" sites who are subject to censorship who
> either hide behind or co-tenant with sites which are not subject to
> censorship. That probably isn't going to be incredibly common right now. Of
> course, this is regrettable from the perspective of people designing these
> protocols, but I think that's the situation.

EKR posted a draft to encrypt SNI, see:
https://www.ietf.org/mail-archive/web/tls/current/msg26468.html <https://www.ietf.org/mail-archive/web/tls/current/msg26468.html>

It targets the CDNs who host most of the web traffic in the US at
least.  The right place to comment on this would be the TLS list of
course, but since proposals are being posted, this is a reality and
needs to be discussed.  Those using SNI need to make sure their use
cases are clear and understood and argue the pros and cons.

Kathleen,

Thanks for pointing out this draft.

As they say, predictions are hard, especially about the future. In March, the ESNI problem looked pretty intractable and then subsequently we had this idea about why it might be workable.

-Ekr

Best regards,
Kathleen

>
> -Ekr
>
>> On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
>>
>> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <tony at yaanatech.co.uk <mailto:tony%20at%20yaanatech.co.uk>>
>> wrote:
>>>
>>> Hi Diego,
>>>
>>> It is also worth referencing a relatively recent Lawfare article on the
>>> scaling litigation in the U.S. against those supporting e2e encryption
>>> services or capabilities.
>>>
>>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis <https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis>
>>>
>>> This litigation trend is also likely to increase the insurance costs of
>>> providers.  Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, may not
>>> even be able to get insurance.  It may be fun and games to play crypto rebel
>>> in venues like the IETF where the risk exposure is minimal, but when it
>>> comes to real world consequences and costs, the equations for providers are
>>> rather different.
>>
>>
>> I think this rather overestimates the degree to which both TLS 1.3 and
>> QUIC change the equation about what a provider is able to determine from
>> traffic inspection. As a practical matter, the primary change from TLS 1.2
>> is that the provider does not get to see the server's certificate, but it
>> does see the SNI. Given that the SNI contains the identity of the server
>> that the client is connected to and that the other identities in the
>> certificate are often whatever the provider decided to co-locate on the same
>> machine, I'm not sure how much information you are really losing.
>>
>> -Ekr
>>
>>>
>>>
>>>
>>> --tony
>>>
>>>
>>> _______________________________________________
>>> PATIENT mailing list
>>> PATIENT at ietf.org <mailto:PATIENT%20at%20ietf.org>
>>> https://www.ietf.org/mailman/listinfo/patient <https://www.ietf.org/mailman/listinfo/patient>
>>
>>
>>
>>
>> _______________________________________________
>> PATIENT mailing list
>> PATIENT at ietf.org <mailto:PATIENT%20at%20ietf.org>
>> https://www.ietf.org/mailman/listinfo/patient <https://www.ietf.org/mailman/listinfo/patient>
>>
>>
>
>
> _______________________________________________
> PATIENT mailing list
> PATIENT at ietf.org <mailto:PATIENT%20at%20ietf.org>
> https://www.ietf.org/mailman/listinfo/patient <https://www.ietf.org/mailman/listinfo/patient>
>

-- 

Best regards,
Kathleen

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 3 Jul 2018 17:12:23 +0000

+1

From: TLS [mailto:[email-masked]] On Behalf Of Bret Jordan
Sent: Tuesday, July 3, 2018 1:08 PM
To: [email-masked]
Subject: [TLS] Encrypted SNI

From a discussion on the PATIENT list found here: https://www.ietf.org/mail-archive/web/patient/current/msg00078.html

Thanks,
Bret

On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty <kathleen.moriarty.ietf at gmail.com<mailto:kathleen.moriarty.ietf%20at%20gmail.com>> wrote:

On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla <ekr at rtfm.com<mailto:ekr%20at%20rtfm.com>> wrote:
>
>
> On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski <tony at yaanatech.co<http://yaanatech.co>..uk>
> wrote:
>>

EKR posted a draft to encrypt SNI, see:
https://www.ietf.org/mail-archive/web/tls/current/msg26468.html

Kathleen,

-Ekr

Best regards,
Kathleen

>> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <tony at yaanatech.co.uk<mailto:tony%20at%20yaanatech.co.uk>>
>> wrote:
>>>
>>> Hi Diego,
>>>
>>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis
>>>
>>> PATIENT at ietf.org<mailto:PATIENT%20at%20ietf.org>
>>> https://www.ietf.org/mailman/listinfo/patient
>>
>>
>>
>>
>> PATIENT at ietf.org<mailto:PATIENT%20at%20ietf.org>
>> https://www.ietf.org/mailman/listinfo/patient
>>
>>
>
>
> PATIENT at ietf.org<mailto:PATIENT%20at%20ietf.org>
> https://www.ietf.org/mailman/listinfo/patient
>

--

Best regards,
Kathleen

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Jul 2018 14:49:03 -0500

> From my personal perspective, we need to be careful with all of these efforts. It feels like the pendulum has swung so far to one side, the side of privacy-at-any-cost, that we are unknowingly incr…

BCP 61 leads us to not expect any protection from the network, does it not?

> If we continue down these paths, then I fear networks will be required to wrap all traffic in some other less secure protocol, outright deny some of these protocols, or be forced to fully proxy all…

I suspect you will find that many proponents of the proposals you find
worrisome would also be enthusiastic proponents of "an approach similar to what
Google has done with BeyondCorp".  Such a discussion would be off-topic for
the TLS list, but you would probably be well-served to have some supporting text
for why this sort of approach should be considered bad, if you want to gain
sympathy for your perspective.

-Ben

> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Darin Pettis <[email-masked]>
Date: Tue, 3 Jul 2018 15:09:20 -0500

+1

On Tue, Jul 3, 2018 at 12:08 PM Bret Jordan <[email-masked]> wrote:

> From a discussion on the PATIENT list found here:
> https://www.ietf.org/mail-archive/web/patient/current/msg00078.html
>
>
> From my personal perspective, we need to be careful with all of these
> efforts. It feels like the pendulum has swung so far to one side, the side
> of privacy-at-any-cost, that we are unknowingly increasing the risk to
> individuals and organizations by enabling threat actors and intrusions sets
> to attack networks and clients without any level of protection from the
> network.
>
> It also feels like a lot of these initiatives are being done without
> adequately involving and ensuring that enterprise networks and critical
> infrastructure can work with these changes. Question, do we know how these
> ideas and changes are going to impact an organizations ability to fulfill
> their requirements for regulatory compliance?
>
> If we continue down these paths, then I fear networks will be required to
> wrap all traffic in some other less secure protocol, outright deny some of
> these protocols, or be forced to fully proxy all traffic or take an
> approach that Google has done with their BeyondCorp design.
>
> The IETF work needs to do more outreach with enterprise networks and
> critical infrastructure and be fundamentally more inclusive.
> Privacy-at-any-cost is not a holistic design.
>
> Thanks,
> Bret
> On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty <kathleen.moriarty.ietf
> at gmail.com> wrote:
>
>> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla <ekr at rtfm.com> wrote:
>> >
>> >
> As they say, predictions are hard, especially about the future. In March,
> the ESNI problem looked pretty intractable and then subsequently we had
> this idea about why it might be workable.
>
> -Ekr
>
> Best regards,
>> Kathleen
>>
>> >
>> > -Ekr
>> >
>> >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <tony at
>> yaanatech.co.uk>
>> >> wrote:
>> >>>
>> >>> Hi Diego,
>> >>>
>> >>> PATIENT at ietf.org
>> >> PATIENT at ietf.org
>> > PATIENT at ietf.org

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 3 Jul 2018 16:08:56 -0400

> sympathy for your perspective.

The proposal came from an AD who just a few moths ago told them not to
worry about these possible changes (see referenced thread on PATIENT
list) that impact their work, so in other words, don't prepare for it,
don't worry about alternate solutions or figuring out ways to better
articulate your use cases.  Then that AD submits the proposal.
Challenging comments are posted and I would expect that there be
sensitivities as to the origin of the draft and making it even more
fair for list participants to comment and understand that this draft
should be treated as any other.

While I agree that additional text and supporting use case information
is needed, there also needs to be an openness to listen to all views
on a proposal.  If there are use cases that are critical for SNI, they
need to surface and be considered.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Hanno Böck <[email-masked]>
Date: Tue, 3 Jul 2018 22:24:14 +0200

So-called "Enterprise" infrastructure has delayed the work of this group
for at least a year. Noone of the people creating that mess has reached
out to this group to explain why they constantly break TLS - let alone
apologize for it.

I believe there's a large overlap of the actors breaking TLS with the
actors who are worried about things like SNI encryption. I'm not sure I
see any reason not to consider these actors as anything but opposed to
the work of this group.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Jul 2018 14:11:20 -0700

On Tue, Jul 3, 2018 at 10:08 AM, Bret Jordan <[email-masked]> wrote:

> From a discussion on the PATIENT list found here: https://www.ietf.org/mai
> l-archive/web/patient/current/msg00078.html
>
>

Well "these changes" covers a lot of ground, but in this particular case,
can't enterprise just strip ESNI records from DNS?

-Ekr

---

From: Brian Sniffen <[email-masked]>
Date: Tue, 03 Jul 2018 17:19:20 -0400

> see any reason not to consider these actors as anything but opposed to

Whoah!  I've been involved for years specifically to ask for care about
encrypted SNI.  I don't know whether I break TLS; maybe opinions vary.
But my concerns have been specific:

First, at the engineering level, a requirement that servers do expensive
cryptographic work in response to a first packet *and* an inability to
charge that work to a user or application is a big problem.  It makes it
too hard for users or applications to share a server, or leads to levels
of address waste expensive even with IPv6.

If we're going to have 0RTT and 1RTT and TCP Fast Open and ECDHE... then
Encrypted SNI is a hard engineering problem! 

Second, at the architectural level, a serious question about whether
this actually helps anybody, and if so whom?  I think the case of the
Amnesty International worker in an oppressive dictatorship is almost
certainly *not* helped by this work---see my questions about how many
bits of security this provides against an adaptive adversary from this
morning---and would like some clarity that this is about inhibiting the
ISPs, from cafes through enterprises up to Comcast-TWC, from monkeying
with user sessions.  

My concerns at the engineering level have been welcomed, recognized,
validated, and addressed.  Not always exactly the way I'd like, but
absolutely addressed in a way that's appropriate and sincere.  I saw the
same with requests to re-insert RSA Kx late last year.  The PATIENT
folks have gotten a fair hearing.

My architectural concerns have been heard, somewhat less eagerly.  Some
participants, including our colleagues who are vendors to enterprises
and folks like Ben Schwartz, have been clear that they will not bring
all their motivations and evidence to the table.  I significantly
discount their arguments and expect others to do the same---but not to
zero.  It means we need to check their work as we go, or actually trust
them as people, but it *can't* be harder than keeping NSA/IA people on
CFRG!

Anyway, I think the PATIENT folks concerns about the engineering of TLS
1.3 have been heard, have been taken seriously, and have been
addressed---same as mine or yours.  What I've seen of the architectural
concerns leading to network-centric management and "tap" devices come
down to claims about changes in architecture being too expensive,
middleboxes being too expensive, changes to applications being too
expensive, and general citation of an architecture only a few years old
as immutable tradition.  Those claims have also been heard, plenty of
folks have respectfully and diligently combed through them for evidence,
and we've moved on.

I bet that's frustrating and frightening for the folks writing from a
world where those claims aren't faith-based---they're obvious.  They
don't need citation any more than "China is a country"[1] needs
citation.  Nonetheless, engineering conversations based on
data-supported arguments continue to be welcome.

-Brian

Footnotes: 
[1]  https://www.cia.gov/library/publications/the-world-factbook/geos/ch.html
     but see also https://www.cia.gov/library/publications/the-world-factbook/geos/tw.html

-- 
Brian Sniffen

---

From: Paul Wouters <[email-masked]>
Date: Tue, 3 Jul 2018 23:31:28 -0400 (EDT)

On Tue, 3 Jul 2018, Eric Rescorla wrote:

> but in this particular case, can't enterprise just strip ESNI records from DNS?

Not if endnodes within the enterprise also use DNSSEC. Unless you want
the enterprise to run authoritative fake DNSSEC for the entire world.

It also requires installing internal trust anchors, which is something
you pushed back hard on with draft-ietf-ipsecme-split-dns

One way this could be done is if draft-ietf-dnsop-dns-rpz finally goes
RFC, so IETF gains change control of a bis document, where we define the
filtering to move the filtered record from the additional to the authority
section, so the filtering can be detected yet DNSSEC verified.  But it
seems draft-ietf-dnsop-dns-rpz is being kept in draft state forever,
which basically prevents us from fixing this.

Paul
ps. also note stripping a ESNI RRTYPE is easier than stripping _some_
TXT records :)

---

From: nalini elkins <[email-masked]>
Date: Wed, 4 Jul 2018 09:57:53 +0530

>see any reason not to consider these actors as anything but opposed to

I believe that enterprise people have tried over and over again to
explain.
You may wish to take a serious look at:

https://datatracker.ietf.org/doc/draft-fenter-tls-decryption/

I, personally, have tremendous respect for the people in the TLS group.
The level of cryptographic expertise as well as the passion /
commitment is unparalleled.

I think both "sides" are acting with good intentions - while looking at the
world through their own lenses.   Enterprises need to be able to do Business
As Usual (BAU) while integrating innovation into their networks.

I suspect that no one likes middleboxes or "breaking" TLS but it is at least
temporarily necessary.   You cannot hide your head in the sand and pretend
it does not exist.  Markets exist for a reason.

People do not spend time and money to make presentations (at the TLS group)
without having a very good reason to do so.

IMHO,  having everything at the end points (or the end-to-end principle)
has led
to an unsustainable trajectory to expensive and complex network functions
and
end-points.   I have done a rudimentary survey of some of the enterprises I
know and they say that much (if not most) of their time is spent in patching
applications and end points.  This is one reason they cannot look ahead to
bigger tasks like migrating to IPv6.

I completely agree that enterprises have not presented the statistics and a
carefully reasoned study to substantiate the above claims.  I am in the
process of taking a step back to see what we need to do - what drafts we
need to write and what numbers we need to present - to have a full
picture of how Internet protocols are used.

Enterprises are a very large group of users of the Internet protocols and
need to be considered as such.

Nalini

-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 4 Jul 2018 11:37:25 -0400

On Tue, Jul 3, 2018 at 5:19 PM Brian Sniffen <bsniffen=
[email-masked]> wrote:

> all their motivations and evidence to the table.

It's always exciting to see your name in print.  Is there something I can
do to help here?  I honestly have no idea who "folks like me" are, or what
we did that gave you this impression.

> I significantly
> zero.

This is pretty disheartening.

Always happy to discuss in person.  I'll be at the meeting in Montreal.

It means we need to check their work as we go, or actually trust
> [1]
> https://www.cia.gov/library/publications/the-world-factbook/geos/ch.html
>      but see also
> https://www.cia.gov/library/publications/the-world-factbook/geos/tw.html
>
> --
> Brian Sniffen
>

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 4 Jul 2018 09:30:50 -0700

> to attack networks and clients without any level of protection from the

Speaking as an industry practitioner and network security professional,
don't trust the network. That is the entire purpose of TLS.

As one of my present job capacities I micromanage Juniper SRX firewall
rules. However, my personal view of the value provided is that it's a
defense-in-depth measure at best.

There are already many ways for attackers to take surprising and unexpected
paths through the network which are much more interesting and useful than
through a DNS+CDN's frontend terminator. Just as one example of such a path
which is incredibly hard to block is Amazon S3, where you can attempt to
whitelist a particular bucket by hostname, and even try to do NIDS to
ensure that S3 requests only go to mybucket.s3.amazonaws.com by inspecting
SNI and rejecting anything but a particular bucket in the SNI, but after
TLS has been established an attacker can send a Host: header of
attackerbucket.s3.amazonaws.com and S3 doesn't care what domain you used to
get there or what SNI you sent.

> their requirements for regulatory compliance?

I am a co-founder of a technology company, and was formerly on the
information security team of a publicly traded next-gen fintech company.
Speaking as a representative of industry, I would once again like to make
it very clear that demands for "visibility" represent one perspective
within industry as a whole. I think if it were possible to take a hum "from
industry", you would find it quite divided on this topic, particularly
between older larger companies and smaller, newer ones.

Having aided (in some cases instrumentally) with PCI-DSS, HIPAA, and SOX
audits in a modern fintech company with a card storage environment and
massive cash flows to account for and safeguard, my professional opinion as
someone on the information security team for that company is that the net
effect of ESNI on any of the compliance strategies being used is 0.

I think you might get a different perspective from someone whose compliance
strategy is largely predicated on e.g. Blue Coat "Visibility" appliances
who think things like passive SNI inspection are good indicators that
traffic flows are legitimate. However, while I'm aware this approach is
quite popular with e.g. older financial institutions, as noted above with
the S3 example it's still leaky. As long as you have a "legitimate"
frontend that can reach a backend which will honor the Host header over
what's in SNI and can get to both "legitimate" and attacker-controlled
resources, attackers can already bypass things passive SNI inspection.

That said, I think there are very much legitimate enterprise use cases of
this feature (see below).

> approach that Google has done with their BeyondCorp design.

In my opinion BeyondCorp-style designs are considered state-of-the-art by
the security teams of companies I respect, including the public fintech
company I formerly worked at which is presently in the process of migrating
from VPN-based access to a BeyondCorp-style approach.

As someone presently solving this problem for my company, I have recently
deployed Google's Identity Aware Proxy (IAP) to provide "front door"
authentication to internal web applications. IAP works by having you point
DNS at Google's frontend web servers, which terminate HTTPS, check for a
credential, and if it isn't present perform an OAuth flow. It integrates
with the rest of Google's suite of "BeyondCorp" tools including things like
Cloud Identity and Endpoint Verification to ensure all access to internal
tools is both strongly authenticated and coming from a known healthy
endpoint.

The important point here is that everyone using IAP is pointing DNS at the
Google frontend. In conjunction with e.g. Google Domains or GCP Cloud DNS,
IAP could support this approach to ESNI. In a BeyondCorp architecture, ESNI
would provide confidentiality for the DNS names of internal tools being
accessed through IAP. Using something like DoH in conjunction with
dns.google.com, we can completely reduce the parties who are able to
determine which internal tools are being accessed to Google exclusively.

Is there enterprise value to actually protecting this information? Well,
like network security, it is (or at least should be) only defense-in-depth.
But I still see value in defense-in-depth.

As an industry practitioner, from the perspective of the sorts of companies
I work at, I see no downsides of this approach. Instead see an interesting
feature which I want to use.

Framing things in terms of "privacy" versus "industry concerns" is a false
dichotomy, and one we continue to see being perpetrated by the "visibility"
camp, e.g.
https://www.ncsc.gov.uk/blog-post/tls-13-better-individuals-harder-enterprises
(which had an awesome response from agl:
https://www.imperialviolet.org/2018/03/10/tls13.html). They are using this
as a rhetorical tactic to spin the "visibility" debate, when the reality is
that the interests of individuals and enterprises are not at odds. What are
at odds are improving Internet security for everyone versus the interests
of e.g. Blue Coat's customers whose compliance story presently depends on
their ability to break their own security from a single point of
compromise. More modern techniques like endpoint agents, tracing
frameworks, and other observability tools can tick the same compliance
checkboxes and solve the same problems like debugging complicated
service-oriented architectures. But it seems some people stuck on the Blue
Coat model would rather make Internet security worse for everyone than
invest in updating to a more modern approach.

Enterprises can benefit from privacy just as much as individuals. However,
not all enterprises within industry as a whole are ready to take advantage
of it. When seeking out industry input for IETF, make sure you're not only
paying attention to a particularly vocal segment whose views are not
representative of industry as a whole.

-- 
Tony Arcieri