Re: Secdir early review of draft-ietf-bfd-optimizing-authentication-16

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 19 June 2024 20:40 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C30C18DB94; Wed, 19 Jun 2024 13:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level:
X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_D7umVmTosW; Wed, 19 Jun 2024 13:40:32 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on2097.outbound.protection.outlook.com [40.107.8.97]) (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 7F3BDC18DBBB; Wed, 19 Jun 2024 13:40:31 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QRKizuzgKzm2KqL4b4s/G5vdtrXmcmkMWNZK2DcdpD4edF61KYn3tPWCYB/igUPZtlWuuyZTQysmOF7dxLKczn2yPgc41eiEoSxomuT+4EP58RaU5hNoVqdJ6yrfojvRA/qRLoHLEDT8R8K0thsy7YFrfToJhEUfRaseyHakZYFb+SqcXHD6LnAM/ziWuoInirtzhfFSity15LvmE3nZo2vETP5PQ0plteAtVqQQNnAri+X1RPJBi9EbQ4AzktOUPfqpwD8PEyJAFpyc819IpGvubJf0RxxL6GV/Iu1I0F+LEFtI9AxTY4gvTkntxzDQ/SH/Lg/SiMrCMRz92RRjng==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MmQ8A2wU/UtkzJW0YDf6vqPt4GlclAtyMzn/zs+g/dI=; b=YZmkyawzs5Wf26K7K759pwUP/5ZGN4NHhB7zTZVrVtVO5jrveO+zbyXz8UJN0Y8o44MSueuK76hnJersgqJjqr+5iuP2oAmo5yF/LYH28lSrcxNn7BGO5k7vpCuJLZlRA9+MEywPs6FhEomejMamVUZSMjSMiWqVrJP2nsqcskDBN7lYM8x8iHhZYHbOVggzJE4OVWa1rSAradqcfhEdGC7XOx89ugfEkhcCIrPXI3HpAz0tiN7hCg7QEr9d/MJw9LdwYuELIHIVCQmMRkGahyeXTvM8qGf+5iX4xa+TpBBzxsjARL0FZ+K0eXPD8H76Z0gz3lFnIxeo/YHpaO0jSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MmQ8A2wU/UtkzJW0YDf6vqPt4GlclAtyMzn/zs+g/dI=; b=ckYvbM/6fmeN3GVzVvg+BTYCrmSeQHUlzPKbhAts71B091OBVTCS8PVhiTruPnkYHrOZ+i83qBzb2DdbuTAFvOsxBy2gqalWnpy+4xpMYGpwi63i8jpQ/5T/gOpzPEbWCS7vtk4gQ7aT+JCz4yOwVbuNfpkSm0XaI+jwfx/kV65vJDGQ7QYC81xF9QnZiz8yCGjZ8GBhxCA9LmcoePnP0d4HadV9LQuRFNQoEIzI5T9ANlIYHWKjVW+P8XKRuLElSxFrfxRQ1pTlyYTYADrhcrGI0/eVfxC8CBd17XKUflddHMl23ybfojoYwRz/3pqfSSjTZ4VgsffFG2KUxvL7XA==
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cs.tcd.ie;
Received: from DB8PR02MB5946.eurprd02.prod.outlook.com (2603:10a6:10:11c::16) by DU0PR02MB9293.eurprd02.prod.outlook.com (2603:10a6:10:471::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7677.31; Wed, 19 Jun 2024 20:40:27 +0000
Received: from DB8PR02MB5946.eurprd02.prod.outlook.com ([fe80::e0d3:772e:a68d:d54a]) by DB8PR02MB5946.eurprd02.prod.outlook.com ([fe80::e0d3:772e:a68d:d54a%6]) with mapi id 15.20.7698.017; Wed, 19 Jun 2024 20:40:27 +0000
Message-ID: <5d78a447-4214-4c00-b192-bbb532784256@cs.tcd.ie>
Date: Wed, 19 Jun 2024 21:40:12 +0100
User-Agent: Mozilla Thunderbird
To: Jeffrey Haas <jhaas@pfrc.org>
References: <171863246380.36317.13945608266304472653@ietfa.amsl.com> <F52920D3-7C84-4754-9625-0656EB6EE442@pfrc.org>
Content-Language: en-US
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Autocrypt: addr=stephen.farrell@cs.tcd.ie; keydata= xjMEY9GzphYJKwYBBAHaRw8BAQdAo6JvjmSbxHdQWPZdvciQYsHhM1NxQBU398Mmimoy4p7N M1N0ZXBoZW4gRmFycmVsbCAoMjU1MTkpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsKQ BBMWCAA4FiEEMG54R8tZDyZFrDOn5Njp+ZeoM90FAmPRs6YCGwMFCwkIBwIGFQoJCAsCBBYC AwECHgECF4AACgkQ5Njp+ZeoM93bogEA25ElRyX0wwg+kGEN1AoL60MoZfvQZ/VtmXY6IC5j +csBAIBpkL5ySuzJK2zLNZn9qQGht8IaUcA7cvDcLvS2uHUEzjgEY9GzphIKKwYBBAGXVQEF AQEHQILCPWOwW36e8D3pY8GmvvtItIT+A5uV80ist+WokVsQAwEIB8J4BBgWCAAgFiEEMG54 R8tZDyZFrDOn5Njp+ZeoM90FAmPRs6YCGwwACgkQ5Njp+ZeoM92bcAEA8R+8cpqRUIS+SoAN iO05xE6O/wEx8/e88BqzAYki3SoBAOQdwiPX+MQrAxkWD8xxOsdMOAtxYKpkD1n8aPJUw6QJ
Subject: Re: Secdir early review of draft-ietf-bfd-optimizing-authentication-16
In-Reply-To: <F52920D3-7C84-4754-9625-0656EB6EE442@pfrc.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------RyYgufzTriHuYSl6nIkWE0M9"
X-ClientProxiedBy: OS0P286CA0093.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:b1::8) To DB8PR02MB5946.eurprd02.prod.outlook.com (2603:10a6:10:11c::16)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DB8PR02MB5946:EE_|DU0PR02MB9293:EE_
X-MS-Office365-Filtering-Correlation-Id: 1c8170e2-7d0a-42c2-e560-08dc90a00cec
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-TCD-Routed-via-EOP: Routed via EOP
X-TCD-ROUTED: Passed-Transport-Routing-Rules
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230037|376011|1800799021|366013;
X-Microsoft-Antispam-Message-Info: kGvLYfVsJu+hn/YQU2Dg61sbw6R6xOBPpgPyA31C6Dj52QvBO7ebwaelNbq8gZpfWFx/SC6WGsh0aZ6wADveeJ7BC7AAJ9XsFbnruqvT/H5ZHSKQRtNb5Z9gWe+QmPZ4lvhbX3SlpJ1RnNjdWkcmW722ZKQV8WyHDsyoCRq6fdruLuL6h+/Znz81MkJ6VwwKo3C8bcuvUiwgw06uOjDxuj6Ca1QRexILsTacpV7A/n07tB2CfimNu3ld7ETm8pjl0bNr/6XB69G2ePoLfuoAQofKG0u2KE0/iwbCYTXea1pE46sgPAhsIlwqZZZqlgfjhpfEfk8qGHFj21VO18SGVnfzzqBWgiA7R/O0zNbFxTPUV9Clkdh+O1ThZ6fm9jbXJ0tQOq/1FiVeAS2lj+7upw5ZUSvjeU/vvb96ljiyaos3H7/OhfAp4LV+p/XDLCQi51lbAnu1xK4pL5T0kuOUd8oi2R0v0+H4AxliHTPQuP0zwcs66epf9J0vZ7hF4uJBHFt6g7CAdpAYDBqVBe7k/Tr61dV67kYfZHEje1BKI4Btl7CzSuorFztEn3qm8a9MO6PVNz4TBdAhI8pOBta9x+1OV0uMM2NU1tUs/Ph3wo13DIaUOKOn7WOqFdLMpnX/8qzhjt9P3QpisVpesSfjLcKH2rWlVjTBU4pXGD6AQTiI0BgeU24QXhs3C54FRBZlYImqv+E0ZRq1fsCNg8fjwsinJPrU90xV7wWMtsS/Lm1JaZdxW1CYUIPgwkdH2Cw3eKdEh/NDH1rFChofrMnsYg9aF5gpiy2AtDihARgeH3okVOPqJMDyJtrgY2sMlPy0S97cteUOVEna1pR1Ib7vL4nIL8xHM+zyfr9cIVDrOu5ayQX3ekhOZqBDgbxIHx+efiHGYqZIw/WAoV991Vsav9yYVzL380JnhQxHif2i+fMc0h/vfqGRslo+y9okmlud/HCAV8+SqR+6NaUD/79oYIxCuUFWNLjA6+XDvRjwwe+Q6zgQ8XfTOnXGJm5nAW0u2hhGKrRPhcbbOYydxQBYn6oLnBtfj5Hn/NaM0zM7F9HzUAhVyIlKbJmJa7t+/LbtJ3OLYFXjRsUz5/vVg6o0YqA+WPmT07D3lgkcIDdYRSyJVfZ2m1E/Lo2VuOhMB5nvbvSIh0GGK6pRQzHyjrgtp/T+AAL3+BWTMfrrQ8BdS8jorxqVwkDqDDa2nyQVEVdHsm/W92/tO9KZVJhhAMxNmwZUsRESIZjLLM+nU2UZzFKqD+8Xug5EmKuYdCqk9wPW
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB8PR02MB5946.eurprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230037)(376011)(1800799021)(366013);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: sqb+y55Z8c1g7h9tk0Cqg1LRPzgdU2Ehx2fJQmXPra8KWFC/DPKiVWTYG126lS7fjsmrgMFfsA5iAOzWumnt2i/fIQR9Ktw3GXgxFcWGLrI9lvEhPMTyjHQQufGh0G41Uq0s2IcV7/OwGfcY88KysZGNBpAY/Bmz2DJrWHKQMYnihvIZOgSvBEQmrKrNm4E3f8yqEU67i5go6DAFRzEIgf2m3oepAsCAiod5ffrGxGJ31lrNJUpImB5vzWthhBB29yWbYuhkG3cpk3OjscEAuhFgJvQl27VopAe+6cq7+K5Ps1YiPWXkSqkhq6N3cHPGn5UW1nSqfzircnicW3vA6BUu9qEuu6yYbjdawGT756+QaTQTiWbe4NupFskfZsyAywGUXSXbYYFpUfZYTFZejcdWvvfXB7uh+ifOzJSENoNZeAIlODDO+8FmaALSBraDeT2DVP20Gy6HudlG++MLQswsX1GLqQR33HmQdeI3DUY0DVa60rD2i56b3h0tLZijB/2AqS/6SDH7P+v7y1onAInyrR5kJLP8Poqkgha5m5IWb5KMGKIleq4gRDY6Olx718JixJif8f+axwz/QioaM6glEdHg9BooUbGT90X9jUYP8h7xF1NokAPDlHDHWE+h+WpG1HTGhgaIdk2J/2oEEurk2OyVgPDR7qpAJZbFDgcp8VW0VGgQDftbF5tqAKFVetWL+91+lU8+4j2P+o+0zXqIVCh2kbXBGSB4wq3MKLvyHe62THgx8klchyHOD2TbSPVvfMtAaN9Uh79zfH8y1HEW4LjKSYg8k6iXxFoaN/61L+Tr1KwHix0pgU2+AKqJ5ouEAC4LKuXksq6Qd+eqMbgv3wQPTLAG5w0rBU1ij90QmSaNwWqD1scL5yfabzno04ruiSPFCMGxR15hYz3Gi2IO6mdxwz9HpSjwJnmwX/XhVh+YfA+U7ZwFOEzn176lepJR+jmjjoIyAiyI5q9900kGpyojFoNub5+0K/ZeXYX5gE0H2BlG7E40A5uwOKdQky8e+FiJgNO2N+hNaHlRsM+5K1JFaE3gP6Lsjf4nRYeuTb60NZPIvUpkiB/WPz4/SruE1WhXK1q5ZX7btm1VQC5fVMsLz55k4q9nRXLESVPmmD7CXpjXIflLnc7PVjkeN3Zd95oNeIRnWWo86TABoITw8ANjjNWx1qpdM5XES9CQFQdDrRaJTFTkc1dAghQZVO09GE+5wRtrRXmDOaYjzSmhflKiIdcQRK7SJsEUzefCG9mkwjM2k4ZUbsH+sCKBT7rAcqtgn//r4HEVgaU3wSOHStKEV9hzg1RZSfIaqRLvHkZDiPwFak6X12qHXmM4IEZ3get3APd+heOyhO9C4Mh/ruvX/QdVKZapx16yTL/sC5vhGmdxS8Ld8178/MR5OuNNvCjn1wqLouRqZaWtELzG5Bc2fn4FWv89yu8GzgKHq0U3koJkXIcFi+t5K/llYhlxoERsGJCYszUUTzb8sRyG2ZrhypUtLWJfTXYFVKAiAiDqh/jzV0kIIWy43I1BAbbTBX6dT2y2lyLfY9juJ6kdXMoBiD5ZpSu34uSDxW5rZWdJGWHeRSWSoh/uE0+yWT+7BTU9KbaH5qD5s7F0U5cU9rs0UfehMQDtwofVYRuDcvQsWxqhT1dk1mq25rYl
X-OriginatorOrg: cs.tcd.ie
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c8170e2-7d0a-42c2-e560-08dc90a00cec
X-MS-Exchange-CrossTenant-AuthSource: DB8PR02MB5946.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2024 20:40:27.3522 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Dh9NfWs1wW3gg4+hhymQZMZft7pdVyUkd/TN3kclCLMWZij48W9Smjw4LVAM0fF2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR02MB9293
Message-ID-Hash: WKHQECUEBPTMQ6VYIQC4HU6QHWPG4CZR
X-Message-ID-Hash: WKHQECUEBPTMQ6VYIQC4HU6QHWPG4CZR
X-MailFrom: stephen.farrell@cs.tcd.ie
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-bfd.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: secdir@ietf.org, draft-ietf-bfd-optimizing-authentication.all@ietf.org, rtg-bfd@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection" <rtg-bfd.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/99zfXRg3vDxtCF2AQliBrvbRzds>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-bfd-owner@ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Subscribe: <mailto:rtg-bfd-join@ietf.org>
List-Unsubscribe: <mailto:rtg-bfd-leave@ietf.org>

Hi Jeff,

On 19/06/2024 18:39, Jeffrey Haas wrote:
> 	
> [External Email] This email originated outside of Trinity College 
> Dublin. Do not click links or open attachments unless you recognise the 
> sender and know the content is safe.
> 
> Stephen,
> 
> Thanks for your review.
> 
> On Jun 17, 2024, at 9:54 AM, Stephen Farrell via Datatracker 
> <noreply@ietf.org <mailto:noreply@ietf.org>> wrote:
>>
>> Generally the idea seems to be to avoid spending CPU on hashing except 
>> for cases where the
>> state changes, and with periodic checks that BFD auth is still 
>> working. That seems like an
>> ok idea to me, given the kinds of authentication that are defined for BFD.
>>
>> - For security reviewers, it'd be great if there were a reference to 
>> something that sets out
>> the performance requirements for BFD, and justifies the claims that 
>> hashing is such a
>> burden. That's counterintuitive for people (like me) who consider 
>> hashing as fast. (And
>> md5 as broken, but that's a different matter:-) That text probably 
>> shouldn't be here but
>> it'd be good if there were a reference to it in most BFD security 
>> consdiderations sections.
> 
> The analysis you're looking for is somewhat covered under RFC 7492, 
> which was done as part of the KARP Working Group tasks.  Due to that 
> specific focus, while still a valuable document, we've generally not 
> cited it as a primary reference.

Yeah, it's useful but not the kind of thing I meant.

> The property you're bothered by is that these "cheap" hashes, when done 
> for a modest to large number of BFD sessions on a linecard that is 
> otherwise wanting that CPU for other useful work related to forwarding 
> is an attack against the linecard doing its actual job.  So, there's a 
> need to balance the costs of strong enough authentication for a BFD 
> scaled scenario vs. the utility that the authentication brings.

Right, I think your/the draft's case would be much improved if
some such measurements were added or referenced that demonstrated
the problem in a convincing manner.

> It's worth noting that section 6 of RFC 7492 notes "hallway 
> conversation" that this optimization draft is addressing. :-)

Well, it's not quite been a decade since that RFC was published;-)

>> - I wondered if the "optimized" terminology is best - say if someone 
>> figures out some new
>> way to optimise things using a different mechanism (e.g. some new way 
>> of amortising the cost
>> of hashing over more packets, or multiple links or something), 
>> wouldn't this terminology
>> then be a bit of a pain? Maybe it'd be better to name this as as a 
>> periodic or selective
>> authentication mechanism or something?
> 
> While I agree with and am sympathetic to this point, it'd take strong 
> Working Group consensus to change the name. 

That's fine.

> I like "selective 
> authentication".
> 
> The issue you note is the usual caveat at naming a thing that may have a 
> followup.  How many "next generation" technologies got the next-next?
> 
> Note that the following comments are contained in an upcoming pull 
> request in the github repo for this document:
> https://github.com/bfd-wg/optimized-auth/tree/jhaas/17-comments 
> <https://github.com/bfd-wg/optimized-auth/tree/jhaas/17-comments>
> 
> 
>>
>> - The description in the yang text of the retry-interval seemed odd to 
>> me. It says "interval
>> of time after which a strong authentication should be enabled..." but 
>> should that be more
>> like "re-tried" rather than "enabled"?
> 
> 
> How about:
> +        "Interval of time after which strong authentication
> +         should be utilized to prevent an on-path-attacker attack.
> ?

That still seems to have sorta the same issue, how about:

   Interval of time after which strong authentication must be
   re-enabled for a number of packets as defined above.

>>
>> - The security considerations says "If this interval is set very low, 
>> or very high, then it
>> will make optimization worthless." It might be worth stating that a 
>> very high interval value
>> would allow an attacker that much time to muck about (with whatever 
>> attack they're trying),
>> but I don't have a concrete attack in mind, so feel free to ignore this.
> 
> How about:
> 
> If this interval is
> +  set very low, the utility of these optimization procedures are
> +  lessened. If this interval is set very high, attacks detected
> +  by the strong authentication mechanisms may happen overly
> +  late.

WFM

Cheers,
S.

> 
>>
>> - looks like a typo in section 4: " there is problems" maybe "there 
>> are problems"?
> 
> Fixed, thanks.
> 
> -- Jeff
>