Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

[Ben Schwartz <[e-mail]>]

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 <[e-mail]> on behalf of tirumal reddy <[e-mail]>
Sent: Friday, October 20, 2023 6:09 AM
To: Tommy Pauly <tpauly=[e-mail]>
Cc: Vodafone Gianpaolo Angelo Scalone <Gianpaolo-Angelo.Scalone=[e-mail]>; DNSOP WG <[e-mail]>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
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=[e-mail]<mailto:[e-mail]>> wrote:


On Oct 19, 2023, at 12:44 PM, Warren Kumari <[e-mail]<mailto:[e-mail]>> 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=[e-mail]<mailto:Gianpaolo-Angelo.Scalone=[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnsop<https://www.ietf.org/mailman/listinfo/dnsop>

_______________________________________________
DNSOP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnsop<https://www.ietf.org/mailman/listinfo/dnsop>

_______________________________________________
DNSOP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnsop<https://www.ietf.org/mailman/listinfo/dnsop>