Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: Timing Attacks

Tero Kivinen <kivinen@iki.fi> Mon, 24 October 2016 11:36 UTC

Return-Path: <kivinen@iki.fi>
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 C8778129699; Mon, 24 Oct 2016 04:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
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 ISTrGrzqBbta; Mon, 24 Oct 2016 04:36:29 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 C0CC8129698; Mon, 24 Oct 2016 04:36:28 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9OBaQxR005577 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Oct 2016 14:36:26 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9OBaQ00029234; Mon, 24 Oct 2016 14:36:26 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22541.62010.241184.539109@fireball.acr.fi>
Date: Mon, 24 Oct 2016 14:36:26 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: nalini.elkins@insidethestack.com
In-Reply-To: <1103626655.678358.1476999979368@mail.yahoo.com>
References: <22495.62038.771947.984586@fireball.acr.fi> <1264225155.363685.1474644268281@mail.yahoo.com> <22507.60901.665544.878052@fireball.acr.fi> <1130739157.4563724.1475509147203@mail.yahoo.com> <22523.36827.869306.70163@fireball.acr.fi> <1103626655.678358.1476999979368@mail.yahoo.com>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 6 min
X-Total-Time: 6 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/gyoXBHGkyCsM05VYaEHDJ4Q7MQk>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" <draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: Timing Attacks
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2016 11:36:29 -0000

nalini.elkins@insidethestack.com writes:
> >Yes, timing attacks are possible against any crypto protocol. If the 
> >protocol and algorithms used in the protocol are specifically written 
> >so that they are protected against timing attacks, they will not work, 
> >but lots of the implementations and protocols care more about the 
> >speed, than for the timing attacks, especially as launching them over 
> >longer distance gets harder and harder as other things add random 
> >times to measurements. 
> 
> >If this allows easy way to get exact timing information from the node 
> >without any issues from the network latencies and so on, this might 
> >open completely new ways to attack implementations and protocols. 
> >Those attacks were not feasible before, but now they might be. 
> 
> 
> 
> Add to Section 8:
> 
> 8.4 Timing Attacks
> 
> The fact that PDM can help in the separation of node processing time
> from network latency brings value to performance monitoring.  Yet,
> it is this very characteristic of PDM which may be misused to make
> certain new type of timing attacks against protocols and
> implementations possible.   Having said that, PDM is more likely to
> be used in response to an attack to find whether there are problems
> in the network or the node rather than its temporary use being
> exploited to mount an attack.  The normal use of PDM is likely to be
> for testing and diagnostics.  So, this is a short-term opportunity
> for an attacker. 
> 
> Even so, if using PDM, we introduce the concept of user "Consent to
> be Measured" as a pre-requisite for using PDM.  Consent is common in
> enterprises and with some subscription services. So, if with PDM, we
> recommend that the user SHOULD consent to its use. 

I think this text might need bit more text about the attacks. I.e. the
nature of these attacks is that they can leak out the long term
credentials of the device. So if attacker is able to make attack,
which causes the enterprice to turn on PDM to diagnose the attack,
then the attacker might use PDM during that debugging time to do
timing attack against the long term keying material used by the crypto
protocol. Immediately when they get the keying material out, they stop
the actual attack, which might then cause the defender to think that
nothing bad happend, and just disable PDM and go on, without realizing
that their long term keying material got stolen during the attack, and
that the visible attack was there only to cause them to turn on PDM...
-- 
kivinen@iki.fi