Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt
Hi Wes, Please see inline On Fri, 24 Jul 2020 at 19:49, Wes Hardaker wrote: > tirumal reddy writes: > > > 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. > > Interesting idea. Thanks. > 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). > Yes, will update text. > > 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). > Yup, the name of the record must match the original QNAME in the DNS request; will add clarifying text. > > 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) > 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 > > -- > Wes Hardaker > USC/ISI > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt
tirumal reddy writes: > 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt
On Thu, 9 Jul 2020 at 12:52, Vittorio Bertola < vittorio.bert...@open-xchange.com> wrote: > > Il 09/07/2020 08:53 tirumal reddy ha scritto: > > 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. > > > 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). > 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. o Does not attempt to offer an exhaustive list for the contents of 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. > > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bert...@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt
> Il 09/07/2020 08:53 tirumal reddy ha scritto: > > > > > 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. > > > > > > 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. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt
On Wed, 8 Jul 2020 at 18:51, Bob Harold wrote: > > On Wed, Jul 8, 2020 at 3:38 AM tirumal reddy wrote: > >> 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: >> Date: Wed, 8 Jul 2020 at 12:55 >> Subject: New Version Notification for draft-reddy-dnsop-error-page-00.txt >> To: Dan Wing , Neil Cook , >> Tirumaleswar Reddy.K , Mohamed Boucadair < >> mohamed.boucad...@orange.com> >> >> >> >> 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. >> >> > 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.) > Thanks, fixed in my local copy. -Tiru > > -- > Bob Harold > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt
On Wed, 8 Jul 2020 at 18:28, Vittorio Bertola < vittorio.bert...@open-xchange.com> wrote: > > Il 08/07/2020 09:37 tirumal reddy 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. > > Comments and suggestions are welcome. > > 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): > > > 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. > 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 > > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bert...@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt
On Wed, Jul 8, 2020 at 3:38 AM tirumal reddy wrote: > 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: > Date: Wed, 8 Jul 2020 at 12:55 > Subject: New Version Notification for draft-reddy-dnsop-error-page-00.txt > To: Dan Wing , Neil Cook , > Tirumaleswar Reddy.K , Mohamed Boucadair < > mohamed.boucad...@orange.com> > > > > 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. > > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt
> Il 08/07/2020 09:37 tirumal reddy 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. > > Comments and suggestions are welcome. > 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 vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
