Hi Christian, On 6/14/23 11:55, Christian Huitema wrote:
In the old model, we are very concerned about third parties spoofing responses and polluting resolver caches. In a secure transport model, the only parties that can spoof responses are the resolvers themselves: authoritative resolvers abusing their authority to add falsehoods in additional sections, recursive resolvers abusing the client trust to send false responses.
I'm not sure what you mean by "authoritative resolver", but another attack vector definitely is to compromise a secondary nameserver and modify the zone content it serves. That is still possible with encrypted transport, unless DNSSEC is used (and signing is not done on the same machine).
I do think that DNSSEC is still useful, even in a secure transport world. But the focus changes. For example, if we consider that "spoofing by recursive server" is a threat, then having the recursive set bits to affirm that the response is verified is not much of a protection -- the emphasis should move to verification by the client. I would love to see this discussed.
I agree that client-side validation would be ideal. One important aspect here is to save on the latency caused by extra queries; my impression is that this extra cost is generally considered prohibitive. Experimental protocols for this have been published. Specifically, RFC 7901 and RFC 9102 come to mind. I'm not aware of any implementations of these protocols -- I think having software support, perhaps experimental, in some of the common software packages would be REALLY cool. Cheers, Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
