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

[[e-mail]]

Hi Barry,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Barry Leiba [mailto:[e-mail]]
> Envoyé : lundi 30 mars 2020 18:40
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Paul Hoffman; Patrick McManus; Murray Kucherawy; Ben Schwartz;
> Dave Lawrence; [e-mail]; RFC Editor
> Objet : Re: [Technical Errata Reported] RFC8484 (6033)
> 
> Re-sending to correct the correction to Mohamed's email address, which
> was mistyped in the errata report and then by me.  Sigh.
> 
> Barry
> 
> On Mon, Mar 30, 2020 at 12:32 PM Barry Leiba <[e-mail]>
> wrote:
> >
> > 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.

[Med] What it forbids is **a different URI** not discovery in general.  

The configuration (including discovery) of the (base) URI is covered by this text:

==
   Note that
   configuration might be manual (such as a user typing URI Templates in
   a user interface for "options") or automatic (such as URI Templates
   being supplied in responses from DHCP or similar protocols).  DoH
   Servers MAY support more than one URI Template
==
 
  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. 

[Med] Wouldn’t that reasoning also imply that there might be conditions under which the client may accept responses from a server that appear to be a valid DNS query? I'm referring to the second part of the sentence: 

   "A DoH client MUST NOT use a different URI **simply** because [...]
   or because a server offers an unsolicited
   response that appears to be a valid answer to a DNS query." 

My understanding is that this is not the intent of the text given this explanation I found in the archives:

====
I send an query to https://www.ekrexample.com/ over HTTP/2. During that 
HTTP/2 session, I get a DoH request/response pair from that origin. 
https://www.ekrexample.com/ is not in the list of configured URIs 
allowed for DoH for this client. I MUST NOT do anything with that DoH 
request/response.
====

This is BTW why I think the server push example is related to the second part of the sentence, not the first one.


 That discovery has to be augmented by some other
> knowledge.

[Med] As I mentioned, this part is about a "different URI". This is even clear with this sentence: 

   This specification does not extend DNS resolution
   privileges to URIs that are not recognized by the DoH client as
   configured URIs. 

I fail to see where that some other knowledge is defined in the document.   

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