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

tirumal reddy <kondtir@gmail.com> Mon, 08 June 2020 13:22 UTC

Return-Path: <kondtir@gmail.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85B83A0A9E for <add@ietfa.amsl.com>; Mon, 8 Jun 2020 06:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PODfc1DfZxtk for <add@ietfa.amsl.com>; Mon, 8 Jun 2020 06:22:55 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D643A0A0C for <add@ietf.org>; Mon, 8 Jun 2020 06:22:54 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id 18so16639948iln.9 for <add@ietf.org>; Mon, 08 Jun 2020 06:22:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h/7MN5Vte4tWBPZ8he+vvZSkybauhujFRUBSZjZWBy8=; b=r5OyYhi8GHW8u/YpuDbG0u+ixzhKoSBGsjgGUln0qalP0R2VBu5EH4o4JwRH1LM43U oCArp2MtaqGUX6rZWdCr+MIo+EaSs74jnWTuPUOO1LBjynO2epGY3ZozucHguhekpGvA bTpHmmlPsx6k05cQTEywgkQGW0ZYt20fB+intRoCybLfmZ/Xqt/acxMTySIk4HiuQYN8 4G3CByQY2YbyI6Q/aHgQR5wG2890hO59nKFRNmH9ZEx9KsxmVv4kmu1Hbgcn6dqs/N7c eFAlnH/1kYEujh6x0q9FYRQRm69rcvzusgR6SsuKWr3zN3F/R7PoLP/+p5nTV2GqOLQ/ NRtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h/7MN5Vte4tWBPZ8he+vvZSkybauhujFRUBSZjZWBy8=; b=njX8UZ6mdnx56Eo9FehHHCzs1jHvCoO7d66ooZxC31nlOqR0K1/F+PuxEFmExo46vh dPxjBXQN1z+leWKheOdi/o1M/0G7/W01NGHUTlnteGxhGrwSEpgWy/z5wcXxi2b1sbNm JrE9e2Tga81f43J0oAQ+oIuPqCY3sQMlT8fZNjAY20cIeSc3ac8sxHwsslO/apFkBNH2 UYQ9NZ+O/PcEhEX5AOgSzxiIMnB4CT55HObd+fKExLEqXjg2lBWvrYaqdaYgSAXhHf1i kqpMH9hy/ZF1v+2Ao2p0t3HDXIfphWaEHlXoJPaHXeSpsAk82CiLFLF9a+FPYtKX8CaO dSTA==
X-Gm-Message-State: AOAM530BA/p5aOKAY5P/r8mJY+F8X/p6D7RkB76+HReTpYoDO2LTv4Jn N+/ZNoK46vxBIoM+CXIje6okoTog4wjaaQdt2VwWvTBQ0to=
X-Google-Smtp-Source: ABdhPJzZCVUDxdxkzfUZYP+HW2CHPpMuR3nLSJZrFd3j94pG1h/7HVR6FithZ5OQ3a3orUbK3aaIewa+WhAlCGg/pcU=
X-Received: by 2002:a92:6411:: with SMTP id y17mr22242410ilb.161.1591622572723; Mon, 08 Jun 2020 06:22:52 -0700 (PDT)
MIME-Version: 1.0
References: <159064546659.30784.12927519685709906985@ietfa.amsl.com> <CAFpG3gfwsyxf7UAd61LLfsF-4Rd+sDEqjc3o86iy_UOveQbY-g@mail.gmail.com> <86151027.6608.1590676320799@appsuite-gw2.open-xchange.com> <CAFpG3gcX0rqVMWaJ6F-gayGhu7kia0RFrHfXJvrp3st9XDS4Nw@mail.gmail.com> <199199696.10466.1591029935148@appsuite-gw1.open-xchange.com> <CAFpG3geQ+6MeKDg15yrh-rVGgqY2W=+QeTsOiumQqioYzTjLAQ@mail.gmail.com> <703165933.16255.1591206344926@appsuite-gw1.open-xchange.com>
In-Reply-To: <703165933.16255.1591206344926@appsuite-gw1.open-xchange.com>
From: tirumal reddy <kondtir@gmail.com>
Date: Mon, 8 Jun 2020 18:52:41 +0530
Message-ID: <CAFpG3gegVqUdbnifLvktJj4AMO3=2Sxr31apE0A1k5E_paRsPQ@mail.gmail.com>
To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
Cc: ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000010527d05a7928295"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/aKYgY_airtt2YE06VK9oUNncrTQ>
Subject: Re: [Add] [EXT] Re: Fwd: New Version Notification for draft-reddy-add-server-policy-selection-02.txt
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2020 13:22:57 -0000

On Wed, 3 Jun 2020 at 23:15, Vittorio Bertola <
vittorio.bertola@open-xchange.com> wrote:

>
> Il 02/06/2020 14:15 tirumal reddy <kondtir@gmail.com> 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.
>

Got it, Thanks.


> 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.
>

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


> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bertola@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
>