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

Eric Osterweil <lists@osterweil.net> Sun, 25 August 2019 18:03 UTC

Return-Path: <lists@osterweil.net>
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 AFF001200B4 for <resolverless-dns@ietfa.amsl.com>; Sun, 25 Aug 2019 11:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oTQThS_qttlx for <resolverless-dns@ietfa.amsl.com>; Sun, 25 Aug 2019 11:03:33 -0700 (PDT)
Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (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 4558212006B for <resolverless-dns@ietf.org>; Sun, 25 Aug 2019 11:03:33 -0700 (PDT)
Received: by mail-qk1-f177.google.com with SMTP id m2so12366893qkd.10 for <resolverless-dns@ietf.org>; Sun, 25 Aug 2019 11:03:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HkTg4kcDXPPHF/g2FKeexa/Rs/9XRKB32phD5XhZlzQ=; b=WhW93XBLGd32uK/Ou8/0dnpJhKEVkUC2pA6qrRW71x55j8H+VHCcKOJkmujAy30Nqi yTskO9U4TtkKlE5LrczahF0XxMVz4f2Fd7VV5LG7FKdtQEVE4AWQULKBqVH6Usp7H8IG ZnwveZgDGSKU02yvwujQUh/P9WgAdIZnDwTCwmtn0iRGjBDqmp+utIfAfm2VZJdwIPjy caN7WD34nP4d+0/5yh2muNLp6/RVirODQ/fWhWXsYE4lDl/YCf0yFcC7QbiasUFwQoJ7 QF/sEq9ptKisIiiosaHjY3hY0A7o1M63FXeB36ZNOnkey79YEdz4XdVMWmcuACp9cLLW xvLw==
X-Gm-Message-State: APjAAAXNUJzh8FwJcOKTCrE3if/rpOqfHQy9Z/mYAgC1+803r3lS95by fNeEX+qsf4E0+FGpOqPACV2sOgUmX9Q=
X-Google-Smtp-Source: APXvYqwLCRAereeKk+L2l+LVycjrgF3schBz5vGWikkfiTtFPhXNStKkF/+1SjltZXor0bcgTnb6sw==
X-Received: by 2002:ae9:e313:: with SMTP id v19mr13153189qkf.22.1566756212371; Sun, 25 Aug 2019 11:03:32 -0700 (PDT)
Received: from empty.byod.gmu.edu ([129.174.182.99]) by smtp.gmail.com with ESMTPSA id z2sm5884787qtq.7.2019.08.25.11.03.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Aug 2019 11:03:31 -0700 (PDT)
From: Eric Osterweil <lists@osterweil.net>
Message-Id: <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_770C1BC4-6879-4955-AE9F-69178F2187F8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sun, 25 Aug 2019 14:03:30 -0400
In-Reply-To: <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de>
Cc: resolverless-dns@ietf.org
To: sy@informatik.uni-hamburg.de
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>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/iBdKhhyZsp-7Do90VYRgy4CMmtY>
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: Sun, 25 Aug 2019 18:03:36 -0000


> On Aug 23, 2019, at 10:27 AM, Erik Sy <sy@informatik.uni-hamburg.de>; wrote:
> 
> 
> On 8/23/19 14:05, Vittorio Bertola wrote:
>>> Il 23 agosto 2019 13:50 Erik Sy <sy@informatik.uni-hamburg.de>; ha scritto:
>>> 
>>> Do you think the bullet point "There is a risk of rendering a site
>>> unusable." does apply to DANE TLSA?
>> Sure, but it also applies to normal HTTPS certificates without pinning. How many times did you try to access an HTTPS website and were stopped by the browser, because the certificate was expired and the owner forgot to renew it, or because the certificate was self-signed, even if the site had not been attacked? It happens every day, but it's not a good reason to stop using certificates and validating them properly - it's rather a good reason for the site owner to get a better webmaster. 
>> 
> Chrome establishes trust in a certificate if it is issued by a valid CA
> and included in the Certificate Transparency (CT) logs. Here, the CT
> allows to monitor the certificates issued by the CAs. In this ecosystem,
> it is unlikely that valid CAs issue illegitimate certificates because
> the trust in misbehaving CAs can be revoked at any time.

The past is prolog:
	https://threatpost.com/final-report-diginotar-hack-shows-total-compromise-ca-servers-103112/77170/ <https://threatpost.com/final-report-diginotar-hack-shows-total-compromise-ca-servers-103112/77170/>
DANE keeps the control of associating TLS certificates with a domain in the hands of the domain holder/operator.

CT is not a panacea, and concerns about it are still evolving.  For example, it exposes all certs from all participating CAs, and this has been shown to have negative consequences when people do not want all of their domain names (such as internal names) necessarily exposed for discovery:
	https://dl.acm.org/citation.cfm?id=3278562 <https://dl.acm.org/citation.cfm?id=3278562>

> 
> Additional pinning of certificates provides the benefit that an
> illegitimate certificate can be detected during the server
> authentication. Note, that CT can detect this only in the aftermath. As
> a drawback of pinning, a misconfiguration of this mechanism always leads
> to a fatal error. The trade-off at hand is catching misbehaving CAs
> before the connection establishment and accepting hard failures due to
> possible misconfiguration versus catching the malicious CA only in the
> aftermath of the connection establishment. I think that Chrome decided
> for the latter one.

If I follow your logic here, then I think this is a statement that is at least break-even for (but likely actually in favor of) DANE.  If a certificate that is proffered over a TCP connection does not match the TLSA record, it is proactively detected and the session initiation fails, yes?

Eric