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

Lars Eggert <lars.eggert@nokia.com> Thu, 04 March 2010 09:51 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 53A8A3A8746; Thu, 4 Mar 2010 01:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.411
X-Spam-Level:
X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 E8oS13skyst5; Thu, 4 Mar 2010 01:51:58 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C59EA3A845C; Thu, 4 Mar 2010 01:51:57 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o249ocGk022620; Thu, 4 Mar 2010 11:50:58 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 11:50:56 +0200
Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 11:50:55 +0200
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o249ostU023194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Mar 2010 11:50:54 +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-5--521251048; protocol="application/pkcs7-signature"; micalg=sha1
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <4B8F326C.4090804@gont.com.ar>
Date: Thu, 4 Mar 2010 10:50:41 +0100
Message-Id: <7BE92F3B-A1EC-43A9-9D3F-10D273D67678@nokia.com>
References: <D80EDFF2AD83E648BD1164257B9B09120E1B46FD@TK5EX14MBXC115.redmond.corp.microsoft.com> <4B8CBEC1.1080203@gont.com.ar> <7E759E79-2154-476C-BD31-F8E0F1483D76@nokia.com> <4B8F326C.4090804@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]); Thu, 04 Mar 2010 11:50:47 +0200 (EET)
X-OriginalArrivalTime: 04 Mar 2010 09:50:55.0587 (UTC) FILETIME=[2F37BB30:01CABB80]
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: Thu, 04 Mar 2010 09:51:59 -0000

Hi,

On 2010-3-4, at 5:09, Fernando Gont wrote:
>> 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.)
> 
> I don't think the resulting changes would affect the results in
> [Allman]. For instance, I'd bet the random() function he used provided
> 32-bit pseudo-random numbers (rathern than 16-bit numbers, as previously
> suggested in the I-D).

please check with Mark on this. I believe you are right, but it's better to be sure than to bet.

>>>> 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".
> 
> I didn't apply any change in response to this. (Just for the record, *I*
> would have been happier with the document recommending a particular
> algorithm... but I do see the point of why the wg didn't think so).

I would have been happier, too, but I think the argument was that we didn't want to needlessly say that some existing implementations don't comply to the recommendations in the RFC when it doesn't matter because their algorithm is good enough.

Lars