Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Joe Abley <jabley@hopcount.ca> Thu, 30 July 2020 20:33 UTC

Return-Path: <jabley@hopcount.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 550DE3A0CA0 for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 13:33:31 -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=hopcount.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 JXJLhI8uNAco for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 13:33:29 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31B73A0C9F for <dnsop@ietf.org>; Thu, 30 Jul 2020 13:33:29 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id 6so21422789qtt.0 for <dnsop@ietf.org>; Thu, 30 Jul 2020 13:33:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7KuM9JdYXZzOye4LvhgReyf3Gfzk0rTQw3ryu86M/aA=; b=nOvSDzEIatnbg6PX1+G97VcA/IoZewP+ivmf1n6OPqBFbCH7qTMiXbxtk2gXjl5mjr 3o8E/v31yM+CD5Oc6tPRo+Mw7YFj/9k6xWqJ7IewRDh+IcuTPfjl2Vm2fFCXBvF2mWkF 50lpPQEfN0NElV3u9Darp1UYRHrb7IqO33/Yw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7KuM9JdYXZzOye4LvhgReyf3Gfzk0rTQw3ryu86M/aA=; b=PE0qVHtkZwVlwBn86PTqxBM4/TpIvUXdU9QL3ZbPPCMeb8CNzO4aJ6VvUCt1pR4czz ZMeouiXxpDgp2ticd0HF8BDRfNSqPI92pbyu/FxtJHPEazTAOJaHDi46lTqCKi6tggm2 +VhCRpUgce7XoraNBSSMcsfXoHEM7FZisNlxj+m+zc1CnZsR5F162ti5P2etqu+sSV+N EgUeWxBw/4FvuCej+SSTDrm5jQ8aouIM3K/VQkRpaOTTBz51mquBNJyaaqJKojwu6Xgg i/pMChy5bbp1blKD7d07d1s47oQPcWKlG8fV+Bnb+TNPDgH7/K5xqx5KRnxifCoZhid1 87lw==
X-Gm-Message-State: AOAM532w3/6WH8nLpYJzDn0RizviHw7W3HoybBRq2WizRT6hVFMAIKiK Hg/6eHx/ymmFH/uzNzYsJ6ylFA==
X-Google-Smtp-Source: ABdhPJyrWtnGqjiIJH5Nqhon44cOi2O8pkECXWQzxQAxkPX3Eup9eH3hoaldZ7QITQ3Yj2KnxXpucQ==
X-Received: by 2002:aed:20e5:: with SMTP id 92mr488863qtb.388.1596141208465; Thu, 30 Jul 2020 13:33:28 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e784:c7:cc64:e39d:b3f2:81cb? ([2607:f2c0:e784:c7:cc64:e39d:b3f2:81cb]) by smtp.gmail.com with ESMTPSA id c205sm5234876qkg.98.2020.07.30.13.33.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2020 13:33:27 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <alpine.LRH.2.23.451.2007301546120.418549@bofh.nohats.ca>
Date: Thu, 30 Jul 2020 16:33:26 -0400
Cc: Ben Schwartz <bemasc@google.com>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F8A7305-44B0-40A3-9639-B194A928168B@hopcount.ca>
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com> <05f9f7ce-1bb7-b195-1be5-4db4c13b3145@nic.cz> <alpine.LRH.2.23.451.2007301253530.416340@bofh.nohats.ca> <CAHbrMsDoYO_hsuCjLeg9pwut_dB703uJ6tgGV0NDq_5sSUWJwA@mail.gmail.com> <alpine.LRH.2.23.451.2007301546120.418549@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IHKXpb2-r-O5acag-2uBnSL4gZ8>
Subject: Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
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, 30 Jul 2020 20:33:31 -0000

Hi Paul,

On 30 Jul 2020, at 16:28, Paul Wouters <paul@nohats.ca> wrote:

> On Thu, 30 Jul 2020, Ben Schwartz wrote:
> 
>>      I do not believe that is correct. The first and foremost purpose is for
>>      the bit to signal the parent zone's behaviour in a public way that
>>      prevents targeted / coerced attacks from the parent.
>> I would love to see some more description of these attacks in the draft.
> 
> I'm a bit confused that you think describing that in more detail helps.
> We are talking about fairly simple records like the .ca zone publishing:
> 
> 
> 		nohats.ca	IN	DS	blob + RRSIG(key of .ca)
> 		nohats.ca	IN	NS	ns0.nohats.ca.
> 		ns0.nohats.ca	IN	A	193.110.157.101
> 
> while also (targetted per victim or within a certain time frame) publishing:
> 
> 	_443._tcp.nohats.ca	IN	TLSA	blob   + RRSIG(key of .ca)
> 		www.nohats.ca	IN	A	<malicious IP>  + RRSIG(key of .ca)
> 		nohats.ca	IN	MX 0	tapbox.ca.  + RRSIG(key of .ca)
> 
> But I can add this if you feel it helps.

Usually when I do risk assessment exercises in order to determine what threats are worth spending money on to mitigate, we throw out those that are thought to be very unlikely to occur or very expensive to mitigate, since there are usually better things to focus on.

Have you done any thought on that kind of risk analysis for this proposal?

For example, has there ever been an example of this attack happening, or are the contractual or commercial pressures to behave well considered by someone to be inadequate? On the expense side, what is the cost of implementation to the degree that the mechanism actually provides some benefit?

My sense is that this is a nice idea in theory but doesn't solve a problem that anybody actually has, and the camel is starting to look a little bit fraught. But I don't think any proposal should succeed or fail based on anybody's uninformed sense, hence the request for more data.


Joe