[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Dec 2016 15:55:45 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Theodore Ts'o <tytso@....edu>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>, Jean-Philippe Aumasson
<jeanphilippe.aumasson@...il.com>, Hannes Frederic Sowa
<hannes@...essinduktion.org>, LKML <linux-kernel@...r.kernel.org>, Eric
Biggers <ebiggers3@...il.com>, "Daniel J . Bernstein" <djb@...yp.to>, David
Laight <David.Laight@...lab.com>, David Miller <davem@...emloft.net>, Andi
Kleen <ak@...ux.intel.com>, George Spelvin <linux@...encehorizons.net>,
kernel-hardening@...ts.openwall.com, Andy Lutomirski <luto@...capital.net>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, Tom Herbert
<tom@...bertland.com>, Vegard Nossum <vegard.nossum@...il.com>, Netdev
<netdev@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: HalfSipHash Acceptable Usage
On Tue, 2016-12-20 at 16:36 -0500, Theodore Ts'o wrote:
> On Mon, Dec 19, 2016 at 06:32:44PM +0100, Jason A. Donenfeld wrote:
> > 1) Anything that requires actual long-term security will use
> > SipHash2-4, with the 64-bit output and the 128-bit key. This includes
> > things like TCP sequence numbers. This seems pretty uncontroversial to
> > me. Seem okay to you?
>
> Um, why do TCP sequence numbers need long-term security? So long as
> you rekey every 5 minutes or so, TCP sequence numbers don't need any
> more security than that, since even if you break the key used to
> generate initial sequence numbers seven a minute or two later, any
> pending TCP connections will have timed out long before.
>
> See the security analysis done in RFC 6528[1], where among other
> things, it points out why MD5 is acceptable with periodic rekeying,
> although there is the concern that this could break certain hueristics
> used when establishing new connections during the TIME-WAIT state.
>
> [1] https://tools.ietf.org/html/rfc6528
We do not use rekeying for TCP ISN, not anymore after commit
6e5714eaf77d79ae1 (where we switched from MD4 to MD5 )
It might hurt some common cases and I do not believe it is mandated by a
current (ie not obsolete) RFC.
Our clock has a 64 ns resolution and 274 second period (commit
9b42c336d0641) (compared to 4 usec one in RFC 6528)
I do not see why SipHash, if faster than MD5 and more secure, would be a
problem.
Same for syncookies.
BTW, we probably should add a ratelimit on SYNACK retransmits,
because it seems that attackers understood linux kernels resist to
synfloods, and they (the bad guys) use reflection attacks.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
