Subject: [dns-privacy] I-D Action: draft-ietf-dprive-phase2-requirements-02.txt

From: [email-masked]
Date: Mon, 02 Nov 2020 14:54:13 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS PRIVate Exchange WG of the IETF.

        Title           : DNS Privacy Requirements for Exchanges between Recursive Resolvers and Authoritative Servers
        Authors         : Jason Livingood
                          Alexander Mayrhofer
                          Benno Overeinder
	Filename        : draft-ietf-dprive-phase2-requirements-02.txt
	Pages           : 10
	Date            : 2020-11-02

Abstract:
   This document describes requirements and considerations for adding
   confidentiality to DNS exchanges between recursive resolvers and
   authoritative servers.  The intent of this document is to guide
   Internet Drafts in the DNS Private Exchange (DPRIVE) Working Group
   pertaining to recursive to authorized name servers, with the stated
   requirements and considerations.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dprive-phase2-requirements/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dprive-phase2-requirements-02
https://datatracker.ietf.org/doc/html/draft-ietf-dprive-phase2-requirements-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-phase2-requirements-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Nov 2020 02:15:03 +0000

Greetings again. I really like many of the changes in draft-ietf-dprive-phase2-requirements-02 and think that it gets closer to what we want for requirements. One of the requirements seems unnecessary, however.

   7.   The authoritative domain owner or their administrator MUST have
        the option to specify their secure transport preferences (e.g.
        what specific protocols are supported).  This SHALL include a
        method to publish a list of secure transport protocols (e.g.
        DoH, DoT and other future protocols not yet developed).

If the WG does with DoT and/or DoQ, you can discover the server's capabilities by probing port 853 and TBD-Q, or maybe by finding TLSA records. There is only a need to "publish" a list of secure protocols if they include DoH or DoHoQ. Also, some folks on this list have already complained about added complexity of discovery mechanisms.

        In addition this SHALL include whether a secure transport protocol
        MUST always be used (non-downgradable) or whether a secure
        transport protocol MAY be used on an opportunistic (not strict)
        basis in recognition that some servers for a domain might use a
        secure transport protocol and others might not.

It is impossible for a server to tell whether a resolver is authenticating, so being able to say "you must authenticate" is kinda just posturing. The choice of whether or not to connect should always be with the resolver. Further, if a resolver is using a mechanism that requires strict authentication, it truly doesn't matter what the authoritative server has said it wants.

This whole requirement could be dropped and it would not affect the security or availability of the desired service.

--Paul Hoffman

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Nov 2020 09:29:24 +0100

On Mon, Nov 02, 2020 at 02:54:13PM -0800,
 [email-masked] <[email-masked]> wrote 

> 	Filename        : draft-ietf-dprive-phase2-requirements-02.txt

In 5.1, items 2 and 3 may require some clarification. For instance, "A
recursive resolver that supports recursive-to-authoritative DNS
encryption MUST be able to determine whether or not a given
authoritative name server to which it intends to connect also supports
recursive-to-authoritative DNS encryption." An obvious way to fulfill
this requirment is to try to start TLS on port 853 and see if it
works. But I guess item 2 was instead about the ability to determine
IN ADVANCE, before connecting, if encryption is supposed to be
supported?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Nov 2020 09:37:13 +0100

On Wed, Nov 04, 2020 at 02:15:03AM +0000,
 Paul Hoffman <[email-masked]> wrote 

> It is impossible for a server to tell whether a resolver is authenticating, so being able to say "you must authenticate" is kinda just posturing. The choice of whether or not to connect should alwa…

Nevertheless, hints from the authoritative name server can be useful,
such as "You should use DoT in strict mode but there is also a DoH
service which is quite experimental with a self-signed
certificate". Other IETF protocols have such hints from the
authoritative side about what the client should do, even if they
cannot be enforced (RFC 7208 for instance).

Is it worth the complexity? I don't know but it is not useless.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Nov 2020 09:42:41 +0100

> 9.1 there are currently three ways to reduce that exposure:

ECS should be mentioned here, as a "fourth way" (or may be just a
reference to RFC 8932).

> 9.2. Operators of authoritative services have to provide stable and
> fast DNS services, and interact with a wide range of clients, not
> all of them authoritative servers.

I don't understand the sentence. Except for NOTIFY/AXFR, the
authoritative name servers do not interact with authoritative name
servers, they talk mostly to resolvers (plus the CS students probing
them with dig).

---

From: Brian Dickson <[email-masked]>
Date: Wed, 4 Nov 2020 01:10:56 -0800

On Tue, Nov 3, 2020 at 6:15 PM Paul Hoffman <[email-masked]> wrote:

> Greetings again. I really like many of the changes in
> draft-ietf-dprive-phase2-requirements-02 and think that it gets closer to
> what we want for requirements. One of the requirements seems unnecessary,
> however.
>
> If the WG does with DoT and/or DoQ, you can discover the server's
> capabilities by probing port 853 and TBD-Q, or maybe by finding TLSA
> records. There is only a need to "publish" a list of secure protocols if
> they include DoH or DoHoQ.

No, this is not accurate, and highly misleading. I am not casting
aspersions on your intent, merely calling out the correctness of the
argument.

The prevention of downgrade attacks requires publication of servers
capabilities and intents, including prefered or offered protocols.
This includes DoT.

Counter-argument: an active attacker can force a downgrade by selectively
blocking port 853 queries.
If the secure transport for DoT is published, this becomes a
denial-of-service attack rather than a downgrade attack.
Lack of publication converts the blockage to a downgrade attack.

There may be multiple authoritative servers in different topological
arrangements, so that the attacker is on-path for only some of those
servers.
In that situation, blocking the port 853 queries to one server would result
in the client (resolver) attempting port 853 connections to the other
servers (assuming the non-opportunistic client).

The existence of clients and servers who both want to do encrypted
transport requires that the design accommodate that, notwithstanding the
desire for others to be opportunistic in their approach.
There is no way to have it both ways. Either strict client-server with no
downgrade is supported by the signaling or it is not.

The needs of the strict crowd cannot be ignored without failing to reach
consensus.
The strict requirements do not actually impose any obligation on clients
wishing to only do weak opportunistic with no DNSSEC validation or any
other non-verification type activity.
As you note, there is no way to force a client to validate.
I don't believe anyone is saying otherwise.

> Also, some folks on this list have already complained about added
> complexity of discovery mechanisms.
>

Please provide pointers or let them speak for themselves.
We should be discussing the requirements first, and addressing whether the
discovery mechanisms are too complex. Those may in fact be implementation
issues that might be addressed without impacting the high level
requirements.

> It is impossible for a server to tell whether a resolver is
> authenticating, so being able to say "you must authenticate" is kinda just
> posturing. The choice of whether or not to connect should always be with
> the resolver. Further, if a resolver is using a mechanism that requires
> strict authentication, it truly doesn't matter what the authoritative
> server has said it wants.
>

I think you are misreading what this paragraph says.

What it really says (or should say) is:
A given domain may have multiple authoritative name servers.
It may be the case that some of those name servers offer secure transport,
and others do not.
It may also be the case that some of those name servers do not offer
non-secure transport (i.e. regular port 53).
The method of publication of availability of secure transport MUST be
capable of distinguishing the availability of secure transport on a
per-authoritative server basis, and the (un)availability of non-secure
transport on a per-authoritative server basis.
I.e. ns1.provider-x.net may do DoT only (no port 53), and ns2.provider-y.net
may not offer any secure transport (only port 53), and ns3.provider-z.net
may offer DoH as well as insecure transport (so port 53 and port 443/DoH).
A client may be opportunistic, and choose any of the three, or may choose
to only use port 53 (thus only ns2 and ns3).
A second client may want to use strict security only, and may support DoT
and DoH, and thus use ns1 or ns3.
A third client may want to use strict security only, and may only support
DoT, and thus use ns1 only.

The choice of secure or not is always available to the client.
However, any client wishing to use secure-only MUST be able to detect and
prevent downgrade attacks. This places more limitations on publication,
naturally.
The server CAN know that a resolver appears to want to authenticate, if it
only offers secure transport and the resolver connects.
Not offering port 53 service in both its publication mechanism and in ports
that are providing DNS, is an unambiguous way of offering non-downgradable
service, should the client want to validate.

It matters what the server says it offers, as that is the only way to
prevent downgrade attacks from succeeding.

>
> This whole requirement could be dropped and it would not affect the
> security or availability of the desired service.
>

As Mark A would say, "This is wrong."
Well, technically, what the claim should be is regarding privacy, rather
than security. But it would still be wrong.
The only way to not affect the privacy, is to keep the requirement, and to
clarify the positive and negative elements of the publication scheme (i.e.
to say yes/no to port 53 in addition to optional yes to other secure
transports.).

It probably should be more detailed in tying the publication of supported
protocols to the name server names (and that the publication point would
need to be at or under those names), rather than in any way tied to a zone.
It is also worth suggesting that different capabilities can and should
require different names, even if the IP address of the server is the same.
E.g. ns1-strict-dot.nameserver-zone.example and
ns2-insecure.nameserver-zone.example for the same IP, with the former
indicating only port 853 should be used, and the latter indicating that
only port 53 should be used.
Then, the choice could be implemented at a zone level, by using NS records
of the former or the latter, as a signal for how that specific zone can be
reached by a client (modulo the client's desire to use secure transport if
it is available).

This is a bit complicated only in that it is multi-dimensional (multiple
DNS operators, possibly multiple jurisdictions with restrictions on
encryption, plus multiple zones per name server) and has a theoretically
large number of possible combinations.
However, in practice, any given zone will have a finite (and likely small)
number of name servers in its NS set (delegation and/or apex), and tying
the signaling on secure transport availability to the name server names is
an obvious choice that requires nearly no work or complexity on the
resolver.
The resolver has a policy that is either "don't want to use any encrypted
transport", or "might use it if the first one I check offers it", or "if
any secure transports are offered, I won't use anything less than a secure
transport".
>From that policy, the processing should be extremely deterministic.

And, for the most part, by tying the publication to name server names,
means that the chances of the information about secure transport not
already being cached is inversely proportional to the popularity of the
name servers themselves.
I.e. the  overhead associated this should become noise, based on the
log/log relationship on zone/server popularity and query volume.

Basically, this isn't difficult at all, IMNSHO.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Wed, 4 Nov 2020 01:36:39 -0800

> 
>> Also, some folks on this list have already complained about added complexity of discovery mechanisms.
> 

I realized after writing this that this was overly snarky and inappropriate.
It also occurred to me that you may actually speak for others.
Please accept my sincere apologies.

I would encourage more information about what (those?) folks want the use case or flow to generally look like. Eg do they want to use a secure transport for forwarding queries to a larger resolver which does the validation for them and return AD=1?
Also, it is possible for different secure transports to be used in a 2 or more secure transport chain, eg DoH to resolver, DoH to big forwarded resolver, and DoT to authority. That does not necessarily increase complexity on the first system.

Brian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Nov 2020 15:04:37 +0000

> IN ADVANCE, before connecting, if encryption is supposed to be

It would be useful if a resolver could tell in advance, and at a cost less than port-checking. There could be a new protocols developed to do that. I don't see this as a requirement, though, given the low cost of port-checking.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Nov 2020 15:06:54 +0000

On Nov 4, 2020, at 12:37 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> certificate".

Such hints could indeed be useful. I don't see them as a requirement, particularly if that requirement delays increased privacy or, worse, makes it harder to deploy.

> Other IETF protocols have such hints from the

SPF is an excellent example of a protocol that has made things more fragile while intending to make them more secure.

> Is it worth the complexity? I don't know but it is not useless.

Fully agree.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Nov 2020 15:07:46 +0000

> ECS should be mentioned here, as a "fourth way" (or may be just a

+1 

> servers, they talk mostly to resolvers (plus the CS students probing

That confused me as well.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Nov 2020 15:11:35 +0000

On Nov 4, 2020, at 1:10 AM, Brian Dickson <[email-masked]> wrote:
>> If the WG does with DoT and/or DoQ, you can discover the server's capabilities by probing port 853 and TBD-Q, or maybe by finding TLSA records. There is only a need to "publish" a list of secure protocols if they include DoH or DoHoQ.
>> 

> No, this is not accurate, and highly misleading. I am not casting aspersions on your intent, merely calling out the correctness of the argument.

The phrase "highly misleading" does indeed cast aspersions. 

> The prevention of downgrade attacks requires publication of servers capabilities and intents, including prefered or offered protocols.
> This includes DoT.

The prevention of downgrade attacks is not needed for the use case that has been described so far (opportunistic encryption). It is only needed for the use case that has not been described (failed DNS resolution when authentication is not possible).

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Nov 2020 09:18:44 -0800

On Wed, Nov 4, 2020 at 7:11 AM Paul Hoffman <[email-masked]> wrote:

> The prevention of downgrade attacks is not needed for the use case that
> has been described so far (opportunistic encryption). It is only needed for
> the use case that has not been described (failed DNS resolution when
> authentication is not possible).
>

What do you mean by "has been described"? You basically just described both
of these.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Nov 2020 17:41:12 +0000

On Nov 4, 2020, at 9:18 AM, Eric Rescorla <[email-masked]> wrote:
> What do you mean by "has been described"? You basically just described both of these.

Only basically. So far on the list, only part of the mechanism (do authentication) has been described. The rest of the mechanism (what to do when authentication for the first server tried fails) and the use case (why you would want to fail DNS resolution) has not.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Nov 2020 10:33:26 -0800

On Wed, Nov 4, 2020 at 9:41 AM Paul Hoffman <[email-masked]> wrote:

> Only basically. So far on the list, only part of the mechanism (do
> authentication) has been described. The rest of the mechanism (what to do
> when authentication for the first server tried fails)

Sure, one would need to define the mechanism.

and the use case (why you would want to fail DNS resolution) has not.

It's not that one wants to fail DNS resolution but rather that one does not
want to send one's query in the clear. I'm not sure what more needs to be
said there.

-Ekr

---

From: Peter van Dijk <[email-masked]>
Date: Sun, 15 Nov 2020 14:52:38 +0100

> It would be useful if a resolver could tell in advance, and at a cost less than port-checking. There could be a new protocols developed to do that. I don't see this as a requirement, though, given…

The cost of port checking is not low.

Variant 1: try 853 and 53 in parallel. High code complexity and a high likelihood that the first query to a 'new' auth (where 'new' might be measured in minutes) will be plain text anyway.

Variant 2: try 853 first. How long do we wait for a timeout? In DNS, 500ms is a long time.

This is not happy eyeballs where both transports (v4 and v6) tend to have identical security properties. 

DNS Flag Day 2019 (no more EDNS fallbacks) was designed to reduce probing and guessing in the resolver process. I'd love for us to not add probing and guessing in other parts of that process.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 15 Nov 2020 16:52:28 +0000

Thanks for the response! I hope that there is more list discussion before the WG meeting this week.

> The cost of port checking is not low.

We disagree in the general case, because I'm assuming a transport cache that is filled before an actual query is sent. Transport caches would be useful for both opportunistic and authenticated encryption.

We agree in the specific case of "determine the transport at the time the resolver's user is waiting for an answer".

> Variant 1: try 853 and 53 in parallel. High code complexity and a high likelihood that the first query to a 'new' auth (where 'new' might be measured in minutes) will be plain text anyway.

There is no code complexity if you are probing the fill a transport cache. There is definitely the large, classical complexity of asyncy-with-abort for determining when needed.

> Variant 2: try 853 first. How long do we wait for a timeout? In DNS, 500ms is a long time.

For cache-filling, a 500 or 1000 ms timeout seems reasonable. For immediate need, there is no way to sanely balance "additional privacy" against "addition latency" in a way that everyone (or even most people) would agree to.

> This is not happy eyeballs where both transports (v4 and v6) tend to have identical security properties. 

Exactly right.

> DNS Flag Day 2019 (no more EDNS fallbacks) was designed to reduce probing and guessing in the resolver process. I'd love for us to not add probing and guessing in other parts of that process.

I would love for that as well, if we make the solution barely harder to implement than port-checking. I am skeptical that we as a group can make a simple solution because everything we as a group do ends up much more complicated than we expected when we started. This is why I think we should compare the result to port-checking.

The interesting wrinkle here is that if the solution is DNS-based, it will very likely be faster than port-checking because in most cases the result will come back much faster than any timeout that someone would pick for port-checking. The answer will likely also have much more value than a port check. That gives us (at least) two axes to compare and argue about, so I think it is worth pursuing. Tony's draft has a lot of good comparison thinking in it already.

--Paul Hoffman

---

From: Peter van Dijk <[email-masked]>
Date: Sun, 15 Nov 2020 19:18:32 +0100

> We disagree in the general case, because I'm assuming a transport cache that is filled before an actual query is sent. Transport caches would be useful for both opportunistic and authenticated encr…

That makes sense, but there's a risk of penalizing the 'small domain
owner' here.

+1

> For cache-filling, a 500 or 1000 ms timeout seems reasonable. For immediate need, there is no way to sanely balance "additional privacy" against "addition latency" in a way that everyone (or even m…

Agreed. It's a big spectrum from DOTPIN (~no additional latency, lots
of privacy, but some serious deployment impediments) to some
interpretation of 'just do TLSA' (lots of additional latency) and any
other proposal is likely to fall somewhere on that spectrum, with some
room to be even worse than TLSA. Anything involving potential timeouts
does look bad from the start, to me.

> I would love for that as well, if we make the solution barely harder to implement than port-checking. I am skeptical that we as a group can make a simple solution because everything we as a group do ends up much more complicated than we expected when we started. 

We are terrible people :-)

> This is why I think we should compare the result to port-checking.

It is a useful baseline for comparison, indeed.

> The interesting wrinkle here is that if the solution is DNS-based, it will very likely be faster than port-checking because in most cases the result will come back much faster than any timeout that…

Yes.

Kind regards,