[secdir] Re: Secdir early review of draft-pignataro-eimpact-icmp-02

Michael Welzl <michawe@ifi.uio.no> Fri, 17 May 2024 05:38 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA42EC180B6D; Thu, 16 May 2024 22:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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=ifi.uio.no
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 rWPSwG4JKGwQ; Thu, 16 May 2024 22:38:05 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D26FC14F6F5; Thu, 16 May 2024 22:38:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ifi.uio.no; s=key2309; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HAXQOCrome1gqihQRTYKcjfwm2GeZSsZt+6q6+s31xI=; b=jXlfkXcCUv0hASsQvLG8tQBIDI BToApfGLjjLJNg5gdbPHvOSFgnPzujPDnIrgnaSlks0mo548d5zrT22T0vtp99imKXufj3yBVmD0p xc82zNw0QNSyD2OJuD4ZtMnw5PXz6d9ZdYsGmFO5UwkqxV4TXUW0RMuUtSYlQSgb2jkTZDwRUTxpv wJ/LUrp++zCLSi5O/Ahlc7VXDJUbKW1yXulXVHnLN70HHeStYgdJQUJjZIo7Sz0UyUoKkYOFtvvt2 eFjofXN7kvggjXYSV2j1vGBg54GeUGr/cji2S6wTVUMaFiegi6MqyITavG1bmKQYwc2nMISoARisp l/y7yD/Q==;
Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from <michawe@ifi.uio.no>) id 1s7qI3-00DJ3i-2y; Fri, 17 May 2024 07:37:59 +0200
Received: from 178.115.74.185.wireless.dyn.drei.com ([178.115.74.185] helo=smtpclient.apple) by mail-mx03.uio.no with esmtpsa (TLS1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256) user michawe (Exim 4.96.2) (envelope-from <michawe@ifi.uio.no>) id 1s7qI2-0000jT-25; Fri, 17 May 2024 07:37:59 +0200
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <9C8679E6-4E52-4A5A-A5B5-B55429A0EF51@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3DCADD82-287B-46BF-A404-7A0FA222E73C"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Date: Fri, 17 May 2024 07:37:46 +0200
In-Reply-To: <cc0d93cc-8569-47cd-a085-7b929651fe35@gmail.com>
To: Shawn M Emery <shawn.emery@gmail.com>
References: <171417174965.64289.3398737354645398983@ietfa.amsl.com> <CACe62M=oSq5Z=80=i=7KEGA0jQP7=X3isWif5imp9d8WKKmRng@mail.gmail.com> <cc0d93cc-8569-47cd-a085-7b929651fe35@gmail.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 178.115.74.185 is neither permitted nor denied by domain of ifi.uio.no) client-ip=178.115.74.185; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple;
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.055,HTML_MESSAGE=0.001,TVD_RCVD_IP=0.001,UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 991CF4491AC7530E0A8CD59C0FF2130ADE0E9797
X-UiOonly: F7D55B9A3FA7C08F233C3FAAA2103C48750BE6D5
Message-ID-Hash: NQL6DSVCZHCDDJX44BD3T5SEPQVJ7V7C
X-Message-ID-Hash: NQL6DSVCZHCDDJX44BD3T5SEPQVJ7V7C
X-MailFrom: michawe@ifi.uio.no
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Carlos Pignataro <cpignata@gmail.com>, draft-pignataro-eimpact-icmp.all@ietf.org, secdir@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [secdir] Re: Secdir early review of draft-pignataro-eimpact-icmp-02
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/wAOf2-mf4hbbHwg5lkmvvrhGLNE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

Hi all !

Just a thought: a router or switch may not itself be much involved in crypto operations (in the absence of IPSec, and while no encrypted management protocol is in use). In such situations, DPA may be a non-problem.

Devices can of course abstain from sharing power information. What if the security considerations section said that devices should allow their owner to configure if they should share this information while cryptographic operations are active?
( I say “allow their owner to configure” because there may be more concerns about sharing power information widely, so anyway an administrator may want to configure the device to share this information only within a certain network domain. )

Cheers,
Michael


> On May 17, 2024, at 7:16 AM, Shawn M Emery <shawn.emery@gmail.com> wrote:
> 
> Hi Carlos,
> 
> Comments begin with SME.
> 
> On 5/12/24 4:41 PM, Carlos Pignataro wrote:
>> Hi 👋🏼 Shawn,
>> 
>> Many thanks for this very useful review!!! Very useful!
> SME: Of course.
>> We have been thinking about your review comments, tracked at
>> https://github.com/cpignata/eimpact-icmp/issues/27 , and have some follow up questions for you (leaving only the relevant part of the review)
>> 
>> 1. For DPA (as in differential power analysis), an attacker would need a “continuous” Current / Power over time curve while the crypto algo is executed. Would the fact that this is getting a single value (not a time series) be a fair high level counter measure?
> SME: This countermeasure is still susceptible to divide-and-conquer attacks, where different parts of the secret key are learned over time.
>> 2. Do these elements typically have DPA protection as in injecting noise? Should we in the results?
> SME: Ideally yes, but this depends on individual component/system/software design and therefore could not assume one way or the other that this type of mitigation has been employed on any given device.
>> 3. Could you please share a reference to DPA we could use to add text? And really welcome textual suggestions!!! 😉
> SME: Hmmm, this is an area of ongoing research, where promising countermeasures include a holistic approach, such as software flagging sensitive data for the hardware to treat this data with algorithmic noise, i.e., undifferentiated power consumption based on input.  So if this type of mitigation was a MUST in this draft then how many network nodes could currently meet this requirement?  If that answer is "very few to none" then this draft, IMO, would not be an appropriate source to provide guidance on how to counter remote side-channels attacks.  What is the granularity of voltage that would be meaningful as a sustainability metric?
> 
>> Thanks again, Shawn!
> SME: NP
> 
> Regards,
> 
> Shawn.
> 
> --
> 
>> On Fri, Apr 26, 2024 at 18:49 Shawn Emery via Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>> wrote:
>>> Reviewer: Shawn Emery
>>> Review result: Has Issues
>> […]
>>> 
>>> However, one attack vector that I could
>>> think of is a high-fidelity reporting of power draw for the targeted node's
>>> memory, cache, or HSM component then an attacker could perform a remote
>>> side-channel attack (i.e., using DPA) during cryptographic operations in order
>>> to extract the associated secret key.
>>> 
>>> General comments:
>>> 
>>> Thank you for the use-case section.
>>> 
>>> Editorial comments:
>>> 
>>> None.
>>> 
>>> 
>