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

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Mon, 03 August 2020 09:00 UTC

Return-Path: <vladimir.cunat+ietf@nic.cz>
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 3344E3A0CBE for <dnsop@ietfa.amsl.com>; Mon, 3 Aug 2020 02:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.945
X-Spam-Level:
X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 ul2QdLvj5Kyq for <dnsop@ietfa.amsl.com>; Mon, 3 Aug 2020 02:00:38 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 A19B03A0CBC for <dnsop@ietf.org>; Mon, 3 Aug 2020 02:00:36 -0700 (PDT)
Received: from [192.168.6.10] (nat-45.starnet.cz [178.255.168.45]) by mail.nic.cz (Postfix) with ESMTPSA id 82B05140AA2; Mon, 3 Aug 2020 11:00:34 +0200 (CEST)
To: Paul Wouters <paul@nohats.ca>, dnsop <dnsop@ietf.org>
References: <5f5e9cb9-bf55-8947-85b8-2bb49d48f0bc@nic.cz> <8234C174-E1EC-49DE-A503-CF45D33B4A78@nohats.ca>
From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
Message-ID: <eeb7a81d-142f-9e70-e9bc-b788faf9a230@nic.cz>
Date: Mon, 3 Aug 2020 11:00:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.1.0
MIME-Version: 1.0
In-Reply-To: <8234C174-E1EC-49DE-A503-CF45D33B4A78@nohats.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xuoMWQM4YwkrcTyjxHVX0ZMxMJU>
Subject: Re: [DNSOP] =?utf-8?q?draft-ietf-dnsop-delegation-only=E2=80=8B=3A_e?= =?utf-8?q?xchanging_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: Mon, 03 Aug 2020 09:00:40 -0000

On 7/31/20 2:34 PM, Paul Wouters wrote:
> 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.

Right, I didn't fully realize that it's impossible to achieve that much
by technical means.


>> 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 considered logging among those "necessary" parts, which might've been
a bit of black&white point of view.


>> 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.

Thanks, I think I see better now - so these are gradual steps to make
this kind of "attacks" harder but never able to completely eliminate
them (unfortunately).

I agree this RFC (without logging) appears relatively cheap, so if it
can improve trust, I expect the main stumbling point is willingness of
important zones to deploy it (which could include some technical
obstacles) and that should be better explored before publishing as RFC. 
Right now I can't see a better first step towards this draft's goal than
the draft itself.


Detail: removing that exception for the root might be nice.  That sounds
possible if the root KSK lifetime really becomes only a couple years
(which I haven't seen promised yet).  As long as the exception is there,
the paragraph about the root rollover feels weird.

--Vladimir