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

mohamed.boucadair@orange.com Tue, 31 March 2020 07:23 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 9490D3A0EBE for <doh@ietfa.amsl.com>; Tue, 31 Mar 2020 00:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 dk-kXeC2DbLk for <doh@ietfa.amsl.com>; Tue, 31 Mar 2020 00:23:28 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9210D3A0EC2 for <doh@ietf.org>; Tue, 31 Mar 2020 00:23:27 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 48s15T3S0lz4xLs; Tue, 31 Mar 2020 09:23:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1585639405; bh=9knMY6YqOCT6hiIMlKfzcqcmBn3moGBmA0xlzBzkgLY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IPMtBtgGOQqFxZjzdfy3Se8KXx12B7Y8rboYNjQKdkpBDToseN3Ml/ErabXGYAugG 9lYNuMujbd9yugdRgmWrQ361b5uVBVGRTj6Ydsf74ziEbQZ3uL6Ghc5yvMoDr/ok+9 tXOgoRURsWTzuoHB7gGcsrg5415wLer4KWCYR8+xtua9i3Y6FtwdwloJmU9Ufw1gOL zddMEpAIZqgKCxS8ipGrnPVYzqwMclyOn8HJ7uU3v/jxXBIZVNRlvI/9xFhezQk77r sNygmhp59P9uKmqnl4bPcvN2aAfkZpC19VHnS+/n9f5f/kb3sLPNaRrKXoyzuVH3Fc uz2ugAwI53gJg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 48s15T10Jxz8sY1; Tue, 31 Mar 2020 09:23:25 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Barry Leiba <barryleiba@computer.org>
CC: Paul Hoffman <paul.hoffman@icann.org>, Patrick McManus <mcmanus@ducksong.com>, Murray Kucherawy <superuser@gmail.com>, Ben Schwartz <bemasc@google.com>, Dave Lawrence <tale@dd.org>, "doh@ietf.org" <doh@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Thread-Topic: [Technical Errata Reported] RFC8484 (6033)
Thread-Index: AQHWBrHijv0n0q7vHE2JDapm+5eGMahiN48g
Date: Tue, 31 Mar 2020 07:23:23 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933031489480@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <20200330155304.45AD8F4074B@rfc-editor.org> <CALaySJJ3dAEebgyz==PoSqnhSzFiHcxh0kmynRYBcD6Vjvm+6w@mail.gmail.com> <CALaySJK-FNqt-uHOz6oqANj8Xpwt7BOQkO6Ut-iAZ_OY-arO5Q@mail.gmail.com>
In-Reply-To: <CALaySJK-FNqt-uHOz6oqANj8Xpwt7BOQkO6Ut-iAZ_OY-arO5Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/P3TQZl_6x3ZdOV1sOoeHSjNdo4s>
Subject: Re: [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: Tue, 31 Mar 2020 07:23:31 -0000

Hi Barry,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Barry Leiba [mailto:barryleiba@computer.org]
> Envoyé : lundi 30 mars 2020 18:40
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Paul Hoffman; Patrick McManus; Murray Kucherawy; Ben Schwartz;
> Dave Lawrence; doh@ietf.org; 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 <barryleiba@computer.org>
> 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
> > <rfc-editor@rfc-editor.org> 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 <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