Re: [DNSOP] If DNSSEC signatures do not validate ...

Paul Wouters <paul@nohats.ca> Tue, 28 April 2020 15:22 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C619D3A0BD2 for <dnsop@ietfa.amsl.com>; Tue, 28 Apr 2020 08:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 ip3xt-LUgSPc for <dnsop@ietfa.amsl.com>; Tue, 28 Apr 2020 08:22:36 -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 00BF43A0B82 for <dnsop@ietf.org>; Tue, 28 Apr 2020 08:22:35 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49BQPB33gXzDfw; Tue, 28 Apr 2020 17:22:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1588087342; bh=0B1jHuHfmtzb9KAuqLrmRO9ZzCD5M/DE8jsO9d1net8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=r0NPGxcHTSaeq6hUQ71gvk6mjFil5HR7Ij9HVn3J9WMoFleWfBDTkYoG4TqpRWnLY fkB2z+rdXpguREDqzDGRDbaCOxfBX0YEECqJ4YbKTrxP9mHs7IYnXMz5+TeY8ZT8nB RT9N/V5QJ/nvrNjUa+TxK0SI6N6g08ChFyY+QIVM=
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 LRfMHrJA88X5; Tue, 28 Apr 2020 17:22:21 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 28 Apr 2020 17:22:21 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 66E2660009B6; Tue, 28 Apr 2020 11:22:20 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 62D3366A9A; Tue, 28 Apr 2020 11:22:20 -0400 (EDT)
Date: Tue, 28 Apr 2020 11:22:20 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Davey Song <songlinjian@gmail.com>
cc: Shumon Huque <shuque@gmail.com>, dnsop <dnsop@ietf.org>
In-Reply-To: <CAAObRXK36VVFTXd=_SNje4z3muBvUL3SZa0PmONgu50-V1r7ug@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.2004281120160.18623@bofh.nohats.ca>
References: <CAAObRXL-hFZ1jFo8dW-+M+2SR8gJ7vypKLMaJNuQJBvCsdJ0Gg@mail.gmail.com> <alpine.LRH.2.21.2004280931470.18623@bofh.nohats.ca> <CAAObRXJKf67Hv8i+fTUWcQMqpk-8hL6PPQ=iXtWnZ8yzk-wNWQ@mail.gmail.com> <CAHPuVdWpqEs+OfVT6Udviyigwegh6416sG5MeaBY_3mf5mpJPw@mail.gmail.com> <CAAObRXK36VVFTXd=_SNje4z3muBvUL3SZa0PmONgu50-V1r7ug@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/46aaPfjJ7UaTNnP-2QNS0iQOT-Q>
Subject: Re: [DNSOP] If DNSSEC signatures do not validate ...
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Apr 2020 15:22:38 -0000

On Tue, 28 Apr 2020, Davey Song wrote:

> OK. It make sense to try every name servers to defend the case if the adversary only intercept one path. But the adversary also know the resolver will
> retry other servers. So a smarter adversary may intercept in the aggregated upstreaming path where all queries are sent. 

Then those adversaries that seem able to block any packets from reaching
you, can also block 8.8.8.8 and all known DoT and DoH servers by IP ?
And send you RST packets.

But if the attacks have that much power, they can also just RST all your
TLS connections to webservers and just let let you have your DNS
packets.

I think you need to be a little more exact on the attack you are
describing and what would be a sensible defense.

Paul