(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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
