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

Paul Wouters <paul@nohats.ca> Tue, 28 April 2020 13:34 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 E214A3A1519 for <dnsop@ietfa.amsl.com>; Tue, 28 Apr 2020 06:34:46 -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 4yYTOOaXIy8k for <dnsop@ietfa.amsl.com>; Tue, 28 Apr 2020 06:34:43 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 928C93A151F for <dnsop@ietf.org>; Tue, 28 Apr 2020 06:34:42 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49BN0v0283zDDq; Tue, 28 Apr 2020 15:34:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1588080879; bh=ZeB7SPUkzIhCuDxGNFUCUXlKfJcrrCBb8l85h7tPjuw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JsOeTXvK+CAn40dAvyReU6qB8KH9uCckHsl7TdGLGE0qp9/MLP8dFVSnlyhi2f2H1 GmCpMOx7XtZEWGWd3dhCFrw/8+jV3+mWsbGjBU0kirEZlH6aCxFJ768+6mD35SIKux YJs36gmR+HVOh/TlKFoEp0NG4uyAvtDU94XRRUuE=
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 DoMtJZh5iXjN; Tue, 28 Apr 2020 15:34:37 +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 15:34:37 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id ABF1B60009B6; Tue, 28 Apr 2020 09:34:36 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A8C6823D186; Tue, 28 Apr 2020 09:34:36 -0400 (EDT)
Date: Tue, 28 Apr 2020 09:34:36 -0400
From: Paul Wouters <paul@nohats.ca>
To: Davey Song <songlinjian@gmail.com>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <CAAObRXL-hFZ1jFo8dW-+M+2SR8gJ7vypKLMaJNuQJBvCsdJ0Gg@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.2004280931470.18623@bofh.nohats.ca>
References: <CAAObRXL-hFZ1jFo8dW-+M+2SR8gJ7vypKLMaJNuQJBvCsdJ0Gg@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/RbsMQek5ER7pdHfachh3egmdb9k>
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 13:34:47 -0000

On Tue, 28 Apr 2020, Davey Song wrote:

> As far as I know, in DNSSEC the validating resolver is able to identify a Bad response if signatures do not validate. But it unable to retrieve the good
> one for stub resolver if there are other alternatives. 

I think you mean if you receive a BOGUS validation result (eg missing
RRSIG records, or otherwise are not getting the records needed for proof
of non-existance or signatures. In that case, I think the existing
DNS protocol already tells you to try other servers?

> I'm thinking about a draft proposal if signatures do not validate, the validating resolver can try other resolution path like DoT or DoH directly to
> authoritative servers or other public DNS servers which open the DNS encryption service. It aims to  work around the resolution path where DNS
> hijack happened. 

This looks exactly what the ADD working group is working on? The only
difference is instead of prefering some more private mechanism, you
only prefer the more private mechanism upon some failure case? And
I think that really comes down to the original politics of who decides
where and when to not use the local resolver. And we are already in
a heavy stale-mate there.

Paul