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

<nalini.elkins@insidethestack.com> Fri, 23 September 2016 15:24 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 001C712B368 for <secdir@ietfa.amsl.com>; Fri, 23 Sep 2016 08:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
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=ham 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 SGwXtXGYeBx0 for <secdir@ietfa.amsl.com>; Fri, 23 Sep 2016 08:24:30 -0700 (PDT)
Received: from nm12-vm6.bullet.mail.ne1.yahoo.com (nm12-vm6.bullet.mail.ne1.yahoo.com [98.138.91.105]) (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 19A8112B31C for <secdir@ietf.org>; Fri, 23 Sep 2016 08:24:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1474644269; bh=lRUbiFWmdpFXuFcMraCpOI2uVJZ3RvucyEx4+lQOex8=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=mGGYq+JF9LM9VXMnY8oinjlU6U3IUeB9DvPqjqMLm6s1HMzuXqzqOKWdZbtRDqa84/lfsOpU3gK34TWIywzlA0HtRWYOez98gsV70rL1eA14JLQaBzmQr7ZZKdTDy8l3bkmBbjz5vqd8sZm/DADygMaBiTlxaserKBUp8Zerb4A+sqJDmrI8y86BUbu9Wuta0SNcNbJQy/fllKg5Q6XBRo2/ixUv/M7t27DpjMLJ38z8z0XGv8A+8RnUZusxbi9fYIO1eV9M+e2XfATC3rufC3N+A6H3SvzjhS1ZxeZ0+NgfSPXglnkupwarNfqH0dgfVxwdzLcp25875OQ2lFJJ4Q==
Received: from [98.138.100.111] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 23 Sep 2016 15:24:29 -0000
Received: from [98.138.226.161] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 23 Sep 2016 15:24:29 -0000
Received: from [127.0.0.1] by omp1062.mail.ne1.yahoo.com with NNFMP; 23 Sep 2016 15:24:29 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 180228.27091.bm@omp1062.mail.ne1.yahoo.com
X-YMail-OSG: lsCbeegVM1neEpvQa8QTPQQBxTTdcwabTzzY88qxMSdgKhkVNOlQQ5czliU_.v0 5OOdnwcVpmYz2DnbqhGxTZFjiG9gmJm_vpNM3NC9L.3QrZslHOzYa9jSqYoGV4LJkVs7CAtOKfv6 ydXm4oWfktFeKd6ThMag6ZSYZhhLB1R9sTRSN_L3WExzMQZ6wPb.xQYinxTiVSGPlkKfLgkRUE7G vSHLVwvMwLBYpjBqxQ_P94fX0xhUqFRhEQflxhk3sE5BFpZF2ypQcMQup.IGjaYFDOSSkMJ_qDSf MxUDTv3_IwardSCje2bM2dAwanWJxEsnUfMON6KavB_w7iT74h__2zlgLWPLBZq7bHTGWGSU12PP Ztmv5znxAl.zzVvjwEQ0.VbDYp9cP8yrllymIsUTG.MoeIq_BonjTkEEtke_2MizAeP6Z8MwGa1n uPNPrCn0vWBZn_cyOM_Q_I20.symae7dymUbCs9uxp2XXnCXI6T_nzT_X_Py7JKiDWT6nDs_Fqsd 5LXnNp44SXnyR.ZZ.3zZfdZ4Kv1vi1v560qUUV1UxrVyn4tdUiMtnQuthoqFTsb9bs4IXtXBq
Received: from jws10035.mail.ne1.yahoo.com by sendmailws103.mail.ne1.yahoo.com; Fri, 23 Sep 2016 15:24:28 +0000; 1474644268.780
Date: Fri, 23 Sep 2016 15:24:28 +0000 (UTC)
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: <1264225155.363685.1474644268281@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: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/9PBMzIiO5VjgzTQmhkduGsg1eg4>
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: Fri, 23 Sep 2016 15:24:32 -0000

Tero,

Thanks for your comments.  We have posted a new draft with corrections at: 
https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-06

Our responses inline.
 
Nalini Elkins

Inside 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 is not clear to me how knowing which ESP packets belong to which traffic flow helps a passive attacker.   The attacker still does not know what is in the packet - the contents of the payload.  Indeed, ESP would normally mask TCP or UDP ports.  With PDM you can tell that there ARE multiple flows but you don't know if they are TCP, UDP, ICMP or anything else.  Most importantly, you don't know what is in the payload. 
 
If one follows the thinking of your objection, isn't any encrypted flow over TCP or UDP a problem since a passive attacker knows the 5-tuple for such flows?  For example, all TLS flows can be analyzed for traffic in your sense.  So, a flow over TLS (without PDM) actually leaks more information than an ESP flow WITH PDM.  Because with TLS, we even know that the flow is TCP and the port number.   Neither of which you know with PDM with ESP.
 
>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...

Thanks for catching those.  Should now be fixed.

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

Thanks.  Should now be fixed.

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

Thanks. Should now be fixed.

--

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.

Please see above.

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



1. The intent of PDM is as a diagnostic feature.  PDM is OFF initially at the end hosts (client and server).  It is turned ON for diagnostics and then turned OFF afterwards.  If someone chooses to leave PDM ON always, then that is explicitly chosen.  Also, PDM is an OPTIONAL feature.  Either client or server operating system may choose not to implement it or use it. 


2. In your example above, it assumes that the signature verification packet (please let me know which exact packet and protocol you are referring to) is passing in the clear so that the attacker knows that it is the signature verification packet.  Possibly this is also a problem. 


3.  Protocols often use blinding techniques to remove correlations between key and encryption time.   Other cryptographic algorithms can be implemented (or masked by a proxy) in a way that reduces or eliminates data dependent timing information.   So if timing information is being leaked, this is a flaw in the algorithm or the protocol.   In this case, we may be "blaming the messenger".  PDM is only reporting what is done.  The algorithm or protocol is the problem. 


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

If you can give me a hint as to what is not clear or what you think this draft DOES propose, then we will be happy to rewrite the abstract / background section.


-- kivinen@iki.fi