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

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 30 March 2020 15:53 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6283A17A5 for <doh@ietfa.amsl.com>; Mon, 30 Mar 2020 08:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hjf_gFS5eJOM for <doh@ietfa.amsl.com>; Mon, 30 Mar 2020 08:53:06 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94873A17AE for <doh@ietf.org>; Mon, 30 Mar 2020 08:53:06 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 45AD8F4074B; Mon, 30 Mar 2020 08:53:04 -0700 (PDT)
To: paul.hoffman@icann.org, mcmanus@ducksong.com, superuser@gmail.com, barryleiba@computer.org, bemasc@google.com, tale@dd.org
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: mohamed.boucaadir@orange.com, doh@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200330155304.45AD8F4074B@rfc-editor.org>
Date: Mon, 30 Mar 2020 08:53:04 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/0h5vlHLklOmbd5hfMDuZgJcNDOo>
Subject: [Doh] [Technical Errata Reported] RFC8484 (6033)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2020 15:53:09 -0000

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 <mohamed.boucaadir@orange.com>

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