Re: [DNSOP] Review of draft-ietf-dnsop-structured-dns-error-03

[[e-mail]]

Hi Mukund, 

Many thanks for the detailed review. 

We updated the spec to address many of your suggestions. We added in particular text to explain the rationale for having c/j mandatory for IT teams and also added text to explain why suberr is defined rather than consuming ede codes. However, no changes were made for your comments about, e.g., translation/TTL, as that part of the text was added to address previous comments we received from the WG. 

FWIW, a diff can be seen at: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-structured-dns-error-03&url2=draft-ietf-dnsop-structured-dns-error-05&difftype=--html

Thanks again. 

Cheers,
Med

> -----Message d'origine-----
> De : DNSOP <[e-mail]> De la part de Mukund Sivaraman
> Envoyé : mardi 27 juin 2023 19:29
> À : [e-mail]
> Objet : [DNSOP] Review of draft-ietf-dnsop-structured-dns-error-03
> 
> We're implementing RFC 8914 for error reporting from NIOS's DNS
> features, and so I read this draft today:
> 
> > DNS Operations Working Group
> D. Wing
> > Internet-Draft
> Citrix
> > Updates: 8914 (if approved)
> T. Reddy
> > Intended status: Standards Track
> Nokia
> > Expires: 28 November 2023
> N. Cook
> >
> Open-Xchange
> >                                                             M.
> Boucadair
> >
> Orange
> >                                                              27
> May
> > 2023
> 
> 
> >                  Structured Error Data for Filtered DNS
> >                 draft-ietf-dnsop-structured-dns-error-03
> 
> > Abstract
> 
> >    DNS filtering is widely deployed for various reasons,
> including
> >    network security.  However, filtered DNS responses lack
> information
> >    for end users to understand the reason for the filtering.
> 
> What is claimed in this introduction does not appear entirely
> accurate after RFC 8914.
> 
> * RFC 8914 allows filtered DNS responses to contain the EDE EDNS
> option
>   that can contain a populated EXTRA-TEXT field specifically for
>   end-users.
> 
> * Whether the EXTRA-TEXT field is populated, and what is entered
> there
>   is optional. Several of our customers would not even want to
> indicate
>   that responses have been filtered (we've had trouble with even
>   returning an SOA record in RPZ-rewritten answers), so the
> optional
>   nature of this field is fine.
> 
> It appears the authors want to structure it so it can be used to
> display a generated error-page within a web-browser, to avoid
> loading an error-page via HTTPS, which is a fine goal.
> 
> > Existing mechanisms to provide explanatory details to end users
> cause
> >    harm especially if the blocked DNS response is to an HTTPS
> server.
> 
> I suggest rewording this sentence as it reads as though the
> blocked DNS response is sent to a HTTPS server. Instead, I assume
> what the authors are attempting to state is that blocked DNS
> responses may cause harm if they contain address records that
> cause web traffic for a web-domain to be directed to a different
> local HTTPS server.
> 
> 
> > 1.  Introduction
> 
> >    DNS filters are deployed for a variety of reasons, e.g.,
> endpoint
> >    security, parental filtering, and filtering required by law
> >    enforcement.
> 
> I suggest keeping the above part of the paragraph ...
> 
> > Network-based security solutions such as firewalls and
> >    Intrusion Prevention Systems (IPS) rely upon network traffic
> >    inspection to implement perimeter-based security policies and
> operate
> >    by filtering DNS responses.  In a home network, DNS filtering
> is used
> >    for the same reasons as above and additionally for parental
> control.
> >    Internet Service Providers (ISPs) typically block access to
> some DNS
> >    domains due to a requirement imposed by an external entity
> (e.g., law
> >    enforcement agency) also performed using DNS-based content
> filtering.
> 
> ... and removing the part above as it's unnecessary extra detail,
> which may not age well.
> 
> >    Users of DNS services that perform filtering may wish to
> receive more
> >    explanatory information about such a filtering to resolve
> problems
> 
> s/such a filtering/such filtering/
> 
> >    with the filter -- for example to contact the administrator
> to
> >    allowlist a DNS domain that was erroneously filtered or to
> > understand
> 
> s/allowlist/allow/
> 
> >    the reason a particular domain was filtered.  With that
> information,
> >    a user can choose another network, open a trouble ticket with
> the
> > DNS
> 
> s/a user can choose another network/a user can choose to use
> another network/
> 
> >    administrator to resolve erroneous filtering, log the
> information, or
> >    other uses.
> 
> s/or other uses/or do something else with it/
> 
> >    For the DNS filtering mechanisms described in Section 3 the
> DNS
> >    server can return extended error codes Blocked, Filtered, or
> Forged
> >    Answer defined in Section 4 of [RFC8914].  However, these
> codes only
> >    explain that filtering occurred but lack detail for the user
> to
> >    diagnose erroneous filterings.
> 
> >    No matter which type of response is generated (forged IP
> address(es),
> >    NXDOMAIN or empty answer, even with an extended error code),
> the user
> >    who triggered the DNS query has little chance to understand
> which
> >    entity filtered the query, how to report a mistake in the
> filter, or
> >    why the entity filtered it at all.  This document describes a
> >    mechanism to provide such detail.
> 
> This has to be reworded, because the user can understand what
> happened from the EXTRA-TEXT field of RFC 8914 if the information
> is provided.
> This draft's purpose appears to be about structuring such
> information for display in a UI, so the authors should describe it
> so.
> 
> >    One of the other benefits of the approach described in this
> document
> >    is to eliminate the need to "spoof" block pages for HTTPS
> resources.
> >    This is achieved since clients implementing this approach
> would be
> >    able to display a meaningful error message, and would not
> need to
> >    connect to such a block page.  This approach thus avoids the
> need to
> >    install a local root certificate authority on those IT-
> managed
> >    devices.
> 
> This is a fine goal and I like it, but:
> 
> (1) Is the need to spoof a website gone? What about clients that
> do not support this draft? They may still receive e.g. address
> records from a resolver that performs filtering, and attempt to
> use those addresses.
> 
> (2) Are web-browser developers on board with implementing such a
> draft?
> 
> >    This document describes a format for computer-parsable data
> in the
> >    EXTRA-TEXT field of [RFC8914].  It updates Section 2 of
> [RFC8914]
> >    which says the information in EXTRA-TEXT field is intended
> for human
> >    consumption (not automated parsing).
> 
> This is the abstract of the draft that describes its purpose
> neatly; I suggest placing this text in the abstract.
> 
> >    This document does not recommend DNS filtering but provides a
> >    mechanism for better transparency to explain to the users why
> some
> >    DNS queries are filtered.
> 
> > 2.  Conventions and Definitions
> 
> >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT",
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
> "MAY", and
> >    "OPTIONAL" in this document are to be interpreted as
> described in
> >    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear
> in all
> >    capitals, as shown here.
> 
> >    This document uses terms defined in DNS Terminology
> [RFC8499].
> 
> >    "Requestor" refers to the side that sends a request.
> "Responder"
> >    refers to an authoritative, recursive resolver or other DNS
> component
> >    that responds to questions.
> 
> >    "Encrypted DNS" refers to any encrypted scheme to convey DNS
> >    messages, for example, DNS-over-HTTPS [RFC8484], DNS-over-TLS
> >    [RFC7858], or DNS-over-QUIC [RFC9250].
> 
> >    The document refers to an Extended DNS Error (EDE) using its
> purpose,
> >    not its INFO-CODE as per Table 3 of [RFC8914].  "Forged
> Answer",
> >    "Blocked", and "Filtered" are thus used to refer to "Forged
> Answer
> >    (4)", "Blocked (15)", and "Filtered (17)".
> 
> > 3.  DNS Filtering Techniques and Their Limitations
> 
> >    DNS responses can be filtered by sending a bogus (also called
> >    "forged") A or AAAA response, NXDOMAIN error or empty answer,
> or an
> >    Extended DNS Error code defined in [RFC8914].
> 
> Does this enumerate all the cases? RPZ and some other lying
> features in DNS implementations allow returning forged answers for
> other types too. I suggest removing the "A or AAAA" part, or
> starting the paragraph as "DNS responses to address queries can be
> filtered...".
> 
> I don't understand the last part, i.e., "DNS responses can be
> filtered by sending ... an Extended DNS Error code defined in
> [RFC8914]". How are responses filtered by sending an EDE EDNS
> option?
> 
> > Each of these methods have advantages and disadvantages that are
> >    discussed below:
> 
> 
> 
> 
> 
> > Wing, et al.            Expires 28 November 2023
> [Page 4]
> >
> 
> 
> > Internet-Draft            Structured DNS Error
> May 2023
> 
> 
> >    1.  The DNS response is forged to provide a list of IP
> addresses that
> >        points to an HTTP(S) server alerting the end user about
> the
> >        reason for blocking access to the requested domain (e.g.,
> >        malware).  When an HTTP(S) enabled domain name is
> blocked, the
> >        network security device (e.g., Customer Premises
> Equipment (CPE)
> >        or firewall) presents a block page instead of the HTTP
> response
> >        from the content provider hosting that domain.  If an
> HTTP
> >        enabled domain name is blocked, the network security
> device
> >        intercepts the HTTP request and returns a block page over
> HTTP.
> >        If an HTTPS enabled domain is blocked, the block page is
> also
> >        served over HTTPS.  In order to return a block page over
> HTTPS,
> >        man in the middle (MITM) is enabled on endpoints by
> generating a
> >        local root certificate and an accompanying (local)
> public/private
> >        key pair.  The local root certificate is installed on the
> >        endpoint while the network security device stores a copy
> of the
> >        private key.  During the TLS handshake, the on-path
> network
> >        security device modifies the certificate provided by the
> server
> >        and (re)signs it using the private key from the local
> root
> >        certificate.
> 
> >        *  However, configuring the local root certificate on
> endpoints
> >           is not a viable option in several deployments like
> home
> >           networks, schools, Small Office/Home Office (SOHO), or
> Small/
> >           Medium Enterprise (SME).  In these cases, the typical
> behavior
> >           is that the filtered DNS response points to a server
> that will
> >           display the block page.  If the client is using HTTPS
> (via a
> >           web browser or another application) this results in a
> >           certificate validation error which gives no
> information to the
> >           end-user about the reason for the DNS filtering.
> 
> >        *  Enterprise networks do not assume that all the
> connected
> >           devices are managed by the IT team or Mobile Device
> Management
> >           (MDM) devices, especially in the quite common Bring
> Your Own
> >           Device (BYOD) scenario.  In addition, the local root
> >           certificate cannot be installed on IoT devices without
> a
> >           device management tool.
> 
> >        *  An end user does not know why the connection was
> prevented
> >           and, consequently, may repeatedly try to reach the
> domain but
> >           with no success.  Frustrated, the end user may switch
> to an
> >           alternate network that offers no DNS filtering against
> malware
> >           and phishing, potentially compromising both security
> and
> >           privacy.  Furthermore, certificate errors train users
> to click
> >           through certificate errors, which is a bad security
> practice.
> >           To eliminate the need for an end user to click through
> >           certificate errors, an end user may manually install a
> local
> >           root certificate on a host device.  Doing so, however,
> is also
> >           a bad security practice as it creates a security
> > vulnerability
> 
> >           that may be exploited by a MITM attack.  When a
> manually
> >           installed local root certificate expires, the user has
> to
> >           (again) manually install the new local root
> certificate.
> 
> The above is a good explanation, but it appears excessive,
> deviating from the gist of the draft. Instead, the authors could
> concisely write that a client may see certificate errors when
> attempting to browse error pages due to the redirection of HTTPS
> traffic to an unauthentic webserver.
> 
> 
> >    2.  The DNS response is forged to provide a NXDOMAIN response
> to
> >        cause the DNS lookup to terminate in failure.  In this
> case, an
> >        end user does not know why the domain cannot be reached
> and may
> >        repeatedly try to reach the domain but with no success.
> >        Frustrated, the end user may use insecure connections to
> reach
> >        the domain, potentially compromising both security and
> privacy.
> 
> This appears to be a good example where having a structured error
> is an advantage over the current practice.
> 
> >    3.  The extended error codes Blocked and Filtered defined in
> >        Section 4 of [RFC8914] can be returned by a DNS server to
> provide
> >        additional information about the cause of a DNS error.
> 
> >    4.  These extended error codes do not suffer from the
> limitations
> >        discussed in bullets (1) and (2), but the user still does
> not
> >        know the exact reason nor he/she is aware of the exact
> entity
> 
> I suggest removing "he/she"; it reads well without it.
> 
> >        blocking the access to the domain.  For example, a DNS
> server may
> >        block access to a domain based on the content category
> such as
> >        "Malware" to protect the endpoint from malicious
> software,
> >        "Phishing" to prevent the user from revealing sensitive
> >        information to the attacker, etc.  A user needs to know
> the
> >        contact details of the IT/InfoSec team to raise a
> complaint.
> 
> A user does not "need to know". "A user may want to know" is
> perhaps better text here. Depending on the feature implementing
> filtering (e.g., RPZ vs. parental control) I doubt if some of our
> customers would even indicate if rewriting/filtering occurred
> going by past activity. So all this is optional.
> 
> >    5.  When a DNS resolver or forwarder forwards the received
> EDE
> >        option, the EXTRA-TEXT field only conveys the source of
> the error
> >        (Section 3 of [RFC8914]) and does not provide additional
> textual
> >        information about the cause of the error.
> 
> This claim does not appear accurate. RFC 8914 section 3 mentions
> "the source of the error SHOULD be attributed in the EXTRA-TEXT
> field" in the context of forwarding only, and just that the source
> is also included alongside any other text that may also be
> present. I don't see that there are any limitations on what may be
> included in the EXTRA-TEXT field, and there could even be multiple
> EDE options.
> 
> > 4.  I-JSON in EXTRA-TEXT Field
> 
> >    DNS servers that are compliant with this specification send
> I-JSON
> >    data in the EXTRA-TEXT field [RFC8914] using the Internet
> JSON
> >    (I-JSON) message format [RFC7493].
> 
> Reword as "DNS servers that are compliant with this specification
> send data in the EXTRA-TEXT field [RFC8914] encoded using the
> Internet JSON
> (I-JSON) message format [RFC7493]."
> 
> However, using some kind of binary encoding may reduce the size of
> the EDE option. DNS client software can decode the binary encoding
> for human-readable presentation.
> 
> >       Note that [RFC7493] was based on [RFC7159], but [RFC7159]
> was
> >       replaced by [RFC8259]
> .
> >    This document defines the following JSON names:
> 
> >    c: (contact)  The contact details of the IT/InfoSec team to
> report
> >       mis-classified DNS filtering.  This field is structured as
> an
> >       array of contact URIs (e.g., tel, sips, https).  At least
> one
> >       contact URI MUST be included.  This field is mandatory.
> 
> I suggest not making it mandatory. The operator may wish to
> indicate that filtering occurred without attracting flak from some
> users.
> 
> Also, just how many IT teams respond or take action when something
> is reported to them? Not all do.
> 
> >    j: (justification)  'UTF-8'-encoded [RFC5198] textual
> justification
> 
> >       for this particular DNS filtering.  The field should be
> treated
> >       only as diagnostic information for IT staff.  This field
> is
> >       mandatory.
> 
> I suggest not making it mandatory. If it is mandatory, some
> operators may put whitespace or "N/A" in the field's value.
> 
> >    s: (suberror)  the suberror code for this particular DNS
> filtering.
> >       This field is optional.
> 
> There are 16 bits in RFC 8914's INFO-CODEs, allowing a total of
> 65536 values. I suggest adding more values there than starting
> another registry. Try to keep text and constructs as simple as it
> can be.
> There's already an RCODE, and an EDE INFO-CODE, and the draft's
> proposing a 3rd level of suberror code. This is excessive.
> 
> >    o: (organization)  'UTF-8'-encoded human-friendly name of the
> >       organization that filtered this particular DNS query.
> This field
> >       is optional.
> 
> >    New JSON names can be defined in the IANA registry introduced
> in
> >    Section 11.2.  Such names MUST consist only of lower-case
> ASCII
> >    characters, digits, and hyphens (that is, Unicode characters
> U+0061
> >    through 007A, U+0030 through U+0039, and U+002D).  Also,
> these
> >    names MUST be 63 characters or shorter and it is RECOMMENDED
> they
> >    be as short as possible.
> 
> >    The text in the "j" and "o" names can include international
> >    characters.  If the text is displayed in a language not known
> to the
> >    end user, browser extensions to translate to user's native
> language
> >    can be used.
> 
> I suggest deleting this paragraph. It has already been mentioned
> elsewhere that the fields are UTF-8 encoded. Describing browser
> extentions to translate strings deviates from the topic of this
> draft.
> 
> >    To reduce packet overhead the generated JSON SHOULD be as
> short as
> >    possible: short domain names, concise text in the values for
> the "j"
> >    and "o" names, and minified JSON (that is, without spaces or
> line
> >    breaks between JSON elements).
> 
> s/packet overhead/DNS message size/
> 
> It isn't exactly "overhead" if it's the contents.
> 
> >    The JSON data can be parsed to display to the user, logged,
> or
> >    otherwise used to assist the end-user or IT staff with
> >    troubleshooting and diagnosing the cause of the DNS
> filtering.
> 
> > 5.  Protocol Operation
> 
> > 5.1.  Client Generating Request
> 
> >    When generating a DNS query the client includes the EDE
> option
> >    (Section 2 of [RFC8914]) in the OPT pseudo-RR [RFC6891] to
> elicit the
> >    EDE option in the DNS response.
> 
> Is this what this draft requires, or is the sentence above
> claiming that RFC 8914 requires it as well?
> 
> > It SHOULD use an OPTION-LENGTH of 2,
> >    the INFO-CODE field set to "0" (Other Error), and an empty
> EXTRA-TEXT
> >    field.  This signal indicates that the client desires that
> the server
> >    responds in accordance with the present specification.
> 
> Why?
> 
> This draft appears to describe a simple extension of EDE, limited
> to structuring the value in the EXTRA-TEXT field.
> 
> > 5.2.  Server Generating Response
> 
> >    When the DNS server filters its DNS response to an A or AAAA
> record
> >    query, the DNS response MAY contain an empty answer,
> NXDOMAIN, or
> >    (less ideally) forged A or AAAA response, as desired by the
> DNS
> >    server.
> 
> Again, limiting to A/AAAA is not correct. Other RR types are also
> filtered by filtering features in implementation today.
> 
> > In addition, if the query contained the OPT pseudo-RR the DNS
> server
> >    MAY return more detail in the EXTRA-TEXT field as described
> in
> >    Section 5.3.
> 
> >    Servers may decide to return small TTL values in filtered DNS
> >    responses (e.g., 2 seconds) to handle domain category and
> reputation
> >    updates.
> 
> Suggesting TTLs here appears off-topic. The draft is just about
> structuring the EDE.EXTRA-TEXT field.
> 
> >    Because the DNS client signals its EDE support (Section 5.1)
> and
> >    because EDE support is signaled via a non-cached OPT resource
> record
> >    (Section 6.2.1 of [RFC6891]) the EDE-aware DNS server can
> tailor its
> >    filtered response to be most appropriate to that client's EDE
> >    support.  If EDE support is signaled in the query the server
> MUST NOT
> >    return the "Forged Answer" extended error code because the
> client can
> >    take advantage of EDE's more sophisticated error reporting
> (e.g.,
> >    "Filtered", "Blocked").  Continuing to send "Forged Answer"
> even to
> >    an EDE-supporting client will cause the persistence of the
> drawbacks
> >    described in Section 3.
> 
> Why? What if forged-answer info-code is returned? A web user-agent
> can ignore the answer section and use the structured EXTRA-TEXT
> field anyway. The paragraph above is not very clear.
> 
> > 5.3.  Client Processing Response
> 
> >    On receipt of a DNS response with an EDE option from a DNS
> responder,
> >    the following actions are performed on the EXTRA-TEXT field:
> 
> >    *  Verify the field contains valid JSON.  If not, the
> requestor MUST
> >       discard data in the EXTRA-TEXT field.
> 
> >    *  The response MUST be received over an encrypted DNS
> channel.  If
> >       not, the requestor MUST discard data in the EXTRA-TEXT
> field.
> 
> Why is this additional requirement present over RFC 8914? RFC 8914
> does not prevent unencrypted DNS transports from carrying a human
> readable EXTRA-TEXT field (which may be displayed by a client
> program such as 'dig').
> 
> >    *  Servers which don't support this specification might use
> plain
> >       text in the EXTRA-TEXT field so that requestors SHOULD
> properly
> 
> s/in the EXTRA-TEXT field so that/field, and so/
> 
> 
> > 6.  Interoperation with RPZ Servers
> 
> >    This section discusses operation with an RPZ server [RPZ]
> that
> >    indicates filtering with a NXDOMAIN response with the
> Recursion
> >    Available bit cleared (RA=0).
> 
> >    When a DNS client supports this specification it includes the
> EDE
> >    option in its DNS query.
> 
> >    If the server does not support this specification and is
> performing
> >    RPZ filtering, the server ignores the EDE option in the DNS
> query and
> >    replies with NXDOMAIN and RA=0.  The DNS client can continue
> to
> >    accept such responses.
> 
> >    If the server does support this specification and is
> performing RPZ
> >    filtering, the server can use the EDE option in the query to
> identify
> >    an EDE-aware client and respond appropriately (that is, by
> generating
> >    a response described in {#server-response}) as NXDOMAIN and
> RA=0 are
> >    not necessary when generating a response to such a client.
> 
> If NXDOMAIN is not necessary, what RCODE will be returned in RPZ-
> rewritten responses where NXDOMAIN is returned today?
> 
> 
> Thank you for attempting this. Some of what is described appears
> as an improvement over what is practised currently.
> 
> The review above may seem overly critical because it mostly
> contains suggestions to correct/change text, rather than praise
> for what is good.
> 
> However, overall, after reading the draft till the end and
> considering what it proposes, I think that based on the INFO-CODE,
> having a web browser display the EXTRA-TEXT field of RFC 8914 as a
> text string would serve the purpose of displaying information
> (whatever the operator desires to show) about what filtering
> occurred, and any other free-text such as contact information.
> Perhaps additional EDE INFO-CODEs may be added to the RFC 8914
> registry as required, and it may be prescribed that browsers avoid
> loading web-pages with address records from forged answers and
> instead display the EXTRA-TEXT field.
> 
> This JSON encoding of the same and adding a registry for fields
> within it appears excessive for the purpose it aims to serve.
> 
> 		Mukund
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.