Re: [DNSOP] 5011-security-considerations status

[Michael StJohns <[e-mail]>]

*pounds head on table*  I'm really not sure how things get worse each 
time but they appear to.

Please, please get rid of activeRefreshOffset, clockskewDriftMargin and 
retryDriftMargin.    Replace this with a single paragraph noting that 
the maximum time (assuming no retransmissions) a node has to wait after 
its holdDownTime expires is activeRefresh.  (e.g. the conclusion you 
reach at the bottom of 6.1.6).  The rest of the math you have is 
basically explaining why in certain chosen circumstances some nodes 
might get there early.... and that's a don't care when looking at worst 
case.

6.2.1 and its related wall clock calculation should be only


addWaitTime = sigExpirationTime + //  this is the last time that an old 
signature can be replayed
                             activeRefresh + // this is the latest time 
that a node can start its addHoldDown timer (assuming no 
drop/retransmit/fail)
                             addHoldDownTim + // this is the latest time 
that a node can finish its addHoldDown interval (assuming ")
                             activeRefresh + // this is the latest time 
that a node can install the new trust anchor (assuming ")
                             retrySafetyMargin // this is the additional 
time the publisher should wait to compensate for real-world issues 
(drops/retransmits/networkfailure)


  I'm done here.  No more responses, no more arguments, no more 
interaction.   Do what you will.  I'll just send out my "-1" and be done 
with it.

Mike


On 2/1/2018 1:30 PM, Wes Hardaker wrote:
> Sorry for the long delay to get this version out (vacation, family
> issues, deadlines are all just excuses).
>
> The -11 version of the document has a redesigned 6.1.6 that I'd love
> everyone to concentrate on.  Hopefully it more clearly articulates the
> issues surrounding Mike's found need to wait yet another activeRefresh
> and spells out the analysis behind the delay better (three potential
> delays, from which we take the maximum value).
>
> We had spoken at the last meeting of doing another update and a 1 week
> last call again.  Due to the complexity of the changes in -11, I'd like
> to request a 2-week last call instead as I think the changes are
> important enough to warrant a longer LC.  Chairs?  Thoughts?
>