Subject: [DNSOP] Is DNSSEC a Best Current Practice?

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Mar 2022 18:54:07 +0000

Greetings again. My motivation here is kinda trivial, but I've heard it is a common complaint. When writing a about DNSSEC, I need to reference the RFC. But it's three RFCs (4033, 4034, and 4035), and possibly another (6840). It would be awfully nice to refer to "DNSSEC" with a single reference like "BCP 250".

To get there, we need to update the RFCs and say that we want an BCP. This is mostly a paperwork exercise, but this WG isn't terribly good at getting those done. Maybe we could create a short-lived WG for moving DNSSEC to BCP that just the DNSSEC-y people need to pay attention to. If we do it, that WG would not take up any new DNSSEC-related work, just spruce up the base RFCs.

In the big picture, I think it would be good for the DNS to be able to refer to DNSSEC more easily. Thoughts?

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Mar 2022 14:04:44 -0500

Sounds good to me.

Even better if we would clarify DNSSEC is not an optional part of DNS, but I don’t think you are volunteering for that discussion 😀

Sent using a virtual keyboard on a phone

> On Mar 10, 2022, at 13:54, Paul Hoffman <[email-masked]> wrote:
> 
> --Paul Hoffman_______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 10 Mar 2022 14:10:06 -0500

I like this idea also.   Warren may have some ideas but could also be
something to do in one of the area WGs.

Grinding paperwork is a necessary evil.

tim

On Thu, Mar 10, 2022 at 2:05 PM Paul Wouters <[email-masked]> wrote:

> Sounds good to me.
>
> Even better if we would clarify DNSSEC is not an optional part of DNS, but
> I don’t think you are volunteering for that discussion 😀
>
> > Greetings again. My motivation here is kinda trivial, but I've heard it
> is a common complaint. When writing a about DNSSEC, I need to reference the
> RFC. But it's three RFCs (4033, 4034, and 4035), and possibly another
> (6840). It would be awfully nice to refer to "DNSSEC" with a single
> reference like "BCP 250".
> >
> > To get there, we need to update the RFCs and say that we want an BCP.
> This is mostly a paperwork exercise, but this WG isn't terribly good at
> getting those done. Maybe we could create a short-lived WG for moving
> DNSSEC to BCP that just the DNSSEC-y people need to pay attention to. If we
> do it, that WG would not take up any new DNSSEC-related work, just spruce
> up the base RFCs.
> >
> _______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Mar 2022 19:15:26 +0000

> Sounds good to me.

Something analogous to bcp195 could be a good plan, esp
as signature algorithms, rsa key sizes and maybe ksk/zsk
handling change over time.

Not sure if it'd be better part of such a document but also
be no harm to try document good/best practices in preventing
hijacking (2fa etc), so one could consider a bcp on the topic
of "managing data/origin authentication for DNS data" rather
then just DNSSEC maybe.

Either could be useful.

Cheers,
S.

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 10 Mar 2022 20:23:46 +0100

Sounds like a good plan to me. 
    
                -Bill

> On Mar 10, 2022, at 7:55 PM, Paul Hoffman <[email-masked]> wrote:
>

---

From: Grant Taylor <[email-masked]>
Date: Thu, 10 Mar 2022 12:59:58 -0700

Hi,

+10 to aggregating current documentation into one place.

On 3/10/22 12:04 PM, Paul Wouters wrote:
> Even better if we would clarify DNSSEC is not an optional part of DNS, 
> but I don’t think you are volunteering for that discussion 😀

Eh ... I'm more interested in aggregating current documentation into one 
place than I am trying to alter the status quo.

I say this because I believe that aggregation / collation of already 
agreed upon (read: published) /current/ standards is a relatively simple 
thing and should have minimal objections.  Conversely, trying to change 
/ update anything will likely garner (non-trivially) more objections.

Perhaps there should be a statement speaking to aggregation / collation 
as opposed to updating in said document.

Aside:  Maybe it's just me, but I feel like there is more perceived 
value in clarifying existing documentation, in the hopes that others 
will be more likely to adopt current best practices, than there is in 
updating things.  Dare I say it, but I feel some urgency to do this.

-- 
Grant. . . .
unix || die

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 10 Mar 2022 15:16:27 -0500

> updating things.  Dare I say it, but I feel some urgency to do this.

I think a single BCP doc is a good idea, but here I'd actually go much
further and argue for a significant section in the BCP that
acknowledges that it is also a best current practice not to enable
DNSSEC. That is objectively the most common practice, and it is very
often intentional. I think there's a way to frame it and lay out the
intrinsic trade-offs between internet stability risks and the security
benefits. That framing actually underscores the importance and urgency
of all the best practices that can mitigate the stability risks and
enhance the security. That might more effectively persuade DNSSEC
skeptics. Absent a big change in adoption, a BCP could otherwise seem
quite disconnected from reality (TLD-scale outages, stale
cryptography) and tone-deaf to the skepticism that's out there. "We
hear you" is powerful.

-- 
Colm

---

From: Grant Taylor <[email-masked]>
Date: Thu, 10 Mar 2022 15:06:49 -0700

On 3/10/22 1:16 PM, Colm MacCárthaigh wrote:
> I think a single BCP doc is a good idea, but here I'd actually go 
> much further and argue for a significant section in the BCP that 
> often intentional.

I'm not trying to get into what is and isn't best current practice.

But I do think that best and common practices often do differ.  I also 
think that just because something is the most common practice doesn't 
equate to being the best practice.  --  History is full of things that 
were once the most common that we would now agree aren't now and 
probably weren't at the time the /best/ thing to be done.

> I think there's a way to frame it and lay out the intrinsic trade-offs 
> between internet stability risks and the security benefits. That 
> framing actually underscores the importance and urgency of all the 
> best practices that can mitigate the stability risks and enhance the 
> security.

Agreed.  It is important to understand and articulate all (known) 
aspects of a problem as well as the pros and cons thereto.

> That might more effectively persuade DNSSEC skeptics. Absent a big 
> change in adoption, a BCP could otherwise seem quite disconnected 
> from reality (TLD-scale outages, stale cryptography) and tone-deaf 
> to the skepticism that's out there. "We hear you" is powerful.

We see such disconnects between BCPs (not smoking / wearing seat belts) 
and people choosing to go against them (by smoking / not wearing seat 
belts).  Such choices don't inherently detract from the veracity of the 
BCP.  --  I know a lot of people that say things like "I know that I 
should do $THING, but I don't like it, so I choose not do $THING."  As 
much as I dislike it, I have to respect their personal choice.  At least 
up until their choice adversely impacts me / others.

-- 
Grant. . . .
unix || die

---

From: Yasuhiro Orange Morishita / 森下泰宏 <[email-masked]>
Date: Fri, 11 Mar 2022 11:44:45 +0900 (JST)

Paul-san,

> In the big picture, I think it would be good for the DNS to be able
> to refer to DNSSEC more easily. Thoughts?

I think it can be said for RFC 1034 and 1035, too.
But it's much more difficult than DNSSEC.

My friend Takashi Takizawa maintains this horrible figure.

  DNS RFCs - ttkzw's site
  <https://emaillab.jp/dns/dns-rfc/>

-- Orange

-- 
Yasuhiro 'Orange' Morishita <[email-masked]>

From: Paul Hoffman <[email-masked]>
Subject: [DNSOP] Is DNSSEC a Best Current Practice?
Date: Thu, 10 Mar 2022 18:54:07 +0000

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 11 Mar 2022 04:38:56 -0500

I have been thinking the same thing this evening about 1034 and 1035.
Thanks for bringing it up.

They do not need to have BCP status, but for several years now I have felt
those two need to be republished with all
the updated text from the many updates (28 for 1035, 18 for 1034) in new
documents.  This does not include any other
changes, and it feels like a thankless task.

tim

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Mar 2022 01:49:41 -0800

Tim Wicinski wrote on 2022-03-11 01:38:
> ... for several years now I have
> felt those two need to be republished with all
not just thankless but useless. a correctness preserving rewrite, from 
scratch, should be performed every few decades. (we're overdue.) a goal 
should be readability which will require NOT reusing most of the 
original text or including the updated text. we often didn't know or 
otherwise misstated our implications. every material statement made by 
any prior DNS specification or update to the specification should be 
enumerated and checked off as its then-modern meaning is incorporated.

i'll offer to join a team to work on this when i eventually retire, if 
it hasn't been recently enough done at that time. so, i think, should 
other guilty parties.

-- 
P Vixie

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 11 Mar 2022 15:56:25 +0530

On Fri, Mar 11, 2022 at 01:49:41AM -0800, Paul Vixie wrote:
> should be readability which will require NOT reusing most of the original
> text or including the updated text. we often didn't know or otherwise
> misstated our implications. every material statement made by any prior DNS
> specification or update to the specification should be enumerated and
> checked off as its then-modern meaning is incorporated.
> 
> i'll offer to join a team to work on this when i eventually retire, if it
> hasn't been recently enough done at that time. so, i think, should other
> guilty parties.

Some years back, I tried to begin a "squash" document along these lines,
but like many other drafts, it was abandoned. When discussing it with
colleagues, most had the opinion that this was a wasteful
endeavour. Opinions were that it was too much work, that the landscape
was changing too much and a new document would become obsolete too.

https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-squash-01

I've assisted new DNS developers in the course of my work. From this
experience, there should be an effort to make a new modern document as
the details of correctly implementing DNS are scattered in too many RFCs
and drafts. It is daunting for a newcomer to navigate unless they have
read all the RFCs prior and know where to find what.

As an example, 2 weeks ago I was asked by a colleage why when parsing a
CNAME response a resolver discards the links of the CNAME chain except
for the link with the owner name it queried for (unless it can validate
the other links). The way this requirement is written in the
corresponding RFC, it's difficult to search and find the appropriate
RFC. If someone is implementing DNS functionality afresh, they may even
miss such requirements because they're all over the place.

		Mukund

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 11 Mar 2022 05:31:25 -0500

> it hasn't been recently enough done at that time. so, i think, should

I agree with you Paul on rewriting. I was trying to comment that even the
idea
of publishing a version of those documents with the updates as a
-00/starting point
felt thankless.

But walking through the specifications ? indeed.

tim

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 11 Mar 2022 21:49:02 +0900

> changes, and it feels like a thankless task.

Given that, here in this ML, I repeatedly correct wide spread
misunderstandings on the original rfcs 1034 and 1035, not
extensions to them, every several years, the task can be
performed properly only by PVM, the original author of the
rfcs, as an active editor, I'm afraid.

						Masataka Ohta

PS

It should be a lot more productive to totally revise DNS which
should be a thankful task.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 12 Mar 2022 00:53:10 -0500

On Thu, Mar 10, 2022 at 06:54:07PM +0000, Paul Hoffman wrote:

> Greetings again. My motivation here is kinda trivial, but I've heard
> it is a common complaint. When writing a about DNSSEC, I need to
> reference the RFC. But it's three RFCs (4033, 4034, and 4035), and
> possibly another (6840). It would be awfully nice to refer to "DNSSEC"
> with a single reference like "BCP 250".

I'm on board for a DNSSEC BCP document.  I've effectively been working
on this for some time.  Hence e.g. the NSEC3 iteration draft and an
upcoming APNIC guest post on ZSK best-practice.

Would be nice to publish more accessible text on the correct handling of
ENTs and wildcards (as e.g. malpracticed by NameCheap).

At least TLSA non-response has mostly gone away as an issue, NSEC3
iterations have come down quite significantly.  Also algorithms 5 and 7
have each lost ~93% of their peak deployment levels.

So communicating (and repeatedly nagging) best-practice does appear to
translate to operational changes, even if the time scale is ~2 years in
some cases.

-- 
    Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Mar 2022 00:13:32 +0000

As a follow-up to the thread last week, I created a fairly short draft that describes DNSSEC in a single document and calls it a BCP. See:
   https://datatracker.ietf.org/doc/draft-hoffman-dnssec/

Based on the list discussion, I spoke with Warren about the idea of a short-lived separate WG for this effort. He said (quite correctly) that doing so would be a hard sell to the IESG, and thought that I should just propose that it be adopted here in DNSOP when the adoption window opens again.

In the meantime, anyone interested can make suggestions on how to improve the draft so that it is nice and shiny when it come to the WG for adoption. I have listed a GitHub repo in the abstract, and can take issues and pull requests; you can also just send me email. I'll rev the draft often based on what I hear.

--Paul Hoffman

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Mar 2022 15:09:59 +0900

Paul Hoffman wrote:

> In the meantime, anyone interested can make suggestions on how to
> improve the draft so that it is nice and shiny when it come to the WG
> for adoption.

    it just
    indicates that the value of deploying DNSSEC is often considered
    lower than the cost.

is just wrong.

Constructive thing to do to make DNS secure is to totally abandon
DNSSEC and rely on DNS cookie or something like that.

						Masataka Ohta

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2022 07:22:14 +0100

> DNSSEC and rely on DNS cookie or something like that.

DNS cookies provide no data origin security, only a weak transport security against non-onpath attackers.

A replacement suggestion for DNSSEC would need a bit more specification than “cookie or something like that”. It would not only need to cover what DNSSEC protects against, but also be worth the pain of a worldwide migration. An internet draft for this would be a good starting point for a discussion.

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Mar 2022 17:01:40 +0900

Paul Wouters wrote:

>>  Constructive thing to do to make DNS secure is to totally
>> abandon DNSSEC and rely on DNS cookie or something like that.

> security against non-onpath attackers.

If a resolver correctly knows an IP address of a nameserver of a
parent zone and the resolver and the nameserver can communicate
with long enough ID, the resolver can correctly know an IP
address of a nameserver of a child zone, which is secure enough
data origin security.

As for MitM attacks, PKI, in general, is insecure against
them as was demonstrated by diginotar. So, don't bother.

IETF can do nothing if some government legally force
people to install some government provided certificates
to some PKI, including DNSSEC, which is as easy as
MitM attacks on ISP chain may be by government order.

					Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Mar 2022 09:25:34 +0100

> address of a nameserver of a child zone, which is secure enough

It's pretty easy to intercept all packets destined for a particular IP
address and spoof the responses.

> MitM attacks on ISP chain may be by government order.

Attacks of this nature are in principle detectable. The way to detect them
is to notice these forcibly injected certificates based on the public keys
presented in them. Of course, you need to have a source of truth, and
nothing is perfect, but also, the best is the enemy of good enough. There's
been plenty of discussion and research on the topic of how to notice that
forged certificates are being presented. What I don't see happening (maybe
I'm missing it) is this stuff being deployed in the real world.

As for using "something like cookies" to secure the communications channel,
this is functionally the same problem as noticing that certificates have
been forged, but gets you a lot less benefit in practice, because you have
to have a secure channel to each thing you want to be able to validate, or
else you have to have  a server that is able to do such validation for you
and a secure channel to it (which amounts to the same thing).

So although DNSSEC is complicated, and it's easy to talk about simpler
solutions, whenever you dig into the details, what you find is that either
they don't actually deliver what DNSSEC delivers, or else they wind up
being more complicated and harder to operate. Security doesn't come for
free.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2022 04:34:42 -0400 (EDT)

On Mon, 21 Mar 2022, Masataka Ohta wrote:

> parent zone

This statement seems a recursion of the original problem statement?

> and the resolver and the nameserver can communicate

This would not help for on-path attackers (without DoT, DoH)

How would this be safe against the current BGP attacks we are seeing?

> them as was demonstrated by diginotar. So, don't bother.

DNSSEC is more hierarchical than the "bag of CAs", so a failure
like this would be more contained. Regardless, I do not understand
how PKI failures relate to DNS?

> MitM attacks on ISP chain may be by government order.

With DNSSEC, a government in country X cannot spoof data of
country Y, they can only block it. DNS without DNSSEC allows
country Y to spoof country X.

Again, I think perhaps you should write this up in a draft, so
we can see how your proposal would cover everything that DNSSEC
covers.

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Mar 2022 21:10:28 +0900

> address and spoof the responses.

Technically, yes, but, socially, no, not at all.

It can be practically possible only if ISPs employees are socially
compromised, which is criminal, or the ISP is ordered to do so
by government.

The problem of DNSSEC, or PKI in general, is that, assuming such
attacks, it is equally easy to socially compromise a zone with
DNSSEC signature.

It's pretty easy to forge certificates.

Never rely on untrustworthy TTPs.

> Attacks of this nature are in principle detectable.

Technically, maybe, but, socially, it is not detectable at
least legally, if such detection is defined to be (may be
criminally) unlawful.

> The way to detect them
> presented in them.

And you can be arrested.

It should be noted that google's attempt to statically install
some certificate in their browser is subject to MitM attacks
on employees of google or distribution chain of the browser.
Moreover, such software may be legally banned by some government.

> Of course, you need to have a source of truth, and

Because security by PKI including DNSSEC is not end to end, it is
impossible to detect security breach so quickly.

Or, can you improve DNSSEC to instantly invalidate compromised zone
information, which is impossible with slowly acting CRLs.

> and a secure channel to it (which amounts to the same thing).

Socially, having long enough message IDs is as secure as DNSSEC.

> So although DNSSEC is complicated,

That is because authors of the original specification of DNSSEC
ignored my comments (at that time, I was not aware of fundamental
lack of security of PKIs), as a DNS expert having enough knowledge
on PKI, to make it highly compatible with existing DNS.

As a result, DNSSEC was modified to be so complicated trying to
incorporate my earlier comments in ugly manners.

> and it's easy to talk about simpler
> solutions,

For me, it was, has been and still is easy.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Mar 2022 21:28:28 +0900

Paul Wouters wrote:

> This statement seems a recursion of the original problem statement?]

What?

The statement is not more demanding for resolvers to be configured
with correct certificates.

> This would not help for on-path attackers (without DoT, DoH)

See below.

> How would this be safe against the current BGP attacks we are seeing?

Are you saying connecting to an IP address secured by DNSSEC
is safe even under BGP attacks?

> how PKI failures relate to DNS?

Are you saying you don't understand DNSSEC is a form of PKI?

> country Y, they can only block it.

Country X legally forcing people to install government provided
root certificates can freely spoof PKI, including DNSSEC, data
of country Y.

> we can see how your proposal would cover everything that DNSSEC

Before diginotar, maybe. After that, I don't think it necessary
any more.

						Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Mar 2022 13:54:49 +0100

Ohta-san, I think the points you are making in response to what I have said
are that

(1) it's easier for a government to fake a DNS delegation than to MiTM an
IP connection, and
(2) if it's a government that's faking your DNS, they can jail you for
noticing.

I think these are both valid points. However, I don't think they lead to
the conclusion you are drawing. First, if the government really cares about
censorship, it's probably going to do some degree of DPI for connections to
IP addresses it has reason to care about. So you could in principle do a
connection to a device that isn't on the government's radar and bypass
their attack, for sure. But this is actually quite hard for a layperson to
arrange, and impossible to automate, since any automatic mechanism would be
known to the government in question.

To the second question, this is also absolutely true, but at the same time,
as we can see, just because something is illegal doesn't mean that it's not
useful. E.g., the government in Russia has made it illegal to protest the
war in Ukraine, and yet we see people protesting in the streets. Their goal
is pretty clearly to bypass a government restriction on communication.

Having a watchdog in software that notices when a certificate has been
replaced by one that isn't valid isn't that hard, and while it might be
made illegal after the fact, officially making it illegal would be a public
act that would have to be announced by the government in order to be
enforceable—otherwise software vendors would have no reason to know they
were violating the law. By announcing it, the government in question is
disclosing the status of your security, which is the whole point. Absent
such a disclosure, citizens can continue to run such software, and continue
to detect such attacks. In the presence of such a disclosure, citizens know
that their traffic is not secure, which is obviously not great, but still
represents success: the user now knows that the network isn't safe to use.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Mar 2022 22:23:23 +0900

> (2) if it's a government that's faking your DNS, they can jail you for

You miss my point that compromising employees of ISPs or zones by, say,
kidnapping their children.

> censorship,

Censorship? Fake news are obviously better.

> is pretty clearly to bypass a government restriction on communication.

Be also aware of fake news produced against Russia by some governments.

> were violating the law.

The point is what, if any, can DNSSEC do against it.

> By announcing it, the government in question is
> disclosing the status of your security, which is the whole point.

But, justice defined by the government is the justice for those
who are under control of the government.

 > Absent
 > such a disclosure, citizens can continue to run such software, and
 > continue to detect such attacks.

Though it can be a criminal offense against local justice.

						Masataka Ohta

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2022 14:45:12 +0100

On Mar 21, 2022, at 13:10, Masataka Ohta <[email-masked]> wrote:
> Ted Lemon wrote

https://therecord.media/klayswap-crypto-users-lose-funds-after-bgp-hijack/amp/

“ Using a rogue AS known as AS9457, on February 3, the attackers began advertising that they owned the IP addresses that served developers.kakao.com,”

You can define every technical hack as a social problem because it involved humans.

> attacks, it is equally easy to socially compromise a zone with

Yet that has never happened, unlike BGP attacks.

> Never rely on untrustworthy TTPs.

Yet I don’t hear you say to abandon TLS ?

> Because security by PKI including DNSSEC is not end to end

With TRRs in browsers like Firefox, it practically is.

> information, which is impossible with slowly acting CRLs.

DNSSEC has no CRLs, only TTLs. I think you meant PKI here, not DNSSEC?

>> Socially, having long enough message IDs is as secure as DNSSEC.

“Socially” makes no sense from a protocol level. 

> ignored my comments

It was not ignored, it was rejected.

> For me, it was, has been and still is easy.

Please submit a draft with enough details for an implementer and/or sample code so the IETF can objectively evaluate your claims.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2022 14:59:32 +0100

>> This statement seems a recursion of the original problem statement?]

You claim DNS can be secured if we somehow securely know all the IPs of all nameservers of parent zones, for which the only source is DNS. How do you propose to fulfill your own stated requirement without DNSSEC ?

> is safe even under BGP attacks?

Yes. Obviously the attacker can deny the actual real DNS content but sending their own made up DNS data is ignored due to data origin protection. 

> Are you saying you don't understand DNSSEC is a form of PKI?

Please refrain from ad hominem attacks if you wish to continue to discuss.

A webpki root ca failure has no relationship to dnssec which has no root ca’s.

> root certificates can freely spoof PKI, including DNSSEC, data

No they cannot. I can give you root access to a nameserver for nohats.ca and you still can’t create a “proof.nohats.ca” DNS record that google DNS would serve to people. Similarly if we imagine you can coerce country X to do anything you want, how you could get this DNS record published so that the world’s servers/clients will believe your answer to be true. 

> Before diginotar, maybe. After that, I don't think it necessary

If you only handwave your claims, the only possible IETF response is to not spend time on your claims. I have now given you two methods to substantiate your claims to further the discussion.

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Mar 2022 23:12:38 +0900

Paul Wouters wrote:

> "Using a rogue AS known as AS9457, on February 3, the attackers
> began advertising that they owned the IP addresses that served
> developers.kakao.com,"

It is as easy as compromising developers.kakao.com.

> You can define every technical hack as a social problem because it

Yup.

> Yet that has never happened, unlike BGP attacks.

You miss my point that DNSSEC to produce correct IP addresses
is powerless against BGP attacks.

> Yet I don’t hear you say to abandon TLS ?

TLS is no better than DH, which is subject to MitM attacks,
though you might hear it from me for the first time.

> With TRRs in browsers like Firefox, it practically is.

Wrong.

Because it is not end to end, it is subject to MitM attacks
on software distribution chain.

>> Or, can you improve DNSSEC to instantly invalidate compromised
>> zone information, which is impossible with slowly acting CRLs.
> 

That CRLs are very slow to react against attacks because
PKI is not end to end makes CRLs totally useless for
PKIs including DNSSEC, which is why I stated "instantly
invalidate".

> “Socially” makes no sense from a protocol level.

BCP is not at the protocol level.

> It was not ignored, it was rejected.

It was ignored and rejected but later, with some implementation
efforts, was recognized resulting in specification changes in
the worst possible way, because recognition occurred to late.

So?

 > Please submit a draft with enough details for an implementer and/or
 > sample code so the IETF can objectively evaluate your claims.

No implementation or code is necessary to say DNSSEC is
fundamentally hopeless.

						Masataka Ohta

---

From: Jim Reid <[email-masked]>
Date: Mon, 21 Mar 2022 14:21:58 +0000

> On 21 Mar 2022, at 14:12, Masataka Ohta <[email-masked]> wrote:
> 

That might or might not be true. But where's your draft and code for an alternative?

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Mar 2022 23:30:42 +0900

Paul Wouters wrote:

> You claim DNS can be secured if we somehow securely know all the IPs
> of all nameservers of parent zones, for which the only source is DNS.
> How do you propose to fulfill your own stated requirement without
> DNSSEC?

Securely configuring IP addresses of root servers, which can
recursively assure data origin security of child servers, is
as easy/difficult as securely configuring root certificates.

So?

>> Are you saying connecting to an IP address secured by DNSSEC is
>> safe even under BGP attacks?
> 
> Yes. Obviously the attacker can deny the actual real DNS content but
> sending their own made up DNS data is ignored due to data origin
> protection.

Wrong.

With BGP attacks, your packet with an DNSSEC secured destination IP
address is delivered elsewhere.

> Please refrain from ad hominem attacks if you wish to continue to

I'm afraid it is you who want to discontinue discussion.

>> root certificates can freely spoof PKI, including DNSSEC, data of
>> country Y.

> No they cannot. I can give you root access to a nameserver for
> nohats.ca and you still can't create a "proof.nohats.ca"

It is trivially easy with root zone certificate recognized by
end users to forge RRs of "nohats.ca" and "proof.nohats.ca".

> If you only handwave your claims,

I'm afraid it is you who is handwaving with such unfounded
statement:

    it just

						Masataka Ohta

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2022 15:33:08 +0100

Okay,

I tried to substantiate the discussion but all I get back are unsubstantiated one line claims. I tried to ask for clarifications with details but didn’t receive these. If you can’t or won’t provide details, I cannot evaluate your claims and can take no action other than to reject your claims. If you can substantiate this in the future, I am happy to pick up this discussion.

Regards,

Paul

> 
> On Mar 21, 2022, at 15:12, Masataka Ohta <[email-masked]> wrote:
> 
> Paul Wouters wrote:
> 
>>> The problem of DNSSEC, or PKI in general, is that, assuming such attacks, it is equally easy to socially compromise a zone with DNSSEC signature.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Mar 2022 23:36:32 +0900

> That might or might not be true. But where's your draft and code for an alternative?

How can you say I must provide some draft for some protocol by
myself even though an alternative of DNS cookie already is an rfc?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Mar 2022 23:40:05 +0900

Paul Wouters wrote:

> I tried to substantiate the discussion

I'm afraid you didn't, from the beginning, to have stated:

    it just

							Masataka Ohta

---

From: Jim Reid <[email-masked]>
Date: Mon, 21 Mar 2022 14:42:23 +0000

> On 21 Mar 2022, at 14:36, Masataka Ohta <[email-masked]> wrote:
> 

Modulo the IETF's code of conduct, I can say whatever I like - as can you or anyone else.

If you're saying DNS cookies are the answer, there's nothing more to say on this thread. Goodbye.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 21 Mar 2022 23:48:02 +0900

Jim Reid wrote:

> If you're saying DNS cookies are the answer,

As I said "DNS cookie or something like that", no, not necessarily
"the answer". But it certainly is an alternative.

						Masataka Ohta

---

From: David Conrad <[email-masked]>
Date: Mon, 21 Mar 2022 10:53:50 -0700

> address of a nameserver of a child zone, which is secure enough

No.

https://therecord.media/klayswap-crypto-users-lose-funds-after-bgp-hijack/ <https://therecord.media/klayswap-crypto-users-lose-funds-after-bgp-hijack/>
https://www.theregister.com/2018/04/24/myetherwallet_dns_hijack/ <https://www.theregister.com/2018/04/24/myetherwallet_dns_hijack/>
Etc.

Securing the channel of communication != securing the data communicated via that channel.

Regards,
-drc

---

From: Brian Dickson <[email-masked]>
Date: Mon, 21 Mar 2022 13:01:04 -0700

> with correct certificates.

I'm presuming you mean "DNSSEC ICANN/IANA Root Trust Anchor", which is a
public key, not a certificate per se.

I presume you're comparing two models, one using DNSSEC, and one where no
DNSSEC validation is done ever (replaced with TLS, either DNS over TLS to
Authority, or DNS over HTTPS to Authority, including root, TLD and all
authority servers for all zones).

I'll use that assumption in the remainder of this message...

> is safe even under BGP attacks?

The complete model of using DNSSEC involves also using TLSA records (DANE).
In the DNSSEC-protected TLSA record model, BGP attacks have no direct
impact on DNSSEC-protected zones, including BOTH the address records
(A/AAAA) AND the TLS information (complete certificate, or public key, or
hash of either of those), and consequently no impact on the TLS connections
subsequent to the DNS lookups (i.e. no possible cert-level MITM or web site
spoofing).

The exclusive capability of a MITM would be to DOS the DNS lookups, or to
block the TLS set-up (if the attacker were on the data path to the
endpoint).

So, yes, a web site properly protected using all of the DNSSEC-based
capabilities, where the client software was doing the validation using the
corresponding methods, would be safe against any and all MITM attacks,
including BGP.

Note that this is already the case for SMTP (using SMTPS via TLSA records).
Those SMTP connections between parties publishing and validating TLSA
records are not subject to downgrade attacks, and only properly validated
endpoints can communicate (securely).

> Are you saying you don't understand DNSSEC is a form of PKI?

I'm reasonably sure that Paul W meant "WebPKI" when he said PKI.

WebPKI is effectively a "flat namespace" sort of PKI, meaning a bunch of
CAs all have the right to issue certificates, with no exclusivity (which is
part of what lead to the diginotar thing).

By comparison, DNSSEC is an exclusively hierarchical, singular control
point PKI system. At each level of the hierarchy, the public keys are under
the exclusive control of the zone owner/administrator/operator, and signed
by the parent zone.
(Any concerns on the out-of-band update aspects are potentially worthy of
work, but that is also the case for the OOB update aspects for WebPKI.)

> root certificates can freely spoof PKI, including DNSSEC, data

This is another place where the "flat" WebPKI vs the "hierarchical" DNSSEC
models are not exactly the same.

In addition to resolvers, end hosts have the ability to do DNSSEC
validation (on data received from resolvers).

Any host (resolver or end host) is capable of installing trust anchors for
any level of the DNS hierarchy, which would preempt any spoofed delegation
information (DS records) and reduce unsigned delegation spoofery to the
aforementioned DOS level of interference. End hosts would never see the
spoofed answers.

End hosts may also have some ability to make use of other resolvers (very
much dependent on local conditions, of course).

The scope of what country X can do with respect to country Y, is limited by
any number of orthogonal elements.
Those include

   - geographical limits (e.g. the physical boundary of country X)
   - topological considerations (all the paths from every host/user to the
   outside world)
   - resolvers reachable by any/all hosts/users
   - host/application configuration on all of the resolvers and hosts
   - necessity of altering responses at every level of the DNS hierarchy by
   on-path changes for all of the above elements

Additionally, outside of the physical geographical boundary of country X,
nothing country X can do can accomplish the spoofing of data of country Y.
And within country X, the necessity of asserting configuration control of
resolvers and hosts, would seem to be an extremely high bar for a state
actor.

> Before diginotar, maybe. After that, I don't think it necessary

Honestly, rather than spending any effort in that area, any concern about
protecting TLS connections would best be done by convincing web browser
software vendors to implement DANE (TLSA) validation.

Brian

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Mar 2022 17:19:42 +0900

> public key, not a certificate per se.

OK.

> DNSSEC validation is done ever (replaced with TLS,

No, TLS is overkill. Plain DNS with long enough message ID is
secure enough. Though it is vulnerable to active MitM attacks,
where packets are not only spoofed but also dropped, modified
and/or generated, such attacks are as likely/unlikely as
having a fake root trust anchor through social attacks
(including legal order by some government).

As for DoS, IMO, anycast is the only practical protection.

					Masataka Ohta

---

From: Bjørn Mork <[email-masked]>
Date: Tue, 22 Mar 2022 09:52:45 +0100

Masataka Ohta <[email-masked]> writes:

> Plain DNS with long enough message ID is secure enough.

Hello!

Can you please point me to the set of RFCs (or draft) which describes
this "secure enough" alternative to DNSSEC?

I must admit I'm a bit lost wrt precisely what that alternative is since
you haven't given a single reference AFAICS. The whole point of the
draft being discussed here is to define a BCP pointing to the relevant
standards. Please contribute to that.

Thanks.

Bjørn

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Mar 2022 18:05:43 +0900

> this "secure enough" alternative to DNSSEC?

As I wrote "rely on DNS cookie or something like that",
an example is in rfc7873.

						Masataka Ohta

---

From: Bjørn Mork <[email-masked]>
Date: Tue, 22 Mar 2022 10:35:04 +0100

> an example is in rfc7873.

Sorry for being slow, but you'll have to explain a lot more than that if
you want to convince me that DNS cookies and DNSSEC are equivalent
alternatives.  But maybe that wasn't your goal here? You're just happy
that you have seen the light and don't care if I understand what it is?

If so, then that's fine.  I don't understand why the announcement was
important though.

I was asking specifically for your alternative BCP.  "Go figure it
out by yourself with DNS cookie or something like that" just doesn't
make it.

Bjørn

---

From: Joe Abley <[email-masked]>
Date: Tue, 22 Mar 2022 11:28:36 +0100

> an example is in rfc7873.

Could I perhaps summarise what you're saying as follows?

1. The cost of DNSSEC signing is high, e.g. due to increased complexity, brittleness of the DNS, perhaps as shown by relatively low demonstrated system-wide deployment;

2. The threats that DNSSEC protects against are not high-probability threats, especially following the adoption of various resolver-hardening techniques adopted following the late Dan Kaminsky's various observations;

3. The threats that DNSSEC protects against are not high-impact either since they affect one layer amongst many for most applications;

4. Protocols and applications that depend on cryptographic assurances in the DNS (DNS as PKI) are few and far between, e.g. low uptake of DANE for protocols other than SMTP;

5. The cryptographic assurances in DNSSEC in any case are not absolute, e.g. since they depend on accurate trust anchor maintenance that is subject to interference by nation states, mobile device management, manipulation through system compromise;

6. Better to avoid the cost of DNSSEC deployment given its low value and focus instead on other approaches like cache-hardening or improving transactional integrity using cookies. 

Does that come close to what you're getting at?

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Mar 2022 21:00:14 +0900

Bjorn Mork wrote:

> alternatives.

In a sense, they are equivalent, because both plain DNS with
long enough message IDs and DNSSEC are subject to MitM attacks,
naturally with similar difficulties.

The point is that DNSSEC, or PKI in general, is not cryptographically
secure merely blindly trusting untrustworthy intermediate systems,
which means it is against the end to end principle, improperly
called TTPs (Trusted Third Parties).

In another sense, they are not equivalent because attack vectors
are different. MitM attacks can be on ISP chains, CA chains
or software distribution chains. The last example is applicable
to browser or DNSSEC resolver software containing some certificates
or public keys.

 > out by yourself with DNS cookie or something like that" just doesn't

That's your problem not to able to understand that DNSSEC is *NOT*
cryptographically secure, which I have been pointing out for these
20 years, because it is subject to MitM attacks on CA chains, which
was demonstrated by diginotar about 10 years ago.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Mar 2022 21:18:54 +0900

Joe Abley wrote:

>> As I wrote "rely on DNS cookie or something like that", an example
>> is in rfc7873.
> 
> 1. The cost of DNSSEC signing is high, e.g. due to increased
> complexity, brittleness of the DNS, perhaps as shown by relatively
> low demonstrated system-wide deployment;

No, cost of DNSSEC is high because PKI, in general, is against
the end to end principle, which automatically means that
it is not cryptographically secure, actually because it blindly
depends on untrustworthy TTPs.

If we can be secure by just declaring some third parties not
under control of the first or the second party are trustworhy,
we can just declare that all the third parties of ISPs between
the first and the second, even with BGP route attacks, parties
are trustworthy.

> 2. The threats that DNSSEC protects against are not high-probability
> threats, especially following the adoption of various
> resolver-hardening techniques adopted following the late Dan
> Kaminsky's various observations;

Partially yes, because DNSSEC is not cryptographically secure.

> 3. The threats that DNSSEC protects against are not high-impact
> either since they affect one layer amongst many for most
> applications;

No, MitM attacks on CA chains has as high or low impact as
MitM attacks on ISP chains.

> 4. Protocols and applications that depend on cryptographic assurances
> in the DNS (DNS as PKI)

Wrong. DNSSEC as PKI is not cryptographically secure subject to
MitM attacks on CA chains, which is not more difficult than
MitM attacks on ISP chains.

> 5. The cryptographic assurances in DNSSEC

No, there is no such assurances.

> 6. Better to avoid the cost of DNSSEC deployment

For no security improvement beyond plain DNS with long enough message
IDs? Yes.

							Masataka Ohta

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Mar 2022 08:37:51 -0400 (EDT)

> MitM attacks on ISP chains.

I think at this point we have reached a point where your repeated
claims lack any merit and you keep refusing to elaborate so we
cannot further progress on this topic.

Perhaps the chairs can ask you to either substantiate your claims,
or for you to stop making false misleading claims.

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Mar 2022 23:12:09 +0900

Paul Wouters wrote:

> claims lack any merit

So, you ignore diginotar to have demonstrated that PKI to
blindly trust untrustworthy TTPs is cryptographically
insecure.

Note again that browsers with some public key information
configured is subject to MitM attacks on software
distribution chains.

						Masataka Ohta

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Mar 2022 15:00:07 +0000

My reading of this thread is that one person thinks that there is a better way to achieve what DNSSEC is designed to achieve, and no one else agrees with him. Thus, I'll leave the text in the document alone unless I see more support for that lone opinion.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Tue, 22 Mar 2022 14:11:58 -0700

> blindly trust untrustworthy TTPs is cryptographically

This is where your error is introduced. DNSSEC does not involve blind
trust.

Previous statements by you (Ohta-san) in this thread, and observations or
counter-points:

> address of a nameserver of a child zone, which is secure enough

The difference between this model (client to server transport security
using IDs) and DNSSEC, is that DNSSEC is resistant to any MITM attacks, so
long as the resolver's root trust anchor is the same as the one published
by ICANN/IANA and used to sign the root zone.

It is correct that the single element is a necessary component of the trust
model for DNSSEC. It is not a dependency within DNSSEC that the endpoint's
connectivity must be transport-secured or impervious to hijack. DNSSEC does
not care where the data lives or how it is retrieved. It protects the data
cryptographically.

> called TTPs (Trusted Third Parties).

I think this is where your argument fails. The trust in DNSSEC is not
blind. The validation which is done by a resolver can be confirmed by an
end-host, along the entire chain (tree) from root to leaf.

In order to achieve complete compromise, the adversary (e.g. state) would
need to compromise every software stack on every host and every resolver,
and block access to every external place that could provide contradictory
results.

Given that the root trust anchor is public, and published on the IANA's web
site with all the appropriate protections, this means anyone can publish
the same information on their own web site, e.g. protected by TLS.

The only way this would not be available to someone under the control of
that adversary, would be the compromise of every CA's cert, or publishing
competing certs for every TLS cert in existence, or to prevent any access
to external sites entirely.

The notion that a state exercising that level of control would also permit
the long-enough ID communication to enable your alternative to function,
does not seem credible.

This devolves down to two possibilities: your method is not viable if the
efforts needed to block use of the Root Trust Anchor are undertaken; or if
the efforts needed to block the Root Trust Anchor are not undertaken (in
their entirety), attempts to replace the Root Trust Anchor are detectable,
which also means the real Root Trust Anchor can be obtained and validated,
and once the latter is done, DNSSEC continues to be cryptographically
secure.

The actual real root trust anchor is not feasible to compromise, nor are
the signing mechanisms involved for signing the root zone. A secured root
zone and root trust anchor makes it impossible to compromise any zone
protected by its parent, with the root zone anchoring those protections.

DNSSEC is not blind trust. The ability to compromise via spoofing requires
compromise of a parent. The root zone cannot feasibly be compromised.
Therefore DNSSEC is secure.

 I concur with the rest of the folks on this thread, this subject thread is
effectively concluded.

This message is mostly for your (Ohta-san's) benefit to understand why
DNSSEC is not in the same category as WebPKI in terms of the trust model
and trust mechanisms.

There is an analogy in infinities:
The rational numbers and real numbers are both infinite, but the infinity
of the real numbers is "uncountable", a larger infinity than the infinity
of the rational numbers, which are "countable".

Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Mar 2022 09:20:51 +0100

Brian, what you said about the crypto is right but there are definitely
opportunities to compromise trust at the tlds. I don’t think it’s wise to
ignore this type of attack. However, in order to make such an attack, you
have to do things which can be noticed (e.g. signing a zone delegation with
a forged key).

So the threat model for a viable  DNSSEC attack is quite a bit different
than for a recursive resolver attack, and is not something that could be
easily effected by a small entity.

Or to put it differently, the cost of a successful attack on DNSSEC would
be orders of magnitude higher than for an attack on a resolver. And unlike
a resolver attack, it is possible to detect a DNSSEC attack by comparing
known keys to detect a compromise. With a resolver attack, you have no way
to know that you’ve been spoofed.

On Tue, Mar 22, 2022 at 22:12 Brian Dickson <[email-masked]>
wrote:

> It is correct that the single element is a necessary component of the
> trust model for DNSSEC. It is not a dependency within DNSSEC that the
> endpoint's connectivity must be transport-secured or impervious to hijack.
> DNSSEC does not care where the data lives or how it is retrieved. It
> protects the data cryptographically.
>
> Given that the root trust anchor is public, and published on the IANA's
> web site with all the appropriate protections, this means anyone can
> publish the same information on their own web site, e.g. protected by TLS.
>
>  I concur with the rest of the folks on this thread, this subject thread
> is effectively concluded.
>

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Mar 2022 21:21:58 +0900

Paul Hoffman wrote:

> My reading of this thread is that one person thinks that there is a
> better way to achieve what DNSSEC is designed to achieve, and no one
> else agrees with him. Thus, I'll leave the text in the document alone
> unless I see more support for that lone opinion.
I'm afraid you miss, among others, my point that:

    it just

    is just wrong.

which has nothing to do with "better way".

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Mar 2022 21:46:57 +0900

Brian Dickson wrote:

> The difference between this model (client to server transport
> security using IDs) and DNSSEC, is that DNSSEC is resistant to any
> MITM attacks, so long as the resolver's root trust anchor is the same
> as the one published by ICANN/IANA and used to sign the root zone.

Wrong.

If a TLD with its key signed by the root is compromised, which
is a MitM attack, child zones under the TLD are easy victim
of the attack.

Or, if your theory is that we can blindly trust any entity
blessed by ICANN/IANA through some chain as an trustworthy
TTP, then, according to your theory, we can blindly trust
all the ISPs as trustworthy TTPs, because they are blessed
by ICANN/IANA through RIRs, which means there can be no MitM
attacks on ISP chains.

 > I think this is where your argument fails. The trust in DNSSEC is
 > not blind. The validation which is done by a resolver can be
 > confirmed by an end-host, along the entire chain (tree) from root to
 > leaf.

You are totally confused, because I never assumed any compromised
resolver.

 > The validation which is done by a resolver can be
 > confirmed by an end-host, along the entire chain (tree) from root to
 > leaf.

"The validation which is done by a resolver" is not compromised.

I merely mean MitM attacks on some part of the zone chain is
effective both to the resolver and the end-host.

					Masataka Ohta

> 
> In order to achieve complete compromise, the adversary (e.g. state)
> would need to compromise every software stack on every host and every
> resolver, and block access to every external place that could provide
> contradictory results.
> 
> Given that the root trust anchor is public, and published on the
> IANA's web site with all the appropriate protections, this means
> anyone can publish the same information on their own web site, e.g.
> protected by TLS.
> 
> The only way this would not be available to someone under the control
> of that adversary, would be the compromise of every CA's cert, or
> publishing competing certs for every TLS cert in existence, or to
> prevent any access to external sites entirely.
> 
> The notion that a state exercising that level of control would also
> permit the long-enough ID communication to enable your alternative to
> function, does not seem credible.
> 
> This devolves down to two possibilities: your method is not viable if
> the efforts needed to block use of the Root Trust Anchor are
> undertaken; or if the efforts needed to block the Root Trust Anchor
> are not undertaken (in their entirety), attempts to replace the Root
> Trust Anchor are detectable, which also means the real Root Trust
> Anchor can be obtained and validated, and once the latter is done,
> DNSSEC continues to be cryptographically secure.
> 
> The actual real root trust anchor is not feasible to compromise, nor
> are the signing mechanisms involved for signing the root zone. A
> secured root zone and root trust anchor makes it impossible to
> compromise any zone protected by its parent, with the root zone
> anchoring those protections.
> 
> DNSSEC is not blind trust. The ability to compromise via spoofing
> requires compromise of a parent. The root zone cannot feasibly be
> compromised. Therefore DNSSEC is secure.
> 
> I concur with the rest of the folks on this thread, this subject
> thread is effectively concluded.
> 
> This message is mostly for your (Ohta-san's) benefit to understand
> why DNSSEC is not in the same category as WebPKI in terms of the
> trust model and trust mechanisms.
> 
> There is an analogy in infinities: The rational numbers and real
> numbers are both infinite, but the infinity of the real numbers is
> "uncountable", a larger infinity than the infinity of the rational
> numbers, which are "countable".
> 
> Brian
>

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 23 Mar 2022 21:56:42 +0900

Ted Lemon wrote:

> opportunities to compromise trust at the tlds. I don't think it's wise to

If a parent zone administrator or some employee of it is
compromised and forged zone delegation (with an IP address
of a forged nameserver using forged public/secret keys)
is signed by a valid key, it will not be noticed easily.

> easily effected by a small entity.

Merely because message ID is short, which can be improved,
which is a lot easier than deploying so costly DNSSEC.

 > And unlike
 > a resolver attack, it is possible to detect a DNSSEC attack by
 > comparing known keys to detect a compromise.

If a resolver has some knowledge on contents of an attacked zone, such
as IP addresses of some servers or some DNSSEC keys, it can detect
a DNS (both resolver and DNSSEC) attack by comparing, unless
an attacker knows IP addresses of detecting resolvers and
return unforged answers to them. So?

Unlike that, birthday attacks on resolvers are trivially detectable
by the resolvers.

						Masataka Ohta

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Mar 2022 22:55:11 +0100

> is signed by a valid key, it will not be noticed easily.

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.

At this point, it is easier to obtain physical access to the enduser device and compromise the OS, browser or webpki stack - DNS attack is not needed.

Even cheaper at this point is to use a hammer on the user’s knee cap.

> which is a lot easier than deploying so costly DNSSEC.

You did not answer my earlier question on how you obtain this alleged secure IP address of all DNS nameservers you plan to talk to with “extra strong message ID”. 

Note also the same employee from above can tcpdump their nameserver or read the RAM and give the extra strong message ID to the attacker. So all attacks you attribute to DNSSEC apply to msg ID too.

> return unforged answers to them. So?

Forged answers require access to a private key. As stated those tend to be in HSMs or offline, so “attacker knowing IP address” is insufficient to forge answers. Your previous reply to his has been “there is always a human you can buy that has access to the key”, at which case see the above hammer and knee cap discussion.

> Unlike that, birthday attacks on resolvers are trivially detectable

In your described world, a birthday attack would not be needed, as the compromised operator that would have DNSSEC key access can also just share the msg ID with the attacker. So the attacker uses one regular response that you cannot distinguish from an unforged response. In a world with your own parameters, your solution would equally have no chance.

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Mar 2022 19:55:19 +0900

Paul Wouters wrote:

>> compromised and forged zone delegation (with an IP address of a
>> forged nameserver using forged public/secret keys) is signed by a
>> valid key, it will not be noticed easily.

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

First, such impressively strong in depth security as strong
as those for nuclear reactors at Fukushima demonstrates a
fact that PKI is not cryptographically secure.

Not surprisingly, diginotar was equally strongly secure.

	https://roselabs.nl/files/audit_reports/Fox-IT_-_DigiNotar.pdf

	The main production servers of DigiNotar, including the
	CA servers and the accompanying hardware security module
	(netHSM), were located in a physically highlysecured
	room and in the Secure-net network segment.

	When a request was approved using the four-eye principle,

	In order for the CA software to automatically sign the
	certificate request, the appropriate private key
	needed to be activated in the netHSM. This was done
	by authorized employees by entering a smartcard
	into the netHSM combined with a PIN code.

So, DNSSEC TLDs are as secure as diginotar.

> At this point, it is easier to obtain physical access to the enduser
> device and compromise the OS, browser or webpki stack - DNS attack is
> not needed.

According to your theory, diginotar should not have been attacked.

It's like guaranteeing nuclear reactors protected by in depth
security never meltdown, proven by so many experts.

But, real security experts including bad guys are not hyped
by mere impression of security, which is merely not very
strong obscurity, which caused meltdown of diginotar.

So, may I volunteer to write a WG ID to obsolete DNSSEC
because it is only as secure as diginotar?

>> Merely because message ID is short, which can be improved, which is
>> a lot easier than deploying so costly DNSSEC.
> 
> You did not answer my earlier question on how you obtain this alleged
> secure IP address of all DNS nameservers you plan to talk to with
> "extra strong message ID".

I can't understand your question because upgrading all the
nameservers and resolvers operated by security aware
operators longer message ID capable is not so difficult.

 > Note also the same employee from above can tcpdump their nameserver
 > or read the RAM and give the extra strong message ID to the attacker.
 > So all attacks you attribute to DNSSEC apply to msg ID too.

So, just accept the reality that DNS, relying on zone chain,
which is subject to MitM attacks on intermediate zones, can not
be so secure regardless of whether you use DNSSEC or not.

>> If a resolver has some knowledge on contents of an attacked zone,
>> such as IP addresses of some servers or some DNSSEC keys, it can
>> detect a DNS (both resolver and DNSSEC) attack by comparing,
>> unless an attacker knows IP addresses of detecting resolvers and 
> Forged answers require access to a private key. As stated those tend
> to be in HSMs or offline, 

HSMs? See above.

> so "attacker knowing IP address" is
> insufficient to forge answers.

I'm afraid you completely miss my point.

						Masataka Ohta

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Sat, 26 Mar 2022 08:15:51 +0100

I am also struggling finding your point.

el

—
Sent from Dr Lisse’s iPhone/iPad
On 24. Mar 2022, 11:56 +0100, Masataka Ohta <[email-masked]>, wrote:
> […]

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 27 Mar 2022 22:24:21 +0900

> 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

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Sun, 27 Mar 2022 15:44:18 +0200

Every single one, actually.

el

—

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 27 Mar 2022 23:14:08 +0900

> Every single one, actually.

I understand that you don't understand, at all, DNSSEC
almost all details of which to make DNS and PKI precisely
match are of my design, through which I puzzled by
too complicated operational practices of PKI.

					Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Sun, 27 Mar 2022 10:42:30 -0400

Ohta-san is using the term MiTM in an unusual way. Normally we mean an
on-path attack. Ohta-san is talking about attacks on root and intermediate
zone keys using the term "man-in-the-middle," that's all. It's true as far
as it goes, but doesn't support the conclusion he's reaching.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 28 Mar 2022 00:07:37 +0900

Ted Lemon wrote:

> Ohta-san is using the term MiTM in an unusual way.

Wrong. See, for example,

	https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack
	More facts have recently come to light about the compromise
	of the DigiNotar Certificate Authority, which appears to have
	enabled Iranian hackers to launch successful man-in-the-middle
	attacks against hundreds of thousands of Internet users inside
	and outside of Iran.

There are a lot of other examples. For example, both plain DNS and
DNSSEC are subject to MitM attacks on software distribution chain
to forge root zone information of IP addresses of root servers
or public key of the root zone.

> Normally we mean an on-path attack.

Exactly, MitM attack means on-path attack on some chain including
but not limitedvto ISP chain. So?

> Ohta-san is talking about attacks on root and intermediate
> zone keys

That is, well known MitM attack, in this case, on zone/CA chain.

> using the term "man-in-the-middle," that's all.

Your denial of the term of MitM can not deny a fact that PKI
including DNSSEC is not cryptographically secure, diseparate
attempt against which is to make intermediate intelligent
entities of CAs physically secure, which was demonstrated
by diginotar not secure at all.

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Mar 2022 09:12:57 -0700

(sunday long read, beware.)

Masataka Ohta wrote on 2022-03-27 06:24:
> ...

> intermediate CAs possible.

i consider that your arguments about PKI CAs apply to DNSSEC in the form 
of static and dynamic trust anchors, those being the root key, and the 
set of DS RRsets in a validation chain. it is always the case that if a 
CA is compromised then security is compromised -- this is axiomatic. in 
DNSSEC, with CA PKI interpreted as "the root key and every DS RRset", it 
is a large attack surface, larger even than in X.509. but if any PKI 
having a CA is insecure, then we must reason within that context. more 
"below".

> intermediate zone and is not cryptographically secure.

i think the specific reliance on physical security is irrelevant. i know 
of secure digital vaults, and i know of insecure physical vaults. we can 
reason about the vulnerability of a PKI CA (which in DNSSEC takes the 
form of the root key and all DS RRsets) without specificity as to cause. 
more "below".

> ...

i think there are two assumptions in the DNSSEC design which go to your 
assertion of meaninglessness. first, birthday attacks of the kind you 
describe are essentially hop by hop (transactional), and any defense 
against only hop by hop attacks will necessarily leave open data 
integrity vulnerabilities in the end to end data path. for example, if 
we had larger message IDs we would still be vulnerable to data 
modification attacks by RDNS operators, or by BGP injections which 
change the identity of an IP address. therefore pure hop by hop security 
features were out of scope for the DNSSEC effort.

second, a general and effective prohibition against end to end attacks 
can be made proof against hop by hop attacks also. DNSSEC attempts this. 
only by data compromise against the PKI CA (which for DNSSEC means the 
root key and any DS RRsets needed for a particular validation) can false 
data be injected by a "hop" in the hop by hop system without detection. 
since this is possible, it should be noted, and caution be exercised. 
this caution includes transparency by each CA operator (the root, and 
every DS RRset owner) as to the methods of generating and using secret 
keys associated with a CA element. this is often "security theater" as 
originally defined by bruce schneier:

https://www.schneier.com/essays/archives/2009/11/beyond_security_thea.html

however, "security theater" is not an unalloyed failure:

https://healthguardsecurity.com/bruce-schneier-ted/
https://www.cnet.com/culture/bruce-schneiers-new-view-on-security-theater/

accordingly, DNSSEC admits to the inevitability of "security theater" 
but considers it, along with the inevitability of compromise in any PKI 
CA system, to be design inputs and not design constraints. more "below".

> or without DNSSEC, be subject to various MitM attacks.

this proposal is out of scope for the reasons described above.

> understood by you not so clealy?

we (you and i) have discussed this on the record several times in the 
last 25 years, and i think i have always understood your concerns. in 
fact i share your concerns, but not your conclusions.

DNSSEC's focus is on end to end data integrity, and handles hop by hop 
data integrity issues by side effect. DNSSEC expects PKI CA compromise 
but makes such compromises transparent and observable. RFC 3833 should 
clarify any misunderstandings as to DNSSEC's intent and utility.

the impact of DNSSEC on relying parties is paramount. DNSSEC makes DNS 
more fragile, signaling failure in both attack scenarios and the more 
common operational error scenarios (wrong keys, expired signatures, and 
so forth). this fragility is another inevitability, another design 
input. no system of this kind will avoid rampant false negatives.

---

"below":

i think your primary argument is that DNSSEC solves the wrong problem, 
and the best formulation of that concern that i have seen is here:

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

while "best", this formulation does not reason from inevitabilities, and 
as such, is unpersuasive. i invite you to raise the bar and offer a more 
persuasive formulation. you have not done so here. the DNSSEC design has 
ruled out several alternatives, including "do nothing" and "handle only 
hop by hop attacks". i don't think you would get traction by arguing for 
either such alternative.

see also my remarks, and others', here:

> Date added: August, 2008
> 
> DNSSEC is a colossal flop, but not a mistake. It's an embarrassment, but we'd do it all again if we had to. It's late -- it was started years before the IPv6 effort but is (believe it if you can) even less finished and less deployed than IPv6. It's ugly and complicated and if we knew then what we know now we'd've scrapped DNS itself and started from scratch just to avoid the compromises we've made. But we didn't know then, etc., and what we have to do now is avert our gaze and fully deploy this ugly embarrassing thing.
> 
> Let me explain.
> ...

https://dnssec.net/why-deploy-dnssec

-- 
P Vixie

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 28 Mar 2022 16:44:20 +0900

>      attacks against hundreds of thousands of Internet users inside

Sorry, this is not a good reference because it mentions MitM attack
on ISP chain is enabled by diginotar.

A proper reference is:

	https://www.thesslstore.com/knowledgebase/ssl-support/explaining-the-chain-of-trust/
	Intermediate Certificate – Intermediate certificates branch
	off of root certificates like branches off of trees. They
	act as middle-men between the protected root certificates
	       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	and the server certificates issued out to the public.
	^^^^^^^^^^^^^^^^^^^^^^^^^^^

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 28 Mar 2022 17:45:13 +0900

Paul Vixie wrote:

> i consider that your arguments about PKI CAs apply to DNSSEC in the
> form of static and dynamic trust anchors, those being the root key,
> and the set of DS RRsets in a validation chain. it is always the case
> that if a CA is compromised then security is compromised

An important question is how the CA is protected. Physically or
cryptographically? As the CA is not cryptographically
protected, DNSSEC is not cryptographically secure.

> i think the specific reliance on physical security is irrelevant.

But it is relied by DNSSEC, which is why not me but Paul Wouters
wrote:

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

> i
> know of secure digital vaults, and i know of insecure physical
> vaults.

You don't have to use metaphor of vaults because
diginotar successfully demonstrated that a CA
with physical security by

    HSMs and physical access restrictions
    using a "four eyes minimum" approach.

can be compromised.

> i think there are two assumptions in the DNSSEC design which go to
> your assertion of meaninglessness. first, birthday attacks of the
> kind you describe are essentially hop by hop (transactional), and any
> defense against only hop by hop attacks will necessarily leave open
> data integrity vulnerabilities in the end to end data path.

"hop by hop (transactional)"??? Do you mean "transaction
by transaction"? Or, do you mean hops over routers,
which is not "transactional" at all.

> for
> example, if we had larger message IDs we would still be vulnerable to
> data modification attacks by RDNS operators, or by BGP injections

They are not "birthday attacks". DNS is subject to MitM attacks
on ISP chain, CA chain and software distribution chain.

> which change the identity of an IP address. therefore pure hop by hop
> security features were out of scope for the DNSSEC effort.

I'm afraid DNSSEC prevents MitM attacks on ISP chain.

> second, a general and effective prohibition against end to end
> attacks can be made proof against hop by hop attacks also.

I'm afraid there is no such thing as "end to end attacks".

You should just say "diginotar".

 >  accordingly, DNSSEC admits to the inevitability of "security
 > theater" but considers it, along with the inevitability of compromise
 > in any PKI CA system, to be design inputs and not design constraints.
 > more "below".

No PKI is cryptographically secure. So?

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

Certainly, the proposal to obsolete DNSSEC is out of scope for
DNSSEC. So?

 >> Which of my points, if any, are you saying, can not be understood
 >> by you not so clealy?
 >
 >  last 25 years, and i think i have always understood your concerns.
 > in fact i share your concerns, but not your conclusions.

Thanks.

 >> DNSSEC's focus is on end to end data integrity,

Note that "end to end data integrity" is applied on ends of
not only ISP but also CA and software distribution chains.

 > DNSSEC expects PKI CA
 > compromise but makes such compromises transparent and observable.

No, as I wrote to Ted Lemon:

: If a parent zone administrator or some employee of it is
: compromised and forged zone delegation (with an IP address
: of a forged nameserver using forged public/secret keys)
: is signed by a valid key, it will not be noticed easily.

 > RFC
 > 3833 should clarify any misunderstandings as to DNSSEC's intent and
 > utility.

It was before diginotar. At that time most people did not think
PKI cryptographically insecure.

 > i think your primary argument is that DNSSEC solves the wrong

No, my primary argument is that DNSSEC is not cryptographically
secure. It prevent MitM attacks on ISP chain but not on CA chain.

 > https://sockpuppet.org/blog/2015/01/15/against-dnssec/

In it, I can't find a concern that CAs can be compromised.

					Masataka Ohta