We have created a PR to address the WG's feedback, please see
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/pull/51/files.
The changes involve removing 'https' and adding 'mailto' as contact URI
schemes. We have also added a new registry for Contact URI schemes,
allowing the addition of new schemes based on IETF review.
-Tiru
On Fri, 20 Oct 2023 at 22:28, Dan Wing <danw...@gmail.com> wrote:
> The authors took a stab at text explaining mitigations which seem to have
> not met the WG's needs.
>
> Removing HTTP would allow the document to move forward. If someone finds
> a suitable way to weaken (or even prevent) malicious use of http in the
> Contact field by the DoH/DoT operator (with an interstitial or something
> else) we can create a bis to allow http in the Contact ("c") field.
>
> -d
>
>
> On Oct 20, 2023, at 7:10 AM, Ben Schwartz <bemasc=
> 40meta....@dmarc.ietf.org> wrote:
>
> This draft originally proposed returning a webpage. After reviews from
> the working group raising concern about allowing the DNS server to inject a
> webpage, it was changed to provide a contact URI instead ... but it then
> lists "https:" as an example of a suitable contact URI scheme. This
> apparent contradiction ("https:" is not a form of contact info) strikes me
> as an awkward compromise, and a fine example of "design by committee".
>
> Ultimately, it seems that this draft as aimed at browsers, and should
> provide information that browser makers believe can safely be displayed to
> users. I think the most sensible solution is (1) replace the "https:"
> example in the draft with "mailto:"; and (2) note that clients are free to
> ignore contact URIs with unsupported schemes.
>
> Even a "mailto:"; scheme is not without risk here, and I wouldn't be
> surprised if some browser vendors feel it is unsafe to display. However,
> it sounds like there is some interest from potential clients, perhaps
> enough to support continuing with this draft.
>
> --Ben
> ------------------------------
> *From:* DNSOP <dnsop-boun...@ietf.org> on behalf of tirumal reddy <
> kond...@gmail.com>
> *Sent:* Friday, October 20, 2023 6:09 AM
> *To:* Tommy Pauly <tpauly=40apple....@dmarc.ietf.org>
> *Cc:* Vodafone Gianpaolo Angelo Scalone <
> Gianpaolo-Angelo.Scalone=40vodafone....@dmarc.ietf.org>; DNSOP WG <
> dnsop@ietf.org>
> *Subject:* Re: [DNSOP] I-D Action:
> draft-ietf-dnsop-structured-dns-error-06.txt
>
> This Message Is From an External Sender
> I would like to clarify that the purpose of the "c" (contact) field is not
> to display an error page but to provide contact details of the IT/InfoSec
> team for reporting misclassified DNS filtering. Its function is to report
> legitimate domain names that have been incorrectly blocked due to
> misclassification.
>
> There is no mention in the draft that the "c" (contact) field is intended
> for displaying an error page. It is assumed that the client application
> would handle the display of an error page, and the content of the "c" field
> would be optionally used in specific scenarios, such as TRR.
>
> To improve clarity, we could update the draft and specify that the error
> page must be displayed by the client application, and the "c" field link
> may be optionally provided to raise complaints. Furthermore, to minimize
> security risks, the client can retrieve the URL from the contact field in
> an isolated environment. It must also take additional precautions, such as
> clearly labeling the page as untrusted. This isolation should prevent the
> transmission of cookies, block JavaScript execution, and prevent the
> auto-fill of credentials or personal information. The isolated environment
> should be separate from the user's normal browsing environment.
>
> Cheers,
> -Tiru
>
>
>
>
>
> On Fri, 20 Oct 2023 at 01:42, Tommy Pauly <tpauly=
> 40apple....@dmarc.ietf.org> wrote:
>
>
>
> On Oct 19, 2023, at 12:44 PM, Warren Kumari <war...@kumari.net> wrote:
>
> I still don't understand why (other than marketing/advertising) this is
> needed — the EDE "4.18. Extended DNS Error Code 17 - Filtered" ("The server
> is unable to respond to the request because the domain is on a blocklist as
> requested by the client. Functionally, this amounts to "you requested that
> we filter domains like this one.") seems to cover it.
>
> If browsers are willing to do anything with the EDE codes (like "ERROR:
> Your DNS filtering provider says you shouldn't go here") what additional
> **important** information needs to be communicated? And if browsers are not
> willing to do anything with just EDE codes, it sure doesn't seem like they
> would want to do that **and** follow an unauthenticated URL…
>
>
> Safari is now displaying the EDE-code based information! So we are willing
> to show that.
>
> The case that might still be interesting is providing the user some
> (hopefully safe) way to contact the blocker to dispute why this is being
> blocked — so a way to send an email to an administrator, but not something
> else. Showing advertising or marketing or any arbitrary page is not
> something I think would fly.
>
> Tommy
>
>
> Anything more simply adds complexity and security risks, and entails
> privacy concerns for the user too…
>
> W
>
>
> On Thu, Oct 19, 2023 at 4:05 AM, Vodafone Gianpaolo Angelo Scalone <
> Gianpaolo-Angelo.Scalone=40vodafone....@dmarc.ietf.org>wrote:
>
> Hi,
> I think that we have now 2 good potential compromises:
>
> 1. A browser interstitial page explaining that the following page is
> generated by the service that blocked the actual page, with a button
> indicating “proceed to the blocking page” and another “dismiss”
> 2. A graphical representation of the blocking page, rendered as image
> with no clickable links, with a button indicating “proceed to the blocking
> page” and another “dismiss”
>
>
> This would be understandable by customers and provide a good user
> experience and security.
> In addition we could start thinking about a reputation mechanism.
>
> Kind regards
>
> Gianpaolo
>
> C2 General
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
