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

[Eric Orth <[e-mail]>]

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!" after a user tries to visit 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 <[e-mail]> 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
>
> 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
>