Re: [DNSOP] new dnsop related draft: RFC5011 security considerations

[Matthijs Mekking <[e-mail]>]

Wes,

On 08/03/2016 07:38 PM, Wes Hardaker wrote:
> Matthijs Mekking <[e-mail]> writes:
> 
>> 1. In the introduction you mention there is no guidance to how long a
>> DNSKEY must be published before it can be considered accepted. Perhaps
>> there is no implicit guidance in RFC 5011, you should be able to derive
>> it from the timing parameters defined in that document.
> 
> I believe one can derive it, hence the reason we titled the draft
> "security considerations".  IE, it's not the intent of the draft to
> create anything new, just to more clearly document what is already true
> (but misunderstood by most).
> 
>> In fact, it has been done before and RFC 7583 (DNSSEC Key Rollover
>> Timing Considerations) gives guidance on exactly this in Section
>> 3.3.4.
> 
> I need to study that document again (it's been a while) in order to
> fully respond to your note, but I agree there is information in there
> that is certainly relevant.  And we should certainly add a reference to
> it as well, if this document needs to go forward.
> 
> In 3.3.4.1, we have:
> 
>     modifiedQueryInterval = MAX(1hr, MIN(15 days, TTLkey / 2))
>     Itrp >= AddHoldDownTime + 2 * modifiedQueryInterval

Looking at this advice again, I think the Zone Maintainer in the
outlined attack actually even makes a conservative assumption about when
it is safe to use the new key (T-36). If the Zone Maintainer followed
the guidance in Section 3.3.4.1 from RFC 7583, it would have at least
waited Itrp.

The AddHoldDownTime is 30 days already in your example, see RFC 5011:

   The add hold-down time is 30 days or the expiration time of* the
   original TTL of the first trust point DNSKEY RRSet that contained the
   new key, whichever is greater.

* Side tracked: This 'of' should probably be an 'or'. Or I don't know
what 'the expiration time of the original TTL...' means.

The modifiedQueryInterval in your example is

    MAX(1hr, MIN(15 days, 1d /2)) = MAX(1hr, 1/2 day) = 1/2 day

So already at T-31 the Zone Maintainer could have believed that all 5011
enabled validators should have accepted the new key.

Now RFC 7583 makes this remark:

   Once
   retrieved, a validating resolver needs to wait for AddHoldDownTime.
   Providing it does not see a validly signed DNSKEY RRset without the
   new key in that period, it 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).

So Itrp does indeed not take into account this attack possibility.

> And in our document, I just realized, fails to define the "safe"
> equation that we came up with.  But our safe value came out to be:
> 
>     Itrp >= AddHoldDownTime + 3 * SignatureLife / 2 + 2 * TTLkey

Which in this example is 30 + 15 + 2 = 47 days.

Since the replay attack is not possible anymore after the signatures at
T-1 (or before) are expired, I think the new Itrp should be:

      Itrp >= SIGVALkey + AddHoldDownTime + 2 * modifiedQueryInterval

...where SIGVALkey is the RRSIG Signature Validity period of the DNSKEY
RRset, used at T-1.


> We'll go add that equation into our document (which I was sure we had
> put in, but apparently not) and republish shortly.
> 
>> 2. The outlined attack is possible because the defined queryInterval is
>> approximately done at the half of the RRSIG expiration interval. If the
>> queryInterval was to be increased that it would be at most the full
>> expiration interval, the replay attack cannot be successfully executed.
>> While this makes the DNSKEY rollover duration even longer, it is now
>> secured against the outlined attack.
> 
> I don't think we need to modify 5011 itself.  Just how to use it.

True. It's a matter of how one wants to fix it: With zone management to
deal with the attack, or with updating the protocol so the attack cannot
take place.

I think the latter is more robust, but it's certainly good advice to
increase the publication time of the DNSKEY to circumvent the attack.


Best regards,
  Matthijs