Subject: Re: [dns-privacy] Recursive Resolver Operator Perspective

From: Brian Haberman <[email-masked]>
Date: Mon, 1 Oct 2018 09:36:10 -0400

All,
     Thanks for a productive set of exchanges on the user perspective
last week! I would like the focus for this week (10/1-10/7) to be on
clarifying the requirements from the perspective of the recursive
resolver operator. So far, I have seen:

* DNS transaction privacy w/o authentication
* DNS transaction privacy w/ authentication of the authoritative server(s)

Do others have additional requirements?

If you agree with the above, could you describe a scenario to highlight
the requirements?

Regards,
Brian

On 7/19/18 2:24 PM, Brian Haberman wrote:
> This thread is for discussion of the recursive resolver operator
> perspective of DNS privacy between the recursive resolver and
> authoritative servers.
> 
>     - Focus on *what* is needed.
>     - Avoid *how* to achieve it.
>     - Consider both ends of DNS the exchange.
>     - Scenarios will frame the discussion.
> 
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Oct 2018 14:16:30 +0000

> Do others have additional requirements?

A third one is DNS transaction privacy with attempted-but-not-required authentication. This is the opportunistic encryption scenario: a resolver wants the best transaction privacy they can get. If example.com has two nameservers, ns1.example.com and ns2.example.com, and I cannot authenticate ns1.example.com, I will prefer to use ns2.example.com because doing so make a system-in-the-middle attack harder. I might sometimes try to authenticate with ns1.example.com again so that I can then choose between them based on other attributes such as speed, but I will prioritize ability to authenticate.

During earlier discussions of opportunistic encryption in the IETF, attempted-but-not-required authentication was strongly preferred over "don't even attempt to authenticate".

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Mon, 1 Oct 2018 16:50:38 +0100

Paul Hoffman <[email-masked]> wrote:
>
> During earlier discussions of opportunistic encryption in the IETF,
> attempted-but-not-required authentication was strongly preferred over
> "don't even attempt to authenticate".

This is only worthwhile if there is downgrade protection, i.e. the client
needs to be able to tell if it is supposed to be able to rely on an
authentication mechanism (e.g. using DANE). Without downgrade protection
it's equivalent to encryption without authentication.

We discussed this a few weeks ago, thread starting at
https://www.ietf.org/mail-archive/web/dns-privacy/current/msg02124.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Fitzroy, Sole: Variable 4, becoming easterly 4 or 5 in east Sole.
Moderate, occasionally rough at first. Fair. Good.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Oct 2018 16:27:15 +0000

> it's equivalent to encryption without authentication.

We have to be careful when we are talking about recursive resolvers. By "client" above, I think you mean "customer of the recursive resolver" and not "the side of the recursive resolver talking to authoritative servers".

Brian asked for this thread to be from the perspective of a recursive resolver operator. If I were running a recursive resolver, I want to do the best job I can for my customers, in this case giving them better privacy. I cannot guarantee them great privacy, but I can make good efforts even if they don't understand those efforts, and attempted-but-not-required authentication is better effort than "don't even attempt to authenticate".

Personally, I do not know of any resolver customers that require downgrade protection unless they are running the recursive resolver for just themselves. That is, "downgrade protection" means "if you cannot get an authenticated answer, you literally want no answer at all". Answers for some RRtypes, notably TLSA, require DNSSEC authentication that must have downgrade protection, but that is not what we are discussing here.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Mon, 1 Oct 2018 18:49:26 +0100

Paul Hoffman <[email-masked]> wrote:
> We have to be careful when we are talking about recursive resolvers. By
> "client" above, I think you mean "customer of the recursive resolver"
> and not "the side of the recursive resolver talking to authoritative
> servers".

No, I'm thinking in terms of client = recursive, server = authoritative,
which are the ends of the connection that we want to improve.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Variable 3 or 4 at
first in east Fair Isle, otherwise cyclonic or westerly 6 to gale 8,
increasing severe gale 9 for a time, then decreasing 4 at times later.
Moderate or rough, becoming very rough or high for a time. Rain or squally
showers. Good, occasionally poor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Oct 2018 23:36:05 +0000

> which are the ends of the connection that we want to improve.

I do not have a scenario where the client (the resolver in this case) needs downgrade protection for privacy. We have no privacy now. If we start having privacy, there might be resolvers who only want to send queries that are private, but that feels like a different DNS than what we have today.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Tue, 2 Oct 2018 11:12:38 +0100

Paul Hoffman <[email-masked]> wrote:
>
> I do not have a scenario where the client (the resolver in this case)
> needs downgrade protection for privacy.

In that case there's no need to worry about authentication at all.
(But I disagree.)

More generally, I don't think the term "opportunistic" is very helpful,
because there are several useful levels:

* cleartext

* unauthenticated - the client auto-discovers encryption is available, but
doesn't have any way to reliably authenticate the server; an attacker can
force the client to downgrade to cleartext.

* authenticated - there is an explicit signal (e.g. DANE, STS) that the
server supports properly authenticated encryption; an attacker can deny
service but not force a downgrade to cleartext.

* pre-configured

The end goal we should be aiming for is as much authenticated encryption
as possible, but it's reasonable to allow unuathenticated encryption as an
intermediate step.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
safeguard the balance of nature and the environment

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Oct 2018 14:40:35 +0000

> In that case there's no need to worry about authentication at all.

And I disagree that there is "no need to worry". As I said in my initial message, a resolver operator might want to take advantage of it if it is available.

> More generally, I don't think the term "opportunistic" is very helpful,

...but it is the hard-fought agreement of the IETF. See RFC 7435. The abstract is quite simple:

   This document defines the concept "Opportunistic Security" in the
   context of communications protocols.  Protocol designs based on
   Opportunistic Security use encryption even when authentication is not
   available, and use authentication when possible, thereby removing
   barriers to the widespread use of encryption on the Internet.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Tue, 2 Oct 2018 19:26:31 +0100

Paul Hoffman <[email-masked]> wrote:
> And I disagree that there is "no need to worry". As I said in my initial
> message, a resolver operator might want to take advantage of it if it is
> available.

I don't understand: first you say you don't need downgrade protection,
then you say you want authentication. This isn't consistent. You aren't
taking advantage of authentication if you are vulnerable to a downgrade
attack. In that case the authentication is worthless.

> ....but it is the hard-fought agreement of the IETF. See RFC 7435.

Yeah, and the point I am making is that it is important to pick apart the
teo options described in RFC 7435's abstract. They have very different
deployment characteristics and security guarantees. For protocols like
SMTP or DNS there isn't an easy identifier that can be reliably
authenticated, so authenticated encryption needs extra deployment work
(e.g. DANE) to be reliable, and if you do that work you get downgrade
protection as a bonus. If you don't do the extra work you can do
unauthenticated encryption, but you remain vulnerable to active attacks.
If you do the extra work without including downgrade protection then you
might as well not have bothered.

Perhaps I should say that this strict security can only apply if both the
server advertises it and the client looks for it; if either of those don't
apply then you get unauthenticated opportunistic encryption, which is OK,
but we can do better when both ends want to be secure.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: Easterly 5 or 6 in far southwest, otherwise variable 3 or 4. Slight or
moderate. Fair. Good.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Oct 2018 19:57:55 +0000

On Oct 2, 2018, at 11:26 AM, Tony Finch <[email-masked]> wrote:
> then you say you want authentication.

Yes, exactly.

> This isn't consistent.

Yes, it is. Note the difference between "need" and "want".

> You aren't
> attack.

If I have a path with authentication and a path without, and I prefer (not demand) the path with authentication, I am taking advantage of it.

> In that case the authentication is worthless.

We disagree. To me (and clearly to many others), it has worth when it is used.

> authenticated,

Why not? IP addresses work just fine in both of those cases. The web world has decided that domain names are good enough identifiers for them, so other worlds might use them as well.

> so authenticated encryption needs extra deployment work
> (e.g. DANE) to be reliable,

DANE works as well, but it is not the only possibility, depending on your use case. If you want to stay within the single-root DNSSEC model, DANE works great today, and there have already been proposals here for protocol extensions to make domain names and IP addresses work as well if we authenticate them on the parent side of a zone cut.

> and if you do that work you get downgrade

Again, we disagree. Some resolver operators want to get good security when they can get it, and are willing to do a little work to get it.

> but we can do better when both ends want to be secure.

Yes, that would be good to say. :-) It then does not denigrate the people who don't need strict security but want to use what RFC 7435 describes as opportunistic.

--Paul Hoffman

---

From: Hugo Connery <[email-masked]>
Date: Wed, 3 Oct 2018 11:04:11 +0200

Hi All,

Thanks Paul and Tony for digging into this.  I've been thinking
about this from a user perspective, but my desired user
perspective behaviour influences the recursive resolver behaviour.

As I see it, the problem with downgrade attacks is when the user
is unaware of the fact that this is occuring.  My user persepctive
requirement is that I know which of the following states my DNS
queries are being made by the recursive resolver: cleartext,
encrypted (but unautheniticated) or encrypted and authenticated.

I would like some visual representation of the status, similar
to the http/https visualisation in modern web browsers.  But,
that is a client side implementation choice.  To do it though,
we need to know what the status is.

Thus, I am proposing that this information is included in the 
client (stub) to recursive resolver protocol.  Could EDNS be used 
to do this?

With this information available, one can do opportunistic encryption
and/or authentication and not require downgrade attack prevention but 
push that risk to the end user.  This may be unwise, but I leave
that the community's wisdom.

Regards,

  Hugo Connery

On Tue, 2018-10-02 at 19:57 +0000, Paul Hoffman wrote:
> If I have a path with authentication and a path without, and I prefer
> (not demand) the path with authentication, I am taking advantage of
> it.
> 
> Why not? IP addresses work just fine in both of those cases. The web
> world has decided that domain names are good enough identifiers for
> them, so other worlds might use them as well.
> 
> DANE works as well, but it is not the only possibility, depending on
> your use case. If you want to stay within the single-root DNSSEC
> model, DANE works great today, and there have already been proposals
> here for protocol extensions to make domain names and IP addresses
> work as well if we authenticate them on the parent side of a zone
> cut.
> 
> Again, we disagree. Some resolver operators want to get good security
> when they can get it, and are willing to do a little work to get it.
> 
> Yes, that would be good to say. :-) It then does not denigrate the
> people who don't need strict security but want to use what RFC 7435
> describes as opportunistic.
> 
> --Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Wed, 3 Oct 2018 12:48:00 +0100

Paul Hoffman <[email-masked]> wrote:
> (not demand) the path with authentication, I am taking advantage of it.

Right, but is the authenticated path securely authenticated? i.e. can
the client tell that an attacker is monkeying around with the
authenticated path?

This is important because it allows clients to make a meaningful choice
between security and availabilty, while still being opportunistic (i.e.
zero per-server config on the client). If the client can't tell the
difference between no authenticated channel and an attacked authenticated
channel, it has no meaningful choice other than to fall back to
unauthenticated encryption, and the upshot is that the authenticated
channel doesn't actually provide any security improvement, and the only
option clients have is unauthenticated encryption.

> > For protocols like SMTP or DNS there isn't an easy identifier that can
> > be reliably authenticated,
>
> Why not? IP addresses work just fine in both of those cases.

No, for SMTP the relevant identifier is the domain in the recipient email
address. When we started working on DANE the problems were that

(1) the MX target name often doesn't match the server's idea of its
own name

(2) the server's certificate often doesn't match either name

Auth DNS has problem (1) (but not 2 because there's no encryption yet),
and also has the problem that it's more latency sensitive and doesn't have
a fast way to signal that encryption is available.

For authentication to actually be secure, there has to be a signal (e.g.
DANE) that this server has been configured without name mismatches, so the
client can properly authenticate it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet, Irish Sea: Variable 4, becoming south or southwest 4 or
5, occasionally 6 in Irish Sea. Slight or moderate. Occasional drizzle, fog
patches at first. Moderate or good, occasionally very poor at first.