On Thu, 13 Jan 2022 at 12:15, Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx> wrote: > > Hello, > > On 13.01.22 00:31, Jason A. Donenfeld wrote: > > On 1/13/22, Toke Høiland-Jørgensen <toke@xxxxxxxxxx> 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 I already pointed out to Jason (in private) that the PRF does not need to be based on a cryptographic hash, so as far as I can tell, siphash would be a suitable candidate here as well, and I already switched the TCP fastopen code to that in the past. But SHA-1 definitely has to go.
