Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt
tirumal reddy <kondtir@gmail.com> Sun, 29 October 2023 05:50 UTC
Return-Path: <kondtir@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FED9C14F736 for <dnsop@ietfa.amsl.com>; Sat, 28 Oct 2023 22:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTaE0CL0kquY for <dnsop@ietfa.amsl.com>; Sat, 28 Oct 2023 22:50:00 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B17C14E513 for <dnsop@ietf.org>; Sat, 28 Oct 2023 22:50:00 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-507c188c529so1138002e87.0 for <dnsop@ietf.org>; Sat, 28 Oct 2023 22:50:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698558599; x=1699163399; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fh+Z42Kr/L8Nfn0IIJr+xaaUtDrqCtL9/4Ap/TWoe9Q=; b=A4vTIkTSto2adupLj2NN/J2hYbAzFkwtmmuRFlQ/LxgixWqPm4IYkp+Rb5h6voazyt 4NFPnmt6jIWCqr2t9mj2t0xQZIlOB8+BsD+XEuFyaMwTd7HBFNEAuETom6oTJd1A0Kht O36c4i49lbiniX14NIvg+l6c5afAOboXCtlxmQdZpIoVcGBZ0dOIC0qTlv7zcxwFuusG fRKrfYHHQqQATvJfOldeWxDwkq1B/YQWO9swCAnxLNANmcv/ZYuY+1iha0kabUSEEEcb /c99Urgc+3WwWyVZFFU+3q+aQgAxTPNChh5yRQKYRvNnrRUEInMXkWAvjahK/vNXC20A VM6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698558599; x=1699163399; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fh+Z42Kr/L8Nfn0IIJr+xaaUtDrqCtL9/4Ap/TWoe9Q=; b=BJ7Hmvw2Cce8SyjyVBaR+dZvWHfJDC/hSOFmNa8AUckWOzGDJjr27xHsX6S2VrYt3b 9ZBFRQ0JYTCVutyHtO1eth+hn+bkiXiUJpffexlMn9+k9pSHlK50C4k+YwakJcz9a7YB TmhxSlwEdslhsWvNqG8N0OPXB/D6MXYWGfLfkJI00b6hJgZ7jruZxu+tcz5b56VypS7F sqTzPIavptNGThcQaYG4ZIN7UM1ZznUrWv3sO36vHlCpg37AhCe5qOKGpZ7QJzHWNLXW gvJ3wrrvjBTx9zgT759/qtdiVnqLv+oKSAco288UBlzxE9Th37iv8JSDslq8pgYjAfh3 52Kw==
X-Gm-Message-State: AOJu0Yy/JYiJoI8VOoUgg0AH5C5NJk/baJECvG9HEoNfo+utALzyxxSX 3jDTn7XQpdymPhiT6RBjEqgRz/hpCppQEDaT1wo=
X-Google-Smtp-Source: AGHT+IFjIOh3bG5m+RxkP+TsreBN0rl1PClQ0kpcMNb/9aguyNExYJtvkXYba5sluQdTMXvRyCZvQj4JxcJapiMmqco=
X-Received: by 2002:a2e:9a89:0:b0:2be:5485:4a99 with SMTP id p9-20020a2e9a89000000b002be54854a99mr4610008lji.4.1698558598295; Sat, 28 Oct 2023 22:49:58 -0700 (PDT)
MIME-Version: 1.0
References: <DB9PR05MB847313955E9EE5F63F53FDB3A3D4A@DB9PR05MB8473.eurprd05.prod.outlook.com> <CAHw9_iKDDt9W207osTsHpfaacjQioDM1VVbLk9JTRB2hjpEa1g@mail.gmail.com> <DB850E35-E036-46B3-9BB0-B29277B75FA3@apple.com> <CAFpG3gcQhVpuWi9iBOFhxum5XNsA4-vXnQaUh2LgfFkQ3nMz9w@mail.gmail.com> <BN8PR15MB3281EAD3D8D14BAB395F47A1B3DBA@BN8PR15MB3281.namprd15.prod.outlook.com> <55ADB8F6-E786-411D-A709-D2C894A2302B@gmail.com>
In-Reply-To: <55ADB8F6-E786-411D-A709-D2C894A2302B@gmail.com>
From: tirumal reddy <kondtir@gmail.com>
Date: Sun, 29 Oct 2023 11:19:46 +0530
Message-ID: <CAFpG3geLJZn1w0r+7WN8NcFKDV5miHehZMN=Tg9X7OX9RPyhyA@mail.gmail.com>
To: Dan Wing <danwing@gmail.com>
Cc: Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, Vodafone Gianpaolo Angelo Scalone <Gianpaolo-Angelo.Scalone=40vodafone.com@dmarc.ietf.org>, DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e1b87b0608d47d28"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fnMrR9UqwEVbY-KvoYna9AvkLaY>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Oct 2023 05:50:04 -0000
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 <danwing@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.com@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-bounces@ietf.org> on behalf of tirumal reddy < > kondtir@gmail.com> > *Sent:* Friday, October 20, 2023 6:09 AM > *To:* Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> > *Cc:* Vodafone Gianpaolo Angelo Scalone < > Gianpaolo-Angelo.Scalone=40vodafone.com@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.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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > >
- [DNSOP] I-D Action: draft-ietf-dnsop-structured-d… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Gianpaolo Angelo Scalone, Vodafone
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Tommy Pauly
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Warren Kumari
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Gianpaolo Angelo Scalone, Vodafone
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… tirumal reddy
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Tommy Pauly
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Eric Orth
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Ralf Weber
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… tirumal reddy
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Warren Kumari
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Peter Thomassen
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Peter Thomassen
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Ralf Weber
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Gianpaolo Angelo Scalone, Vodafone
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Warren Kumari
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Tommy Pauly
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… tirumal reddy
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Ben Schwartz
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… Dan Wing
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-structur… tirumal reddy