15 Čec
2020
15 Čec
'20
8:25
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