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

[tirumal reddy <[e-mail]>]

Please see inline

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

>
> Il 01/06/2020 12:22 tirumal reddy <[e-mail]> 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.
>

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.


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