Subject: [Add] Updated requirements draft

From: "Chris Box (BT)" <[email-masked]>
Date: Tue, 3 Nov 2020 19:04:47 +0000

Hi everyone,

As yesterday was deadline day there was of course a surge of new drafts.

One of those is a first revision to draft-box-add-requirements. Following
the feedback from the first interim, this is now tightly focussed on the
"single use case", that of discovering the encrypted resolvers that are
claimed to be equivalent to a resolver (e.g. Do53) that the client already
knows about. This narrower focus has allowed for more description of the
case itself, and there are now 16 tentative requirements that flow from it.
Happily it's only 10 pages long.

https://tools.ietf.org/html/draft-box-add-requirements-01

I'm sure you will have opinions on the content, and I'd like to hear them.
I don't claim the draft is fully correct, but hopefully it's a good basis
to start discussion.
<https://www.ietf.org/archive/id/draft-pauly-add-deer-00.html>

Please share your thoughts on the list, or directly. Github issues are also
possible, but preferably after I've had time to tidy up and respond to the
existing ones which I hope to do on Weds or Thurs.

Thanks,
Chris

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 3 Nov 2020 15:03:10 -0500

Thank you for the updated draft.  Some comments:

Introduction
> it lists
> requirements that any proposed discovery mechanisms should address.
> They can do this either by providing a solution, or by explicitly
> stating why it is not in scope.

This seems like a fine sentiment to me, but Sections 3-6 do not seem
compatible with it.  These sections use phrasings like "a solution is
required", "must support", "need to be supported" unconditionally.  I think
the phrasing should be adjusted so that requirements language only appears
in Section 7, where it can be made clear that these are not mandatory.
Prior sections should focus on describing the use cases that would benefit
if these requirements are met.

Section 3.1
> Network-identified is preferred

I don't think this is true.  For example, it may be operationally
preferable to let the resolver keep control of publishing its own
configuration, where the potential for skew and confusion is minimized.  I
also don't think this claim belongs in a requirements document.

Section 3.2
> a means is needed for the discovery process to work
> from a locally-addressed Do53 resolver to an Encrypted DNS resolver
> that is accessible either at the same (local) address, or at a
> different global address.  Both options need to be supported.

I don't think we need to support all imaginable configurations that
correspond to our general use case.  We only "need" to solve one
configuration, and we can consider covering others where it is fruitful to
do so.

It seems like the motivating use case here is in Section 5 (a forward
reference would be helpful).

Section 5
> It is frequently the case that Do53 resolvers announced by home
> networks are difficult to upgrade to support encrypted operation.

I think it would be interesting to elucidate this further.  In particular,
I think we should distinguish between routers that cannot be upgraded at
all, and routers that could receive small patches but would present
difficulties when introducing major new functionality.

For example, it may be that there are routers that would perform poorly
when terminating TLS locally, but could be updated to forward port 853 to
the upstream resolver.

> it is possible that the only option for encrypted
> operation is to refer to a separate globally-addressed encrypted DNS
> resolver.

I think it would be helpful to explain under what circumstances such a
separate resolver would be likely to provide "equivalence" as described in
Section 3.

Section 6
I like the presentation of the threat model here.

I don't understand the point about ensuring an attacker cannot "Influence
automatic discovery mechanisms".  Does this mean "ensure the attacker
cannot interfere with other secure name resolution mechanisms"?

Section 7
I like the enumeration structure here.

I'm still concerned about the use of normative language.  No single
"solution" is going to cover all of these requirements, so what is it that
these MUSTs mean?  I would prefer a non-normative description of each
requirement or capability.

On Tue, Nov 3, 2020 at 2:05 PM Chris Box (BT) <[email-masked]>
wrote:

> Please share your thoughts on the list, or directly. Github issues are
> also possible, but preferably after I've had time to tidy up and respond to
> the existing ones which I hope to do on Weds or Thurs.
>
> Thanks,
> Chris
>
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "Chris Box (BT)" <[email-masked]>
Date: Wed, 4 Nov 2020 19:02:13 +0000

Ben,

Thanks for your comments.

> if these requirements are met.

I'm happy to adjust the phrasing. If it turns out that more than one
solution is required to satisfy the requirements, then clearly no single
solution would comply with them all.

> also don't think this claim belongs in a requirements document.

Originally I thought this sentence was uncontroversial, but now you've
opened my eyes I can see it's probably best left out. It doesn't need to be
there.

> reference would be helpful).

Yes I'll add the forward reference. And again, if we cannot have a single
solution that meets all requirements of this case, then yes I can see there
could be separate solutions for:

   - Local address Do53 to same local address DoH
   - Local address Do53 to global address DoH

Is this what you mean?  Or are you saying that some particular
configurations should not be solved?

> when terminating TLS locally, but could be updated to forward port 853 to

This is definitely something that could be explored.

> separate resolver would be likely to provide "equivalence" as described in

Ok.

> cannot interfere with other secure name resolution mechanisms"?

Perhaps Tommy or Chris W could answer this better.

> requirement or capability.

Not sure how best to proceed on this front. I'd value the opinion of others
in the working group too, i.e. what do you consider is the best way to
state these requirements?

Chris

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 4 Nov 2020 14:38:47 -0500

...

> configurations should not be solved?

Yes.  There's a whole slew of permutations here: Do53 IP is local or
global, encrypted DNS IP is same or different, DoH or DoT,
network-identified or resolver-identified, etc.  I don't think we need to
solve all combinations, and some combinations may not have good solutions.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Nov 2020 10:23:55 +0100

On Tue, Nov 03, 2020 at 07:04:47PM +0000,
 Chris Box (BT) <[email-masked]> wrote 
 a message of 79 lines which said:

> One of those is a first revision to
> draft-box-add-requirements. Following the feedback from the first
> interim, this is now tightly focussed on the "single use case", that
> of discovering the encrypted resolvers that are claimed to be
> equivalent to a resolver (e.g. Do53) that the client already knows
> about. This narrower focus

This is more reasonable, indeed. But it lets open an important
question: what's left? If the encrypted resolver is equivalent to the
unencrypted (for instance if they both lie in the same way, e. g. they
both censor SciHub), encryption provides only a small benefit. Sure,
it is always better to encrypt but, since the default unencrypted
resolver is probably close to the user, in the same AS, the benefit is
not so important.

Speaking of this, the draft says:

> Using an encrypted and authenticated resolver that is equivalent to
> the one provisioned by the network can provide several benefits

The first benefit, "Prevent other devices on the network from
observing client DNS messages", is OK but the two others are
questionable:

* "Authenticate that the DNS resolver is the correct one" If you got
it from DHCP or RA, which are not very safe, authenticating is not so
important. If an attacker can hijack the DNS traffic to a rogue
encrypted resolver, he or she can also probably spoof DHCP or RA.

* "Verify that answers come from the selected DNS resolver" Same
remark.

Also, the introduction:

> While it is possible for clients to statically configure encrypted
> DNS resolvers to use, dynamic discovery and provisioning of
> encrypted resolvers can expand the usefulness and applicability of
> encrypted DNS to many more use cases.

Does not convince me. The good thing about DoT and DoH is that you can
safely use a resolver that you choosed. It means it was configured
statically. An encrypted resolver discovered by automatic means, from
hints of the access network, is only marginally better than an
unencrypted one.

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Nov 2020 12:49:11 +0000

> encrypted resolver, he or she can also probably spoof DHCP or RA.

There are layer 2 mechanisms to make that very difficult.

> * "Verify that answers come from the selected DNS resolver" Same

If you have layer 2 DHCP/RA security then it's reasonable for the network
to tell you how to authenticate the resolver as well as its address. The
resolver is often going to be some number of links away, so authenticating
it has the effect of stretching your layer 2 DHCP/RA security to reach the
more distant DNS service.

> hints of the access network, is only marginally better than an

True, but almost nobody is going to use it unless it is configured
automatically.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, South Bailey: Southwesterly 4 to 6, becoming variable 2 to 4. Rough
or very rough. Occasional rain or drizzle. Moderate or good, occasionally
poor.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Nov 2020 14:28:02 +0100

On Fri, Nov 06, 2020 at 12:49:11PM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 37 lines which said:

> > Does not convince me. The good thing about DoT and DoH is that you
> > can safely use a resolver that you choosed. It means it was
> > configured statically.

> True, but almost nobody is going to use it unless it is configured

"statically" does not mean by the end user. It can be by the OS, for
instance (systemd forwards to 8.8.8.8 by default...)