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 <[email protected]>
> 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 <[email protected] <mailto:[email protected]>> on
> behalf of tirumal reddy <[email protected] <mailto:[email protected]>>
> Sent: Friday, October 20, 2023 6:09 AM
> To: Tommy Pauly <[email protected]
> <mailto:[email protected]>>
> Cc: Vodafone Gianpaolo Angelo Scalone
> <[email protected]
> <mailto:[email protected]>>; DNSOP WG
> <[email protected] <mailto:[email protected]>>
> 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 <[email protected]
> <mailto:[email protected]>> wrote:
>
>
>> On Oct 19, 2023, at 12:44 PM, Warren Kumari <[email protected]
>> <mailto:[email protected]>> 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
>> <[email protected]
>> <mailto:[email protected]>>wrote:
>> Hi,
>> I think that we have now 2 good potential compromises:
>> 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”
>> 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
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
