Re: [Doh] [Ext] DoH client-server interoperability vs. strict HTTP parameter checking
bert hubert <bert.hubert@powerdns.com> Sun, 02 June 2019 08:50 UTC
Return-Path: <bert@hubertnet.nl>
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 D399F1200B9 for <doh@ietfa.amsl.com>; Sun, 2 Jun 2019 01:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 TQA198ztBczF for <doh@ietfa.amsl.com>; Sun, 2 Jun 2019 01:50:01 -0700 (PDT)
Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138EC120025 for <doh@ietf.org>; Sun, 2 Jun 2019 01:50:00 -0700 (PDT)
Received: from server.ds9a.nl (ip565244ed.adsl-surfen.hetnet.nl [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 1E1E7A2E33; Sun, 2 Jun 2019 08:49:56 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id 84724AD243D; Sun, 2 Jun 2019 10:49:56 +0200 (CEST)
Date: Sun, 02 Jun 2019 10:49:56 +0200
From: bert hubert <bert.hubert@powerdns.com>
To: Mark Delany <d5e@xray.emu.st>
Cc: doh@ietf.org
Message-ID: <20190602084956.GA26997@server.ds9a.nl>
References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <F46C6B72-BD56-4C5C-9E10-26AC9B187102@icann.org> <20190601160830.10633.qmail@f3-external.bushwire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190601160830.10633.qmail@f3-external.bushwire.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/sjZrulC9Ldy65iVLs0NllWFVL4I>
Subject: Re: [Doh] [Ext] DoH client-server interoperability vs. strict HTTP parameter checking
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: Sun, 02 Jun 2019 08:50:03 -0000
On Sat, Jun 01, 2019 at 04:08:30PM +0000, Mark Delany wrote: > Surely a server has to expect that it will eventually be talking to a > client from the future which will, by definition, be adding unknowable > parameters. And in the DNS world we've often let clients know we don't get their newfangled speak (FORMERR). Silently ignoring unexpected parameters is a great way to proliferate half-working configurations. "Did parentalcontrol=0&malwarefilter=1 get accepted or not? I have no idea". Secondly, the accepting nature of most HTTP services has created reams of tracking possibilities, viz utm_source and fbclid which now get tacked on at random and track you even if you copy paste the URL to someone. So in short, I would not go out and recommend that servers simply ignore unknown parameters. They might accidentally do it but it fosters bad things like silent errors & even more tracking than cookies, TLS resumption tickets and HTTPS agent headers already bring. Bert
- [Doh] DoH client-server interoperability vs. stri… Christoph
- Re: [Doh] [Ext] DoH client-server interoperabilit… Paul Hoffman
- Re: [Doh] [Ext] DoH client-server interoperabilit… Mark Delany
- Re: [Doh] [Ext] DoH client-server interoperabilit… Christoph
- Re: [Doh] DoH client-server interoperability vs. … Patrick McManus
- Re: [Doh] [Ext] DoH client-server interoperabilit… bert hubert
- Re: [Doh] [Ext] DoH client-server interoperabilit… Mark Delany
- Re: [Doh] [Ext] DoH client-server interoperabilit… Joe Abley
- [Doh] signalling client expectations and server c… Jim Reid
- Re: [Doh] signalling client expectations and serv… Mark Delany
- Re: [Doh] DoH client-server interoperability vs. … Vladimír Čunát
- Re: [Doh] DoH client-server interoperability vs. … Joe Abley
- Re: [Doh] DoH client-server interoperability vs. … Patrick McManus