Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt

[Wes Hardaker <[e-mail]>]

Michael StJohns <[e-mail]> writes:

> Also, you're still missing the fact that a given resolver can start
> its addHoldDown timer anywhere in the range of [0..activeRefresh]
> AFTER the signature expiration depending on when it was starting its
> clock.  All of your calculations are starting from the wrong point.

No I'm not.  Set the resolver query offset amount to something large and
it does exactly what you're talking about.  I didn't forget it.

In fact, the most interesting case is when you set it large (set it to
300d, and the code will clip it to activeRefresh-1 anyway) and then you
set the resolver query drift amount to -1.  You'll note, in this case,
that that the dnskey is accepted *after* my current activeRefreshOffset
line, *proving* your case.  You keep saying I don't understand and don't
agree with you, but if this doesn't prove that I both do understand and
agree with the problem I don't know what will.  Go change *only* those
two lines in the simulator and it *shows* that you have very
legitimately found a source of real-world error that must be accounted for.

>
> Your calculations represent the best case [e.g. triggers at 0 for both ends of the problem] when what
> you want is worst case.

Try 300d in resolver query offset.
-- 
Wes Hardaker
USC/ISI