Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-information-model-11: (with DISCUSS and COMMENT)
"STARK, BARBARA H" <bs7652@att.com> Fri, 12 March 2021 01:25 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 D07DC3A16EF; Thu, 11 Mar 2021 17:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 vhPiOUTsGRXb; Thu, 11 Mar 2021 17:25:28 -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 B2AB53A16EE; Thu, 11 Mar 2021 17:25: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 12C1PIiS046434; Thu, 11 Mar 2021 20:25:28 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 3772jsm30k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Mar 2021 20:25:27 -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 12C1PP6Q005589; Thu, 11 Mar 2021 20:25:26 -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 12C1PNSU005582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Mar 2021 20:25:23 -0500
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 475644009E68; Fri, 12 Mar 2021 01:25:23 +0000 (GMT)
Received: from GAALPA1MSGEX1DC.ITServices.sbc.com (unknown [135.50.89.116]) by zlp30487.vci.att.com (Service) with ESMTP id 179734009E67; Fri, 12 Mar 2021 01:25:23 +0000 (GMT)
Received: from GAALPA1MSGEX1DF.ITServices.sbc.com (135.50.89.119) by GAALPA1MSGEX1DC.ITServices.sbc.com (135.50.89.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 11 Mar 2021 20:25:22 -0500
Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1DF.ITServices.sbc.com (135.50.89.119) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2 via Frontend Transport; Thu, 11 Mar 2021 20:25:16 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.170) 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; Thu, 11 Mar 2021 20:24:33 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G+OScPj64uf4kIX/GfOHJkw7PVkQJLbSqiWlf6mqM3qaNivNGiGJkXeOtBbvZC1tpdzyOwfGos4tQd0YMlEkPtKnwBbY/IjU9bXZriI+vc99e/IgEjOr6QzfzCrSPmkGnCNYzlNo+KFijyLkLX+6dNW2qnB9be9czuDcD+Jx9PJxX9ai1gytva0PcGFALN7kaFEQz2H1HYS0Foj0WSl2pPzUaug/HJK4XXfh0ChKuAkB5HJVAJw7Fdiy/OxbndbjyKhhNWRv71AJd9d07lgqdTQfSB2no+C81ffNlGNx+L0sABVax3snP04KQyfRTbmYetmCd0oZMStJ2dJWc+ddJg==
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=jufITqmeZQQ7kt/nd51LjMk8XD1Mv0sevhXEax25QYw=; b=AdwF7FF9L8U2DeYHVBeNvWtmqMW7VF6q/67gitpiYcofYeUl3qNUgk4YP65lUttK4YfYTKziiwQI072nDTql2Khbzfy0Imyzl9gsE6s07LrezmVRYGxVYXFZYxhUOPnYslMHL/MgD8j4Pc3CsdjMDP6NzJeUCPtoYCsCsm+5Ke4maOCvy4+6TB0rQUmey5Uwv7p9uhcT7Ran0UzrQaLazKqPcUQvoW45gZMw6BX7EUnsMwyVmtssQJgbbWzgMHDhz/IVhJWepZT6K4R3QR4rgLHETFCGuDtxnBovvgCHpTnPJCEYw0Glw6DyXfzMPDWPvkrOa7Q6Ra5+jqfFFIYU9A==
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=jufITqmeZQQ7kt/nd51LjMk8XD1Mv0sevhXEax25QYw=; b=n+fipe5lnAN5Z+KkJzcfynE5xMfKUJ+r/qZLepDzIrM5C39itF4+N3eY6RiN6o+KaTHfbxjGSUrfQsmrZlGNTmVjjThMo4L0g1ylxH8qaTLKGaotZMT2GOXwTG5PiM9fUy4pDP7SLGet/RvAkkSd3ByKxsEtO9omID5sG2QwglI=
Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM5PR02MB2571.namprd02.prod.outlook.com (2603:10b6:3:3f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.30; Fri, 12 Mar 2021 01:24: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; Fri, 12 Mar 2021 01:24:32 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Benjamin Kaduk' <kaduk@mit.edu>
CC: "'babel-chairs@ietf.org'" <babel-chairs@ietf.org>, "'d3e3e3@gmail.com'" <d3e3e3@gmail.com>, 'The IESG' <iesg@ietf.org>, "'babel@ietf.org'" <babel@ietf.org>, "'draft-ietf-babel-information-model@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+9zCACT03AIABlDYwgBlk4oCAEXGNEIABjMOAgAATegCAAaoGsA==
Date: Fri, 12 Mar 2021 01:24:32 +0000
Message-ID: <DM6PR02MB69241C27CDD2807A3CE5B284C36F9@DM6PR02MB6924.namprd02.prod.outlook.com>
References: <160436211925.31069.7931310164710901437@ietfa.amsl.com> <SN6PR02MB4512CEC73FF751E20D7A64F1C3CC0@SN6PR02MB4512.namprd02.prod.outlook.com> <DM6PR02MB6924227133396A388EECD9D0C3B49@DM6PR02MB6924.namprd02.prod.outlook.com> <20210209164932.GU21@kduck.mit.edu> <BY5PR02MB691424143621B8AC6D1B2DF3C3819@BY5PR02MB6914.namprd02.prod.outlook.com> <20210226204349.GA21@kduck.mit.edu> <DM6PR02MB69248597F0A5306203F104C6C3919@DM6PR02MB6924.namprd02.prod.outlook.com> <20210310224643.GG56617@kduck.mit.edu> <DM6PR02MB69247B75FC36A097F86FFDB7C3909@DM6PR02MB6924.namprd02.prod.outlook.com>
In-Reply-To: <DM6PR02MB69247B75FC36A097F86FFDB7C3909@DM6PR02MB6924.namprd02.prod.outlook.com>
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: 54e18fb1-28e3-4ef1-14d0-08d8e4f59732
x-ms-traffictypediagnostic: DM5PR02MB2571:
x-microsoft-antispam-prvs: <DM5PR02MB25715795777A6310BEAB8C7EC36F9@DM5PR02MB2571.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: VytVE9TeSI235P4yCEgqDGtpRQHObeEaP/Pm1pXUi0O20mOfx1MPREFqmwwMRWxuFmv/Qyehqwq0I0eY7KrNFy17RR5VGcbnd22Kak1FTOHqc+1TpFSchn+tAEjNRVvojW4HnQrfMBgHkdkKk7cdPv/YtFFGy27AAteKIhQIvbt9kofimvP2k1rKPRf7Z6Jg71J0z0z1/+TWSI8L7ADQgLeNqqGjIejf9gBXYkM0kqpmb4WAPrGN/p9+lEjIzgcQoxPezvkL7svd0Sg6JV3Sk3TDY7TgaPsU+TQWzUQyl/HHaXRb1HPOQW5PjmUxuTqqZjzbTsUj6Z8S8OmRgQ1BSqRRtQ63BnoX1CSmYkINqSWcvSJwrIRrxQriIpF+ZurQ2+CnplQ4L/DoJRgsCJNAgXGnYxtNcoEI0W/ahazAE1kRa4c0Gniq3ZNFDN5FuRamw8elClSmXKSueakKqHaHfuNJ/ZPUtcmGX9vmdTDrSteG1w2r+6qtz3AxOkLQLx4Vl12ka7IgRi2Z+l+ky0BwjwnVd6C49FgnwX/CmVkU56MMzrI9AkiiYexbGIrGVuD7Sl5eCbPhmkkrdjhjIDPwfAMkiLCoK3c8HO04XATRsNE=
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)(136003)(396003)(39860400002)(366004)(376002)(346002)(30864003)(26005)(64756008)(82202003)(66946007)(478600001)(54906003)(66446008)(76116006)(7696005)(2906002)(55016002)(9686003)(4326008)(66476007)(5660300002)(66556008)(8936002)(71200400001)(186003)(52536014)(8676002)(316002)(966005)(83380400001)(86362001)(66574015)(33656002)(6916009)(6506007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 79vP9vAVzK/uQWIDFCZpIV/OP37RE6Ss47dSNZUbti2Ej3LqSl1gUN3oOqDYrNHzjERDMSurRnjWXBuDr1QgGazbjuK6FYzbtLN6lb8vNTbk9RGtuQQN3bxyKYw7AloYtC15+bIk3rex9yNW7J1tIKWhtW83X5u2MWqkGF8Gyz8IDkW0MEBgl0LPMcjBZUtinU4IluexcE4/wZoTYGTZsv/Ql7qn0g5SR3KfcH7VF3XL/Ejs7jo1+TkUHOr6J/LvcuUtBMqofVx4ALMNeeWhZ2Ae98SIAToLPa9XcGiASW169piNrPGrxog1Bzoh1N2+yhYMTeFcTkbtt/CXvMKNRXLUMYpCMdJrow6J8EpnbGXRCU13Lq7vra5DUo0Mllcf3sx/hz8b6EXxkQDvXUL817gTmMUpGi94UUZa7gQdbT0Os6AlT+ZcwswCkdRwrEmlu4Vrd4n6AxKr+n3EhIXUk1UGToOdwK/w0vp0kpXN8JoX5N+tX4t6DVvB2euOlf/CjkVmIOCepiIegJMPYbmusElo9ITrhnFzfi/815ANQp29PS5BSj40g5uKFPcgIMnWWdBGxGLyZobrvYnbRnDE5tPYQeX1CFdZl4ecO1I9gwMiv7WR813AwCxuflEtE2UdBQn+WJeOzPxFdHrs2kMaSoEpCjHhJ6h3iWUQ90Uykz8pm/0AvCPTSG6JkAdS8hjAcH7DxmK/Z2B2WLMksXZE1GQw5bIZIrH5uqSDvFkOJEG5dbvNllFePsjEW4wsRxwBBsVWrTtAfY25dzFvf24vcn/u21Oju/2bWv9ZzhAZBEyy9+efVzRfcyFmvSJlsE6DaXu3iYXNUEoCc6ZRaeqCPl7N0dM1iv7siBGq2oPo6xPJW4znx5ZjDcIYx8nOG8iAd18WEWI3EFzm5rtxrMLE6fJdCBSwLg6vf91E91MJAiBT85NfWpwyoXh1jMTpXQKDGS7xyn8VRRBKpYY68dxOOjeAn7H6Sh6YtbL6PYg4WEz18zn8Ei0j+DB0Jo3MC5PQKGC4bV7/XBRbTbYaMy9iELvNz1VHeNrJ3ggzp6iC2pS8v7pbeF2OCBThS11H0HCM75M5GYqJ+BYx/y+revJUTapC1YOvGhu4opnqwSWUOGOB5M4XwVlOQ3D3UpKnKUpAqKWg1WtmXZQG4xA+BnEIu3Kt7+IzjqwgOLH8ptVclI84SbvC2FiRNLBUBlEaNhueXGe+f1w6jMumT9irqWkoY8EU2mLEIQ5RbZFQpGgHW924zoMVUtf1F5laVvaCooiMPRVSPQfreyv1gb+9lVOJ7d9dDmqqfyY95WjiTwIsIoQSGP9NJJ8Jw+nDKtDrKBwq
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: 54e18fb1-28e3-4ef1-14d0-08d8e4f59732
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2021 01:24:32.2141 (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: mX4rDrk5xp865U+c1ma/BjXc5iA7DaPuVLPHwBJJxGgxesAvEBD0n28PImMShq3H
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR02MB2571
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: 92C122E7CF5F530C697DC25217272C9C74923F8B79F1DAF8F2E4CA4F192A39CA2
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-11_12:2021-03-10, 2021-03-11 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 adultscore=0 bulkscore=0 priorityscore=1501 suspectscore=0 phishscore=0 spamscore=0 mlxlogscore=999 clxscore=1015 impostorscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103120006
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/4nwPmFziFYgX_04fBqos-QDhUvg>
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." <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: Fri, 12 Mar 2021 01:25:32 -0000
Hi Ben, On the off-chance that maybe the text changes I proposed are all acceptable, I've uploaded a -14. I think Martin V would like to move this draft along so he doesn't have to get approvals again. 😊 https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-information-model-14 Thx, Barbara > Hi Ben, > Thx. Reply below... > Barbara > > > Hi Barbara, > > > > Thanks for following up. I feel a little bad that I forgot this topic was > > still open, and didn't even look at the babel agenda while deciding what > > session to attend for that timeslot... (inline) > > > > 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 during 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 time > > matching > > > > > > the stated justification with my understanding of the facts. > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > DISCUSS: > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > Section 2 says that the "DTLS certificate values" are required 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 certificate > > > > values" > > > > > > to > > > > > > > > "DTLS private keys" (which are required to return no value when > > read). > > > > > > > > > > > > > > > > > While I appreciate that IPv6 is the current version of the internet > > > > > > > > > protocol, I do see that 6126bis allows for Babel to run over both > > IPv6 > > > > > > > > > and IPv4, yet this document in multiple places implicitly assumes > > that > > > > > > > > > Babel runs over IPv6, to the exclusion of IPv4. Such a restriction > > from > > > > > > > > > the core protocol spec should only be undertaken by an > information > > > > 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 <Juliusz: please look at this and > > > > provide > > > > > > > > suggested changes>: > > > > > > > > "This information model only includes parameters and parameter > > 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 both > > > > > > > > IPv4 and IPv6 routes." > > > > > > > > > > > > > > > > and then expand on this in the Introduction with > > > > > > > > "This information model only includes parameters and parameter > > 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 simplicity > > > > > > > > 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-local > > IPv6 is > > > > > > widely > > > > > > > > supported among devices where Babel is expected to be used. > > > > > > > > Note that Babel over IPv6 can be used for configuration of both > > > > > > > > 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 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. > > > > > > Here's what I'm thinking as a proposal for the key value parameter > description: > > > > (I assume the "The value of the MAC key" is going to stay, before this.) > > > > > 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]. > > > > 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. > > > > 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". > > > > This looks good to me. > > Cool. Great! > > > Thanks again, > > > > Ben > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/babel__;!! > > > BhdT!xlHCqJqacb_fuDLeZqvtD56PDONmR485Le0l1QBmYkg1UK8OXSVNGFl2ovf > > NIg$
- [babel] Benjamin Kaduk's Discuss on draft-ietf-ba… Benjamin Kaduk via Datatracker
- Re: [babel] Benjamin Kaduk's Discuss on draft-iet… STARK, BARBARA H
- Re: [babel] Benjamin Kaduk's Discuss on draft-iet… STARK, BARBARA H
- Re: [babel] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [babel] Benjamin Kaduk's Discuss on draft-iet… STARK, BARBARA H
- Re: [babel] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [babel] Benjamin Kaduk's Discuss on draft-iet… STARK, BARBARA H
- Re: [babel] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [babel] Benjamin Kaduk's Discuss on draft-iet… STARK, BARBARA H
- Re: [babel] Benjamin Kaduk's Discuss on draft-iet… STARK, BARBARA H