On 7/19/24 08:34, Yorgos Thessalonikefs wrote:
I'm also interested in the possibilities for malicious use of this extension.
Can a malicious domain cause a resolver to do an enormous amount of work? Can
a malicious intermediary cause an enormous volume of error reports?
For validation work, the resolver could be made to try validation twice; once
with dry-run DSes, and if that fails, once more with the real DSes.
"try validation" could mean a lot of things for validating software but with
the recent KeyTrap family of vulnerabilities, validators should have sufficient
strategies/limits to mitigate excessive use of validation time.
Since dry-run may need to restart validation with the real DSes those
strategies/limit would need to be restarted as well.
This implies that supporting dry-run means that a validator can't commit to the
actual work it is will to do. This seems like it could be a problem; I'm
curious to learn what resolver folks say.
Example:
- Consider a validator to be willing to perform work W in a certain situation.
- With dry-run:
* can be exhausted with dry-run DS records
* to follow real DS, work count is then restarted for real DS
--> total work = 2W
* If the resolver really wants to limit its work to W, it could commit to
only W/2
--> in the worst case, work is still bound by 2 * W/2 = W
- Now, when there is *no* dry-run DS, should the validator spend work W or W/2?
* There's probably little reason to bound by W/2, because actual willingness
is W
* Work bounds with dry-run would then be W/2, and in real life would be W
--> In this case, validation strategies for dry-run and real life would
differ! Probably not intended ...
To prevent this discrepancy between how dry-run and real validation is done,
the resolver either needs to halve its work bounds (which is a disadvantage for
real deployments), or commit to twice the work it is willing to do.
Hmm....
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
