Re: [secdir] Secdir review of draft-ietf-tsvwg-port-randomization-06.txt

Lars Eggert <lars.eggert@nokia.com> Tue, 02 March 2010 14:30 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AAA3A8A86; Tue, 2 Mar 2010 06:30:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.308
X-Spam-Level:
X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM0PEvfFF+bA; Tue, 2 Mar 2010 06:30:05 -0800 (PST)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4A8A43A8A85; Tue, 2 Mar 2010 06:30:05 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o22ESqmB016958; Tue, 2 Mar 2010 08:29:00 -0600
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 16:28:25 +0200
Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 16:28:25 +0200
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o22ESM2V024469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 16:28:23 +0200
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/signed; boundary="Apple-Mail-40--677400384"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <4B8CBEC1.1080203@gont.com.ar>
Date: Tue, 02 Mar 2010 06:28:11 -0800
Message-Id: <7E759E79-2154-476C-BD31-F8E0F1483D76@nokia.com>
References: <D80EDFF2AD83E648BD1164257B9B09120E1B46FD@TK5EX14MBXC115.redmond.corp.microsoft.com> <4B8CBEC1.1080203@gont.com.ar>
To: Fernando Gont <fernando@gont.com.ar>
X-Mailer: Apple Mail (2.1077)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Tue, 02 Mar 2010 16:28:16 +0200 (EET)
X-OriginalArrivalTime: 02 Mar 2010 14:28:25.0583 (UTC) FILETIME=[9E8FFFF0:01CABA14]
X-Nokia-AV: Clean
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "secdir@ietf.org" <secdir@ietf.org>, "micheal.larsen@tietoenator.com" <micheal.larsen@tietoenator.com>, "jmpolk@cisco.com" <jmpolk@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-port-randomization-06.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 02 Mar 2010 14:30:06 -0000

Hi,

when you make some of the text changes that Charlie suggested, please make them in a way that doesn't break what the document says about [Allman]. (Mark Allman ran some tests with some of the algorithms in this document, and if we change their description retroactively, it may affect what we can say about his effort.)

On 2010-3-1, at 23:31, Fernando Gont wrote:
>> Detailed non-security relevant comments:
>> 
>> The document is titled "Transport Protocol Port Randomization
>> Recommendations", but it doesn't really make recommendations. It
>> enumerates current practice and calls out the pros and cons, but it
>> doesn't really recommend what an implementer should do. That's
>> probably OK, but it seemed a bit odd.

this came up during the WG discussion. If I remember correctly, the document is the way it is because the WG felt that multiple schemes work well, and because this is not something that requires interoperability, there was no strong need to pick a "winner".

Lars