[Babel-users] key rotation take #2

[Dave Taht]

Toke Høiland-Jørgensen <toke at toke.dk> writes:

> Dave Taht <dave.taht at gmail.com> writes:
>
>> On Wed, Nov 28, 2018 at 12:23 PM Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>>>
>>> Dave Taht <dave at taht.net> writes:
>>>
>>> > Toke Høiland-Jørgensen <toke at toke.dk> writes:
>>> >
>>> >> Dave Taht <dave at taht.net> writes:
>>> >>
>>> >>> so we invent a new keyword "serial".
>>> >>
>>> >> So what you're trying to express here is the notion of a "receive-only"
>>> >> key that is not used for signing outgoing packets, right?
>>> >
>>> >
>>> > No... the old key is retired from active use in the protocol after
>>> > concensus is achieved on the new key by the protocol, and not used
>>> > again unless a router comes up with an unreadable hmac. In that case
>>> > we go back to at least trying to verify (periodically?) that it's not
>>> > using the old key (if we still have it around) and if it's using the
>>> > old key, we go back to signing stuff with that key.
>>> >
>>> > Does that concept need to be in the protocol spec?
>>>
>>> This reads to me like a specific operational procedure for deployment;
>>> don't think that should go into the spec, no.
>>>
>>> >> it would be better to express that explicitly as a property of the key
>>> >> config that can be changed on a per-key basis. For one thing, 'serial'
>>> >> is misleading as it sounds like something that affects the wire
>>> >> format,
>>> >
>>> > OK. how about "new" and "old" as keywords? That implies two states and
>>> > two states only. I liked 0 and X as numbers, so long as the ascending
>>> > property is maintained. As for why not 0 and 1, see below.
>>> >
>>> > Totally open to bikeshedding the name. :) babeltowerno?
>>>
>>> Don't care what they are called. My point is just that it's a property
>>> of a particular key.
>>>
>>> Bird already has this, BTW: each key can be set to "generate" signatures
>>> and "accept" signatures, where the former puts them on the wire, and the
>>> latter will accept packets signed with that key. You can set time ranges
>>> for each or both. See
>>> https://bird.network.cz/?get_doc&v=20&f=bird-3.html (search for
>>> "password option"). The Babel HMAC implementation inherits this.
>>
>> That is essentially my first proposal... in bird syntax. :) Aside from
>> needing good time, there are really good reasons to stage key
>> rotations that way....
>>
>> while the odds are much better that a boot/bootstrapping bird router
>> has a working rtc, your typical home router doesn't.
>
> No, but you can use the mechanism without the timeouts to mark keys as
> active/passive using whatever provisioning system you are using to
> distribute the keys (just use "{generate,accept} from 1970-01-01").

Same as the first mechanism I proposed, except I didn't have the concept
of "from" a date in it per se'. Bird's formulation is superior.

I have zero issue with making how babeld does it essentially compatible
to how bird thinks about it... so long as we do it, and test it.

Shall we make it three's the charm on these proposals and go implement?

...

Still, to me, just having an incremental "babeltowerno" number removes
all reliance on the notion of time, and seems more appropriate to boxes
that don't have a solid notion of such. 

...


Then there's an issue of encoding the darn key. It's hex now, and of
fixed length. I like to think the WEP experience (a string of numbers)
showed that the WPA2 method (human readable text) was more deployable.
BASE64 can be shorter, and also representable as human readable text -

"I_Take_The_F1fth!!!" was one of my favorite passwords back when I
feared rubber-hose cryptanalysis, as it would allow me to answer the
question honestly, under duress. 

or as something gnarly like 234aB#=%Awhat()ever with mildly more strength.

>
> -Toke