Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01

Neil Cook <neil.cook@noware.co.uk> Tue, 16 November 2021 10:40 UTC

Return-Path: <neil.cook@noware.co.uk>
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 0D66A3A07D9 for <dnsop@ietfa.amsl.com>; Tue, 16 Nov 2021 02:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=noware.co.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0b4TvEhzwdZ for <dnsop@ietfa.amsl.com>; Tue, 16 Nov 2021 02:40:21 -0800 (PST)
Received: from mail.noware.co.uk (mail.noware.co.uk [IPv6:2604:a880:400:d0::1a21:4001]) by ietfa.amsl.com (Postfix) with ESMTP id DC15B3A07DC for <dnsop@ietf.org>; Tue, 16 Nov 2021 02:40:20 -0800 (PST)
Received: from smtpclient.apple (unknown [IPv6:2a00:23c7:1a00:d101:c042:6bd:bb2e:d387]) by mail.noware.co.uk (Postfix) with ESMTPSA id ED86980ABE; Tue, 16 Nov 2021 10:40:17 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.noware.co.uk ED86980ABE
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=noware.co.uk; s=default; t=1637059219; bh=EB9pKc0fNftgRR16mz+tEzI0cAakYtyT2rxmY8FJnec=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=jGXfl06I+Ups7CnRIJPndQivu1EnXdEOw+1vwMrTVD14QQvOPfY5aZ1soO69j32F4 UEdk0dIgWjd9Jnu1YXYTj3Yg4vXWsstfIOxGrmONeX+XtaZz/3y5Q401ufqzbbFJoU HnCSToGopZkTEN/xZ3TSZ9Ocf1jIfZsAIp/gAk90=
From: Neil Cook <neil.cook@noware.co.uk>
Message-Id: <DD66CACC-2BDF-4461-A146-8E6AEDBFE105@noware.co.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_77330197-9798-4772-9BAB-A157D9FB78B4"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Tue, 16 Nov 2021 10:40:16 +0000
In-Reply-To: <CAMOjQcFS_VRHFT-sOKHGUcKHQMbVFa9auS6C23pN3ybK=F_AzA@mail.gmail.com>
Cc: Petr Špaček <pspacek@isc.org>, Ben Schwartz <bemasc@google.com>, dnsop@ietf.org, Dan Wing <danwing@gmail.com>, Eric Rescorla <ekr@rtfm.com>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Eric Orth <ericorth=40google.com@dmarc.ietf.org>
References: <D1CF0779-EAB3-4759-8F50-643E9EC8C490@gmail.com> <d7f55c0d-0746-9c74-2ff1-ebdcec7ad45e@isc.org> <5193d399-859a-ef45-2dff-e1c112adc0e4@isc.org> <CAMOjQcFS_VRHFT-sOKHGUcKHQMbVFa9auS6C23pN3ybK=F_AzA@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-VADE-SPAMSTATE: clean
X-VADE-SPAMSCORE: -100
X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvuddrfedvgddukecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfpgffknfevqffqmfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpefpvghilhcuvehoohhkuceonhgvihhlrdgtohhokhesnhhofigrrhgvrdgtohdruhhkqeenucggtffrrghtthgvrhhnpedvtefhhfetudeivdfftdetffdutdetffduhefffefhgeehfeejffeludelveevgfenucffohhmrghinhepvgigrghmphhlvgdrtghomhdpghhmrghilhdrtghomhdpihgvthhfrdhorhhgnecukfhppedvrgdttdemvdeftgejmedurgdttdemugdutddumegttdegvdemiegsugemsggsvdgvmegufeekjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvrgdttdemvdeftgejmedurgdttdemugdutddumegttdegvdemiegsugemsggsvdgvmegufeekjedphhgvlhhopehsmhhtphgtlhhivghnthdrrghpphhlvgdpmhgrihhlfhhrohhmpefpvghilhcuvehoohhkuceonhgvihhlrdgtohhokhesnhhofigrrhgvrdgtohdruhhkqedprhgtphhtthhopegvrhhitghorhhthhepgedtghhoohhglhgvrdgtohhmsegumhgrrhgtrdhivghtfhdrohhrghdprhgtphhtthhopehpshhprggtvghksehishgtrdhorhhgpdhrtghpthhtohepsggvmhgr shgtsehgohhoghhlvgdrtghomhdprhgtphhtthhopegunhhsohhpsehivghtfhdrohhrghdprhgtphhtthhopegurghnfihinhhgsehgmhgrihhlrdgtohhmpdhrtghpthhtohepvghkrhesrhhtfhhmrdgtohhmpdhrtghpthhtohepughkghesfhhifhhthhhhohhrshgvmhgrnhdrnhgvth
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xJkVtn4OgF2uDNZl_FqfXzp4UDM>
Subject: Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 16 Nov 2021 10:40:26 -0000

Hi Eric,

> So this leads back to, if we don't pull the DNS-provided error message into the UI, what does this new draft give us that EDE doesn't or how should this work alongside EDE? And does this provide enough value and solve enough of the problem for resolvers to implement if the clients can't currently commit to displaying custom error messages in UIs?


I think it’s worth noting that there are multiple parts to the structured text, not just the error message:

1) Justification  - Agreed if you don’t pull this message into the UI it doesn’t provide any additional information beyond EDE, which will have already told you that that DNS query was filtered/censored. However what I’m not getting from your message below is whether you’re planning to implement anything beyond logging when receiving Extended DNS Errors. For example, even without this draft, if you received a filtered EDE response, would you only log it, or would you potentially display something to the user in the UI?

2) Complaint - Currently this is a URI based on the domain name of the encrypted DNS server, but there has been good feedback about making this more flexible. Being able to give users a way to report misclassification would be very valuable, again assuming that this could be implemented in a safe way by UI vendors.

3) Contextual Information - There is some additional information about the organization that filtered the query, but you might well regard that with the same degree of suspicion as the justification text.

Neil

> On 15 Nov 2021, at 19:58, Eric Orth <ericorth=40google.com@dmarc.ietf.org> wrote:
> 
> I already gave my thoughts live during the WG session last week, but happy to summarize and expand on it here.
> 
> When it comes to displaying resolver-provided text in a Chrome UI, this is all very scary.  We have to be extremely careful about anything displaying content to users that does not come securely from Chrome itself or the website the user is trying to access to avoid problems like phishing attacks.  Even when things are limited only to text, you still have to worry about text like "To access your gmail login page, go to attacker.example.com <http://attacker.example.com/>!" after a user tries to visit gmail.com <http://gmail.com/>.
> 
> I'm not going to say the whole concept is completely unworkable, just that, even with the various mitigations that have been added in the draft, we can't do anything approaching this functionality without some serious work with Google security and UX experts to make sure we are extremely clear to users that that error message is not trustworthy.  But I'm not sure when priority-wise we would be able to make such conversations happen, so I don't really have any specific feedback for the WG on how to make the draft more compatible with our needs.
> 
> But from the perspective of adding any of this information to debug logging, that's all much less controversial.  We already have not-yet-implemented plans to pull in Extended DNS Errors to our logs, and this just seems like an extension of that.  Similarly, we recognize that our error messages after DNS failures are not always the most helpful, and we are planning on accounting for Extended DNS Errors in informing the relevant logic when picking (Chrome-provided) error messages.
> 
> So this leads back to, if we don't pull the DNS-provided error message into the UI, what does this new draft give us that EDE doesn't or how should this work alongside EDE? And does this provide enough value and solve enough of the problem for resolvers to implement if the clients can't currently commit to displaying custom error messages in UIs?
> 
> On Fri, Nov 12, 2021 at 12:00 PM Petr Špaček <pspacek@isc.org <mailto:pspacek@isc.org>> wrote:
> Hello everyone,
> 
> let me try to to restart the discussion about "Structured Data for 
> Filtered DNS" draft. See below.
> 
> On 14. 10. 21 19:36, Dan Wing wrote:
>  > We recently published -01 of Structured Data for Filtered DNS based 
> on WG feedback from IETF 111.  We also incorporated both motivational 
> and normative text from draft-reddy-dnsop-error-page.  New version at: 
> https://datatracker.ietf.org/doc/html/draft-wing-dnsop-structured-dns-error-page-01 <https://datatracker.ietf.org/doc/html/draft-wing-dnsop-structured-dns-error-page-01>
> 
> On 10. 11. 21 17:17, Petr Špaček wrote:
> > Let's start from the hardest questions:
> > 
> > 1. Input from browser vendors
> > -----------------------------
> > I believe we really really _really_ need input from end-client vendors, 
> > most importantly Google Chrome and Safari. Is there any indication that 
> > they might be interested? If not, why?
> > 
> > In my experience browser people have much better idea about UX design 
> > and HTTP ecosystem security than we DNS people do, and they might have 
> > different requirements on the data we plan to send back to clients, or 
> > reasons why the idea cannot be implemented in browsers as is.
> 
> I'm CCing known Google and Mozilla people on this e-mail. Please kindly 
> ask Safari people if you know any to contribute here as well.
> 
> 
> So, to really start again, I think we need to make step back and ask 
> what browsers are willing to work with.
> 
> Currently the user experience with any sort of blocking follows.
> 
> This is what user sees if:
> - blocking is done via forged NXDOMAIN
> - the the site has a DNS outage
> - there is a typo in the domain name
> 
> Chromium:
> > This site can’t be blockedsite.example’s server IP address could not be found.
> > Try:
> > Checking the connection
> > Checking the proxy, firewall, and DNS configuration
> > ERR_NAME_NOT_RESOLVED
> 
> Firefox:
> > Hmm. We’re having trouble finding that site.
> > 
> > We can’t connect to the server at blockedsite.example.
> > 
> > If that address is correct, here are three other things you can try:
> > 
> >     Try again later.
> >     Check your network connection.
> >     If you are connected but behind a firewall, check that Firefox has permission to access the Web.
> 
> Safari:
> > Safari Can't Find the Server
> > Safari can't open the page "blockedsite.example" because Safari can't find the server "blockedsite.example".
> 
> 
> This is what happens if blocking is done with forged A RR answer 
> pointing to a web server serving "this is blocked" web page:
> 
> Chromium:
> > Your connection is not private
> > Attackers might be trying to steal your information from blockedsite.example (for example, passwords, messages, or credit cards). Learn more
> > NET::ERR_CERT_COMMON_NAME_INVALID
> 
> Firefox:
> > Warning: Potential Security Risk Ahead
> > 
> > Firefox detected a potential security threat and did not continue to blockedsite.example. If you visit this site, attackers could try to steal information like your passwords, emails, or credit card details.
> > 
> > What can you do about it?
> > 
> > The issue is most likely with the website, and there is nothing you can do to resolve it. You can notify the website’s administrator about the problem.
> 
> Safari:
> > This Connection Is Not Private
> > This website may be impersonating "blockedsite.example" to steal you personal or financial information. You should go back to the previous page.
> 
> 
> Finally, The Question for web browser vendors is:
> Do you have an interest in improving this user experience?
> 
> If the answer is yes, what extra information from the resolver you need?
> 
> Thank you for your time.
> 
> -- 
> Petr Špaček
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop