[DNSOP] Re: Fwd: New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-02.txt

[Peter Thomassen <[e-mail]>]

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/