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

Dave Lawrence <tale@dd.org> Fri, 08 June 2018 02:09 UTC

Return-Path: <tale@dd.org>
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 13D3F130E0D for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 19:09:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CJwmdNiQANvW for <doh@ietfa.amsl.com>; Thu, 7 Jun 2018 19:09:45 -0700 (PDT)
Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D5112F1A6 for <doh@ietf.org>; Thu, 7 Jun 2018 19:09:45 -0700 (PDT)
Received: by gro.dd.org (Postfix, from userid 102) id 3A8C829BCB; Thu, 7 Jun 2018 22:09:44 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <23321.58728.220321.285973@gro.dd.org>
Date: Thu, 7 Jun 2018 22:09:44 -0400
From: Dave Lawrence <tale@dd.org>
To: DoH WG <doh@ietf.org>
In-Reply-To: <527501e1-5a0e-fa58-9394-436daf88a77b@it.aoyama.ac.jp>
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> <527501e1-5a0e-fa58-9394-436daf88a77b@it.aoyama.ac.jp>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/skAtCcYL_973j6fRt6U7cyA5GEY>
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: Fri, 08 Jun 2018 02:09:46 -0000

Martin J. Dürst writes:
> So for a JSON message, there's not limit of 64K on the actual message 
> length. But there is (or should be) an *indirect* limitation that can 
> roughly be expressed as "a JSON message, when converted to a binary 
> format, has to fit into 64K".

If I understand correctly, you are saying that it is a better state of
affairs to require servers to be cognizant of the encoding size of one
media type when responding with another?  I'm having a hard time
seeing how this wouldn't mean having to at least sometimes do the work
of fully encoding it in the one before it can send it in the other.

Incidentally, this has raised another question in my mind.  In a
defined-limit world, what happens when some rogue DoH server generates
Content-Length > 64k?  Presumably well-behaved clients will be sanity
checking for the possibility of that.  In a Content-Length: unlimited
world you are still free to consider > 64k responses to have failed
until you get around to adapting your software.  It seems to me you're
no worse off for being forward-looking now.