Subject: [Add] New I-D: draft-box-add-requirements-02

From: Chris Box <[email-masked]>
Date: Mon, 25 Jan 2021 12:33:35 +0000

Hi everyone,

During 109 and afterwards we discussed what qualified as "equivalent", but
to me this discussion highlighted that users, networks, and resolvers are
diverse, and it's not that simple. As a result, after some thinking,
there's now an -02 version of draft-box-add-requirements on datatracker.

The main change is that it steps away from equivalence, by removing any
mention of the properties of the encrypted resolvers, or properties of the
relationship between the network and the various resolvers. It focusses *only
on the ability of an untrusted network or resolver to designate one or more
resolvers*.

Designation is an assertion by a network, or by a resolver, that one or
more other resolvers are safe and appropriate to use without user
intervention. Clients will of course make their own decisions about whether
to use designated resolvers or not, using whatever information they have
available.

There are other changes. Three subcases of resolver-identified are split
out: local to local, local to upstream and public to public. And we discuss
the benefits of having a solution where the client can validate that the
designation came from an entity that already has full control of the
client's Do53 queries.

This new draft is only part of the requirements picture. In order to
support the client's decision-making process, it's expected that other
requirements drafts will list pieces of information that could be useful
(in some situations) if they were supplied to the client. These are
expected to be grouped into properties of the resolver, and properties of
the relationship between the designator and the resolver. There is also a
need to document requirements for trusted networks. At the interim on
Wednesday we should be able to discuss in more detail if you think this
overall approach will be a useful way forward.

Here are the links.

Title : Requirements for Discovering Designated Resolvers
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-box-add-requirements/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-box-add-requirements-02.html
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-box-add-requirements-02
Tools version: https://tools.ietf.org/html/draft-box-add-requirements-02
Repo: https://github.com/ietf-wg-add/draft-add-requirements

Chris

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 26 Jan 2021 18:30:26 +0100

On Mon, Jan 25, 2021 at 12:33:35PM +0000,
 Chris Box <[email-masked]> wrote 

> there's now an -02 version of draft-box-add-requirements on

The section 4, on privacy and security requirments does not mention
the risks that come from the resolver itself (encrypting communication
with an evil - for some definition of evil - resolver is
pointless). 

In the same way, R5.2 and R5.3 are fine but the risks of an attacker
inside the designated resolver are not mentioned. (An ISP using the
resolver to conduct surveillance over users, or serving censored
answers, for instance.) If these risks are excluded from the threat
model, it must be explicit.

---

From: Chris Box <[email-masked]>
Date: Tue, 26 Jan 2021 19:00:27 +0000

Stephane,

Thanks for reviewing the draft.

> with an evil - for some definition of evil - resolver is

Indeed, and I would say that encrypting traffic to a malicious resolver is
worse than sending it cleartext traffic, because it hinders any on-path
security tools that may be present.

> model, it must be explicit.

The draft does not say the client must use the designated resolver. On the
contrary, the client must come to its own decision about which resolvers it
uses, encrypted or otherwise. Everyone's threat model is slightly
different, and so the idea to be presented tomorrow is to empower the
client with as much information as possible to allow it to make the best
choice. For example, would it be useful if we enabled an ecosystem that
published information about resolvers? Not just self-publishing, but
directories of resolvers with a certain behaviour? This could in theory
enable bad practices to be identified, as well as giving a stamp of
approval to good ones.

Chris

---

From: "Winfield, Alister (Senior Solutions Architect)" <[email-masked]>
Date: Wed, 27 Jan 2021 08:55:50 +0000

Obviously bad,

I can think of local policy mechanisms that a network / application / device might choose to implement that would limit the success of such attacks. Plus if your network monitor is aware that the devices ought to be using a known DNS service and it doesn’t generate any connections to that service the lack of use would on its own be a signal that something is potentially wrong.

A.

From: Add <[email-masked]> on behalf of Chris Box <[email-masked]>
Date: Tuesday, 26 January 2021 at 19:00
To: Stephane Bortzmeyer <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] New I-D: draft-box-add-requirements-02

Stephane,

Indeed, and I would say that encrypting traffic to a malicious resolver is worse than sending it cleartext traffic, because it hinders any on-path security tools that may be present.

The draft does not say the client must use the designated resolver. On the contrary, the client must come to its own decision about which resolvers it uses, encrypted or otherwise. Everyone's threat model is slightly different, and so the idea to be presented tomorrow is to empower the client with as much information as possible to allow it to make the best choice. For example, would it be useful if we enabled an ecosystem that published information about resolvers? Not just self-publishing, but directories of resolvers with a certain behaviour? This could in theory enable bad practices to be identified, as well as giving a stamp of approval to good ones.

Chris
--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to [email-masked]. Thank you
--------------------------------------------------------------------

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Wed, 27 Jan 2021 13:37:07 +0000

To me, this statement highlights a concern that has been raised a number of times:
“The draft does not say the client must use the designated resolver. On the contrary, the client must come to its own decision about which resolvers it uses, encrypted or otherwise.”

The Network Operator’s intent *is* for the client / device to use the designated resolver advertised for that network.  

-Vinny

From: Add <[email-masked]> On Behalf Of Winfield, Alister (Senior Solutions Architect)
Sent: Wednesday, January 27, 2021 3:56 AM
To: Chris Box <[email-masked]>; Stephane Bortzmeyer <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: New I-D: draft-box-add-requirements-02

Obviously bad,

A.

From: Add <[email-masked] <mailto:[email-masked]> > on behalf of Chris Box <[email-masked] <mailto:[email-masked]> >
Date: Tuesday, 26 January 2021 at 19:00
To: Stephane Bortzmeyer <[email-masked] <mailto:[email-masked]> >
Cc: ADD Mailing list <[email-masked] <mailto:[email-masked]> >
Subject: [EXTERNAL] Re: [Add] New I-D: draft-box-add-requirements-02

Stephane,

Chris

This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to [email-masked] <mailto:[email-masked]> . Thank you

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Jan 2021 14:46:54 +0100

On Wed, Jan 27, 2021 at 01:37:07PM +0000,
 Vinny Parla (vparla) <[email-masked]> wrote 
 a message of 402 lines which said:

> The Network Operator’s intent *is* for the client / device to use
> the designated resolver advertised for that network.

If the network operator controls the endpoints (typical case inside an
organization), it is easy (well, at least, possible) to do so.

If it does not (case of an Internet Access Provider), then it must not
force the clients to use a specific resolver.

Today, the three drafts draft-pauly-add-deer, draft-btw-add-home and
draft-box-add-requirements are, in my opinion, quite "neutral". They
describe technical ways to send information to the client and does not
say what to do with it. This is reasonable but my concern, from the
beginning of the ADD effort, has always been that, should they be
published as standards track RFCs, they will be regarded as
mandatory-to-use "the IETF said you must not use DoH/DoT except
towards a resolver retrieved by these mechanisms". This is why threat
modelling and security considerations are very important.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Jan 2021 14:54:38 +0100

On Tue, Jan 26, 2021 at 07:00:27PM +0000,
 Chris Box <[email-masked]> wrote 
 a message of 73 lines which said:

> I would say that encrypting traffic to a malicious resolver is worse
> than sending it cleartext traffic,

At least it is not better. That's why the entire ADD effort brings
little value since it will only allow to switch to encryption towards
the SAME (or an "equivalent") resolver. Specially in "closed" networks,
this does not improve security a lot.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 27 Jan 2021 15:09:46 +0100 (CET)

> Il 27/01/2021 14:46 Stephane Bortzmeyer <[email-masked]> ha scritto:
> 
>  

Well, it depends. Whoever provides Internet access through the network may impose conditions, or be required by applicable regulation to impose conditions, which could include the use of a specific resolver. Clients, of course, will still be able to decide whether they want to accept that indication and connect to the network, reject that indication and do not connect to the network, or connect to the network while trying to bypass that indication and use a different resolver.

IMHO, it could perhaps be useful to clients if the discovery mechanism allowed the entities designating a resolver to specify, as part of the additional information, whether they mean "this resolver is available but I'm fine if you want to use another one" or rather "you must use this resolver if you want to use this network". This would allow clients to differentiate their decisions and/or their UI messages to the end-user (if necessary). In a way, it could also be an evolution of the "canary domain" concept.

> modelling and security considerations are very important.

I think that any malicious behaviour by the resolver is out of scope for this draft, simply because the draft deals with an existing network/resolver designating another one; if the existing network/resolver is malicious or captured by an attacker, of course the designated resolver could also be malicious, but you would already be in trouble if no discovery existed and you just continued to use the Do53 resolver. As long as the discovery mechanism is in itself secure, it is not adding risks from this point of view.

Regarding general client policies, I think that recommendations or constraints on the use of "non local" resolvers may rather come from outside the technical standardization process. The fact that an IETF standard exists has never implied that people cannot do different things in other ways if they want.

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Jan 2021 06:15:22 -0800

On Wed, Jan 27, 2021 at 5:37 AM Vinny Parla (vparla) <vparla=
[email-masked]> wrote:

> *“**The draft does not say the client must use the designated resolver.
> On the contrary, the client must come to its own decision about which
> resolvers it uses, encrypted or otherwise.”*
>
>
> The Network Operator’s intent **is** for the client / device to use the
> designated resolver advertised for that network.
>

That's a pretty blanket statement.

For instance, I'm the operator of my home network and of course it
advertises a resolver, but my intent is for Firefox users to use the
Firefox DoH/TRR program.

Aside from that, whatever the operators *intent* may be, the question of
whether the client has to do it is plainly out of scope of the charter of
this WG:

This working group will focus on discovery and selection of DNS resolvers
by DNS clients in a variety of networking environments, including public
networks, private networks, and VPNs, supporting both encrypted and
unencrypted resolvers. It is chartered solely to develop technical
mechanisms. Making any recommendations about specific policies for clients
or servers is out of scope.

-Ekr

>
> -Vinny
>
>
>
> *From:* Add <[email-masked]> *On Behalf Of *Winfield, Alister
> (Senior Solutions Architect)
> *Sent:* Wednesday, January 27, 2021 3:56 AM
> *To:* Chris Box <[email-masked]>; Stephane Bortzmeyer <
> [email-masked]>
> *Cc:* ADD Mailing list <[email-masked]>
> *Subject:* Re: [Add] [EXTERNAL] Re: New I-D: draft-box-add-requirements-02
>
>
>
> Obviously bad,
>
>
>
> I can think of local policy mechanisms that a network / application /
> device might choose to implement that would limit the success of such
> attacks. Plus if your network monitor is aware that the devices ought to be
> using a known DNS service and it doesn’t generate any connections to that
> service the lack of use would on its own be a signal that something is
> potentially wrong.
>
>
>
> A.
>
>
>
> *From: *Add <[email-masked]> on behalf of Chris Box <
> [email-masked]>
> *Date: *Tuesday, 26 January 2021 at 19:00
> *To: *Stephane Bortzmeyer <[email-masked]>
> *Cc: *ADD Mailing list <[email-masked]>
> *Subject: *[EXTERNAL] Re: [Add] New I-D: draft-box-add-requirements-02
>
>
>
> Stephane,
>
>
>
> *--------------------------------------------------------------------*
>
> *This email is from an external source. Please do not open attachments or
> click links from an unknown or suspicious origin. Phishing attempts can be
> reported by using the report message button in Outlook or sending them as
> an attachment to [email-masked] <[email-masked]>. Thank you*
>
> *--------------------------------------------------------------------*
>
>
>
> Information in this email including any attachments may be privileged,
> confidential and is intended exclusively for the addressee. The views
> expressed may not be official policy, but the personal views of the
> originator. If you have received it in error, please notify the sender by
> return e-mail and delete it from your system. You should not reproduce,
> distribute, store, retransmit, use or disclose its contents to anyone.
> Please note we reserve the right to monitor all e-mail communication
> through our internal and external networks. SKY and the SKY marks are
> trademarks of Sky Limited and Sky International AG and are used under
> licence.
>
> Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited
> (Registration No. 2067075), Sky Subscribers Services Limited (Registration
> No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or
> indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the
> companies mentioned in this paragraph are incorporated in England and Wales
> and share the same registered office at Grant Way, Isleworth, Middlesex TW7
> 5QD
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Wed, 27 Jan 2021 14:59:11 +0000

That is fair,

Let me insert the word Enterprise before Network Operator  as that might better express the sentiment. 
In an Enterprise Network, the notion I expressed below would be largely accurate.

-Vinny

From: Eric Rescorla <[email-masked]> 
Sent: Wednesday, January 27, 2021 9:15 AM
To: Vinny Parla (vparla) <[email-masked]>
Cc: Winfield, Alister (Senior Solutions Architect) <[email-masked]>; Chris Box <[email-masked]>; Stephane Bortzmeyer <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: New I-D: draft-box-add-requirements-02

On Wed, Jan 27, 2021 at 5:37 AM Vinny Parla (vparla) <vparla=[email-masked] <mailto:[email-masked]> > wrote:

For instance, I'm the operator of my home network and of course it advertises a resolver, but my intent is for Firefox users to use the Firefox DoH/TRR program.

Aside from that, whatever the operators *intent* may be, the question of whether the client has to do it is plainly out of scope of the charter of this WG:

-Ekr

 

-Vinny

From: Add <[email-masked] <mailto:[email-masked]> > On Behalf Of Winfield, Alister (Senior Solutions Architect)
Sent: Wednesday, January 27, 2021 3:56 AM
To: Chris Box <[email-masked] <mailto:[email-masked]> >; Stephane Bortzmeyer <[email-masked] <mailto:[email-masked]> >
Cc: ADD Mailing list <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Add] [EXTERNAL] Re: New I-D: draft-box-add-requirements-02

Obviously bad,

A.

Stephane,

Chris

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

---

From: Andrew Campling <[email-masked]>
Date: Wed, 27 Jan 2021 15:26:41 +0000

On Mon, Jan 25, 2021 at 17:30, Stephane Bortzmeyer <[email-masked]> wrote:

> In the same way, R5.2 and R5.3 are fine but the risks of an attacker inside the designated resolver are not mentioned. (An ISP using the resolver to conduct surveillance over users, or serving censored answers, for instance.) If these risks are excluded from the threat model, it must be explicit.

If anyone has real evidence of any European ISPs acting in a way that is not compliant with GDPR then they would presumably contact the relevant regulatory for enforcement action. There seems to be a fixation on such problems when some of the most egregious breaches of privacy have been at end-points - a cursory query of " surveillance capitalism" via your preferred search engine should yield plenty pf recent examples.  

Andrew

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Wed, 27 Jan 2021 15:29:47 +0000

Hi Stephane,
There are a large number of use cases where the Enterprise Network Operator is *not* the Device Manager / owner.
Guest Networks,  (you are using Big-Box Store's guest network and they would like to filter your content while on their network).
Edu Networks,
Are just two examples of this.

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Stephane Bortzmeyer
Sent: Wednesday, January 27, 2021 8:47 AM
To: Vinny Parla (vparla) <[email-masked]>
Cc: Winfield, Alister (Senior Solutions Architect) <Alister.Winfield=[email-masked]>; ADD Mailing list <[email-masked]>; Stephane Bortzmeyer <[email-masked]>; Chris Box <[email-masked]>
Subject: Re: [Add] New I-D: draft-box-add-requirements-02

On Wed, Jan 27, 2021 at 01:37:07PM +0000,  Vinny Parla (vparla) <[email-masked]> wrote  a message of 402 lines which said:

> The Network Operator’s intent *is* for the client / device to use the 

If the network operator controls the endpoints (typical case inside an organization), it is easy (well, at least, possible) to do so.

If it does not (case of an Internet Access Provider), then it must not force the clients to use a specific resolver.

Today, the three drafts draft-pauly-add-deer, draft-btw-add-home and draft-box-add-requirements are, in my opinion, quite "neutral". They describe technical ways to send information to the client and does not say what to do with it. This is reasonable but my concern, from the beginning of the ADD effort, has always been that, should they be published as standards track RFCs, they will be regarded as mandatory-to-use "the IETF said you must not use DoH/DoT except towards a resolver retrieved by these mechanisms". This is why threat modelling and security considerations are very important.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Jan 2021 16:37:10 +0100

On Wed, Jan 27, 2021 at 03:26:41PM +0000,
 Andrew Campling <[email-masked]> wrote 

> If anyone has real evidence of any European ISPs acting in a way that is not compliant with GDPR then they would presumably contact the relevant regulatory for enforcement action. There seems to be…

The Internet access provider I currently use censors Sci-Hub on its DNS
resolver. Do you want a copy of dig's output or is my word enough?

---

From: Andrew Campling <[email-masked]>
Date: Wed, 27 Jan 2021 15:57:42 +0000

On Wed, Jan 27, 2021 at 15:37, Stephane Bortzmeyer <[email-masked]> wrote:

> The Internet access provider I currently use censors Sci-Hub on its DNS resolver. Do you want a copy of dig's output or is my word enough?

I'm not sure that the ADD list is the best place to debate whether a resolver operator complying with court orders that enforce the rights of copyright owners is actually censorship or the prevention of theft of intellectual property.  Such a discussion is probably better undertaken within a policy forum.  

Andrew

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 27 Jan 2021 16:57:53 +0100 (CET)

> Il 27/01/2021 16:37 Stephane Bortzmeyer <[email-masked]> ha scritto:
> 

That seems to be the effect of a decision by the High Court of your own country:

https://www.technadu.com/sci-hub-libgen-blocked-france-high-court-order/63409/

Are you suggesting that a resolver operator abiding by French laws and court orders is "an attacker inside the designated resolver"? Independently from what we may think of such a court order, I do not think that this can ever be accepted as an assumption within an IETF document. If you do not like that decision, the correct place to voice your concerns would be either a French court or the French political scene.

Also, I think this is out of scope for the draft that we are discussing, and perhaps even for the ADD charter.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Jan 2021 13:02:17 -0500

Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
    >> The Internet access provider I currently use censors Sci-Hub on its
    >> DNS resolver. Do you want a copy of dig's output or is my word enough?

    > Are you suggesting that a resolver operator abiding by French laws and
    > court orders is "an attacker inside the designated resolver"?

No, but let's flip this the other way.
How can some application, (or home router), know that it is compliant to
current French law, if that's whwat it wants to be?

This resolver which is applying a court-ordered censor should say so.
(This is *no* different from resolvers in Turkey censoring twitter, or
those in North Korea)

I don't know, if in France, if applications ("Firefox") are obligated to
follow that ruling.  That's not my (or our job) to know, but it is important
that we have a way to convey the posture of that resolver.

    > Independently from what we may think of such a court order, I do not
    > think that this can ever be accepted as an assumption within an IETF
    > document. If you do not like that decision, the correct place to voice
    > your concerns would be either a French court or the French political
    > scene.

    > Also, I think this is out of scope for the draft that we are
    > discussing, and perhaps even for the ADD charter.

I believe that it has to be within our scope.
"child-friendly" / "malware-blocking" / "court-order-compliant"
are just policies.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 27 Jan 2021 18:10:22 +0000

> This resolver which is applying a court-ordered censor should say so.

I agree. As highlighted in the requirements deck today (or so I thought?), this can be accomplished via Extended DNS Errors. Are there signals beyond the use of EDE Code 16 - Censored (blocked by order of someone other than the resolver's actual operator) the WG should consider? My opinion for now is "no" because I don't see how a client could act differently given more detail than that. I do not see a need for additional, unactionable info.

Thanks,
Tommy

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, January 27, 2021 10:02 AM
To: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] New I-D: draft-box-add-requirements-02

    > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.technadu.com%2Fsci-hub-libgen-blocked-france-high-court-order%2F63409%2F&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com%7C2885fe75c73f45f41a6608d8c2edea61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473674855162347%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=%2FPa8Fm6B2HwwfiwtI1wTyf5vJRdG%2FSbwQvyJtcxtsmk%3D&amp;reserved=0

No, but let's flip this the other way.
How can some application, (or home router), know that it is compliant to current French law, if that's whwat it wants to be?

This resolver which is applying a court-ordered censor should say so.
(This is *no* different from resolvers in Turkey censoring twitter, or those in North Korea)

I don't know, if in France, if applications ("Firefox") are obligated to follow that ruling.  That's not my (or our job) to know, but it is important that we have a way to convey the posture of that resolver.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com%7C2885fe75c73f45f41a6608d8c2edea61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473674855162347%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ywTnPgx6xeOhYmxh4mde30v8TxqHt3SHypxDA3J8LnQ%3D&amp;reserved=0        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Jan 2021 13:20:26 -0500

> I agree. As highlighted in the requirements deck today (or so I
    > thought?), this can be accomplished via Extended DNS Errors. Are there
    > signals beyond the use of EDE Code 16 - Censored (blocked by order of
    > someone other than the resolver's actual operator) the WG should
    > consider? My opinion for now is "no" because I don't see how a client
    > could act differently given more detail than that. I do not see a need
    > for additional, unactionable info.

1) I think we need to know before selecting the resolver.
   This is particularly true as this resolver gets to see my (failing)
   queries, and might decide to report me.

2) I think it matters to my Canadian client if it's blocked by order of French
Court or Canadian Court, or local school board(*).

Even if the jurisdiction is correct, the data might not be, so it's also
important to know which censor did this, so that an appropriate complaint can
be made.

(*)-because operator of DNS resolver has been provided a policy for specific
subnets for instance.

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 27 Jan 2021 20:06:40 +0000

Comments in-line

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, January 27, 2021 10:20 AM
To: Tommy Jensen <Jensen.Thomas=[email-masked]>
Cc: [email-masked]
Subject: Re: [Add] [EXTERNAL] Re: New I-D: draft-box-add-requirements-02

[Tommy] I think this comes back around to whether you trust the resolver or not. I think within this WG we have to assume that if a client is speaking with a resolver (or its securely bootstrapped designated replacement) they trust it with its client IP address to query content mapping. If that isn't the case, Oblivious DoH would be an excellent candidate for addressing this scenario. Otherwise, I see no path forward here, as a government has no motivation to alert potential clients as to what queries will get them into trouble. In fact, major pushback against Mozilla's TRR program from the UK was centered around the requirement to publish names that are not allowed when their law requires them _not_ to disclose those names.

2) I think it matters to my Canadian client if it's blocked by order of French Court or Canadian Court, or local school board(*).

Even if the jurisdiction is correct, the data might not be, so it's also important to know which censor did this, so that an appropriate complaint can be made.

(*)-because operator of DNS resolver has been provided a policy for specific subnets for instance.

[Tommy] Since the information is intended for human use, or at least non-functionality impacting such as logging for audits/review, I think the EDE EXTRA-TEXT field is the answer. The resolver can provide text there that describes the censorship which would be useful for reporting erroneous censorship. For example, a client can log something like f"The query for \"{domain_name}\" has failed because it was censored. The resolver provided the following explanation: \"{response.error.extra_text}\""

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 28 Jan 2021 15:26:01 +0100 (CET)

> Il 27/01/2021 19:10 Tommy Jensen <jensen.thomas=[email-masked]> ha scritto:
> 
>  

We sort of switched discussion - Stephane's point was that a resolver blocking domains should be considered an attacker in our threat model, and I don't think that's appropriate. How to communicate properly that a domain is being blocked and for which reason is another matter - we standardized the extended EDE codes 15-17 exactly for that. Also, work is ongoing elsewhere on how to convey the URI for a human-readable error page:

https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/

It would then be up to clients whether and how to use that URI.