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

<nalini.elkins@insidethestack.com> Tue, 10 January 2017 03:45 UTC

Return-Path: <nalini.elkins@insidethestack.com>
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 3D78C129A48 for <secdir@ietfa.amsl.com>; Mon, 9 Jan 2017 19:45:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.756
X-Spam-Level:
X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 GCeap2Mvjagr for <secdir@ietfa.amsl.com>; Mon, 9 Jan 2017 19:45:47 -0800 (PST)
Received: from nm26-vm3.bullet.mail.gq1.yahoo.com (nm26-vm3.bullet.mail.gq1.yahoo.com [98.136.216.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8373612943D for <secdir@ietf.org>; Mon, 9 Jan 2017 19:45:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1484019947; bh=yOu9sGkUmOWtZBez//aoJjF3L25GbTftV0waWSaJfnY=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=dmpS8bYWbUVfmK1+rHEX5TlaakNX9jYv4IG205ed+i5J5I0Jzf9a2mzXkr3cInp+T1xw3JPCKR0ScGj5Y13jp/BG+f+2rYNQRiLuI4IoZWmllHGGXNZWfU/Lj7EcCVdkKI/DKEZMQkVY00Ztt9RNq8ySMIv0l+9x4ftfGFu6vWxxVMnBuDSMw/IfwVk1005nCk9pnHkB01+k3Ed8H/ImVth6jTpk8suZrpEX03HRWDx0/HvhMCd4KEuAEZWufY60iGmGICpK7fsw+9DolSfOXzFGqmqvqN3FsKztSimrLnh5c9uwBy/CpNYEYsC13DncWJjMXcHm2CAVnhO/CUS4UA==
Received: from [98.137.12.59] by nm26.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jan 2017 03:45:47 -0000
Received: from [98.137.12.224] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jan 2017 03:45:47 -0000
Received: from [127.0.0.1] by omp1032.mail.gq1.yahoo.com with NNFMP; 10 Jan 2017 03:45:47 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 24836.69817.bm@omp1032.mail.gq1.yahoo.com
X-YMail-OSG: r_ZmJ8QVM1k8.i.AvDYuLHPQPG1oUhYCphPreH1I6hRsUYSslLFru3kET5M90sr 6wJC7YFeT_FVXklQG0MVaJOcpzWwRg3XoL7ImzkAVWuvtX_RzpbxsYih4CmN4SGSJ0OGH610p22w mpVrQjG825ZOZzZRWPtRwqplIVavp1Q6.QeR35VL9e6UL_Gr0AzXyRegGA8HSeCHZJ5PBtV6lolD fqSDvigVbAGhQdbflIp9OWkH9eopL_xxRaFwPoQMW6dp8OdzGvmdeWQXQ2BozQBUUr4h1DttRGZN Zq5XKTvMhdkZu9Nv_Amrzf9VNnUoOP2YVlNjHVpZzawZm5iWZ1KIimKecj_3adk3sP8hsaDI0GID fYbczOAkf0YWBjL1V4HXgQtYm6WypNtwdHT3Q7lkheivpWUmqkdVV_u8XmxibUuHmc_QUHZqq4mO OTUIDFOPc8Q5Me9MJBmkB.RyvYO7IsktSwuphargWQpGZP23oJutKmMsBAg1KbLN6VO2JVVp3tq_ u5D_w9bbLd1zbxCZN_0W2qPYNWz7D3jtBnfTF7_OgPZsl09dLDeGryiezXltnRZF.
Received: from jws300048.mail.gq1.yahoo.com by sendmailws121.mail.gq1.yahoo.com; Tue, 10 Jan 2017 03:45:46 +0000; 1484019946.657
Date: Tue, 10 Jan 2017 03:45:46 +0000 (UTC)
From: <nalini.elkins@insidethestack.com>
To: Tero Kivinen <kivinen@iki.fi>
Message-ID: <970641405.98311.1484019946430@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
References: <970641405.98311.1484019946430.ref@mail.yahoo.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/11ZyBJjE1oMAQS1voTqBF3DTajE>
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
Reply-To: nalini.elkins@insidethestack.com
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 03:45:49 -0000

Tero,

I believe this is the last outstanding issue!  After we reach agreement, I will rewrite the draft to:

1) incorporate the new changes

2) incorporate the changes suggested by the Gen-Art reviewer.

This particular thread relates to timing attacks in the Security section.

nalini.elkins@insidethestack.com writes: 
>>> 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. 

>Security by obscurity never works. Attackers have much more time to 
>think and plan about attacks than people who are implementing code for 
>something unrelated. If you are too vague, people who are implementing 
>PDM or the crypto protocols, thinks that those attacks are impossible. 
>It is better to spell them out for those implementing those so they 
>can make needed security measures for those. 

>One of those security measures could for example be that PDM is 
>enabled only for certain ip-addresses, or only for some ports. Another 
>would be to enable it for certain timeperiod (for example for 1 hour), 
>so it can be made sure that PDM is not accidently left on after 
>debugging has been done etc. 

>> 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. 

>I think it is better to explain the attacks properly to the PDM 
>implementors, so they understand what kind of things they need to 
>think about when implementing PDM. Same thing for the people 
>implementing crypto protocols. They need to understand that with PDM 
>some things that used to be hard will be easy. 

>If you just give general warnings, that means that quite a lot of 
>implementors think that this text is just general text, not really 
>specific for this. So implementors might think it does not concern 
>them, and ignore the issue. 


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. 


Thanks,
Nalini