14 Čec
2020
14 Čec
'20
19:22
Hi Jean-Piet,
sure, the implementation in Knot would be fully flexible and up to the
operator, how long the 'revoked' period would be.
I'm just curious about your thoughts and interpretation of 5011, mostly
induced by thinking about automatic management... The hold-down timers
are "30 days *OR* some TTLs", which is not clear if it's a maximum or
minimum. Interestingly,
https://tools.ietf.org/html/rfc6781.html#section-4.1.2.1 requires 'zone
maximum TTL', which sounds really odd to me, since KSK has nothing to do
with zone contents besides DNSKEY RRSet (and its TTL).
BR,
Libor
Dne 14.07.20 v 18:43 Jan-Piet Mens napsal(a):
Hi Libor,
I'm open to implement this for the next
version, at least for the
manual key management, as you suggested.
I'm tentative for enabling this with automatic key management, since
it's quite complicated, and with algorithm rollover maybe even
fragile: https://tools.ietf.org/html/rfc6781.html#section-4.1.4.2
It's super complicated. I "fondly" recall how 5011 brought me the very
first CVE with my name on it! I know Evan wasn't amused. :-)
Anyway, I'd like to ask you for an
operational opinion: for how long
period would you publish the old KSK with 'revoked' flag before
deleting it
RFC5011 specifies add/remove hold-down timers of 30 days each, but if
we do this with manual key management, I think it should be either
configurable or be defined by the operator, a bit like active= and
retire= work: just let the operator specify a (relative) time. (This
is particularly important for testing, as BIND and Unbound have
switches with which to reduce the 30 days to, say, minutes, if I want.)
I'd be fine with manual mode permitting me to have keymgr(8) revoke
the key, and sometime later, at my discretion, remove the key as we do
now.
To the side note: For the sake of simplicity,
when manual key
management is enabled, knotd is simply not allowed to modify the
keyset in any way
Understood, thank you.
-JP