Re: [Doh] [Technical Errata Reported] RFC8484 (6033)

[Barry Leiba <[e-mail]>]

The proposed change substantively changes the text and cannot be
approved through an errata report.  My inclination is "Rejected", as I
do believe the text says what it's intended to say (so it's not an
erratum), but I could be convinced that "held for document update" is
better if the document editors weigh in.

In particular:
> Forbidding discovery of URI outside the configuration contradicts the above excerpt. The text is as such incorrect.
>
> (6) Also, I suggest to remove "simply" from the text. Not sure what message is supposed to convey.

"Simply" is critical, and addresses your line above.  Consider:

   A DoH client MUST NOT use a different URI that was discovered outside
   of the client's configuration

That's your substitution, and *that* forbids discovery outside the
configuration.  But with "simply", as written, it says that there must
be another reason for using a different URI.  It can discover the URI
from outside the configuration, but that can't be the only reason for
using it.  That discovery has to be augmented by some other knowledge.

Barry

On Mon, Mar 30, 2020 at 11:53 AM RFC Errata System
<[e-mail]> wrote:
>
> The following errata report has been submitted for RFC8484,
> "DNS Queries over HTTPS (DoH)".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6033
>
> --------------------------------------
> Type: Technical
> Reported by: Mohamed Boucadair <[e-mail]>
>
> Section: 3
>
> Original Text
> -------------
>    A DoH client MUST NOT use a different URI simply because it was
>    discovered outside of the client's configuration (such as through
>    HTTP/2 server push) or because a server offers an unsolicited
>    response that appears to be a valid answer to a DNS query.
>
> Corrected Text
> --------------
>    A DoH client MUST NOT use a different URI that was discovered outside
>    of the client's configuration (except via HTTP redirection discussed
>    in Section 6.4 of [RFC7231]).  Also, the DoH client MUST ignore an
>    unsolicited response (such as through HTTP/2 server push) that
>    appears to be a valid answer to a DNS query unless that response
>    comes from a configured URI (as described in Section 5.3).
>
> Notes
> -----
> (1) The intent of this text is confusing.
>
> (2) I checked the mailing list and found that the text was updated late in the publication process to address this comment: https://mailarchive.ietf.org/arch/msg/doh/f_V-tBgB-KRsLZhttx9tGt75cps/.
>
> (3) The example provided in the thread (server push) is related to the second part of the OLD text. It is mistakenly attached to the first part.
>
> (4) The push example may be interpreted as if server push is disallowed. This is conflicting with Section 5.3.
>
> Hence, this change:
>
> Also, the DoH client MUST ignore an
>    unsolicited response (such as through HTTP/2 server push) that
>    appears to be a valid answer to a DNS query ** unless that response
>    comes from a configured URI (as described in Section 5.3) **.
>
> (5) An intuitive way to discover the URI outside the configuration is redirection.  RFC8484 indicates clearly the following:
>
>    The described approach is more than a tunnel over HTTP.  It
>    establishes default media formatting types for requests and responses
>    but uses normal HTTP content negotiation mechanisms for selecting
>    alternatives that endpoints may prefer in anticipation of serving new
>    use cases.  In addition to this media type negotiation, it ** aligns
>    itself with HTTP features ** such as caching, **redirection**, proxying,
>    authentication, and compression.
>
> Forbidding discovery of URI outside the configuration contradicts the above excerpt. The text is as such incorrect.
>
> (6) Also, I suggest to remove "simply" from the text. Not sure what message is supposed to convey.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC8484 (draft-ietf-doh-dns-over-https-14)
> --------------------------------------
> Title               : DNS Queries over HTTPS (DoH)
> Publication Date    : October 2018
> Author(s)           : P. Hoffman, P. McManus
> Category            : PROPOSED STANDARD
> Source              : DNS Over HTTPS
> Area                : Applications and Real-Time
> Stream              : IETF
> Verifying Party     : IESG