Re: [DNSOP] draft-ietf-dnsop-delegation-only​: exchanging DS set

Paul Wouters <paul@nohats.ca> Fri, 31 July 2020 12: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 7C2E13A07E8 for <dnsop@ietfa.amsl.com>; Fri, 31 Jul 2020 05:34:24 -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 FCKD2xYimjj7 for <dnsop@ietfa.amsl.com>; Fri, 31 Jul 2020 05:34:22 -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 50AAD3A08AE for <DNSOP@ietf.org>; Fri, 31 Jul 2020 05:34:21 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BJ6Cw0tTYz9ZP; Fri, 31 Jul 2020 14:34:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1596198860; bh=4diAto+kMfOFcY7hiPcaeNxrNessy7qQOvSeUwFjnTs=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=X7367WG7nor9RiCT1tfvt7rnmx0ErxZBVMp8PSmCJXa20DOszBUUM+DIBE9sw+Szr NWBFFdUnb5rSycHO5J4Wvw5DvUmF/HdqXP2EfyNuW/K7rdkVqK2Givt4fpAkwCM5sl u0lsMRX2YHAodsQCjgEqr6ajpkDR+VfS5MnnMBrk=
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 HOwOPukJPQz3; Fri, 31 Jul 2020 14:34:18 +0200 (CEST)
Received: from bofh.nohats.ca (unknown [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 31 Jul 2020 14:34:18 +0200 (CEST)
Received: from [193.110.157.210] (unknown [193.110.157.210]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 29AE56029A48; Fri, 31 Jul 2020 08:34:17 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Fri, 31 Jul 2020 08:34:15 -0400
Message-Id: <8234C174-E1EC-49DE-A503-CF45D33B4A78@nohats.ca>
References: <5f5e9cb9-bf55-8947-85b8-2bb49d48f0bc@nic.cz>
Cc: DNSOP@ietf.org
In-Reply-To: <5f5e9cb9-bf55-8947-85b8-2bb49d48f0bc@nic.cz>
To: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0F9aoRCzzeVqE9BZhpBgHuBSYUA>
Subject: Re: [DNSOP] draft-ietf-dnsop-delegation-only​: exchanging DS set
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: Fri, 31 Jul 2020 12:34:25 -0000

On Jul 31, 2020, at 05:06, Vladimír Čunát <vladimir.cunat+ietf@nic.cz> wrote:
> 
> Hello dnsop.
> 
> So far it's been clear.  But now... how do we know that this fake
> victim.evil DS set was not submitted by the registrant?  I assume every
> registrant is supposed to watch the logs from everyone for such fakes? 
> Sounds OK-ish, so if they do find an incorrect set, they know that the
> registry is "bad" (intentionally or not), but how can they prove *to
> anyone else* that they did not submit it to the registry?

A few things could be done.

The client could publish a CDS set which would never include the rogue DS.

The log could look and explicitly warn for “fast DS changes and undo”, since this would be flipping back and forth.

The process of a rogue parent is not a purely technical one. It can include a legal system, a payment dispute, and many other things.

Per definition, it will be a manual process to confirm if a “changed child” is a legitimate change or not. Logging helps this process.

But remember, forcing a rogue parent into this mode is already a win we currently don’t have.

> Without that ability I'd still feel quite powerless as a registrant, and
> I currently can't see a nice way of solving that.  It would be nice if
> there was a way we could get the ability in future (for reasonable costs).

Some DS flip flopping can be detected so a warning can be issued to the registrant or a public entity. So the registrant isn’t entirely powerless. But contacting the registrant is still tricky if you cannot trust the info from the parent (eg whois)

> I do support the aims of the draft, but so far the plan doesn't make me
> feel safer, and deploying *all* the necessary parts doesn't seem very
> easy either. 

All the necessary parts is one bit and a few lines of code and a tool option. It’s not that much. The real work happens by log operators.


> I'm sorry if I've missed something.  Well, *my* trust
> isn't really important here, so if dnsop thinks the approach will
> increase trust of some more important parties...

Forcing parents into mucking with their customer DS records itself is a big win. The parent now has an Enigma Problem and is more or less guaranteed to be found out it’s cheating it’s own published policy.

Paul