• KASP Inactive/Retired timestamps

    From Gregory Shapiro@bind-users@g.gshapiro.net to bind-users on Tue May 19 17:37:20 2020
    From Newsgroup: comp.protocols.dns.bind

    After the fantastic ISC DNSSEC webinar series last month, I began using KASP for my DNSSEC signed zones. I have noticed an odd behavior with regards to the files BIND keeps in keys/ (K*.key, K*.private, and K*.state). For inactive/retired keys, every BIND restart updates the dates in those files (see below). This raises two questions:

    1. Should the time a key becomes inactive or retired be a fixed point in time rather than changing to the last time BIND restarted for every restart?

    2. When, if ever, is it safe to remove the files from the keys directory for inactive/retired keys (i.e., is there a state after Inactive or Retired)?

    An example set of changes is shown in the pruned diff below. Note that for this particular key, the state file shows the following states:

    DNSKEYState: hidden
    ZRRSIGState: hidden
    GoalState: hidden

    --- Kgshapiro.net.+008+05640.key 18 May 2020 02:06:14 -0000 1.9
    +++ Kgshapiro.net.+008+05640.key 19 May 2020 23:53:06 -0000
    -; Inactive: 20200518020420 (Tue May 18 02:04:20 2020)
    +; Inactive: 20200519230430 (Tue May 19 23:04:30 2020)

    --- Kgshapiro.net.+008+05640.private 18 May 2020 02:06:14 -0000 1.9
    +++ Kgshapiro.net.+008+05640.private 19 May 2020 23:53:06 -0000
    -Inactive: 20200518020420
    +Inactive: 20200519230430

    --- Kgshapiro.net.+008+05640.state 18 May 2020 02:06:14 -0000 1.8
    +++ Kgshapiro.net.+008+05640.state 19 May 2020 23:53:06 -0000
    -Retired: 20200518020420 (Tue May 18 02:04:20 2020)
    +Retired: 20200519230430 (Tue May 19 23:04:30 2020)

    Thanks!
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Matthijs Mekking@matthijs@isc.org to bind-users on Wed May 20 08:25:05 2020
    From Newsgroup: comp.protocols.dns.bind

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d6hKXDL9GbeTzU7e8I3JhfCTG8ico5oKl
    Content-Type: multipart/mixed; boundary="RfARtNtuWoBq0W5sC0v6PDlw0TLHkhZX2";
    protected-headers="v1"
    From: Matthijs Mekking <matthijs@isc.org>
    To: bind-users@lists.isc.org
    Message-ID: <22ff7e34-d329-24e4-e954-6ec3643faba1@isc.org>
    Subject: Re: KASP Inactive/Retired timestamps
    References: <20200520003720.62lknfqeuhlvofjp@smallberries.local>
    In-Reply-To: <20200520003720.62lknfqeuhlvofjp@smallberries.local>

    --RfARtNtuWoBq0W5sC0v6PDlw0TLHkhZX2
    Content-Type: text/plain; charset=utf-8
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable

    Hi Gregory,

    Thanks for trying out out the new KASP. Let me try to answer your
    questions below.

    On 5/20/20 2:37 AM, Gregory Shapiro via bind-users wrote:
    After the fantastic ISC DNSSEC webinar series last month, I began
    using KASP for my DNSSEC signed zones. I have noticed an odd
    behavior with regards to the files BIND keeps in keys/ (K*.key,
    K*.private, and K*.state). For inactive/retired keys, every BIND
    restart updates the dates in those files (see below). This raises
    two questions:
    =20
    1. Should the time a key becomes inactive or retired be a fixed point
    in time rather than changing to the last time BIND restarted for
    every restart?

    Named now takes care of the rollover, taking over the job of fiddling
    with dnssec-keymgr. That means that named will set the key times.

    Note that a key time is an indication of an event happening: if the
    underlying state machine thinks it is not yet safe to do so, the event
    will happen at a later point in time.

    In other words, the keymgr embedded in named is making decisions on
    rollover actions based on this state machine, not the key times. The
    key times do help the user to see when key rollovers will happen.

    In principle these times are fixed, but changes in key files (a key gets published, a change in key lifetime, ...) will trigger updating the key
    times.


    2. When, if ever, is it safe to remove the files from the keys
    directory for inactive/retired keys (i.e., is there a state after
    Inactive or Retired)?

    There is a Deleted time as well, at this point the key and corresponding signatures should no longer occur in the zone. When looking at the key
    state files: if all states are in "hidden" it is safe to prune the files.=


    An example set of changes is shown in the pruned diff below. Note
    that for this particular key, the state file shows the following
    states:

    Thanks for showing this example. This is a minor bug. What happens is
    that the key file matches your dnssec-policy but most likely another
    active key also matches. Any excess keys are retired immediately (even
    if this key was already retired previously).


    Best regards,

    Matthijs


    DNSKEYState: hidden ZRRSIGState: hidden GoalState: hidden
    =20
    --- Kgshapiro.net.+008+05640.key 18 May 2020 02:06:14 -0000
    1.9 +++ Kgshapiro.net.+008+05640.key 19 May 2020 23:53:06
    -0000 -; Inactive: 20200518020420 (Tue May 18 02:04:20 2020) +;
    Inactive: 20200519230430 (Tue May 19 23:04:30 2020)
    =20
    --- Kgshapiro.net.+008+05640.private 18 May 2020 02:06:14 -0000
    1.9 +++ Kgshapiro.net.+008+05640.private 19 May 2020 23:53:06
    -0000 -Inactive: 20200518020420 +Inactive: 20200519230430
    =20
    --- Kgshapiro.net.+008+05640.state 18 May 2020 02:06:14 -0000
    1.8 +++ Kgshapiro.net.+008+05640.state 19 May 2020 23:53:06
    -0000 -Retired: 20200518020420 (Tue May 18 02:04:20 2020) +Retired: 20200519230430 (Tue May 19 23:04:30 2020)
    =20
    Thanks! _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
    this list
    =20
    ISC funds the development of this software with paid support
    subscriptions. Contact us at https://www.isc.org/contact/ for more information.
    =20
    =20
    bind-users mailing list bind-users@lists.isc.org=20 https://lists.isc.org/mailman/listinfo/bind-users
    =20


    --RfARtNtuWoBq0W5sC0v6PDlw0TLHkhZX2--

    --d6hKXDL9GbeTzU7e8I3JhfCTG8ico5oKl
    Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQEzBAEBCAAdFiEEF9tUtPZjiCApvBobVHl7Vy10FR4FAl7EzUEACgkQVHl7Vy10 FR679ggA7JNxhlKWxPGRwb2YIJI7ISNk1q4k6+354krrdHWaUHUR4AI6GnersDMN PRjq8F9lNFjaGVJ6Z3QY3oJoMDV01LPwFKELEr3tFWgTnOuC1SUX3OhpbJhdR6g+ 9Y2EkDcGSsdzBt0Rib/xfJ6e/r/IT3dDKi5Y+4w3GMzikJV0qpOdm2G4WcvBfIWi plYk5ZvoRq2VKxCk/Boa5O6plKaZvYTQiQf1byNz2rvfE8m51N8O8j+Ihv+LCTSp TsoBMlwj+ak58ce/Opa7KZzHN+PhBYBO/fuGCNmjYzbqqTIetPDZMTfU7G02OlzI XFVRYD5qQ8MxlER/c8+3436RVROAXg==
    =/vte
    -----END PGP SIGNATURE-----

    --d6hKXDL9GbeTzU7e8I3JhfCTG8ico5oKl--
    --- Synchronet 3.18a-Linux NewsLink 1.113