Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt

Paul Wouters <paul@nohats.ca> Thu, 07 May 2020 04:06 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 45D453A0823 for <dnsop@ietfa.amsl.com>; Wed, 6 May 2020 21:06:49 -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 qnqM_y1nWnmU for <dnsop@ietfa.amsl.com>; Wed, 6 May 2020 21:06:47 -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 5539F3A0821 for <dnsop@ietf.org>; Wed, 6 May 2020 21:06:46 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49HfzS0Q1Hzp9; Thu, 7 May 2020 06:06:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1588824404; bh=bIwmqfrM2MycXBityfMzazbd5FOUm9YedH3nj3gu6qQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=q4JMheI28G6hI3LdKUJFGMEmjNYbazUD3+GmFkKHbdb1S+rxZ48kQew9ClZtRyt9u xlIFLFHC4sEM/q6DIHPeC5duB3K2Jt31tCYqL3mkpg35OJ+S1RX0EcmJIDxCP83dxM RvtXydeIsSRCf4mHp8ktQaZyE1LFK4YPDLDyhQKE=
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 QcJ8b57QvoCO; Thu, 7 May 2020 06:06:42 +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; Thu, 7 May 2020 06:06:42 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9BD7F6020D9F; Thu, 7 May 2020 00:06:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 988F866B7C; Thu, 7 May 2020 00:06:41 -0400 (EDT)
Date: Thu, 7 May 2020 00:06:41 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: =?ISO-8859-2?Q?Vladim=EDr_=C8un=E1t?= <vladimir.cunat+ietf@nic.cz>
cc: dnsop@ietf.org
In-Reply-To: <44bd31fb-e53c-7f17-bedb-465d132a7ef5@nic.cz>
Message-ID: <alpine.LRH.2.21.2005062354000.536@bofh.nohats.ca>
References: <158828214716.7748.7938281376930754647@ietfa.amsl.com> <44bd31fb-e53c-7f17-bedb-465d132a7ef5@nic.cz>
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/s70uJ5QMiOEX0jeeqsNftK6oWAs>
Subject: Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt
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: Thu, 07 May 2020 04:06:50 -0000

On Tue, 5 May 2020, Vladimír Čunát wrote:

> 1. Validation without logging.
> At the end of 3.1 you claim that mode is still useful.  When I focus on
> intentional attacks, signing a malicious DS seems among the easiest
> ones, and that can't be detected without the attacked machine doing
> logging (the DS might be served to specific targets only).

Serving to specific targets is getting harder and harder, because we
see more and more people defaulting to not use their DHCP obtained DNS
server. And when picking another non-local server, DoH or DoT is
preventing man in the middles from replacing DS records in responses.

So they would either have to publicly replace the DS for everyone, or
add a DS for everyone. That becomes a very visible event.

>  Consequently
> I'm doubtful about implementing and deploying such a "half-secure"
> approach in validators, especially as the RFC draft feels very hazy
> about the way logging might be done.

This draft is not trying to specify the DNSSEC logging. But I described
things in earlier messages already. The way we had our experimental
logging done with Linus Nordberg, is that we used dnssec-chains (RFC
7901) as the record format for the DNS data, wrapped in the regular
append-only style transparency log using merckle trees.

> 2. Amount of logging.
> The draft implies it would allow to very significantly decrease the
> amount of data that needs to be logged.  Zones without the bit perhaps
> won't be logged, but I hope that wasn't a significant point.

Right. Anything without DNSSEC cannot be helped.

>  The draft
> doesn't explicitly say what would be logged; my conclusion for zones
> using this bit is that "we" would need basically any authoritative (i.e.
> signed) data except for NSEC* records that have DS bit and miss opt-out
> bit.  Am I missing something?

You would need to log the DS, and possibly log the denial of existence
of the DS record. If the delegation-only bit it set, you can further log
anything that should not have been signed but was signed, so any records
outside of the apex that are signed. But this data is already dropped
by supporting validators as BOGUS, so those hooks could be used for
logging it. It should not be common. As soon as you see any of this,
the zone is basically malicious and a public inquery should be started.

As for opt-out, again zones without DNSSEC cannot be helped. Zones with
DNSSEC, you log the DS and the denial of existence of DS.

When to log this is a bit similar to the CT gossip protocol that was
proposed. You log things when you see a modification (no-DS to DS or
visa versa, or old-DS to new-DS). But that is outside the scope of
this draft.

>  As for large TLD zones, even in best
> currently practical case the reduction seems by less than a half? 

You are missing the point that currently resolvers cannot determine if
a TLD is delegation-only. For example, if you assume all TLDs are
delegation-only, you break things, such as .de where registrations can
be done without NS record, straight signed by the .de key. The point of
the DNSKEY DELEGATION_ONLY flag is to indicate that yes this zone does
not do this and THUS you can log these things when you see them.

> (missing DS bits in about half delegations) I expect that the whole
> trust chains to the logged records are also needed, so that the logger
> can prove they haven't forged the records.

Yes, you log an RFC 7901 chain from the root to the record in question
you want to see logged. Not only to prevent the logger from lying, but
also to proof you have the top-most offender in the chain.

Paul