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
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
