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

Dave Taht <dave.taht@gmail.com> Mon, 26 November 2018 22:04 UTC

Return-Path: <dave.taht@gmail.com>
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 A0BB2131038 for <babel@ietfa.amsl.com>; Mon, 26 Nov 2018 14:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WIIbhu6T7cos for <babel@ietfa.amsl.com>; Mon, 26 Nov 2018 14:04:07 -0800 (PST)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F2313102F for <babel@ietf.org>; Mon, 26 Nov 2018 14:04:07 -0800 (PST)
Received: by mail-qt1-x82c.google.com with SMTP id d18so19527691qto.8 for <babel@ietf.org>; Mon, 26 Nov 2018 14:04:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=x9bgxdI+5I14aFc9SDjSnQICifr9cf1bQWx1x31ThhY=; b=LKX3RrisnITTX55Z3nt07WJ0ykw2scGaEiP2V65j5BHMqjt/Qzzljc9/CnOXlFVZhB BEOaLuksxoJkwQOoj4sh7NfTVcpTi97GBA93INFdr5CksSZJ1DwsRrvzd+zwTH7Hr5vP 11/fHoEaInOt8ZD6QKHXfu2SV8DP2VfyWGKK5abV9yQwYDhPJsMz61NG9hfBBLLvF4Je 7rJ1ZprshvLFf8kx5NBqv1JL+YiBbT7Dhhg3UGU7dqKIEh5JJCEzG2SDs4X7O6dkAWaQ vlduYDuHGT6XGFoUzmFbMcdpRDyLbcQFQNir1LEI0LeOm48HLzqWUV7l5f0vC5f5TAW6 5YIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=x9bgxdI+5I14aFc9SDjSnQICifr9cf1bQWx1x31ThhY=; b=GuCtk3TAWoMpBcTLUDBRAfLiJcVNCoPQWwNtdKlAqUX7b6cEZVg5plFjwbCH2EvpRV 46yvSNMM8sML5pbcwqQ5/uzbB2sV6G9GHAepvIZmoCol/L6CPH7dzxR1Zds9ORPTjYZ+ RfmlqFwCQPAATRpuJfsVOoebAMWY/VYgNJ3rUckrQzyRfzX4h9PfhSd9Hye+8Z2GxDbu 1VmGJ1qfAPLgDmlqWVonxYYxzFXlENKNr9QCxGi4XqhCddC7V/zVqmfyhn+VKbgre3M7 6Ije6eg9yDY19bh22WOnDP0bZlvEGVPby4aVlkiTxFKHNgJSs0J7hsEg69/Eh4Y9RfuB zOaw==
X-Gm-Message-State: AGRZ1gIvDJcVjU2GBalFhHBNLfNhNxzVgBdfAP9Uh3I8nGIge2/dHrER kmCGZtcIxfbPuchMTDfHI0+lbQ9h4KUJSBTmZp8D/q3d
X-Google-Smtp-Source: AJdET5fcOSZmV2Up0ZYsqkbosIfS99ar2YxRRGbpvy5zEddbuUAV+eZDdj1LOcnlZ30slW7Nt6rD6Ym8og0WOxiCB6E=
X-Received: by 2002:ac8:3065:: with SMTP id g34mr28879260qte.136.1543269846645; Mon, 26 Nov 2018 14:04:06 -0800 (PST)
MIME-Version: 1.0
References: <CAA93jw5fHRm21yEJsabiiOF1ZP7Zh3M_gEgRo0imBOpRGhf0qA@mail.gmail.com> <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <CAA93jw5gaYgyUX-ABX156_TnFX25Sy5SLyuRgd28fMLfRW4UHA@mail.gmail.com> <871s78x7z0.fsf@toke.dk> <CAA93jw6268QC1kmHEasJ-FbyXL_mgfQc_C-6cdksHd02ceb2Kw@mail.gmail.com> <87k1kzwnmn.fsf@toke.dk>
In-Reply-To: <87k1kzwnmn.fsf@toke.dk>
From: Dave Taht <dave.taht@gmail.com>
Date: Mon, 26 Nov 2018 14:03:53 -0800
Message-ID: <CAA93jw756p-78D5ciJEeXa0fpMAaFXBJEn+km8d5HCA3dX9eDw@mail.gmail.com>
To: Toke Høiland-Jørgensen <toke@toke.dk>
Cc: Juliusz Chroboczek <jch@irif.fr>, babel-users <babel-users@lists.alioth.debian.org>, Babel at IETF <babel@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/nv38zvLBuF9WHGIUobd0galeOg8>
Subject: Re: [babel] HMAC Key rotation key format (was ripemd)
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: Mon, 26 Nov 2018 22:04:10 -0000

On Mon, Nov 26, 2018 at 1:10 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Dave Taht <dave.taht@gmail.com> 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.

> > 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.

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

As for the key format, I wanted a way to test keys and key rollover in
the existing daemons to verify this bit would work, and also measure
the cpu overhead and failure modes, like those I describe below.

> 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"?

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.

The case where you want to immediately remove a key is in the event of
a security breach.


I tried to use the example of dnssec as one way key rotation (on
admittedly a much bigger scale) that got done right, but the new keys
were distributed a good year beforehand.

https://kb.isc.org/docs/aa-00822

...

also "old and new key are sent" should be "old & new keys are used for signing".

...

>
> -Toke



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740