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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Sun, 25 June 2017 19:09 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 ED60C120726; Sun, 25 Jun 2017 12:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9Q9KiA9k-aRC; Sun, 25 Jun 2017 12:09:14 -0700 (PDT)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 3DA0A1200FC; Sun, 25 Jun 2017 12:09:14 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id 84so23836736ybe.0; Sun, 25 Jun 2017 12:09:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MP0qI9wb2rzTBz5AHkbBLPI9x0WPcoojKZo0izWq++Y=; b=Vxj6U3c2ccx0c4V5uchFhoNPoI0FRn4b67WID+wkLQey0bPnvIGXmetO7G4NtXPdaY L02jHVUaO+yejXkC07L1ZwUks2190li8mDpbTUsksHWFJ3hhftVPkyCHiIIc6h5h/WZw W4q2HG4aKhZ/fC+U5SSy0zpzUXjRbx/j6lX9SvqmdcFILxaDl55o37QibtiA+jyZhrIF tjDLVjceR5wO/GRGkmjxmmbBcOmPV4I5koabpvv/IJ2c8oyMTodbQjODj7p5QfG2X/Hx xvIyXflD9lQMyTom2kasFnLW7n5SPaCNL0HTlXAJZ5wDdMUYtv56OXK5G+3tzDHQKMcW OSwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MP0qI9wb2rzTBz5AHkbBLPI9x0WPcoojKZo0izWq++Y=; b=dMWjhXTb/eZC316qbbUG465rOrCuVgCxQ/a7asmTqKtfx2PKt6955lT8q7uNDE1/EC uBVfIt7DQlRqd3QKeUKw6AF6sM2UMNAV74Rvz4EfrEEzx9Bql1AixvfjMjHzu+B90/Ov cQhcUBN8wN8hErmHi61NKTvSK2e8g47kqHunYaDAnS1XHKSyEpZXEx/ykzkOMBII3aKL wKog7GMDaP9YVnxKgv89OS6hwCb4LpLG4XAbcvR0rLGo5Lnn4sib5RYxm56XqT8jTPKQ XVSiWD/F1a7EZd7+rgqidTEv3RSdntVX43Zb8DRS3pweHYvSlAajhTz13Xu7G+AVfrzx 0wkA==
X-Gm-Message-State: AKS2vOwmMpyA/buhBhlfRC9/JQkchHzxSN0k+g5CYSR4qIYdvau41/Xa Q1NnNuzjkospEGMOcIA66PeuXu6LKA==
X-Received: by 10.37.204.138 with SMTP id l132mr12744664ybf.176.1498417753451; Sun, 25 Jun 2017 12:09:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.104.144 with HTTP; Sun, 25 Jun 2017 12:09:13 -0700 (PDT)
In-Reply-To: <922169529.4233696.1495466806431@mail.yahoo.com>
References: <149200885746.15718.798617550888585150.idtracker@ietfa.amsl.com> <922169529.4233696.1495466806431@mail.yahoo.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Sun, 25 Jun 2017 14:09:13 -0500
Message-ID: <CAKKJt-dFKE-iS8iFTyVg5SbA+m_GphcEkuocrHe1vZSXbToARg@mail.gmail.com>
To: Nalini J Elkins <nalini.elkins@insidethestack.com>
Cc: Alissa Cooper <alissa@cooperw.in>, The 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>
Content-Type: multipart/alternative; boundary="94eb2c075b32eb7bef0552cd912a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/90SKvPP4txjTFrmyhTrNGpbIE6s>
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: Sun, 25 Jun 2017 19:09:17 -0000

Hi, Alissa,

On Mon, May 22, 2017 at 10:26 AM, Nalini J Elkins <
nalini.elkins@insidethestack.com> wrote:

> Alissa,
>
> Please let me know if you are OK with the proposed change.
>

The change looks OK to me, but I'm not the expert on this. Could you let us
know what you think?

Thanks,

Spencer


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