thanks for your feedback. If the DNS message can be verified by DNSSEC, the resolver should response the DNS package with the "AD" bit to the end user. If the verification is failed, it should response "Bogus" If the resolver do not get enough data to do the verification, then the resolver which weak trust anchor should be response with "insecure" DNS package. it is up to end-user or netizens to decide what to do next.
this method is useful for the kaminsky attack. for the downgrade attacks, the resolver which configured with weak trust anchor has told the end-user that "it is a insecure DNS package", I think the end-user has the ability to decide to drop/accept it. thanks ------------------ original email ------------------ >From: Matth�us Wander<[email protected]> >Reply-To: >To: [email protected] >Subject: Re: [DNSOP] draft-zhang-dnsop-weak-trust-anchor.txt >Date: Fri, 30 May 2014 15:05:32 +0200 > Hi, Section 4: > If the resolver was > configured with a weak trust anchor and got nothing after sending a > request with DO bit set, then it should clear DO bit in the EDNS0 in > the query message and query again to the authoritative name server. > So it could receive a normal DNS message (with no DNSSEC information, > if the previous packet loss was caused by large size) and continue > its DNS query process, then return the result as an insecure message. The concept is vulnerable to downgrade attacks: - An on-path MITM attacker can drop DNSSEC messages to force insecure DNS and then spoof bogus DNS responses. - An off-path attacker can saturate links to delay/drop DNSSEC messages to force insecure DNS and then spoof bogus DNS responses. The interoperability problems can be solved without degrading security, e.g. fall back to TCP. Regards, Matt -- Universitt Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
