Re: [ippm] Alissa Cooper's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)

Alissa Cooper <alissa@cooperw.in> Fri, 30 June 2017 17:18 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA94131442; Fri, 30 Jun 2017 10:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=ap0PJ/Of; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I9wVuyWa
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 uw7HgPrrOrUW; Fri, 30 Jun 2017 10:18:53 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB82129AFE; Fri, 30 Jun 2017 10:18:53 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C2EE7207DA; Fri, 30 Jun 2017 13:18:52 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Fri, 30 Jun 2017 13:18:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=/vZrBg1POHSsbsT2v4fD0JgJ3yVVjwI68XZhHxOws O0=; b=ap0PJ/Of1MnrRa8IhT0Kz8rJGN6yAQfIRL4m7mQGApPQj0RZ82v2tE8h/ pzLjFolEs6jJw93hBsSYSW0UynlKnPnuZuk9jgj1APbrZPHGIbtiXkDw94xY8j5e Du+7VyQv6n5kQ44sgmwtw3pXhMij1KSUukwtSqSu+t8oLXXYlQrKR23+v8xFCMFp D1/zKcasgJvxqKzE7UtwYDVSdxGtcY0xCXAJGd89COKZMuxUAlA5sDrMN2JOH5Qk TxJoARYkXBSBqCjH5s050FdgNFwTD4d1qZHBRE4snJ+jQatPUKk+KjXUkAFOoPAt gioOe3ZL+Ezr+Zy2UNMLdxRV7ScYA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=/vZrBg1POHSsbsT2v4 fD0JgJ3yVVjwI68XZhHxOwsO0=; b=I9wVuyWaVNef4xo+WpAJgk4kYDXFZHWqfh Z3eFr0T70VnnVeIEDOjGFNxw26kDweh+vYab1JuuaIPlpB1yyZJ32yxTrVwsfPY7 hXNBJTVAOiqyCgxBXCVYcqZZDjTkzr4kIV3g3zoFVSTCRjX9bQ0O42e7KepGAYbH PdqVWCQMSXIpYrgzwch1+MG30+9aFb6yLOXbwRTl3ppTXQSLDKuFhoU92ETlYWoj L0SGjrYWtP6LpRHzbSPDnIcSbvdm9cB+w80yA5Y0V8BplSSm84XBUdeIHxMrYrIG 7jEJzSSZ26bfXYi8R6CanHXOC9840uZxbHJXiNku9DJ29DwLAZ9Q==
X-ME-Sender: <xms:_IdWWUqZ1YicssCrUTJ0pv6S7yfF8tjgHa0GvTnMlu263A1qUcCRfA>
X-Sasl-enc: vTGkJdvIXG8RMwndSc6BeFrgSdVnDqAta7jeMIHGZ3FR 1498843131
Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.167]) by mail.messagingengine.com (Postfix) with ESMTPA id D4FAE7E4AA; Fri, 30 Jun 2017 13:18:50 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E3B207BE-001A-42C7-A170-9AEB27D4AE38"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <922169529.4233696.1495466806431@mail.yahoo.com>
Date: Fri, 30 Jun 2017 13:18:49 -0400
Cc: IESG <iesg@ietf.org>, "draft-ietf-ippm-6man-pdm-option@ietf.org" <draft-ietf-ippm-6man-pdm-option@ietf.org>, Bill Cerveny <ietf@wjcerveny.com>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "acmorton@att.com" <acmorton@att.com>, "ippm@ietf.org" <ippm@ietf.org>
Message-Id: <4F5FBC6F-F92A-4A28-9A22-3EE9DD541CC4@cooperw.in>
References: <149200885746.15718.798617550888585150.idtracker@ietfa.amsl.com> <922169529.4233696.1495466806431@mail.yahoo.com>
To: Nalini J Elkins <nalini.elkins@insidethestack.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/gFs6dp1IL_VraWQhIKS4dKW-fWU>
Subject: Re: [ippm] Alissa Cooper's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jun 2017 17:18:56 -0000

Thanks, this seems better to me.
Alissa

> On May 22, 2017, at 11:26 AM, Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:
> 
> Alissa,
> 
> Please let me know if you are OK with the proposed change.
> 
> 
> 
> 
> >Alissa Cooper has entered the following ballot position for
> >draft-ietf-ippm-6man-pdm-option-09: No Objection
> 
> 
> >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> >for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> >The document, along with other ballot positions, can be found here:
> >https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ <https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/>
> 
> 
> 
> >----------------------------------------------------------------------
> >COMMENT:
> >----------------------------------------------------------------------
> 
> >The analysis in Sec 4.2 seems to be missing some considerations. In cases
> >where the packet payload is encrypted and the attacker does not have
> >access to the keys, the attacker does not in fact have access to the
> >entire packet, in which case PDM provides more information than a packet
> >without PDM. Also in those cases, it seems like including PDM information
> >would generally make a packet stream more susceptible to traffic analysis
> >insofar as the timing and sequence information may provide additional
> >indicators about the type of application in use, not just the speed of
> >the end host.
> 
> 
> Are you OK if I do the following:
> 
> 
> OLD
> ------
>  Since PDM passes in the clear, a concern arises as to whether the
>  data can be used to fingerprint the system or somehow obtain
>  information about the contents of the payload.  
> 
>  Let us discuss fingerprinting of the end host first. It is possible
>  that seeing the pattern of deltas or the absolute values could give
>  some information as to the speed of the end host - that is, if it is
>  a very fast system or an older, slow device.   This may be useful to
>  the attacker.  However, if the attacker has access to PDM, the
>  attacker also has access to the entire packet and could make such a
>  deduction based merely on the time frames elapsed between packets
>  WITHOUT PDM.  
> 
>  As far as deducing the content of the payload, it appears to us that
>  PDM is quite unhelpful in this regard.
> 
> 
> 
> New
> ------
> 
> Since PDM passes in the clear, a concern arises as to whether the
> data can be used to fingerprint the system or somehow obtain
> information about the contents of the payload.  
> 
> Let us discuss fingerprinting of the end host first. It is possible
> that seeing the pattern of deltas or the absolute values could give
> some information as to the speed of the end host - that is, if it is
> a very fast system or an older, slow device.   This may be useful to
> the attacker.  However, if the attacker has access to PDM, the
> attacker also has access to the entire packet and could make such a
> deduction based merely on the time frames elapsed between packets
> WITHOUT PDM.  
> 
> As far as deducing the content of the payload, it is conceivable
> that an attacker could attempt to deduce the type of application in
> use by noting the server time and payload length.   Having said that,
> some encryption algorithms attempt to obfuscate the packet length
> to avoid just such vulnerabilities.  In the future, encryption algorithms
> may wish to obfuscate the server time as well.  
> 
> 
>