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, 2 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