Re: [babel] MAC and key size

Antonin Décimo <antonin.decimo@gmail.com> Tue, 09 March 2021 17:44 UTC

Return-Path: <antonin.decimo@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 1633F3A1176 for <babel@ietfa.amsl.com>; Tue, 9 Mar 2021 09:44:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 IojOBlDvGYEL for <babel@ietfa.amsl.com>; Tue, 9 Mar 2021 09:44:00 -0800 (PST)
Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 9B1A33A111E for <babel@ietf.org>; Tue, 9 Mar 2021 09:44:00 -0800 (PST)
Received: by mail-oo1-xc35.google.com with SMTP id h38so3235271ooi.8 for <babel@ietf.org>; Tue, 09 Mar 2021 09:44:00 -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; bh=EDcwicxRWr65sHcmd3Ji0umW7x0w/eXLyMBpsbbee1Y=; b=W1MZVg+iWg2e/MrBHhH/Uwm3NCxlUyybwFvTCyrEOTAN7AIUc74tOgxiwehtplc4YB qcYVnPOQcedjmKAk7VscvNA3dfEWvEQc9PvrBXrUjznSGTqPw4FRhKSbnGypZgzw+QnQ tSnAEVPiD67VYWSqLXZJR1CC9UwBJI9aJ+HRC4Uwi7Lp75BjGqG0oVoOKaGcDt0mrRCm GpcZJrLkc/+c68FZC2Rv5k5VRs860aUpN2fN8bxuH2SgQfQVVCTcIuaxnY/pboezqzQV FF0rfsY/PYyUnnP5ZytlopA4U6V70JMXU6buIb73okgWfLbb56y44FJvSpKsOZUVGikT iECw==
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; bh=EDcwicxRWr65sHcmd3Ji0umW7x0w/eXLyMBpsbbee1Y=; b=sD/X88mmyI67xBwofvslMPaUhMoBGQo5Ah126P8/W0fHoArbs7uYx84YteHOw7m6Md 84JLrJakLtjykwXSEVVXAItbzqqIeuvBWAjmdOq29I2Ys21pQ4qlcDtSfkontNsvlkNG 6VjWQZHOpbkntm2Qs2nY86jpOnF8ZqnPKs1pPUamQdAHjDbH6JPa/LYgHJ+x2LR9K0Z0 vkJFRLRV26AI9zKvL9DcMt0DHdIJDnTL6p7pYBi2IiQTO26q15pUe3xqzq6+XhVWlwgt f42jykoPE5fURtplQ/e5YNA6fFdipHuPVx9VrfeGtO3tzdUcnGc5A/fbGvvCDHuSOifE U7NQ==
X-Gm-Message-State: AOAM530tMO0INPvuV3qMiyhlMs5YoL3E8KwReSpcZf53N8Ig2adInWzr O4qjUpSLfmdwdBN0Xwd1IecR39Plm84hodPVi34svVHTGJ8=
X-Google-Smtp-Source: ABdhPJwEAzG3wUctbPXXPNjgm/8cfR3LRyLDGSZ9R6WkeBeQko8osyS60yIVSd2Syrqa1ysEJm0kdJqFMzlMjWYpsps=
X-Received: by 2002:a4a:858c:: with SMTP id t12mr23264500ooh.20.1615311838498; Tue, 09 Mar 2021 09:43:58 -0800 (PST)
MIME-Version: 1.0
References: <875z20tjmj.wl-jch@irif.fr>
In-Reply-To: <875z20tjmj.wl-jch@irif.fr>
From: =?UTF-8?Q?Antonin_D=C3=A9cimo?= <antonin.decimo@gmail.com>
Date: Tue, 9 Mar 2021 18:43:47 +0100
Message-ID: <CAC=54B+ZQ33ECaR+Y5+7t8+wvfO1tLDWqffXtPWgQNzBogMjVw@mail.gmail.com>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: Babel at IETF <babel@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/ssR0EGhJD2rCXa5Irn5wX4HgjHY>
Subject: Re: [babel] MAC and key size
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: Tue, 09 Mar 2021 17:44:02 -0000

There is indeed confusion in OSPF RFCs about the upper bound for the
key in HMAC after which to start hashing. RFC 4634, 6234, Wikipedia,
Bird (quoting Toke), and babeld use the block size. Babel-MAC links to
RFC 6234. We are safe from that issue.

> HMAC is defined using two keys:
> - K' = H(K)  if |K| > block size

HMAC and blake2s are slightly different, in particular blake2s
*limits* the maximum size of the key and doesn't pre-hash it.

> Ben wants it to be K, while I would prefer it to be K', and any
> hashing should be done before the key is inserted into the
> management interface.

Note that reference implementations of hash algorithms take K as
parameter. But there's not much to worry about: for hmac-sha256 it
doesn't matter whether they are pre-hashed or not because of the HMAC
construct, and for blake2s it doesn't matter because the key isn't
hashed (and a pad is trivial).

I expect the user to be a bit confused to see the hashed key. If the
management delivers the hashed key, it also means that the key
derivation function is in the management interface. That would
simplify a bit a Babel implementation.

> the key SHOULD be no larger than the underlying hash's block size,

For blake2s the key cannot be larger than half the hash's block size.

I'd be in favor of using the limits enforced by the hashing algorithm
if they exist (the case of blake2s). If they don't, then use this
SHOULD, although for hmac-sha256 we've already accepted that keys
longer than 32 bytes (half the hash's block size) give no additional
security. But does it really matter, as HMAC already handles
arbitrary-sized keys?

> it SHOULD be at least the digest size

Seems like a good recommendation, but I think we're just guessing here.


What matters most and where we had troubles was the digest size to
use: it can be configured with blake2s, or generally the output can be
truncated. Implementations using the same hashing algorithm must agree
on a digest size beforehand, or verifying the signature of a packet
simply will fail (and you don't want to check if digests are prefixes
of each other). We are safe from that issue in Babel-MAC.


Regarding the input format of a key, I've seen a mail exchange that
flew a bit over my head, but remember that a key is just a big number,
and we're looking for a practical symbolic representation of that
number. An hexadecimal string seems to me the easiest human and
machine wise. I don't see babeld accepting a raw binary sequence as a
key (but I could be wrong).

Currently in babeld I enforce 32 bytes keys for both hmac-sha256 and
blake2s, but that could be relaxed. Babeld only understands
hexadecimal strings.

-- Antonin