Re: [Doh] [Ext] DoH client-server interoperability vs. strict HTTP parameter checking

"Mark Delany" <d5e@xray.emu.st> Sun, 02 June 2019 12:17 UTC

Return-Path: <d5e@xray.emu.st>
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 0F0EF120100 for <doh@ietfa.amsl.com>; Sun, 2 Jun 2019 05:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st
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 53IzeuET6n51 for <doh@ietfa.amsl.com>; Sun, 2 Jun 2019 05:17:57 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id DFCD91200B6 for <doh@ietf.org>; Sun, 2 Jun 2019 05:17:56 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id 410C03B05C; Sun, 2 Jun 2019 22:17:54 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1559477874; bh=HApH4SVNa+F238bZvo6am9ImRPM=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=BaZQQTWAXZgH1u0eo4eF1Mj7KKp62hMUvHEBPgkFE9Z7sCCDWH2Y5UsKmnqgWPbH7 hcF5cuAPi8aAr5CSSF/xKYBriEiZk/KiK22ftSAiyvjXfPE6yj2LmvFbaMi0hY0Nyy +wUjIV1e2HI3HsRMB5jpjlFUb8psDPtuol70ZgaE=0ZgaE=
Comments: QMDA 0.3a
Received: (qmail 15406 invoked by uid 1001); 2 Jun 2019 12:17:54 -0000
Date: 2 Jun 2019 12:17:54 +0000
Message-ID: <20190602121754.15405.qmail@f3-external.bushwire.net>
From: "Mark Delany" <d5e@xray.emu.st>
To: doh@ietf.org
References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <F46C6B72-BD56-4C5C-9E10-26AC9B187102@icann.org> <20190601160830.10633.qmail@f3-external.bushwire.net> <20190602084956.GA26997@server.ds9a.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20190602084956.GA26997@server.ds9a.nl>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/PSOIHDxia6QMTImXJoRVFlc_c24>
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 12:17:58 -0000

> 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".

There are certainly pros and cons to this as well as many counter-examples.

Haven't we just spent the last decade trying to encourage things like caches,
forwarders and firewalls to accept and pass thru DNS RR types they don't
recognize?  After all, how would we ever extend DNS if every component rejected
every RR type and OPT sub-type it didn't understand?

I'm not sure I see the distinction between disallowing unexpected HTTP
parameters - as you recommend - and disallowing unexpected DNS parameters -
which I presume you don't recommend.

> 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.

I sympathize with the problem and like many here I too have been on the
receiving end of protocol implementations which were far too lax in what they
sent/accepted. But you're effectively recommending that DoH shouldn't use the
extension mechanisms built into HTTP. At that point you have to ask whether it's
even HTTP any more.

A related problem is that most DoH implementors probably rely on pre-existing
HTTP componentry rather than rolling their own from scratch. Said componetry is
notorious for adding headers without necessarily giving the application much
control over it. After all, it's worked fine for the last 20+ years, why stop
now? So at least on that front I think the horse has well and truly bolted.


I suppose one could go down the path of a DoH HTTP profile or version but most
internet protocols seem to shy away from the strictures of profiling and
versioning - perhaps because upgrades tend to turn into monumental events.


I don't think there's ever been a good solution to this dilemma: accepting
unknown parameters is a protocol risk yet accepting unknown parameters is also
the preferred mechanism for version interop.


Mark.