This is an excellent initiative, for tails, and for all clients on general/untrusted networks.
"Reducing the attack surface" (NEW RELATED) has potential impact for any client/server using
iptables (possibly also firewalld).
Creating a privacy preserving DHCP client is of wide-scale potential benefit.
The IETF have been considering privacy enhancement for all standard protocols,
DHCP included. They have a working group on DHCP:
https://datatracker.ietf.org/wg/dhc/charter/
Here is a recent presentation:
https://www.ietf.org/proceedings/90/slides/slides-90-dhc-6.pdf
(I am not associated with the WG or the slide presenter in any way)
I do not suggest that you wait for the IETF, but that once you have consensus
for your target(s) that you inform the WG listed above of your choices, such
that they may be worked into a standard, if that is appropriate and/or possible.
== MAC Address Handling ==
I see two approaches for dynamic MAC address handling: Privacy at all cost,
and Give me an address ASAP.
In the first case, one would wish for as many as possible registrations of the same
MAC address on as many link local networks as possible. Thus, there should be
a list of agreed, preferred addresses to take from an agreed pool of addresses.
(Does such an open "cannot be claimed by manufacturers" MAC address pool exist?
I admit my ignorance).
The client should use these by preference, only choosing the next if the previous
was already claimed on the link local network (ARP query).
In the second case, a randomised scheme seems the most useful. It would reduce
the likelihood of conflicts with existing registrations, but expose whatever ideosyncrasies
of the randomisation scheme may exist.
An excellent initiative. My two cents worth.
Regards,
--
Hugo Connery, GPG:
https://keys.env.dtu.dk/
"Freedom, Security, Convenience; choose two." -- Dan Geer 2014
