Re: [TLS] Encrypted SNI

[Tony Arcieri]

On Tue, Jul 3, 2018 at 10:08 AM Bret Jordan  wrote:

> 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.
>

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.


> 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?
>

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).


> 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.
>

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 

Re: [TLS] Encrypted SNI

[Ben Schwartz]

On Tue, Jul 3, 2018 at 5:19 PM Brian Sniffen  wrote:

> Hanno Böck  writes:
>
> > 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.
>
> 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.


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
> discount their arguments and expect others to do the same---but not to
> 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
> 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[nalini elkins]

 >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.

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


On Wed, Jul 4, 2018 at 1:54 AM, Hanno Böck  wrote:

> 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: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Paul Wouters]

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 :)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Eric Rescorla]

On Tue, Jul 3, 2018 at 10:08 AM, Bret Jordan  wrote:

> From a discussion on the PATIENT list found here: https://www.ietf.org/mai
> l-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?
>

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

-Ekr



> 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  at gmail.com> wrote:
>
>> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla  wrote:
>> >
>> >
>> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski > ..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
>>
>> 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 > yaanatech.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-twitte
>> r-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
>> >>
>> 

Re: [TLS] Encrypted SNI

[Kathleen Moriarty]

On Tue, Jul 3, 2018 at 3:49 PM, Benjamin Kaduk
 wrote:
> On Tue, Jul 03, 2018 at 11:08:21AM -0600, Bret Jordan 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.
>
> BCP 61 leads us to not expect any protection from the network, does it not?
>
>> 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.
>
> 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.

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

>
> -Ben
>
>> 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 > gmail.com > wrote:
>> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla > > wrote:
>> >
>> >
>> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski 
>> > 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 
>> 
>>
>> 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, 

Re: [TLS] Encrypted SNI

[Darin Pettis]

+1



On Tue, Jul 3, 2018 at 12:08 PM Bret Jordan  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
> 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  at gmail.com> wrote:
>
>> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla  wrote:
>> >
>> >
>> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski > ..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
>>
>> 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 > yaanatech.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
>> >>>
>> >>> 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 

Re: [TLS] Encrypted SNI

[Benjamin Kaduk]

On Tue, Jul 03, 2018 at 11:08:21AM -0600, Bret Jordan 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. 

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

> 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.  

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

> 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  gmail.com > wrote:
> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla  > wrote:
> >
> >
> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski 
> > 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 
> 
> 
> 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  >> >
> >> 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
> >>>  
> >>> 
> >>>
> >>> 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
> 

Re: [TLS] Encrypted SNI

[Ackermann, Michael]

+1

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Bret Jordan
Sent: Tuesday, July 3, 2018 1:08 PM
To: tls@ietf.org
Subject: [TLS] Encrypted SNI

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
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 mailto:kathleen.moriarty.ietf%20at%20gmail.com>> wrote:

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

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 > 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
>>>
>>> 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
>> 

[TLS] Encrypted SNI

[Bret Jordan]

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
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 mailto:kathleen.moriarty.ietf%20at%20gmail.com>> wrote:
On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla mailto:ekr%20at%20rtfm.com>> wrote:
>
>
> On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski 
> 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 


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 > >
>> 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
>>>  
>>> 
>>>
>>> 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 

Re: [TLS] Encrypted SNI hangout

[Eric Rescorla]

I already have a conflict for this, so I will not be attending.

-Ekr


On Mon, Nov 13, 2017 at 3:57 AM, Darin Pettis  wrote:

> Sean - thank you for the update and options on rooms.
>
> Ben and Brett - which room should we meet in?
>
> Initially opposed to encrypting SNI as it appears to break many services
> that utilize it but curious to hear more.   Thx
>
> On Mon, Nov 13, 2017 at 9:17 AM Christian Huitema 
> wrote:
>
>> On 11/12/2017 4:54 PM, Sean Turner wrote:
>>
>> > Hi!  I applaud the initiative for suggesting the hangout [0].
>> Squatting in that room ought to be okay but in case the secretariat ends up
>> scheduling another IETF session in that room the 12 person room
>> (Butterworth) is still available during that time:
>> > https://www.ietf.org/registration/MeetingWiki/wiki/
>> doku.php?id=100sidemeetings2
>> > It can be scheduled through the following link:
>> > https://ietf.org/meeting/amreq.html
>> >
>> > Cheers,
>> >
>> > spt
>> >
>> > [0] For those more process oriented folks, Ben and Bret correctly
>> identified this as a hangout.  it’s not a WG session that got canceled.
>> >
>>
>> The SNI Encryption draft is maintained on the TLS WG Github, at
>> https://github.com/tlswg/sniencryption. It would be really nice if after
>> or during the discussions someone opened issues and possibly PR.
>>
>> Thanks, and sorry I could not join you in Singapore
>>
>> -- Christian Huitema
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI hangout

[Darin Pettis]

Sean - thank you for the update and options on rooms.

Ben and Brett - which room should we meet in?

Initially opposed to encrypting SNI as it appears to break many services
that utilize it but curious to hear more.   Thx

On Mon, Nov 13, 2017 at 9:17 AM Christian Huitema 
wrote:

> On 11/12/2017 4:54 PM, Sean Turner wrote:
>
> > Hi!  I applaud the initiative for suggesting the hangout [0].  Squatting
> in that room ought to be okay but in case the secretariat ends up
> scheduling another IETF session in that room the 12 person room
> (Butterworth) is still available during that time:
> >
> https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100sidemeetings2
> > It can be scheduled through the following link:
> > https://ietf.org/meeting/amreq.html
> >
> > Cheers,
> >
> > spt
> >
> > [0] For those more process oriented folks, Ben and Bret correctly
> identified this as a hangout.  it’s not a WG session that got canceled.
> >
>
> The SNI Encryption draft is maintained on the TLS WG Github, at
> https://github.com/tlswg/sniencryption. It would be really nice if after
> or during the discussions someone opened issues and possibly PR.
>
> Thanks, and sorry I could not join you in Singapore
>
> -- Christian Huitema
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI hangout

[Christian Huitema]

On 11/12/2017 4:54 PM, Sean Turner wrote:

> Hi!  I applaud the initiative for suggesting the hangout [0].  Squatting in 
> that room ought to be okay but in case the secretariat ends up scheduling 
> another IETF session in that room the 12 person room (Butterworth) is still 
> available during that time:
> https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100sidemeetings2
> It can be scheduled through the following link:
> https://ietf.org/meeting/amreq.html
>
> Cheers,
>
> spt
>
> [0] For those more process oriented folks, Ben and Bret correctly identified 
> this as a hangout.  it’s not a WG session that got canceled.
>

The SNI Encryption draft is maintained on the TLS WG Github, at
https://github.com/tlswg/sniencryption. It would be really nice if after
or during the discussions someone opened issues and possibly PR.

Thanks, and sorry I could not join you in Singapore

-- Christian Huitema

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI hangout

[Sean Turner]

Hi!  I applaud the initiative for suggesting the hangout [0].  Squatting in 
that room ought to be okay but in case the secretariat ends up scheduling 
another IETF session in that room the 12 person room (Butterworth) is still 
available during that time:
https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100sidemeetings2
It can be scheduled through the following link:
https://ietf.org/meeting/amreq.html

Cheers,

spt

[0] For those more process oriented folks, Ben and Bret correctly identified 
this as a hangout.  it’s not a WG session that got canceled.

> On Nov 12, 2017, at 22:16, Ben Schwartz  wrote:
> 
> Let's meet in the room TLS would have had (Padang) for an informal discussion 
> about encrypted SNI.
> 
> On Sun, Nov 12, 2017 at 12:57 AM, Bret Jordan  wrote:
> All,
> 
> Since the TLS session on Monday got canceled what would people think about 
> using that time to talk about encrypted SNI?  
> 
> Bret 
> 
> Sent from my Commodore 128D
> 
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Encrypted SNI hangout

[Bret Jordan]

All,

Since the TLS session on Monday got canceled what would people think about 
using that time to talk about encrypted SNI?  

Bret 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Eric Rescorla]

On Wed, Jun 7, 2017 at 4:53 AM, Toerless Eckert  wrote:

>
> Thanks. Just in case anyone is counting
> I think thats a bad choice that limits the usefulness of 1.3. And it will
> just
> cause less security in systems where logging etc. is required than if this
> was possible by apps to configure.
>
> Why can i negotiate a cipher suite without encryption but not disable cert
> encryption ?
>

You won't be able to do that in TLS 1.3 either. We've removed all the
non-encryption
cipher suites (though someone could define more off the Standards Track).

However, with that said, I don't think that this is a very good analogy.
Having
unencrypted certs even as an options would significantly impact the state
machine,
whereas null ciphers do not

-Ekr




> The argument you gave could equally be made to not permit a cipher suite
> without encryption,
> right ?
>


> Cheers
> Toerless
>
> On Tue, Jun 06, 2017 at 09:59:16PM -0400, Dave Garrett wrote:
> > Correct; certs are never in the clear. There is no scenario where
> anything will be unencrypted after the hellos in TLS 1.3+. If you're doing
> anything with an old system that relies on this, the general advice is to
> upgrade your old system to not do that anymore. If you're logging traffic
> from some server(s), log the traffic on those server(s) instead of MitMing.
> See old threads for more detail.
> >
> >
> > Dave
> >
> >
> > On Tuesday, June 06, 2017 08:36:38 pm Toerless Eckert wrote:
> > > So no options in TLS 1.3 that make it possible to see the server cert
> in the clear ?
> > >
> > > On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote:
> > > > On 06/02/2017 08:28 AM, Toerless Eckert wrote:
> > > > > Another candidate use case coming to mind eg: auditing tht is
> required in many eg: financial
> > > > > environments. In the past i have seen even the requirement for the
> whole data streams to be unencrypted
> > > > > for auditing. Maybe that market segment would also be able to get
> more privacy but maintain a
> > > > > relevant level of auditing if the auditing relevant class of
> information was visible via
> > > > > the cert.
> > > >
> > > > That use case has been extensively discussed (look for the thread
> > > > "Industry Concerns about TLS 1.3", also a fair bit of hallway
> > > > discussions), and was not seen to provide a compelling argument for
> any
> > > > change in TLS 1.3.  There are purely server-side options that should
> be
> > > > able to provide the necessary functionality (crypto details omitted
> for
> > > > now).
>
> --
> ---
> t...@cs.fau.de
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Toerless Eckert]

Thanks. Just in case anyone is counting
I think thats a bad choice that limits the usefulness of 1.3. And it will just
cause less security in systems where logging etc. is required than if this
was possible by apps to configure.

Why can i negotiate a cipher suite without encryption but not disable cert 
encryption ?
The argument you gave could equally be made to not permit a cipher suite 
without encryption,
right ?  

Cheers
Toerless

On Tue, Jun 06, 2017 at 09:59:16PM -0400, Dave Garrett wrote:
> Correct; certs are never in the clear. There is no scenario where anything 
> will be unencrypted after the hellos in TLS 1.3+. If you're doing anything 
> with an old system that relies on this, the general advice is to upgrade your 
> old system to not do that anymore. If you're logging traffic from some 
> server(s), log the traffic on those server(s) instead of MitMing. See old 
> threads for more detail.
> 
> 
> Dave
> 
> 
> On Tuesday, June 06, 2017 08:36:38 pm Toerless Eckert wrote:
> > So no options in TLS 1.3 that make it possible to see the server cert in 
> > the clear ?
> > 
> > On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote:
> > > On 06/02/2017 08:28 AM, Toerless Eckert wrote:
> > > > Another candidate use case coming to mind eg: auditing tht is required 
> > > > in many eg: financial
> > > > environments. In the past i have seen even the requirement for the 
> > > > whole data streams to be unencrypted
> > > > for auditing. Maybe that market segment would also be able to get more 
> > > > privacy but maintain a
> > > > relevant level of auditing if the auditing relevant class of 
> > > > information was visible via
> > > > the cert.
> > > 
> > > That use case has been extensively discussed (look for the thread
> > > "Industry Concerns about TLS 1.3", also a fair bit of hallway
> > > discussions), and was not seen to provide a compelling argument for any
> > > change in TLS 1.3.  There are purely server-side options that should be
> > > able to provide the necessary functionality (crypto details omitted for
> > > now).

-- 
---
t...@cs.fau.de

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Dave Garrett]

Correct; certs are never in the clear. There is no scenario where anything will 
be unencrypted after the hellos in TLS 1.3+. If you're doing anything with an 
old system that relies on this, the general advice is to upgrade your old 
system to not do that anymore. If you're logging traffic from some server(s), 
log the traffic on those server(s) instead of MitMing. See old threads for more 
detail.


Dave


On Tuesday, June 06, 2017 08:36:38 pm Toerless Eckert wrote:
> So no options in TLS 1.3 that make it possible to see the server cert in the 
> clear ?
> 
> On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote:
> > On 06/02/2017 08:28 AM, Toerless Eckert wrote:
> > > Another candidate use case coming to mind eg: auditing tht is required in 
> > > many eg: financial
> > > environments. In the past i have seen even the requirement for the whole 
> > > data streams to be unencrypted
> > > for auditing. Maybe that market segment would also be able to get more 
> > > privacy but maintain a
> > > relevant level of auditing if the auditing relevant class of information 
> > > was visible via
> > > the cert.
> > 
> > That use case has been extensively discussed (look for the thread
> > "Industry Concerns about TLS 1.3", also a fair bit of hallway
> > discussions), and was not seen to provide a compelling argument for any
> > change in TLS 1.3.  There are purely server-side options that should be
> > able to provide the necessary functionality (crypto details omitted for
> > now).

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Toerless Eckert]

So no options in TLS 1.3 that make it possible to see the server cert in the 
clear ?

On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote:
> On 06/02/2017 08:28 AM, Toerless Eckert wrote:
> > Another candidate use case coming to mind eg: auditing tht is required in 
> > many eg: financial
> > environments. In the past i have seen even the requirement for the whole 
> > data streams to be unencrypted
> > for auditing. Maybe that market segment would also be able to get more 
> > privacy but maintain a
> > relevant level of auditing if the auditing relevant class of information 
> > was visible via
> > the cert.
> 
> That use case has been extensively discussed (look for the thread
> "Industry Concerns about TLS 1.3", also a fair bit of hallway
> discussions), and was not seen to provide a compelling argument for any
> change in TLS 1.3.  There are purely server-side options that should be
> able to provide the necessary functionality (crypto details omitted for
> now).
> 
> -Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Benjamin Kaduk]

On 06/02/2017 08:28 AM, Toerless Eckert wrote:
> Another candidate use case coming to mind eg: auditing tht is required in 
> many eg: financial
> environments. In the past i have seen even the requirement for the whole data 
> streams to be unencrypted
> for auditing. Maybe that market segment would also be able to get more 
> privacy but maintain a
> relevant level of auditing if the auditing relevant class of information was 
> visible via
> the cert.

That use case has been extensively discussed (look for the thread
"Industry Concerns about TLS 1.3", also a fair bit of hallway
discussions), and was not seen to provide a compelling argument for any
change in TLS 1.3.  There are purely server-side options that should be
able to provide the necessary functionality (crypto details omitted for
now).

-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Ilari Liusvaara]

On Fri, Jun 02, 2017 at 03:28:33PM +0200, Toerless Eckert wrote:
> On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote:
> > > If a web service hoster does not provide any useful demultiplexer then it
> > > can of course not
> > > expect not to get blacklisted across services. Is it not already common
> > > practice to assign
> > > separate certificates to separate "web customers" ?
> > 
> > No. It's typically the opposite.
> 
> Thanks.
> 
> Btw: does TLS 1.3 mandate server side cert encryption or is this something 
> server
> apps can decide ? 

It is required.

Of server messages, TLS 1.3 only leaves ServerHello unencrypted. SH
contains low-level connection parameters:

- TLS version used
- Server random value
- Record protection / PRF algorithm used
- DH key share (if DH is used).
- PSK identity selected (if PSK is used).


The certificate is sent in certificate message, which is always
protected (encrypted).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Eric Rescorla]

On Fri, Jun 2, 2017 at 6:28 AM, Toerless Eckert  wrote:

> On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote:
> > > If a web service hoster does not provide any useful demultiplexer then
> it
> > > can of course not
> > > expect not to get blacklisted across services. Is it not already common
> > > practice to assign
> > > separate certificates to separate "web customers" ?
> >
> > No. It's typically the opposite.
>
> Thanks.
>
> Btw: does TLS 1.3 mandate server side cert encryption or is this something
> server
> apps can decide ?


It mandates it.



> Just because shared web services may not yet leverage the ability to
> use certs to authenticate network connections well doesn't mean that that
> option should not
> be given to apps. And it would be sad if one would have to revert to older
> protocol options
> to have that functionality.
>

That functionality is illusory even now, because they are unable to
determine
that the server and the client are not colluding to lie about the server's
identity.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Toerless Eckert]

On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote:
> > If a web service hoster does not provide any useful demultiplexer then it
> > can of course not
> > expect not to get blacklisted across services. Is it not already common
> > practice to assign
> > separate certificates to separate "web customers" ?
> 
> No. It's typically the opposite.

Thanks.

Btw: does TLS 1.3 mandate server side cert encryption or is this something 
server
apps can decide ? Just because shared web services may not yet leverage the 
ability to
use certs to authenticate network connections well doesn't mean that that 
option should not
be given to apps. And it would be sad if one would have to revert to older 
protocol options
to have that functionality.

Another candidate use case coming to mind eg: auditing tht is required in many 
eg: financial
environments. In the past i have seen even the requirement for the whole data 
streams to be unencrypted
for auditing. Maybe that market segment would also be able to get more privacy 
but maintain a
relevant level of auditing if the auditing relevant class of information was 
visible via
the cert.

Cheers
Toerless

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Ryan Sleevi]

On Fri, Jun 2, 2017 at 6:31 AM, Toerless Eckert  wrote:

> On Fri, Jun 02, 2017 at 01:16:01PM +0300, Richard Barnes wrote:
> > Operators trying to do this by inspecting TLS (and not decrypting) are
> > going to have a bad time anyway.  With HTTP/2 connection coalescing, even
> > if they can see the certificate, the actual HTTP request could be for any
> > name in the certificate.  So there's nothing really gained by exposing
> the
> > certificate.
>
> If a web service hoster does not provide any useful demultiplexer then it
> can of course not
> expect not to get blacklisted across services. Is it not already common
> practice to assign
> separate certificates to separate "web customers" ?
>

No. It's typically the opposite.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Toerless Eckert]

On Fri, Jun 02, 2017 at 01:16:01PM +0300, Richard Barnes wrote:
> Operators trying to do this by inspecting TLS (and not decrypting) are
> going to have a bad time anyway.  With HTTP/2 connection coalescing, even
> if they can see the certificate, the actual HTTP request could be for any
> name in the certificate.  So there's nothing really gained by exposing the
> certificate.

If a web service hoster does not provide any useful demultiplexer then it can 
of course not
expect not to get blacklisted across services. Is it not already common 
practice to assign
separate certificates to separate "web customers" ?

--Toerless

> --Richard
> 
> 
> 
> > As soon as the IP address used to host a web-service runs
> > multiple web-services (domain-names), this is today done by inspecting the
> > TLS 1.2 server certificate
> > or SNI.
> >
> > Web hosters whose services do share IP addresses across domain name should
> > be very interested to
> > ensure such inspection works, because else a single misbehaving
> > web-service they host will easily
> > cause all their web-services to be blacklisted by any of the varied
> > organizations that create
> > blacklists: because blacklisting can then only be applied on a per-IP
> > address.
> >
> > Of course, IPv6 could make this need somewhat obsolete because there
> > should be no reason to
> > share IPv6 addresses across domain-names, but i am not aware what todays
> > common practice are with IPv6
> > in this respect.
> >
> > Cheers
> > Toerless
> >
> > On Thu, Jun 01, 2017 at 04:38:46PM +0200, Benoit Claise wrote:
> > > Dear all,
> > >
> > > You should be aware that the TLS list is debating encrypting SNI so
> > > that the host name cannot be seen from TLS sessions.
> > > https://www.ietf.org/mail-archive/web/tls/current/msg23251.htm
> > >
> > > If you're aware of valid (valid in the IETF-sense) operational
> > > practices that require the host name visible, we should enter the
> > > debate.
> > >
> > > Regards, Benoit
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >

-- 
---
t...@cs.fau.de

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Richard Barnes]

On Fri, Jun 2, 2017 at 11:43 AM, Toerless Eckert  wrote:

> Thanks, Benoit
>
> [hope it's ok. to cross-port and redirect replies to TLS]
>
> I have not followed TLS 1.3 in detail, so a quick question first:
>
> Will TLS 1.3 still permit servers to send their certificate and/or SNI in
> the clear as an option or
> will it force server operators to encrypt either/or ? If it does not
> permit server applications
> to indicate what to encrypt, then i would really love to know which shared
> web-hosters did
> explicitly express support for TLS 1.3.
>
> Use case: (i can't believe this hasn't been discussed _forever_, but i do
> not subscribe to TLS...)
>
> Operators of "client-side" networks want to be able to enforce policies
> which "web-services"
> their clients can communicate with.


Operators trying to do this by inspecting TLS (and not decrypting) are
going to have a bad time anyway.  With HTTP/2 connection coalescing, even
if they can see the certificate, the actual HTTP request could be for any
name in the certificate.  So there's nothing really gained by exposing the
certificate.

--Richard



> As soon as the IP address used to host a web-service runs
> multiple web-services (domain-names), this is today done by inspecting the
> TLS 1.2 server certificate
> or SNI.
>
> Web hosters whose services do share IP addresses across domain name should
> be very interested to
> ensure such inspection works, because else a single misbehaving
> web-service they host will easily
> cause all their web-services to be blacklisted by any of the varied
> organizations that create
> blacklists: because blacklisting can then only be applied on a per-IP
> address.
>
> Of course, IPv6 could make this need somewhat obsolete because there
> should be no reason to
> share IPv6 addresses across domain-names, but i am not aware what todays
> common practice are with IPv6
> in this respect.
>
> Cheers
> Toerless
>
> On Thu, Jun 01, 2017 at 04:38:46PM +0200, Benoit Claise wrote:
> > Dear all,
> >
> > You should be aware that the TLS list is debating encrypting SNI so
> > that the host name cannot be seen from TLS sessions.
> > https://www.ietf.org/mail-archive/web/tls/current/msg23251.htm
> >
> > If you're aware of valid (valid in the IETF-sense) operational
> > practices that require the host name visible, we should enter the
> > debate.
> >
> > Regards, Benoit
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Ilari Liusvaara]

On Fri, Jun 02, 2017 at 10:43:00AM +0200, Toerless Eckert wrote:
> Thanks, Benoit
> 
> [hope it's ok. to cross-port and redirect replies to TLS]
> 
> I have not followed TLS 1.3 in detail, so a quick question first:
> 
> Will TLS 1.3 still permit servers to send their certificate and/or SNI in the 
> clear as an option or
> will it force server operators to encrypt either/or ? If it does not permit 
> server applications
> to indicate what to encrypt, then i would really love to know which shared 
> web-hosters did
> explicitly express support for TLS 1.3.

SNI is always in the clear, certificates are always encrypted.

There was lots of discussion about SNI encryption, but encrypting SNI
turned out to be too nasty.
 
> Web hosters whose services do share IP addresses across domain name should be 
> very interested to
> ensure such inspection works, because else a single misbehaving web-service 
> they host will easily
> cause all their web-services to be blacklisted by any of the varied 
> organizations that create 
> blacklists: because blacklisting can then only be applied on a per-IP address.

At least GSB can blacklist even at page granularity (I have seen such
blacklisting, in that case due to images being loaded from "shady"
sites.)


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Toerless Eckert]

Thanks, Benoit

[hope it's ok. to cross-port and redirect replies to TLS]

I have not followed TLS 1.3 in detail, so a quick question first:

Will TLS 1.3 still permit servers to send their certificate and/or SNI in the 
clear as an option or
will it force server operators to encrypt either/or ? If it does not permit 
server applications
to indicate what to encrypt, then i would really love to know which shared 
web-hosters did
explicitly express support for TLS 1.3.

Use case: (i can't believe this hasn't been discussed _forever_, but i do not 
subscribe to TLS...)

Operators of "client-side" networks want to be able to enforce policies which 
"web-services"
their clients can communicate with. As soon as the IP address used to host a 
web-service runs
multiple web-services (domain-names), this is today done by inspecting the TLS 
1.2 server certificate
or SNI. 

Web hosters whose services do share IP addresses across domain name should be 
very interested to
ensure such inspection works, because else a single misbehaving web-service 
they host will easily
cause all their web-services to be blacklisted by any of the varied 
organizations that create 
blacklists: because blacklisting can then only be applied on a per-IP address.

Of course, IPv6 could make this need somewhat obsolete because there should be 
no reason to
share IPv6 addresses across domain-names, but i am not aware what todays common 
practice are with IPv6
in this respect.

Cheers
Toerless

On Thu, Jun 01, 2017 at 04:38:46PM +0200, Benoit Claise wrote:
> Dear all,
> 
> You should be aware that the TLS list is debating encrypting SNI so
> that the host name cannot be seen from TLS sessions.
> https://www.ietf.org/mail-archive/web/tls/current/msg23251.htm
> 
> If you're aware of valid (valid in the IETF-sense) operational
> practices that require the host name visible, we should enter the
> debate.
> 
> Regards, Benoit

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Viktor Dukhovni]

On Thu, May 11, 2017 at 08:01:58PM +0200, Hubert Kario wrote:

> > But beware of:
> > 
> >   - the adversary can replay this SNI and see what site he gets
> >   - DDoS risk: servers can't be try lots of crypto (no asymmetric ops,
> > no operations that scale linearly with number of sites hosted)
> 
> Doesn't that create a Catch 22?
> 
> I need to get the key to encrypt the SNI. But if we don't want the names to 
> leak, how do I authenticate the key without telling the server what 
> certificate I will accept to authenticate the key?
> 
> That doesn't look to me like a problem we can solve with typical symmetric or 
> asymmetric crypto - it looks to me like more of a zero-knowledge proof issue.

No zero-knowledge schemes come to mind that are suitable to this task.

What can work, but costs latency is to do anon-(EC)DH key agreement
first, and only *then* exchange certificates under the established
keys and sign the session transcripts as required.  That is enable
encryption first, and authentication second, with SNI sent after
you have an unauthenticated encrypted channel.

Yes, an active MiTM attack could capture the SNI, but it would
prevent full session establishment, and so would be tamper-evident.

(One might imagine that initial opportunistic crypto being TCPinc,
with channel bindings extracted into a light-weight authentication
protocol on top, that no longer needs to do the key agreement bits).

The TLS 1.3 draft protocol, while eschewing weaker crypto primitives,
seems optimized more for lower-latency than for greater resistance
to traffic analysis.  I don't think that you can have both.

To really address the issue, one needs a more complete architecture,
that combines all the relevant bits of TCP, TLS and HTTP, 
Such holistic (r)evolution is extremely difficult.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Hubert Kario]

On Thursday, 11 May 2017 16:31:26 CEST Brian Sniffen wrote:
> Daniel Kahn Gillmor  writes:
> > On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
> >> It certainly was. But then the clear text SNI is a gaping privacy hole
> >> in TLS, the kind of issue that should keep us awake at night until it is
> >> resolved. We need to make sure that we make progress, rather than rehash
> >> the old arguments. Maybe we should invest some time and document the
> >> various proposals in a draft. I am willing to work on that. Any other
> >> volunteers?
> > 
> > I agree with Christian's assessment of the problem, and i'd be
> > interested in collaborating on such a draft.
> 
> Who's the audience for that draft?  If it's meant to document the blind
> alleys we've found, perhaps we could list both alleys, and the walls at
> the end:
> 
>   - hash the name [adversaries can hash too]
>   - hash the name with a salt [adversaries can check the salted hash
> too, as if operating all the banned sites]
>   - encrypt the SNI under the pre-shared key
> 
> But beware of:
> 
>   - the adversary can replay this SNI and see what site he gets
>   - DDoS risk: servers can't be try lots of crypto (no asymmetric ops,
> no operations that scale linearly with number of sites hosted)

Doesn't that create a Catch 22?

I need to get the key to encrypt the SNI. But if we don't want the names to 
leak, how do I authenticate the key without telling the server what 
certificate I will accept to authenticate the key?

That doesn't look to me like a problem we can solve with typical symmetric or 
asymmetric crypto - it looks to me like more of a zero-knowledge proof issue.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Brian Sniffen]

Daniel Kahn Gillmor  writes:

> On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
>> It certainly was. But then the clear text SNI is a gaping privacy hole
>> in TLS, the kind of issue that should keep us awake at night until it is
>> resolved. We need to make sure that we make progress, rather than rehash
>> the old arguments. Maybe we should invest some time and document the
>> various proposals in a draft. I am willing to work on that. Any other
>> volunteers?
>
> I agree with Christian's assessment of the problem, and i'd be
> interested in collaborating on such a draft.

Who's the audience for that draft?  If it's meant to document the blind
alleys we've found, perhaps we could list both alleys, and the walls at
the end:

  - hash the name [adversaries can hash too]
  - hash the name with a salt [adversaries can check the salted hash
too, as if operating all the banned sites]
  - encrypt the SNI under the pre-shared key

But beware of:

  - the adversary can replay this SNI and see what site he gets
  - DDoS risk: servers can't be try lots of crypto (no asymmetric ops,
no operations that scale linearly with number of sites hosted)
  - not everybody's going to do this, not even every TLS 1.3 instance
  - if networks can't track activity, some will push users to stay on
TLS 1.2.

-Brian

-- 
Brian Sniffen
Akamai Technologies

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Hubert Kario]

On Wednesday, 10 May 2017 21:04:53 CEST Viktor Dukhovni wrote:
> > On May 10, 2017, at 2:47 PM, Hubert Kario  wrote:
> > 
> > But in general, I wonder if we didn't approach the SNI from the wrong side
> > - as I said, we may not need to encrypt it, we just make sure that client
> > and server agree on the virtual host the connection is going to.
> 
> They can do that with a name in the clear.  If the name is to be hidden
> from passive observers, then you do need encryption so that only the
> client and server, and not the passive observers, can recover the name.

You are going in the exact direction I'm saying we should not go, for the same 
reason you said:

> I do believe this was discussed at some length previously.

There are multiple schemes that allow the peers to make sure that both of them 
mean X without outright saying "X". Salting and hashing is one, including it 
in key exchange, (SRP style) is another.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Daniel Kahn Gillmor]

On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
> It certainly was. But then the clear text SNI is a gaping privacy hole
> in TLS, the kind of issue that should keep us awake at night until it is
> resolved. We need to make sure that we make progress, rather than rehash
> the old arguments. Maybe we should invest some time and document the
> various proposals in a draft. I am willing to work on that. Any other
> volunteers?

I agree with Christian's assessment of the problem, and i'd be
interested in collaborating on such a draft.

The DNS folks are making strides to protect name information (the other
main place where this kind of data is leaking).  TLS needs to keep up.

--dkg

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Roland Zink]

Not necessarily as you may for example use the path part of a URL to 
distinguish between services.



Roland




Am 10.05.2017 um 23:50 schrieb Christian Huitema:


On 5/10/2017 2:40 PM, Roland Zink wrote:

The SNI extension is optional, so you don't have to send the literal
value. Indeed quite some number of apps do not send it. Browsers
currently can't know if the SNI is required by the origin servers and
usually send this, but there could be some signal to not send it. One
example could be a HTTP header to tell the browser that SNI should be
send and if it isn't present then no SNI is send. Unfortunately this
would break current sites but still it can be done the other way
around e.g. send a header to not send SNI.

Yes. But this is only possible when each service has a separate IP
address. The privacy gain occurs precisely when several services share
the same address, but that's exactly when the SNI is required. If the
SNI was somehow encrypted, adversaries would not be able to use it to
find which service the user is connecting to.

-- Christian Huitema



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Christian Huitema]

On 5/10/2017 2:40 PM, Roland Zink wrote:
> The SNI extension is optional, so you don't have to send the literal
> value. Indeed quite some number of apps do not send it. Browsers
> currently can't know if the SNI is required by the origin servers and
> usually send this, but there could be some signal to not send it. One
> example could be a HTTP header to tell the browser that SNI should be
> send and if it isn't present then no SNI is send. Unfortunately this
> would break current sites but still it can be done the other way
> around e.g. send a header to not send SNI.

Yes. But this is only possible when each service has a separate IP
address. The privacy gain occurs precisely when several services share
the same address, but that's exactly when the SNI is required. If the
SNI was somehow encrypted, adversaries would not be able to use it to
find which service the user is connecting to.

-- Christian Huitema

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Roland Zink]

The SNI extension is optional, so you don't have to send the literal 
value. Indeed quite some number of apps do not send it. Browsers 
currently can't know if the SNI is required by the origin servers and 
usually send this, but there could be some signal to not send it. One 
example could be a HTTP header to tell the browser that SNI should be 
send and if it isn't present then no SNI is send. Unfortunately this 
would break current sites but still it can be done the other way around 
e.g. send a header to not send SNI.


Regards,

Roland


Am 10.05.2017 um 19:28 schrieb Hubert Kario:

Yes, encrypted SNI was discussed and ultimately rejected.

But do we really have to send the literal value? Don't we need to just make
sure that the client and server agree on the host that the client wants to
connect?

Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending
the salt and the resulting hash, making the server calculate the same hash
with each of the virtual host names it supports and comparing with the client
provided value?

(apologies if that was already proposed and rejected)


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Ilari Liusvaara]

On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote:
> Yes, encrypted SNI was discussed and ultimately rejected.
> 
> But do we really have to send the literal value? Don't we need to just make 
> sure that the client and server agree on the host that the client wants to 
> connect?
> 
> Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending 
> the salt and the resulting hash, making the server calculate the same hash 
> with each of the virtual host names it supports and comparing with the client 
> provided value?

What makes encrypting SNI nasty is replay attacks.

There also was proposal for putting SNI mapping into DNS (which limits the
leakage if DNS lookups are private). However, I came up with a way to use
that to attack HTTPS (the usual "default vhost" attacks).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Benjamin Kaduk]

On 05/10/2017 02:12 PM, Christian Huitema wrote:
>
> On 5/10/2017 12:04 PM, Viktor Dukhovni wrote:
>>> On May 10, 2017, at 2:47 PM, Hubert Kario  wrote:
>>>
>>> But in general, I wonder if we didn't approach the SNI from the wrong side 
>>> - 
>>> as I said, we may not need to encrypt it, we just make sure that client and 
>>> server agree on the virtual host the connection is going to.
>> They can do that with a name in the clear.  If the name is to be hidden
>> from passive observers, then you do need encryption so that only the
>> client and server, and not the passive observers, can recover the name.
>>
>> Encryption means key agreement, and requires delaying SNI by a round-trip,
>> or having published DH shares in DNS, which of course also needs privacy
>> protection for SNI encryption to matter.
>>
>> I do believe this was discussed at some length previously.
> It certainly was. But then the clear text SNI is a gaping privacy hole
> in TLS, the kind of issue that should keep us awake at night until it is
> resolved. We need to make sure that we make progress, rather than rehash
> the old arguments. Maybe we should invest some time and document the
> various proposals in a draft. I am willing to work on that. Any other
> volunteers?
>

It seems like there are a number of ways to encrypt the SNI for the
*second* (and subsequent) exchange with a given server; I have one that
I have some notes on and might try to write up.  But do we think that's
worth doing, or do we want to also provide protection for the initial
contact?  It seems like there is a qualitative difference, there...

-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Christian Huitema]

On 5/10/2017 12:04 PM, Viktor Dukhovni wrote:
>> On May 10, 2017, at 2:47 PM, Hubert Kario  wrote:
>>
>> But in general, I wonder if we didn't approach the SNI from the wrong side - 
>> as I said, we may not need to encrypt it, we just make sure that client and 
>> server agree on the virtual host the connection is going to.
> They can do that with a name in the clear.  If the name is to be hidden
> from passive observers, then you do need encryption so that only the
> client and server, and not the passive observers, can recover the name.
>
> Encryption means key agreement, and requires delaying SNI by a round-trip,
> or having published DH shares in DNS, which of course also needs privacy
> protection for SNI encryption to matter.
>
> I do believe this was discussed at some length previously.
It certainly was. But then the clear text SNI is a gaping privacy hole
in TLS, the kind of issue that should keep us awake at night until it is
resolved. We need to make sure that we make progress, rather than rehash
the old arguments. Maybe we should invest some time and document the
various proposals in a draft. I am willing to work on that. Any other
volunteers?

-- Christian Huitema

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Salz, Rich]

> Encryption means key agreement, and requires delaying SNI by a round-trip,
> or having published DH shares in DNS, which of course also needs privacy
> protection for SNI encryption to matter.

With TLS1.3 encryptedExtensions, secure "domain fronting" becomes possible.  

A am long overdue for a writeup on this.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Encrypted" SNI

[Viktor Dukhovni]

> On May 10, 2017, at 2:47 PM, Hubert Kario  wrote:
> 
> But in general, I wonder if we didn't approach the SNI from the wrong side - 
> as I said, we may not need to encrypt it, we just make sure that client and 
> server agree on the virtual host the connection is going to.

They can do that with a name in the clear.  If the name is to be hidden
from passive observers, then you do need encryption so that only the
client and server, and not the passive observers, can recover the name.

Encryption means key agreement, and requires delaying SNI by a round-trip,
or having published DH shares in DNS, which of course also needs privacy
protection for SNI encryption to matter.

I do believe this was discussed at some length previously.

-- 
-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] "Encrypted" SNI

[Hubert Kario]

Yes, encrypted SNI was discussed and ultimately rejected.

But do we really have to send the literal value? Don't we need to just make 
sure that the client and server agree on the host that the client wants to 
connect?

Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending 
the salt and the resulting hash, making the server calculate the same hash 
with each of the virtual host names it supports and comparing with the client 
provided value?

(apologies if that was already proposed and rejected)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Salz, Rich]

> I'm not sure I understand the design you're suggesting.

Does the EncryptedExtensions contain the entire hello for the "next hop"?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Eric Rescorla]

On Sun, Dec 6, 2015 at 6:46 AM, Salz, Rich  wrote:

> > I'm not sure I understand the design you're suggesting.
>
> Does the EncryptedExtensions contain the entire hello for the "next hop"?
>

No. It (at most) says "the stuff that is post-handshake is actually a
ClientHello for the next hop". I.e., it's literally TLS in TLS.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Jacob Appelbaum]

On 12/6/15, Dave Garrett  wrote:
> On Saturday, December 05, 2015 08:58:58 pm Salz, Rich wrote:
>> Can we embed an EncryptedExtension inside an existing EE?  That would let
>> us do TOR purely within TLS, right?
>
> If clients are allowed to send any encrypted extensions other than the
> tunneling extension (that contains the tunneled hello), then we would have
> to allow sending an EncryptedExtension through it, otherwise tunneled peers
> would have less capabilities than non-tunneled. I don't see anything in this
> design that would prohibit recursively doing this as many times as desired.
> (e.g. tunnel of a tunnel of a tunnel of a...) That does sound somewhat
> TOR-like, though obviously, lots more would be needed to actually do
> anything with that. If this can actually be done, it sounds very promising.
>

I had a similar thought.

There needs to be a way to blind each server that is two hops away to
make it work:

Alice connects to a server_0, the server routes to server_1, server_1
routes to server_2 and that passes the final TLS to Bob.

Alice's TLS message needs to be passed to server_1 without every
indicating in an encrypted fashion that server_2 is in the path. In
this analogy, server_0 is like the Tor guard, server_1 is the middle
node, and server_2 is the exit node.

There are some issues with such a design - which is why Tor's design
is to use TLS as an outer link layer and then internally to use 512
byte (or slightly larger) cells. I won't get into those here but I
find the general idea of tls within tls to be useful.

All the best,
Jacob

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Encrypted SNI

[Eric Rescorla]

Subject: SNI Encryption Part XLVIII

Folks,

TL;DR.
This message describes a technique for doing SNI encryption that just
requires (re)adding EncryptedExtensions to the client's first flight [0]
defining an extension that indicates "tunnelled TLS" and (maybe) a new
TLS content type. We would only tunnel the first flight and everything
else would be handed off to the hidden service. This seems like the
minimal change to enable Encrypted SNI while retaining our existing
analytical frame for the rest of TLS.


DETAILS
During the discussion of SNI Encryption in Yokohama, Deb Cooley
argued that rather than messing with TLS to allow SNI encryption,
we should just tunnel TLS in TLS. A number of people objected
to this on the grounds of the performance cost for the gateway
because it has to encrypt and decrypt everything.

After the meeting, Martin Thomson suggested a modification to the
tunnelling proposal that removes this cost. The key observation is
that if we think of the 0-RTT flight as a separate message attached to
the handshake, then we can tunnel a second first flight in it. Here's
the idea:

 Client   Gateway  Hidden

 ClientHello#1
  + KeyShare
  + EarlyDataIndication
  + SNI = gateway
 (Finished)
 (
   ClientHello#2
+ KeyShare
+ SNI = hidden
   //
 )
 (end_of_early_data alert)  >

 ClientHello#2
 + KeyShare
 + SNI = hidden
 >
   ServerHello
+ KeyShare
 {EncryptedExtensions}
{ServerConfiguration*}
{Certificate*}
 {CertificateRequest*}
  {CertificateVerify*}
 <---   {Finished}
{Finished}   --->


Key to brackets:

  () encrypted with Client->Gateway 0-RTT key (either handshake or data)
  <> encrypted with Client->Hidden 0-RTT key
  {} encrypted with Client->Hidden 1-RTT handshake


The way this works is that the Gateway decrypts the *data* in the
client's first flight, which is actually ClientHello#2 from the
client, containing the true SNI and then passes it on to the, Hidden
server. However, the Hidden server responds with its own ServerHello
which the Gateway just passes unchanged, because it's actually the
response to ClientHello#2 rather than to ClientHello#1. As long as
ClientHello#1 and ClientHello#2 are similar (e.g., differing only in
the client's actual share (though of course it must be in the same
group)), SNI, and maybe EarlyDataIndication), then an attacker should
not be able to distinguish these cases.


Notes on several obvious technical issues:

1. How does the Gateway distinguish this case from where the initial
   flight is actual application data? See below for some thoughts
   on this.

2. Can we make this work with 0-RTT data from the client to the Hidden
   server? I believe the answer here is "yes", because the server's
   EarlyDataIndication does not carry the configuration_id. I just
   didn't show it in the diagram because it was already getting
   complicated.

3. What happens if the Gateway server doesn't gateway, e.g., because
   it has forgotten the ServerConfiguration? In that case, the
   client gets a handshake with the Gateway, which it will have
   to determine via trial decryption. At this point the Gateway
   supplies a ServerConfiguration and the client can reconnect
   as above.

4. What happens if the client does 0-RTT inside 0-RTT (as in #2 above)
   and the Hidden server doesn't recognize the ServerConfiguration in
   ClientHello#2? In this case, the client gets a 0-RTT rejection and
   it needs to do trial decryption to know whether the rejection was
   from the Gateway or the Hidden server.


The big advantage of this design compared to the designs we were
discussing in Yokohama is that it requires effectively no changes
to TLS. The only thing you need is a way to signal to the Gateway
server that the encrypted application data is actually a ClientHello
which is intended for the hidden service. The two most obvious
designs are:

- Have an EncryptedExtension which indicates that the inner
  data is tunnelled.
- Have a "tunnelled" TLS content type.

In the interest of explicit signaling I think EncryptedExtensions is
best but we either need to require that all TLS 1.3 implementations
handle that extension or *also* have a new content type, because
otherwise it might be possible for an attacker to craft an inner
ClientHello which was processable in part as an upper-level protocol
message, which could be bad.

The major disadvantage of this overall design strategy 

Re: [TLS] Encrypted SNI

[Viktor Dukhovni]

On Sat, Dec 05, 2015 at 02:15:07PM -0500, Watson Ladd wrote:

> I've got another question: how does the client know that the gateway
> is supposed to be the gateway? As it stands it seems an attacker can
> MITM the Gateway, and recover all SNIs.

That's a whole lot different than passively reading all the SNIs,
if not this or similar, then we're sending the SNI in the clear...

That said, ekr's post includes:

Important note: this whole discussion punts the question of how
a client knows that it can do any of this stuff. My assumption
here is that the client learns it from the Hidden server in some
unprotected connection or via some side channel (e.g., DNS).

DNS seems to make sense, because in any case the client will already
be asking for the IP address of the same said server via DNS.  It
may as well ask for the 0-RTT key.  If DNS is in the clear for the
IP address, then encrypting SNI is often (absent TOR and the like)
pointless, if DNS is protected then the key lookup is also protected.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Dave Garrett]

On Saturday, December 05, 2015 01:32:11 pm Eric Rescorla wrote:
> Subject: SNI Encryption Part XLVIII
> 
> Folks,
> 
> TL;DR.
> This message describes a technique for doing SNI encryption that just
> requires (re)adding EncryptedExtensions to the client's first flight [0]
> defining an extension that indicates "tunnelled TLS" and (maybe) a new
> TLS content type. We would only tunnel the first flight and everything
> else would be handed off to the hidden service. This seems like the
> minimal change to enable Encrypted SNI while retaining our existing
> analytical frame for the rest of TLS.
[...snip...]

Neat. This design is modeled more similarly to what SNI is actually for and 
this generalized approach may be useful for other applications. Not that 
simple, but we knew that we weren't going to get that here.

This is actually more than just SNI encryption; every possible indicator in a 
server's first flight gets encrypted here. We can get encrypted ALPN through 
this too, which could be nice to have. It would give ideal protection against 
attempts to identify the intended server via ClientHello fingerprinting, in 
general. (still a finite amount of virtual hosts to guess from, but that's not 
fixable here)

Sounds like a good proposal to me. :)


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Salz, Rich]

Can we embed an EncryptedExtension inside an existing EE?  That would let us do 
TOR purely within TLS, right?

You said “in the interest of explicit signaling” but I think you meant in the 
interest of avoiding that, right?

I still think the “inner/real SNI” is simpler, but will have to think about the 
two.

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Tom Ritter]

On 5 December 2015 at 12:32, Eric Rescorla  wrote:
> Subject: SNI Encryption Part XLVIII

A small concern that probably is "No, that can't happen", but I would
want to be sure that a normal (non-encrypted SNI) ClientHello would be
unable to be wrapped in a new ClientHello to a gateway by a MITM
(without being detected.)

Also, I'm a little confused about what the client is supposed to put
in the outer SNI (for the gateway). Is this blank? Some constant? Does
this change at all in the simple deployment situation when there is no
gateway involved, and everything sits on the same server?

-tom

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

[Eric Rescorla]

On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter  wrote:

> On 5 December 2015 at 12:32, Eric Rescorla  wrote:
> > Subject: SNI Encryption Part XLVIII
>
> A small concern that probably is "No, that can't happen", but I would
> want to be sure that a normal (non-encrypted SNI) ClientHello would be
> unable to be wrapped in a new ClientHello to a gateway by a MITM
> (without being detected.)
>

That would certainly be consistent with the proposed design. Why is that
bad?


Also, I'm a little confused about what the client is supposed to put
> in the outer SNI (for the gateway). Is this blank? Some constant?


Whatever SNI you would use to talk to the gateway ordinarily. Otherwise
you would have a distinguisher.



> Does
> this change at all in the simple deployment situation when there is no
> gateway involved, and everything sits on the same server?
>

No.

-Ekr

>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Salz, Rich]

Thanks for your detailed and thoughtful review.

It's all trade-offs.  In previous emails on this thread I acknowledged the 
co-dependant issue, by calling out dkg's excellement statement of it.

At the TLS interim earlier this week, Brian Sniffen (from Akamai) started a 
proposal that makes SNI-encryption something that can be deployed and tested on 
the Internet in TLS 1.3.  So we'll see if it gets used and works.  The earlier 
slides notwithstanding, it's something we (those of us at Akamai) would really 
like to see.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Dave Garrett]

On Friday, September 25, 2015 01:10:37 pm Martin Rex wrote:
> Because it is not necessarily immediately obvious, you will need
> padding also for the Server Certificate handshake messages.
> And, because the key exchange is side-effected by properties of
> the Server Certificate, you may additionally need padding for the
> ServerKeyExchange and ClientKeyExchange handshake messages, so
> that the protocol doesn't leak of one of the service uses
> an RSA certificate and the other uses an ECDSA (or EdDSA) certificate.

This sounds like a good argument to come up with a default padding scheme for 
all handshake messages for even clients that don't use application data padding.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Martin Rex]

Salz, Rich wrote:
> 
> At the TLS interim earlier this week, Brian Sniffen (from Akamai) started
> a proposal that makes SNI-encryption something that can be deployed and
> tested on the Internet in TLS 1.3.  So we'll see if it gets used and works.
> The earlier slides notwithstanding, it's something we
> (those of us at Akamai) would really like to see.

I haven't been tracking the TLSv1.3 proposals -- but whatever you do
in the area of encrypted SNI, please ensure that padding *WILL* be used,
so that two encrypted server names, that happend to differ by length,
will not remain easily distinguishable.

-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Nick Mathewson]

On Tue, Sep 22, 2015 at 2:37 PM, Salz, Rich  wrote:
> We discussed this before.  Not that we can't discuss it again.  Here's a link 
> to slides I presented at the Toronto Interim in July 2015.
>
> 
> https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing
>


Thanks for that link, Rich!

Please forgive me if my analysis has already been gone over, but I
believe that there are at least three problematic aspects in the
argument as presented in your slides.

1) Entrenchment of codependent vulnerabilities

This is a strong antipattern in security design, and it's been
practiced by some of the great minds of the field, but I think it's
fundamentally mistaken. Here's how it works:

There are two systems, A and B.  Each has a problem that enables some
kind of attack. The people who maintain system A say: "There is no
point in fixing A, because any attacker who breaks A could achieve the
same results via B."  But the people who maintain system B say: "There
is no point fixing B because any attacker who breaks B can achieve the
same results via A."

Both groups are using solid logic: neither one of them would
materially improve user security by fixing the vulnerability in their
system.  The Codependent Vulnerability antipattern arises when no
progress is ever made, because each group decides that the problems
outside its control will probably never be fixed.

In your slides, I see several instances of codependent vulnerabilities:

a) Improved DNS security vs Encrypted SNI

The lack of security in current DNS usage is taken to justify not
improving SNI privacy. But in discussions about DNS privacy,
vulnerabilities in other protocols are frequently taken as
justification for not improving DNS privacy.

b) Traffic analysis vs encryption

Traffic analysis is indeed strong today, but it's not omnipotent, and
good research on resisting it is happening all the time.  But if we
take the weaknesses of TLS against traffic analysis a a permanent
feature of the world, then such research will have less opportunity to
bear fruit, since TLS will entrench the problems that
anti-traffic-analysis research cannot yet solve.

c) Technical attacks vs rubber-hose attacks

See point 2 below.


2) Attacks are not equally costly and do not scale equally well.

It's not sufficient to say "This defense will not render the attack
impossible; therefore it is useless"; we also need to consider whether
the defense will render the attack _more expensive_.

Even for regimes unconcerned with fair play and regimes with
significantly intrusive attitudes to civil liberties... intimidating
citizens, applying political pressues, and backdooring infrastructure
are not zero-cost operations.  In nearly all cases, ithese attacks are
more difficult and costly than simply reading bytes off the wire.


3) Censorship vs surveillance.

The analysis in the slides is concerned with attackers against privacy
rather than attackers against availability.  But IMNSHO, both kinds of
attacker are a significant threat to human rights.

Unencrypted SNI makes a censor's job extremely easy.  In today's TLS,
it's trivial to block targeted domains hosted at a provider without
blocking ones where the censors consider access desirable.  Encrypting
SNI would make this kind of blocking more difficult and technically
expensive.


To be fair, encrypted SNI would probably make trouble for providers
who host some censored and some uncensored services.  Plaintext SNI
does make it easier for censors to be selective, and thereby makes it
easier for hosting providers to avoid conflicts and drama.


best wishes,
-- 
Nick Mathewson


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Jacob Appelbaum]

On 9/21/15, Daniel Kahn Gillmor  wrote:
> On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni 
> wrote:
>> So the client would now need to cache some session data by transport
>> address, and other data by name and port.  That's rather complex.
>
> This is already done by HTTP/2 clients, since they can access multiple
> servers at the same address:port combination.
>
>> And how often will the same client visit multiple servers at the
>> same transport address?
>
> *.github.io, *.blogspot.com, massive CDNs, etc.  It's a common pattern.
>
>> I don't really see this as viable or worth the effort.
>
> I disagree -- the metadata leaked to a passive attacker by mandatory SNI
> is a valuable signal.  It is worth trying to protect it.

I agree - this metadata is usable as a selector for automated
surveillance and for automated exploitation.

>
>> I don't think SNI hiding is viable without encryption at the
>> transport or network layers.
>
> any encrypted SNI is effectively acting as a shim for transport
> encryption, yes.  Then again, TLS is itself "transport layer security",
> so we should try to provide it at least as an option.

In an ideal world: using ephemeral keys, we must be able to have usage
of the protocol that is selector free.

>
>> And there's still a metadata leak via DNS which may prove difficult to
>> address.
>
> The DNS community is working to address the DNS leak in DPRIVE.  The TLS
> community should be working to fix its own part of the metadata leak.
>

Agreed, strongly.

All the best,
Jacob

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Salz, Rich]

We discussed this before.  Not that we can't discuss it again.  Here's a link 
to slides I presented at the Toronto Interim in July 2015.


https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Daniel Kahn Gillmor]

On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni  
wrote:
> So the client would now need to cache some session data by transport
> address, and other data by name and port.  That's rather complex.

This is already done by HTTP/2 clients, since they can access multiple
servers at the same address:port combination.

> And how often will the same client visit multiple servers at the
> same transport address?

*.github.io, *.blogspot.com, massive CDNs, etc.  It's a common pattern.

> I don't really see this as viable or worth the effort.

I disagree -- the metadata leaked to a passive attacker by mandatory SNI
is a valuable signal.  It is worth trying to protect it.

> I don't think SNI hiding is viable without encryption at the
> transport or network layers.

any encrypted SNI is effectively acting as a shim for transport
encryption, yes.  Then again, TLS is itself "transport layer security",
so we should try to provide it at least as an option.

> And there's still a metadata leak via DNS which may prove difficult to
> address.

The DNS community is working to address the DNS leak in DPRIVE.  The TLS
community should be working to fix its own part of the metadata leak.

  --dkg

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Salz, Rich]

 How's it done with IPv6, generally?

We don't see address-sharing with IPv6, although I wonder if that will change 
when the routing tables get too big. :)  We also don't see anyone willing to go 
IPv6-only; it's not close to universal enough yet.

 I agree that it's a lot of effort for relatively little gain.

It doesn't protect those who need it against those who would harm them.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls