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

Paul Hoffman <paul.hoffman@icann.org> Mon, 11 June 2018 15:26 UTC

Return-Path: <paul.hoffman@icann.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 4EE0C130F3A for <doh@ietfa.amsl.com>; Mon, 11 Jun 2018 08:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level:
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 gAzZLowibPfp for <doh@ietfa.amsl.com>; Mon, 11 Jun 2018 08:26:03 -0700 (PDT)
Received: from out.west.pexch112.icann.org (unknown [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15311277BB for <doh@ietf.org>; Mon, 11 Jun 2018 08:26:03 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 11 Jun 2018 08:26:01 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Mon, 11 Jun 2018 08:26:01 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: DoH WG <doh@ietf.org>
Thread-Topic: [Ext] [Doh] Proposal to close off these threads
Thread-Index: AQHUAZiAoAyVQiyCOk6ZyfgEqlmFEg==
Date: Mon, 11 Jun 2018 15:26:00 +0000
Message-ID: <8E5D4626-6DB3-4168-87E8-717F2CA1DB5D@icann.org>
References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <23325.65421.902726.322697@gro.dd.org>
In-Reply-To: <23325.65421.902726.322697@gro.dd.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7AB3738071171942A7B574C724FFCD64@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/wa6DqjIWZ6n7txK-tms9emluenw>
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 15:26:07 -0000

Cherry-picking some places to respond to this...

> On Jun 10, 2018, at 9:50 PM, Dave Lawrence <tale@dd.org> wrote:
> 
> It's trying to address a legacy issue that hasn't been
> demonstrated

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.

> and instead introduces a new one.

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

> DoH is a new tool though that changes nothing at all that happens on
> DNS/UDP or DNS/TCP.  There is no good reason why legacy code should
> end up dealing accidentally with wire format messages larger than 64k
> because it doesn't have any standard way of getting them that isn't
> the result of new code.

Multiple developers on the list have talked about creating gateways. You are correct that there is no standard way to create a DNS transport gateway, but that's true of nearly every protocol gateway used across the Internet. The times that the IETF has tried to create standards for gateways have often ended up pretty terribly; ample data is available by looking in the archives of the MIXER and IPP WGs.

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

> Setting a limit on DoH, even constrained to one particular media type,
> creates a new legacy problem because if larger messages are eventually
> deemed acceptable then you'll have an installed base that all wrote in
> a limit per this standard.  I posit that even despite Paul's attempt to
> make more clear the media type versus the substrate, the chances that
> the limit is incorrectly associated as a property of https versus a
> property of the media type are high.

Developers of other data formats have successfully dealt with differing media types for 25 years. If the DNS folks screw this up worse than everyone else, well, there is nothing we can do about that. I would prefer to think that we can learn from them.

> We already expect a new media type, JSON, that will not have natively
> have any sense of the size of a DNS wire format encoding by which to
> adjudge the propriety of its own encoding.

No, we absolutely do not expect a JSON format that has the same capabilities of the wire format. I have tried repeatedly for many years to get interest in standardizing one, and there was a complete lack of interest in anything other than a small subset of DNS messaging. This is well-documented in the DNSOP WG archives.

>  Are we going to hamstring
> that 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.

--Paul Hoffman