Thinking about the KeyTrap problem, and the discussions here about potential approaches to mitigation of "bad stuff", one thought that came to mind was that everyone would necessarily have the same data to crunch (or avoid), and there might be ways to leverage the work required.
This is just an initial though, and might have obvious shortcomings, but those might have suitable ways of being avoided. The general idea would involve: - Some kind of identification and trust for resolvers or resolver operators - Attestation of specific tuples as being problematic - Specification on what the problem is - Possibly proof of work or similar - A place to publish those results for the benefit of other resolver operators - Local policy on whether/how to trust the published results - Methods for both manual and automated publication The example use case would be a few operators of large well-known resolver sets, publishing to some well-known location when DNS entries are found which exhibit specific criteria. Other operators could have local configurations of quorum (how many reports by different operators are required), which operators to trust (or rules for establishing trust such as GPG-type things). If the details can be worked out and such a system were deployed, it would have the potential to significantly raise the bar for attackers. It could also provide mechanisms that scale, for warning operators of new attacks (presuming some sort of language or encoding for what the problem seen is or which DNS tuples are problematic.) The attestation etc would be intended to prevent attackers causing DOS via false positives. There might be benefit to revocation of reports based on a counter-quorum, if that activity is expected or observed. There are obviously scaling issues in adding this to things resolvers need to do. Suitable scaling approaches for publication and signaling might be able to be established, or perhaps software vendors could add ways for publication/consumption on their respective packages, similar to e.g. code signing or fingerprint publications. Any reactions and feedback are welcome, or just discuss it in a thread... Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
