Re: [Doh] Authoritative DoT or DoH

"Martin Thomson" <mt@lowentropy.net> Fri, 15 March 2019 02:27 UTC

Return-Path: <mt@lowentropy.net>
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 C2A5312782C for <doh@ietfa.amsl.com>; Thu, 14 Mar 2019 19:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=MaPu2j5l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Cm1q97C3
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 X-_MDFM-y5PI for <doh@ietfa.amsl.com>; Thu, 14 Mar 2019 19:27:40 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CD11277D9 for <doh@ietf.org>; Thu, 14 Mar 2019 19:27:39 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E1C0721EAD for <doh@ietf.org>; Thu, 14 Mar 2019 22:27:38 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 14 Mar 2019 22:27:38 -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=fm1; bh=7brwWLCCtn3em6Vt5Vt0MvnW9DtgNAX hypLAYzmurr4=; b=MaPu2j5ltUCBoSxtLE2XJy9i7xm435Zm4Xnoaa1a1RoVruC vWOg2TRYy3jsm7wRjAjefk3Ro2ZeXSHfzPRTJRdbiumQ7w4westp6KjpeArP2pxz cHP11Z8eF7xtNKSbYl9lmr2a1edgLWcHt1fblsQzPPz+mzPjysSPu6rFf2xz6PCA 5Mfikb4+hsdhWxIwpEClIUxmssXn+S1O+DyACcNRiTcaJij3QycPZtK/VlrwAhHj g2+m2WPD0YbcDpZNOSVRCN+sZRGJ6GrtG9rPtMqyUxhLUFbZaHc5KqHnMYP2yNVi Gd722ddYjqCGHxfn9+iDLOIl+3NB9CUA6ksBQFw==
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=fm2; bh=7brwWL CCtn3em6Vt5Vt0MvnW9DtgNAXhypLAYzmurr4=; b=Cm1q97C3fin9CIc8SheTHr v5Qeol2RMxO1gwVQt55cG3+A4bJNzmFOy4sEvXm5DMCe4fvw6YwvR/ljs3f//G9H xq5jxsFAeIUyn14lRSkCTZGH9aO/yeCplqapbJHyo1c+zLLJz0ztbraSmR/u1m82 VhMYBeM7o2sJH16qJ/jenPbvyWRejQjaejTmIOjWNil34UXCbNgsnM0WPE4JkpSQ fomfyBTcbCJlxyE/vgzhQ0RyNpeFJQemcEPYaWUIMFRn8O2NuhmA4Yu5MYGGMUU2 4YUmLaSQ4CKwO6keYcFVlZN/iuWRBqh0rtBeT/O5JOv8qgPXDHjiLog5wIbYswGg ==
X-ME-Sender: <xms:mg2LXB4zI-CBXMBLELD4GCrQllHxHcNkDJEr9xtQOHWVs45rCDO9ng>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrheeggddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt
X-ME-Proxy: <xmx:mg2LXKyKdilTdCB5IiAf-XWzSmx_-4rxK2WG_tpgOuKfpkOF01OIPg> <xmx:mg2LXFeuavZVHRfm3nhaJw9ID9ETBAvxdZ3JjVwqFkSqTmJe7XDyoQ> <xmx:mg2LXPDPc6tPiCP8XdDDLPG6hCkJjChHW7p5YtlPUtviSMctub9J0w> <xmx:mg2LXIlBQKlN4pHazVMNieLfRkGYyF5mCFVJTApEMNncqEQf_2yxTw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5D7A27C5FB; Thu, 14 Mar 2019 22:27:38 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-976-g376b1f3-fmstable-20190314v3
Mime-Version: 1.0
X-Me-Personality: 92534000
Message-Id: <73eb005a-da34-41cb-a05d-1cb8268060d2@www.fastmail.com>
In-Reply-To: <C8284F2D-F46A-484E-A145-99C0D8ADBC58@verisign.com>
References: <C8284F2D-F46A-484E-A145-99C0D8ADBC58@verisign.com>
Date: Thu, 14 Mar 2019 22:27:39 -0400
From: Martin Thomson <mt@lowentropy.net>
To: doh@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/6tJNorpV-7tZbfLr0GmHuwVPlno>
Subject: Re: [Doh] Authoritative DoT or DoH
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: Fri, 15 Mar 2019 02:27:42 -0000

There is far less reason to use DoH for connections to authoritative servers.  DoT seems far more appropriate (than both DoH and the unencrypted variants).

I expect there to be a lot of discussion about DoS (not DNS over SCTP, sadly) and load management in any such document.  I don't see much of the stuff that has generated so much heat lately to be relevant in the authoritative context.

On Fri, Mar 15, 2019, at 06:18, Henderson, Karl wrote:
>  
> In the last couple of days there has been a lot of activity concerning 
> DNS over HTTPS (DoH) - Hoffman and Alibaba presentations at ICANN and 
> IETF drafts: 
> draft-reid-doh-operator/draft-livingood-doh-implementation-risks-issues/draft-betola-bcp-doh-clients.
> 
> 
> These discussions have focused on DoH for client (typically web 
> browser) communication with recursive resolvers, and its comparisons 
> with DoT for this purpose.
> 
> 
> Is there any compelling reason at this point to be considering DoH for 
> recursive resolver-to-authoritative name server communications?
> 
> 
> As I noted at the DPRIVE interim meeting, the working group needs 
> empirical studies looking at performance and attack vectors for 
> authoritative DNS encryption.
> 
> 
> Unless there are compelling reasons to consider Authoritative DoH, I 
> propose the working group focus its authoritative DNS encryption 
> assessments around Authoritative DoT.
> 
> 
> In support, I am willing to co-author an Authoritative DoT operational 
> consideration draft in order to outline the operational challenges the 
> community needs to address - similar to the draft-reid-doh-operator 
> draft between client and recursive.
> 
> 
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>