lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 13 Jan 2022 14:30:39 +0100 From: Toke Høiland-Jørgensen <toke@...hat.com> To: Ard Biesheuvel <ardb@...nel.org>, Hannes Frederic Sowa <hannes@...essinduktion.org> Cc: "Jason A. Donenfeld" <Jason@...c4.com>, "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" <netdev@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Geert Uytterhoeven <geert@...ux-m68k.org>, Herbert Xu <herbert@...dor.apana.org.au>, Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>, Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, Erik Kline <ek@...gle.com>, Fernando Gont <fgont@...networks.com>, Lorenzo Colitti <lorenzo@...gle.com>, hideaki.yoshifuji@...aclelinux.com Subject: Re: [PATCH RFC v1 2/3] ipv6: move from sha1 to blake2s in address calculation Ard Biesheuvel <ardb@...nel.org> writes: > On Thu, 13 Jan 2022 at 12:15, Hannes Frederic Sowa > <hannes@...essinduktion.org> wrote: >> >> Hello, >> >> On 13.01.22 00:31, Jason A. Donenfeld wrote: >> > On 1/13/22, Toke Høiland-Jørgensen <toke@...hat.com> wrote: >> >> However, if we make this change, systems setting a stable_secret and >> >> using addr_gen_mode 2 or 3 will come up with a completely different >> >> address after a kernel upgrade. Which would be bad for any operator >> >> expecting to be able to find their machine again after a reboot, >> >> especially if it is accessed remotely. >> >> >> >> I haven't ever used this feature myself, though, or seen it in use. So I >> >> don't know if this is purely a theoretical concern, or if the >> >> stable_address feature is actually used in this way in practice. If it >> >> is, I guess the switch would have to be opt-in, which kinda defeats the >> >> purpose, no (i.e., we'd have to keep the SHA1 code around >> >> Yes, it is hard to tell if such a change would have real world impact >> due to not knowing its actual usage in the field - but I would avoid >> such a change. The reason for this standard is to have stable addresses >> across reboots. The standard is widely used but most servers or desktops >> might get their stable privacy addresses being generated by user space >> network management systems (NetworkManager/networkd) nowadays. I would >> guess it could be used in embedded installations. >> >> The impact of this change could be annoying though: users could suddenly >> lose connectivity due to e.g. changes to the default gateway after an >> upgrade. >> >> > I'm not even so sure that's true. That was my worry at first, but >> > actually, looking at this more closely, DAD means that the address can >> > be changed anyway - a byte counter is hashed in - so there's no >> > gurantee there. >> >> The duplicate address detection counter is a way to merely provide basic >> network connectivity in case of duplicate addresses on the network >> (maybe some kind misconfiguration or L2 attack). Such detected addresses >> would show up in the kernel log and an administrator should investigate >> and clean up the situation. Afterwards bringing the interface down and >> up again should revert the interface to its initial (dad_counter == 0) >> address. >> >> > There's also the other aspect that open coding sha1_transform like >> > this and prepending it with the secret (rather than a better >> > construction) isn't so great... Take a look at the latest version of >> > this in my branch to see a really nice simplification and security >> > improvement: >> > >> > https://git.zx2c4.com/linux-dev/log/?h=remove-sha1 >> >> All in all, I consider the hash produced here as being part of uAPI >> unfortunately and thus cannot be changed. It is unfortunate that it >> can't easily be improved (I assume a separate mode for this is not >> reasonable). The patches definitely look like a nice cleanup. >> >> Would this be the only user of sha_transform left? >> > > The question is not whether but when we can/will change this. > > SHA-1 is broken and should be removed at *some* point, so unless the > feature itself is going to be obsolete, its implementation will need > to switch to a PRF that fulfils the requirements in RFC7217 once SHA-1 > ceases to do so. > > And I should also point out that the current implementation does not > even use SHA-1 correctly, as it omits the finalization step. This may > or may not matter in practice, but it deviates from crypto best > practices, as well as from RFC7217 Right, but that implies we need to work on a transition mechanism. For newly deployed systems changing the hash is obviously fine, it's the "reboot and you have a new address" problem. We could introduce new values to the addr_gen_mode? I.e. values of 4 and 5 would be equivalent to 2 and 3 (respectively), but with the new hashing algorithm? And then document that 2 and 3 are considered deprecated to be removed at some point in the future... -Toke
Powered by blists - more mailing lists