Matthijs Mekking <matth...@pletterpet.nl> 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
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
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.
--
Wes Hardaker
Parsons
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
