Re: [dhcwg] Order of options for DHCP Anonymity profile

Tomek Mrugalski <tomasz.mrugalski@gmail.com> Mon, 31 August 2015 18:56 UTC

Return-Path: <tomasz.mrugalski@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B1A1B59C4 for <dhcwg@ietfa.amsl.com>; Mon, 31 Aug 2015 11:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 XqpcjlqgY2gF for <dhcwg@ietfa.amsl.com>; Mon, 31 Aug 2015 11:56:56 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (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 0B3C41B59C0 for <dhcwg@ietf.org>; Mon, 31 Aug 2015 11:56:56 -0700 (PDT)
Received: by lbbtg9 with SMTP id tg9so65987640lbb.1 for <dhcwg@ietf.org>; Mon, 31 Aug 2015 11:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=bHI3vsGLRYGqF772koSuS2zgqwjgkIVxNRoz/Rmuhdo=; b=KHuCip4R4duBlISoXJ8Id6XuOpUzxAeACpkNjEK/Kzv7xYHFaoCJXaN+DDtTjWpXYl 5IMZ9dEnuf3BEiWAymrD2XKjwDY/6l7R9pvgPPxCfpbJzC/6uokCaEOidHXM5JD2poI5 Cn1J6IFMHcoG5po74KcVEGxbHiNvgGp1/EHm+fgE+GJSItLC41EQIj2f+VjAhXtt4+bd hbcG9Uk79wRlly6sOx0zGTZxv5sAPlVjxFL8VjuscT90CiOJv6iZvkF9+0tvrN6Qcx5A eAE+FkyyUEkhoxFwRu7RwXOz1217SKQw+LzciU3ueHDvtsV3ueHR2AfItYBpeYEr1Q2Z 2mqg==
X-Received: by 10.152.27.10 with SMTP id p10mr11208471lag.89.1441047414286; Mon, 31 Aug 2015 11:56:54 -0700 (PDT)
Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by smtp.googlemail.com with ESMTPSA id t5sm3306168lat.3.2015.08.31.11.56.52 for <dhcwg@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Aug 2015 11:56:53 -0700 (PDT)
To: dhcwg@ietf.org
References: <DM2PR0301MB0655D1C7800B593A3C6268A1A86C0@DM2PR0301MB0655.namprd03.prod.outlook.com> <55E34736.60609@s-carlsen.dk> <489D13FBFA9B3E41812EA89F188F018E1CC5EE54@xmb-rcd-x04.cisco.com>
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55E4A374.4090102@gmail.com>
Date: Mon, 31 Aug 2015 20:56:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CC5EE54@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/VHzrirgHZZM7ARZ4ApSAFvjjwlw>
Subject: Re: [dhcwg] Order of options for DHCP Anonymity profile
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 18:56:58 -0000

On 31.08.2015 16:20, Bernie Volz (volz) wrote:
> Ordering by option number seems a fine (and simpler) approach. The
> differences in options requested might still make fingerprinting
> possible (especially for clients that ask for more unusual options).
By sending options ordered you would disclose the desire for anonymity.
It is obvious from the first packet intercepted.

Sten said that the randomization function might be recognizable. That's
technically true, but for all reasonably good randomizations it would
require gathering large number of packets before you could draw any
statistically significant conclusions.

Christian said that the order of options comes from how the software
processes the packet. I understand that. But I think the conclusion
coming out of it is somewhat weak. You say that it's doable to order
options by option code but it's too much effort to randomly reshuffle
them? In both cases that would likely be a step conducted at the final
steps of packet processing, shortly before sending it over the wire.

I still think that randomizing the order of both options and option
codes in PRL/ORO is the way to go. If you strongly object to that,
perhaps the text could say that the client SHOULD randomize, but if it's
not possible for whatever reason, it MAY send options/option codes
ordered by option number.

Tomek