On Wed, Aug 3, 2016 at 10:38 AM, Wes Hardaker <wjh...@hardakers.net> wrote: > 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.
Yup, somehow the equation section ran away during edits of the initial version -- Wes and I hunted it down, put it back in the document and it's been posted. Hopefully it is clearer now. W > >> 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 -- 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
