Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers

Paul Vixie <paul@redbarn.org> Sat, 27 June 2020 00:04 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053D53A0D27 for <add@ietfa.amsl.com>; Fri, 26 Jun 2020 17:04:59 -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, SPF_HELO_NONE=0.001, 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 FeEZqaWwrlrm for <add@ietfa.amsl.com>; Fri, 26 Jun 2020 17:04:57 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672F93A0CB3 for <add@ietf.org>; Fri, 26 Jun 2020 17:04:57 -0700 (PDT)
Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 55222B0588; Sat, 27 Jun 2020 00:04:54 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Tommy Pauly <tpauly@apple.com>, add@ietf.org
Cc: ADD Mailing list <add@ietf.org>, Eric Rescorla <ekr@rtfm.com>
Date: Sat, 27 Jun 2020 00:04:52 +0000
Message-ID: <2013869.BjYadG0qc2@linux-9daj>
Organization: none
In-Reply-To: <CABcZeBOyAb3HrX0ABM2ZFuz-_Vn+0sPk_88e2OwQ5U-DRjAxXQ@mail.gmail.com>
References: <CABcZeBPTkWeB40wpTowKvEJ-gXA3AL2e-BE+C_FC7Js7-D0DZQ@mail.gmail.com> <1AB2782B-87C0-4991-8703-AE2C98411AFC@apple.com> <CABcZeBOyAb3HrX0ABM2ZFuz-_Vn+0sPk_88e2OwQ5U-DRjAxXQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/lGEI60EdSBRzCDU7NnZRoNHyIDc>
Subject: Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2020 00:04:59 -0000

On Friday, 26 June 2020 22:08:05 UTC Eric Rescorla wrote:
> ... Other than inelegance, what's problematic about the CNAME approach?

inelegance is permanent, accretive, and earns compound interest. we ought not 
dismiss inelegance as the basis for reluctance. inelegance is not inevitable 
nor is it automatically acceptable.

> ...
> 
> The scenario you seem to be interested in is one in which the user joins
> the network and then learns that the associated Do53 resolver supports DoH
> and then connects to it with whatever coordinates that resolver (or DHCP or
> whatever) provides. That clearly is not useful in the 3552 threat model
> which assumes that the attacker entirely controls the network because the
> attacker can just send their own resolver coordinates. That isn't to say
> that there aren't more limited but still realistic threat models where this
> would be useful, but I think you should start by describing those.

as we describe them, we should also describe their scale, their age, and their 
likely lifespan. the 3552 threat model, while it does use the term 
'pervasive', is nowhere near as common as the SASE (secure access service 
edge) operations model, nor will it ever be. if apps who want to do their own 
DNS treat any DoH failure as an attack, and start an arms race of spy-vs-spy 
bypass along the lines of Tor, that's going to feel problematic to any of us 
whose privately owned securely operated edge networks have a local-only DNS 
policy.

RESINFO could probably get better results by using TXT, because of long tail 
problems. but ultimately we have to pick a default assumption that we can act 
on when secure resolver discovery fails. "OMG it's a 3552 attack" is not the 
only interpretation we could think of for this. it's entirely possible that 
the most engineering solution to the discovery problem is to fail hard when 
the middlebox prevents authenticated policy negotiation, to force middlebox 
upgrades. i know that "tough love" is a hard sell, but "assume 3552 attack" is 
also a form of tough love.

-- 
Paul