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 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.com@dmarc.ietf.org>
wrote:

>
>
> On Oct 19, 2023, at 12:44 PM, Warren Kumari <warren@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.com@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
>