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

<nalini.elkins@insidethestack.com> Mon, 19 September 2016 14:57 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 6BEF312B3FF for <secdir@ietfa.amsl.com>; Mon, 19 Sep 2016 07:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 IfrExeBCIAfN for <secdir@ietfa.amsl.com>; Mon, 19 Sep 2016 07:57:18 -0700 (PDT)
Received: from nm28-vm1.bullet.mail.ne1.yahoo.com (nm28-vm1.bullet.mail.ne1.yahoo.com [98.138.91.35]) (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 0526A12B400 for <secdir@ietf.org>; Mon, 19 Sep 2016 07:57:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1474297036; bh=6toqydDOLjFbTusQU6VZ7XJW2qE4lBPmEZi6h4ETuDY=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Q9FM1buA7NVLD0prCaJKrTy4kaTzNqyepjWeiBYVamaO/buzWjHqmqZ9+gD2l2/8JimVpU6ZljJ+SsI70+p+/fOgRUO5DQjpJ6P9BqSiHq5aoG/jAm4/RLKQx4faCvjHL3SMRJ8v/LK7Rsf5f6Pwt9EMf+GZbk7TzqN34GggMOlagccNIXeXgjqsEV4CLJu02YsgzlxtkBSs1xB1OrOwUHT3NBO6/Yz5hr8aUT+Yc8hyVf16b96HbfO8xrjp/aGnvXYr9OIrXjiAAvofZdb5NXDAwzUB567WoHNi1O0A3tLgV3d7hM4zh8G0tCED7qwzKG4MuPV2Uqzwtcfb9TC9lw==
Received: from [98.138.226.180] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2016 14:57:16 -0000
Received: from [98.138.89.192] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 19 Sep 2016 14:57:16 -0000
Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP; 19 Sep 2016 14:57:16 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 83775.29007.bm@omp1050.mail.ne1.yahoo.com
X-YMail-OSG: fmtgN1AVM1lQ6.mq0E8O.jJqykCY7b9vubF5fQcTjxatPHDAYZWepfPdIiMu3CJ _frK1HqWikX_I7aDsT4gFRMSbGXzUKumbAs6zXpWihPRXF1tETRo3SXQt.UXnm5OdTnVy4y2keNE mdOiJrHY.l98wOVG76PQTboYaEckzn9MNY9AuUzDxPNGneyWU8u0IGSqpJSnE32bnsMCwO0u0VOb 4s3iUjabSAiXv3QICZkR2B.W6J1UJZqnj_dCAL01YGuGb6Ckl7Ska7u0dVI_DGvAtbQz_FC4xLnw vYfmeX6hTUxFayCNSHqeXXFVQyMyh16ls0rpvBdGUgr6urfjpYhaS9wvxsWx7TYAdv_DbSwJ1aqJ WCM984VjQm3kM80fX1JwqNylxjT3CMbg3XsrIQXpvCR0dmpL4G.ej5m8QD6XY0ucK9Oj5EP8VuPL XkytjL5YvTqu_a5eFmufFcyHyZF2A94qIY8BIajj6lWtf3lpPQe_n.Z7QQjwWLCMQmuHzCfbL.Rp xcFTvAldC1G_hLjyKPNPdZLxESra3SsXgpBhGcHxA9Mey6fogM2_tJUUJ8FAThkCjAy2Trj55
Received: from jws100105.mail.ne1.yahoo.com by sendmailws133.mail.ne1.yahoo.com; Mon, 19 Sep 2016 14:57:15 +0000; 1474297035.655
Date: Mon, 19 Sep 2016 14:57:15 +0000
From: nalini.elkins@insidethestack.com
To: Tero Kivinen <kivinen@iki.fi>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" <draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org>
Message-ID: <2079549486.943099.1474297035246@mail.yahoo.com>
In-Reply-To: <22495.62038.771947.984586@fireball.acr.fi>
References: <22495.62038.771947.984586@fireball.acr.fi>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_943097_163803426.1474297035239"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/YBSNz_kugHLYo2Xf5Rj50ciluOU>
Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05
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: Mon, 19 Sep 2016 14:57:22 -0000

Tero,
Thank you for your comments.  We will review and get back to you on them later today.  But, first, let me address one thing which may be a misunderstanding of PDM.
1.  PDM is OFF initially at the end hosts (client and server)
2.  It is turned ON for diagnostics then turned OFF afterwards.  If someone chooses to leave PDM ON always, then that is explicitly chosen for their network.
3.  PDM is an OPTIONAL feature.  One may choose not to implement it at all.

To address some of your comments about leakage, etc.
Let's discuss how this might happen:
1.  Attacker obtains access to either or both end host client and server and turns on PDM 
2.  Attacker watches passively.
Actually the problem is 1.  If you have done that, what do you need PDM for?   Many other things can be found - such as type of device, etc without resorting to PDM.  Thanks,
Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360

      From: Tero Kivinen <kivinen@iki.fi>
 To: iesg@ietf.org; secdir@ietf.org; draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org 
 Sent: Monday, September 19, 2016 7:12 AM
 Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-05
   
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes adding new IPv6 destination option header to
allow performance metrics calculations.

I think this document has serious issues.

It proposes that the new Destination option MUST be put before the ESP
so it is sent in clear. This will leak out the traffic information
from the ESP, allowing easy traffic analysis of encrypted packets, as
passive attacker can see which encrypted ESP packets belong to which
5-tuple flow. The PDM option header includes the incrementing sequence
numbers, so checking those will allow see which packet belongs to
which flow.

It claims that PDM MUST be placed before the ESP header in order to
work, which is untrue. This is destination option, thus it is meant to
be checked on the destination host, i.e., the packet capture after the
ESP decryption will allow seeing the PDM header values without issues.

--

Also the Time Base definations seem to be inconsistent. The section
3.2 says:

  That is, for a value of 00 in the Time Base field, a value of 1 in
  the DELTA fields indicates 1 microsecond.

Section 4.4 on other hand claims:

  That is, for a value of 00 in the Time Base field, a value of 1 in
  the DELTA fields indicates 1 picosecond.

On the other hand looking at the table in both 3.2 and 4.4 it seems
that time base value field value of 00 means milliseconds, not
microseconds or picoseconds.

Again section 4.5 says that "TimeBase of picosecond (or 00)", and
again I think picoseconds was supposed to be Time Base of 11...

The whole section 4 seems to be wierd. It is talking about different
encodings, and time units on different systems, and it also talks
about the limitations on TCP Timestamp Option, but this option uses
different encoding so I have no idea why this text is here. It would
be more useful to count what are the limits on the encoding method
used here (16 bit value, 7 bit signed scaling value), instead of what
some other option use.

In section 5.3 in the example it converts 4 seconds to hex value of
3A35 and scale of 25. On the other hand it is using milliseconds as
Time Base, so I think those values are wrong, i.e. 4 seconds in
milliseconds is 4000 milliseconds, thus FA0 with scale of 0 would be
correct represetnation. Same mistake in 5.4.

--

I skipped most of the section 6 and 7, so cannot say if similar
mistakes are in those sections.

--

The section 8 is wrong as it claims

    "PDM does not introduce any new security weakness."

while this will leak lots of information about the traffic flows
inside the encrypted transport mode ESP packets.

Also another thing the PDM leaks is exact host timings, i.e., it can
be used to launch timing attacks against crypto protocols. In general
those are hard as it is very hard to know how much of n ms rtt is
network delay and how much was the actual host processing the packet.
Now if we can see that that host used 123 nanoseconds to process the
signature verification packet, and next time it uses 1755 nanoseconds,
this might allow attacker to get information out from the key. The
actual round trip times might have been 123 ms in both cases, and the
1 microsecond difference in the processing time would have been lost
by the network latencies.

In addition to that the abstract is not very clear, it does not do
very good job of telling that this draft tries to do, and having the
Background section to duplicate most of that text does not still what
this document really tries to do. 
-- 
kivinen@iki.fi