Subject: [Add] new draft: draft-grover-add-policy-detection-00

From: Andy Grover <[email-masked]>
Date: Mon, 8 Jul 2019 11:29:02 -0700

Hello all,

We've posted an initial draft of draft-grover-add-policy-detection,
which proposes a method of identifying if content filtering or other
policy is implemented on the local resolver, so applications doing DNS
resolution can adjust their behavior.

Thanks -- Regards -- Andy

-------- Forwarded Message --------
Subject: New Version Notification for
draft-grover-add-policy-detection-00.txt
Date: Mon, 08 Jul 2019 10:46:45 -0700
From: [email-masked]
To: Andy Grover <[email-masked]>, Peter Saint-Andre
<[email-masked]>

A new version of I-D, draft-grover-add-policy-detection-00.txt
has been successfully submitted by Peter Saint-Andre and posted to the
IETF repository.

Name:		draft-grover-add-policy-detection
Revision:	00
Title:		DNS Resolver-Based Policy Detection Domain
Document date:	2019-07-08
Group:		Individual Submission
Pages:		6
URL:
https://www.ietf.org/internet-drafts/draft-grover-add-policy-detection-00.txt
Status:
https://datatracker.ietf.org/doc/draft-grover-add-policy-detection/
Htmlized:
https://tools.ietf.org/html/draft-grover-add-policy-detection-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-grover-add-policy-detection

Abstract:
   This document specifies the behavior that is expected from the Domain
   Name System with regard to DNS queries for the special-use domain
   name 'TBD.arpa' and designates this domain as a special-use domain
   name.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 8 Jul 2019 14:42:25 -0600

A point of clarification...

Paul Hoffman was kind enough to point us to
draft-sah-resolver-information and draft-sah-resinfo-doh just now, which
intend to solve a similar problem. It's not that we think those I-Ds
define a bad approach, instead we missed them entirely. We will read
them between now and the Montreal meeting so that we can discuss them
intelligently in person and on the relevant discussion lists.

Sorry about the lack of due diligence!

Peter

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 08 Jul 2019 23:10:59 +0200

Moin!

> resolution can adjust their behavior.
In what way? While there are lots of MUST in the draft for DNS elements
I did not find a single word on what applications then do with that
information.

To get more detailed on the DNS side 5.5 is not how DNS works.
Authoritative DNS servers reply with REFUSED or referrals to stuff they
don’t know. The can only answer NXDomain if they are authoritative for
the domain.

5.4 and 5.6 together are contradictory as a DNS server operator for
sure runs a Caching DNS server, but one is MUST (the server software)
and one is SHOULD (the server operator). Why, and why does the
application description (5.2) doesn’t have any normative language?

So long
-Ralf
—--
Ralf Weber

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 9 Jul 2019 11:26:29 +0200 (CEST)

> Il 8 luglio 2019 22:42 Peter Saint-Andre <[email-masked]> ha scritto:
> 
>  

Still, if I remember the two sah drafts correctly, they define the basic framework for discovering information about the local resolver, but neither deals with discovering local policy, so we could still turn this effort into an additional document building on sah-resolver to add that piece of information.

If we do, however, I would suggest that we work on a much more nuanced expression of policy behaviour, including the origin of the policy (user, network or law) and perhaps even a description of the reasons and of the types of destinations that are affected. While "neutral" applications might just want to discover that policy exists and avoid Do*-to-the-cloud in any such case, I would expect "opinionated" applications ;-) to behave differently depending on specific policy types and sources, as well as, maybe, the location of the user and other factors. In such case, and barring the problem of lying resolvers, having more detailed information would lead to matching the expectations of the user much more precisely.

Ciao,
-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 09 Jul 2019 20:08:05 +1000

On Tue, Jul 9, 2019, at 19:26, Vittorio Bertola wrote:
> Still, if I remember the two sah drafts correctly, they define the 
> basic framework for discovering information about the local resolver, 
> but neither deals with discovering local policy, 

That was my understanding also, which makes this useful at least in terms of framing.  As an extension to the -sah drafts, if that is where the community is headed (I have my reservations), and this fits there, then changing to fit into that framework makes sense.  As it stands, this seems much easier to implement.
 
> If we do, however, I would suggest that we work on a much more nuanced 
> expression of policy behaviour, [...] In such case, and barring the problem of lying 
> resolvers, having more detailed information would lead to matching the 
> expectations of the user much more precisely.

This is a more difficult point.  If the intent is to build this sort of infrastructure, then I agree that it needs a lot more rigour.  Probably both along the lines you suggest here, and finding ways in which that information can be authenticated.  Personally, I don't hold high hopes of that sort of approach being successful, but only because the task is extraordinarily large in scope.  If you include authentication, that likely requires building decentralized systems for establishing accountability, which is one of the Hard problems.

My understanding of the approach Andy suggests that it is much less ambitious in scope.  As I understand this, the view is that choosing your own resolver is important enough to deploy by default.  Maybe that view says that it is inevitable. 

Importantly, it recognizes that this can't be a global default starting tomorrow.  There will need to be an adjustment period.  People use DNS in ways that are incompatible with this approach, which leads to surprising outcomes (like inadvertent circumvention of certain local policies).

By providing an option to disable use of BYOR, this gives local administrators time to adjust their strategy.  As you say, this is not an idea contemplated by the -sah drafts, but it could be complementary.

Cheers,
Martin

---

From: <[email-masked]>
Date: Wed, 10 Jul 2019 12:12:43 +0000

Andy,

Re. draft-grover-add-policy-detection, how do you see from a protocol perspective clients handling a policy negotiation with servers?  How will they behave when the server's policy conflicts with the client's mandatory and optional policy preferences? For example if no suitable DoH (or DoT) server is available, when/how does the client fall back to plain text DNS? 

Thanks

Andy

[email-masked]

This email contains information from BT that might be privileged or confidential. And it's only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks.
We monitor our email systems and may record all our emails.
British Telecommunications plc
R/O : 81 Newgate Street, London EC1A 7AJ
Registered in England: No 1800000

-----Original Message-----
From: Add [mailto:[email-masked]] On Behalf Of Andy Grover
Sent: 08 July 2019 19:29
To: [email-masked]
Subject: [Add] new draft: draft-grover-add-policy-detection-00

Hello all,

We've posted an initial draft of draft-grover-add-policy-detection,
which proposes a method of identifying if content filtering or other policy is implemented on the local resolver, so applications doing DNS resolution can adjust their behavior.

-------- Forwarded Message --------
To: Andy Grover <[email-masked]>, Peter Saint-Andre <[email-masked]>

A new version of I-D, draft-grover-add-policy-detection-00.txt
has been successfully submitted by Peter Saint-Andre and posted to the IETF repository.

Abstract:

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

---

From: Andy Grover <[email-masked]>
Date: Wed, 10 Jul 2019 10:14:59 -0700

On 7/10/19 5:12 AM, [email-masked] wrote:
> Re. draft-grover-add-policy-detection, how do you see from a protocol
> perspective clients handling a policy negotiation with servers?  How
> will they behave when the server's policy conflicts with the client's
> mandatory and optional policy preferences? For example if no suitable
> DoH (or DoT) server is available, when/how does the client fall back
> to plain text DNS?
I would say it's only a negotiation in that the client is deciding
whether to use app-based DNS such as DoH, or to not use it. This
proposal doesn't tell the client anything about the local DNS resolver's
policy, just that it *has* one, and it's up to the app to decide how to
use that information -- the most straightforward case would be the app
deciding that since the local resolver has special behavior (i.e. the
policy), that app-based DNS would unavoidably bypass, that it's more
important to keep that in place by using the default network resolver
rather than doing app-based name resolution.

This proposal doesn't touch on the example you give. If app-based DNS
isn't working then policy or no, the default network DNS resolver should
be used.

-- Andy

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 17 Jul 2019 23:33:06 +0000

I appreciate the intent behind this draft to allow DNS-capable apps to detect if configured DNS resolvers need to be deferred to. However, I agree with Ralf that NXDOMAIN is the wrong way to signal that.

What about defining a new TXT record format to signal the presence of policies? This has the benefits of 1) not overloading the interpretation of whether the domain exists or not as well as 2) giving room for future flexibility beyond the binary "resolver (does|does not) have DNS policies in place you shouldn't bypass" signal.

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of Ralf Weber <[email-masked]>
Sent: Monday, July 8, 2019 2:10 PM
To: Andy Grover <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Add] new draft: draft-grover-add-policy-detection-00

Moin!

So long
-Ralf
—--
Ralf Weber

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ccc63ddd828e040943c2008d703e8ced1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636982170753293139&amp;sdata=Uex9ZlO2OiBLqKzkVwDgX6Ewf%2B6Fvd1gUAioDOGBnA4%3D&amp;reserved=0

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Jul 2019 23:44:03 +0000

> What about defining a new TXT record format to signal the presence of policies? This has the benefits of 1) not overloading the interpretation of whether the domain exists or not as well as 2) givi…

Please see <https://datatracker.ietf.org/doc/draft-sah-resolver-information/> for a proposal that is being discussed in the DNSOP WG. It proposes a message format (JSON) and two transports (DNS and HTTPS) that can be used by a resolver for lots of things, including the policy ideas in the draft that this thread is about.

Discussion of draft-sah-resolver-information should be on the DNSOP list. There will be a slot in the meeting next week to discuss it.

--Paul Hoffman

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Jul 2019 16:57:00 -0700

On Wed, Jul 17, 2019 at 4:44 PM Paul Hoffman <[email-masked]> wrote:

> > I appreciate the intent behind this draft to allow DNS-capable apps to
> detect if configured DNS resolvers need to be deferred to. However, I agree
> with Ralf that NXDOMAIN is the wrong way to signal that.
> >
> > What about defining a new TXT record format to signal the presence of
> policies? This has the benefits of 1) not overloading the interpretation of
> whether the domain exists or not as well as 2) giving room for future
> flexibility beyond the binary "resolver (does|does not) have DNS policies
> in place you shouldn't bypass" signal.
>
> Please see <
> https://datatracker.ietf.org/doc/draft-sah-resolver-information/> for a
> proposal that is being discussed in the DNSOP WG. It proposes a message
> format (JSON) and two transports (DNS and HTTPS) that can be used by a
> resolver for lots of things, including the policy ideas in the draft that
> this thread is about.

Is there a good definition of the term "policy ideas"?

thanks,
Rob

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Jul 2019 00:08:36 +0000

> Is there a good definition of the term "policy ideas"?

No, but you already knew that. Most specifications of policy ever created in the IETF have been dissatisfying to some people for various (good) reasons. That's one of the reasons why the spec in draft-sah-resolver-information allow anyone to create their own temporary specs before standardization.

--Paul Hoffman

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Jul 2019 17:12:09 -0700

On Wed, Jul 17, 2019 at 5:08 PM Paul Hoffman <[email-masked]> wrote:

> No, but you already knew that.

Yes, I did. But you still wrote it.

> Most specifications of policy ever created in the IETF have been
> dissatisfying to some people for various (good) reasons. That's one of the
> reasons why the spec in draft-sah-resolver-information allow anyone to
> create their own temporary specs before standardization.
>

So, the spec allows anyone to create whatever they want? Why would that be
called a standard? Isn't that just writing code?

I might be missing something, but this doesn't seem to make sense.

thanks,
Rob