Tails compliance with Anonymity Profiles for DHCP Clients documentation?

Support Tails
1

This document & research from 2016 is interesting and talks about “Anonymity Profiles for DHCP Clients”[1]

if the link-layer address changes and the DHCP identifier stays constant, then it is really easy to correlate old and new link-layer addresses, either by listening to DHCP traffic or by observing that the IP address remains constant, since it is tied to the

From what I have observed is that Tails doesn’t send the hostname in DHCP packet which is :+1: according to this old document since hostname is affiliated to “amnesia” (unique to tails)

Tails NetworkManager Configs

ipv6.ip6-privacy=2 → Configures IPv6 privacy extensions
dhcp=internal → Switches from ISC DHCP to internal DHCP client
dns=none → Prevents NetworkManager from managing resolv.conf (Tor DNS)

ethernet.cloned-mac-address=preserve
wifi.cloned-mac-address=preserve
These configures NetworkManager to not touch MAC addresses (Tails handles MAC spoofing separately)

So looking at this and what can be done disabling mutlicast doesn’t make sense since DNS is set to none so connection.mdns=1 and connection.llmnr=0 would be pointless yet harmless though.
Where my questions arise are DHCP options, DUID, and Client ID’s?

Do these change upon reboot or does connection.stable-id need to be utilized to influence these?

ipv6.addr-gen-mode=stable-privacy
ipv6.dhcp-duid=stable-uuid
ipv4.dhcp-client-id=stable
ipv4.iaid=stable

connection.stable-id=${CONNECTION}/${BOOT} or connection.stable-id=${RANDOM} (Just random may cause re-auth on reconnect for same session or possible leaks)?

Is there anything else that can be done or is Tails pretty good when compared and cross referenced to this document?

  1. RFC 7844 - Anonymity Profiles for DHCP Clients ↩︎

2

You raise some good points and I would argue that most users are safe when comparing to this information. However what does come to mind is users that save Network Connections profiles in their persistence storage?

Could saved connection profiles indeed carry static or predictable DHCP identifiers across reboots?

The default stable id would violate RFC 7844.

If the value is unset, a global connection default is consulted. If the value is still unset, the default is “default${CONNECTION}” go generate an ID unique per connection profile.

But unless if you change how all “stable” generation is handled like how you mentioned connection.stable-id=${CONNECTION}/${BOOT} that would mean it would fit more in line with it.
I think ${RANDOM} could cause DHCP lease stability personally however its mentioned.

This example I found from official github mirror mentions a config for this case (4 years old though) exactly.

NetworkManager/examples/nm-conf.d/30-anon.conf at main · NetworkManager/NetworkManager · GitHub

Also mentioned in the manpage it mentions ${CONNECTION}-${BOOT}-${DEVICE}, which means different stable-id per boot AND per interface. Tails users typically uses one interface at a time. If the same profile activates on different interfaces, then correlation arises?

My conclusion is ${CONNECTION}/${BOOT} makes the most sense since a new identifier is generated for every saved network connection profile on every boot if I’m understanding it correctly.