Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size)

Mukund Sivaraman <muks@mukund.org> Wed, 13 June 2018 19:20 UTC

Return-Path: <muks@mukund.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 5697612426A for <doh@ietfa.amsl.com>; Wed, 13 Jun 2018 12:20:44 -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 hmGoiK0WN3a9 for <doh@ietfa.amsl.com>; Wed, 13 Jun 2018 12:20:42 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id E737F130E8A for <doh@ietf.org>; Wed, 13 Jun 2018 12:20:41 -0700 (PDT)
Received: from jurassic (unknown [14.194.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 5E54532C0972; Wed, 13 Jun 2018 19:20:36 +0000 (UTC)
Date: Thu, 14 Jun 2018 00:50:30 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: petr.spacek@nic.cz, DoH WG <doh@ietf.org>
Message-ID: <20180613192030.GA2792@jurassic>
References: <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <CAHbrMsBoKE-pfz97ZDb9ReLKMedk2KJ7xLCw_MPmxVtqF7PcuA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHbrMsBoKE-pfz97ZDb9ReLKMedk2KJ7xLCw_MPmxVtqF7PcuA@mail.gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/HsG1COK8HOcOzo32DGHh6dxmOrw>
Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: 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: Wed, 13 Jun 2018 19:20:45 -0000

On Wed, Jun 13, 2018 at 02:16:11PM -0400, Ben Schwartz wrote:
> > I think Ray was too shy to ask The Question:
> >
> > Is the goal of the current doh WG
> >
> > a) "standardize encodings for DNS queries and responses
> > that are suitable for use in HTTPS. This will enable the domain name
> > system to function over certain paths where existing DNS methods (UDP,
> > TLS [RFC 7857], and DTLS [RFC 8094]) experience problems." in an
> > interoperable way, i.e. doing a thing the WG was chartered to do?
> >
> > OR
> >
> > b) Invent DNS 2.0 and attempt to hide that the proposal goes beyond the
> > original DNS protocol? We badly need DNS 2.0 so let's admit that, it is
> > not a shame.
> >
> 
> I appreciate your concern but please try to avoid accusing members of the
> working group of trying to hide anything.

It's a valid question that has been asked. Many of us are concerned
about things are being said and it's best to discuss them freely without
taking offense.

This is from Tale's post:

> There are already indications from people who want to leverage it to
> provide DNS response delivery without involving the traditional
> resolution path.  Some of them stated quite clearly at the first DoH
> BoF that they really weren't even interested in working on it if it
> was just going to be merely a tunneling protocol.
> 
> It isn't clear to me how you could meaningfully restrict it from being
> a "'first class' transport".  Fiat declaration sure wouldn't do it.

This may well fit in within current DoH charter or may not, depending on
how "existing DNS methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094])
experience problems" from the charter is interpreted.

Is this a replacement for traditional DNS? (there's no need to take
offense at this question.. please let's just discuss it.)

The 64kB limit is just one aspect (we've been asked for proof of
problems - it has been explained already that DNS message parsers do it
in memory currently - 64kB imposes an implicit upper limit on the
derived objects in in-memory message structures (lists of names + RDATA
objects).  E.g., a 32-bit limit would mean the possibility of requiring
to hold 4GB wire data in memory and the larger derived structs from
parsing it, or, reimplementing message parsing with disk storage. (Think
of sax vs. DOM XML parsing for an analogy.)

> The question of what message size limits to require or recommend does not
> resemble an attempt at any kind of "DNS 2.0".  Note that message size
> interoperability questions are not a new issue within the DNS: many
> endpoints will reject messages larger than 4K or 8K, even though there is
> no way to signal this limitation.  HTTP has similar issues (e.g. URL length
> limits).

Implementators are concerned because this 64kB limit has been assumed
forever now and various parts of code aren't written or even designed to
handle larger sizes. I don't know how you mean by "endpoints will reject
messages larger than 4k".. I think any of the popular open source DNS
nameservers will parse 64kB messages over TCP (though some may not
generate > 16kB messages as name compression pointers have a limit of
16kB from the start).

> The charter does not require that the standard guarantee functionality in
> all possible use cases and multi-system interactions, and both choices (to
> apply a limit or not) fail to serve a desirable use case: either we don't
> support 100% reliable gateways from DoH into DNS-over-TCP, or we don't
> support large zone transfers over DoH.  It's up to the working group to
> balance these concerns, either by choosing one option or by finding a
> middle ground.

The charter says:

"The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS clients (e.g.,
operating system stub resolvers) and recursive resolvers."

and

"Specification of how DNS-formatted data may be used for use cases
beyond normal DNS queries is out of scope for the working group."

and we're talking about zone transfers. Zone transfers are not DNS
queries. So what's the limit of this charter?

Large zone transfers are supported today using TCP continuation messages
and the same can be encoded by DoH within the 64kB message limit. FWIW,
even we don't use larger than 16kB messages for zone transfers in
traditional DNS because it doesn't compress well, though there is a 64kB
budget.

If DoH is purely an encoding transport to carry traditional DNS
messages, then there will be a problem with larger than 64kB messages
from:

(1) tradtional NS -> (2) trad:DoH intermediate using 1MB messages -> (3) DoH client

and:

(1) DoH NS using 1MB messages -> (2) DoH/trad intermediate -> (3) traditional client

because TSIG will not validate if only (1) has the secret to generate
them and (2) is just a forwarder.

A person like me is wondering about these things, because I don't know
what's the limit for DoH - how all it will be used, because of
everything that's being discussed. It appears that DoH will not be
restricted, so before rushing to update things, please discuss
traditional DNS's concerns, and also discuss what's within scope in the
charter.

As an exercise, it'd be good to read about several practial usage
patterns in which DoH may be used.

		Mukund