Re: [Doh] [Ext] DNS Camel thoughts: TC and message size

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 07 June 2018 21:48 UTC

Return-Path: <ajs@anvilwalrusden.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 C3719130DD4 for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 14:48:16 -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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Y1MJs++V; dkim=pass (1024-bit key) header.d=yitter.info header.b=eWdY/F84
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 DhV89X4TeTFR for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 14:48:12 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DAD130DD1 for <doh@ietf.org>; Thu, 7 Jun 2018 14:48:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 17279BDEF9 for <doh@ietf.org>; Thu, 7 Jun 2018 21:47:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528408061; bh=HrICC6qIQYCqUv3fAZ3XVyEKqnMSbXkbwYyYPi643P8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Y1MJs++VWlvJHB2c0x3I/qCvtxmwPrzYWjdxBu6gDa67brCVjO8uIcdyHbcVHSFrw oBcAi0S2rZaP81bNYEGJGqTBvlnRRANGtA41ij6RJQeno9RjESb3jfCnnZbFuMsfNY XdEJs1JRRmbx4cBGxTwgftbibXjWgwSrpgvq9FbA=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y46rbYgOd8nq for <doh@ietf.org>; Thu, 7 Jun 2018 21:47:40 +0000 (UTC)
Date: Thu, 07 Jun 2018 17:47:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528408059; bh=HrICC6qIQYCqUv3fAZ3XVyEKqnMSbXkbwYyYPi643P8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=eWdY/F84U/zZp5DkoB1vxNrWPDT1yZJSBanNUYD6tur1ICY5Y1hIvWVN4brg3Zo4F T+U78azAufsy6ns+hTBOpSmcQCGZrDEdeLW2vVWngNqsSQ1qL4WrUM334pjCDIRdqr jJe4UpMoaLAQ85tQbh4Dzsw0Ld/fZIfC8Ey9p3AU=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: doh@ietf.org
Message-ID: <20180607214737.GP11227@mx4.yitter.info>
References: <20180606093212.GA23880@server.ds9a.nl> <alpine.DEB.2.11.1806061501340.10764@grey.csi.cam.ac.uk> <F5774061-35B9-477F-ADDA-8BB3472F30EF@icann.org> <CAOdDvNq9g3ghbg9fkfhP+ZA4-6E5oDNFCGo6NN9bydqUX76cLA@mail.gmail.com> <20180607093647.GB32326@server.ds9a.nl> <CAOdDvNriZDjU9yqUQjqN4fO84ENPWO3si-QePiKRgt+7VJVK0g@mail.gmail.com> <23321.27027.73356.94056@gro.dd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <23321.27027.73356.94056@gro.dd.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/mLZESyAxZDE4suQvEp2B6luYEg0>
Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 07 Jun 2018 21:48:17 -0000

On Thu, Jun 07, 2018 at 01:21:23PM -0400, Dave Lawrence wrote:
> 
> "Sort of".  Wire format itself does not have the limitation.  Its use
> on certain transports does.  This distinction needs to keep being
> made.

That sounds like a foot-gun loaded for bear, to me.  Wire format on
every transport so far has this limitation.  Even if you break that
limitation (and I'm still not fully convinced you can), the mere fact
that this is called the "wire format" will lead people to expect that
they can pop in the very same parsing code they already use for the
"traditional" wire format, and it'll work fine.  So, if the document
is not going to set the limit in concrete, it had better have a Big
Giant Warning section that points out that a completely reasonable
assumption is not true and that the competent implementer will have to
do a bunch of additional work to be safe in a corner condition that is
incredibly rare right now.

What will actually happen, of course, is that some programmer will
say, "Aw, nobody's going to do that," fail to check the bounds
carefully, and create some festering large problem somewhere down the
road.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com