[babel] info model: rehashing hashing

"STARK, BARBARA H" <bs7652@att.com> Tue, 02 March 2021 17:54 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 67E0A3A0888 for <babel@ietfa.amsl.com>; Tue, 2 Mar 2021 09:54:33 -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 dPLwdI-b84go for <babel@ietfa.amsl.com>; Tue, 2 Mar 2021 09:54:31 -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 EDB0F3A089C for <babel@ietf.org>; Tue, 2 Mar 2021 09:54:28 -0800 (PST)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 122HsNtH033082 for <babel@ietf.org>; Tue, 2 Mar 2021 12:54:28 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 3704kgju0y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <babel@ietf.org>; Tue, 02 Mar 2021 12:54:27 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 122HsQbJ023509 for <babel@ietf.org>; Tue, 2 Mar 2021 12:54:26 -0500
Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 122HsKc0023375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <babel@ietf.org>; Tue, 2 Mar 2021 12:54:20 -0500
Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id 2ED324030731 for <babel@ietf.org>; Tue, 2 Mar 2021 17:54:20 +0000 (GMT)
Received: from MISOUT7MSGEX2DA.ITServices.sbc.com (unknown [135.66.184.178]) by zlp27126.vci.att.com (Service) with ESMTP id 056A54030705 for <babel@ietf.org>; Tue, 2 Mar 2021 17:54:20 +0000 (GMT)
Received: from MISOUT7MSGEX2AB.ITServices.sbc.com (135.66.184.210) by MISOUT7MSGEX2DA.ITServices.sbc.com (135.66.184.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 2 Mar 2021 12:54:19 -0500
Received: from MISOUT7MSGETA01.tmg.ad.att.com (144.160.12.221) by MISOUT7MSGEX2AB.ITServices.sbc.com (135.66.184.210) 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, 2 Mar 2021 12:54:19 -0500
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.56) by edgeso1.exch.att.com (144.160.12.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2176.2; Tue, 2 Mar 2021 12:54:14 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dr+okVClUqZstVrgKSjobvnecyL2PFeZ2oZYO2nUOwO7LavVQFck1TwvuwjY1IV48O5RM9QlMebkBDqVrLxWFoKKprlxyLule0i+r6xm1kj/XEIALRIlH6B5SUCd3eRffAg8SjGW/yobzF0oVa1AJB8rx1YvvuWVExguBVgfQdpsk/thxKk8wZ3ow5+BKmbwDf1OBheO0n8Cy8+5PEz2tdclpMG4EhnJNxhuNmVJ17fVj/W70j61biSOT33sSfpKcFsinTPxOp2hrJy3KFeuLX3KVimKO/NGWEJQHbd/D2mMk+JhupOG7LfROelI0bbMW0zwuyT6t2qunAAVtF0tVQ==
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=Kk158RoNpsHHLzwHK57ch4xZ5GZQSWo1faCAJenErbg=; b=IkXS8g+VP0F6pJfUA2W7gPgrnz4KpTXvWkLA7DI7JFJPBichMeO26PW+CO6P+clKhHTt/m9nxeUbta4IbbNaXj/jtIaig+XdyOgvNP2zb9rkRhbF2zJkHR8znVy3yjZNL5/3IhytOGZQ8uQxMkMWO40BgLb2lzb+/uVqtx2O6R8Rjn3I6dJFejqLe6rRwuHT4LGHvm20EmVMwk+7ESX+JfFEY9DwYventFGOE6LrB5mzJ2Lnu9XMQ3YwPkOGbc1VdGbRJa7ZFM01tgHEvTi0Ibsa+80rzj4exyqSBaHrEzH/8EGiL7WAnWyTTdkrKYZoxWYUDmQQZ2eZVle7lE9ddw==
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=Kk158RoNpsHHLzwHK57ch4xZ5GZQSWo1faCAJenErbg=; b=NCFcr9yTVcEXASsKQ/FB7x9lcf2Bgjw/Nw9Z4duvmzuJz85eurWOA8YY1jvbSOXI9mObuBSLgcXjIDqqXPRmwt53qZM5MSlPRAXYfx7foa8LOfQGBLbIsyVCnDIoxiZ0G5eGRmagAGhzMGknT1DPZk3tUDvyCh/xamTvBoJVMTM=
Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB6906.namprd02.prod.outlook.com (2603:10b6:5:257::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.20; Tue, 2 Mar 2021 17:54:12 +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.029; Tue, 2 Mar 2021 17:54:12 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: "'babel@ietf.org'" <babel@ietf.org>
Thread-Topic: info model: rehashing hashing
Thread-Index: AdcPhfIUrBwqxAHdRK6W+FtOjtJ1ag==
Date: Tue, 02 Mar 2021 17:54:12 +0000
Message-ID: <DM6PR02MB69245CB8DA35FC044907AF94C3999@DM6PR02MB6924.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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: 7ee18602-77b5-4ef1-7a4c-08d8dda43057
x-ms-traffictypediagnostic: DM6PR02MB6906:
x-microsoft-antispam-prvs: <DM6PR02MB69067DA97DBD209D5EF57515C3999@DM6PR02MB6906.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: iyPBf8JrLp35wMV5IvsRtcrJH5EiG81gqVcCgBTiR9XSqE7Qs8Ey57u+hegbopMll5N5Ryfu25slB754MXZ6+ShpXIRb5NzQNakK94hr4SO6SEI46whHZtma+/5fpQTy24S4ANhAA6cvA3cqq8hOuroEag+6QBTw5BFu5KVFq+g8wpKtaOAwtgRjdeXsXK6fKaK2lzlfGMkcFZecjkDnM3U3Yj9bAroktSYM8vWmIb0Q/6L/c6fSobzvrnpBUH4nlBdD9ESxoOk9REbOes5dRi217Da7vquD1RwYp6KLiCxdmgoeC7vwUKwRnSKBrTCiSYu7wgOyQdO5vxD43ftAg/rUFIOO86OrKlfkQdk5nDm0Cu/6n0PHMtKYe//pr3oijlj02otByA3qDFIddVRsk9qAXhx6jbkqdyeyMJs+sG/akHVIGOO8vFfn6ap1ZxdY0zKzwjBNT1zmk8w2CLxqv1uMV2qcj1EfSY+F6UOEnsb4M8fiKovH28t5JfWQnK2tUt91Kw2qGpEMC9LDFEfMRTBcneqE+eC94hzyKfj9N2CEI7TNiAGiCUaeNSDoo3/k
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)(366004)(396003)(136003)(376002)(2906002)(66556008)(66476007)(7696005)(6506007)(66446008)(26005)(66946007)(86362001)(64756008)(6916009)(478600001)(76116006)(33656002)(316002)(186003)(82202003)(71200400001)(52536014)(8676002)(83380400001)(9686003)(30864003)(8936002)(5660300002)(55016002)(491001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: F3Ntq+xb3ngGUX52IIcqNGQDhtFsil64RyO7daVrXybHKq5kpJyygk98EcQuhAOHMwDRqFXK92X4ryF7xtx+T7zdcEoZVu8wjcxgNgxCOQdJMcbruMidUE+2Vpkbjf5ms9Fjt1sSzavwbwbcQxQuhtpYLoCrw7WtiWxEY7xgbT3QZUas+3+5B67R9MYZwBS83vMQsiDZXRoBIy52T7FQcNOsiJBqat4nLAyc/vShqRCtsOZW6RkJU+sz8OxvJmfdhGlHKhTnPo8uaa0NdYSkrroaIxft71gAjQ8iHAnAjsVrRtKmkYIXjxP1YU7WIw5cnsdAKQ8QX0Vm/hEsCtVUJj3M5Ajt0xe0zLqBtI5O0b6L9Z1suqUghRqQmfQFOEpagkpp4PHHt8HGXJWArwXTwUux1bZKijhPjSUWXG7qWkIAW5ho2uJKQKywwaZyi8vEQmgwAqYwOk0UHiWrT3XMzhJza3M7l+569OxZyDzo7CFotRFoNC8JiGwKWBhND/QcvkobmAjdOVig/953A9SO08YmFQt3XEfOFiXcEQ3eSrk/JREQj8CIkinpf31VhVk13UHXK8VZLvmgjiaxi1ZDVJh1bc+Aqq/qEGXYJHZ5PfEdmNnVIM8sMrHnQkTI1de1HBoX9grW3p5rTsNoYgByH+Or3XrPGJhpQCbzxuj9fei67KCrR6cJNnqUmzawIDjjS2mxSLmbGfutCsLzh1urQiVyjOAh5xmT3k6u8JZnFQvVmrLBT5niTAjf+IPc/ljDZbwcDAiDYo0i0ZGqq34Ne8YdZKL/0j68rxQErmuWKXRPD2KTvrh1a1C+toDPxSadwFe532fjp0eWiAaIe9gD4Swh9f3cd0sPFSfB0yZVWTMa759vr4Do79jOWeiv3fSIknKP9apm8m6Z68aNmVCkxNXUsyRa7dXu+4tsZt9WWoJdE78Or1uX3TBClGqV8g+yBtx44lM+3KtM0Jnar37lOzDBfYTRwOWXYC9BOWAonaz2hDjzA8arHd1dUPXcZCoxJhiXVAFwEp24QzL1y5letJtdbGYYATXn6vz1M/i3ackz2uJD6guNakPX7j5b882jbr6VVAMZStwfoJ0B7c8YJWmAqJzHccQWoBZnlHcbOyBiD4y4riHxDUAx/OEhRgkm/9sCJHexUD2Axk3nogU0w+ZAohwtmwavTbNXlw92Dl+5PSM7WLbFv1qophHzzyVqg7WWm8jnwq1BBXYxsLDhpkw+RIbUqnuuAWfOxa1uJK+S35xDQXhChVmInrwrJ+Iv6/7bgOMq1YGnV20wmMqs1lfHhBb+vI4e/ZpE7xu+agw=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
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: 7ee18602-77b5-4ef1-7a4c-08d8dda43057
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2021 17:54:12.7194 (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: Iy2DbKuoFPtzjdxhWOyVWZ5H6ZXq8kHCzhsRjr5tEG8Y6tBPx4SiEKTPc4z4ThMG
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6906
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: DBFB612DA15183BDFC700B5425139F27CC93110499D2317015651276285F2C772
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-02_08:2021-03-01, 2021-03-02 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxlogscore=999 priorityscore=1501 bulkscore=0 clxscore=1015 lowpriorityscore=0 suspectscore=0 adultscore=0 malwarescore=0 mlxscore=0 phishscore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103020139
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/gIMJgo48bBqZrsQSmyHYmgPCzUQ>
Subject: [babel] info model: rehashing hashing
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, 02 Mar 2021 17:54:33 -0000

Hi Babel,
The WG had 2 extensive discussions around configuring keys for MAC algorithms. First in January 2019 and then in August 2019. The language in the info-model draft reflects the consensus we reached after the August 2019 discussion:

   babel-mac-key-value:  ...  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 the block size of the
      underlying hash inclusive (where "HMAC-SHA256" block size is 64
      bytes as described in [RFC4868]).  If the algorithm is "BLAKE2s-
      128", the length MUST be between 0 and 32 bytes inclusive, as
      described in [RFC7693].

Ben Kaduk is pushing back on this. I've included our conversation, at the bottom. 4 "> > > >" or  a single ">" precede my comments and nothing, 2 "> >", or 5 "> > > > >" precede Ben's. But to summarize the comment that concerns me most, he says the restriction on keys for HMAC-based algorithms to be less than the block size will not be short enough to avoid the problem we saw with the Bird implementation using OSPF code (which calculates the cryptographic key for long "Authentication Key" per OSPF RFC 5709 and not HMAC RFC 2104).

Here is that specific part of the conversation:
-------------------------------------
> The Bird (language) implementation of Babel used existing code for OSPF. That code was designed according to RFC 5709, which will hash any "Authentication Key" (K) longer than the length of the hash (L) to create a cryptographic key (Ko) that is exactly L octets long.
> 
> What RFC 5709 describes is different than what RFC 2104 (HMAC) describes. RFC 2104 says to create a hash of the authentication key (K) if it is longer than the block size of the hashing algorithm (B). For SHA-256, B != L. Therefore, using RFC 5709 will get a different value for the cryptographic key than RFC 2104, for authentication key length between L and B. This difference was noted in RFC5709 errata. RFC 7166 updated RFC 6506 wrt this. But RFC 7166 didn't update RFC 5709.  RFC 7474 updated RFC 5709 and kept the L boundary. We looked at the Bird library code which does indeed do the calculation according to RFC 5709. Fortunately, there is great consistency among the various RFCs around zero-padding short authentication keys.
> 
> Furthermore, the Bird implementation allowed the key to be provided via a GUI that treated the input sequence of characters as ASCII. This was, again, from code that already existed for OSPF. But note there is no requirement in any RFC for support of an authentication key entered in ASCII format.

Thanks; this is really helpful information to know (and pretty unfortunate
about the OSPF situation).
But if issues with how an existing Babel implementation handles input keys
longer than the output length of the hash are what motivate the key length
restrictions, shouldn't the length restrictions reflect the hash output
length rather than the hash block size?
-------------------------------------

Does the parameter description have the right length limits? Please help! Thx,
Barbara

====================== entire conversation with Ben ==================================
> > > > > Similarly (as Roman notes), we are putting requirements on the key
> > > > > length for MAC keys (relative to the block size of the underlying hash
> > > > > function) that have were once present in draft-ietf-babel-hmac but have
> > > > > been removed as of draft-ietf-babel-hmac-10.  I assume that the intent
> > > > > is not to impose additional restrictions compared to the protocol spec,
> > > > > thus we need to catch up to those changes.
> > > >
> > > > How humans interact with configuration parameters presented through
> > > > a data model instantiation of this information model is a concern. Having
> > > > experienced the horrors of the days of configuring WEP keys (which were
> > > > either ASCII or hex and caused most people not to use WEP with Wi-Fi)
> > > > and witnessed (and been party to) the discussions in
> > > > Babel where we wanted to ensure that whatever string was inputted for
> > > > the key would yield consistent MAC computation across all implementations
> > > > (i.e.,
> > > > would yield consistent "actual key"), I believe
> > > > it is imperative for the information model to constrain the input. As I
> > explained
> > > > in my response to Roman and Valery, we saw considerable variability in
> > > > how existing libraries for allowing users to supply a key value treated
> > > > values that could not be directly used as what RFC 2104 calls "the actual
> > key".
> > > > To ensure human users are successful in supplying the same "actual key"
> > value
> > > > to various
> > > > implementations, it's necessary for user interfaces to restrict what is
> > > > supplied to be "the actual key" so no extraneous hashing and processing
> > > > is needed to generate "the actual key" (other than adding zeroes if the input
> > > > key is shorter than an "actual key").
> > 
> > These are all important considerations, and I am glad that you are keeping
> > them in mind (while simultaneously being sad that they are necessary).
> > But they seem to mostly be concers with the translation layer between the
> > input layer and the cryptographic API, and the restrictions that I am
> > concerned about are ones that relate to processing done within the
> > cryptographic API boundary.
> 
> I find this statement a little confusing, since the info model is placing no restrictions on processing done within a cryptographic API boundary. It's only placing restrictions on the length and datatype of a parameter (supplied via a management protocol or user interface) that is then provided to a Babel implementation. What the Babel implementation does to or with this parameter is not something the info model cares about.

Well, my reasoning is basically that the information model is imposing a
limitation on the inputs to the cryptographic API that is more stringent
then the documented requirements for that API.  The only vaguely plausible
reason that I know of that one might want to impose this specific
requirement is to affect the internal processing of that API (to avoid the
extra "hash the key input" step).  So, picking this specific limit on the
input to the cryptographic API comes across as attempting to force a
specific behavior path within the cryptographic API.

IMO, if you are going to use HMAC, use the HMAC interface as documented and
let HMAC determine which of its internal paths to take.  If you need to
impose some restriction on the inputs, do so for reasons related to
processing at the application layer (including, potentially, existing
implementations that do the wrong thing) and document it as such.

> > > > The restrictions provided for the length of an input key are consistent with
> > > > what the HMAC and BLAKE RFCs indicate for "actual key" length.
> > > >
> > > > This allows implementations of draft-ietf-babel-hmac to use existing HMAC
> > > > and BLAKE2s libraries without worrying about what inconsistent
> > manipulations
> > > > the libraries or associated libraries for inputting keys do to strings that are
> > > > too long to be directly used as "actual keys".
> > 
> > In particular, the procedures for using an HMAC key longer than the block
> > length of the underlying hash function (hash the key first) are
> > longstanding and well-implemented.  Are you saying that you have
> > experiences with buggy HMAC implementations that don't do this?  (If so,
> > that would be a great tidbit to mention in the document as motivation.)
> 
> The Bird (language) implementation of Babel used existing code for OSPF. That code was designed according to RFC 5709, which will hash any "Authentication Key" (K) longer than the length of the hash (L) to create a cryptographic key (Ko) that is exactly L octets long.
> 
> What RFC 5709 describes is different than what RFC 2104 (HMAC) describes. RFC 2104 says to create a hash of the authentication key (K) if it is longer than the block size of the hashing algorithm (B). For SHA-256, B != L. Therefore, using RFC 5709 will get a different value for the cryptographic key than RFC 2104, for authentication key length between L and B. This difference was noted in RFC5709 errata. RFC 7166 updated RFC 6506 wrt this. But RFC 7166 didn't update RFC 5709.  RFC 7474 updated RFC 5709 and kept the L boundary. We looked at the Bird library code which does indeed do the calculation according to RFC 5709. Fortunately, there is great consistency among the various RFCs around zero-padding short authentication keys.
> 
> Furthermore, the Bird implementation allowed the key to be provided via a GUI that treated the input sequence of characters as ASCII. This was, again, from code that already existed for OSPF. But note there is no requirement in any RFC for support of an authentication key entered in ASCII format.

Thanks; this is really helpful information to know (and pretty unfortunate
about the OSPF situation).
But if issues with how an existing Babel implementation handles input keys
longer than the output length of the hash are what motivate the key length
restrictions, shouldn't the length restrictions reflect the hash output
length rather than the hash block size?

> The C implementation of Babel was designed with the expectation that a centralized system would push the key out to all the routers. It assumed the supplied key was in binary format. Preferably, the centralized system would randomly generate the binary value. But if there were a user entering an ASCII string at the centralized system, the centralized system would be able to do whatever desired manipulation and push a suitable binary out to all routers. The C implementation does not accept ASCII input.

(I assume that "does not accept ASCII input" just means "does not do
processing on input to take a human-presentable ASCII representation of a
binary key and convert it into the underlying binary key", as opposed to
"checks for the condition where all octets of the input are in the ASCII
printable range and rejects that input".)

> The WG discussed all of this extensively in January of 2019. And then re-hashed it (haha) in August of 2019. There was discussion of imposing either RFC 5709 or RFC 2104 calculation for long "authentication keys" on the Babel implementations (in the babel-mac draft). There was discussion of requiring the key supplied to an implementation to be exactly the cryptographic key (so all manipulation was done external to Babel). And other ideas (I can point to the emails in the archive, if you like; there were many emails). The August 2019 decision was for the babel-mac draft not to impose additional restrictions on the format of provided keys (other than restrictions imposed by SHA-256 and BLAKE2s RFCs on keys) and not to choose between RFC 5709 or RFC 2104. So the Bird and C implementations did not need to change what they were doing. But the info model would restrict the length and datatype of "authentication key" values it supplied so the cryptographic keys the implementations ended up calculating from the input binary authentication key would always be the same. The values supplied by the info model will simply never invoke code that would result in inconsistent cryptographic key values.

Thank you very much for the summary of the prior WG discussions; I cannot
hope to try to repeat the depth of consideration that was already given.
As above, though, my reading of the -13 is that it does allow hitting the
code that would result in inconsistent key values, since the stated limit
for HMAC-SHA256 is 64 bytes, not 32.

> > The situation for Blake2s-128 (which is being used directly and not via
> > HMAC) is not quite so clear to me since it's a more recent innovation, and
> > RFC 7693 seems rather unclear about what to do if the input key is larger
> > than 64 bytes (it talks only of padding the key and setting as d[0], where
> > d[0] is a 16-word block, and for Blake2s words are 32 bits).  So while
> > limiting the length of the Blake2s key may be justified in fact, (1) that
> > justification should probably be in the document, and (2) I don't see a
> > factual basis for limiting HMAC keys to the block length.
> 
> And we also could find nothing that described what to do for long keys in BLAKE2s. So the datatype and length restriction would again ensure consistent cryptographic key calculation.

I would strongly encourage adding some discussion of the motivation for the
length limits into the draft itself.

> > (For what it's worth I did do a bit of math, and even if the "actual key"
> > is limited to uppercase letters plus digits, a 64-character string can
> > still contain some 330 bits of entropy, which is stronger than a 32-byte
> > random string.  You'd have to be really limited in what characters can be
> > used, e.g., to only digits, in order to have the maximum theoretical
> > entropy of the 64-character string fall below 256 bits.)

If the limit is actually going to be 32 characters, the numbers go down
accordingly, but 165 bits is not shabby, and adding in lowercase letters
gets you up to 190 bits, and the full 95 ASCII printables cap out at 210
bits.