Re: [babel] [Babel-users] key rotation take #2

Dave Taht <dave.taht@gmail.com> Wed, 28 November 2018 21: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 68E27130EE4 for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 13:04:10 -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 wPh5JnQqhtL4 for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 13:04:08 -0800 (PST)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 DAEED130E27 for <babel@ietf.org>; Wed, 28 Nov 2018 13:04:07 -0800 (PST)
Received: by mail-qk1-x72b.google.com with SMTP id o125so17750290qkf.3 for <babel@ietf.org>; Wed, 28 Nov 2018 13: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=HEQd7XF1e2l6CzPVLP4yDC5KSnAFWsdEPUufy3BKDpo=; b=m8eYEyzxM7A6zh77ltRnM/v25+DUQtEXqFxEs6V2Ziag6BSij4zA2ODkKEELm3ycye sz9D0SqBFZPNmlJrl4DxYP1IGe4DNk6R8PpHDx+i/guv6H8SepSqquVPrLS++odLRM7W tjn+jgl50o3Zh7FPjr+k/KjkkKECdjE6fd/Q8dqGlHZ8E35d3hbAjUfUBzI0rbAt2+ta HT0BE3OhPdWi/YVgtr5zQhJIpC/75SjG4nfyZuKKA0f+ogfX3HuaVceQqaLho8WHg2kL BqS3y7DRHBwW6JvxZfDlPNw+mxvp96u0/1kn4N2OPAqgFHRPMEUi54Raw0V02+HU1OWP Kvjg==
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=HEQd7XF1e2l6CzPVLP4yDC5KSnAFWsdEPUufy3BKDpo=; b=meXXFa6XsRKJ040UQKt1gZuvJwq7PLUwFB7qfRl2fgHtE+cqQ3B0l1Ays1xSH2JHKT 6Fv3WMzxSdHH4hJK2HW9GVIuiSdxwm8539D63VZBFdiI1KvnAB2scPXUctDVp8gMTMrF H3zZkcP1hPObxMvFTu46VpWdIgNVIkZqK6eGmSeYUfMpTN872u0Wj+ycR2MKYpGlLmKr XDCxGpD6oh3O5nOlBzV3sh/pkrnpWNDEO9Gg9tEGVOptI+jhRuQCyH3STqZhSJxqWePv vaJfo+NVOeXUIEMewY/rxc+3isfJmydGMfKlhdEGKlOtvGr0dd4Y6dv/ZqFndxAv0sdD O5RA==
X-Gm-Message-State: AA+aEWbH7Q/6T/vGo37+lSe19Q2f2MMHvQuFEe5TtPb3MePW7czhrJeU oZe/yB7OuvWGxYPRCuJ00pDthX+qsZgITUbzmG6tsg==
X-Google-Smtp-Source: AFSGD/XJb/x1Zg07PH2yCWQj/W/iQkNDBOM5yksZ6avyUb7aNegGxFbba5pLjwCGejNwLU3Zn0RQ2mUsjKsrYwaJWV0=
X-Received: by 2002:a37:18d5:: with SMTP id 82mr34509962qky.65.1543439046870; Wed, 28 Nov 2018 13:04:06 -0800 (PST)
MIME-Version: 1.0
References: <87in0h1ppd.fsf@taht.net> <87efb5v1y6.fsf@toke.dk> <877egx17w6.fsf@taht.net> <87tvk1t0h9.fsf@toke.dk>
In-Reply-To: <87tvk1t0h9.fsf@toke.dk>
From: Dave Taht <dave.taht@gmail.com>
Date: Wed, 28 Nov 2018 13:03:55 -0800
Message-ID: <CAA93jw5=82X-cvo0_ZXEvwEYt4_r4Nn-trOXTiLtKB_0q5kh2Q@mail.gmail.com>
To: Toke Høiland-Jørgensen <toke@toke.dk>
Cc: Dave Täht <dave@taht.net>, 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/sM6RymK6lW4swtqe4icTEyJO3ms>
Subject: Re: [babel] [Babel-users] 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 21:04:11 -0000

On Wed, Nov 28, 2018 at 12:23 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Dave Taht <dave@taht.net> writes:
>
> > Toke Høiland-Jørgensen <toke@toke.dk> writes:
> >
> >> Dave Taht <dave@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.

>
> -Toke
>
> _______________________________________________
> Babel-users mailing list
> Babel-users@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users



-- 

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