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

Fernando Gont <fernando@gont.com.ar> Wed, 15 December 2010 20:56 UTC

Return-Path: <fernando.gont.netbook.win@gmail.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 B63A13A706A; Wed, 15 Dec 2010 12:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Level:
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 8XG4zNt2GYIh; Wed, 15 Dec 2010 12:56:49 -0800 (PST)
Received: from mail-gy0-f194.google.com (mail-gy0-f194.google.com [209.85.160.194]) by core3.amsl.com (Postfix) with ESMTP id A133F3A6FB7; Wed, 15 Dec 2010 12:56:49 -0800 (PST)
Received: by gyf1 with SMTP id 1so519015gyf.1 for <multiple recipients>; Wed, 15 Dec 2010 12:58:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=IjJpCKAgf0IUIz5O7belmk0IOtE5OV/cTPNoY6Gzagc=; b=XOkKQPlczVc7cmCmycw5fRMJqS/V8mxTQeGZUeHlDW+diks1iiI3ut+E/IYuoFaWRW Hf3+HMbXgxtAA2rK+pgx0jMNSsrmYLEAERTcKqmSh1+nTX7OZup2mQAkgXAbrhyrx/KK tL5LMtaTSBgjDMOOuy9pFtFjnVSRBw2xrxU1c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=vD/64/lk/ZNoHAd88d+P6uGxmwK3KM7T7E5KR2LJe7l9nCBFd3T3NiWJt16Dwe2I3Z fWs1F7+q/9BZIyeHh7P5g9Ms/QU84rjjPtpivSchtROvHFJ96z7tXPKYXFuIDH45If02 4f9lwf7TeQ53IQY04O7VAIEvODw28HdCAqA70=
Received: by 10.150.138.17 with SMTP id l17mr10887953ybd.82.1292446712403; Wed, 15 Dec 2010 12:58:32 -0800 (PST)
Received: from [192.168.2.4] ([186.137.76.188]) by mx.google.com with ESMTPS id q4sm4206173ybe.12.2010.12.15.12.58.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Dec 2010 12:58:31 -0800 (PST)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4D092BEC.7090209@gont.com.ar>
Date: Wed, 15 Dec 2010 17:58:20 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: "Scott G. Kelly" <scott@hyperthought.com>
References: <1292437905.046510307@192.168.2.229>
In-Reply-To: <1292437905.046510307@192.168.2.229>
X-Enigmail-Version: 1.1.1
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=UTF-8
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: Wed, 15 Dec 2010 20:56:50 -0000

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,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1