Re: [Add] data integrity and DNSSEC or DoH/DoT

Paul Wouters <paul@nohats.ca> Fri, 06 September 2019 03:27 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57FE120826 for <add@ietfa.amsl.com>; Thu, 5 Sep 2019 20:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 RlwfUnEYiptW for <add@ietfa.amsl.com>; Thu, 5 Sep 2019 20:27:33 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D64120817 for <add@ietf.org>; Thu, 5 Sep 2019 20:27:33 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46Pjfp1yVYz3D1; Fri, 6 Sep 2019 05:27:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1567740450; bh=g2HLsRu7zstFCnifvotcsv5TLbQs5iXMZ7WtxU9Axiw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gX4pGjuOBARdW3jqJjj2R1tDThTEolkgPMT194LQnSULFe5nkkoNeRAXCLBfnS4Ts eHztKz1PzMKxpbkoM1vGBrjZgFy5zsYEOyfZkbPbPOAAA/QkG0ol+kGNqkWsvOFDB7 Li+nGWhSFK4IhFq3gTBIbL8/3YNi1fFWmtIBraPw=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id fgI7mA7MfTv6; Fri, 6 Sep 2019 05:27:28 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 6 Sep 2019 05:27:27 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8BECA35297B; Thu, 5 Sep 2019 23:27:26 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8BECA35297B
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7F93C406A906; Thu, 5 Sep 2019 23:27:26 -0400 (EDT)
Date: Thu, 05 Sep 2019 23:27:26 -0400
From: Paul Wouters <paul@nohats.ca>
To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
cc: Brian Dickson <brian.peter.dickson@gmail.com>, ADD Mailing list <add@ietf.org>
In-Reply-To: <125944910.3423.1567677431631@appsuite-gw1.open-xchange.com>
Message-ID: <alpine.LRH.2.21.1909052317500.4174@bofh.nohats.ca>
References: <A1128702-1E19-4657-9740-E84AE09992F2@piuha.net> <CA+9kkMAfuOwJu8_qJTuhAY4mUwR+tVUxr+k3QFHBk3byV672Ow@mail.gmail.com> <A7EA862E-8E80-40E3-834D-E628988C0A24@virtualized.org> <CAFWeb9KT=2JL0oHUgJ2WMcduR3na+hP2QncvRR4YurmqsAWxTA@mail.gmail.com> <59E0EC53-0E30-431C-8376-52C7BFC121A8@virtualized.org> <CAFWeb9+Z7RmXEr46qx5PaUcxh2R3+HXhrZeW-8QEMX4HLt7a-w@mail.gmail.com> <589DAFCB-1BDC-4156-A2CA-179C4559A6B2@virtualized.org> <cf2152d7-8618-7ad2-b8f9-7a259ab5df19@cs.tcd.ie> <683A176C-3CE6-4866-A736-F2A7465FA5B5@rfc1035.com> <CABcZeBPmWYBKcKhjTUBLw62xJT=OXbp3v6MZ+8Gtr=gFmQ-g6A@mail.gmail.com> <E40CC478-BBA1-4DA9-8F6A-FE1782E0F27E@rfc1035.com> <CABcZeBMnG_HJHYrGpQD1LWWNi8zuhAm=0Uy2HNRRmhYS9PsCtg@mail.gmail.com> <06613304-C325-4BA4-AB6F-32D79DFCECA0@open-xchange.com> <CABcZeBMr6WtzbyPPA6W1Da0A9bUoowMVucbBf5K0BQgqZrNdwg@mail.gmail.com> <CAH1iCioWFzHN_hTW4G=0kNHX+2onC64xTSEG-U4miQ1YUH8bSQ@mail.gmail.com> <125944910.3423.1567677431631@appsuite-gw1.open-xchange.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/yzmoFXM5UoDk9NBFI1HyOckFUu0>
X-Mailman-Approved-At: Fri, 06 Sep 2019 08:26:20 -0700
Subject: Re: [Add] data integrity and DNSSEC or DoH/DoT
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2019 03:27:37 -0000

On Thu, 5 Sep 2019, Vittorio Bertola wrote:

[ quoting might have errors as the original messages seems to have odd quoting mechanisms ]

> Moreover, this model would break the cases in which the user does not trust the resolver, but the resolver still has to apply filters
> because they are legally mandated, or applies filters that are beneficial anyway (e.g. against malware), which however cannot be
> validated via DNSSEC.

If filtered properly (eg RPZ 2.0) the censored Answer section is moved
to the Authoritatve section so that DNSSEC validation can succeed while
the answer is suppressed for the client (and those not supported this
will also see a failure, even if a DNSSEC failure, instead of an
extended error opcode DNS failure with DNSSEC proof)

> In the end, I think we are at a point where we need to give some thought at the general architecture of DNS resolution over the
> Internet, and think: where and how should it be done? For example, would it be better if full resolution happened on each individual
> device?

This has been the case for a while now. This is why I wrote RFC 7901.
This is why we wrote draft-tls-dnssec-chain.

You can still use a forwarder, and you can still get all information in
one round trip.

Trusting unsigned data from the internet from random parties is not done
for any other protocol, why allow it for DNS?

> I think that this would have more drawbacks than advantages.

Can you elaborate on why you think that is?

>  So the only alternative is to facilitate the establishment of trust
> in at least one resolver.

No because transport security provided by a resolver is not data origin
security offered by DNSSEC.

> In the end, I think that a general "resolver accreditation service" on a global scale - which Mozilla has the ambition to create with
> their TRR list - will never work due to scaling problems, unless you centralize resolution into a handful of global platforms, which
> IMHO would be a much bigger problem for the Internet. What could instead work is a way for the user to express and change an assertion
> of trust in one or more resolvers, devolving the problem to the edges of the network and letting each user define implicitly their own
> requirements for trust.

Sounds very similar to the browsers having a store of root CA's. It
didn't really work from a trust point of view, and it was patched up
with first CRLs, then OCSP and then CT. Why make the same mistake
with DNs resolvers?

> I also think it would be better for all parties if implementers not deploy things like TRRs until the bare minimum of mechanisms
> is available, which may require work not only on the applications (doing dns) but also on the resolvers themselves.

Some believe TRR's are better than random ISP DNS resolvers they happen
to be (forced to) using, such as hotel or coffee shops. For example,
I've stayed at hotels whose wifi blocked Priceline and Booking.com
using DNS. So I don't see why TRR's should not be deployed until
some mysterious future time.

Paul