Re: [Doh] signalling client expectations and server capabilities

"Mark Delany" <d5e@xray.emu.st> Sun, 02 June 2019 20:57 UTC

Return-Path: <d5e@xray.emu.st>
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 B6B491200F5 for <doh@ietfa.amsl.com>; Sun, 2 Jun 2019 13:57:40 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st
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 wdmOjoFS5dp6 for <doh@ietfa.amsl.com>; Sun, 2 Jun 2019 13:57:39 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id DFD9012004E for <doh@ietf.org>; Sun, 2 Jun 2019 13:57:38 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id CD4933B05C; Mon, 3 Jun 2019 06:57:35 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1559509055; bh=2hDS0esy/D1gSwvjc+2tyG3tJLM=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=M94hGQhNSzLZe/j5KXAOWRzWdo2GMa/R6Mxglrna5RK583l2OJfd2mfYflly5o7RX K/kSLK3DXfrEJq5qXyPWd+No6txt0SU22ya+vDOnvIl1+mc9bsNqUh18cW+RKixZxE eF+gmsIvw5PQfddDnU400XKU/JPAF5NtYWmo07Xo=o07Xo=
Comments: QMDA 0.3a
Received: (qmail 17700 invoked by uid 1001); 2 Jun 2019 20:57:35 -0000
Date: 2 Jun 2019 20:57:35 +0000
Message-ID: <20190602205735.17699.qmail@f3-external.bushwire.net>
From: "Mark Delany" <d5e@xray.emu.st>
To: doh@ietf.org
References: <770d0bf0-0a93-4d9a-4cb1-1f1e44c584aa@appliedprivacy.net> <F46C6B72-BD56-4C5C-9E10-26AC9B187102@icann.org> <20190601160830.10633.qmail@f3-external.bushwire.net> <20190602084956.GA26997@server.ds9a.nl> <20190602121754.15405.qmail@f3-external.bushwire.net> <D857B391-A414-4681-9AC2-72D82301ACE6@hopcount.ca> <C954F5BA-0B74-4D6F-9395-B537EFCC7CF8@rfc1035.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <C954F5BA-0B74-4D6F-9395-B537EFCC7CF8@rfc1035.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/za6vAOtf59hfxaieuLUJNl_jC8g>
Subject: Re: [Doh] signalling client expectations and server capabilities
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 02 Jun 2019 20:57:41 -0000

On 02Jun19, Jim Reid allegedly wrote:
> 
> 
> > On 2 Jun 2019, at 16:54, Joe Abley <jabley@hopcount.ca>; wrote:
> > 
> > In the very general sense (ignoring protocol specifics relating to the DNS and HTTP) it feels like it might be handy to be able to specify a capabilities requirement with a query. Something like
> > 
> >  - I want an answer to the question PIR.ORG/IN/SOA with RD=1
> >  - I want query minimisation and secure transport for recursive queries
> >  - I want you to confirm explicitly that you understand the request for query minimisation

Yes, I had thought about mentioning capabilities but I doubted anyone would have
read below the fold of my email :-)

One thing I wondered about is how well capabilities work in a multi-hop and
multi-transport system that has DoH in the path. In the very general sense
should a stub resolver asking for capabilities have said query punch all the way
through to an auth server?

There is already a smattering of adhoc capability signals in DNS such as TC=1
and maximum response size which probably should have received some attention in
8484 so if nothing else maybe formalization will at least raise the question for
future protocol designers: "how do we deal with capabilities?".


> Hmmm. The add list might be a more appropriate place to discuss this. Or maybe dnsop. It???s not clear if these sorts of capabilities could/should be signalled in DoH or vanilla DNS.

It's certainly a big topic and probably risks the second-system syndrome.


Mark.