Joe, http:// <http://tools.ietf.org/html/rfc6967#section-3>tools.ietf.org<http://tools.ietf.org/html/rfc6967#section-3> / <http://tools.ietf.org/html/rfc6967#section-3>html<http://tools.ietf.org/html/rfc6967#section-3> /rfc6967#section-3 <http://tools.ietf.org/html/rfc6967#section-3> says that a host-id will be generated anew any time the endpoint IP address changes, perhaps more often.
Is that wrong? It's hard to do a privacy audit if the behavior isn't agreed on. On Mar 10, 2014 1:05 PM, "Joe Touch" <[email protected]> wrote: > > > On 3/10/2014 9:56 AM, Scott Brim wrote: > >> On Mon, Mar 10, 2014 at 12:34 PM, Behcet Sarikaya >> <[email protected]> wrote: >> >>> Hi Brian, >>> >>> On Thu, Mar 6, 2014 at 12:03 PM, Brian E Carpenter >>> <[email protected]> wrote: >>> >>>> >>>> a) Since this is fixing some of the damage done by NAT, it's >>>> really unfinished business for BEHAVE, which if iirc was a >>>> Transport Area WG. Just saying... >>>> >>>> b) The word "privacy" doesn't appear in the draft. Discussing >>>> privacy aspects is clearly essential if there is any thought of >>>> advancing this work. Actually I doubt if such a host ID is ever >>>> going to be acceptable from a privacy point of view, unless the >>>> end system is at liberty to change it at random (like RFC 4941). >>>> >>> >>> Scott Brim said there are no privacy issues. >>> >> >> I said I don't believe this introduces any NEW privacy issues, as long >> as host-ids change at least as often as IP addresses. I hope you will >> get other opinions. I just might be wrong, eh? >> > > Host-IDs might change a lot less often - to retain a persistent ID across > such changes - or more often. > > I don't think we can or should assume either one. We might assume that it > should be under app-layer control, at which point the ball's in the user's > court as to how to manage their own privacy. > > That's worth pointing out, but AFAICT unless there's active user > management to the contrary it can't be worse than an IP address wuold have > been (but it might defeat a network edge from trying to protect internal > users/services). > > Joe >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
