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

Eric Osterweil <> Sun, 25 August 2019 21:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D6C9120020 for <>; Sun, 25 Aug 2019 14:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o_439EVDHzY9 for <>; Sun, 25 Aug 2019 14:29:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A7E2120041 for <>; Sun, 25 Aug 2019 14:29:22 -0700 (PDT)
Received: by with SMTP id z4so16191759qtc.3 for <>; Sun, 25 Aug 2019 14:29:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=naQOckg18yjPSFIj+GuIx0yI++15lSFsuPlNOcgATuw=; b=b3lKey+rlLuGNzBTeEFlK2ru+iNH2TZFe5mGszrAMSskWHI/oexNbQyonAxkZ5VK9u OudQLSVKGKpCyg9Qy346ZNs7VRAXzH2r+K+aEqQAqJQw2SHn8WYI1O6U/BzLeIWK1Ewy Az0G999WWi5JXTsCM7cf4PiSUkrPXSM8kX4mKtpmUb2ILQ34rH7coxcFATyf2BmkBPTf S/KwWlLg5GENXmd82k2FD+Y4pamhH6Yn7Ww2tU6kiVAPWqAgbeYA1oD/VTvRcQ2LDBf+ mVfErvMWqWqoz7PFUmqsCoN4Vf7JS7HmofiOPlEhI10KNVdbHB7jNQ+6OBhzKFZVv8r/ B1ag==
X-Gm-Message-State: APjAAAUbWF/DrzGN2sNeIdifUkCW2UVQ1+z8av0bnEyDzj3jA/45NvCW 2ctVzERuJQsgk6rZXUazH/ciQSlK55o=
X-Google-Smtp-Source: APXvYqyozguckhXL3v8Ex0qctY5WW5oleBuoYpNSp6jUUHGcZMwD+UJ//jBGHfPNECa7wMkeXYSyLA==
X-Received: by 2002:aed:2b01:: with SMTP id p1mr15043618qtd.33.1566768560948; Sun, 25 Aug 2019 14:29:20 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id i5sm7008067qti.0.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Aug 2019 14:29:20 -0700 (PDT)
From: Eric Osterweil <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_47B6671A-7B8C-4299-8555-B4581CC87188"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sun, 25 Aug 2019 17:29:18 -0400
In-Reply-To: <>
References: <> <4568720.uvMTqBdgP4@linux-9daj> <> <34813218.VKkrhzyXsx@linux-9daj> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Aug 2019 21:29:24 -0000

> On Aug 25, 2019, at 4:40 PM, Erik Sy <> wrote:
> On 8/25/19 20:03, Eric Osterweil wrote:
>>> 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?
> Here is a quote from Chris Palmer on this issue[1]:
> 1:
>!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ <!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ>
> "The strength of PKP ― run-time enforcement with hard-fail — is also
> exactly its weakness. Some people are OK with the risk, but overall I
> think the market has spoken: HPKP has seen close to no adoption. People
> don't want to brick their sites.
> As for DANE, it would at best have the same strength/weakness of HPKP,
> but with the additional problems of DNSSEC.”

I think this consideration is fundamentally too narrow.  As I pointed out (elsewhere in the previous message), DANE is part of an architectural solution ( <> ).  While browser security is a very important space, it is just one potential application.  While DANE does offer an elegant security solution for HTTPS connections, that does not mean its benefits are limited to that venue.

To reiterate earlier points: DANE securely binds associations to names in a generalized architecture.  The architecture is composed of a non-stationary suite of solutions.  In regards to TLS, its protections go beyond just for the browser.  For instance, consider opportunistic transport layer cert/key learning for SMTP (RFC-7672: <> ).  The deployment numbers for this use are up-and-to-the-right ( <> ).  However, what I think really illustrate's DANE’s true potential (my own 0.02 here) is the fact that it also enables certificate/key learning for object security suites like S/MIME and PGP ( <> ).

> In total, it seems like Chrome does not want to deploy DANE.

It continues to be a shame, but there’s always time for people to see look at growing evidence and reconsider previous decisions. ;)