Re: [Tails-dev] minimalist/anonymity-preserving DHCP clients…

このメッセージを削除

このメッセージに返信
著者: intrigeri
日付:  
To: The Tails public development discussion list
題目: Re: [Tails-dev] minimalist/anonymity-preserving DHCP clients [was: Re: Reducing attack surface of kernel and tightening firewall/sysctls]
Hi,

Hugo Maxwell Connery wrote (11 Dec 2014 15:01:11 GMT) :
> Here is a recent presentation:
> https://www.ietf.org/proceedings/90/slides/slides-90-dhc-6.pdf


I'll look it up, thanks!

> (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.


Seems to make sense (but I've very little understanding of the IETF
processes -- dkg will surely be able to correct us if we go
off-tracks).

> == 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.


I fail to see what this has to do with DHCP, since MAC addresses don't
leak via DHCP requests only. May you please elaborate? (if the
above-mentioned presentation explains this, just tell me, and then
I'm sorry.)

Cheers,
--
intrigeri