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. -- Glen Wiley KK4SFV Sr. Engineer The Hive, Verisign, Inc. On 7/30/14 6:15 AM, "Rene Bartsch" <[email protected]> wrote: >Two years ago I would have thought the same. But today we are far beyond >conspiracy theories. We are facing the biggest coordinated hacker attack >in history of the internet. After what we've learned in the last year >the US government has abused the trust of billions of internet users to >gain control over the internet. We have no clue what other governments >and intelligence angencies have done or might do. The former director of >the austrian intelligence agency expects a lot of new disclosures in the >next half year. Internet users worldwide are furious about the >situation. > >If we sell DANE as magic bullet without mentioning the trust anchor can >manipulate the whole DNSSEC system and who the trust anchor is users >will trust DANE blindly. If the trust anchor abuses control over DNSSEC >this will blow up right into our face and harm the reputation of the >IETF. > >In my opinion we should mention the identity of the DNSSEC trust anchor >in security considerations and we should mention the DNSSEC trust anchor >has the possibility to manipulate the whole DNSSEC system. > >Regards, > >Renne > > >Am 2014-07-28 19:12, schrieb Olafur Gudmundsson: >> <chair-hat> >> This discussion is off topic. >> DANE is about how to leverage DNSSEC by applications and conspiracy >> theories are not within our charter. >> >> Anyone that does not trust DNSSEC operations is free to ignore >> distribution of OPENPGP keys via DNS, and continue to >> use the web of trust. >> </char-hat> >> >> Olafur >> >> On Jul 28, 2014, at 10:59 AM, Rene Bartsch <[email protected]> wrote: >> >>> Maybe I misunderstood draft-zhang-ct-dnssec-trans-00 but I do not see >>> how it would help. Consider the following case: >>> >>> (Forced by secret US law) The IANA secretly hands over the current >>> private key of the DNSSEC trust anchor to a US government agency which >>> uses the private key to sign forged zones and feeds them to DNS >>> resolvers. That way US government agencies would be able to manipulate >>> any DNS record including OpenPGP while users would be lulled in a >>> false sense of security. >>> >>> In case I didn't miss any super-security feature users should be aware >>> of that fact. >>> >>> Am 2014-07-28 15:52, schrieb Paul Wouters: >>>>> 3. Security considerations: The IANA has control over the DNSSEC >>>>> root keys. As the IANA is bound to US law, US government agencies >>>>> probably have access to the DNSSEC root keys and are capable to >>>>> manipulate the OpenPGP keys signed with DNSSEC. >>>> There is currently a first attempt at specifying transparancy for >>>> DNSSEC for those who want to audit/track the DNSSEC root or parent >>>> domain holders: >>>> http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans-00 >>>> Paul >>> >>> -- >>> Best regards, >>> >>> Renne >>> >>> _______________________________________________ >>> dane mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dane > >-- >Best regards, > >Rene Bartsch, B. Sc. Informatics > >_______________________________________________ >dane mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
