Re: [dns-privacy] Review request: draft-btw-dprive-rfc8484-clarification

Martin Thomson <mt@lowentropy.net> Mon, 31 August 2020 06:51 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E673A0FD3 for <dns-privacy@ietfa.amsl.com>; Sun, 30 Aug 2020 23:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=RN3kz9cb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tfMp6QP1
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 15M_2DBnSIgu for <dns-privacy@ietfa.amsl.com>; Sun, 30 Aug 2020 23:51:06 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160C03A0FCF for <dns-privacy@ietf.org>; Sun, 30 Aug 2020 23:51:06 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6A0DE5C00FF for <dns-privacy@ietf.org>; Mon, 31 Aug 2020 02:51:05 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Mon, 31 Aug 2020 02:51:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=jr/MuKpcr9lldXqTxqqwcNN00n4yN7B Sle7LsNGsNzs=; b=RN3kz9cbXO989jXoGQ3YnyNnF7hYmfEmN+OuZlf3wwB0pRK koxlgTeMgJfUM+6niG4LnMITL+TNMJLnKaYMhzgeUpGDKuBFoPd0EKE1iqDJL+i1 tag8Q78uCjv4pkZv+0RoKeV32lKQDZBRi6yyYTKM9Kj6DaRBDbvLGuQKDLxc3JOY 2acil9gWge7x/rniSDFTH/X9lb3cCTySB2Q31EkLz58B75wwCNzEFVLchMLyo4xR +vanT92bNPIPT6ZB76i75TW38eU56wKAkDpSKUlbXCMiWlbk+9YIRL3O82XdOS4q y9mGoHORob2OGHEW9gWyWVoRmQz7rmqr9g/i5AA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=jr/MuK pcr9lldXqTxqqwcNN00n4yN7BSle7LsNGsNzs=; b=tfMp6QP1LBbu20ikz2dPjg VZWiN56JzDdhz8TW0yghwSmDL1HezfstxfMe2zJUN0tNtkVwDwqRwdnBsBorjT09 6OORVeMj+kT2d514yPp3aO8sxJ7HhtHERA/1Uqh5pQbJwswPswwlanbfzCOYjB/O XCfbSgisb8LBHRW+koTULXJWnGzDDyGYEeaH4dLpZUMhlkv8fhlWLecv9jz6IS1O uZgjkKoVHevWHgBlK00cVWpB/eHwHYcZnpDm2gDKpVhQgYlQjzOVZDzUId6DSMqF Kmbd574VTYNCp1NrZiKps9mxe7yNvXvOfQuS4Rn3lbbTecMgqE1ajm0n22qBL/Tg ==
X-ME-Sender: <xms:2Z1MX88ySWLbYXyQpuXC74VRB2sdcRxZlBz7u0SugbVl02qImVapkw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudefgedguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepheefteduudduhedtke fhvdfhteelffdujeegjeffheffveekudeigfeuveekfeelnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth
X-ME-Proxy: <xmx:2Z1MX0u4mj0_Nb3fOPMgPZXc18oYjcLAaTUdIC49V8wtW_vRaz4PCA> <xmx:2Z1MXyAy-CKhvc6dSupzA1o3DI_zP_CTpRkWnVmOnMRypNbW3kaJaQ> <xmx:2Z1MX8eDGRsesfMX-5CphlJpPnW3gFkiLKyBNUJSgZ1nb-rkWN3NVA> <xmx:2Z1MX_tD-XbDriYzc_Hw5IBvhNCaWsav3QP74xs4GbYLfYUgM4tzbg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 14C5B20064; Mon, 31 Aug 2020 02:51:05 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-232-g4bdb081-fm-20200825.002-g4bdb081a
Mime-Version: 1.0
Message-Id: <d05268fc-e22d-40f7-9849-00409c59f328@www.fastmail.com>
In-Reply-To: <CAHbrMsB7T+5Y=2n4LfcXwyAZQSnK4x72R44_2mCDsLhh_zD9Vw@mail.gmail.com>
References: <6e071da2-4281-d525-03ba-4d6dfc843a76@innovationslab.net> <CAHbrMsB7T+5Y=2n4LfcXwyAZQSnK4x72R44_2mCDsLhh_zD9Vw@mail.gmail.com>
Date: Mon, 31 Aug 2020 16:50:09 +1000
From: Martin Thomson <mt@lowentropy.net>
To: dns-privacy@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/YpMg1_zm4woX2-YKK2t8yveLM2w>
Subject: Re: [dns-privacy] Review request: draft-btw-dprive-rfc8484-clarification
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2020 06:51:15 -0000

I agree with Ben on all points (*) and would prefer to see none of the proposed amendments published.

(*) I think that the push qualification is not necessary, but it is not as clearly a misunderstanding as Ben suggests.  It clearly limits this to configured URIs, which seems in line with original intent.  However, it likely denies access to server push in several cases, including after redirects.

On Sat, Aug 29, 2020, at 00:41, Ben Schwartz wrote:
[...]
> The ".well-known" proposal (Section 6) does what RFC 8484 avoided 
> doing: it proposes an alternative encoding of DNS records in JSON.

I would suggest that authors join the "resolver info" beauty contest.  The use of .well-known rather than (for example) a link relation is clearly inferior for the reasons Ben mentions.  But I tend to think that resource records are more appropriate for this particular application, as they work in more cases.

> The 3XX proposal (Section 7) sends DNS records in the body of a 3XX 
> response.

A client that doesn't follow a redirect isn't much use, so the question for me is whether the client gets the extra info it needs.  It seems to me like clients will follow the redirect and discard any content.  That would lead to the extra stuff being dropped.  I would expect a DoH client to make a separate query if it needed more information to follow the redirect.

A superior design would be to push necessary A/AAAA/CNAME records.  If the client makes a query that ends up at the pushed URI, then this will save time without having to invent novel handling for HTTP messages.