Re: [babel] hmac info model elements

Toke Høiland-Jørgensen <toke@toke.dk> Fri, 04 January 2019 20:38 UTC

Return-Path: <toke@toke.dk>
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 D158D130E9A for <babel@ietfa.amsl.com>; Fri, 4 Jan 2019 12:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
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 ROZjoJa4kbKn for <babel@ietfa.amsl.com>; Fri, 4 Jan 2019 12:38:41 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D891200D7 for <babel@ietf.org>; Fri, 4 Jan 2019 12:38:41 -0800 (PST)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1546634317; bh=7yITfTNeCH9MsTae+dfiYgpR5U6aULaARNjlyAT1W40=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=GP9eksrudJQ63TjSTk3mh5OzwCD0D+2gJhU0i0Ehy/5D8RH82lj8P3TNmShepEYWC v54PtBnwZtOIZ77QYW+9WuPUGVW7Ua2Zt9B/zHED5OkJQJjhA2S7LI7mtRNogNLofJ 3VN0M+v1rTLas2fniRQkkRHB87vDGYmSuOS+gl2ZXtoFRT7/hqWoTpJNa3csdzXX+W ALf+st3Fa4EKCOpkOqBD7OWEBPvDUfhZffCFOx6MApx/wujApt56LMxCRy7wPGjD/Q iKy/+vPas08XDRowRVmEDIYMg13qAahA6FVE/xqr4G7UQFxeUNTcSYAM6LB1EuTSc8 PRQ4ehYlDxXEg==
To: "STARK, BARBARA H" <bs7652@att.com>, 'Mahesh Jethanandani' <mjethanandani@gmail.com>
Cc: Babel at IETF <babel@ietf.org>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com>
Date: Fri, 04 Jan 2019 21:38:33 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <878t00yx86.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/AdCdGDDUDwQBh72NTSxNizPsTT8>
Subject: Re: [babel] hmac info model elements
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: Fri, 04 Jan 2019 20:38:43 -0000

"STARK, BARBARA H" <bs7652@att.com> writes:

>> > We had discussed previously that keys should not be readable -- only add
>> and delete keys. In this case, it's good for a non-readable parameter to have
>> a "nickname" or index to reference it with. And it can be useful to know
>> when the key was added. In my experience, these sorts of shared keys are
>> modeled as strings.
>> 
>> I would think the keys are modeled as binary.
>
> That depends on how we generally expect the keys to be generated. If
> we think they'll be randomly generated by a centralized machine, then
> binary makes sense. If we think they'll be created by a human being
> who will input them through a keyboard, then string makes sense. I was
> thinking the latter would be more common. I'm curious what others
> think?

Bird uses an unencoded string...

-Toke