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

[tirumal reddy <[e-mail]>]

Hi Petr,

Thanks for the detailed review. Please see inline

On Wed, 10 Nov 2021 at 21:48, Petr Špaček <[e-mail]> wrote:

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

Thanks.


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

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

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


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

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

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.


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


Agreed.


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

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.


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


Yes, Accept-Language HTTP header is permitted.


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

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

-Tiru


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


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