From owner-freebsd-arch Wed Jul 25 0:48:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by hub.freebsd.org (Postfix) with ESMTP id 5919F37B405; Wed, 25 Jul 2001 00:48:45 -0700 (PDT) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.11.4/8.11.4) id f6P7SA522199; Wed, 25 Jul 2001 03:28:10 -0400 (EDT) (envelope-from barney) Date: Wed, 25 Jul 2001 03:28:05 -0400 From: Barney Wolff To: Mike Silbersack Cc: arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: TCP sequence numbers: RFC1948 patch ready for testing Message-ID: <20010725032805.A21133@tp.databus.com> References: <20010724230813.A31803-200000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010724230813.A31803-200000@achilles.silby.com>; from silby@silby.com on Tue, Jul 24, 2001 at 11:19:57PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have a few comments :) 1. Rekeying is completely unnecessary - talking of brute-forcing the MD5 of a 32-byte random secret is fantasy, for the forseeable future. Similarly, isn_offset adds nothing real to security. 2. By rekeying you risk violating the monotonicity of the isn across the rekeying, which is the whole point of not just doing random isn. 3. Unless I'm confused, hz is typically 100 or 1000, meaning that the signed-32 tick counters you're relying on to trigger rekeying will flip sign and overflow within the typical uptime of a server. You risk having the test fail for a long time, if isn_reseed_time is a large positive and ticks has become negative before you get to test it. Of course that's no loss, imo. 4. As a nit, if you're going to do the rekeying check, do it only when you're actually going to do the md5 work, not before the test that may return arc4random. 5. You seem to have ignored 1948's advice to include some configurable secret in the hash - are we really sure that read_random gives good bits right after reboot? Regards, Barney Wolff On Tue, Jul 24, 2001 at 11:19:57PM -0500, Mike Silbersack wrote: > > Hello all, the RFC1948-like sequence number generation patch is ready for > testing. The patch included will apply cleanly to both a recent -current > and a recent -stable. I've spent a good deal of time looking at tcpdump > logs, and it looks good to me. > > Please test and review this if you feel comfortable doing so. If you do > not feel comfortable doing so, please simply test it instead. :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message