Re: [DNSOP] DNSSEC as a Best Current Practice

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Mon, 11 April 2022 13:19 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 EEA413A10F7 for <dnsop@ietfa.amsl.com>; Mon, 11 Apr 2022 06:19:47 -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 sWOSXhUNDlwJ for <dnsop@ietfa.amsl.com>; Mon, 11 Apr 2022 06:19:43 -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 BC0AE3A10DC for <dnsop@ietf.org>; Mon, 11 Apr 2022 06:19:42 -0700 (PDT)
Received: (qmail 32440 invoked from network); 11 Apr 2022 13:15:30 -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; 11 Apr 2022 13:15:30 -0000
Message-ID: <d6d29d9f-99e2-ddf8-d828-3bf5cbc4bd69@necom830.hpcl.titech.ac.jp>
Date: Mon, 11 Apr 2022 22:19:38 +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: Paul Wouters <paul@nohats.ca>, "dnsop@ietf.org WG" <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> <350d8ab8-0477-b656-8b08-56f7561a7fda@necom830.hpcl.titech.ac.jp> <CAH1iCiqkAPHq1QBKdkbh86j8UhimjEMG9DU15O9Tkch4BedBjg@mail.gmail.com> <0e2dffab-6afc-b1b6-9028-175f89f0d29e@necom830.hpcl.titech.ac.jp> <b3bf6748-be6d-a287-27e4-87af36ab10@nohats.ca>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <b3bf6748-be6d-a287-27e4-87af36ab10@nohats.ca>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UIZ_LxkyTflYwZxiDajBLeDVQVQ>
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: Mon, 11 Apr 2022 13:19:48 -0000

Paul Wouters wrote:

>> First, "CA" is terminology not specific to WebPKI, whatever it
>> means, but PKI in general including DNS. That is, a DNSSEC TLD is a
>> CA.

> This is incorrect.

First, thank you very much for an evidence that discussion is
still continuing.

Anyway,

	https://en.wikipedia.org/wiki/Public_key_infrastructure
	In cryptography, a PKI is an arrangement that binds public
	keys with respective identities of entities (like people
	and organizations). The binding is established through a
	process of registration and issuance of certificates at
	and by a certificate authority (CA).

Do you still insist that CA is terminology specific to WebPKI
not PKI in general?

> In your favourite
> terms, diginotar as DNSSEC entity would have only been able to mess
> up .nl and not any other TLD,

The fact is that diginotar actually supported government PKI of NL,
which is why the problem is so serious.

As for DNSSEC, we can be sure that national TLDs are not so secure.

> You keep conflating operational security with protocol security, and 
> insisting protocol security is not needed because operational
> security is always the weaker link.

Your previous statement:

: At the TLD level
: and higher, this involves HSMs and physical access restrictions
: using a "four eyes minimum" approach.

is an evidence that operational security is required because
DNSSEC is not secure merely by protocol security.

I don't deny DNSSEC has some protocol security, but the
problem is that it is not complete and useless without
operational security.

> But you are not offering any alternative ("larger plaintext cookies" 
> is not a security protocol)

Cookies and DNSSEC, subject to active MitM attacks, are
equally secure.

> So please tell me why you use TLS at all? Why not force your browser > into only using port 80? You can also use extra long HTTP header
> cookies.

With compromised intermediate CAs and ISPs, TLS and plain http with
long enough cookies are equally secure against active MitM attacks.

The difference is that, unlike cookies, TLS is safe against passive
MitM attacks of packet snooping.

So?

						Masataka Ohta