Re: [DNSOP] DNSSEC as a Best Current Practice

Paul Vixie <paul@redbarn.org> Sun, 27 March 2022 16:13 UTC

Return-Path: <paul@redbarn.org>
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 2364C3A0F61 for <dnsop@ietfa.amsl.com>; Sun, 27 Mar 2022 09:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.org
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 UF9OfP2QaQ47 for <dnsop@ietfa.amsl.com>; Sun, 27 Mar 2022 09:13:03 -0700 (PDT)
Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E059A3A0F9D for <dnsop@ietf.org>; Sun, 27 Mar 2022 09:13:00 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id 5C1CB1A2423; Sun, 27 Mar 2022 16:12:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1648397577; bh=SZ3seeHLq9RJQKZhxEciLA0spqB46CQ8ufTHzCC1Osw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Co3WmtpGu2tAOIGWSqacE6u+vv9qjqhKcChxf5sP2BQY1uiTwWU4Z+2W80AfgyfuW d0oNye7zljonO/EJGnvEcL6O0ASP02ir69DOsoRzN7fP4ujMSRvqXgxyhdHwujQQCB V0MiaSjXMP2dRihyzx6Xslt5iazP4M+6xrf8CvaQ=
Received: from [24.104.150.147] (dhcp-147.access.rits.tisf.net [24.104.150.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 3EA217597D; Sun, 27 Mar 2022 16:12:57 +0000 (UTC)
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: dnsop@ietf.org
References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <A9F689C9-4ABF-4947-AA6B-56E2F0C17D13@nohats.ca> <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp> <27d48ac5-2132-4b8d-be28-2f5b4a07ca28@Spark> <fff12041-aa37-f601-e5f6-66289a47ad20@necom830.hpcl.titech.ac.jp>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <0197b013-724d-fec7-9b14-dbfee6a96e77@redbarn.org>
Date: Sun, 27 Mar 2022 09:12:57 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.54
MIME-Version: 1.0
In-Reply-To: <fff12041-aa37-f601-e5f6-66289a47ad20@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TX1A-lfxXTemRNVVTLM56M64k1o>
Subject: Re: [DNSOP] DNSSEC as a Best Current Practice
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: Sun, 27 Mar 2022 16:13:10 -0000

(sunday long read, beware.)

Masataka Ohta wrote on 2022-03-27 06:24:
> Dr Eberhard W Lisse wrote:
> 
>> I am also struggling finding your point.
> 
> ...

i am not eberhard, but:

> If some CA between you and your peer is compromised, communication
> between you and your peer is compromized.
> 
> About 10 years ago, diginotar demonstrated that attack on
> intermediate CAs possible.

i consider that your arguments about PKI CAs apply to DNSSEC in the form 
of static and dynamic trust anchors, those being the root key, and the 
set of DS RRsets in a validation chain. it is always the case that if a 
CA is compromised then security is compromised -- this is axiomatic. in 
DNSSEC, with CA PKI interpreted as "the root key and every DS RRset", it 
is a large attack surface, larger even than in X.509. but if any PKI 
having a CA is insecure, then we must reason within that context. more 
"below".

> Another evidence for my point is that, DNSSEC assumes actually-not-
> so-strong but too costly physical security of intermediate zones,
> which means DNSSEC relies on too costly physical security of
> intermediate zone and is not cryptographically secure.

i think the specific reliance on physical security is irrelevant. i know 
of secure digital vaults, and i know of insecure physical vaults. we can 
reason about the vulnerability of a PKI CA (which in DNSSEC takes the 
form of the root key and all DS RRsets) without specificity as to cause. 
more "below".

> ...
> 
> It is true that plain DNS is not so secure because birthday
> attacks from anyone, not necessarily MitM, can be successful
> because of too short (16bits) message IDs.
> 
> However, that DNSSEC is not cryptographically secure subject
> to MitM attacks means operating costly DNSSEC only to keep
> it subject to MitM attacks is not only meaningless but also
> harmful to let society give false sense of security as if
> DNSSEC were cryptographically secure.

i think there are two assumptions in the DNSSEC design which go to your 
assertion of meaninglessness. first, birthday attacks of the kind you 
describe are essentially hop by hop (transactional), and any defense 
against only hop by hop attacks will necessarily leave open data 
integrity vulnerabilities in the end to end data path. for example, if 
we had larger message IDs we would still be vulnerable to data 
modification attacks by RDNS operators, or by BGP injections which 
change the identity of an IP address. therefore pure hop by hop security 
features were out of scope for the DNSSEC effort.

second, a general and effective prohibition against end to end attacks 
can be made proof against hop by hop attacks also. DNSSEC attempts this. 
only by data compromise against the PKI CA (which for DNSSEC means the 
root key and any DS RRsets needed for a particular validation) can false 
data be injected by a "hop" in the hop by hop system without detection. 
since this is possible, it should be noted, and caution be exercised. 
this caution includes transparency by each CA operator (the root, and 
every DS RRset owner) as to the methods of generating and using secret 
keys associated with a CA element. this is often "security theater" as 
originally defined by bruce schneier:

https://www.schneier.com/essays/archives/2009/11/beyond_security_thea.html

however, "security theater" is not an unalloyed failure:

https://healthguardsecurity.com/bruce-schneier-ted/
https://www.cnet.com/culture/bruce-schneiers-new-view-on-security-theater/

accordingly, DNSSEC admits to the inevitability of "security theater" 
but considers it, along with the inevitability of compromise in any PKI 
CA system, to be design inputs and not design constraints. more "below".

> So, let's recognize that DNSSEC is not cryptographically
> secure not worth its so high cost and move on to make
> DNS with longer message IDs even though DNS must, with
> or without DNSSEC, be subject to various MitM attacks.

this proposal is out of scope for the reasons described above.

> Which of my points, if any, are you saying, can not be
> understood by you not so clealy?

we (you and i) have discussed this on the record several times in the 
last 25 years, and i think i have always understood your concerns. in 
fact i share your concerns, but not your conclusions.

DNSSEC's focus is on end to end data integrity, and handles hop by hop 
data integrity issues by side effect. DNSSEC expects PKI CA compromise 
but makes such compromises transparent and observable. RFC 3833 should 
clarify any misunderstandings as to DNSSEC's intent and utility.

the impact of DNSSEC on relying parties is paramount. DNSSEC makes DNS 
more fragile, signaling failure in both attack scenarios and the more 
common operational error scenarios (wrong keys, expired signatures, and 
so forth). this fragility is another inevitability, another design 
input. no system of this kind will avoid rampant false negatives.

---

"below":

i think your primary argument is that DNSSEC solves the wrong problem, 
and the best formulation of that concern that i have seen is here:

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

while "best", this formulation does not reason from inevitabilities, and 
as such, is unpersuasive. i invite you to raise the bar and offer a more 
persuasive formulation. you have not done so here. the DNSSEC design has 
ruled out several alternatives, including "do nothing" and "handle only 
hop by hop attacks". i don't think you would get traction by arguing for 
either such alternative.

see also my remarks, and others', here:

> Date added: August, 2008
> 
> DNSSEC is a colossal flop, but not a mistake. It's an embarrassment, but we'd do it all again if we had to. It's late -- it was started years before the IPv6 effort but is (believe it if you can) even less finished and less deployed than IPv6. It's ugly and complicated and if we knew then what we know now we'd've scrapped DNS itself and started from scratch just to avoid the compromises we've made. But we didn't know then, etc., and what we have to do now is avert our gaze and fully deploy this ugly embarrassing thing.
> 
> Let me explain.
> ...

https://dnssec.net/why-deploy-dnssec

-- 
P Vixie