Subject: Re: [DNSOP] DNSSEC as a Best Current Practice

From: Masataka Ohta <[email-masked]>
Date: Thu, 7 Apr 2022 21:44:08 +0900

As I wrote:

>> 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.

> Not surprisingly, diginotar was equally strongly secure.

Are there anyone who still think DNSSEC were cryptographically secure
or had protected TLDs more securely than diginotar?

							Masataka Ohta

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Apr 2022 10:40:52 -0400 (EDT)

> or had protected TLDs more securely than diginotar?

Yes, everyone but you who participated in this thread.

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 8 Apr 2022 00:01:02 +0900

> Yes, everyone but you who participated in this thread.

That's simply wrong.

Are there anyone who still think, with reasons, DNSSEC were
cryptographically secure or had protected TLDs more securely
than diginotar?

						Masataka Ohta

---

From: Bjørn Mork <[email-masked]>
Date: Thu, 07 Apr 2022 17:56:04 +0200

> cryptographically secure or had protected TLDs more securely

Does DNSSEC make the TLD operators less trustworthy in your eyes?

Bjørn

---

From: Brian Dickson <[email-masked]>
Date: Thu, 7 Apr 2022 12:36:40 -0700

> or had protected TLDs more securely than diginotar?

I'm not sure why "thinks" enters into the conversation.

Nobody is entitled to their own facts, only their own opinions.

The facts are what matters here:

   - Each TLD has its own specific infrastructure, practices, etc.
      - Not all TLDs are equivalent for purposes of comparison of relative
      security (to each other or when compared to corresponding CA
infrastructure
      and practices)
   - Each TLD is a monopoly for the purposes of DNSSEC. The TLD operator
   has exclusive control over the delegations (including DNSSEC components) to
   registrants.
   - Registrants choose the TLD to use when they register a domain
   - Modulo the restrictions applicable to specific TLDs, the available
   choices of TLD are substantial
   - Each CA (including diginotar) is not a monopoly. Any CA can issue a
   certificate for any domain name.
   - Each CA has its own specific infrastructure, practices, etc.
      - Not all CAs are equivalent for purposes of comparison of relative
      security (to each other or when compared to corresponding TLD
      infrastructure and practices)

Taking these facts into consideration, the following assertions are clear
consequences:

   - Some CAs MAY have stronger infrastructure and practices than some TLDs
   - Some TLDs MAY have stronger infrastructure and practices than some CAs
   - It MAY be the case that some TLDs have infrastructure and practices
   that are not exceeded by those of any CA
      - Rephrased: some TLDs >= all CAs (which includes the boundary
      condition of "some TLDS == some CAs" without explicitly claiming that set
      is non-empty)
   - An attacker who wishes to compromise a domain via a WebPKI
   certificate, can choose which CA to use for this purpose
   - An attacker who wishes to compromise a domain via DNSSEC delegation,
   cannot choose which TLD to use for this purpose

Taken together, this means that as long as there exists any CA which is
weaker than some TLD, that automatically means that as a global system,
DNSSEC is more cryptographically secure than WebPKI.
And, given the facts regarding diginotar, this means that as a system,
DNSSEC is more cryptographically secure than diginotar.

QED

Registrants get to choose the TLD. Once that decision has been made, the
attacker has no alternatives to that TLD in terms of what would need to be
compromised to affect that specific domain.
The same is not true of CAs. Any CA being compromised places every domain
(regardless of TLD) in jeopardy, if the only protections on certificates
are those currently employed (e.g. CT, CRLs, OCSP).
If/when DANE (TLSA records) are used to improve certificate validation, the
choice of CA for the attacker to compromise is removed from the equation.

Brian

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 8 Apr 2022 14:04:57 +0900

> Does DNSSEC make the TLD operators less trustworthy in your eyes?

Good point.

A false sense of security that DNSSEC were
cryptographically secure motivates the operators
ignore DNSSEC operation rules, which are very
complicated and hard to follow, for relatively
strong physical security, which might be what
happened in diginotar.

With proper recognition that DNSSEC is not cryptographically
secure, operators won't violate rules for physical security
of DNSSEC and, instead, stop operating DNSSEC.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 8 Apr 2022 14:27:31 +0900

> I'm not sure why "thinks" enters into the conversation.

You may replace it with "dreams".

> The facts are what matters here:

The important facts are that:

	DNSSEC is not cryptographically secure.

	DNSSEC "at the TLD level and higher", which
	include root zone, is only as trustworthy
	as diginotar.

> Taken together, this means that as long as there exists any CA which
> is weaker than some TLD, that automatically means that as a global
> system, DNSSEC is more cryptographically secure than WebPKI.
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.

Second "any CA which is weaker than some TLD" means not
"cryptographically weaker" but "operationally/physically
weaker". As such, your conclusion can only be "DNSSEC is
more operationally/physically secure than WebPKI"

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.

Remember:

>> At the TLD level and higher, this involves HSMs and physical
>> access restrictions using a "four eyes minimum" approach. > Not surprisingly, diginotar was equally strongly secure.

					Masataka Ohta

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Apr 2022 14:31:37 +0000

Now that the document in question has been published as a WG document, it follows the standard IETF rules about consensus. As document author, I will follow those rules to the best of my ability.

I see a very strong consensus in this thread against the proposals from Ohta-san, so I think the thread can close. If Ohta-san wants to re-open the thread, he can do so with specific wording changes for draft-ietf-dnsop-dnssec-bcp and then we can see if there is consensus for those. Until then, though, maybe we can move to other topics.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Apr 2022 10:40:27 -0400 (EDT)

> it means, but PKI in general including DNS. That is, a DNSSEC

This is incorrect. Or rather, it is equivalent to a CA with a
very strict path constraint of being within the TLD. In your
favourite terms, diginotar as DNSSEC entity would have only
been able to mess up .nl and not any other TLD, if it had been
a "DNSSEC CA" instead of a "webpki CA". The hierarchical space
offers better security than the flat webpki.

> more operationally/physically secure than WebPKI"

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

But you are not offering any alternative ("larger plaintext cookies"
is not a security protocol) and therefor imply we should abandon every
cryptographic protocol in the name of "false security".

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.

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 11 Apr 2022 22:01:16 +0900

Paul Hoffman wrote:

> I see a very strong consensus in this thread against the proposals
> from Ohta-san,

I can't see any as discussion is still ongoing.

							Masataka Ohta

---

From: Jerry Lundström <[email-masked]>
Date: Mon, 11 Apr 2022 15:11:09 +0200

I'm against the proposals from Ohta-san.

/Jerry

On 4/11/22 15:01, Masataka Ohta wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 11 Apr 2022 22:19:38 +0900

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.

> 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.

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 11 Apr 2022 23:09:18 +0900

Paul Wouters wrote:

> In your

I can't see any reason why you think the root zone is
more secure than TLDs, especially because, as I wrote:

: 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.

and

: A false sense of security that DNSSEC were
: cryptographically secure motivates the operators
: ignore DNSSEC operation rules, which are very
: complicated and hard to follow, for relatively
: strong physical security, which might be what
: happened in diginotar.

					Masataka Ohta

---

From: Paul Wouters <[email-masked]>
Date: Mon, 11 Apr 2022 10:33:07 -0400 (EDT)

> 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.

I was also responsible for the design and implementation of a large TLD
fully implementation redundant DNSSEC signer solution.

I talked to a lot of TLD operators at ICANN during my term as the
IETF Liason to the ICANN Technical Expert Group.

> :  their formal documents.

This is an anecdote, that a logical reasoned argument.

> :  cryptographically secure

This remains factually incorrect, no matter how many times you quote
yourself.

> : motivates the operators

This is hearsay combined with personal opinion that is unsubstantiated
by facts.

As for your other mail to list, it seems we do not in fact have an
ongoing discussion. You keep repeating and quoting yourself as evidence
while people keep telling you they disagree with your quotes.

But to make it abundantly clear this is not a discussion, I shall
refrain from further messages so you cannot  miscatageorize my
correspondence as a "discussion of peers".

Paul

---

From: Jim Reid <[email-masked]>
Date: Mon, 11 Apr 2022 15:36:34 +0100

> On 11 Apr 2022, at 14:01, Masataka Ohta <[email-masked]> wrote:
> 

There is no discussion, just you arguing with yourself. Please stop.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 14 Apr 2022 20:55:34 +0900

> 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.

 > fully implementation redundant DNSSEC signer solution.

So, the root and TLD zones are as secure as diginotar.

 > IETF Liason to the ICANN Technical Expert Group.

I'm sure none of them were aware that PKI is not cryptographically
secure. So?

 > 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.

							Masataka Ohta

---

From: <[email-masked]>
Date: Thu, 14 Apr 2022 13:01:57 +0100

Surely this is at the point of just being trolling right?

-----Original Message-----
From: DNSOP <[email-masked]> On Behalf Of Masataka Ohta
Sent: Thursday, April 14, 2022 12:56 PM
To: Paul Wouters <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [DNSOP] DNSSEC as a Best Current Practice

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:
> 
> 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.

 > 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.

							Masataka Ohta

---

From: Paul Wouters <[email-masked]>
Date: Thu, 14 Apr 2022 10:02:31 -0400 (EDT)

> procedures", which is not cryptographic.

No I did not say that at all.

> Your point is, surely, conclusive.

This twisting of my words has now reached abusive levels, and I hope
the chairs will now take action.

Paul

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 14 Apr 2022 10:17:30 -0400

I sent this earlier today but I failed to do the Reply-All:

---

>From the chairs,

This needs to stop.  Please send suggested text for the document that can
be discussed, otherwise we are requesting you cease

Thanks
Tim
----

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 14 Apr 2022 19:47:43 +0530

> 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