Subject: [Add] Terminology in draft-ietf-add-requirements - "secure" etc

From: Patrik Fältström <[email-masked]>
Date: Thu, 08 Jul 2021 08:08:27 +0200

In the requirements document, wordings are used like (example from section 4):

> Redirect secure DNS traffic to themselves when
> they would not otherwise handle DNS traffic.

I find it a bit confusing what the wording "secure DNS traffic" implies.

In various scenarios we might have (at least) situations when the traffic between stub and recursive resolver is encrypted or not. And it might be validated on the recursive resolver or not, and it might be possible for the stub resolver to query with DO flag or not.

Or to put it differently, the DNSSEC validation might:

1. Not take place at all
2. Take place in the recursive resolver side
3. Take place in the local client

In case (1) there is not much to do.

In case (2) the client must trust the recursive resolver.

In case (3) the recursive resolver do not have to trust the resolver.

In all cases the transport between client and recursive resolver can of course be encrypted or not.

May I ask for some carefully selected language here so that we do not call all three cases "secure"? Specifically if the only thing we are looking for is encrypted communication between stub and recursive resolver?

And IF we have some flags and negotiation taking place, would it not be a good idea for the client to actually know where validation takes place?

   Patrik

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Jul 2021 06:11:52 -0700

On Wed, Jul 7, 2021 at 11:08 PM Patrik Fältström <paf=
[email-masked]> wrote:

> In various scenarios we might have (at least) situations when the traffic
> between stub and recursive resolver is encrypted or not. And it might be
> validated on the recursive resolver or not, and it might be possible for
> the stub resolver to query with DO flag or not.
>
> May I ask for some carefully selected language here so that we do not call
> all three cases "secure"? Specifically if the only thing we are looking for
> is encrypted communication between stub and recursive resolver?
>
> And IF we have some flags and negotiation taking place, would it not be a
> good idea for the client to actually know where validation takes place?
>

Well, the client surely knows whether validation is taking place on the
client (spoiler alert: infrequently). How does an encrypted transport
change its epistemic situation wrt the recursive's validation practices
from where we are now?

-Ekr

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 08 Jul 2021 15:26:21 +0200

On 8 Jul 2021, at 15:11, Eric Rescorla wrote:

> Well, the client surely knows whether validation is taking place on the client (spoiler alert: infrequently).

Of course, but I might be sloppy with my term "client" here. It could be both the stub resolver or the application in my text. Whoever issues the DNS query do know whether it is doing validation... ;-)

> How does an encrypted transport change its epistemic situation wrt the recursive's validation practices from where we are now?

My message had two requests/questions:

1. Please ensure the wording in the draft is correct regarding the use of the word "secure".

2. If this whole work in ADD is to change the situation to the better, why not improve the corner of validation as well?

We need more validation of signed data in the world, not less.

   Patrik

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Jul 2021 09:03:53 -0700

On Thu, Jul 8, 2021 at 6:26 AM Patrik Fältström <[email-masked]> wrote:

> client (spoiler alert: infrequently).
>
> Of course, but I might be sloppy with my term "client" here. It could be
> both the stub resolver or the application in my text. Whoever issues the
> DNS query do know whether it is doing validation... ;-)
>

Is there any appreciable amount of stub resolvers doing DNSSEC without
being explicitly configured to do so? As noted above, the application knows
if it is.

> > How does an encrypted transport change its epistemic situation wrt the
> recursive's validation practices from where we are now?
>

Well, in the example you cite, "secure" is used in the context of "secure
DNS traffic", so I think that is reasonably clear. And the use of
"encrypted" is actually more inaccurate, because encryption does not
necessarily confer either integrity or data origin authentication.

2. If this whole work in ADD is to change the situation to the better, why
> not improve the corner of validation as well?
>

I actually don't think this is the right answer. This WG is about discovery
and to the extent to which you want to know the capabilities of your
resolver, then we should find a way to ask the resolver, not overload
discovery.

In any case, the protocol has extensions, so it's possible to add this
later.

-Ekr

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 08 Jul 2021 18:25:02 +0200

On 8 Jul 2021, at 18:03, Eric Rescorla wrote:

> Is there any appreciable amount of stub resolvers doing DNSSEC without being explicitly configured to do so? As noted above, the application knows if it is.

No, but if the DNS client (regardless of whether it is in the stub resolver or in the application) is to support this new protocol, it could be good if it could know whether the full service resolver it is using is doing DNSSEC validation.

> Well, in the example you cite, "secure" is used in the context of "secure DNS traffic", so I think that is reasonably clear. And the use of "encrypted" is actually more inaccurate, because encryption does not necessarily confer either integrity or data origin authentication.

If people that really work with security do understand what it means, then I am ok with it.

> I actually don't think this is the right answer. This WG is about discovery and to the extent to which you want to know the capabilities of your resolver, then we should find a way to ask the resolver, not overload discovery.

My point is that during the discovery process you might want to choose a full service resolver that do validation of DNSSEC signed responses and not one that do not. I view that as a parameter when selecting resolvers. As we see (as you wrote) DNSSEC validation is not done in the client.

> In any case, the protocol has extensions, so it's possible to add this later.

Ok.

   Patrik

---

From: Paul Wouters <[email-masked]>
Date: Thu, 8 Jul 2021 12:40:44 -0400 (EDT)

> Is there any appreciable amount of stub resolvers doing DNSSEC without being explicitly configured to do so? As noted above, the application knows if it is.

Yes.

All systems that come pre-installed with systemd-resolved for example.
(like the last few releases of Fedora). Those are  hardwired via
/etc/nsswitch.conf to even ignore the content of /etc/resolv.conf
and via glibc will automatically result in getaddrinfo() and
gethostbyname() resulting in getting DNSSEC validated.

But I think the question is a leading question. We should design for
this use case ever increasing. We see an increase in government
requirements to muck with DNS, and DNSSEC is the only proper defense
to at least force detection of this, as a successor to RPZ that could
do this is stalled by the RPZ draft still being stuck at the ISE.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Jul 2021 13:24:49 -0400

> being explicitly configured to do so? As noted above, the application knows

Well... systemd-resolver, but technically that's a local recursive cache, not
a stub resolver.   I would think of it more like old Solaris "nscd".
I think that the systemd people had notions of replacing some of the stub
resolver code in libc such that it would be more integrated, and would be
more MIF and container aware, and wouldn't require IP transport, which
sometimes is undesireable for certain containers to have.

I don't know if that happened or not.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Tony Finch <[email-masked]>
Date: Fri, 9 Jul 2021 10:17:30 +0100

Michael Richardson <[email-masked]> wrote:
> a stub resolver.

No, it's definitely a stub resolver. It doesn't provide recursive service
to other systems and it doesn't do iterative resolution. Basically all
systems these days have a system-wide DNS service with a cache, but even
though they are less feeble than the traditional libc resolver, they are
still stub resolvers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
democracy, participation, and the co-operative principle

---

From: tirumal reddy <[email-masked]>
Date: Sat, 10 Jul 2021 11:39:24 +0530

On Thu, 8 Jul 2021 at 21:55, Patrik Fältström <paf=
[email-masked]> wrote:

> No, but if the DNS client (regardless of whether it is in the stub
> resolver or in the application) is to support this new protocol, it could
> be good if it could know whether the full service resolver it is using is
> doing DNSSEC validation.
>
> >> 1. Please ensure the wording in the draft is correct regarding the use
> of
> >> the word "secure".
> >
> > Well, in the example you cite, "secure" is used in the context of
> "secure DNS traffic", so I think that is reasonably clear. And the use of
> > I actually don't think this is the right answer. This WG is about
> discovery and to the extent to which you want to know the capabilities of
> your resolver, then we should find a way to ask the resolver, not overload
> discovery.
>
> My point is that during the discovery process you might want to choose a
> full service resolver that do validation of DNSSEC signed responses and not
> one that do not. I view that as a parameter when selecting resolvers. As we
> see (as you wrote) DNSSEC validation is not done in the client.
>

You may want to look into
https://datatracker.ietf.org/doc/html/draft-reddy-add-resolver-info-03, it
discusses a mechanism for DNS resolvers to publish information about
themselves.

-Tiru

>    Patrik
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>