Subject: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt

From: tirumal reddy <[email-masked]>
Date: Wed, 8 Jul 2020 13:07:41 +0530

Hi all,

This draft https://tools.ietf.org/html/draft-reddy-dnsop-error-page-00
discusses a method to return an URL that explains the reason the DNS query
was filtered. It is useful for HTTPS enabled domain names blocked by DNS
firewalls for non-managed devices in Enterprise and Home networks. The
error page URL is returned along with the "Forged Answer" extended error
code defined in ietf-dnsop-extended-error.

Comments and suggestions are welcome.

Cheers,
-Tiru

---------- Forwarded message ---------
From: <[email-masked]>
Date: Wed, 8 Jul 2020 at 12:55
Subject: New Version Notification for draft-reddy-dnsop-error-page-00.txt
To: Dan Wing <[email-masked]>, Neil Cook <[email-masked]>,
Tirumaleswar Reddy.K <[email-masked]>, Mohamed Boucadair <
[email-masked]>

A new version of I-D, draft-reddy-dnsop-error-page-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:           draft-reddy-dnsop-error-page
Revision:       00
Title:          DNS Access Denied Error page
Document date:  2020-07-08
Group:          Individual Submission
Pages:          10
URL:
https://www.ietf.org/internet-drafts/draft-reddy-dnsop-error-page-00.txt
Status:
https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/
Htmlized:       https://tools.ietf.org/html/draft-reddy-dnsop-error-page-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-dnsop-error-page

Abstract:
   When a DNS server filters a query the response conveys no detailed
   explanation of why the query was blocked, leading to end-user
   confusion.  This document defines a method to return an URL that
   explains the reason the DNS query was filtered.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 8 Jul 2020 14:58:36 +0200 (CEST)

>     Il 08/07/2020 09:37 tirumal reddy <[email-masked]> ha scritto:
> 
> 
>     Hi all,
> 
>     This draft https://tools.ietf.org/html/draft-reddy-dnsop-error-page-00 discusses a method to return an URL that explains the reason the DNS query was filtered. It is useful for HTTPS enabled domain names blocked by DNS firewalls for non-managed devices in Enterprise and Home networks. The error page URL is returned along with the "Forged Answer" extended error code defined in ietf-dnsop-extended-error.
> 
This would be actually useful in real world use cases, together with the new EDE codes, so it would benefit from standardization.

Regarding section 4, in DPRIVE (on draft bcp-op) we have recently been told that the IETF does not recommend in its best practices anything which is not strictly technical (in that case, it was about communicating to users the jurisdiction under which DNS resolution is provided):

https://mailarchive.ietf.org/arch/msg/dns-privacy/rJ7R3OBUyySfEyJgwhoxs1DNGuc/

So I would assume that that section is out of scope as well, and I would remove it.

--

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

---

From: Bob Harold <[email-masked]>
Date: Wed, 8 Jul 2020 09:20:54 -0400

On Wed, Jul 8, 2020 at 3:38 AM tirumal reddy <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-reddy-dnsop-error-page-00
> Htmlized:
Minor nit:

7.1.  Error Page URL DNS Parameter

   This parameter indicates the URL that provides additional information
   about the cause of blocking access to a domain is designated for use
   with the "Forged answer" extended error code.  This is a string
   encoded as UTF-8 characters.  This is a string encoded as UTF-8 characters.

 -- The last sentence is duplicated (This is a string encoded as UTF-8
characters.)

-- 
Bob Harold

---

From: tirumal reddy <[email-masked]>
Date: Thu, 9 Jul 2020 12:23:14 +0530

On Wed, 8 Jul 2020 at 18:28, Vittorio Bertola <
[email-masked]> wrote:

> This would be actually useful in real world use cases, together with the
> new EDE codes, so it would benefit from standardization.
>

Yes.

>
>
> Regarding section 4, in DPRIVE (on draft bcp-op) we have recently been
> told that the IETF does not recommend in its best practices anything which
> is not strictly technical (in that case, it was about communicating to
> users the jurisdiction under which DNS resolution is provided):
>
>

My understanding is the "jurisdiction" is out of scope but not RPS (see
https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-12#section-6)

-Tiru

> [email-masked]

---

From: tirumal reddy <[email-masked]>
Date: Thu, 9 Jul 2020 12:26:23 +0530

>  -- The last sentence is duplicated (This is a string encoded as UTF-8

Thanks, fixed in my local copy.

-Tiru

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 9 Jul 2020 09:22:29 +0200 (CEST)

>     Il 09/07/2020 08:53 tirumal reddy <[email-masked]> ha scritto:
> 
> 
>     My understanding is the "jurisdiction" is out of scope but not RPS (see https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-12#section-6) 
> 
Sure, those three points were agreed with Alissa as the scope of any statement that might be described in the best practice:

o  Relates _only_ to matters around to the technical operation of DNS
privacy services, and not on any other matters.

o  Does not attempt to offer an exhaustive list for the contents of
an RPS.

o  Is not intended to form the basis of any legal/compliance
documentation.

So I would take that as guidance here as well: I don't think we can say whether it should contain regulatory information, redress measures etc. (though that would indeed be advisable). Also, in Italy the ISP, when blocking websites by court order, is required to show a page which is exactly defined by law and by the public authority that "seized" the website (e.g. https://www.startmag.it/wp-content/uploads/butac.png ) - it is not allowed to change it in any way. I would expect that to happen in other countries as well.

--

---

From: tirumal reddy <[email-masked]>
Date: Thu, 9 Jul 2020 13:16:31 +0530

On Thu, 9 Jul 2020 at 12:52, Vittorio Bertola <
[email-masked]> wrote:

> Sure, those three points were agreed with Alissa as the scope of any
> statement that might be described in the best practice:
>
> So I would take that as guidance here as well: I don't think we can say
> whether it should contain regulatory information, redress measures etc.
> (though that would indeed be advisable).
>

Yes, I agree; will update the section to say:

   The content of the error page is non-normative, the above text only
   provides the guidelines and template for the error page and.

      an error page.

   o  It is not intended to form the basis of any legal/compliance for
      developing the error page.

Cheers,
-Tiru

Also, in Italy the ISP, when blocking websites by court order, is required
> to show a page which is exactly defined by law and by the public authority
> that "seized" the website (e.g.
> https://www.startmag.it/wp-content/uploads/butac.png ) - it is not
> allowed to change it in any way. I would expect that to happen in other
> countries as well.
>
> --
>

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 24 Jul 2020 07:19:32 -0700

tirumal reddy <[email-masked]> writes:

> discusses a method to return an URL that explains the reason the DNS
> query was filtered.

Interesting idea.  A couple of points:

1) The document doesn't state where the HTTPS record should go.  I
assume in the additional section (it's not an answer).

2) It doesn't talk about what the name should be for the record.  I
assume it must match the name that was requested (IE, the question
section name).

3) WRT DNSSEC and this statement:

       but DNSSEC signing and validation
       is not possible for the HTTPS record returning the error page URL
       along with the "Forged Answer" extended error.

   You should probably also insert a MUST / MUST NOT about these errors
   and how they must only come from the resolver the client is talking
   to and must not be forwarded from something upstream (double hops
   provide no trust in DOH (or any other secured transport) without
   DNSSEC or some other signing mechanism)

-- 
Wes Hardaker
USC/ISI

---

From: tirumal reddy <[email-masked]>
Date: Mon, 27 Jul 2020 10:47:15 +0530

Hi Wes,

Please see inline

On Fri, 24 Jul 2020 at 19:49, Wes Hardaker <[email-masked]> wrote:

> Interesting idea.

Thanks.

> A couple of points:

Yes, will update text.

> assume it must match the name that was requested (IE, the question

Yup, the name of the record must match the original QNAME in the DNS
request; will add clarifying text.

>    DNSSEC or some other signing mechanism)

Good point, added following text to security considerations section:

The DNS resolver MUST NOT forward the "Forged Answer" extended error and
the HTTPS record from an upstream resolver as an attacker (e.g., MiTM)
could insert a fake extended error response and HTTPS record into the DNS
response.

Cheers,
-Tiru