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

<> Mon, 24 October 2016 12:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D08A1296AE for <>; Mon, 24 Oct 2016 05:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yml-9x2Sqzf1 for <>; Mon, 24 Oct 2016 05:49:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 143E51296B8 for <>; Mon, 24 Oct 2016 05:49:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1477313370; bh=v69KkD8q9oY6CFtRS/7sfL4zpatLPSkTRYY8LCvPjto=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=lBYlUGbm/lnI8p/2r4ARvu7rTx1qhvjz2EN/Ez+v5F36h9TjwH6k/uf0n8ojiUB2JBTrlD+arUQCQ3oYrhlF2deria2WlC4gctsorSEBLC33NNShZHCJMyNvbMN+dYx9v+Pqc9IK+R8j5s5+b9UP9cBTmj0nG2SZDhWoe2jKicfsclD36bO0wGoDdaLK2hKUP0+/BCgyaaT8L4QtCFbDPtsDnNOjFMTX/YBoBuo7Ynla4Cnrb1IbutJYcANakjkSZYFjSylsat+Ema+jZDqFJYdXk7Klc/VoeVtEdOZSmXAPHuTNrX9YXbnlJKJzXkuoZ4Zdx1sLHlMoM9dFplxUhg==
Received: from [] by with NNFMP; 24 Oct 2016 12:49:30 -0000
Received: from [] by with NNFMP; 24 Oct 2016 12:49:30 -0000
Received: from [] by with NNFMP; 24 Oct 2016 12:49:30 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: uDP.VUwVM1lUSYNzcXGk9JViWtKgKueMlkX3o4jXaJ1UHCjlfqwdGUU2GCOZZcy TE8LI8dl2ulq_eIElzjcHwn5nFTqkK0q6tS8__YSI8q6EjiLINO.LfbI2FkN3EHwZhP5kf_oJ.AT yrIoc8s_2F79ruZJXzsgwcPWjARepziFAKasvviny7bXZFNvvGP.edce7nywmVLHrrJAdBTJxrmx GwZYiTCCkNcWs9T.p5g.BXP.9CqQ4bSqAc4bw9hNAmqKamjajLh1KuqLzEk2qEEZ2hmdwEzOSoWK dAnzEOgmJkhgD8UEjj.l_Ow1gkSrDw.OMKGLtGt2GHWSwD0pdCgcKI5eyf9l08xrVCwx5GP0A_mq 61MkiWPuKU5rCaeiwO80KGLRUSI28nwFM2KMVDaM5JPN0WVTSH9oXOPqXBXNWTae8TPmlQnMAu67 kHGvauC1N9BqU2Zhub9nM464DUFLeBlbe65xNBIy7Ur0cF2mE0vtvfKyVgHdlYAqtULR9j2w9TGe H9bblp7swcOWTs8.Qg7dFt7kWNGuf3I2m7rDPMYwy
Received: from by; Mon, 24 Oct 2016 12:49:29 +0000; 1477313369.878
Date: Mon, 24 Oct 2016 12:49:29 +0000
To: Tero Kivinen <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: Timing Attacks
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Oct 2016 12:49:36 -0000


From: Tero Kivinen <> 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. 

[Tero's comments below]
>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...


Tero, I am a bit reluctant to be completely specific as I think that will give people ideas that they might not have had before.

That is, before I say it, few people might think to launch such attacks but if I spell it out clearly that such attacks can be launched, then people who might not even have thought that this was possible, will now think that they can do it.

Let me think a bit about how to phrase this.