Am 2014-07-30 15:21, schrieb Mark Andrews:
In message <cffe5fc9.4d653%[email protected]>, "Wiley, Glen" writes:
Renne,
While it is technically true that the holder of the trust anchor could
alter key material it would be impossible to accomplish unnoticed. In
order for a trust anchor to change your zone (say by changing an A
record)
they would have to create a new private key (and corresponding public
key)
then sign the altered RR set.
Your DNS key signing and zone signing keys should be protected with as
much diligence as your private signing and encryption keys.
It is as though a locksmith would have to change the locks on a house
in
order to open the door. Sure they can do it but the homeowner will
notice
immediately when their keys no longer work. My analogy breaks down if
you
take it too far, but I hope it conveys the point.
I am far more worried about vectors that can be leveraged passively
and
unobtrusively.
I agree that we should be open about DNSSEC/DANE however the holder of
the
trust anchor can not manipulate the DNS without being detected.
If one can intecept the packets one could fake up a world view.
This would be detectable if you have trust anchors for the parts
of the world being faked.
If one can't intercept the packets it will be almost certainly be
detected.
Maintaining a set trust anchors for all the TLD's would defeat most
of the threat. A state agency would have to compromise multiple
tlds to pull this off not just the root.
I have the following attack in mind:
An attacker (Mallory) with access to the trust anchor keys runs a
man-in-the-middle attack on sender and recipient. He forges the
OPENPGPKEY RRs, the ZSK-RRs and KSK-RRs of the sender and recipient
domains and the TLDs but uses the current origin keys of the trust
anchor to sign the forged DNSSEC RRs.
Alice gets the OPENPGPKEY 1 of Mallory as Bob's and Bob gets the
OPENPGPKEY 2 of Mallory as Alice's via DANE.
Alice -> OPENPGPKEY 1 of Mallory -> Mallory -> OPENPGPKEY of Bob ->
Bob
Bob -> OPENPGPKEY 2 of Mallory -> Mallory -> OPENPGPKEY of Alice ->
Alice
Unless Alice and Bob do not accidentially compare their public OpenPGP
keys manually they won't realize the attack.
It seems DNSSEC/DANE helps against most hackers and attackers but cannot
protect from attackers which have access to both the trust anchor keys
and routing infrastructure.
Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with resolver
software?
Renne
--
Best regards,
Rene Bartsch, B. Sc. Informatics
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
