Michael StJohns <m...@nthpermutation.com> writes: > 2) T + activeRefresh is the time at which the server sees the last > query from the last resolver just starting their trust anchor > installation. > 3) T + activeRefresh + addHoldDownTime is the time at which the server > sees the first query from any resolver finalizing its trust anchor > installation.
There is where we disagree. Given 2, where you state "last query from the last resolver is just starting", I argue that exactly an addHoldDownTime beyond that is when that *exact same resolver* will finish because it will have sampled the first at (2) and again at exactly T + activeRefresh + addHoldDownTime and accept it, per 5011: Once the timer expires, the new key will be added as a trust anchor the next time the validated RRSet with the new key is seen at the resolver. And the last query from the last resolver will be at T + activeRefresh + addHoldDownTime. > Between (2) and (3) any given resolver may drift/retransmit with the > result that any given resolver may end up making a query just before > (3) placing its next and final query at (3) plus activeRefresh. Please forget drift in the top half of the equation. There is zero drift in the mathematically precise section. We will deal with drift, delays, and everything else in the safetyFactor alone, with many terms or concepts within it to get it right. >> 5) will query again at lastSigExpirationTime + 30 days - .000001 > No - from the servers point of view, the worst client (which is the > only one the server cares about) will make its last query before trust > anchor installation at lastSigExpirationTime + activeRefresh (when the > last CLIENT saw its first valid update) + 30 days -.0000001. Yes, I said that in 6 stating that it was *still waiting*. IE, #5 was supposed to describe the second to last query. >> 6) notes this is still in waiting period Let me put together something, per Paul's request, to work at this from another angle where one of us can be shown right or wrong. [... retry, delay text by me deleted ...] > And again. NO. The retransmits over a given set of clients in the > addHoldDown period will result in at least one client (the "worst" > client) ending up making a query just before the expiration of ITS > addHoldDown timer. Assuming the worst case of at least one client > making a query just before the lastSigExpirationTime and that same > client drifting/retransmitting enough to make a query just before its > addHoldDown time the activeRefreshOffset is a useless value to > calculate. If you want to put an extra activeRefresh into the safetyMargin to account for drift, I'm willing to do so. Or we can insert a new term labeled "driftSafetyMargin" and define it as activeRefresh if you want. But that goes below my math line, not above it (and we can relabel safetyMargin as retryFailureSafetyMargin). >From a purely security analysis point of view, the first thing we have to agree upon is the precise moment at which all clients in a perfect world, with *no errors at all* (no drift, no retries, no transmission line delays, no CPU processing delays, no clock failures, etc). Once we have this line in the sand in place, then we can introduce real-world correctional elements to account for reality sneaking into our perfect world. I'm trying to talk only about the perfectionists world line in the sand first, and then introduce needed operational components *after that line*. You keep inserting "drift" (eg) everywhere in the process of this argument, which I absolutely agree needs to be dealt with. But below my perfect-world line only. The way I keep reading everything you've written is that your perfect line includes two activeRefreshes, which I (still) argue is incorrect. As I said last time and this time, I'd be happy to insert a "drift" term, but lets please label it what it is. If you agree with that, I'll make that change and push. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
