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. > > >
- [ippm] Alissa Cooper's No Objection on draft-ietf… Alissa Cooper
- Re: [ippm] Alissa Cooper's No Objection on draft-… Nalini J Elkins
- Re: [ippm] Alissa Cooper's No Objection on draft-… Spencer Dawkins at IETF
- Re: [ippm] Alissa Cooper's No Objection on draft-… Alissa Cooper
- Re: [ippm] Alissa Cooper's No Objection on draft-… Nalini J Elkins