Subject: [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations

From: tjw ietf <[email-masked]>
Date: Wed, 18 Oct 2017 07:16:56 -0400

>From talking with the authors and reading all the comments on the mailing
lists, it appears that all outstanding issues have been addressed.

This starts a Working Group Last Call for:
draft-ietf-dnsop-rfc5011-security-considerations

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/

Please review the draft and offer relevant comments. Also, if someone feels
the document is *not* ready for publication, please speak out with your
reasons.

This starts a two week Working Group Last Call process, and ends on  1
November 2017

thanks
tim

---

From: Michael StJohns <[email-masked]>
Date: Wed, 18 Oct 2017 09:13:42 -0400

On 10/18/2017 7:16 AM, tjw ietf wrote:
>
> From talking with the authors and reading all the comments on the 
> mailing lists, it appears that all outstanding issues have been addressed.

Nice try - but no.  I got Wes' responses yesterday and haven't yet 
re-read the document (which was published today with the changes). Given 
the responses I'm pretty sure we've still got problems.  So... NO.

Mike

> Please review the draft and offer relevant comments. Also, if someone 
> feels the document is *not* ready for publication, please speak out 
> with your reasons.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Fri, 20 Oct 2017 16:39:52 +0000

On 10/18/17, 04:17, "DNSOP on behalf of tjw ietf" <[email-masked] on behalf of [email-masked]> wrote:

>This starts a Working Group Last Call for: draft-ietf-dnsop-rfc5011-security-considerations

I outright oppose publishing this document.

One, the audience of this document (namely the targetted operators) has not participated in the review of the document.  I should perhaps add "sufficiently" as I have made comments and my personal observation is that the document isn't all that helpful. No other operator, so far as I know (big caveat), has commented.

Two, the document perpetuates the mis-use the term "trust anchor".  To point to a specific place in the document:

## 3.  Terminology
##
##    Trust Anchor Publisher  The entity responsible for publishing a
##       DNSKEY that can be used as a trust anchor.

That is not a term I'd define.  Trust is gained, not read.  One cannot
"push" trust via publishing something.  What is published are secure
entry point keys:

>From "DNSSEC Resource Records", section "The Flags Field":

"Bit 15 of the Flags field is the Secure Entry Point flag, described
in [RFC3757]"

Note that it is not the "Trust Anchor flag."  I don't think that the working group should progress documents that lead to terminology confusion.

Three, the document beings to co-mingle validation with trust anchor management, which are two different concepts:

##    RFC5011 Validating Resolver  A DNSSEC Validating Resolver that is
##       using the RFC5011 processes to track and update trust anchors.
##       Sometimes referred to as a "RFC5011 Resolver"

Automated Updates is not part of the validation process, it is a part
of the trust anchor management function.  Whether the set of trust anchors
are managed in accordance to Automated Updates or not, the validation process
is the same.

Four...well, as I said, it's hard to justify spending time on a document that has a low ROI.  The equation for timing, which is the highlight of the document, is too complicated and includes an unsupported "safety margin."  The latter element throws out the window any reason to be so precise up to that point.

I appreciate the document's desire.  But it would be better written if it came from operator experience in implementing a key management scheme that is compatible with what is described in the Automated Updates of DNSSEC Trust Anchors document.  And it would be less harmful if the terminology stuck to the language used in developing the protocol, as opposed to the colloquial use that has emerged.  (Such as the notion that trust anchors "are published".)

The reason I'm opposing going forward without providing new text is that I don't feel that I can give new text until completing a process designed to be compatible with "Automated Updates".  I could envision a "Recommended Management of Secure Entry Points for Compatibility with Automated Updates" coming in the future, but not yet.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 25 Oct 2017 13:16:02 -0700

> draft-ietf-dnsop-rfc5011-security-considerations

I support the publication of 
draft-ietf-dnsop-rfc5011-security-considerations either as-is or with an 
additional section on looking at timing from a second perspective (as 
detailed by Mike StJohns).

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Thu, 26 Oct 2017 11:11:35 -0400

> detailed by Mike StJohns).

Thank you, Paul.

Dear WG - I know that this document has a limited audience, is kind of
an annoying read, and is filled with maths (gasp!).
Wes and I do believe that this is an important document - getting
these timers wrong potentially has really bad security implications;
there was intended to be a companion document to RFC5011, but seeing
as that wasn't created, I think it is really importantt that we
address this.

So, pretty please, review this document and send feedback. We've tried
hard to make it readable, but the topic is unfortunately complex and
can only be simplified so far - it is also really hard to talk about
sliding windows of time.

So, again, please review and comment,
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Michael StJohns <[email-masked]>
Date: Thu, 26 Oct 2017 13:42:42 -0400

> can only be simplified so far - it is also really hard to talk about

*sigh*

It's really not complex and its neither a timer nor an interval nor a 
window - but a fixed point in time given the input data:

    earliest date when its safe to revoke ALL old trust anchor keys ::=
    latest expiration date of any RRSet containing the key(s) to be
    revoked + queryInterval (from 5011) + holdDownTime (from 5011) +
    queryInterval (from 5011)

    earliest date when the zone owner thinks its safe to revoke all the
    old keys ::= the above + safetyFactor

The first query time is the maximum time it takes for all resolvers to 
make their first query (assuming no retries).  The second query time is 
the time for all resolvers to make the "next query after the hold down 
time expires" (again assuming no retries).

The safety factor is there primarily to deal with network outages AT THE 
RESOLVER and is a SWAG that should represent a value that captures the 
answer to the question "given the retry interval and a 99% network 
uptime and N resolvers, how long until 99.99% of the resolvers have 
completed all necessary retries at both the beginning and the end of the 
process?"  Like most retry questions, this has a bi-modal answer - given 
a reliable network, the vast majority of resolvers will be successful in 
small multiples of the retry interval.   A very tiny few will not be 
successful even after 100s of retries.  The SWAG should pick a number of 
retries that balances the operational need to complete the process with 
the possibility of a few resolvers not getting the word.

so:  safetyFactor ::= retryInterval (from 5011) * (5 + func(N)) - 5 is a 
SWAG to set a minimum for even a small group of resolvers.

I was thinking Log2(N) - which would give 23 for 10 million resolvers or 
28*retryInterval.   Or something suitably non-linear....

Note that "latest expiration date of any RRSet containing the key(s) to 
be revoked" makes a worst case assumption:  that the pre-signed RRSets 
are not necessarily protected from disclosure.    If this is not true, 
then this reduces down to "the latest expiration date of any RRSet 
containing the keys to be revoked that has been seen publicly".  The 
document SHOULD assume that any signed RRSet may be available to an 
attacker whether it's been published in the DNS or not.

5011 was a timer based document because it applied to each resolver in 
each resolver's time domain.  When a timer fired on resolver A, it had 
no impact on the behavior of resolver B nor on the DNS server that was 
being queried.

With this document, the 5011 timer intervals are useful only to figure 
out an earliest possible safe date given the previous live data set.  
When that  (those) data set become irrelevant for the purposes of Wes' 
attack is pretty straight forward: when it expires!   The 5011 intervals 
can be used to calculate forward from that DATE and TIME to get an idea 
of when most well-behaving resolvers will have accepted new trust 
anchors even if they were being attacked.  Note "most".  There is no 
guarantee that even if you waited 6 years that all resolvers would get 
the new trust anchors and you just need to accept that the fall back is 
for the resolver owner to fix the problem when it occurs.

This discussion has been helpful because it forced me to consider two 
things the root does that I never contemplated in 5011:  1) A steady 
state of a single trust anchor and 2) pre-signing RRSets. Neither of 
these affects the resolver implementation, but both make the 
publishing/signing schedules more security sensitive - hence this document.

Later, Mike