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

From: RFC Errata System <[email-masked]>
Date: Mon, 30 Mar 2020 08:53:04 -0700 (PDT)

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 <[email-masked]>

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Mar 2020 12:32:47 -0400

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.

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Mar 2020 12:37:41 -0400

Re-sending after fixing Mohamed's email address, which seems to be
mis-typed in the errata report.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Mar 2020 12:39:57 -0400

Re-sending to correct the correction to Mohamed's email address, which
was mistyped in the errata report and then by me.  Sigh.

Barry

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Mar 2020 17:24:17 +0000

On Mon, Mar 30, 2020 at 12:32 PM Barry Leiba <[email-masked]> wrote:
> approved through an errata report.  

I agree with Barry, even though I believe that what Mohamed is asking for could have been what the WG or the IETF wanted, had they seen this proposed change while the document was being developed. For example, when I read the proposed change, I thought "of course he's right about HTTP redirection"; however, I don't know if other people who are more literate about HTTP would agree.

> My inclination is "Rejected", as I

"held for document update" normally indicates that the erratum is believed to be valid. We don't know that without going through WG Last Call and IETF Last Call again. Given how heavily this document was discussed before publication, I do not think it is appropriate to change it with an erratum.

I have not heard of any developer misunderstanding the current words in a way that would be fixed by this rewording. Further, the bit about HTTP redirection is a technical change (possibly an oversight, or possibly it was left out on purpose by those who understand it better). 

--Paul Hoffman

---

From: <[email-masked]>
Date: Tue, 31 Mar 2020 07:23:23 +0000

Hi Barry,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Barry Leiba [mailto:[email-masked]]
> Envoyé : lundi 30 mars 2020 18:40
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Paul Hoffman; Patrick McManus; Murray Kucherawy; Ben Schwartz;
> Dave Lawrence; [email-masked]; RFC Editor
> Objet : Re: [Technical Errata Reported] RFC8484 (6033)
> 
> > > Forbidding discovery of URI outside the configuration contradicts
> the above excerpt. The text is as such incorrect.
> > >
> > 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
> > 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.   

> > > (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:
> > >
> > > (5) An intuitive way to discover the URI outside the configuration
> is redirection.  RFC8484 indicates clearly the following:
> > >
> > > Forbidding discovery of URI outside the configuration contradicts
> the above excerpt. The text is as such incorrect.
> > >

---

From: <[email-masked]>
Date: Tue, 31 Mar 2020 09:03:21 +0000

Hi Paul,

Thank you for sharing your thoughts. 

I'm now more puzzled about the intent of the document with regards to redirection:

(a) The document says explicitly 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.

Which I interpret as redirection is part of the design goals.

(b) But what I'm hearing from you is that redirection may be implicitly disallowed for some "reason". This seems like an internal inconsistency of the document that is worth to be fixed. 

Can you please clarify the following:

* Is redirection allowed or not?  
* How a different URI can be discovered using server push? 

                             ^^^^^^^^^^^^^^^^
                                                    ^^^^^^^^^^^^^^^^
   HTTP/2 server push)
   ^^^^^^^^^^^^^^^^^^

Thank you. 

Cheers,
Med

> De : Paul Hoffman [mailto:[email-masked]]
> Envoyé : lundi 30 mars 2020 19:24
> À : [email-masked]
> Cc : Barry Leiba; BOUCADAIR Mohamed TGI/OLN; Patrick McManus; Murray
> S. Kucherawy; Ben Schwartz; David Lawrence; RFC Editor
> Objet : Re: [Ext] [Technical Errata Reported] RFC8484 (6033)
> 
> I agree with Barry, even though I believe that what Mohamed is asking
> for could have been what the WG or the IETF wanted, had they seen this
> proposed change while the document was being developed. For example,
> when I read the proposed change, I thought "of course he's right about
> HTTP redirection"; however, I don't know if other people who are more
> literate about HTTP would agree.
> 
> "held for document update" normally indicates that the erratum is
> believed to be valid. We don't know that without going through WG Last
> Call and IETF Last Call again. Given how heavily this document was
> discussed before publication, I do not think it is appropriate to
> change it with an erratum.
> 
> I have not heard of any developer misunderstanding the current words
> in a way that would be fixed by this rewording. Further, the bit about
> HTTP redirection is a technical change (possibly an oversight, or
> possibly it was left out on purpose by those who understand it
> better).
> 
> --Paul Hoffman

---

From: Barry Leiba <[email-masked]>
Date: Tue, 31 Mar 2020 09:00:18 -0400

Just a process point:

> "held for document update" normally indicates that the erratum is believed to be valid.

Not really.  It is sometimes used when we know the errata report is
valid, such as when it's reporting a typo.  But it's also used when
the errata report does not meet the requirements for "Verified" but
merits discussion if and when the document is updated.  In that sense
it's used to "put a pin in it" for discussion later.  If we should
decide to go this way I would add a note that explains a bit of the
discussion and says that further discussion is needed, along with
rough consensus for any change.

Barry

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 31 Mar 2020 14:47:50 +0000

> I'm now more puzzled about the intent of the document with regards to redirection:

That's fine, and you are not alone. But the proper resolution of that puzzlement is not an erratum, it is a document update.

--Paul Hoffman

---

From: <[email-masked]>
Date: Tue, 31 Mar 2020 15:10:57 +0000

Paul, 

(1)

I went with an errata because I thought the document does not contain any internal inconsistency, but this discussion reveals there is one. While waiting for a document, I do think that at minimum we need a record for this. Tagging this errata as "held for document update" would be appropriate. 

(2)

What about this part of the errata:

* How a different URI can be discovered using server push? Can you please provide a flow example?

Thank you.

Cheers,
Med

> Envoyé : mardi 31 mars 2020 16:48
> Cc : [email-masked]; David Lawrence; Ben Schwartz; Patrick McManus;
> Murray S. Kucherawy; Barry Leiba; RFC Editor
> Objet : Re: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033)
> 
> That's fine, and you are not alone. But the proper resolution of that
> puzzlement is not an erratum, it is a document update.
> 
> --Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 31 Mar 2020 11:15:07 -0400

The purpose of this text is to reiterate that DNS records pushed from
untrusted and unrecognized sources must be discarded.

As Barry noted, the word "simply" is important here.  It is being used as a
synonym for "merely", i.e. there must be some other good reason to use the
record.  Following a redirect seems like a good reason!

On Tue, Mar 31, 2020 at 11:10 AM <[email-masked]> wrote:

> Paul,
>
> (1)
>
> I went with an errata because I thought the document does not contain any
> internal inconsistency, but this discussion reveals there is one. While
> waiting for a document, I do think that at minimum we need a record for
> this. Tagging this errata as "held for document update" would be
> appropriate.
>
> (2)
>