IETF Logo Mail Archive

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

Jim Reid <jim@rfc1035.com> Mon, 26 August 2019 15:37 UTC

Return-Path: <jim@rfc1035.com>
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 23BA412081A for <add@ietfa.amsl.com>; Mon, 26 Aug 2019 08:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 6MqdR-ukag2X for <add@ietfa.amsl.com>; Mon, 26 Aug 2019 08:37:09 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE86112080D for <add@ietf.org>; Mon, 26 Aug 2019 08:37:08 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id EA36B242109D; Mon, 26 Aug 2019 15:37:04 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <CABcZeBPbvug-+N+4_85XN++ySLqZmUGOqzU-jRbr0h6AZ0usNw@mail.gmail.com>
Date: Mon, 26 Aug 2019 16:37:04 +0100
Cc: ADD Mailing list <add@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6254AD2E-5A06-4327-A083-FA32746C0278@rfc1035.com>
References: <A1128702-1E19-4657-9740-E84AE09992F2@piuha.net> <CABcZeBMfOTjq-8hDDoKMtJvfHUA5nC8o60zuk-2Xe-ZhfwriJQ@mail.gmail.com> <766112E1-F532-4C6B-8CA8-A096671E02EE@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> <69015C05-4AE8-4FB2-94D4-3B52018DEBA6@rfc1035.com> <CABcZeBPbvug-+N+4_85XN++ySLqZmUGOqzU-jRbr0h6AZ0usNw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/dKILh4YXgyzHKKJ3-vaQyhSAaLo>
X-Mailman-Approved-At: Mon, 26 Aug 2019 10:14:12 -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: Mon, 26 Aug 2019 15:37:10 -0000


> On 23 Aug 2019, at 13:25, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Let's go back to your original message, which made the distinction between actual truth and whatever the resolver told you "DNSSEC validation means you get the truth, the whole truth and nothing but the truth regardless of your choice of resolver or the transport path between you and that resolver. DoH and DoT offer no protection at all from a lying resolver - you’re just guaranteed to receive precisely whatever lies or truth that resolver sends" This distinction is only relevant if you actually aren't going to just trust whatever the resolver tells you.

Indeed. 

However I don’t understand how this relates to the point you seemed to be making, namely differentiation between a resolver that’s blocking malware and a malicious resolver (for some definition of that term). Could you please apply some clue?

v2.23.0 | Report a Bug | By Email