Re: [DNSOP] DNSSEC as a Best Current Practice

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sun, 27 March 2022 13:24 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 BBBB33A07A9 for <dnsop@ietfa.amsl.com>; Sun, 27 Mar 2022 06:24:28 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 l-4gtWST5szi for <dnsop@ietfa.amsl.com>; Sun, 27 Mar 2022 06:24:27 -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 C3EB53A073E for <dnsop@ietf.org>; Sun, 27 Mar 2022 06:24:24 -0700 (PDT)
Received: (qmail 46710 invoked from network); 27 Mar 2022 13:20:29 -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; 27 Mar 2022 13:20:29 -0000
Message-ID: <fff12041-aa37-f601-e5f6-66289a47ad20@necom830.hpcl.titech.ac.jp>
Date: Sun, 27 Mar 2022 22:24:21 +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
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>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <27d48ac5-2132-4b8d-be28-2f5b4a07ca28@Spark>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dTvnyDX42pn843ZaczoFLsLNVYs>
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 13:24:29 -0000

Dr Eberhard W Lisse wrote:

> I am also struggling finding your point.

More than 20 years ago, I noticed that PKI, including DNSSEC is, not
at all, cryptographically secure subject to MitM attacks on CA or
zone chain, whichI pointed it out for every several years in this ML.

Initially, I was puzzled why PKI is operationally so complicated
with a lot of parameters without any theory to properly determine
proper values for the parameters, which turned out to be that
there can not be any proper values for the parameters because
PKI is not cryptographically secure.

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.

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.

Diginotar also demonstrated that costly physical security similar
to DNSSEC TLDs can be compromised and is not secure at all.

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.

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.

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

					Masataka Ohta