Subject: [DNSOP] requesting WGLC for 5011-security-considerations

From: Wes Hardaker <[email-masked]>
Date: Wed, 05 Jul 2017 10:11:08 -0700

Folks,

We believe that the latest draft-rfc5011-security-considerations
document is ready for WGLC, and would like the chairs to start that
process unless anyone thinks it's not ready to go forward.  In
particular, we believe all outstanding issues with it have been
resolved.

Objections?

-- 
Wes Hardaker
USC/ISI

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 05 Jul 2017 10:23:01 -0700

> particular, we believe all outstanding issues with it have been

Just a note that the actual filename for the draft is 
draft-ietf-dnsop-rfc5011-security-considerations, and it can be found at 
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/>

---

From: Michael StJohns <[email-masked]>
Date: Wed, 05 Jul 2017 17:54:50 +0000

Could you hold off on this for another week? The revised version dropped
last week and I've been on travel and enjoying the holiday and haven't had
a chance to review the changes.   Thanks - Mike

On Wed, Jul 5, 2017 at 13:11 Wes Hardaker <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 05 Jul 2017 15:21:19 -0700

"Paul Hoffman" <[email-masked]> writes:

> draft-ietf-dnsop-rfc5011-security-considerations, and it can be found

Whoops; thanks Paul.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 05 Jul 2017 15:22:29 -0700

Michael StJohns <[email-masked]> writes:

> Could you hold off on this for another week? The revised version
> dropped last week and I've been on travel and enjoying the holiday and
> haven't had a chance to review the changes.   Thanks - Mike

FYI, the changes are very small:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-rfc5011-security-considerations-01&url2=draft-ietf-dnsop-rfc5011-security-considerations-02

-- 
Wes Hardaker
USC/ISI

---

From: Michael StJohns <[email-masked]>
Date: Wed, 05 Jul 2017 22:33:09 +0000

That's not actually a plus you understand.   Mike

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 05 Jul 2017 17:11:21 -0700

> That's not actually a plus you understand.   Mike

Sure it is.  We're down to the point where large changes aren't needed :-P
-- 
Wes Hardaker
USC/ISI

---

From: Michael StJohns <[email-masked]>
Date: Thu, 6 Jul 2017 13:33:18 -0400

> Sure it is.  We're down to the point where large changes aren't needed :-P

I'm sure you think that... but the small changes you've made to address 
some of my comments haven't gone far enough.  There's also a need for a 
grammar and syntax pass on the document.

Here's what I've got so far (in document order rather than order of 
importance):

1) Use "exclusively" rather than "only" where you can - "only" has some 
issues with misunderstanding.  E.g. in the abstract you have "only 
recently" which can be interpreted applying to "recently" rather than 
meaning "exclusively" with " recently added DNSKEYs"

Instead in the abstract:  "... before exclusively signing with recently 
added DNSKEYs"

2) In the introduction  - "validators can update" vs "validators can 
extend".

3) In the introduction - same issue with "only recently"

4) In the introduction - "ceasing publication of a revoked key" vs 
"removing a key from a zone"

5) Section 1.1 - What is the definition of "rolled"?   Your use of it 
doesn't match 5011s and it's not defined either here or in 4033 or .   
Also "before signing a zone" - I don't think this is exactly what you 
asked them and the summary is probably inaccurate.

6) Section 2 "which apply to" vs "as required from".

7) Section 2 "Note that it does not..." - which "it" are you talking about?

8) Section 2 "using only recently" - same issue as above.

9) Section 2. New para at "Failure of a DNSKEY..."

10) Section 2. "... leaving that key in their trust anchor storage 
beyond the key's expected lifetime." vs "... leaving a key in their 
trust anchor storage beyond their expected lifetime" -"their" applies to 
two different things

11) Section 3: Attacker.  "An entity intent..." vs "An attacker 
intent..." - self referencing definition problem

12) Section 4.1:  This doesn't actually describe what's in 5011 - 
specifically bullet 3 was modified to clarify your concerns, but isn't 
what was in 5011.  You need to have both here.

13) Section 4.1, bullet 3:  Same problem with "only".  Instead "Begin to 
exclusively use recently published DNSKEYs..."

14) Section 4.2 last para:  This is only an attack if the private key is 
compromised.  In which case, with only a steady state of a single key, 
you've got lots of other problems.  Basically, in your one in one out 
with a steady state of one model, once the current private key is 
compromised you have no ability to fix the problem.    But getting the 
numbers for figuring out when this change becomes "sticky" correct is 
useful.

15) Section 6 - general comment.   You're doing interval calculations 
and you want to do date/time wall clock calculations instead.   While 
the 5011 values are based on intervals from the RRs get to the 
validator, the publisher has to be looking at absolute times first (e.g. 
signature inception and expiration, original TTL) and then deltas from 
those. [Note, this is NOT a new comment - I've made it previously and 
strongly]

16) Section 5.1.1 - You're missing a *very* important point here - that 
DNSKEY RRSets may be signed ahead of their use.  You need to assume that 
once signed, they are available to be published - even by an attacker.  
So wherever you have "signature lifetime" you want something like 
"latest signature expiration of any DNSKEY RRSet not containing the new 
key" or at least you want to calculate the date/time value based on that.

17) Section 5.1.1 doesn't actually apply if you use the 5011 rollover 
approach (section 6.3).   E.g. K_old (and any RRSets it signed) will be 
revoked the first time K_new is seen and K_standby is the signing key.  
At this point this reduces to a normal denial of service attack (where 
you prevent new data from being retrieved by the resolver).  You'd need 
a different section to do that analysis. [And thinking about it, why is 
there any practical difference between this attack and a normal denial 
of service attack in the first place?]

18) Section 5.1.1, T+35:  "since the hold down time of 30 days + 1/2 the 
signature validity... " - Two items:  Wordsmithing:  The hold down time 
is just the 30 days, not the plus 1/2...  which I *think* given the 
reference to 2.3 is actually the queryInterval. clarify please.  And 
queryInterval is not actually 1/2 the signature validity - its the MIN 
(15 days, 10 days (sig life)/2 and 1 day(orig ttl)/2) or  1/2 a day.

19) Section 6 - the formulas are wrong.  I also  don't understand where 
you got MAX(originalTTL/2,15 days) - there's no support for this in the 
text.

The final formula should be:

EarliestDateWhereAttackFails::=  latest SignatureExpiration of any 
DNSKEY RRSet not containing the new key

waitExpirationDate =  EarliestDateWhereAttackFails + 2*queryInterval 
(from RFC5011 section 2.3) + holdDownTime + slop (let's call this twice 
the query interval or some other number - its really there just to deal 
with an attacker preventing the last RR_New from being delivered)

In the given example, assuming a 5/1/2017 00:00UTC inception date for 
the RR_Old, an 5/1/2017/00:01UTC inception date for the RR_new, a 
consistent 10 day signature validity and a 1day original TTL.

EarliestDateWhereAttackFails == 5/11/2017 00:01UTC

queryInterval = 1/2 day

waitExpirationDate = EarliestDateWhereAttackFails + 30 + 2 or 6/12/2017 
00:01UTC - 42 days after the last old RRSet was signed and 32 days after 
the last possible expiration date of an RRSet without the new key.

So assume you sign both the new and old RRSigs with one seconds 
difference with identical parameters:

At T=0 a publisher sends RR_new

At query interval, and until EarliestDateWhereAttackFails and attacker 
somehow manages to intercept RR_new and substitute RR_Old - alternately, 
the attacker can let RR_new through until the next step - probably the 
more reasonable approach.

At T=EarliestDateWhereAttackFails-1second attacker intercepts RR_new and 
sends its last valid RR_old

At T=EarliestDate+queryInterval resolver receives another RR_new and 
starts the hold down

 From T=EarliestDate+queryInterval until 
T=EarliestDate+queryInterval+holdDownTime every queryInterval the 
resolver gets another copy of RR_new

At T=EarliestDate+queryInterval+holdDownTime+queryInterval resolver gets 
the final copy of RR_New it needs to trigger the installation of the new 
trust anchor

An attacker can prevent or delay the installation of the trust anchor by 
preventing delivery of RR_New (or subsequent RR with the new key), but 
that's sort of the definition of a Denial of Service attack and really 
no worse than keeping say "A" records from the resolver.

In any event, the point needs to be made that this attack - while real - 
is a "retail" attack that would be difficult to prosecute by a single 
attacker across a broad range of end-entities.  This goes to the general 
model that no publisher of DNS data knows each and every consumer of 
that data, nor can wait its publication on every consumer getting 
published data.  The data protocol for DNS is unidirectional and the 
update protocol in 5011 was designed with that in mind.

20) The value in 6 regardless of what it is is the wrong value for 
revocation.   revocationPublicationWaitTime is basically 
EarliestDateAttackFails + queryInterval + slop.   Revocations take place 
immediately. You can delay them only as long as you have old valid 
signed RRSets.

So - not ready for last call.

Mike

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 06 Jul 2017 10:40:40 -0700

Michael StJohns <[email-masked]> writes:

> I'm sure you think that... but the small changes you've made to
> address some of my comments haven't gone far enough.  There's also a
> need for a grammar and syntax pass on the document.

Thanks for the review and suggested text (the previous messages you sent
didn't provide as many concrete fixes, so we can now incorporate you
exact issues now that they're more directed).  We'll try to put together
an update to address the issues you've pointed out shortly (which really
can't happen till Monday of IETF since we're after cut-off).
-- 
Wes Hardaker
USC/ISI

---

From: Michael StJohns <[email-masked]>
Date: Thu, 6 Jul 2017 13:42:57 -0400

> can't happen till Monday of IETF since we're after cut-off).

I didn't provide concrete fixes because the general model was missing 
the point and the re-write could have been substantial. Now we're 
finally on the same page that this only applies to "exclusively signing 
with the new keys" we can make progress.  It wasn't until this last 
version that you'd adopted those changes.

Later, mike

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 06 Jul 2017 11:53:47 -0700

Michael StJohns <[email-masked]> writes:

> finally on the same page that this only applies to "exclusively
> signing with the new keys" we can make progress.  It wasn't until this
> last version that you'd adopted those changes.

We disagreed about the proper way to word it.  We always agreed on the
idea.  It's good to clarify it more completely to ensure everyone else
reads that intent though.
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 12 Jul 2017 10:35:28 -0700

Mike,

> The value in 6 regardless of what it is is the wrong value for
> EarliestDateAttackFails + queryInterval + slop.  Revocations take
> place immediately. You can delay them only as long as you have old
> valid signed RRSets.

So in short, the advice in 5011 section 6.6 step 3:

   3.  After 30 days, stop publishing the old, revoked keys and remove
       any corresponding DS records in the parent.

Has nothing to do with a needed wait time (because keys are revoked
immediately) but rather the above 30 days is really just a suggested
time for operational practice?

In 2.4.2 you have:

   The remove hold-down time is 30 days.  This parameter is solely a key
   management database bookeeping parameter.  Failure to remove
   information about the state of defunct keys from the database will
   not adversely impact the security of this protocol, but may end up
   with a database cluttered with obsolete key information.

Which seems to back this up (though I'm not convinced that there is no
security ramifications of having old trust anchors around; else why
delete them?)

So in the 5011-security-considerations draft, I agree with your point
that the right amount of time to wait should be changed to replayTime +
queryInterval + slop.  Thanks for pointing that out.  (though it's worth
noting that replayTime + queryInterval can be longer than 30 days).

-- 
Wes Hardaker
USC/ISI

---

From: Michael StJohns <[email-masked]>
Date: Sun, 16 Jul 2017 05:21:51 -0400

> time for operational practice?

In your "prevent the add of a new trust anchor" attack, you only need to 
intercept one query/response pair over a period of queryInterval + 
EarliestDateAttackFails.  In the "prevent revocation" attack, you need 
to intercept ALL query/response pairs for at least 30 days (in the 
example - that's 60 Q/Rs) - quite a bit harder and pretty much 
impossible to do widespread.    Also, 6.6 talks about deletion of a 
subordinate trust point by revoking all the trust anchors - depending on 
the behavior of the resolver (which I had many arguments about with 
various vendors), trust will generally be traced through the new DS 
record(s) with the absence of the old trust anchor key  in the DNSKEY 
RRSet so the presence (or absence) of the "revoked" key in the 
resolver's trust anchor set is mostly a non-issue once the DS is published.

Given that I can think of only a few possible subordinate trust points 
and none of them will probably ever be deleted, I probably wouldn't 
change this guidance.    If we were going to change the guidance, it 
wouldn't be as simple as the publish new trust anchor model - you would 
need to consider the expiration of the Parent DS (if any) as well as 
expiration of the child DNSKEY RRSet in picking a new value.

> security ramifications of having old trust anchors around; else why

Nope - two different parameters with the same value.  The first was a 
publication guidance, the above was simple database management guidance 
for the resolver.

> noting that replayTime + queryInterval can be longer than 30 days).
If you mean that replayTime ~= last validity date/time of the old DNSKey 
RRSet with the to be removed keys - then yes.  But please be clear and 
precise in how you define this term in the document.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 19 Jul 2017 04:42:53 -0400

On date time vs intervals - I finally realized why Wes and I are 
somewhat disconnected on this.

5011 was written as the protocol for the resolver and is totally 
interval driven.   (E.g. query and retry timers are set and fire based 
on when the resolver performs an action).

This document is being written for the zone publishers, and the process 
of publication is task driven and has humans as protocol element 
timers.  The actual publication of a DNSSEC RRSIG is divorced from both 
the date/time of creation and the RRSig's actual inception and 
expiration dates.  While there is a defined interval between inception 
and expiration, expiration occurs at a fixed point in time and that 
point in time is independent from the interval between publication and 
receipt by the client.

In other words - the correct (or at least better and less subject to 
being misunderstood) way of describing the various points in time the 
publisher should do something is by referencing the fixed point in time 
(expiration) where both publisher and client agree that something 
happens and then figuring other fixed points in time from that point.   
Or to restate it again - "A publisher must wait until June 5th 2010" 
will always evaluate to the same date and time regardless of who 
calculates it and when they calculate it; "A publisher must wait 30 
days" will not.

So :
"
publicationAddWaitInterval :: = MAX (30 Days, originalTTL of NEW DNSKEY 
RRSet) + MAX ( all calculated queryIntervals for OLD and new RRSets)  + 
addSlopInterval
queryInterval ::= MAX (1 hour, MIN (
                                                 15 days,
                                                .5 * expirationInterval 
DNSKey RRSet,
                                                .5 * originalTTL DNSKey 
RRSet)
                                           )

expirationInterval :: = expirationDate - inceptionDate
addSlopInterval ::= 2 * MAX(originalTTL of any  DNSKEY RRSet valid 
during the transition process)

The publicationAddWaitDateTime  is the date and time on which the 
publisher can assume that most of the 5011 capable resolvers have 
accomplished the addition of the new trust anchor to their trust anchor 
sets.  That date is the addHoldDownTimeInterval AFTER the latest in time 
signature expiration date of any RRSet without the new key.  This 
includes both published and unpublished RRSets. Publishers should 
refrain from creating or publishing DNSKEY RRSets signed exclusively by 
a new key until after this date. Specifically, the inception date of 
such an RRSig should be later than the publicationAddWaitDateTime"

The addHoldDownTimeInterval above differs from what is in 5.1 section 
2.4.1 in that this is the publishers view of when the new trust anchor 
is accepted by the resolver which may differ from a specific resolvers 
view (due to when things are actually sent and received).  Section 2.4.1 
has to be combined with the text in section 2.2 which states that the 
key isn't added until after the next time it is seen after the 
expiration of the add hold down. Also, the queryInterval term of this 
calculation should be the maximum of any DNSKEY RRSet seen during the 
transition - it's possible that the publisher may reduce the intervals 
or increase the intervals between RRSets and this provides the publisher 
with the worst case value that any given resolver should be using.

Let's not confuse resolver numbers with publisher numbers and spend a 
bit of time to get the language clear correct and implementable.

Mike

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 20 Jul 2017 14:34:56 +0200

Wes,

It's been a while since I have had a look at this draft, my apologies.

I don't think it is ready for WGLC because I am not convinced the math
is correct. Section 6 defines the waitTime:

     waitTime = addHoldDownTime
                + (DNSKEY RRSIG Signature Validity)
                + MAX(MIN((DNSKEY RRSIG Signature Validity) / 2,
                          MAX(original TTL of K_old DNSKEY RRSet) / 2,
                          15 days),
                      1 hour)
                + 2 * MAX(TTL of all records)

Which is the same as:

     waitTime = addHoldDownTime
                + (DNSKEY RRSIG Signature Validity)
                + queryInterval
                + 2 * MAX(TTL of all records)

but reads better.

This should be the same as Itrp as defined in RFC 7583:

      Itrp >= queryInterval + AddHoldDownTime + queryInterval

Basically these two differ at the following points:

1. Itrp does not include (DNSKEY RRSIG Signature Validity). It does
mention that the validator should not see a validly signed DNSKEY RRset
without the new key in that period. So adding (DNSKEY RRSIG Signature
Validity) is a good update.

2. waitTime only adds one queryInterval, while Itrp adds two. I believe
to be safe on the publishing side, two queryIntervals is needed. RFC
7583 explains:

   A validator will treat it as a trust anchor the next
   time it retrieves the RRset, a process that can take up to another
   queryInterval (the third term).

3. waitTime adds two MAX(TTL of all records) (margin). The draft says
that it probably not needed, and I agree, and that explains why it is
missing from the Itrp definition.

4. Both definitions (Itrp and waitTime) don't really take into
consideration the retryTime defined in RFC 5011. Perhaps that can be
used for defining the extra safety margin.

5. Itrp actually is defined with a modifiedQueryInterval which excludes
the RRSIG expiration interval. Now this is recognized to be the time
between inception and expiration of the RRSIG, I actually think it does
not need to be removed from the equation. So Itrp could have worked with
just queryInterval.

Given these points I think the correct definition of waitTime is:

     margin = 2 * MAX(TTL)

     waitTime = addHoldDownTime
                + signatureValidity(DNSKEY)
                + 2 * queryInterval
                + margin

I think slop needs to be separated and it should be documented that this
is a suggested value for the slop.

Furthermore, this document should also give guidance on the wait time
before a revoked DNSKEY can be removed from the zone:

     waitRemoveTime = signatureValidity(DNSKEY)
                + queryInterval
                + margin

This document should probably update RFC 7583 because it is giving a
better definition of Itrp and Irev.

For readability of the document I would like to suggest to move the
Attack example and breakdown to the Appendix.

Kind regards,
  Matthijs