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
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=40apple....@dmarc.ietf.org<mailto:40apple....@dmarc.ietf.org>> wrote:
On Oct 19, 2023, at 12:44 PM, Warren Kumari
<war...@kumari.net<mailto: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<mailto: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<mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop<https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org<mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop<https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org<mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop<https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
