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

From: [email-masked]
Date: Tue, 19 Dec 2017 10:49:57 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Security Considerations for RFC5011 Publishers
        Authors         : Wes Hardaker
                          Warren Kumari
	Filename        : draft-ietf-dnsop-rfc5011-security-considerations-10.txt
	Pages           : 19
	Date            : 2017-12-19

Abstract:
   This document extends the RFC5011 rollover strategy with timing
   advice that must be followed by the publisher in order to maintain
   security.  Specifically, this document describes the math behind the
   minimum time-length that a DNS zone publisher must wait before
   signing exclusively with recently added DNSKEYs.  This document also
   describes the minimum time-length that a DNS zone publisher must wait
   after publishing a revoked DNSKEY before assuming that all active
   RFC5011 resolvers should have seen the revocation-marked key and
   removed it from their list of trust anchors.

   This document contains much math and complicated equations, but the
   summary is that the key rollover / revocation time is much longer
   than intuition would suggest.  If you are not both publishing a
   DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new
   Secure Entry Point key for use as a trust anchor, you probably don't
   need to read this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-10
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Bob Harold <[email-masked]>
Date: Tue, 19 Dec 2017 15:24:17 -0500

> security-considerations-10
6.1.7.  driftSafetyMargin

"Moving past the theoretical model parameters above, we not that clock
drift"

"not" -> "note"

-- 
Bob Harold

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 19 Dec 2017 12:37:55 -0800

FYI, there are multiple data analysis engines you can play with when
trying to figure out the math and how it works.

MSJ posted a java program that simulates a lot of clients under
randomized conditions with failure rates here:

https://www.ietf.org/mail-archive/web/dnsop/current/msg21602.html

Additionally, I wrote a javascript based calculator for a single
resolver so you can try to put in "worst case" numbers into form fields
and have it calculate what happens here:

https://www.isi.edu/~hardaker/projects/5011/

-- 
Wes Hardaker
USC/ISI

---

From: Michael StJohns <[email-masked]>
Date: Tue, 19 Dec 2017 18:05:12 -0500

I didn't think this could get worse.  I was wrong.

I can't support any version of this document for publication.   In the 
same way that activeRefreshOffset is a nonsensical value so to are  
driftSafetyMargin and timingSafetyMargin.

1) Drift happens per query.
2) Any drift that happens related to the multiple queries in the 
addHoldDown interval can safely be ignored with respect to its impact on 
the overall wait time for the publisher.  (e.g. all the drift is going 
to do is change the phase of the last query in the interval with respect 
to the end of the addHoldDown time)
3) The only other drift that may be of interest is the drift at the 
beginning and end of the queryInterval where the end of the interval is 
the beginning of the addHoldDown interval. Given that a typical drift is 
something like 1-60 seconds it can safely be ignored related to all the 
other stuff.

Timing safety margin is based on the nonsensical driftSafetyMargin and 
activeRefreshOffset and is then by definition also nonsensical.

(And yes, I realize that Wes has set driftSafetyMargin to activeRefresh 
meaning that calculated results are identical to what I want, but 
there's no analysis that supports the use of a driftSafetyMargin and 
this just seems to be sleight of hand to replace activeRefreshOffset 
with a term that has a value activeRefresh... *pounds head against wall*)

Please delete 6.1.6, 6.,1.7 and 6.1.8 and fix the formulas accordingly.

Again:

addWaitClockTime = lastSigExpirationTime + activeRefresh + 
addHoldDownTime + activeRefresh + safetyMargin (which now seems to be 
labeled retrySafetyMargin).

Mike

On 12/19/2017 1:49 PM, [email-masked] wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 20 Dec 2017 10:15:36 -0800

> 1) Drift happens per query.

Agreed.  I'll go double check that I didn't imply that, or better: make
sure I state that in the document.

> addHoldDown interval can safely be ignored with respect to its impact
> on the overall wait time for the publisher.  (e.g. all the drift is
> going to do is change the phase of the last query in the interval with
> respect to the end of the addHoldDown time)

Most likely, but I could see bad code calculating total waited time by
adding time between queries together, rather than doing a wall clock
subtraction from new - start_hold_down like they should.

Anyway, I agree only the last one should be shifted in the correct case.

> beginning and end of the queryInterval where the end of the interval
> is the beginning of the addHoldDown interval. Given that a typical
> drift is something like 1-60 seconds it can safely be ignored related
> to all the other stuff.

I think I agree with that too.  Only a small percentage of clients will
end up needing the extra queryInterval.

> (And yes, I realize that Wes has set driftSafetyMargin to
> activeRefresh meaning that calculated results are identical to what I
> want, but there's no analysis that supports the use of a
> driftSafetyMargin and this just seems to be sleight of hand to replace
> activeRefreshOffset with a term that has a value
> activeRefresh... *pounds head against wall*)

Hmm...  I'll try to clean up the wording some more to make the analysis
more clear.  But in the end, yes: when real world conditions occur
you're right and the extra activeRefresh is needed.  Again, you're right
there is *another* new issue with 5011 that had to be spelled out, and
I'm glad you caught yet another needed length extension during last
call.

But no, it wasn't slight of hand and have no idea why you think I'd be
trying to trick you.  Again, Mike, I can't state this more clearly: I
admit you were right and found a more important timing constraint than
activeRefreshOffset.  That being said, I left (and want to leave)
activeRefreshOffset in the document so that others performing similar
analysis of the whole 5011 process understand all the ramifications of
both the theoretical and practical applications of the 5011 algorithm
and usage.  Thus, we actually agree.  You just want to limit what goes
into it.

> labeled retrySafetyMargin).

Which is exactly what's in ...  *crap* ...  I missed a term in an
equation.

But 6.2.1.1 *will* state:

   addWaitTime = addHoldDownTime
                 + sigExpirationTimeRemaining
                 + MAX(1 hour,
                       MIN(sigExpirationTime / 2,
                           MAX(TTL of K_old DNSKEY RRSet) / 2,
                           15 days)
                       )
                 + 2 * activeRefresh
                 + retrySafetyMargin

So your desired equation is there.

(the current published document doesn't have the 2*, even though the
previous non-expanded version should have lead to it).

I'll do a final check of equations again today, as well as look to make
sure I didn't state drift can only happen for one query (though I'm sure
I didn't say that).
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 20 Dec 2017 10:21:49 -0800

> But 6.2.1.1 *will* state:

Whoops, I got the section number wrong for the equation you wanted.

It's 6.2.2 and it *will* state:

   addWallClockTime = lastSigExpirationTime
                      + addHoldDownTime
                      + 2 * MAX(1 hour,
                                MIN(sigExpirationTime / 2,
                                    MAX(TTL of K_old DNSKEY RRSet) / 2,
                                    15 days)
                                )
                      + retrySafetyMargin

Which is exactly what you wanted.
-- 
Wes Hardaker
USC/ISI

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 Dec 2017 13:27:12 -0500

> sure I state that in the document.

Take it out of any formula.  It has little impact outside of the 
addHoldDown interval and in there all it does is shift the end point.  
It's OK to mention it as part of the general slop, but in reality it 
turns out to have only very minor impacts.

> Anyway, I agree only the last one should be shifted in the correct case.

That's not what I said.  What I said was that the cumulative effect of 
drift within the add hold down interval is to shift the phase of the 
last query before the end of the period.  The intermediate queries also 
shift phase, but are subsumed in analysis by the cumulative shift within 
the interval.

> end up needing the extra queryInterval.

No.  Drift per query is ~<= 10 seconds or so.   queryInterval ~>= 
hours.    Drift for these two queries can safely be ignored in the 
evaluation.

> I'm glad you caught yet another needed length extension during last

I'm glad you got here, but if you were showing your work, you would not 
be getting a good grade.....  sorry.

The activeRefresh before the addHoldDown interval is from the worst-case 
assumption that at least one out of N resolvers will have made a query 
just before the lastSigExpire date.
The activeRefresh after the addHoldDown interval is from the worst-case 
assumption that at least one out of N resolvers will have made a query 
just before ITS addHoldDown expired and will have to wait an entire 
activeRefresh interval

These assumptions are made without reference to any assumptions about 
drift or retransmissions.

> trying to trick you.

I'm sorry if you thought my words implied I thought you were trying to 
trick me.  However, given that you had no real reason for setting 
driftOffset to activeRefresh it really did look like "and then a miracle 
occurs" type of logic.

> Again, Mike, I can't state this more clearly: I

Wes - I just want to not have "fake math" in this document.

timingSafetyMargin depends on driftSafetyMargin.

driftSafetyMargin seems to have been pulled out of thin air and has no 
support which means that timingSafetyMargin also makes no sense.

Neither of these terms are of any use in either the equations or analysis.

Delete them and refactor any text that references them.

> sure I didn't state drift can only happen for one query (though I'm sure

*sigh* As currently written you get the second activeRefresh from the 
random setting of driftSafetyOffset (see 6.1.7) via timingSafetyMargin 
(6.1.8). That's wrong.     Since 6.2.1 uses timingSafetyMargin - its 
also wrong.  Since the rest of the equations derive from 6.2.1 they are 
suspect.

Delete these (6.1.7) (6.1.8) section and fix any references to these 
terms in the base equation.  From there fix the rest of the math.

Later, Mike