2012/10/24 Paul Wouters <[email protected]> > On Tue, 23 Oct 2012, Guangqing Deng wrote: > > 2012/10/23 Alexander Gurvitz <[email protected]> >> Hello. >> >> http://tools.ietf.org/html/rfc6394#section-3.1 : >> >> Continuing to require PKIX validation also limits the degree to >> which >> DNS operators (as distinct from the holders of domains) can >> interfere >> with TLS authentication through this mechanism. As above, even if a >> DNS operator falsifies DANE records, it cannot masquerade as the >> target server unless it can also obtain a certificate for the target >> domain. >> >> >> This seems like a mistake to me - DNS operator can always issue a >> fraudulent usage 2/3 record, >> and thus skip the CA validation. >> >> >> >> Remind that the section 3.1 just discusses the “CA Constraints” which >> refers to usage 0 TLSA record but not usage 2/3 TLSA records, which >> is discussed in other sections. So, the statement “even if a DNS operator >> falsifies DANE records, it cannot masquerade as the target >> server unless it can also obtain a certificate for the target domain” is >> correct. >> > > But it can, just by updating the A/AAAA record to a server it owns. >
What you pointed out is about the incorrect configuration of DNS resource records, which may be another story. Just as previously discussed in this mailing list, DNSSEC may add data integrity protection and data origin authentication but definitely not the trustworthiness for the DNS resource records that it protects. If the DNS operator is going to do something bad (such as incorrectly configuring DNS resource records) intentionally or unintentionally, DNSSEC cannot stop the DNS operator from doing that. > > I vague remember pointing out this exact mistake in the draft. I guess > we all kind of missed updating it in the end. > > Paul > -- Guangqing Deng
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
