Re: [babel] HMAC Key rotation key format (was ripemd)

[Toke Høiland-Jørgensen <[e-mail]>]

Dave Taht <[e-mail]> writes:

> On Mon, Nov 26, 2018 at 1:10 PM Toke Høiland-Jørgensen <[e-mail]> wrote:
>>
>> Dave Taht <[e-mail]> writes:
>>
>> > To me this leaves the biggest problem remaining is key rotation. Me
>> > being me, and remembering just how hard it was to get dnssec working
>> > on systems lacking reliable time,
>>
>> The Babel HMAC extension as currently specified does not rely on wall
>> clock time in any way, so not really sure how a comparison to dnssec is
>> relevant?
>
> More below. Relative time is ok, too. 3000 seconds from now, start
> rolling over. Stop signing records with the old key as soon as
> everyone you can currently hear uses the new key, 6000 seconds from
> now, retire the old key unconditionally.

Well, you would handle this by whatever mechanism you use to configure
your routers in the first place...

>> > Setting that aside for the moment, having a standardized file format
>> > for babel keys would be a boon and boost interoperability between
>> > bird/babel and other possible implementations.
>>
>> From the point of view of each routing daemon this would just make Babel
>> a special snowflake.
>
> ok. That leaves how to get new keys into nodes running different
> daemons. Anyone for IKEv2?
>
> My out of bound way is via scp and ssh.

I think Juliusz' insistence that we shouldn't reinvent key distribution
is wise. See above; you need to configure the daemons in the first place
anyway...

> Also the present babeld cannot rewrite it's entire config file (so far
> as I know). I think bird can...


Yup, a 'bird reconfigure' will re-read the entire config file and apply
it if it parses successfully.

> but I don't trust it.

Your trust issues are probably best resolved between you and your daemon ;)

>> What we can do is to specify the format in the information model if a
>> cross-implementation format is really needed (which I'm not really
>> convinced of, either)...
>
> To quote from appendix A:
>
> "In order to perform key rotation, the new key is added to all the
> nodes; once this is done, both the old and the new key are sent in all
> packets, and packets are accepted if they are properly signed by
> either of the keys. At that point, the old key is removed."
>
> My key points made here are "the new key is added to *all* the
> nodes"... which may or may not be up over the course of days, or weeks
> for whatever definition of "all" you have ... "Once this is done" -
> how can you tell? -  "and packets are accepted if they are properly
> signed by either of the keys" hopefully you log this ... "the old key
> is removed".
>
> perhaps "deprecated, no longer actively used for signing, then removed
> after a suitable period"?

Hmm, having a way to mark a key as "verify only" may be useful for
simpler monitoring. But really, you *could* derive the same information
from the opposite bit (track how many neighbours don't sign with the new
key yet). So then it becomes more of an efficiency issue (you could save
one signature on the wire during rotation). Not sure if it's worth
specifying another bit in the spec for this? Or if such a configuration
mode should even be in the spec at all?

> So, if you do a key rotation and X routers are offline or inaccessible
> at that particular time... they are going to stay inaccessible
> forevermore, unless rekey'd via sneakernet, climbing on trees, and
> other forms of manual intervention.

Presumably your key rotation policy would take into account the outage
schedules of the routers in your network? :)

-Toke