Re: [babel] MAC and key size

"STARK, BARBARA H" <bs7652@att.com> Tue, 09 March 2021 21:15 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 1503D3A0CFA for <babel@ietfa.amsl.com>; Tue, 9 Mar 2021 13:15:40 -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 d7ZJuCbnwv2H for <babel@ietfa.amsl.com>; Tue, 9 Mar 2021 13:15:38 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 0D9E83A0D00 for <babel@ietf.org>; Tue, 9 Mar 2021 13:15:30 -0800 (PST)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 129LEOqO021949; Tue, 9 Mar 2021 16:15:28 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 375s7wfcy2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 Mar 2021 16:15:28 -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 129LFQ0d023641; Tue, 9 Mar 2021 16:15:27 -0500
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 129LFKjB023455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Mar 2021 16:15:20 -0500
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id E27CA4009E69; Tue, 9 Mar 2021 21:15:20 +0000 (GMT)
Received: from GAALPA1MSGEX1DA.ITServices.sbc.com (unknown [135.50.89.114]) by zlp30487.vci.att.com (Service) with ESMTP id BD0A04009E68; Tue, 9 Mar 2021 21:15:20 +0000 (GMT)
Received: from GAALPA1MSGEX1BD.ITServices.sbc.com (135.50.89.105) by GAALPA1MSGEX1DA.ITServices.sbc.com (135.50.89.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 9 Mar 2021 16:15:02 -0500
Received: from GAALPA1MSGETA02.tmg.ad.att.com (144.160.249.124) by GAALPA1MSGEX1BD.ITServices.sbc.com (135.50.89.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2 via Frontend Transport; Tue, 9 Mar 2021 16:15:02 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.172) by edgeal2.exch.att.com (144.160.249.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2176.2; Tue, 9 Mar 2021 16:14:33 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b91xNAi0jD1ZMHfD+pafmNt534fnLYzWU6gIKMCvky4JMsRjLo1Y+Rdz9WbP0wdEluU9M3UyjvolyKM5WO21ykRrpqkahqy2RPmBQF0LV5FfPy90pr0LGdelslFAt66sHBp55ICj9mJcMR3LwAmXNGmjN3JyI2/sAaMfNKoyC7oo6in3ZQnKHW8cq+HDUZPpWRxAGrhFyfDcvCP6pryq99fyb2zAkTFRivRdZXj+RkXieMuUPO9CdIXJ+QQZvRu0aYUc9PX7CbHdR52WRERM5KGkMgWALNEjp1JCj1tJzglWyGJxH6KaH01QSdfkZLbkh+AawtZ/8slRdWSz1XpN+g==
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=caePHe0KWoDdpkQ8VvZRPr2/11dqfzbi58dcOya0yhM=; b=G6XaTZDWmWmam4uonHnikuMA0d9FYEMwvBAO9gjPoU0CYhKFE3ydo5Ur3DfV1iGDXmkhr6GXZbv2VHOI8J7k3ZNFJ1bB5xfySGUu2lMNWEgMJcXmcxMC9sez+Eu9mB3hE54ITpKo/rFfEe4JdRZj7gDUm6mXfHMcw2tKAIVxaY4gJ6x0YY1pKjTU9h860DdZKeV0awCRJIOiXG4ODinlJsac3dEWe8P9b3PZOgQ2TPJKDALh1GVzp+GD1YEBLnnLj51kngjvyNQY2MATIeMNtOzwBm0MwS8fhGpUlAsZUVXgd3R4LWONX15M2RHDUgHMF98iLCis6K12t+4CiayYFg==
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=caePHe0KWoDdpkQ8VvZRPr2/11dqfzbi58dcOya0yhM=; b=fUDwnymozYS0QT/sriWu/MgBwXp3gx7nDzClCF7IT/8l/N5EgYcrMEoKZNoZ2FWpZ2ERLaDvEcFNGo61qnudzoF5IfV0dIf1BaaZA4QNoj2TjYCvv/iyTCuZToJeI1vEUSyzAbf73XHvvdydSPcORP9ZuwinOg+vl9v/h6tIbFw=
Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM5PR02MB2475.namprd02.prod.outlook.com (2603:10b6:3:41::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.20; Tue, 9 Mar 2021 21:14:32 +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; Tue, 9 Mar 2021 21:14:32 +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: AQHXFPuHKjWHBF01eUWdOzHnKGzsoap77YyAgAAzLwA=
Date: Tue, 9 Mar 2021 21:14:32 +0000
Message-ID: <DM6PR02MB6924231BFE98976806014B6DC3929@DM6PR02MB6924.namprd02.prod.outlook.com>
References: <875z20tjmj.wl-jch@irif.fr> <CAC=54B+ZQ33ECaR+Y5+7t8+wvfO1tLDWqffXtPWgQNzBogMjVw@mail.gmail.com>
In-Reply-To: <CAC=54B+ZQ33ECaR+Y5+7t8+wvfO1tLDWqffXtPWgQNzBogMjVw@mail.gmail.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: 31cc79ab-6c0e-477e-159f-08d8e340555b
x-ms-traffictypediagnostic: DM5PR02MB2475:
x-microsoft-antispam-prvs: <DM5PR02MB24759C05D6CB6F630C00CF2DC3929@DM5PR02MB2475.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: M/zKH9jpmB6ehQvbivkd4H7aQo7yG1o37/7/YwfcIDctfXpLZ9oEv576KKoA0jp/+c2xccjykQo/bh1brCSH0Hsn6JpEWh4BfvRZoFQhX4sP2B/maqw/LNMODAyusm2NWvsrT/BHKiPzo7fUDDbs90hAGyprjT0aHl3bMMGFJL5BdpNovysPzj1DthRvABxi3eP0xUvTgZNAKP4W/LSuxlg/4DbxTq+CaxxdNmO8rI2bfm94ciJKCNIn7AHYCnAneNZz9mqYJtpkLc4XH9t/xTwBbI0UUxZmxuyjfzpVWh6TM3l9z83F4HWcHVmL3uYffeLQuuUrkeeJnZBh2XaslWdEam3iMnLBjfO5MNnUP0Fmu4cS96dwVNVjCFo9ZQTYm7TcKkTz7my8LA11f2IRfRWZ1B3RIwSlGES+4KSvwZ8Yf30p1YE2Ey5nstm6EYfmu4sCZjSSam7vPvxjJHl0w9aeXTZEmNHW0vHUXifBAIIQMAWj+c4n1muD2VpbRuw3JuUuZFUbNRBgf0B4t5d5qA==
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)(346002)(39860400002)(136003)(376002)(366004)(396003)(76116006)(66946007)(4326008)(2906002)(66446008)(66476007)(82202003)(316002)(64756008)(66556008)(8936002)(5660300002)(8676002)(83380400001)(66574015)(110136005)(55016002)(52536014)(9686003)(478600001)(86362001)(6506007)(7696005)(186003)(26005)(33656002)(71200400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?W0UhM5Qa3S2p/f7lvbYX+qv9Hw5YeWmVutQtP8GtLPgkiBubRCfutEZWZM?= =?iso-8859-1?Q?3Ls05Z+HB+MNK/dtyN020nnQhTZ3WNL2MsAlVmwSNJHTRtVYLBsryckWRg?= =?iso-8859-1?Q?9NAc6D+2za3PDCad4lYiQ2onJ+ql3GjPUVuDsmRWCX3lEisgvpvh7Jqu/z?= =?iso-8859-1?Q?yvC6YObTIFYJdchF5CA81bc9YBj5X3lVeCzLdpDCvgUf9ij8BMmDsfNUM5?= =?iso-8859-1?Q?etlKSPPCSqJ041SBBfl2ImYbIliH43sXMlFYiFWOhxwHhH7YStSY9tQMiP?= =?iso-8859-1?Q?8YHRy1R/6/W08rX3DU3+GlQEjyNWCVuQ9z0OZxtAXkA18hbcdg3LCUNYky?= =?iso-8859-1?Q?ZJ3ZU5mL5qHURajWagDkq50gPohDfoWkvQDMhg6277OYsCl6fkhMzAr8BX?= =?iso-8859-1?Q?59ZlWZ7qZyxL+YsdP0ZxT4LcNDnbOx1ZomMlGa7U7gkVGjz73UREOixo7D?= =?iso-8859-1?Q?hMpqmdhz/2ZW1QyRRNNhqF3hD5469HW2h78JdjMHl3LXeMZJI16Nbxf+sE?= =?iso-8859-1?Q?gRKo4UF5VJVTRiRqxdbDPnBIIRVsMnMxUhRjGp5EROPQjQg8YkCkCpb11t?= =?iso-8859-1?Q?Hig4qVrQ1xzUWtLtcts/tj/SkBtuYtFUDOTeUMQwZMlx+tgx4GUqRH2tEy?= =?iso-8859-1?Q?OAdQAEyI7zCmbQ53akT39oKT5mpreBaWMgrmgSp6Ah0EGj1sLwCUg2Sts8?= =?iso-8859-1?Q?l8WjUzu03CB+UQxT2E3zRLgMo247NHkRyY1X+cVGxM4VNPc5Owr6Wlk8qg?= =?iso-8859-1?Q?4+bmIgwtlkVCfPJnTyqW3AAnVtcw2qZR572uYVTpKhntqJQ4VfXnuCfcyC?= =?iso-8859-1?Q?MaEwhiNm31Rh+Kqfyb2cBmMAmSk9bI7dVjwex8f0Fe+OIl+XHxz60l9FlD?= =?iso-8859-1?Q?fpR+MGgMLg2WB6+mOC9zqs1oaKquG4fBB6IQHyjeuMkXsvpqkz05lrwcrR?= =?iso-8859-1?Q?wJS+R+xxf3Xb6FMohdMwqG59JhsKg800el13b7fAMi8NLvujOSBiz080n4?= =?iso-8859-1?Q?b6M7EWKOFOEPNwMViy8ytlPkWmEZCuqJVTSoKNPTwKt9w7+jRrTe3vpnKl?= =?iso-8859-1?Q?aL2puv2YWAiw+5jOXbWj+9Li40FdqM7aqbqEf2B4aI/vpW4/JRlvH3QL4j?= =?iso-8859-1?Q?WZ/ES7ZqEDWcidjZH4FNbd0x1wpB7bOUyvKQexSaNhTUmblElveYKEdCre?= =?iso-8859-1?Q?cZhdfqN2hzNY01MzjjQHcA5SUmlMUZMHJzzLID0Yr//o2Fu+n7leGbW8zA?= =?iso-8859-1?Q?xltJNGkbKEZB4awhgiyUbfc65UHdYYaZLF1xNLB5WHrEGOkq6OwpY3vK9U?= =?iso-8859-1?Q?+IlS/SKdX9t6p7aDxcC9emz9OAAomHr7hAIJ57NTCYjWjEA=3D?=
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: 31cc79ab-6c0e-477e-159f-08d8e340555b
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2021 21:14:32.0995 (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: ibcNO8fWMfDdKdSZ978I3k9H8t+aO46iylhRj5uHPrnR/Ug+oVPeb/7xBnfeJ6qC
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR02MB2475
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: C151B8D8B138F75D5F4484C5773987BE2C1A0DF8964A2B4CFA311CB7FE7FAE172
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-09_18:2021-03-09, 2021-03-09 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 spamscore=0 adultscore=0 priorityscore=1501 mlxscore=0 suspectscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 clxscore=1011 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103090104
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/Zevolq6zquD3MdNpEH47JdqcXjU>
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 21:15:40 -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.

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