[babel] key rotation take #2

Dave Taht <dave@taht.net> Wed, 28 November 2018 10:06 UTC

Return-Path: <dave@taht.net>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5654712D4ED for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 02:06:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMiD9kB02BDy for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 02:06:37 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3630128C65 for <babel@ietf.org>; Wed, 28 Nov 2018 02:06:36 -0800 (PST)
Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id AAEEF221E9; Wed, 28 Nov 2018 10:06:33 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: babel@ietf.org, babel-users@lists.alioth.debian.org
Date: Wed, 28 Nov 2018 02:06:22 -0800
Message-ID: <87in0h1ppd.fsf@taht.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/om5K6Hmwz9xj7n_cFnw3M9EkTMA>
Subject: [babel] key rotation take #2
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2018 10:06:38 -0000

OK, nobody liked timestamps and the dnssec analogy, nor standardizing on
an easily distributable out of band key format.

I can live with that.

However, what I would like to be doing is testing the key signing, and
rollover methods, and measuring the overhead of HMAC-ing twice, as well
as the effects (and bugs) on unicast and multicast transmissions and the
rollover process itself, and interoperability between bird and babel.

So here's a simpler alternate suggestion for configuring the the thing.
It is not intended as an ietf standard but as a means to deploy tests of
key rollovers.

This is the present babel conf file format:

key id key1 type sha1 value deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
key id key2 type sha1 value dea2f0d01a57b0071057a11da7adeadbeeffffff
default enable-timestamps true unicast true hmac key1
interface enp7s0 unicast false hmac key1
interface wlps3 type wireless
interface enp4s0
interface wg1 hmac key2

so we invent a new keyword "serial".

a key rollover is initiated by adding a new key with the same name and a
larger serial number than the old one.

A key id line with no serial keyword has an implied serial number of 0.

A new line gets added (via conf or configuration interface) that looks
like this:

key id key2 type blake2s serial 1 value dea2f0d01a57b0071057a11da7adeadbeefffff0

*the protocol* retires the old key as soon as possible.

the admin removes the old key when convenient and safe to do so.

Does that work for everybody?



PS it would be mildly more compact to use
base64 to encode the key.

/me hides