Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-add-server-policy-selection-02.txt

From: tirumal reddy <[email-masked]>
Date: Mon, 1 Jun 2020 15:52:36 +0530

Please see inline

On Thu, 28 May 2020 at 20:02, Vittorio Bertola <
[email-masked]> wrote:

>
> Il 28/05/2020 12:19 tirumal reddy <[email-masked]> ha scritto:
>
>
> Hi all,
>
> We prepared an updated version of
> https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-02 to
> address comments from Neil. It discusses how a DNS client can authenticate
> it is connecting to a DoH/DoT server hosted by a specific organization
> (e.g., ISP). We now rely on I-D.pp-add-resinfo to retrieve the Policy
> Assertion Token (PAT).
>
> Comments are welcome.
>
> Thanks for this work. I think we need feedback by client developers that
> would consume this information. You might need something more detailed or
> specific to express the server's policies; for example, machine-readable
> indication of authentication support, logging policies, or fine-grained
> description of filtering policies could be used by clients that want to
> standardize their analysis and presentation of server features. It's good
> to have an extension mechanism, but there would still be the need for
> agreement on what the new claims mean.
>

The attributes defined in the draft do not convey any “privacy claims” like
logging policies. We don’t want to compete/replace the privacy statements
written by an attorney and create any ambiguity or under-represent the
legal statements. The attributes identify the capabilities of the DoH
server (e.g., malware filtering) and the attribute privacyurl provides a
URL that points to the human readable privacy policy statement.

The main purpose of this draft is to discuss how a DNS client can
cryptographically identify it is connecting to a DoT/DoH server hosted by a
specific organization (e.g., ISP).  It is particularly useful when the
DoH/DoT server is insecurely discovered and prevents the client from
connecting to a attackers server.

Can you please provide more details on what you mean by machine-readable
authentication support and what kind of fine-grained description of
filtering policies should be conveyed to the client ?

Cheers,
-Tiru

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

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 1 Jun 2020 18:45:34 +0200 (CEST)

>     Il 01/06/2020 12:22 tirumal reddy <[email-masked]> ha scritto:
> 
> 
>     Can you please provide more details on what you mean by machine-readable authentication support and what kind of fine-grained description of filtering policies should be conveyed to the client ?
> 
This is really a question for client developers. However, perhaps a server with conditional access (example: an ISP server which is made available to the ISP's customers also when roaming onto other networks) would like to express that it requires user authentication (with certain methods, in a certain domain) before usage, so that the client knows that it has to be performed, or can avoid this resolver if it is just looking for open ones.

In terms of filtering policies, "malware filtering" is quite general: does it include botnets? Phishing? Even more for "policy blocking": there are at least two big categories (blocked by operator policy vs blocked by law); for the former category, there are several different possible policies (parental control, productivity control, audiovisual blocking etc) which could by the way be applied differently to different users; for the latter, you would at least need to know which law (which jurisdiction) is being applied. IMHO just knowing that the resolver does "some filtering" is not very useful; on one hand, all resolvers in most jurisdictions will be required by law/courts to filter at least something, and on the other, should you actually care about this kind of information to determine whether you want to use or not a resolver that you just discovered, you would need to tell what is being filtered at a more detailed level.

But again, it does not make sense to delve further into detailing this information if it is not going to be consumed by the clients.

-- 

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

---

From: tirumal reddy <[email-masked]>
Date: Tue, 2 Jun 2020 17:45:33 +0530

Please see inline

On Mon, 1 Jun 2020 at 22:15, Vittorio Bertola <
[email-masked]> wrote:

> This is really a question for client developers. However, perhaps a server
> with conditional access (example: an ISP server which is made available to
> the ISP's customers also when roaming onto other networks) would like to
> express that it requires user authentication (with certain methods, in a
> certain domain) before usage, so that the client knows that it has to be
> performed, or can avoid this resolver if it is just looking for open ones.
>

Good point, client authentication looks like a relevant use case for
Enterprise provided DoH/DoT server to authenticate roaming users. For
example, Firefox DoH setting accepts user credentials (network.trr.credentials)
to authenticate the user to use the DoH server but I don't see any support
client certificate based authentication yet. Anyways, I guess we can assume
other DoH/DoT client implementations will also support client
authentication in near future.

I don't get the ISP use case, what credentials will be used by the ISP's
customers and how will the browser/OS be provisioned to use the credentials
?

>
> In terms of filtering policies, "malware filtering" is quite general: does
> it include botnets?  Phishing?
>

Yes, malicious botnet command and control servers will be also be blocked.
Malicious bots are typically considered a subset of malware. We will update
to include capability of the resolver to block phishing sites.

> Even more for "policy blocking": there are at least two big categories
> (blocked by operator policy vs blocked by law); for the former category,
> there are several different possible policies (parental control,
> productivity control, audiovisual blocking etc) which could by the way be
> applied differently to different users; for the latter, you would at least
> need to know which law (which jurisdiction) is being applied. IMHO just
> knowing that the resolver does "some filtering" is not very useful; on one
> hand, all resolvers in most jurisdictions will be required by law/courts to
> filter at least something, and on the other, should you actually care about
> this kind of information to determine whether you want to use or not a
> resolver that you just discovered, you would need to tell what is being
> filtered at a more detailed level.
>

I would say this type of blocking access to domains falls under the
category of "censorship" contrary to filtering malware/phishing domains.

>
>
> But again, it does not make sense to delve further into detailing this
> information if it is not going to be consumed by the clients.
>

Agreed.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 3 Jun 2020 19:45:44 +0200 (CEST)

>     Il 02/06/2020 14:15 tirumal reddy <[email-masked]> ha scritto:
> 
>     Good point, client authentication looks like a relevant use case for Enterprise provided DoH/DoT server to authenticate roaming users. For example, Firefox DoH setting accepts user credentials (network.trr. credentials) to authenticate the user to use the DoH server but I don't see any support client certificate based authentication yet. Anyways, I guess we can assume other DoH/DoT client implementations will also support client authentication in near future. 
> 
>     I don't get the ISP use case, what credentials will be used by the ISP's customers and how will the browser/OS be provisioned to use the credentials ?
> 
The same way as in the enterprise use case. Think of those ISPs that require you to authenticate before using their SMTP server from outside their network.

> 
>         > >         Even more for "policy blocking": there are at least two big categories (blocked by operator policy vs blocked by law); for the former category, there are several different possible policies (parental control, productivity control, audiovisual blocking etc) which could by the way be applied differently to different users; for the latter, you would at least need to know which law (which jurisdiction) is being applied. IMHO just knowing that the resolver does "some filtering" is not very useful; on one hand, all resolvers in most jurisdictions will be required by law/courts to filter at least something, and on the other, should you actually care about this kind of information to determine whether you want to use or not a resolver that you just discovered, you would need to tell what is being filtered at a more detailed level.
> > 
> >     > 
>     I would say this type of blocking access to domains falls under the category of "censorship" contrary to filtering malware/phishing domains.
> 
Well, to some people "policy blocking" seems to be an euphemism for censorship, no matter what gets blocked and why. In HRPC, actually, a draft currently under discussion defines even malware blocking as "censorship". However, the use of more or less loaded terminology is out of scope - the point is rather whether it would be useful for the client to know the policies more in detail or whether a generic "I filter stuff" signal is useful. But again, this depends on the clients.

--

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 3 Jun 2020 19:52:53 +0200 (CEST)

>     Il 03/06/2020 19:45 Vittorio Bertola <vittorio.bertola=[email-masked]> ha scritto:
> 
> 
> 
> 
>         > >         Il 02/06/2020 14:15 tirumal reddy <[email-masked]> ha scritto
> > 
> > 
> >     > 
>         > > 
> >     >     Well, to some people "policy blocking" seems to be an euphemism for censorship, no matter what gets blocked and why. In HRPC
> 
[correction: for some reason, it's actually PEARG]

--

---

From: tirumal reddy <[email-masked]>
Date: Mon, 8 Jun 2020 18:52:41 +0530

On Wed, 3 Jun 2020 at 23:15, Vittorio Bertola <
[email-masked]> wrote:

> example, Firefox DoH setting accepts user credentials (network.trr. credentials)
> The same way as in the enterprise use case. Think of those ISPs that
> require you to authenticate before using their SMTP server from outside
> their network.
>

Got it, Thanks.

> Well, to some people "policy blocking" seems to be an euphemism for
> censorship, no matter what gets blocked and why. In HRPC, actually, a draft
> currently under discussion defines even malware blocking as "censorship".
> However, the use of more or less loaded terminology is out of scope - the
> point is rather whether it would be useful for the client to know the
> policies more in detail or whether a generic "I filter stuff" signal is
> useful. But again, this depends on the clients.
>

I will go with the definitions of "censorship" and "blocking" defined in
Sections 4.16 and 4.17 in
https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16.

Cheers,
-Tiru