Subject: Re: [DNSOP] Responding to MSJ review of the previous rfc5011-security-considerations

From: Wes Hardaker <[email-masked]>
Date: Mon, 16 Oct 2017 14:34:59 -0700

Mike,

Here's some responses to your comments from last time out.  I'm
only including the ones that needed a response or had an actionable
item.

1.12 FIXED 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.

  + Result: Intro paragraph added to note we're paraphrasing 5011 at a
    very high level only.

  + MSJ responds:

    Nope - not fixed.  You have "This document discusses the following
    scenario, which is one of many possible combinations of operations
    defined in Section 6 of RFC5011:" followed by "3. Begin to
    exclusively use recently published DNSKEYs to sign the appropriate
    resource records."

    5011 does not define this as a possible operation.

    Instead: "This document discusses the following scenario which is a
    combination of the operations of sections 6.1 and 6.2 but ignores
    the guidance of the first paragraph of section 6 which recommends at
    least two keys per trust point at all times."

  + Result: changed the sentence in question to:

    This document discusses the following scenario, which the principle
    way RFC5011 is currently being used (even though Section 6 of
    RFC5011 suggests having a stand-by key available)

1.16 FIXED2 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.

  + Result: There are two issues here:
    1. When we discuss the exact requirements for publication, we should
       be very very clear about the timing requirements.  I agree.
    2. We're trying to pass on the concept of the attack in this
       section, not necessarily a description that exactly covers all
       possibilities.  So, though I'm all for making it as accurate as
       we can, I don't think we should make the example text so
       confusing to cover all the corner cases that no one can follow
       it.
    3. It doesn't benefit an attacker to publish the signatures ahead of
       time. So you're right that anyone can publish new signatures, it
       really doesn't affect the timing required by the publisher to
       wait, which is the point of this draft.
    4. The important take away I take from your text is that any delay
       between signing and publication will affect the length of time to
       wait, and I'm sure this is what you mean by needing to calculate
       via wall-clock (since everything should be based on
       sigexpiration).

  With this goal in mind, I've cleaned up the text a bit to make it
  a bit more clear.

  + MSJ Responds about point 3:

    The attacker doesn't publish the signatures - the publisher has
    signatures it won't be using....    the publisher signs stuff way in
    advance of publication because getting people together and getting
    the HSM unlocked to sign things is a big huge expensive
    production. If the publisher doesn't think to modify its signing
    schedule in advance of a 5011 action, then your interval
    calculations are less then useless.

  + Fair point, thanks for clarifying.  I've added the following text to
    5.1.1:

    Note that for simplicity we assume the signer is not pre-signing and
    creating "valid in the future" signature sets that may be stolen and
    replayed even later.

    I've also changed the terminology of sigExpirationTime:

    sigExpirationTime: The amount of time remaining before any existing
    RRSIG's Signature Expiration time is reached.  Note that for
    organizations pre-creating signatures this time may be fairly
    lengthy unless they can be significantly assured their signatures
    can not be replayed at a later date.  sigExpirationTime will
    fundamentally be the RRSIG's Signature Expiration time minus the
    RRSIG's Signature Inception time when the signature is created.

1.17 NOTHINGTODO 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?]

  + Result: As we've both agreed in the past, the attack described in
    our 5.1.1 section only applies when you sign exclusively with a key
    that is too new.  So, yes when you are using K_standby, the attack
    in question doesn't work.  We're only describing the case where
    there either isn't a K_standby, or when K_standby is also newer than
    our 'waitTime' time.

  + And, yes by preventing a new key from being accepted as a trust
    anchor, this is a denial of service attack.  Though one with
    potentially serious ramifications since it may require manual
    intervention on all the devices affected by it (unlikely a
    network-based DDoS attack, it doesn't stop when the attacker stops
    sending packets; this is long lived until the configuration is
    manually fixed).

  + MSJ responds:

    Section 5.1.1 does not apply to preventing a resolver from seeing a
    revocation.  The calculations are different.   You could add a new
    section describing the revocation attack, but I think all you need
    to do is note that at the beginning of 5.1.1 and point to section
    6.2 as the mitigation math.

  + Result: 5.1.1 does not now say that it applies to revocation and
    specifically discusses "The timing schedule listed below is based on
    a Trust Anchor Publisher publishing a new Key Signing Key (KSK),
    with the intent that it will later become a trust anchor."

1.19 FIXED 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.

  You're misreading the commas.  One of the terms in the outer max
  clause is "MAX(original TTL of K_old DNSKEY RRSet) / 2".  This is
  slightly different than what is in the "1/2*OrigTTL" clause in 5011
  itself.  This is because if the publisher changes TTLs over the course
  of signing, you have to take the maximum value of any of them, not
  just the most recent.  (though, to be super-accurate you need to do
  some math which we might want to describe about when a given TTL is
  published vs when Knew is introduced).

  Anyway, in the end, the formula in ours draft directly derives from
  what is in yours.  We do take into account the possibility of multiple
  TTLs for a given signature set, which 5011 doesn't take into account
  (and to some extent, it's less important, but only further shows how
  much variance a resolver might have before accepting a new trust
  anchor).

  A clear piece of advice for an eventual BCP would be to not change
  TTLs at the same time you start any 5011 publication or revocation
  process.

  + MSJ responds:

  Note that in 6.1 you have 5 terms, but in the fully expanded equation
  in 6.1.6 you have 4.  You're missing the safetyMargin which you didn't
  actually define completely in section 6.1.5.

  + Result: I think you mean activeRefreshOffset, as safetyMargin was defined
    (though we had to change it again due to the possibility of
    extremely short TTLs).  But I have added the expansion of
    activeRefreshOffset to the equation; thanks for catching that.  I
    haven't changed the definition since I don't see any missing pieces
    to it (or to the safetyMargin definition).

-- 
Wes Hardaker
USC/ISI

---

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

Top posting because of the "last call" note.

Still not ready.

You said in 4.1:

  which the principle

And then in  T-1 you say:

But - "the way RFC5011 is currently being used" is with "pre-signing" 
and "valid in the future" signature sets.   So you want to have your 
cake and eat it too.     You're now both not dealing with the way 5011 
said you should do things nor are you dealing with the way that the root 
actually does things.

All of this can be fixed by going to a wall clock model which is the way 
the publisher works vs the interval model which is only appropriate for 
the client.

You continue to have a problem with "sigExpirationTime".
> The amount of time remaining before any existing
>        can not be replayed at a later date.

the problem is:  Amount of time measured from when?     (and it should 
be "latest RRSIG's Signature Expiration time is reached" at least.

> sigExpirationTime will
This is no longer fundamentally the difference between one RRSig 
inception and expiration time.  You can't even describe it as the 
difference between the earliest inception and latest expiration because 
that changes as the earlier RRSigs expire.   The only fixed value (and 
easiest value) is "latest expiration date". You could say "latest 
expiration date - now" which then gets added to "now" to get back to 
lastest expiration date.....

Please, please please just move to a wall clock value based on the 
latest expiration date plus appropriate intervals.  All the minor 
twiddles you've done to try to avoid doing this have made the document 
less clear.

NOT READY FOR LAST CALL.

More below.

> 1.12 FIXED Section 4.1:  This doesn't actually describe what's in 5011 -

OK.  Not perfect but works.
> 1.16 FIXED2 Section 5.1.1 - You're missing a *very* important point here -

No.  You floated this document as being an attack on 5011 updates. Your 
comments have been that we should concentrate on how 5011 is actually 
used by the root.  So then you need to have an example that actually 
meshes with how the root does things.  The root presigns data.  The 
example should deal with that.

>      RRSIG's Signature Inception time when the signature is created.

See my top posting.
> 1.17 NOTHINGTODO Section 5.1.1 doesn't actually apply if you use the 5011 rollover
OK
> 1.19 FIXED Section 6 - the formulas are wrong.  I also  don't understand
You've got a new term "(addHoldDownTime % activeRefresh)"  that you 
don't appear to have text to cover the "why".   It's not "safetyMargin" 
as you expanded the last term to match that definition.  Is that 
activeRefreshOffset?   Doesn't match the text at the beginning of 6.1.6 
so I'm confused.

Mike

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 18 Oct 2017 14:21:34 -0700

>     said you should do things nor are you dealing with the way that the
>     root actually does things.
>
>     All of this can be fixed by going to a wall clock model which is the
>     way the publisher works vs the interval model which is only
>     appropriate for the client.
>
I understand that's how you'd structure the document.  For me,
I believe it's easier for people to understand the problem as
structured.  The example walk-through is designed to be simple
for learning about the issue, which is already complex enough.
This topic was brought up on the list before and in Chicago and
the consent was to leave it as is, though there wasn't a huge
number of voiced opinions.  We designed the document to come at
the topic for human understanding, and I believe most people
think about the problem as a delta from the time they sign and
publish the zone.  I believe that coders will implement it
according to how they need to given their software.

If you feel strongly about this, please encourage others to
chime with requests for change too in order to shift consensus.
At this time we don't plan to change the document to reflect
your preferred style.

>    difference between the earliest inception and latest expiration
>    because that changes as the earlier RRSigs expire.   The only fixed
>    value (and easiest value) is "latest expiration date". You could say
>    "latest expiration date - now" which then gets added to "now" to get
>    back to lastest expiration date.....
>

I've changed the wording to your "latest...".  Thank you for the
concrete suggestion.  As to "when" it amounts to the current
value time(), which is indicated by the "The amount of time
remaining...".  Again, this is written from the point of view of
a human wanting to calculate how long the need to continue waiting. 

-- 
Wes Hardaker
USC/ISI

---

From: Michael StJohns <[email-masked]>
Date: Thu, 19 Oct 2017 09:25:45 -0400

On 10/18/2017 5:21 PM, Wes Hardaker wrote:
> structured.

This is unfortunately a deflection.  The document is still being 
two-faced in that it is claiming to address "the way RFC5011 is 
currently being used" but ignoring the "pre-signing" and "valid in the 
future" signature sets in its discussion of the issue AND the solution.

With respect to below, I believe that "most people" (who are doing 5011 
in the way you've described) would want the answer to the question: 
"When is it safe for me to revoke all of the older trust anchor 
keys?".   When they discuss it with "other people" they will use a fixed 
date not "5 days from when I did the calculation which was 2 days ago so 
three days from now".

This isn't about a structuring preference, it's about having 10 people 
doing the math at different times and having 100s others get the same 
understanding of the answer when the first 10 discuss it.

Even the Root 5011 folks discuss their timings in terms of actual 
dates.  Yes they get to the dates by doing interval calculations, but 
what matters are the dates and I haven't heard anyone say otherwise.

>   The example walk-through is designed to be simple
> concrete suggestion.
You're welcome.  However, all the rest of these are also "concrete 
suggestions".  Or do you mean "actual text that I can incorporate"? I'm 
happy to edit the entire document to fix the issues if you want to give 
me the edit token.

>   As to "when" it amounts to the current
> remaining...".

So 10 people doing this have to publish both the interval they calculate 
and the time() value at which they did their calculations?  So the other 
10-100 people can figure out "when"? I think not.

> Again, this is written from the point of view of
And it should be written from the POV of a human wanting to tell a group 
of people WHEN something will be done.   Sending out "we're going to do 
this in 45 days" is problematic especially if I re-read the email 10 
days after it was sent or if the email was delayed.    Sending out 
"we're going to do this on January 1st at 10am" or "we're going to do 
this in 45 days which is January 1st at 10am" is going to be more useful 
than a simple interval.

I can't figure out why you continue to argue as you do - the output of 
this calculation is a date and time at which it is safe to revoke the 
old keys - not an interval.  In fact you have to work hard to make it an 
interval.

Later, Mike