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

From: Petr Špaček <[email-masked]>
Date: Wed, 10 Nov 2021 17:17:15 +0100

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
> 
> Summary of changes:
>     *  removed support for multiple responsible parties
>     *  one-character JSON names to minimize JSON length
>     *  partial URI sent in "c" and "r" names, combined with "d" name sent
>        in JSON to minimize attack surface and minimize JSON length
>     *  moved EDNS(0) forgery-mitigation text, some Security
>        Considerations text, and some other text from
>        [I-D.reddy-dnsop-error-page] to this document
> 
> Side-by-side differences from -00 to -01 at https://www.ietf.org/rfcdiff?url2=draft-wing-dnsop-structured-dns-error-page-01.txt

First of all, I agree that a mechanism is needed to solve usability 
problem described in Introduction. This might be a way to go.

Secondly, sorry for a lengthy e-mail. I was looking through archives to 
find out if some of these issues were discussed already but I found 
almost nothing, so it is possible I repeat old ideas here...

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.

2. Caching
----------
The draft needs some discussion about interaction with caches. Forged 
answers and also forged NXDOMAINs are subject to "downstream" DNS 
caching and we need to decide what to do with that.
- Ignore? Then it might not be very useful because most answers will not 
get the error data.
- Cache? Then resolvers need a completely new infrastructure for cache 
because this is not regular RR, and EDNS options do not fit existing 
caching patterns.

Is it even okay to resend the same structured error data to multiple 
clients? Keep in mind resolvers _also_ deduplicate queries going to 
authoritatives, so multiple client queries might receive the same 
response, even if it is not cached at the end.

What's impact of cache if the links inside contain timestamps or things 
like that?

Does the error structure need it's own TTL? (I hope not.)

I don't have answers but it needs to be considered.

3. Forwarding
-------------
Current text:
>    *  DNS forwarders (or DNS proxies) are supposed to propagate unknown
>       EDNS(0) options (Sections 4.1 and 4.4.1 of [RFC5625]), which means
>       the Structured Error EDNS(0) option may get propagated by such a
>       DNS server.  To detect this scenario, the DNS client MUST verify
>       the domain name in the Structured Error "d" value matches the
>       domain name of the encrypted DNS resolver.  If this match fails,
>       the DNS client MUST ignore the Structured Error EDNS(0) option in
>       the response.

AFAIK this is true only for "dumb" proxies. Caches/proxies which 
implement full DNS protocol (e.g. BIND in forwarding mode) follow RFC 6891:

>    EDNS is a hop-by-hop extension to DNS.  This means the use of EDNS is
>    negotiated between each pair of hosts in a DNS resolution process,
>    for instance, the stub resolver communicating with the recursive
>    resolver or the recursive resolver communicating with an
>    authoritative server.

and thus do not forward EDNS options.

In my experience this forwarding is very common in enterprise settings 
and it raises another usability concern: If the option is _not_ 
forwarded, then lots of users might not be getting the information 
because it will be dropped by an intermediate forwarder.

Feedback for actual text in the draft
-------------------------------------
> 4.  Structured JSON

First, please add a normative reference for the JSON format, especially 
because we need to be clear about character encoding and stuff like that.

>    c: (complaint)  a partial URI for the user to further diagnose and
>       possibly report mis-classified DNS filtering.  The value is
>       converted to an expanded absolute URI.  This field is optional,
>       but note its absence still allows a URI to be formed.

I think that mandating https:// template is overly prescriptive. 
"complaint" could be an URI like
"mailto:[email-masked]?subject=blocked domain blah. @ 
2021-10-21" and still be very useful.

>    d: (domain)  Contains the domain-name of the encrypted DNS server.
>       This is used to create the expanded URIs for both the "c" and "r"
>       fields, and also detect undesired forwarding of EDNS(0) options.
>       This field is mandatory.

I think it is grave mistake to conflate name of DNS responder and domain 
"base" domain for HTTPs error pages. Especially for DoT there is 
typically no HTTPS running on the host, and IMHO it is pretty bad idea 
to require that on the protocol level.

Security considerations section hints there might be reasons for this I 
did not find in the archives, but then please spell them out explicitly.

>    j: (justification)  the textual justification for this particular DNS
>       filtering.  This field is mandatory.

I don't think that text field "justification" needs to be mandatory. 
Even if the field is technically mandatory it can be just an empty 
string, so ...
In any case we should get feedback on this field browsers. Is it even 
useful without translations? etc.

Ad proposed DNS protocol itself:
> 3. Structured Error EDNS(0) Option Code
> 5. Protocol Operatio

Protocol-wise, I think it would be better to do this:

1. Client can optionally send a new option to request structured errors 
- this option should always be empty. (= No change.)
2. If the new option was present in query, then DNS responder sends back 
Extended DNS Errors option (EDE, RFC 8914) with INFO-TEXT field 
formatted according to structured JSON specified in this draft.

This IMHO has several advantages:
a) It completely eliminates protocol corner cases like structured error 
option being present without an allowed EDE option being present 
(currently forbidden by section 5.3. Client Processing Response anyway).

b) It offers a way to add data to other EDE codes as we see fit, now or 
in the future.

It is conceivable to send URI of an informational page for EDE 22 - No 
Reachable Authority happens.
I guess lots of operators would love ability to show a page 
"facebook.com is down for everyone, this is not our fault, so don't 
bother calling our support line".

Sure, it does not fit into complain/regulation categories, but we could 
simply add a new URI field "extra-info" for cases like this.

> 7.  Security Considerations
This very much needs feedback from browser vendors. First part about 
isolated environment looks okay to my HTTP-inexperienced eyes, but I 
think there might be some important details. E.g. is Accept-Language 
HTTP header permissible? I would say it should be otherwise we cannot 
meaningfully show errors in language understood by the user etc.

For this part I need some clarification:
>    Although the "d" value is validated, an attacker who is able to
>    inject the Structured Error EDNS(0) option so that a DNS proxy or DNS
>    forwarder, unaware of the option, will forward it and pass the
>    validation checks described in Section 5.3.  This means the other
>    JSON fields can be controlled by the attacker.  The "j" and "o"
>    fields are, perhaps, the most interesting for an attacker to modify
>    for nefarious purposes, because the "d" field has to match the
>    encrypted DNS server's name and the expanded URIs from the "c" and
>    "r" will point at the DNS resolver not under the attacker's control.

What attack scenario is this describing? DNS proxy which accepts 
encrypted connections but then blindly forwards via insecure channel 
upstream? Seriously?

Congratulations if you made it this far - have a great day!

-- 
Petr Špaček

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 11 Nov 2021 12:59:42 +0100 (CET)

> Il 10/11/2021 17:17 Petr Špaček <[email-masked]> ha scritto:
> 

I don't want to speak for them (I don't know if they are on this list, but they definitely are on ADD) but in past discussions around this concept they recognized its potential usefulness (apart maybe from a specific browser which seems to have a principle stance against DNS filters) but were concerned about the security of the mechanism, i.e. the risk that it could be used to present to the user a phishing or misleading page, either by an attacker or by the network itself, with the risk of the user not realizing that this is not their intended destination but a page generated by someone else. This explains many of the restrictions and requirements in the document, including the restriction to encrypted DNS connections.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 12 Nov 2021 15:26:04 +0100

On Thu, Nov 11, 2021 at 12:59:42PM +0100,
 Vittorio Bertola <vittorio.bertola=[email-masked]> wrote 
 a message of 24 lines which said:

> I don't want to speak for them (I don't know if they are on this
> list, but they definitely are on ADD) but in past discussions around
> this concept they recognized its potential usefulness (apart maybe
> from a specific browser which seems to have a principle stance
> against DNS filters) but were concerned about the security of the
> mechanism, i.e. the risk that it could be used to present to the
> user a phishing or misleading page,

Moreover, I have serious doubts that DNS configuration errors could be
meaningfully reported to end users. It would be very difficult to make
them understandable and, since we deal with errors in authoritative
servers, the client could not do anything, anyway.

I have nothing against informing users (some will find that useful)
but we should focus on reporting to the zone manager, not to the
client.

So, I don't think interaction with Web browser's authors is required.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 12 Nov 2021 15:32:27 +0100

On Fri, Nov 12, 2021 at 03:26:04PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 

> So, I don't think interaction with Web browser's authors is required.

Sorry, please ignore this message, I've mixed up
draft-wing-dnsop-structured-dns-error-page and
draft-ietf-dnsop-dns-error-reporting.

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 12 Nov 2021 10:24:41 -0500

On Wed, Nov 10, 2021 at 11:18 AM Petr Špaček <[email-masked]> wrote:
...

> formatted according to structured JSON specified in this draft.

I like this idea a lot.  In fact, I don't even think we need a new option.
It's not as if INFO-TEXT is already widely used.  We can just declare
something like "if the INFO-TEXT is JSON, here's what it means".

This also allows us to remove the "access denied" emphasis, and broaden our
focus to explaining all kinds of resolution failures.

I also agree that requiring an HTTP URL seems out of place here.  I would
prefer an "ID" string of unspecified contents, so that operators can use
UUIDs, domain names holding TXT records, URIs, or whatever mechanism they
want to identify failure types.

---

From: Petr Špaček <[email-masked]>
Date: Fri, 12 Nov 2021 16:38:57 +0100

> but we should focus on reporting to the zone manager, not to the

Seems like you are talking about a different document? Or are you 
suggesting the document to be dropped entirely because it goes in a 
completely wrong direction?

-- 
Petr Špaček

---

From: Petr Špaček <[email-masked]>
Date: Fri, 12 Nov 2021 18:00:30 +0100

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

> 1. Input from browser vendors

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

---

From: Eric Orth <[email-masked]>
Date: Mon, 15 Nov 2021 14:58:56 -0500

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 <[email-masked]> wrote:

> > Attackers might be trying to steal your information from
> blockedsite.example (for example, passwords, messages, or credit cards).
> Learn more
> > 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.
> >
> > 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 website may be impersonating "blockedsite.example" to steal you
> personal or financial information. You should go back to the previous page.
>
>

---

From: tirumal reddy <[email-masked]>
Date: Tue, 16 Nov 2021 11:18:50 +0530

Hi Petr,

Thanks for the detailed review. Please see inline

On Wed, 10 Nov 2021 at 21:48, Petr Špaček <[email-masked]> 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:
> > Side-by-side differences from -00 to -01 at
> https://www.ietf.org/rfcdiff?url2=draft-wing-dnsop-structured-dns-error-page-01.txt
>

Thanks.

> 1. Input from browser vendors

Yes, it needs to be discussed. The TTL value in the forged DNS response for
blocked domains is typically modified by the DNS filtering server to a
short duration value (e.g, 2 seconds) to handle domain category and
reputation updates. I don't see a problem if the timestamp in the "c" field
is offset by a few seconds.

> 3. Forwarding

[TR] Yes, it is referring to such proxies, see
https://datatracker.ietf.org/doc/html/rfc5625

> because it will be dropped by an intermediate forwarder.

We will update the draft to discuss the behaviour as follows:

When a forwarder receives a Structured Error EDNS(0) option, whether or not
(and how) to pass along JSON information on to their client is
implementation dependent.  Implementations MAY choose to not forward
information, or they MAY choose to create a new Structured Error EDNS(0)
option that conveys the information in the "j" field encoded in the
received EDNS(0) option.

> Feedback for actual text in the draft

The domain name is used to avoid the attack where a DNS proxy unaware of
the option forwards the received structured EDNS(0) option blindly. The
domain name validation ensures both the servers (DoT and HTTPS) are
operated by the same entity and have the same origin (similar to the same
Origin Policy). We will add more details for better clarity.

> In any case we should get feedback on this field browsers.

Agreed.

> Is it even

> simply add a new URI field "extra-info" for cases like this.

The extension allows the creation of new fields in future specifications.
If there is good consensus from the WG, we can definitely consider adding
new parameters in this document.

> HTTP header permissible?

Yes, Accept-Language HTTP header is permitted.

> I would say it should be otherwise we cannot

DNS proxy may use secure connection upstream but may not be aware of this
option.

-Tiru

> --
> Petr Špaček
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: tirumal reddy <[email-masked]>
Date: Tue, 16 Nov 2021 11:54:48 +0530

On Fri, 12 Nov 2021 at 20:55, Ben Schwartz <bemasc=
[email-masked]> wrote:

> I like this idea a lot.  In fact, I don't even think we need a new
> option.  It's not as if INFO-TEXT is already widely used.  We can just
> declare something like "if the INFO-TEXT is JSON, here's what it means".
>
> This also allows us to remove the "access denied" emphasis, and broaden
> our focus to explaining all kinds of resolution failures.
>

Sounds good to me, it requires an update to RFC8914 to add JSON in
EXTRA-TEXT.

>
> I also agree that requiring an HTTP URL seems out of place here.
>

The HTTP URL is for the end-user to report mis-classified DNS filtering of
a domain.

> I would prefer an "ID" string of unspecified contents, so that operators
> can use UUIDs, domain names holding TXT records, URIs, or whatever
> mechanism they want to identify failure types.
>

Yes, ID string is useful and the content can be opaque to the client. UUID
or URIs are useful for the DNS operator to identify the reason for failure.
I don't get the use of TXT records.

-Tiru

---

From: Neil Cook <[email-masked]>
Date: Tue, 16 Nov 2021 10:40:16 +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=[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hello everyone,
> 
> 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>
>

---

From: Eric Orth <[email-masked]>
Date: Tue, 16 Nov 2021 11:37:24 -0500

On Tue, Nov 16, 2021 at 5:40 AM Neil Cook <neil.cook=
[email-masked]> wrote:

> 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
> 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?
>

Yes, when we add the EDE support, beyond adding to logging, we would like
to use it to inform error messages displayed to the user.  So when Chrome
gets the Filtered EDE response, we could display an error message
indicating DNS filtration as the cause, rather than the current error
message about the domain maybe not existing.  Note that this would likely
be a hardcoded canned message generic to any filtering scenarios since
using any text from the response is where we get into the
security-sensitive situations.

>
> 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.
>

Yes, any text could be dangerous.  Imagine this error message: "Chrome
could not load your website because it has been blocked or filtered by the
following organization: GO TO ATTACKER.EXAMPLE.COM TO LOAD YOUR
WEBSITE!!!!111". Sure, it's obviously not legit for anybody that actually
reads the error message, but for anybody that just wants to visit their
website and is just quickly skimming the page to see how to do that,
there's enough danger here to make the security experts concerned.

> 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.
>
> 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

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 25 Nov 2021 14:37:21 +0100

Hello,
I realize this is tangential, but I believe it's important over the long 
term.

Any modification of DNS will break *later* DNSSEC validation.  As 
filtering seems almost always done by DNS modification (e.g. NXDOMAIN), 
and I see significant trends in doing filtering as a service, there's a 
problem that DNSSEC gets crippled from the filterer onwards.

I can't realistically see moving *all* filtering use cases into end 
clients, but I'd really hate for DNSSEC to meet the same fate and I 
don't think it's necessary at all.  In other words, we need a model 
where upstream DNS service is trusted with filtering but not with 
DNSSEC.  Now perhaps if validation was done directly in a browser, it 
might choose that only "positive" answers get validated and the rest is 
trusted (encrypted link etc), but generally I wouldn't do that, as it 
would surely create some holes in DANE or elsewhere.

What we already have is SERVFAIL.  That's what validators MUST return 
instead of the forged answer (since the beginning of DNSSEC).  And 
actually it does the filtering job, as the SERVFAILed services won't be 
accessible.

With EDE (RFC 8914) indicating a few kinds of filtering, servers and 
clients now could make some behavior better suited for these cases, 
around fallback to other servers, maybe caching, etc. (Say, only if it 
came over a trusted channel, based on local policy.)  I suspect there's 
currently still lots of room for improvement on implementation side 
here.  And orthogonally, structured-error-page or other mechanism could 
extend the available information in these *SERVFAIL* answers and perhaps 
get utilized in web browsers.

I do realize that SERVFAIL isn't ideal approach to blocking, but I can't 
really see anything better (or similar) that could reconcile DNSSEC with 
some of the common filtering use cases.

--Vladimir | knot-resolver.cz

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Nov 2021 09:41:42 -0500

I have repeatedly asked for RPZ draft publication so we can extend to a new version of RPZ that moves the censored dnssec answer to the additional section. This has the advantage that:

1) dnssec validation can still be done by clients that support this on the withheld answer RR
2) censorship is forced to be opt-in (the real answer can still be digged out of censored replies)
3) rogue censoring is still flagged as rogue censorship

Paul

Sent using a virtual keyboard on a phone

> On Nov 25, 2021, at 08:37, Vladimír Čunát <[email-masked]> wrote:
> 
> Hello,
> I realize this is tangential, but I believe it's important over the long term.
> 
> Any modification of DNS will break *later* DNSSEC validation.  As filtering seems almost always done by DNS modification (e.g. NXDOMAIN), and I see significant trends in doing filtering as a service, there's a problem that DNSSEC gets crippled from the filterer onwards.
> 
> I can't realistically see moving *all* filtering use cases into end clients, but I'd really hate for DNSSEC to meet the same fate and I don't think it's necessary at all.  In other words, we need a model where upstream DNS service is trusted with filtering but not with DNSSEC.  Now perhaps if validation was done directly in a browser, it might choose that only "positive" answers get validated and the rest is trusted (encrypted link etc), but generally I wouldn't do that, as it would surely create some holes in DANE or elsewhere.
> 
> What we already have is SERVFAIL.  That's what validators MUST return instead of the forged answer (since the beginning of DNSSEC).  And actually it does the filtering job, as the SERVFAILed services won't be accessible.
> 
> With EDE (RFC 8914) indicating a few kinds of filtering, servers and clients now could make some behavior better suited for these cases, around fallback to other servers, maybe caching, etc. (Say, only if it came over a trusted channel, based on local policy.)  I suspect there's currently still lots of room for improvement on implementation side here.  And orthogonally, structured-error-page or other mechanism could extend the available information in these *SERVFAIL* answers and perhaps get utilized in web browsers.
> 
> I do realize that SERVFAIL isn't ideal approach to blocking, but I can't really see anything better (or similar) that could reconcile DNSSEC with some of the common filtering use cases.
>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Nov 2021 09:25:37 -0800

SERVFAIL is often taken as a signal to try other servers for the 
delegation point or some other recursive server. when recursive server 
policy has trampled an answer, it is meant to be about the data, not the 
server. so SERVFAIL is both operationally and syntactically wrong here.

as an example, DNS RPZ will be default pass through any DNSSEC-signed 
response, but it can be overridden with an option called "break dnssec" 
or similar. neither passing it through or breaking the signatures is 
desirable, but we kicked that can down the road.

in the years since DNS RPZ was made, i've realized that authoritarian 
network operators including authoritarian national governments are not 
well served by DNS RPZ in its current form. what we (and they) need is a 
way to include the original answer and also a server-level signature on 
the policy-trampled answer. this way we (and they) can watch what the 
stub does next -- which answer it consumes -- and therefore know whether 
the policy (or the law) is being abrogated, so as to trigger an 
enforcement action.

probably this just means packing the original answer and the policy 
signature into EDNS in some way. but the response itself will have to 
have the policy-trampled answer and rcode (likely NXDOMAIN but not always.)

vixie

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Nov 2021 18:36:32 -0500 (EST)

On Thu, 25 Nov 2021, Paul Vixie wrote:

> in the years since DNS RPZ was made, i've realized that authoritarian network 
> operators including authoritarian national governments are not well served by 
> DNS RPZ in its current form. what we (and they) need is a way to include the 
> original answer and also a server-level signature on the policy-trampled 
> answer. this way we (and they) can watch what the stub does next -- which 
> answer it consumes -- and therefore know whether the policy (or the law) is 
> being abrogated, so as to trigger an enforcement action.

This is deeply concerning statement, even if you are trying to convince
the authoritarians that they should let the DNS answer slide through
"in their best interest".

In fact, a much better answer here would be to develop a DNS protocol
that would prevent those kind of authoritarian network operators to
get any visiblity at all in what their citizens are doing. Luckily,
there is a good protocol for that, DoH. I hope it sees widespread use
over too many hostnames to track and block.

> probably this just means packing the original answer and the policy signature 
> into EDNS in some way. but the response itself will have to have the 
> policy-trampled answer and rcode (likely NXDOMAIN but not always.)

This has a similar effect as moving the RRs from Answer to Authority
section, and sure has a little better signaling support although if
this is not coming directly from the application, they might not see
the EDNS option either. So sadly this would be a reason to move DNS
into applications, something which I wish we could stop doing.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Nov 2021 16:16:42 -0800

> "in their best interest".

any belief that too much effort will at some point cause authoritarian 
network operators (including myself, most large enterprises, and many 
national governments) to give up and let the spice flow where it may, is 
naive or pretense. we should adopt some nuance, and figure out what the 
real shape of the real negotiating table is, and start working towards 
an equilibrium. these ships will NOT pass in the night.

> over too many hostnames to track and block.

right now DoH is pretty easy to detect and block. that'll change, as DoH 
adopts cover traffic and other Tor-style trickery. eventually it'll be 
nec'y to block some traffic at the IP (packet) layer even if that cuts a 
network operator off from important CDNs. later, it'll become nec'y to 
block all outbound packet traffic and insist that an edge proxy with a 
local crypto key be used. no managed private network operator can afford 
to "just say yes." _their network means their rules_ just as it did when 
unsolicited traffic (spam, DDoS) first crawled out of the muck.

the more the internet tries to make itself viral, the more abuse we'll 
see from surveillance capitalists (including a lot of IoT) and botnets 
and intruders and malicious insiders and malware, all of whom are hoping 
to get the treatment that's being planned by digital activists for 
political dissidents. this will cause escalation by defenders. the end 
game is that the internet stops at the border of each managed private 
network, and signals are regenerated after being analyzed.

i'm speaking of inevitabilities here not aspirations, so please don't 
shoot the messenger. the world is the way it is for reasons, and unless 
we learn how the world is and why, we had better worry about unintended 
consequences of digital signal activism. adult negotiation starts with 
the middle ground of the possible and only uses shows of force to avoid 
corners and edges. the IETF is not doing this, which will lead us 
through wasted time and missed better outcomes.

> the EDNS option either. ...

the signal path from the authority to the stub must pass through many 
networks, some of which are public (commercial ISPs) or otherwise policy 
agnostic (many universities and many families). to the extent that some 
signal patterns are unacceptable to some on-path operators, we should 
make transactions and outcomes including policy-trampling as transparent 
as we can. hiding stuff because you consider on-path actors to be 
hostile is going to seem, well, hostile.

> ... So sadly this would be a reason to move DNS into applications,
> something which I wish we could stop doing.
that last topic is one for the ADD WG which i know that you (wouters) 
are actively aware of and participating in, but for the benefit of 
others here: see <https://datatracker.ietf.org/wg/add/about/>. one topic 
currently under discussion there is how a network operator can signal 
its resolver policy -- partly because operators of managed private 
networks want to be sure that an endpoint who does not follow that 
policy is behaving intentionally and with forethought. this helps guide 
and prioritize our enforcement activities.

-- 
vixie