Subject: [DNSOP] 5011-security-considerations status

From: Wes Hardaker <[email-masked]>
Date: Thu, 01 Feb 2018 10:30:44 -0800

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?

-- 
Wes Hardaker
USC/ISI

---

From: Michael StJohns <[email-masked]>
Date: Thu, 1 Feb 2018 14:43:43 -0500

*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

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 01 Feb 2018 12:27:47 -0800

Michael StJohns <[email-masked]> writes:

> 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
> might get there early.... and that's a don't care when looking at
> worst case.

Thanks for the review Mike.  6.1.6 gets to the value you want
(activeRefresh), by more explanation than you want because I'm doing
showing a full analysis of all issues.  I think we'll need to agree to
disagree on whether the full analysis is beneficial to the document or
not (I believe it is).

> addWaitTime = sigExpirationTime + //  this is the last time that an
> old signature can be replayed
>                             addHoldDownTim + // this is the latest
> time that a node can finish its addHoldDown interval (assuming ")
>                             retrySafetyMargin // this is the
> additional time the publisher should wait to compensate for real-world
> issues (drops/retransmits/networkfailure)

That's what's in 6.2.2, so we're good there.  I realize you don't like
the flipside in 6.2.1, but again that's where we disagreed on the best
way to present it so I added both so we'd both be happy.

In the end, in this version of the document you and I both agree on the
math, but not necessarily on how it's presented.  Thanks. 

-- 
Wes Hardaker
USC/ISI