Re: [Doh] [Ext] Proposal to close off these threads

Dave Lawrence <tale@dd.org> Mon, 11 June 2018 16:42 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 DC335131036 for <doh@ietfa.amsl.com>; Mon, 11 Jun 2018 09:42:03 -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 WDgkVg5jZzm1 for <doh@ietfa.amsl.com>; Mon, 11 Jun 2018 09:42:02 -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 0549D1310CC for <doh@ietf.org>; Mon, 11 Jun 2018 09:42:01 -0700 (PDT)
Received: by gro.dd.org (Postfix, from userid 102) id 4359C32885; Mon, 11 Jun 2018 12:42:00 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23326.42584.259069.537631@gro.dd.org>
Date: Mon, 11 Jun 2018 12:42:00 -0400
From: Dave Lawrence <tale@dd.org>
To: DoH WG <doh@ietf.org>
In-Reply-To: <8E5D4626-6DB3-4168-87E8-717F2CA1DB5D@icann.org>
References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <23325.65421.902726.322697@gro.dd.org> <8E5D4626-6DB3-4168-87E8-717F2CA1DB5D@icann.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/viSq4RkrpsRJfxHE-CcWvQjIwPE>
Subject: Re: [Doh] [Ext] Proposal to close off these threads
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: Mon, 11 Jun 2018 16:42:11 -0000

Paul Hoffman writes:
> This feels dismissive of the other developers in the WG who said
> that they do see the issue in the code they are writing. You might
> not see it in the code you are writing, but that doesn't mean it
> hasn't been seen.

I'm not being dismissive of them.  I am observing that I haven't seen
a description of a real problem that they have where a message larger
than 64k is getting into existing software that isn't a result of new
code being written, code which can trivially check to make sure there
isn't a problem.

I am really quite okay with being corrected on this point, being shown
a real, practical problem that exists that is solved by insisting on a
limit for all implementations.  I am also really quite okay with being
gently reminded that such an example has already been provided, so
that I can have the opportunity to evaluate it.

> It does not introduce a legacy issue: it introduces a restriction
> for a completely new media type. 

I described further down in my message how this creates a new legacy
issue, but causing new code to be written with the unnecessary limit
and further solidifying the notion that this maximum length is an
immutable characteristic of DNS messages.  My contention is that even
though you're trying to attach it to a specific media type, if that
media type is the one-and-only media type that starts off being
defined for DoH it will be very easy to programmers to confuse it as
an attribute of the transport rather than an attribute of only one
media type, leading to deployment problems in the future.

> > A message greater than 64k wouldn't be representable on DNS/UDP or
> > DNS/TCP?  This is an issue that goes back the founding of the DNS;
> > there's always been the potential for a message to only be fully
> > available on one transport.  Not a new problem.
> 
> Yes, it is. There were two transports defined with no explicit
> provision for more. This WG has created a new problem. 

I really don't get how this remark is in disagreement with my
assertion.  You're disputing that the UDP/TCP DNS already has
situations where some messages can only be representable on one (TCP)
transport?  That's what my remarks were about, that philosophically
this is not a new concept and not a technical reason to claim that
messages over 64k should be verboten.

> >  Are we going to hamstring [JSON] too?  If not, why not?
> 
> Because, if it exists, it will be an new media type. Each media type
> has its own rules. There is nothing in current DOH spec that limits
> what a media type can do. 

I agree with you on that last bit, but it shoots right past the point.
If JSON is going to be allowed to carry DNS data that would ultimately
represent DNS wire format messages in excess of 64k, then why should
an explicitly DNS wire format media type be unnecessarily constrained?
I need to use an even more voluminous media type in order to get the
large messages that I want?