Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jul 2001 19:04:54 -0500 (CDT)
From:      Mike Silbersack <silby@silby.com>
To:        Barney Wolff <barney@databus.com>
Cc:        <arch@FreeBSD.ORG>, <net@FreeBSD.ORG>
Subject:   Re: TCP sequence numbers: RFC1948 patch ready for testing
Message-ID:  <20010725185434.V35719-100000@achilles.silby.com>
In-Reply-To: <20010725032805.A21133@tp.databus.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 25 Jul 2001, Barney Wolff wrote:

> 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.

I'll go ahead and remove the isn_offset addition.  I'm not really willing
to remove the rekeying, though; we can't say that a faster method of brute
force attack will not arise.  Would a longer rekeying interval such as a
day or two suffice?  I'm not concerned about rekeying breaking a few
connections given that it will only happen occasionally.

> 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.

Doh!  I'll fix that in the next rev of the patch.

> 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.

Will do as well.

> 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?

I didn't think second-guessing the random dev would be a worthwhile
endeavor, as it would probably just lead to less entropy.  (Especially
given that noone would ever set the configureable secret.)

However, boot time randomness is a valid concern.  We're slightly lucky in
that the initial keying doesn't occur until the first connection, which
isn't at a fixed time in the kernel startup, but is rather dependant on
usage of the box.  I'll check with Mark Murray on this.  (And in 4.x, I'll
use read_random_unlimited so that the entropy doesn't get truncated.)

Thanks for the comments,

Mike "Silby" Silbersack

>
> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010725185434.V35719-100000>