From nobody Wed Mar 10 16:01:28 2021 Return-Path: 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 8035F3A1078; Wed, 10 Mar 2021 16:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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, URIBL_BLOCKED=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 z_5L8xflIksZ; Wed, 10 Mar 2021 16:01:18 -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 404803A1073; Wed, 10 Mar 2021 16:01:18 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 12ANtJY2036616; Wed, 10 Mar 2021 19:01:17 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 376h3bwgqh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Mar 2021 19:01:16 -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 12B01G1l025885; Wed, 10 Mar 2021 19:01:16 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 12B01Cpl025771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Mar 2021 19:01:12 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 22DB94009E62; Thu, 11 Mar 2021 00:01:12 +0000 (GMT) Received: from GAALPA1MSGEX1CE.ITServices.sbc.com (unknown [135.50.89.112]) by zlp30488.vci.att.com (Service) with ESMTP id E81D54009E61; Thu, 11 Mar 2021 00:01:11 +0000 (GMT) Received: from GAALPA1MSGEX1CE.ITServices.sbc.com (135.50.89.112) by GAALPA1MSGEX1CE.ITServices.sbc.com (135.50.89.112) 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 19:01:11 -0500 Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1CE.ITServices.sbc.com (135.50.89.112) 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 19:01:11 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.171) 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 19:00:44 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZzHOduaGgGEiS55ountRHQLmsWF/rgdtskMF3aBvx8FFLGqhHzwZtezrhglz8Js3aUbDBZnRUPb+lfZCxxGIIunUH5Jz0U4WlyNKJJ9JP9RL2DY4pb3eUg9YuSsD0dPhJERCNk4Of8jjk8N/ohq9tC7pwjkgjncFGTfgmGdolFfA8wS2PPg3PGgtkCykxgZICCf2imZCzEsPovSRiTbhajFIC50C6oxOUGmxy8BUnOPKPz0N/rWrqzq07tdCa/FqCyU/iqB46E9ldySJap+vwYhueA46+T3i0XWFHkNc9/tRF19rivKRgsQsE5ghAIR1qzfNN5zPQQCtRsmSjTW19g== 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=wNoEwbiMfOS4tI0E+eJyYB0kTAUPJ3kNxK6y+HanC+A=; b=KnrOIjTnM1QmHHR7WBtAZUrkZ1AtDlpiciPeMumVtZgCcx30PnySLxc0meS4bqOOHKBgdrgGS7epeQjjBeJsH0VIWSN0CMpwA+R8j0+5s+c7o07A4I3NzCrbb/BJSTqilQj8cVHcJMli099Hkr2jYtG2kWN6y7QWTQJH7fv4vUxGhXzEKZIN6tYxvt/bNfStdIal+XZKBKqHvVtq2VkXpc0NC1Zf8iaiKUhxeWiz91MbrnyExtAr7r9M3a0+wPDhlWNXsDRdRaZ5Wohi217y19fmWt8BzzaPxnBQoDL+n1L5zU+OQ3CoULLN1mo1yFLOM+mtWja23xW0pzf7PrB8OA== 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=wNoEwbiMfOS4tI0E+eJyYB0kTAUPJ3kNxK6y+HanC+A=; b=CB/zKL/zR3bFOpMmreWMLQicyEbiaoZJ5z6ixk6G6yoMHrglFnpKSHpgwAE0o+56ykUQUmPl8iVyWu4agT0oZR6H7+0DB3+3iesobHJh/LVT7lzqyrxuSfxESHSmioKGDo+0dGbB7Ok3V6XMO22FKKDF4m+o8oS2mbwJ8bG4GzA= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB6378.namprd02.prod.outlook.com (2603:10b6:5:1fc::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17; Thu, 11 Mar 2021 00:00:41 +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; Thu, 11 Mar 2021 00:00:41 +0000 From: "STARK, BARBARA H" To: "'Benjamin Kaduk'" CC: "'babel-chairs@ietf.org'" , "'d3e3e3@gmail.com'" , "'The IESG'" , "'babel@ietf.org'" , "'draft-ietf-babel-information-model@ietf.org'" Thread-Topic: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-information-model-11: (with DISCUSS and COMMENT) Thread-Index: AQHWsXWjpHz8bjw21kuCQu2IvFzP6am4p/pggI6+9zCACT03AIABlDYwgBlk4oCAEXGNEIABjMOAgAATegA= Date: Thu, 11 Mar 2021 00:00:41 +0000 Message-ID: References: <160436211925.31069.7931310164710901437@ietfa.amsl.com> <20210209164932.GU21@kduck.mit.edu> <20210226204349.GA21@kduck.mit.edu> <20210310224643.GG56617@kduck.mit.edu> In-Reply-To: <20210310224643.GG56617@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; 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: c1209f51-5460-4899-d851-08d8e420b624 x-ms-traffictypediagnostic: DM6PR02MB6378: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PHL28kyfolCAfnGPsxPC8xrnh23mRsexEKBnat1xLjXozWnC5jvcjXEQg/tlna3oUN96YGM5eBlyilQT30Ua0TctuQkYl+VtxLH1suQQ2XxICX2WguQ++ttovrd3cGdwZXaY9UowqcFkIuB9evN+AudW0tvJSjyqn/FWiHtPGrbf5Oq51kc5meqn9sYFF4PtYFkBcMSss0JdCi+0349lfBcagBYNuLL0zw0eKTCzhexUUQDZlS+lMeYjXWWEPYN2t+nyT8jwB6VAOeTFHjABdH3Ai7fTteYaoRuYc3pM7M47PiS8Amh3Q+z/y5k2eW2XjkmPcWghikzDpOu593rylVgjd8rRSNZJpSjMe8WyI9iDAi5NYdt/nsSbn/KyGLaHhQVKKJaI8nKkEckY1jblpIj4SkOxksACfZ3ZCKmpNjarTxHlOZvk9ZD5aEFaErBszi4XTMigWaNfSHE7LMzfbmGZ1E5+zBaI8sBoEkVjUBqmjvH7D7HKf9xGgH+4ThgrSm+MRKgqa2QbS2NErGD/pturYzvhd3G3Ac/oHRkwQRxR8pI0yDzlX95JDtRyh7KDsHdSBcWqZncxJbEYmUZVyxtPUDP1goh/kjkv6ytpBpI= 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)(346002)(39860400002)(396003)(366004)(136003)(52536014)(6506007)(8936002)(76116006)(26005)(2906002)(5660300002)(83380400001)(55016002)(9686003)(6916009)(966005)(7696005)(186003)(86362001)(71200400001)(66574015)(33656002)(478600001)(82202003)(66446008)(8676002)(66556008)(4326008)(66476007)(54906003)(30864003)(66946007)(316002)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?3uu+pDrgwD0e1EVxKx/AgVFEwnWpSi9YQKlKLhsPasV1haDXn/khQmzmKwI8?= =?us-ascii?Q?e1gr6la4xJGpj1OWR5BpN6L0jyMb24wOSARc7qzWJIbmS7tvmZ0/GckKkFRm?= =?us-ascii?Q?RKbeK8+khlpq8fr9PdNZf2TNYXbiwvndWXct7fYNpYvrbg+zDeHpBGph/nRW?= =?us-ascii?Q?z2KazFYPPhpHC6weNUFkDsPxCE5K4l8Iwv8KtX/Cla+WX37u61Y/SAiPew1D?= =?us-ascii?Q?izs/rinGDlu3e2P3JHlWKDITtosq5uiPrlr6tamVs5j9s6gAT0853l5XC/br?= =?us-ascii?Q?EqAJ65VrWXispOER1w35DnEsxj9B29LcBAF8/igT2X5CiBnnIz2BtypbH9JU?= =?us-ascii?Q?XaRlZqPRT5wIJUbCHVJgscmPQW3KjwjahO8uyYbR/IIfzCgiucDBI4ei/W7p?= =?us-ascii?Q?RMLPLkU7+90T4YPWm//OfniB0k9XBDLz/MmMKkBqG90WJGoGXmkAFSTdU3an?= =?us-ascii?Q?SUFapHljIS/jBL0npCTSwWZqYXfu46F+C7OUeFcN4YI/fI+dUEicGDo1Hwyr?= =?us-ascii?Q?nXa6CGUSheqReqvbHnJy8Xp1GvjqOmdpNr5r8LebJLyOPRSlcompAupsM337?= =?us-ascii?Q?kjwkPGVgw1a6DtlNc/ueAYQqtB7Lcgh4N8opnhJsOOlYo2sYB+iDkWo/aMS/?= =?us-ascii?Q?oTdC5D6XYpdgaf50rGY3K9sdI5xBv6EK9FygXg+hOuPjJlvd1GzcTGaH4wU+?= =?us-ascii?Q?YNCj4WAe38smxu7hVwdDWnlJQtLccr4VOItKOemH1O/Tgb8XPUnvFe7e5wgY?= =?us-ascii?Q?fSetSCguAY5Wnzmr/X2Zotn4WtnSn+xKcRUMS55LCEIYb7xnFz96IqsRjaNa?= =?us-ascii?Q?S1QhWVFqmus8tZkm5PItA6e45ZzoM5CGrbOEDOoX4nczpEZO5oJZsRADZUhW?= =?us-ascii?Q?TmH+sQODB+EaeYnd54bsKHHZG3EVBqHwHYnmOCeDxPoslEPccfnKatkasdVG?= =?us-ascii?Q?qDBZGt45FUPLMPXyzPKxnAFnosprppFUziqBniLobcO96aRIusVMnAxqz5O4?= =?us-ascii?Q?rivNvAMO4ZIz3PxdzJex9/XicoTv1ot+g/eyV6BgAtP5RIdSvYSt3Sl2re4j?= =?us-ascii?Q?Dwn2+vL9GkJrSU5y3sCKNNVoqLakoVKRWXa0dZjGOW3TQVKRTglvrgatcLxn?= =?us-ascii?Q?1/QrImHBfNAqbaWGdQz8gT1Vfo6uTgmB4oKdTRPpdzCG0NA0egYWbzS3o2r6?= =?us-ascii?Q?NvKlxc87p0ERozyNcNYs6GlUQwjXXuXmI/QnZq449n6G4SSmnyia9sHLvUqz?= =?us-ascii?Q?iE0TfUsYav8dJ1JHn2g1uTRNzKKICNP6cDcTvCnIu5Egr3EcNmEEc8+JRwkc?= =?us-ascii?Q?7boYwatgvcobeGTbLxG/+mw9?= 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: c1209f51-5460-4899-d851-08d8e420b624 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2021 00:00:41.6689 (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: 4uiBa8rUx8HpoF7D3H0T1KtTDwYdkK8nXhY7xffONkm+Y6aTGKPkuXYpT7rM56fh X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6378 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 6D5CE4288677B92983110CD72213D91F83B2B883C705551A210FC184AFDF02032 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-10_13:2021-03-10, 2021-03-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 adultscore=0 mlxlogscore=999 lowpriorityscore=0 bulkscore=0 mlxscore=0 clxscore=1015 suspectscore=0 phishscore=0 impostorscore=0 priorityscore=1501 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103100116 Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-information-model-11: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 00:01:22 -0000 Hi Ben, Thx. Reply below... Barbara > Hi Barbara, >=20 > Thanks for following up. I feel a little bad that I forgot this topic wa= s > still open, and didn't even look at the babel agenda while deciding what > session to attend for that timeslot... (inline) >=20 > On Wed, Mar 10, 2021 at 10:12:20PM +0000, STARK, BARBARA H wrote: > > Hi Ben, > > I'm cutting to just the one open issue. The WG discussed this today dur= ing its > meeting, and we've exchanged some emails. It turns out some things have > changed in the past year (and some haven't). My comment / suggested text = is at > the bottom of this email. Thx, > > Barbara > > > > > > > I think the -12 addresses most of my concerns, but we may need to= talk a > > > > > bit more about the HMAC key length topic -- I'm having a hard tim= e > matching > > > > > the stated justification with my understanding of the facts. > > > > > > > > > > > > > > > > > > > > -----------------------------------------------------------= ----------- > > > > > > > > DISCUSS: > > > > > > > > -----------------------------------------------------------= ----------- > > > > > > > > > > > > > > > > Section 2 says that the "DTLS certificate values" are requi= red to > return > > > > > > > > no value when read, but this property seems to be intended = for > private > > > > > > > > data such as DTLS private key values, not the certificates > themselves > > > > > > > > (which are public). > > > > > > > > > > > > > > Thanks. I agree and suggest in Section 2, changing "DTLS cert= ificate > > > values" > > > > > to > > > > > > > "DTLS private keys" (which are required to return no value wh= en > read). > > > > > > > > > > > > > > > While I appreciate that IPv6 is the current version of the = internet > > > > > > > > protocol, I do see that 6126bis allows for Babel to run ove= r both > IPv6 > > > > > > > > and IPv4, yet this document in multiple places implicitly a= ssumes > that > > > > > > > > Babel runs over IPv6, to the exclusion of IPv4. Such a res= triction > from > > > > > > > > the core protocol spec should only be undertaken by an info= rmation > > > model > > > > > > > > with clear reasoning and loud disclaimer. > > > > > > > > > > > > > > The WG did discuss this and expressed the view that they were= only > > > > > interested > > > > > > > in defining configuration for Babel over IPv6. Note that use = of Babel > to > > > > > > > configure > > > > > > > IPv4 routing tables can be done over IPv6. > > > > > > > > > > > > > > Perhaps if we added to the Abstract > > provide > > > > > > > suggested changes>: > > > > > > > "This information model only includes parameters and paramete= r > values > > > > > > > useful for managing Babel over IPv6. > > > > > > > This model has no parameters or values specific to operating = Babel > > > > > > > over IPv4, although Babel can be operated over IPv4. > > > > > > > Note that Babel over IPv6 can be used for configuration of bo= th > > > > > > > IPv4 and IPv6 routes." > > > > > > > > > > > > > > and then expand on this in the Introduction with > > > > > > > "This information model only includes parameters and paramete= r > values > > > > > > > useful for managing Babel over IPv6. > > > > > > > This model has no parameters or values specific to operating = Babel > > > > > > > over IPv4, even though [ID.ietf-babel-rfc6126bis] does define= a > multicast > > > > > > > group for sending and listening to multicast announcements on= IPv4. > > > > > > > There is less likelihood of breakage due to > > > > > > > inconsistent configuration and increased implementation simpl= icity > > > > > > > if Babel is operated always and only over IPv6. Running Babel= over > IPv6 > > > > > > > requires IPv6 at the link layer and does not need advertised = prefixes, > > > router > > > > > > > advertisements or DHCPv6 to be present in the network. Link-l= ocal > IPv6 is > > > > > widely > > > > > > > supported among devices where Babel is expected to be used. > > > > > > > Note that Babel over IPv6 can be used for configuration of bo= th > > > > > > > IPv4 and IPv6 routes." > > > > > > > > > > > > > > > Similarly (as Roman notes), we are putting requirements on = the key > > > > > > > > length for MAC keys (relative to the block size of the unde= rlying > hash > > > > > > > > function) that have were once present in draft-ietf-babel-h= mac 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 pr= otocol > 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 con= cern. > 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 wit= h Wi- > Fi) > > > > > > > and witnessed (and been party to) the discussions in > > > > > > > Babel where we wanted to ensure that whatever string was inpu= tted > 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 i= nput. As I > > > > > explained > > > > > > > in my response to Roman and Valery, we saw considerable varia= bility > in > > > > > > > how existing libraries for allowing users to supply a key val= ue 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 "a= ctual > key" > > > > > value > > > > > > > to various > > > > > > > implementations, it's necessary for user interfaces to restri= ct what is > > > > > > > supplied to be "the actual key" so no extraneous hashing and > processing > > > > > > > is needed to generate "the actual key" (other than adding zer= oes if > the > > > input > > > > > > > key is shorter than an "actual key"). > > > > > > > > > > These are all important considerations, and I am glad that you ar= e > keeping > > > > > them in mind (while simultaneously being sad that they are necess= ary). > > > > > But they seem to mostly be concers with the translation layer bet= ween > the > > > > > input layer and the cryptographic API, and the restrictions that = I am > > > > > concerned about are ones that relate to processing done within th= e > > > > > cryptographic API boundary. > > > > > > > > I find this statement a little confusing, since the info model is p= lacing no > > > restrictions on processing done within a cryptographic API boundary. = It's only > > > placing restrictions on the length and datatype of a parameter (suppl= ied via a > > > management protocol or user interface) that is then provided to a Bab= el > > > 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 imposin= g a > > > limitation on the inputs to the cryptographic API that is more string= ent > > > then the documented requirements for that API. The only vaguely plau= sible > > > reason that I know of that one might want to impose this specific > > > requirement is to affect the internal processing of that API (to avoi= d 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 document= ed > 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 e= xisting > > > HMAC > > > > > > > and BLAKE2s libraries without worrying about what inconsisten= t > > > > > manipulations > > > > > > > the libraries or associated libraries for inputting keys do t= o strings that > > > are > > > > > > > too long to be directly used as "actual keys". > > > > > > > > > > In particular, the procedures for using an HMAC key longer than t= he 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 motiva= tion.) > > > > > > > > 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 cryptogra= phic 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 !=3D L. T= herefore, > using > > > RFC 5709 will get a different value for the cryptographic key than RF= C 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 variou= s 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 require= ment in > any > > > RFC for support of an authentication key entered in ASCII format. > > > > > > Thanks; this is really helpful information to know (and pretty unfort= unate > > > 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 l= ength > > > restrictions, shouldn't the length restrictions reflect the hash outp= ut > > > length rather than the hash block size? > > > > > > > The C implementation of Babel was designed with the expectation tha= t a > > > centralized system would push the key out to all the routers. It assu= med 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 abl= e to do > > > whatever desired manipulation and push a suitable binary out to all r= outers. > 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 AS= CII > > > printable range and rejects that input".) > > > > > > > The WG discussed all of this extensively in January of 2019. And th= en 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 req= uiring > 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 poin= t to the > > > emails in the archive, if you like; there were many emails). The Augu= st 2019 > > > decision was for the babel-mac draft not to impose additional restric= tions on > the > > > format of provided keys (other than restrictions imposed by SHA-256 a= nd > > > 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 "authent= ication > > > 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 t= hat > would > > > result in inconsistent cryptographic key values. > > > > > > Thank you very much for the summary of the prior WG discussions; I ca= nnot > > > hope to try to repeat the depth of consideration that was already giv= en. > > > 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 l= imit > > > for HMAC-SHA256 is 64 bytes, not 32. > > > > > > > > The situation for Blake2s-128 (which is being used directly and n= ot via > > > > > HMAC) is not quite so clear to me since it's a more recent innova= tion, and > > > > > RFC 7693 seems rather unclear about what to do if the input key i= s 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 k= eys 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 f= or the > > > length limits into the draft itself. > > > > > > > > (For what it's worth I did do a bit of math, and even if the "act= ual key" > > > > > is limited to uppercase letters plus digits, a 64-character strin= g 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 character= s can be > > > > > used, e.g., to only digits, in order to have the maximum theoreti= cal > > > > > entropy of the 64-character string fall below 256 bits.) > > > > > > If the limit is actually going to be 32 characters, the numbers go do= wn > > > accordingly, but 165 bits is not shabby, and adding in lowercase lett= ers > > > gets you up to 190 bits, and the full 95 ASCII printables cap out at = 210 > > > bits. > > > > Here's what I'm thinking as a proposal for the key value parameter desc= ription: >=20 > (I assume the "The value of the MAC key" is going to stay, before this.) >=20 > > This value is of a length suitable for the associated babel-mac-key-alg= orithm. > 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 l= ength > (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 rand= omly > generating a value or by using a key derivation technique as recommended = in > [RFC8967] Security Considerations). If the algorithm is "BLAKE2s-128", th= e > length MUST be between 0 and 32 bytes inclusive as specified by [RFC7693]= . >=20 > Just to check my understanding: the "upper limit" is something set by an > implementation (and presumably, documented), subject to the requirement > that it is at least as large as the HMAC output length? Yes -- set by an implementation of the information model.=20 =20 > > In the Security Considerations I propose adding, after the sentence "Se= e the > Security Considerations section of [RFC8967] for additional consideration= s > 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 deri= ved > 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 wou= ld be > the management system in the case of a remote management protocol). It al= so > recommends that keys "should have a length of 32 octets (both for HMAC- > SHA256 and BLAKE2s), and be chosen randomly". >=20 > This looks good to me. Cool. Great! =20 > Thanks again, >=20 > Ben >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/babel__= ;!! > BhdT!xlHCqJqacb_fuDLeZqvtD56PDONmR485Le0l1QBmYkg1UK8OXSVNGFl2ovf > NIg$