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

[Wes Hardaker <[e-mail]>]

Michael StJohns <[e-mail]> 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