Subject: [dns-privacy] Another reason not to layer DNS security on TLS

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Mar 2015 13:43:19 -0500

I have been thinking about the TLS SNI hole again and I have a sketch that
I think is quite practical for solving the issue.

For the sake of argument, assume we are doing a TLS/2 which is a complete
break with the past TLS protocol that removes most if not all the options
in the current protocol and either eliminates them or makes them mandatory.

So no more OCSP stapling option, if you are doing TLS/2, it is a
requirement. The restart mechanism is MTI as well and has a mechanism to
allow the crypto state to be offloaded to the server.

One hole that does raise privacy issues is Server Name Identification. If
you have 200 web sites on a server, you don't want to have to burn an IPv4
address for each one. So the DNS name of the server has to be passed in the
TLS handshake before the encryption tunnel is established. That is a
privacy hole.

There are a few ways round this problem. But all the best ones involve
passing some sort of key from the DNS server. But to make those work
cleanly it is essential that TLS is layered on DNS and not the other way
round.

---

From: Shumon Huque <[email-masked]>
Date: Sat, 7 Mar 2015 20:47:24 -0500

> in the current protocol and either eliminates them or makes them mandatory.

Is that what we are envisioning, and if so, why?  I was assuming we are
planning to reuse an existing TLS protocol (v1.2 or the upcoming 1.3).

> cleanly it is essential that TLS is layered on DNS and not the other way

The simplest way of addressing this issue is not using the TLS SNI
extension. I don't expect operators to deploy TLS/DNS instances on the same
system that houses 200 other websites, and even if they did, they would
likely not be sharing the same application port. Last I heard, the TLS/DNS
proposals are using port 53 or an alternate non-web port. In such
configurations, we don't need SNI to disambiguate the application service
endpoint on a shared system.

Also, is protecting the identity of the nameserver one of the privacy
goals? This will be very challenging to do, unless we do something radical
like making them Tor hidden services or similar. A passive surveillance
adversary collecting packets can pull out the IP address of the nameserver
easily enough, and if they wanted the NS name, correlate it with a passive
DNS database.

Besides SNI, the TLS server certificate, transmitted in the clear in the
handshake, could also reveal the nameserver identity, so we'd also have to
consider if that needs to be protected or obfuscated.

It would be nice if the SNI extension supported subject name forms other
than "hostname", but it doesn't today. If so, one could define a new
nametype carrying an obfuscated identity/key/token if needed.

Shumon Huque

---

From: Watson Ladd <[email-masked]>
Date: Sat, 7 Mar 2015 18:09:27 -0800

On Sat, Mar 7, 2015 at 10:43 AM, Phillip Hallam-Baker
<[email-masked]> wrote:
> I have been thinking about the TLS SNI hole again and I have a sketch that I
> think is quite practical for solving the issue.
>
> break with the past TLS protocol that removes most if not all the options in
> the current protocol and either eliminates them or makes them mandatory.
>

This change (SNI encryption) was already discussed in the TLS WG. I
have no idea if by restart mechanism you mean resumption tickets,
which are already widely supported.

> TLS handshake before the encryption tunnel is established. That is a privacy
> hole.
>
> passing some sort of key from the DNS server. But to make those work cleanly
> it is essential that TLS is layered on DNS and not the other way round.

Huh? It's entirely possible to have bootstrapping: a preset public key
to encrypt data to the resolver is used to establish the TLS
connection over which DNS queries are made to retrieve the public keys
needed for other servers.

Sincerely,
Watson Ladd
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Mar 2015 12:14:12 -0400

On Sat, Mar 7, 2015 at 8:47 PM, Shumon Huque <[email-masked]> wrote:

> On Sat, Mar 7, 2015 at 1:43 PM, Phillip Hallam-Baker <
> [email-masked]> wrote:
>
>> I have been thinking about the TLS SNI hole again and I have a sketch
>> that I think is quite practical for solving the issue.
>>

People have been discussing TLS/2 in the TLS working group. My point is
that if we layer DNS/2 on TLS then we end up with all the legacy crud from
TLS/1.2 permanently baked into the stack.

What IETF should be trying to move towards is a state where we can jettison
as much legacy cruft as possible when we move to IPv6. Crud tends to build
up over time.

> extension.

You are arguing against SNI on the DNS resolver, which isn't the point. The
problem comes on the application server, e.g. Web server that is discovered.

IPv4 will continue to be essential on Web servers for at least 20+ years
for backwards compatibility. And IPv4 addresses will continue to appreciate
in cost for the next ten years or so. When an IPv4 address is costing
$50/year to an ISP, the cost of non-SNI TLS is going to add about a hundred
dollars a year to server operation costs.

The reason this is strongly connected to DPRIV is that the decisions we
make will determine whether DPRIV helps us solve these other problems or
becomes an additional barrier to deployment.

If we want people to use DPRIV we had better design it in a way that makes
it as small as possible with as few dependencies as possible.

I don't expect operators to deploy TLS/DNS instances on the same system
> that houses 200 other websites, and even if they did, they would likely not
> be sharing the same application port.
>

SNI is used on the Web servers that the DNS services provide discovery to.
The way to close up the SNI gap is to encrypt the initial handshake. But to
make that possible you have to get a key from somewhere to start the
conversation.

In this case the key is a host key and not a service key. So if I have
web1.com, web2.com on host1.coloc.net the discovery sequence for web1.com
would be:

web1.com XSRV -> host1.com + key (host1.coloc.net)

host1.coloc.net TLS handshake under key (host1.coloc.net)
Turn on encryption
Send SNI for web1.com

Get cert for web1.com.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 08 Mar 2015 19:43:59 +0000

Hi Phil,

On 08/03/15 16:14, Phillip Hallam-Baker wrote:
> People have been discussing TLS/2 in the TLS working group

I have only seen you discussing that recently. There was some
discussion along those lines early in the development of TLS1.3
but the WG decided to work on TLS1.3 and are not doing anything
(and are not chartered [1] to do anything) about a TLS1.3.

Cheers,
S.

[1] https://tools.ietf.org/wg/tls/charters

---

From: Shumon Huque <[email-masked]>
Date: Sun, 8 Mar 2015 16:05:35 -0400

On Sun, Mar 8, 2015 at 12:14 PM, Phillip Hallam-Baker <[email-masked]

> You are arguing against SNI on the DNS resolver, which isn't the point.
> The problem comes on the application server, e.g. Web server that is
> discovered.
>

Besides SNI, the subsequently presented server certificate is likely to
leak the website's identity also, so a larger scope encrypted handshake is
needed. I would prefer the TLS working group solve this problem
independently of DPRIVE. If TLS (for applications) needs bootstrapping
information from the content of signed DNS records (e.g. to provide better
resistance against active adversaries), they could obtain them over DPRIVE
developed protocol extensions.

Also I'm not sure it's worth the effort to protect the identity of only
websites that are colocated with many others on a shared hosting service.
If users want to not the leak the identity of websites they visit, a more
general solution is needed that covers other sites too (how would a user
know in advance in any case if the website is on a shared host?). This
means looking at solutions that hide the network layer identity of the
service also, like Tor or other anonymity networks. This might be where we
are heading anyway - Facebook is already available as a Tor hidden service
for example, and I'm sure others will follow. With something like Tor, you
already gain encryption of the the cleartext TLS handshake parameters,
ahead of any TLS protocol changes. Of course, you'd have to consider active
attempts to de-anonymize users (malicious guard/entry nodes etc), but I
think research is going on in this area.

Also keep in mind that DPRIVE has a very limited initial charter (
https://datatracker.ietf.org/wg/dprive/charter/ ), focussing initially only
on stub to iterative-resolver confidentiality (and only a later stage
covers confidentiality to authority servers). I agree that we should not be
an impediment to better TLS privacy mechanisms (and I support TLS
enhancements to more fully encrypt cleartext handshake parameters), but I
don't think DPRIVE needs to actively help solve this problem for TLS either.

Shumon Huque.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Mar 2015 17:24:09 -0400

On Sun, Mar 8, 2015 at 3:43 PM, Stephen Farrell <[email-masked]>
wrote:

> (and are not chartered [1] to do anything) about a TLS1.3
>

I thought that we decided to do 1.3 now and TLS-NG 'later'.

Now whether 'later' turns out to be 'never' has yet to be seen but I
definitely didn't think we closed out the option.

I don't want DPRIV to effectively close out that option.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 08 Mar 2015 14:34:10 -0700

On Sat 2015-03-07 18:09:27 -0800, Watson Ladd wrote:
> On Sat, Mar 7, 2015 at 10:43 AM, Phillip Hallam-Baker <[email-masked]> wrote:

I agree with Phillip that the SNI leakage of TLS is a privacy issue with
that protocol.  But i don't think that it follows that we must not use
TLS for DPRIV.  As Watson points out, a bootstrapping configuration
(something like an address and a public key for the server) is probably
the most sensible approach to configuring a sytsem to talk securely to a
resolver.

Once the client has this kind of bootstrapped info, using it to protect
a TLS handshake isn't particularly complicated.

This isn't to say that TLS is necessarily the right way to implement
DPRIV, but i don't think the SNI leakage of TLS is relevant to the
choice.

        --dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Mar 2015 17:35:38 -0400

> developed protocol extensions.

That is what I want to happen as well.

What worries me is if we build a circular dependency into the stack. TLS is
layered on top of DNS at several points. The names used in TLS are DNS
names.

If we build a dependency on TLS into DNS then we end up with a death
embrace that locks the two protocols together in a fashion that makes later
cruft clearance impossible.

> service also, like Tor or other anonymity networks.
>

The place where we get a short term payoff is for enterprise networks where
the resources being accessed are in a part of the DNS name space that is
not visible to the general Internet.

But the co-loc sites are still very important. Going to a big site like
Facebook is not usually a privacy issue. And when it is a privacy issue you
need mechanisms like Tor to get a connection. Its when you go to a smaller
site that is more likely to be co-loc that more privacy issues arise.

> https://datatracker.ietf.org/wg/dprive/charter/ ), focussing initially
> only on stub to iterative-resolver confidentiality (and only a later stage
> covers confidentiality to authority servers).
>

Having a small initial charter is not license to create unnecessary
problems later on.

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 8 Mar 2015 16:48:40 -0700

> What worries me is if we build a circular dependency into the stack. TLS is layered on top of DNS at several points. The names used in TLS are DNS names.

Let's step back a minute. We are worried that TLS carries clear text that may disclose the nature of the service. In the absence of such disclosure, adversaries only know that the client is using "one of the many services collocated at the IP address of this server." With the disclosure, adversaries discover that the client is "using a private DNS resolver service located at the IP address of the server." 

But then, look at what happen if we define a special purpose protocol, different from TLS. Adversaries can presumably identify that this is "the DPRIVE protocol." Thus, they can identify that the client is "using a private DNS resolver service located at the IP address of the server."

What kind of privacy would we gain?

-- Christian Huitema

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Mar 2015 21:45:55 -0400

On Sun, Mar 8, 2015 at 7:48 PM, Christian Huitema <[email-masked]>
wrote:

> > What worries me is if we build a circular dependency into the stack. TLS
> is layered on top of DNS at several points. The names used in TLS are DNS
> names.
>
> Let's step back a minute. We are worried that TLS carries clear text that
> may disclose the nature of the service. In the absence of such disclosure,
> adversaries only know that the client is using "one of the many services
> collocated at the IP address of this server." With the disclosure,
> adversaries discover that the client is "using a private DNS resolver
> service located at the IP address of the server."
>
> But then, look at what happen if we define a special purpose protocol,
> different from TLS. Adversaries can presumably identify that this is "the
> DPRIVE protocol." Thus, they can identify that the client is "using a
> private DNS resolver service located at the IP address of the server."
>

The privacy concern DPRIV is trying to address is to prevent an adversary
seeing the contents of DNS traffic or being able to deduce them from packet
sizes, timing etc.

That is a very different problem from stopping the attacker from being able
to distinguish DNS traffic from HTTP. At the extreme, any client connecting
to 8.8.8.8 is doing DNS...

Now there are techniques that we can use to make the observation somewhat
harder. But there we have stepped outside the 'stop pervasive monitoring'
brief and we are trying to prevent pervasive censorship. That is an
important problem but not one that we are focused on here.

DNS client-resolver queries over TCP and TLS is going to be quite easy to
identify as DNS traffic.

The problem I have been concerned about in this thread is that if we assume
DPRIV succeeds, we will still be leaking the DNS names through the SNI
feature in HTTPS, i.e. HTTP-over-TLS.

HTTPS privacy isn't the problem we are solving right now but DPRIV privacy
isn't going to be worth very much if the information we are securing is
then disclosed in the HTTP/HTTPS layer. So we have to solve DPRIV in a way
that does not paint us into a corner when we try to solve the next puzzle.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 8 Mar 2015 20:31:33 -0700

On Sun, Mar 8, 2015 at 6:45 PM, Phillip Hallam-Baker
<[email-masked]> wrote:
<snip>
> isn't going to be worth very much if the information we are securing is then
> disclosed in the HTTP/HTTPS layer. So we have to solve DPRIV in a way that
> does not paint us into a corner when we try to solve the next puzzle.

But I don't see how using TLS 1.2 for a resolver to client connection
paints us into a corner when trying to solve SNI related leakage by
changes in TLS 1.3, in a way that using some other cryptographic
protocol doesn't. The information leaked by SNI when connecting to the
resolver is not the information looked up over that link.

Sincerely,
Watson Ladd

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Mar 2015 01:42:35 -0400

On Sun, Mar 8, 2015 at 11:31 PM, Watson Ladd <[email-masked]> wrote:

> then

Please read what I wrote rather than answering what you guessed I might
have written.

I am not concerned with the SNI issue in the DNS client resolver protocol
and I have said that four times now.

The SNI issue comes in the HTTPS session that the DNS discovery is being
used to build. There are currently two places that the DNS names leak out,
first in the DNS and then in the HTTP or HTTPS channel.

For years this has created an impasse because the DNS folk would say 'no
point in fixing the privacy leakage in DNS when it gets given out in TLS'.
And then the TLS folk say that SNI isn't an issue in HTTPS because the name
leaks in DNS.

So we have to start somewhere and DNS is the place we are starting. But the
protocol has to be layered in a way that makes sense. Either DNS is layered
on TLS or vice versa. If there is mutual dependency we will have a very bad
time trying to change either protocol in future.

This is not a cryptography issue, it is a protocol design issue.

There is no point in doing DPRIV unless we are going to eventually fix SNI
in HTTPS for web browsing.

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 8 Mar 2015 22:50:06 -0700

> The privacy concern DPRIV is trying to address is to prevent an adversary seeing the contents 
> of DNS traffic or being able to deduce them from packet sizes, timing etc.
>
> That is a very different problem from stopping the attacker from being able to distinguish 
> DNS traffic from HTTP. At the extreme, any client connecting to 8.8.8.8 is doing DNS...

OK. So, we have clarified that you do not have an issue with leaking SNI while using TLS for DPRIVE. You are looking at ways to plug the SNI leak in TLS, and also the clear text certificate leak. You are concerned that even if make DNS traffic opaque, adversaries will still be able to retrieve the same information by harvesting SNI and certificate. That's certainly a valid concern, but why not fight one battle at a time? Let's first make DNS traffic opaque. That's the DPRIVE charter. Then plug the holes in TLS. That ought to be the TLS charter.

The circular dependency that you hypothesize is only an issue if SNI+CERT disclosure mitigations (1) need to be applied to the DNS resolver connection and (2) require finding data in DNS. I am not sure at all about (1) since as you wrote, "at the extreme, any client connecting to 8.8.8.8 is doing DNS..." And I would rather not assume that the data comes from the DNS as in (2), before seeing actual designs...

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Mar 2015 11:06:31 +0000

Phill,

On 09/03/15 05:50, Christian Huitema wrote:
> Then plug the holes in TLS. That ought to be the TLS charter.

Right. The TLS WG have discussed this exact point a number of
times for TLS1.3. So far, nobody's found a convincing way to
solve the problem, but equally, I don't believe the topic is
closed, if someone finds a workable solution. I'd suggest you
chat to the TLS WG chairs to find out when they think it might
be a good time to bring this up again. And please also check the
WG archive - a bunch of different ideas were discussed already.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Mar 2015 08:53:18 -0400

> WG archive - a bunch of different ideas were discussed already.

Actually I do have a solution but it depends on deployment of DPRIV and
ACME first and we would probably want the ECC cipher suites as well.

Privacy is hard. It is a lot harder than the security we have done to date
because reducing the problem to independent parts does not work so well. It
is like the difference between normal automotive engineering and Formula
One racing. When you get to the really extreme performance you are not
considering the engine as just an engine, it is also the principal
structural member of the chasis.

This approach is only tractable though if DPRIV in particular is designed
in a way that respects the layering model and does not create a circular
dependency in the stack.

=Architecture

We separate service discovery (SRV/MX) from host discovery (A/AAAA) and
issue separate keys for each. If a host is co-locating 100 services it will
have 100 service TLS certs and keys and one host key. Only the service keys
are relied on for authenticating the service and so only those require the
full PKIX lifecycle management tools. The host keys are just passed as raw
keys through the DNS.

=Key provisioning

Let us imagine for the sake of argument that ACME is designed in a way that
makes deployment of DANE like keys practical. That is the hook that lets me
get a key for the host machine into the DNS. Without the ability to
automate that part of the administration work, any attempt to introduce
host keys is doomed to fail operationally.

=Discovery phase

The next part of the problem is how to efficiently discover the fact that
there is a host key for the initial host exchange. There are many ways that
this can be done but they all come down to separating out host discovery
from service discovery with an SRV like record that allows us to attach
what amounts to a TLSA like record.

One of the side benefits of DPRIV is that the performance penalty for
multiple DNS query transactions goes away. Whether we go the TCP route or
the UDP route, the cost of making queries for five records is the same as
the cost of one.

=TLS Changes.

With ACME and DPRIV in place we can then fix the TLS protocol. Which is
fairly straightforward, we simply bolt a key agreement to the host key onto
the front of the first client-server message. But this is only
straightforward if we can offload all the negotiation part of the scheme
off to the DNS.

Now this could be seen as a TLS change or it could be seen as an outline
for a TCPINC like beast. I prefer the second as we could use this approach
as a substitute for TLS in cases where the alternative is to go enclair. If
a site is colocating 100 sites and only ten of them have TLS certs, the
other 90 still get the benefit of some encryption but there is no
authentication component and certainly no padlock icon unless the DNSSEC
chain is present and has been checked.