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

Tero Kivinen <kivinen@iki.fi> Tue, 10 January 2017 12:05 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 CA782129BCE; Tue, 10 Jan 2017 04:05:22 -0800 (PST)
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 ZCtjKq6heZhE; Tue, 10 Jan 2017 04:05:21 -0800 (PST)
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 F27CA127077; Tue, 10 Jan 2017 04:05:20 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v0AC5GK0025206 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Jan 2017 14:05:16 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v0AC5FQH004742; Tue, 10 Jan 2017 14:05:15 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22644.52731.787564.284071@fireball.acr.fi>
Date: Tue, 10 Jan 2017 14:05:15 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: nalini.elkins@insidethestack.com
In-Reply-To: <970641405.98311.1484019946430@mail.yahoo.com>
References: <970641405.98311.1484019946430.ref@mail.yahoo.com> <970641405.98311.1484019946430@mail.yahoo.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 1 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Bs2EUPhrkgRgMFonZS7e6slQxP8>
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: Tue, 10 Jan 2017 12:05:22 -0000

nalini.elkins@insidethestack.com writes:
> Tero,
> 
> I believe this is the last outstanding issue!  After we reach
> agreement, I will rewrite the draft to: 
...
> 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. 
> 
> That is, in some cases, depending on the nature of the cryptographic 
> protocol used, it may be possible to leak the long term credentials 
> of the device.  For example, if and attacker is able to create an attack 
> which causes the enterprise to turn on PDM to diagnose the attack, 
> then the attacker might use PDM during that debugging time to launch 
> a timing attack against the long term keying material used by the 
> cryptographic protocol. 
> 
> An implementation may want to be sure that PDM is enabled only for 
> certain ip addresses, or only for some ports.  Additionally, we 
> recommend that the implementation SHOULD require an explicit 
> restart of monitoring after a certain timeperiod (for example for 1 hour), 
> to make sure that PDM is not accidently left on after 
> debugging has been done etc. 
> 
> 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. 

This new text looks good.
-- 
kivinen@iki.fi