Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Vixie <[e-mail]>]

(sunday long read, beware.)

Masataka Ohta wrote on 2022-03-27 06:24:
> Dr Eberhard W Lisse wrote:
> 
>> I am also struggling finding your point.
> 
> ...

i am not eberhard, but:

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

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

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

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

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

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

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

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

> Which of my points, if any, are you saying, can not be
> 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