Re: [DNSOP] DNSSEC as a Best Current Practice

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Thu, 24 March 2022 10:55 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 787D53A1941 for <dnsop@ietfa.amsl.com>; Thu, 24 Mar 2022 03:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 d3ZW0RmfXxgt for <dnsop@ietfa.amsl.com>; Thu, 24 Mar 2022 03:55:26 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 4F7F13A1931 for <dnsop@ietf.org>; Thu, 24 Mar 2022 03:55:25 -0700 (PDT)
Received: (qmail 98593 invoked from network); 24 Mar 2022 10:51:31 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 24 Mar 2022 10:51:31 -0000
Message-ID: <9732682e-78e7-f6bf-84fc-685de22d5e12@necom830.hpcl.titech.ac.jp>
Date: Thu, 24 Mar 2022 19:55:19 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Cc: Ted Lemon <mellon@fugue.com>, Paul Wouters <paul@nohats.ca>
References: <57f1c37b-497c-e1a0-329c-4b9c8b7e197b@necom830.hpcl.titech.ac.jp> <A9F689C9-4ABF-4947-AA6B-56E2F0C17D13@nohats.ca>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <A9F689C9-4ABF-4947-AA6B-56E2F0C17D13@nohats.ca>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CkFrGC1wgrhPUXzlK-hqjQVdciM>
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: Thu, 24 Mar 2022 10:55:32 -0000

Paul Wouters wrote:

>>  If a parent zone administrator or some employee of it is 
>> compromised and forged zone delegation (with an IP address of a
>> forged nameserver using forged public/secret keys) is signed by a
>> valid key, it will not be noticed easily.

> Such an individual would have to get access, create the records, give
> them to others, who then have to on-path attack you. At the TLD level
> and higher, this involves HSMs and physical access restrictions using
> a “four eyes minimum” approach.

First, such impressively strong in depth security as strong
as those for nuclear reactors at Fukushima demonstrates a
fact that PKI is not cryptographically secure.

Not surprisingly, diginotar was equally strongly secure.

	https://roselabs.nl/files/audit_reports/Fox-IT_-_DigiNotar.pdf

	The main production servers of DigiNotar, including the
	CA servers and the accompanying hardware security module
	(netHSM), were located in a physically highlysecured
	room and in the Secure-net network segment.

	When a request was approved using the four-eye principle,

	In order for the CA software to automatically sign the
	certificate request, the appropriate private key
	needed to be activated in the netHSM. This was done
	by authorized employees by entering a smartcard
	into the netHSM combined with a PIN code.

So, DNSSEC TLDs are as secure as diginotar.

> At this point, it is easier to obtain physical access to the enduser
> device and compromise the OS, browser or webpki stack - DNS attack is
> not needed.

According to your theory, diginotar should not have been attacked.

It's like guaranteeing nuclear reactors protected by in depth
security never meltdown, proven by so many experts.

But, real security experts including bad guys are not hyped
by mere impression of security, which is merely not very
strong obscurity, which caused meltdown of diginotar.

So, may I volunteer to write a WG ID to obsolete DNSSEC
because it is only as secure as diginotar?

>> Merely because message ID is short, which can be improved, which is
>> a lot easier than deploying so costly DNSSEC.
> 
> You did not answer my earlier question on how you obtain this alleged
> secure IP address of all DNS nameservers you plan to talk to with
> "extra strong message ID".

I can't understand your question because upgrading all the
nameservers and resolvers operated by security aware
operators longer message ID capable is not so difficult.

 > Note also the same employee from above can tcpdump their nameserver
 > or read the RAM and give the extra strong message ID to the attacker.
 > So all attacks you attribute to DNSSEC apply to msg ID too.

So, just accept the reality that DNS, relying on zone chain,
which is subject to MitM attacks on intermediate zones, can not
be so secure regardless of whether you use DNSSEC or not.

>> If a resolver has some knowledge on contents of an attacked zone,
>> such as IP addresses of some servers or some DNSSEC keys, it can
>> detect a DNS (both resolver and DNSSEC) attack by comparing,
>> unless an attacker knows IP addresses of detecting resolvers and 
>> return unforged answers to them. So?
> 
> Forged answers require access to a private key. As stated those tend
> to be in HSMs or offline, 

HSMs? See above.

> so "attacker knowing IP address" is
> insufficient to forge answers.

I'm afraid you completely miss my point.

						Masataka Ohta