Re: [babel] MAC and key size

"STARK, BARBARA H" <bs7652@att.com> Wed, 10 March 2021 20:59 UTC

Return-Path: <bs7652@att.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 F22D73A1810 for <babel@ietfa.amsl.com>; Wed, 10 Mar 2021 12:59:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 Kk6s0REqYgmP for <babel@ietfa.amsl.com>; Wed, 10 Mar 2021 12:59:12 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 4BB193A180F for <babel@ietf.org>; Wed, 10 Mar 2021 12:59:12 -0800 (PST)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 12AKrgqL048206; Wed, 10 Mar 2021 15:59:11 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 376kkvrha2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Mar 2021 15:59:10 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 12AKxAn2006320; Wed, 10 Mar 2021 15:59:10 -0500
Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 12AKx5XB006225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Mar 2021 15:59:05 -0500
Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id EAE50400B579; Wed, 10 Mar 2021 20:59:05 +0000 (GMT)
Received: from GAALPA1MSGED2CC.ITServices.sbc.com (unknown [135.50.89.134]) by zlp30483.vci.att.com (Service) with ESMTP id CC8B7400B574; Wed, 10 Mar 2021 20:59:05 +0000 (GMT)
Received: from GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) by GAALPA1MSGED2CC.ITServices.sbc.com (135.50.89.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 10 Mar 2021 15:59:05 -0500
Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2 via Frontend Transport; Wed, 10 Mar 2021 15:59:05 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.100) by edgeal1.exch.att.com (144.160.249.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2176.2; Wed, 10 Mar 2021 15:58:49 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZXEWucLT0mP1txcPcdNthlxZDT0iP4RbnhLbMMXR5adWdufBlN+OWEVlmKq8gcCOVHFfG/vmj0hAXqmX+/C6Y4P+uZanHgoTB/bgpjEH5pMNxosuQL4AHevzrFgRFGIA4FD8v6XAB5mZxrwFQdLCM8rkiX+CnI1Xyo/ZBPEba94gtISN6F71K4k6kGNi57kWmW7i3jeyppyyu+j4VfsO8nQvUK/nW/LtIiBMHkLPdKHb6YFeSFyRe03otV4j6HiMl80LqpSl96SJX3vFTWzcZtgPiXbYQ4TAYleb+fO8OUakSM8EZGtCv0dWWaq4Y5l2EkgGhFQxBlj3Jv3Xu7dILg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R93/5fMfJ1+gtpdww+vzBiztKm9bWEAgxE5JZ60ndGU=; b=Rb7frFbO+MX6K8N6bR1ljgjuGEipWR2bJWhub9lcPQWpm6RozAw75ci5++8QhhMXwtvk/QLno0Bo9ex5f6uPeg3QLLzW0klV0iLoLIOaqmFoOUeNK2U6kkc2gWqgq8IFSQrNljPz3Om9X1r/dgVAWmZq0Uzx/Lm2SlrQDVGBF5/r8gUHf8QthWZsZjKuPmLxg261jay/wHdCf8PTEYTFjL2IV+fE/nEcld+FTd0svjVRlrzSqBHmS4UHXOCNP+HeFzcHeCRAyQ+BM296o/ug+cXSo8pz9tb/66UJhl5jpOlJeF3HPrDMny5x1H6Ax+M3xthlOqDtnprTiMe0B11lKg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R93/5fMfJ1+gtpdww+vzBiztKm9bWEAgxE5JZ60ndGU=; b=xBzk/Ox5XyN5ojz7yg3aA1GQvI3izct7vo8Q+QdEJo755evVLRNTozz6ImeDmQvS3f6eDujo+BABuDM4/113l0TZpyIjRHw2jTVQ97zXWtDrlhJPFL1zgUIb+qDqRuUGMPk9Z2Rfs6jmndUsK3YdmAMXfWqzdOd7I6M7qtAp1CQ=
Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB6923.namprd02.prod.outlook.com (2603:10b6:5:25e::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19; Wed, 10 Mar 2021 20:58:45 +0000
Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d9c0:4a62:170b:b925]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d9c0:4a62:170b:b925%7]) with mapi id 15.20.3890.038; Wed, 10 Mar 2021 20:58:45 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: =?iso-8859-1?Q?=27Antonin_D=E9cimo=27?= <antonin.decimo@gmail.com>, "'Juliusz Chroboczek'" <jch@irif.fr>
CC: "'Babel at IETF'" <babel@ietf.org>
Thread-Topic: [babel] MAC and key size
Thread-Index: AQHXFPuHKjWHBF01eUWdOzHnKGzsoap77YyAgAAzLwCAAZT1MA==
Date: Wed, 10 Mar 2021 20:58:45 +0000
Message-ID: <DM6PR02MB6924FEC53CD4447EBA51F115C3919@DM6PR02MB6924.namprd02.prod.outlook.com>
References: <875z20tjmj.wl-jch@irif.fr> <CAC=54B+ZQ33ECaR+Y5+7t8+wvfO1tLDWqffXtPWgQNzBogMjVw@mail.gmail.com> <DM6PR02MB6924231BFE98976806014B6DC3929@DM6PR02MB6924.namprd02.prod.outlook.com>
In-Reply-To: <DM6PR02MB6924231BFE98976806014B6DC3929@DM6PR02MB6924.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=att.com;
x-originating-ip: [45.18.123.63]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 82a08d35-8470-4865-9b1c-08d8e4074b9c
x-ms-traffictypediagnostic: DM6PR02MB6923:
x-microsoft-antispam-prvs: <DM6PR02MB692305BB84634A612267EBECC3919@DM6PR02MB6923.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /Zgx1RRA2w7Sl2WpGRNjGqUJuFojDww5HvNTeUkI2sU4wCd9QbeLRdwI07wIqD7PoFJyOAd6jXosFwg84e7icRiz/Vnxuej8O6Y7fWx7h+fPao99WDkO6bGVumeDoTepC4XwQbqM+H6FKmGWju3Q4Ye0LiAuJ5OGYbyxUF3K+eOBwPvfAgZnphhDpHmmDI8BOGJsTVmduS1/4Q8a0bAUEaSRS9yaYAK9ejWp0+EOJ63KI+D4S1zdkb6J30jvFNqyDZUAaFFj2Iw0VqDRSpQjX2WVXU6xV+5VXLjQ7+GvnUMxWlY/mZm7g3OKnG28ugBWa2Zb2KTclzciVOhO/56reQGgxuyi0R5POjcNQNSezr0z1DRmqJ/PITCdmCptUIWxtvgX2R+Rz6yX2At2wgi5HIystJhzamb5KqvrLbuPLlXpeBXwb5P98+EoH04JjHAaaOz7CCB2q4XWjDPN8nLedCAvzDopmx2bcBVqo3w/DRS1SBb23WW5liyyUxX5FHSSv9KeF7hxnyYFHjEaLcIahg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(346002)(366004)(136003)(39860400002)(66556008)(26005)(33656002)(86362001)(76116006)(186003)(66476007)(6506007)(8936002)(110136005)(55016002)(52536014)(4326008)(82202003)(7696005)(71200400001)(5660300002)(8676002)(2906002)(83380400001)(66574015)(478600001)(9686003)(66446008)(64756008)(316002)(66946007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?LwxqG4pQ/DP1G0gMIS7CFvoTNLSru6nN0pw6E3YK5mfKaCItE15t8um61g?= =?iso-8859-1?Q?F4+4d/MGEKyebD6KQeT9E3VX20A8pVZjItYrgoIfuIMMfjztwF7miAFHO/?= =?iso-8859-1?Q?FYsEr50JIWIh08tqvIVPBI7Y4S9ZN4Z8UGmjSmjgb0ZJcB18ncbSp+ZQfD?= =?iso-8859-1?Q?QeEaqOCNoWJ0Pj9lYtaxzar3ggCzmMpFs7I5SVaBfzax9QFdRlWIEhnIPu?= =?iso-8859-1?Q?nknxh/NR6A2aPRa3SfMftx6Sc8P1IDo1Uv3bexdpySaD1YrDuISB+fNL+X?= =?iso-8859-1?Q?blK81ZgRQH9eDMfHITkRY3LkZGNkiRWIcx5nKxPjQbfzCh63g8ItLuURVF?= =?iso-8859-1?Q?OhaVj5Kr8o1hPVxpy5d95sTgohJChIBsMZ6TWYJyR3i9PrfJOmR6BjxuWa?= =?iso-8859-1?Q?1OaMOt7KWzlUF6VrdB1TgUzW4ysJx3j+bOEOMBycVf9H/qf5u84XAiSp6r?= =?iso-8859-1?Q?VOwJvmjYkqJ0ZaI02s+fM4Od+q4Xw6xydbZCpsQG+RaXpxinWnd2DQ6oc+?= =?iso-8859-1?Q?JMRSkDIaHIJBfIUPP3KdRIcfOW04444m24LiyUFyfdL+hLmsRUUHEZKmhH?= =?iso-8859-1?Q?cwYB/1yCf589RhHLKYhn2xNtrIJvNFGWO4EhCG87d/QCbgmKbDXD3JgN1F?= =?iso-8859-1?Q?yqDDNWE2zls3/6k2ZA94XVDola/7kZT26845eoFfLdqaIFW/ayyUZxM/XL?= =?iso-8859-1?Q?GwOihXw1bbBoKbb2EBRk8abOw45pQ+H8zSVz0hNuYa+fOd9G01aY5M+JLw?= =?iso-8859-1?Q?H3Un44lSgHzpFUFjMInK0lmKF4YiFGNR8RM6pUcqiz89N3POY8ZVI+Vhpt?= =?iso-8859-1?Q?Ms5Ytzb6oQcNCS/M4w/tu9/hSvhKLsoLHpNoNcby0bROh5i4HQ9vUDXohB?= =?iso-8859-1?Q?6SX6ILbd6KE46Mh1bL8EQACt2kOH+cAmYvxNt5N5qs1k5CCEfuKREdmO0z?= =?iso-8859-1?Q?AMAI6jKfcpOKTIXocl+8arWFlES7LuPBHAw70tyl5pVwf+x6CtpX0fMvoN?= =?iso-8859-1?Q?CJzAGcL7WtFEGBlu3gC7K0rqZasMMreGibgeT3WeqSwGaPDcYHDK7x9DIy?= =?iso-8859-1?Q?1waN/wQwOylbiS/BaR1OY2cEo8K3v9NDLVF149UX13sGwLND1AENGtLEf4?= =?iso-8859-1?Q?syYQmYBw3bd1hDeno6IvROl0RhP3JhpzqxSuH+4T/U3jPfIbe/rXAIa3nH?= =?iso-8859-1?Q?2+qtmIfbLPtADjbdec4bNY7gqOHQRqhlESkBxvxegGJ5222gXTtas9bLkY?= =?iso-8859-1?Q?ZY3abQOm29h7kY5+W6PFrfANBH1q3LFazxgFWCq6H2Y9OsO2SZ+rYx5ghY?= =?iso-8859-1?Q?Js5v1e8NAsH/z64cNmLx5dFLrjM1pl6ZSpfwuPdG+6gFEDfVTh3oTiAkvV?= =?iso-8859-1?Q?nlsg7ps5fm?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 82a08d35-8470-4865-9b1c-08d8e4074b9c
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2021 20:58:45.6666 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fc8N8RG0r/tQjvhCuuAIC7yUrlQkhjIPwyx7KxNSp2wSbRLaRGJpptpkGjWvhUmR
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6923
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: 8A7B81254F34D83244118AA3E908BCF1BE78C2F79BD541692CF7704ACD11ED1C2
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-10_12:2021-03-10, 2021-03-10 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 phishscore=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 priorityscore=1501 clxscore=1015 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103100100
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/-bD4M4Ot8TkeXQc1nrfgt4Xi9I4>
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: Wed, 10 Mar 2021 20:59:14 -0000

I've been pondering and have a new suggestion.

Here's what I'm thinking as a proposal for the parameter description:

This value is of a length suitable for the associated babel-mac-key-algorithm. If the algorithm is based on the HMAC construction [RFC2104], the length MUST be between 0 and an upper limit that is at least the size of the output length (where "HMAC-SHA256" output length is 32 octets as described in [RFC4868]). Longer lengths MAY be supported but are not necessary if the management system has the ability to generate a suitably random value (e.g., by randomly generating a value or by using a key derivation technique as recommended in [RFC8967] Security Considerations). If the algorithm is "BLAKE2s-128", the length MUST be between 0 and 32 bytes inclusive as specified by [RFC7693].

In the Security Considerations I propose adding, after the sentence "See the Security Considerations section of [RFC8967] for additional considerations related to MAC keys.": 

The fifth paragraph of that security Considerations section makes some specific key value recommendations that should be noted. It says that if it is necessary to derive keys from a human-readable passphrase, "only the derived keys should be communicated to the routers" and "the original passphrase itself should be kept on the host used to perform the key generation" (which would be the management system in the case of a remote management protocol). It also recommends that keys "should have a length of 32 octets (both for HMAC-SHA256 and BLAKE2s), and be chosen randomly".

I need to get an email sent to Ben today. If I hear nothing, I'll propose this to him later today.
Barbara

> > 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.
> 
> I think I'll stick with the binary datatype. That's what Juliusz had previously
> suggested (and we did discuss that). It's pretty trivial to go between hex and
> binary and to provide a UI for entering hex that then converts immediately to
> binary, if there were to be a UI. Or for the remote management code (on the
> router) to convert binary to hex before providing to a Babel implementation (if
> that were necessary). All bits are fully supported and represented in both
> datatypes.
> 
> Here's what I'm thinking as a proposal for the description:
> 
> This value is of a length suitable for the associated babel-mac-key-algorithm. If
> the algorithm is based on the HMAC construction [RFC2104], the length SHOULD
> be between 0 and the block size of the underlying hash inclusive (where "HMAC-
> SHA256" block size is 64 bytes as described in [RFC4868]) for cases where the
> management system has the ability to generate a suitably random value (e.g., by
> randomly generating a value or by using a key derivation technique as
> recommended in [RFC8967] Security Considerations). While longer values could
> be provided, they do not increase security if the value is sufficiently random. If
> the algorithm is "BLAKE2s-128", the length MUST be between 0 and 32 bytes
> inclusive, as described in [RFC7693].
> 
> Barbara