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
- [Add] What to do in this potential working group Jari Arkko
- Re: [Add] What to do in this potential working gr… Eric Orth
- Re: [Add] What to do in this potential working gr… Jari Arkko
- Re: [Add] What to do in this potential working gr… Eric Rescorla
- Re: [Add] What to do in this potential working gr… Jim Reid
- Re: [Add] What to do in this potential working gr… Vittorio Bertola
- Re: [Add] What to do in this potential working gr… Jari Arkko
- Re: [Add] What to do in this potential working gr… Eric Vyncke (evyncke)
- Re: [Add] What to do in this potential working gr… Ted Lemon
- Re: [Add] What to do in this potential working gr… Jim Reid
- Re: [Add] What to do in this potential working gr… Ted Lemon
- Re: [Add] What to do in this potential working gr… Tommy Jensen
- Re: [Add] What to do in this potential working gr… Jari Arkko
- Re: [Add] What to do in this potential working gr… Eric Rescorla
- Re: [Add] What to do in this potential working gr… Ray Bellis
- Re: [Add] What to do in this potential working gr… Eric Rescorla
- Re: [Add] What to do in this potential working gr… Ray Bellis
- Re: [Add] What to do in this potential working gr… Eric Rescorla
- Re: [Add] What to do in this potential working gr… Ted Hardie
- Re: [Add] What to do in this potential working gr… David Conrad
- Re: [Add] What to do in this potential working gr… Alec Muffett
- Re: [Add] What to do in this potential working gr… Ted Hardie
- Re: [Add] What to do in this potential working gr… David Conrad
- Re: [Add] What to do in this potential working gr… Brian Dickson
- Re: [Add] What to do in this potential working gr… Brian Dickson
- Re: [Add] What to do in this potential working gr… Stephen Farrell
- Re: [Add] What to do in this potential working gr… Ted Hardie
- Re: [Add] What to do in this potential working gr… Alec Muffett
- Re: [Add] What to do in this potential working gr… Stephen Farrell
- Re: [Add] What to do in this potential working gr… David Conrad
- Re: [Add] What to do in this potential working gr… Rob Sayre
- Re: [Add] What to do in this potential working gr… Jari Arkko
- Re: [Add] What to do in this potential working gr… Stephen Farrell
- Re: [Add] What to do in this potential working gr… Alec Muffett
- Re: [Add] What to do in this potential working gr… Ted Hardie
- Re: [Add] What to do in this potential working gr… Adam Roach
- Re: [Add] What to do in this potential working gr… Ted Hardie
- Re: [Add] What to do in this potential working gr… David Conrad
- Re: [Add] What to do in this potential working gr… Rob Sayre
- Re: [Add] What to do in this potential working gr… Stephen Farrell
- Re: [Add] What to do in this potential working gr… Alec Muffett
- Re: [Add] What to do in this potential working gr… David Conrad
- [Add] data integrity and DNSSEC or DoH/DoT Jim Reid
- Re: [Add] What to do in this potential working gr… Rob Sayre
- Re: [Add] data integrity and DNSSEC or DoH/DoT Stephen Farrell
- Re: [Add] data integrity and DNSSEC or DoH/DoT David Conrad
- Re: [Add] data integrity and DNSSEC or DoH/DoT Rob Sayre
- Re: [Add] data integrity and DNSSEC or DoH/DoT Stephen Farrell
- Re: [Add] Unstated assumptions in What to do in t… John Levine
- Re: [Add] data integrity and DNSSEC or DoH/DoT Brian Dickson
- Re: [Add] What to do in this potential working gr… Patrik Fältström
- Re: [Add] What to do in this potential working gr… Patrik Fältström
- Re: [Add] What to do in this potential working gr… Rob Sayre
- Re: [Add] What to do in this potential working gr… Eric Rescorla
- Re: [Add] What to do in this potential working gr… Martin Thomson
- Re: [Add] data integrity and DNSSEC or DoH/DoT Eric Rescorla
- Re: [Add] What to do in this potential working gr… Eric Rescorla
- Re: [Add] What to do in this potential working gr… Jari Arkko
- Re: [Add] What to do in this potential working gr… Daniel Stenberg
- Re: [Add] What to do in this potential working gr… Jari Arkko
- Re: [Add] data integrity and DNSSEC or DoH/DoT Stephen Farrell
- Re: [Add] What to do in this potential working gr… Ray Bellis
- Re: [Add] What to do in this potential working gr… Martin J. Dürst
- Re: [Add] What to do in this potential working gr… Stephen Farrell
- Re: [Add] What to do in this potential working gr… Vittorio Bertola
- Re: [Add] What to do in this potential working gr… Eric Rescorla
- Re: [Add] What to do in this potential working gr… Ralf Weber
- Re: [Add] data integrity and DNSSEC or DoH/DoT Ralf Weber
- Re: [Add] data integrity and DNSSEC or DoH/DoT Willem Toorop
- Re: [Add] data integrity and DNSSEC or DoH/DoT Jim Reid
- Re: [Add] What to do in this potential working gr… Rubens Kuhl
- Re: [Add] data integrity and DNSSEC or DoH/DoT Paul Wouters
- Re: [Add] What to do in this potential working gr… Paul Wouters
- Re: [Add] data integrity and DNSSEC or DoH/DoT Livingood, Jason
- Re: [Add] What to do in this potential working gr… Livingood, Jason
- Re: [Add] What to do in this potential working gr… Livingood, Jason
- Re: [Add] What to do in this potential working gr… Livingood, Jason
- Re: [Add] What to do in this potential working gr… Adam Roach
- Re: [Add] What to do in this potential working gr… Eric Rescorla
- Re: [Add] data integrity and DNSSEC or DoH/DoT Eric Rescorla
- Re: [Add] data integrity and DNSSEC or DoH/DoT Rob Sayre
- Re: [Add] data integrity and DNSSEC or DoH/DoT Jim Reid
- Re: [Add] What to do in this potential working gr… Vittorio Bertola
- Re: [Add] data integrity and DNSSEC or DoH/DoT Eric Rescorla
- Re: [Add] data integrity and DNSSEC or DoH/DoT Brian Dickson
- Re: [Add] data integrity and DNSSEC or DoH/DoT Jim Reid
- Re: [Add] data integrity and DNSSEC or DoH/DoT Eric Rescorla
- Re: [Add] data integrity and DNSSEC or DoH/DoT Neil Cook
- Re: [Add] data integrity and DNSSEC or DoH/DoT Neil Cook
- Re: [Add] data integrity and DNSSEC or DoH/DoT Neil Cook
- Re: [Add] data integrity and DNSSEC or DoH/DoT Paul Wouters
- Re: [Add] data integrity and DNSSEC or DoH/DoT Christian Huitema
- Re: [Add] data integrity and DNSSEC or DoH/DoT Christian Huitema
- Re: [Add] data integrity and DNSSEC or DoH/DoT Brian Dickson
- Re: [Add] data integrity and DNSSEC or DoH/DoT Andrew Campling
- Re: [Add] data integrity and DNSSEC or DoH/DoT Vittorio Bertola
- Re: [Add] data integrity and DNSSEC or DoH/DoT Paul Wouters
- Re: [Add] data integrity and DNSSEC or DoH/DoT Vittorio Bertola
- Re: [Add] data integrity and DNSSEC or DoH/DoT Alec Muffett
- Re: [Add] data integrity and DNSSEC or DoH/DoT Alec Muffett