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

[Petr Špaček <[e-mail]>]

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:[e-mail]?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