On 7/12/2017 1:35 PM, Wes Hardaker wrote:
Mike,
The value in 6 regardless of what it is is the wrong value for
revocation. revocationPublicationWaitTime is basically
EarliestDateAttackFails + queryInterval + slop. Revocations take
place immediately. You can delay them only as long as you have old
valid signed RRSets.
So in short, the advice in 5011 section 6.6 step 3:
3. After 30 days, stop publishing the old, revoked keys and remove
any corresponding DS records in the parent.
Has nothing to do with a needed wait time (because keys are revoked
immediately) but rather the above 30 days is really just a suggested
time for operational practice?
In your "prevent the add of a new trust anchor" attack, you only need to
intercept one query/response pair over a period of queryInterval +
EarliestDateAttackFails. In the "prevent revocation" attack, you need
to intercept ALL query/response pairs for at least 30 days (in the
example - that's 60 Q/Rs) - quite a bit harder and pretty much
impossible to do widespread. Also, 6.6 talks about deletion of a
subordinate trust point by revoking all the trust anchors - depending on
the behavior of the resolver (which I had many arguments about with
various vendors), trust will generally be traced through the new DS
record(s) with the absence of the old trust anchor key in the DNSKEY
RRSet so the presence (or absence) of the "revoked" key in the
resolver's trust anchor set is mostly a non-issue once the DS is published.
Given that I can think of only a few possible subordinate trust points
and none of them will probably ever be deleted, I probably wouldn't
change this guidance. If we were going to change the guidance, it
wouldn't be as simple as the publish new trust anchor model - you would
need to consider the expiration of the Parent DS (if any) as well as
expiration of the child DNSKEY RRSet in picking a new value.
In 2.4.2 you have:
The remove hold-down time is 30 days. This parameter is solely a key
management database bookeeping parameter. Failure to remove
information about the state of defunct keys from the database will
not adversely impact the security of this protocol, but may end up
with a database cluttered with obsolete key information.
Which seems to back this up (though I'm not convinced that there is no
security ramifications of having old trust anchors around; else why
delete them?)
Nope - two different parameters with the same value. The first was a
publication guidance, the above was simple database management guidance
for the resolver.
So in the 5011-security-considerations draft, I agree with your point
that the right amount of time to wait should be changed to replayTime +
queryInterval + slop. Thanks for pointing that out. (though it's worth
noting that replayTime + queryInterval can be longer than 30 days).
If you mean that replayTime ~= last validity date/time of the old DNSKey
RRSet with the to be removed keys - then yes. But please be clear and
precise in how you define this term in the document.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
