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

Eric Osterweil <> Sun, 25 August 2019 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 799E21200F7 for <>; Sun, 25 Aug 2019 11:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mkIVfu_7stoI for <>; Sun, 25 Aug 2019 11:03:14 -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 0E37E12006B for <>; Sun, 25 Aug 2019 11:03:13 -0700 (PDT)
Received: by with SMTP id m10so12406957qkk.1 for <>; Sun, 25 Aug 2019 11:03:13 -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=fzIe1IoQPPB3ll8ue2o2fUNnTuWXKMfOTK75yF86c24=; b=PKWdEY8BaXLfYXMIYeJzmj1dXGMZQ9lJ/JgAfMJ2Qa6g48PpC81hkStkEHSlQIprze rCJjOel/RI/9RS0AsMG0j2Sx4RaQQlzBaF7cgeVULf7SA1s3A44bTs3gboIm8IBg6qRW QJUNZYgl4usx3uZYGxbcL0dElLlhO1Rb2us/KS0novmtLH1E30u2iiT+OgpFnKC6ivre GfNdvRn6awLX9DCXPuEeFR0R0oWvhGVDask3sAtmezyZcol320Jaqn7+QbYPNYEMU9YR 5wkKy2u0AEYenaJEwcnR2TOcfkGAydviXpJfs5v0PYnbgTizjnXVfuhE6uDIxT92fiww FDbQ==
X-Gm-Message-State: APjAAAUn04CPkEOv/FkxFpYBY/RqhjisTLulIz2tnEpasbaO07o63e7t G9irXDX6FxFaQLZaCMawlu85b+Az6YE=
X-Google-Smtp-Source: APXvYqzf/7XW2vJDvRdMUOmUd4afyZQ3YHoEHcsKUyZwwPUeWFC2+TZeQrSTFER0peVNL8QFeDz29A==
X-Received: by 2002:a05:620a:134b:: with SMTP id c11mr13532801qkl.454.1566756192907; Sun, 25 Aug 2019 11:03:12 -0700 (PDT)
Received: from ([]) by with ESMTPSA id z2sm5884787qtq.7.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Aug 2019 11:03:12 -0700 (PDT)
From: Eric Osterweil <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CE18A48C-FF9B-4357-9072-A649AFBE0F4F"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sun, 25 Aug 2019 14:03:11 -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 18:03:16 -0000

> On Aug 23, 2019, at 5:37 AM, Erik Sy <> wrote:


>>>> the economy depends on them doing so.
>>> I find that only 0.9% of the .com domains are signed [2] and having a
>>> signature does not mean that they can be successfully validated.
>> i suggest you broaden your search for knowledge. for example, this web
>> site may be of interest, along with the monthly reports posted to
>> dns-operations@ by the same authors.
> Anyway, lets assume that all domains and resolvers perfectly support
> DNSSEC and that we have transport encryption between the client and the
> resolver. In this scenario, the client still needs to trust the resolver
> to provide the correct address. Furthermore, having a correctly resolved
> IP address does not solve the problem of communicating to the correct
> server, which is usually the intention of the client.

I feel like this kind of misses the point of DANE.  DANE specifies the authoritative model for creating and verifying security associations.  One of DANE’s core observations is that if the A record is securely resolved, then that same security substrate should be used to resolve the binding of that name to a certificate/key.  Said differently, the binding of a TLS certificate to a domain name (via the TLSA record) gives the client its assurance that is talking to the correct server.

>>>> if RDNS isn't client software from your point of view, you'll dismiss
>>>> these assertions.
>>> RDNS requires the client to trust the used recursive resolver.
>> not for DANE work flows. stub validation is not widely implemented or
>> well supported by DNSSEC, but it works, and existing DANE TLSA clients
>> do this.
> In my view, DANE TLSA is an approach to do public key pinning. The web
> already collected a lot of experience with public key pinning as this
> can be also done using other protocols than DNS. In summary, the Chrome
> browser deprecated this mechanism last year [1]. Assuming that DANE TLSA
> would be widely supported on client systems, I think that Chrome would
> not start using this mechanism to do public key pinning.
> 1:
>!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ <!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ>

I would say this argument also misses a fundamental point.  Architecturally, DNSSEC uses a single root TA to make domain names unambiguous (i.e. collision-free) and verifiable, and DANE adds security associations to certificates by the same infrastructure.  It’s the single-rooted verification hierarchy that makes name-to-object verification collision-free and unambiguous, as opposed to solely leaving it the hands of the multi-rooted Web PKI (though DANE's selector field allows synergy w/ that model).  These assurances are not (afaict) provided by key pinning alone.  

There is a fair amount of writing that discusses this, and numerous presentations.  I’m happy to provide pointers if anyone would like.