Subject: [dnsoverhttp] Configured as trustworthy

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 16 Jun 2017 21:40:41 +0000

Hi,

Minor question on draft-hoffman-dns-over-https-01:

Section 9 states:

 Instead, a client MUST only trust DNS API server that is configured as trustworthy.

Perhaps obvious to many but may I ask for a more precise definition of what is meant by “configured as trustworthy”?

Best Regards
Göran

---

From: Patrick McManus <[email-masked]>
Date: Fri, 16 Jun 2017 17:47:08 -0400

as with most things https, the protocol doesn't try to define a policy for
the client - though I think this could still use a little more
non-normative exploration of the possibilities..

the existing text just asks you to consider the scope of authority for the
server when considering poisoning attacks. (so a dns api server configured
for the role of recursive resolver is basically configured as trustworthy
for everything, but other roles have lesser scope..)

On Fri, Jun 16, 2017 at 5:40 PM, Göran Eriksson AP <
[email-masked]> wrote:

> Perhaps obvious to many but may I ask for a more precise definition of
> what is meant by “configured as trustworthy”?
>
> Best Regards
> Göran
>
> _______________________________________________
> dnsoverhttp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsoverhttp
>
>

---

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 16 Jun 2017 22:15:03 +0000

Tnx

as with most things https, the protocol doesn't try to define a policy for the client - though I think this could still use a little more non-normative exploration of the possibilities..

Yeah- the value of the MUST is of course dependent of the precision and clarity of the text following it, :-).

the existing text just asks you to consider the scope of authority for the server when considering poisoning attacks. (so a dns api server configured for the role of recursive resolver is basically configured as trustworthy for everything, but other roles have lesser scope..)

Right. Any thoughts about allowing the origin (of a web app) to provide the UA with a ‘signal’ on its preferences (fully aware of this more being an API question but such matters would have a potential impact on the protocol as well)? Or is that outside the scope of this draft/work?

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 16 Jun 2017 19:13:29 -0400

I'm really interested in these kinds of questions (user agent behavior,
origin based rules, interaction with dnssec), but it might be worth keeping
them separate from the protocol specification.  Maybe a second doc...

On Jun 16, 2017 3:15 PM, "Göran Eriksson AP" <[email-masked]>
wrote:

> Right. Any thoughts about allowing the origin (of a web app) to provide
> the UA with a ‘signal’ on its preferences (fully aware of this more being
> an API question but such matters would have a potential impact on the
> protocol as well)? Or is that outside the scope of this draft/work?
>
>

---

From: Göran Eriksson AP <[email-masked]>
Date: Sat, 17 Jun 2017 07:39:57 +0000

(user agent behavior, origin based rules, interaction with dnssec)

+1.

worth keeping them separate from the protocol specification.

Maybe a second doc...

Agree.