Re: [Resolverless-dns] Paper on Resolver-less DNS

Ted Lemon <mellon@fugue.com> Thu, 29 August 2019 14:59 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB53B120119 for <resolverless-dns@ietfa.amsl.com>; Thu, 29 Aug 2019 07:59:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 7s5VsYdY8G_6 for <resolverless-dns@ietfa.amsl.com>; Thu, 29 Aug 2019 07:59:25 -0700 (PDT)
Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4F61200F9 for <resolverless-dns@ietf.org>; Thu, 29 Aug 2019 07:59:25 -0700 (PDT)
Received: by mail-qk1-x742.google.com with SMTP id w18so3241800qki.0 for <resolverless-dns@ietf.org>; Thu, 29 Aug 2019 07:59:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aPZiqjRt58IBgrPAR7z+lci5t55+OumBjJqJzwBfzlY=; b=NTFsBzpfv+px8Om2VqnokrozsIzbRn9ehaDNm7RUlArGpggy2txhYsRXZYiiHWltT2 zAjNsbv0tMkBqCgag+ezwOTlSv1Z6dzK1MkqQ7I2wblmO6hsmGPdwsDQv1Cvk7YVCB5b O91jjMoJMIi5bVTtfa02G1ojGYRkxEfj4uiJ+of0pvG1fJhdL01XyXsXYs81lRZENZsR jfXg3nyhm+HATGR+AXFfMeyKJjhHYRQG6ZSKVgbLw2UwKbRVF5veElEUi6Lazup0jVF+ kzsfFxRZb6x5UVindl4IsiXKVmWfNSBMEax6oxbR+9EyUypqXuZ7KZOyexVI62guOXBt OuJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aPZiqjRt58IBgrPAR7z+lci5t55+OumBjJqJzwBfzlY=; b=RzzN6sL940sagecr1op5Q6uYn590ofggY1nZ9x2Y/XMgIN6H00SsHdndn/c7CrWjU2 WfCg3A6yQF6Y2KTAcH74xexDamC+qLo5JBpGQ7W7UUkpg5psdweK9GzQcvYC9O327yi3 EdP51aThU45d19ymKcc53eFSUuqX6tb6U4XN25BTD0lPbbQrXNGPrxbPugqtGVTUS+uM by9sKkYeMqOWIavNpRyB7DLEzqnZI4saKBCjAROn/0RPBGYk+2c10TSjmz+8humKHv42 nFkaXzaBJ58v38HPuQpDYdr8JDu+p9V50xSmG5nQU46HdgnQsITPds4oABBiaXxDpiP5 lXnw==
X-Gm-Message-State: APjAAAUXprF9VsuLBioXRJC2jME/xAfJ6AAjuETBbxxTj016VGJy62J+ GNw29r4qzmn5aJXyBpq8neyz4w==
X-Google-Smtp-Source: APXvYqzMCxRaGJirh29pvVSxYPUgFIjWBco0asrmBXHirRIHxZxxj+r84ZsUhoJ6eA8v6whSx0R8OA==
X-Received: by 2002:a37:a0c2:: with SMTP id j185mr9749291qke.123.1567090764379; Thu, 29 Aug 2019 07:59:24 -0700 (PDT)
Received: from [10.0.100.59] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id b50sm290271qte.48.2019.08.29.07.59.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 07:59:23 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de>
Date: Thu, 29 Aug 2019 10:59:22 -0400
Cc: resolverless-dns@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E36BB574-0873-49DA-A429-D9781AA52B16@fugue.com>
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <4568720.uvMTqBdgP4@linux-9daj> <fb12f102-714d-95cc-c6cc-0871a2df9f50@informatik.uni-hamburg.de> <34813218.VKkrhzyXsx@linux-9daj> <ae355776-a1bb-cf23-f380-133439661d1f@informatik.uni-hamburg.de> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <a8d9398b-4fea-0a1e-3fa7-5954d001f9ea@informatik.uni-hamburg.de> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> <b2b3e56a-c577-f08a-627a-f54e2e6fadb6@informatik.uni-hamburg.de> <f093a605-6e7d-0237-df5c-441d6789c66f@erik-sy.de> <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de>
To: Erik Sy <sy@informatik.uni-hamburg.de>
X-Mailer: Apple Mail (2.3578.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/4zf7snesif8APWnY66DwaTTxGOw>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2019 14:59:28 -0000

Or, the client could explicitly request the validation chain.   But of course this has implications for padding: it may be that the size of the output will be more helpful for guessing.   Or it may be that it makes no difference, because the bulk of the data is signatures, which are in principle always the same size (assuming that the client specifies the signature algorithm it wants, and the server sends only those signatures).   This would be an interesting thing to investigate.

> On Aug 29, 2019, at 10:36 AM, Erik Sy <sy@informatik.uni-hamburg.de>; wrote:
> 
> On 8/27/19 23:39, Viktor Dukhovni wrote:
>>> On Aug 27, 2019, at 5:18 PM, Erik Sy <email@erik-sy.de>; wrote:
>>> 
>>> It seems to me, that both of you are OK with the risk of DNSSEC + DANE
>>> TLSA leading to hard failures.
>> I also deny beating my spouse...  Seriously, the premise of the question
>> "are you OK with the risk of DANE leading to hard failures" is flawed.
>> Hard failures are the purpose of security mechanisms.  Of course I am
>> OK with a security mechanism that may deny access, that's not the
>> right question.
> 
> I disagree, that this question is flawed. It assumes that DNSSEC + DANE
> is an optional security mechanism in the context of web browsers. Note,
> that for example a valid TLS certificate is considered a mandatory
> security mechanism and should be enforced by hard failures. Thus, the
> question is more like "are you OK with optional security mechanisms
> leading to hard failures".
> 
>> 
>> The right question is whether a given mechanism is sufficiently robust
>> to be usable. 
> At least the given mechanism needs also to provide a significant
> security benefit. In my view, the additional benefit of DNSSEC+ DANE
> compared to Certificate Transparency + Strict Transport Security (HSTS
> or MTA-STS) is for the majority of server operators or users not relevant.
>>> I like to point out, that resolver-less DNS can be extended to support
>>> DNSSEC + DANE TLSA as a validation mechanism for DNS records. Thus, in
>>> case browser vendors decide to support DNSSEC + DANE TLSA the browsers
>>> can receive the corresponding records also via resolver-less DNS.
>> Actually, we've been down that road already (TLS DNSSEC chain
>> extension fiasco).  There is no clean way to provide downgrade
>> resistance in such a protocol, or even properly ensure that
>> answers are in bailiwick.  I doubt you are proposing that servers
>> MUST always return a full DNSSEC validation chain for the returned
>> RRsets (or denial of existence proofs for the associated DS RRs).
> 
> In my view, supporting DNSSEC + DANE TLSA in resolver-less DNS makes
> only sense if the server provides a full DNSSEC validation chain because
> everything else seems to introduce significant delays. However, given
> the significant size of full DNSSEC validation chains such feature
> should be deactivated in a default configuration of resolver-less DNS.
> Anyway, as long as no web browser intends to support a validation of DNS
> records via DNSSEC + DANE TLSA, there is no requirement for
> resolver-less DNS to support this practice.
> 
> Erik
> 
> 
> -- 
> Resolverless-dns mailing list
> Resolverless-dns@ietf.org
> https://www.ietf.org/mailman/listinfo/resolverless-dns