Re: [Add] draft-btw-add-rfc8484-clarification (was RE: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033))

mohamed.boucadair@orange.com Fri, 17 April 2020 13:17 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDBA3A0863; Fri, 17 Apr 2020 06:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 j1Kq_G1MQiY3; Fri, 17 Apr 2020 06:17:56 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB033A085B; Fri, 17 Apr 2020 06:17:55 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 493c8f3kfzzCqq1; Fri, 17 Apr 2020 15:17:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1587129474; bh=NKZWVcyYLQVfogfVMkLkBn5YiFGys3b11EKOoxRyNrI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=e8dIbl3+itX8+OaXKe4FWrFbWKaJFaVrkvTOx1/uM8jZz45XAokn+Ax37vifr0RxZ gM10KDcEGVgCK8kHyFm/i0r98CPkNJ/TYFLqr7QbMV2Ivk0R0WVWq/ZZedQuwcDJED +mpprJfUMxX9c4aEZngQxFoj5qS+xWCO1nsJ9aEL5puNu1w5NppaAR1uZBIW9rNTU8 mEgYupOquM1SrmkdLGSHV3Y9GNI/sfGxe5ZNu9cAs7LUqgaktrrgzcd2S7q81si4iQ oUDjlqym3VDp/s42ZpPQmhjB/js3jYoiGcU80IgQrEjENJ3NhcruPHQdHApzj6lGV+ PsmwANa8uzyJw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 493c8f2x2Nz1xp6; Fri, 17 Apr 2020 15:17:54 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Ben Schwartz <bemasc@google.com>
CC: Paul Hoffman <paul.hoffman@icann.org>, "Murray S. Kucherawy" <superuser@gmail.com>, "doh@ietf.org" <doh@ietf.org>, "ADD Mailing list (add@ietf.org)" <add@ietf.org>, Barry Leiba <barryleiba@computer.org>
Thread-Topic: [Add] draft-btw-add-rfc8484-clarification (was RE: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033))
Thread-Index: AQHWD5dpk/sKBgVZCU+oagEvki87gqh9TrpQ
Date: Fri, 17 Apr 2020 13:17:50 +0000
Message-ID: <9ebcb06a-a4b8-486c-bd71-464e750a7cae@OPEXCAUBM24.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B93303149307D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAHbrMsB3M8DSyH_XTKHhH=a14aN-Gn8Lp3ry2vK__pp_RmwMFQ@mail.gmail.com>
In-Reply-To: <CAHbrMsB3M8DSyH_XTKHhH=a14aN-Gn8Lp3ry2vK__pp_RmwMFQ@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: multipart/alternative; boundary="_000_9ebcb06aa4b8486cbd71464e750a7caeOPEXCAUBM24corporateadr_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/JQHGd_orvqgWH3clmFeilmWK2EI>
Subject: Re: [Add] draft-btw-add-rfc8484-clarification (was RE: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033))
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Apr 2020 13:17:59 -0000

Hi Ben,

All good points. Thank you.

We updated the draft to take into account your comments and suggestions:


·         We moved the Server Push proposal to an appendix. We prefer to have there to illustrate how that kind of design is complex. We added some text to explain that.

·         We still maintain “MUST” for returning both A/AAAA in a redirect especially when the DoH service is available in another location. We maintain that language because Do53 may not be possible in some configurations (an example is provide in the draft). We may revisit the language as a function of how we solve the issue we discuss in Section 6.

·         We also updated Section 6 to discuss why Alt-Svc is not an option in some redirect scenarios. We also describe a proposal using GET to hopefully avoid some of the issues you raised.

·         We will send a note to httpbis and dnsop WGs for more feedback, but I do think that some aspects discussed in the draft belong to add as well.

The updated version is available at: https://tools.ietf.org/html/draft-btw-add-rfc8484-clarification-01

Comments and suggestions are more than welcome.

Cheers,
Med

De : Ben Schwartz [mailto:bemasc@google.com]
Envoyé : samedi 11 avril 2020 02:23
À : BOUCADAIR Mohamed TGI/OLN
Cc : Paul Hoffman; Murray S. Kucherawy; doh@ietf.org; ADD Mailing list (add@ietf.org); Barry Leiba
Objet : Re: [Add] draft-btw-add-rfc8484-clarification (was RE: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033))

On venue: ADD is not chartered for core protocol development work, and DoH is shutting down, so I think the correct venue is probably DNSOP.  However, you should also get input from HTTPBIS, where there is expertise on HTTP semantics.

On the draft:
* The draft introduces new MUST-level requirements, so I don't think it can reasonably be called a clarification.  Sending DNS records in a 3XX response body, for example, is a novel construction.

* I would remove the HTTP/2 PUSH version of the proposal, which seems more complicated without much benefit, and I would make the 3XX response body optional.  If the response body is absent, clients SHOULD resolve the target hostname in the same way that they resolved the original DoH server hostname, or fail if this is not possible.

* I think RFC 8484 is pretty clear on the main point in question: HTTP redirection applies in the usual way, whatever that might be.  Don't trust DoH URIs from strangers.

* In practice, redirection may have been given little attention because it doesn't necessarily give us the behavior we want.  For a GET request (where DoH encodes the query in the URI), a redirect only applies to that specific query.  A server that is trying to refer users to a different server would have to redirect each DoH GET individually -- not a recipe for good performance.  Permanent redirects for all those queries would also bloat the client's HTTP cache.  Alt-Svc, in contrast, would allow relocating the whole origin, which seems closer to the intended behavior.

For POST, all queries share a URI, so permanent redirects might work OK.  However, clients are permitted to convert POST to GET (dropping the body) when encountering a 302 redirect, so only a 308 will work.  However, as noted in RFC 7238:
   "initial use of status code 308 will be restricted to cases
   where the server has sufficient confidence in the client's
   understanding the new code"

Perhaps support for 308 is now sufficiently universal that DoH servers can safely rely on it, but I would recommend checking with HTTPBIS.

* Despite all these concerns, I'm glad to see interest in improving DoH, and I agree that a way to offer an updated DoH URI template would be nice.  If we can't find an elegant solution using redirects, we can find another way, e.g. an HTTP response header containing the new template.

On Fri, Apr 10, 2020 at 4:22 AM <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Hi Paul, Barry, all,

(+add wg as I guess the draft should be discussed there)

We prepared a document to clarify the redirection issue: https://datatracker.ietf.org/doc/draft-btw-add-rfc8484-clarification/

The document specifies also how redirection can be done in DoH.

Cheers,
Med

> -----Message d'origine-----
> De : Paul Hoffman [mailto:paul.hoffman@icann.org<mailto:paul.hoffman@icann.org>]
> Envoyé : mardi 31 mars 2020 16:48
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : doh@ietf.org<mailto:doh@ietf.org>; David Lawrence; Ben Schwartz; Patrick McManus;
> Murray S. Kucherawy; Barry Leiba; RFC Editor
> Objet : Re: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033)
>
> On Mar 31, 2020, at 2:03 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:
> > 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

--
Add mailing list
Add@ietf.org<mailto:Add@ietf.org>
https://www.ietf.org/mailman/listinfo/add