Paul Vixie wrote:
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
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".
> 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/
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.
>
> this proposal is out of scope for the reasons described above.
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?
>
> 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.
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.
> "below":
>
> i think your primary argument is that DNSSEC solves the wrong
> problem,
No, my primary argument is that DNSSEC is not cryptographically
secure. It prevent MitM attacks on ISP chain but not on CA chain.
> and the best formulation of that concern that i have seen is
> here:
>
> https://sockpuppet.org/blog/2015/01/15/against-dnssec/
In it, I can't find a concern that CAs can be compromised.
Masataka Ohta
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
