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:compla...@somewhere.com?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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
