Re: [secdir] secdir review of draft-ietf-tcpm-tcp-timestamps-02

"Scott G. Kelly" <scott@hyperthought.com> Thu, 16 December 2010 04:44 UTC

Return-Path: <scott@hyperthought.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 33A7728C13A for <secdir@core3.amsl.com>; Wed, 15 Dec 2010 20:44:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 1J-vd8GNe9+g for <secdir@core3.amsl.com>; Wed, 15 Dec 2010 20:44:53 -0800 (PST)
Received: from smtp192.dfw.emailsrvr.com (smtp192.dfw.emailsrvr.com [67.192.241.192]) by core3.amsl.com (Postfix) with ESMTP id 514D928C153 for <secdir@ietf.org>; Wed, 15 Dec 2010 20:44:53 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id E3CA13C8374; Wed, 15 Dec 2010 23:46:36 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id 42B623C81B9; Wed, 15 Dec 2010 23:46:36 -0500 (EST)
Message-ID: <4D0999AB.7020705@hyperthought.com>
Date: Wed, 15 Dec 2010 20:46:35 -0800
From: "Scott G. Kelly" <scott@hyperthought.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <1292437905.046510307@192.168.2.229> <4D092BEC.7090209@gont.com.ar>
In-Reply-To: <4D092BEC.7090209@gont.com.ar>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-tcpm-tcp-timestamps.all@tools.ietf.org, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcp-timestamps-02
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, 16 Dec 2010 04:44:54 -0000

Hi Fernando,

Your proposed security considerations text does tie the two statements 
together better.

Thanks,

Scott

On 12/15/10 12:58 PM, Fernando Gont wrote:
> Hi, Scott,
>
> Thanks so much for your feedback! Please find my comments inline....
>
> On 15/12/2010 03:31 p.m., Scott G. Kelly wrote:
>
>> Minor nits:
>>
>> The last paragraph of section 3 includes this sentence:
>>
>> "As noted in [Silbersack], such randomization schemes break prevent
>> the mechanism proposed in this document from recycling connections
>> that are in the TIME-WAIT state."
>>
>> Might want to remove the word "break".
> I'll rephrase to:
>
> ---- cut here ----
>      As noted in [Silbersack], such randomization schemes may
>      prevent the mechanism proposed in this document from recycling
>      connections that are in the TIME-WAIT state.
> ---- cut here ----
>
>
>> The security considerations has this paragraph:
>>
>> While the algorithm described in this document for processing
>> incoming SYN segments would benefit from TCP timestamps that are
>> monotonically-increasing across connections, this document does not
>> propose any specific algorithm for generating timestamps, nor does
>> it require monotonically-increasing timestamps across connections.
>>
>> Maybe I'm just naive, but based on the information given, I don't
>> understand why this statement is in the security considerations
>> section. Does the failure to propose any specific algorithms have
>> security consideration (that might be more obvious to someone who
>> reads [CPNI-TCP])?
> The most obvious implementation of an algorithm that would produce
> monotonically-increasing timestamps across connections would be to have
> a global timestamp clock that is initialized to a fixed value (e.g.,
> zero) at systemp boot-strap time, and that is incremented as specified
> in RFC 1323. Such an algorithm could, e.g., leak information such as
> system uptime.
>
> How about if I re-write the SecCons as follows:
>
> ---- cut here ----
>     While the algorithm described in this document for processing
>     incoming SYN segments would benefit from TCP timestamps that are
>     monotonically-increasing across connections, this document does not
>     propose any specific algorithm for generating timestamps, nor does it
>     require monotonically-increasing timestamps across connections.
>     [CPNI-TCP] contains a detailed discussion of the security
>     implications of TCP timestamps and of different Timestamps
>     generation algorithms.
> ---- cut here ----
>
> ?
>
> Thanks!
>
> Kind regards,