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 799E21200F7 for <resolverless-dns@ietfa.amsl.com>; Sun, 25 Aug 2019 11:03:16 -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 mkIVfu_7stoI for <resolverless-dns@ietfa.amsl.com>; Sun, 25 Aug 2019 11:03:14 -0700 (PDT)
Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) (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 0E37E12006B for <resolverless-dns@ietf.org>; Sun, 25 Aug 2019 11:03:13 -0700 (PDT)
Received: by mail-qk1-f193.google.com with SMTP id m10so12406957qkk.1 for <resolverless-dns@ietf.org>; Sun, 25 Aug 2019 11:03:13 -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=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 empty.byod.gmu.edu ([129.174.182.99]) by smtp.gmail.com with ESMTPSA id z2sm5884787qtq.7.2019.08.25.11.03.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Aug 2019 11:03:12 -0700 (PDT)
From: Eric Osterweil <lists@osterweil.net>
Message-Id: <362BF53C-8B12-4A1B-8C74-7D391C2637F7@osterweil.net>
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: <ae355776-a1bb-cf23-f380-133439661d1f@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>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/sH9zv85siXEiK3m9erxmJvTxs7I>
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:16 -0000


> On Aug 23, 2019, at 5:37 AM, Erik Sy <sy@informatik.uni-hamburg.de> wrote:
> 

<snip>

>>>> 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.
>> 
>>  
>> 
>> https://stats.dnssec-tools.org/
>> 
>>  
>> 
> 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:
> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ <https://groups.google.com/a/chromium.org/forum/#!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.

Eric