14 Jul
2020
14 Jul
'20
9:37 a.m.
Hello!
first of all, thank you for a wonderful authoritative DNS server; as
mentioned a while back, I'm loving the automatic key management and DS
push; both work a treat.
I have a requirement for manual key management and that is to be able to
roll KSK keys a la RFC 5011 for both BIND and Unbound instances to
automatically change their trust anchors.
In Knot I can retire a key and subsequently have it removed, but the key
isn't revoked (a.k.a. key flags 257+128 == 385).
keymgr . set 41155 active=+1mi retire=+5mi remove=+60mi
As such, BIND will, when this particular KSK is removed from the DNSKEY
RRset, (rightly) complain:
managed-keys-zone: Active key 41155 for zone . unexpectedly
missing
managed-keys-zone: Key 30377 for zone . is now trusted
(acceptance timer complete)
I've not found the word 'revoke' in the documentation, and no flags I
can set with keymgr(8) seem to indicate that I can revoke a key. Can you
help me, please?
As an aside, I've noticed that when keymgr's `remove' time is reached,
the key is removed from the zone (which is expected), however the key
itself remains in the key store. From there, I can delete it, but I can
also set flags on it in such a way as that it's brought *back* into the
zone. Is that expected behaviour? It's not a problem per se, I'd just
like to know whether I've understood the system.
Thank you and kind regards,
-JP
14 Jul
14 Jul
2:23 p.m.
Hi Jean-Piet!
Thanks much for your feature suggestion.
The truth is, that Knot DNS has not been RFC5011-aware at all.
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
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 (comparing to DNSKEY TTL, zone maximal TTL, propagation delay etc)?
To the side note: well, this is something between a bug and a feature :)
For the sake of simplicity, when manual key management is enabled, knotd
is simply not allowed to modify the keyset in any way, including final
deletion of keys marked as deleted (with automatic key management
however, the deleted keys really disappear).
Hearty regards,
Libor
Dne 14.07.20 v 09:37 Jan-Piet Mens napsal(a):
Hello!
first of all, thank you for a wonderful authoritative DNS server; as
mentioned a while back, I'm loving the automatic key management and DS
push; both work a treat.
I have a requirement for manual key management and that is to be able
to roll KSK keys a la RFC 5011 for both BIND and Unbound instances to
automatically change their trust anchors.
In Knot I can retire a key and subsequently have it removed, but the
key isn't revoked (a.k.a. key flags 257+128 == 385).
keymgr . set 41155 active=+1mi retire=+5mi remove=+60mi
As such, BIND will, when this particular KSK is removed from the
DNSKEY RRset, (rightly) complain:
managed-keys-zone: Active key 41155 for zone . unexpectedly
missing
managed-keys-zone: Key 30377 for zone . is now trusted
(acceptance timer complete)
I've not found the word 'revoke' in the documentation, and no flags I
can set with keymgr(8) seem to indicate that I can revoke a key. Can
you help me, please?
As an aside, I've noticed that when keymgr's `remove' time is reached,
the key is removed from the zone (which is expected), however the key
itself remains in the key store. From there, I can delete it, but I
can also set flags on it in such a way as that it's brought *back*
into the zone. Is that expected behaviour? It's not a problem per se,
I'd just like to know whether I've understood the system.
Thank you and kind regards,
-JP
6:43 p.m.
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
7:22 p.m.
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 
15 Jul
15 Jul
8:25 a.m.
Hi,
On 7/14/20 7:22 PM, libor.peltan wrote:
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).
First of all, there are two hold-down timers, only the Add hold-down
timer is TTL based. The Remove hold-down timer is just 30 days and is
solely for bookkeeping purposes.
I think you are right that RFC 6781 could have said "DNSKEY_K_1 must be
published for one more DNSKEY TTL with the REVOKE bit set." Rollovers
in this RFC are using Maximum Zone TTL for most of its rollovers and
this may be a copy paste error.
Although it is not a real problem, the Maximum Zone TTL is a safe period
to wait (because it is always equal or larger than the DNSKEY TTL), but
you might want to report an errata for it.
Best regards,
Matthijs
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
2217
days inactive
2218
days old
4 comments
3 participants
participants (3)
-
Jan-Piet Mens -
libor.peltan -
Matthijs Mekking