Re: [DNSOP] DNSSEC as a Best Current Practice

Mukund Sivaraman <muks@mukund.org> Thu, 14 April 2022 14:17 UTC

Return-Path: <muks@mukund.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 D22C03A1B45 for <dnsop@ietfa.amsl.com>; Thu, 14 Apr 2022 07:17:54 -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, 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=mukund.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 7qQkdVWzdlNa for <dnsop@ietfa.amsl.com>; Thu, 14 Apr 2022 07:17:49 -0700 (PDT)
Received: from mx.mukund.org (mx.mukund.org [144.76.148.120]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5273A1A14 for <dnsop@ietf.org>; Thu, 14 Apr 2022 07:17:48 -0700 (PDT)
Date: Thu, 14 Apr 2022 19:47:43 +0530
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mukund.org; s=mail; t=1649945866; bh=G2KSzoXRperQNV7SdFrwaL+nimPt4AnHRt7R3Hehpwg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LvYx4Xj3jRvn1/T3UC0xv4PVx1A6kHYHFR8cz4iARaFKMB9xc+d+/tvH16La+hbhH iVesbMHAB7p2Dn7Ch81zeGbgngsyyKkf0IpOcQuvEAGdPC9SKAUtZcxqCPutSwXCY0 cgqIROGDmwX4L/IYL0buY4s9AHoLQcXfqrUy+KCE=
From: Mukund Sivaraman <muks@mukund.org>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: Paul Wouters <paul@nohats.ca>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Message-ID: <YlgtBwre0T/OZh4C@d1>
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> <dc4a21ee-cc4c-9cb1-9a56-b4992201378c@necom830.hpcl.titech.ac.jp> <c47227f6-5556-1e75-3a48-8aa6bad498ac@nohats.ca> <61b46811-fa52-5ec0-e16b-eb7e9d9560d4@necom830.hpcl.titech.ac.jp>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="l/tiCIbo97QvM9rh"
Content-Disposition: inline
In-Reply-To: <61b46811-fa52-5ec0-e16b-eb7e9d9560d4@necom830.hpcl.titech.ac.jp>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cf7Pc8jY8ezEccJhlAqNCD4T73s>
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, 14 Apr 2022 14:17:55 -0000

On Thu, Apr 14, 2022 at 08:55:34PM +0900, Masataka Ohta wrote:
> Paul Wouters wrote:
> 
> > > I can't see any reason why you think the root zone is
> > > more secure than TLDs, especially because, as I wrote:
> > 
> > Because I am informed about their operational procedures and I
> > contributed to the technical design as one of the for the DNS Root Zone
> > Key-Signing-Key of the Root Zone Rollover advisory group.
> 
> So, you mean the root zone is secure because of "operational
> procedures", which is not cryptographic.
> 
> Thank you very much to have confirmed my  point that DNSSEC
> is not cryptographically secure.
> 
> Your point is, surely, conclusive.
> 
> > I was also responsible for the design and implementation of a large TLD
> > fully implementation redundant DNSSEC signer solution.
> 
> So, the root and TLD zones are as secure as diginotar.
> 
> > I talked to a lot of TLD operators at ICANN during my term as the
> > IETF Liason to the ICANN Technical Expert Group.
> 
> I'm sure none of them were aware that PKI is not cryptographically
> secure. So?
> 
> >> :  Third, all the CAs, including TLDs, pursuing commercial
> >> :  success have very good appearance using such words as
> >> :  "HSMs" or "four eyes minimum". That is, you can't
> >> :  compare actual operational/physical strength from
> >> :  their formal documents.
> >
> > This is an anecdote, that a logical reasoned argument.
> 
> That's your anecdote to mention "HSMs" or "four eyes minimum"
> proven to be useless by diginotar.

(From your posts in this thread, you appear well convinced that
 cryptography is broken due to operational weaknesses in securing access
 to signers. So I don't know if this will convince you differently.)

HSMs don't have anything to do with DNSSEC's security guarantee. Use of
HSMs is an implementation/operational detail. An operational decision
leading to weakness doesn't mean that the cryptographic foundation of
DNSSEC is broken or cannot be secured. So it's not entirely correct to
say "DNSSEC is not cryptographically secure."

On the topic of leak of private key or access to signers by rogue
parties, there have been experiments to use threshold cryptography with
DNSSEC where the actual private key is not present in any single form,
but distributed as "key shares" among N parties, and "signature shares"
are generated separately by M out of N parties and combined to make the
final signature. The private key does not exist in one place to be used
by bypassing operational security mechanisms.

E.g., see this implementation by NIC Chile: https://github.com/niclabs/dtc

There has also been a previous C/C++ implementation by them. These
provide a PKCS11 implementation that can be used by existing DNSSEC
signing tools that support the PKCS11 library interface.

They use the RSA threshold signatures mechanism designed by Victor
Shoup, which is compatible to be used for PKCS#1 v1.5 signature
generation as used in the DNSSEC RSA algorithms, i.e., it can be used in
DNSSEC currently within the RSA algorithms.

https://www.shoup.net/papers/thsig.pdf

There are other methods for ECDSA, and some standardization process at
NIST.

The army can be sent to the house of every member of "N eyes minimum"
group to hit on the knuckles repeatedly until either the key cracks or
their knuckles crack. Bribing with carrots also works sometimes.

https://xkcd.com/538/

So this isn't an attempt to convince you that security is relative. :)

		Mukund