Re: Magnus Westerlund's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi,

I understand the difficulty in trying to address the various. So lets just drop
this comment as not needing to be addressed.

Cheers

Magnus

On Fri, 2020-10-23 at 14:59 +0200, [e-mail] wrote:
> Magnus,
> 
> > Unfortunately I think will not be able to propose a set of adjustment. I
> > understand that might result in that the easiest way forward is to do
> > nothing
> > here. I fully understand that, please just keep it in mind if you anyway are
> > doing any edits on the text if the formulation really are represenatative. 
> 
> During working group review we did quite a few edits to limit overstating the
> claimed privacy improvements.
> The only thing temporary addresses provide by itself is a mechanism for host
> stacks/applications to use if they want to avoid remote end correlation.
> 
> That correlation might of course be done independently of the mechanism:
>  - if application uses the temporary address if combined with a remote server
> which identifies user
>  - the access network the host connects to does the correlation
>  - the application leaks the correlation itself, via e.g. ICE
> 
> I don't think this document by itself should have to specify all the knobs
> that have to be set correctly to avoid correlation.
> 
> The document is written with the reverse assumption. Long lived IPv6 addresses
> provide an easy and cheap way to correlate users across web-sites.
> Temporary addresses solves that particular problem and nothing else.
> 
> I wouldn't mind text proposals making that even clearer, although as I
> mentioned at the top the WG has done quite a bit already.
> (I have a quite dystopian view of what we can do here that has any practical
> improvement. Hopefully this document isn't written to give the reader any
> glimmer of hope).
> 
> Cheers,
> Ole, document shepherd.
> 
> 
> > 
> > On Thu, 2020-10-22 at 11:44 -0300, Fernando Gont wrote:
> > > Hello, Magnus,
> > > 
> > > Thanks so much for your review! In-line....
> > > 
> > > On 22/10/20 05:23, Magnus Westerlund via Datatracker wrote:
> > > > ----------------------------------------------------------------------
> > > > COMMENT:
> > > > ----------------------------------------------------------------------
> > > > 
> > > > I understand that this is an update of an older document resolving
> > > > several
> > > > important issues. However, what was advanced traffic analysis 10 years
> > > > ago
> > > > is
> > > > not as advanced today. The security consideration discuss some of the
> > > > weakness.
> > > > To me it appears that there are significant risks of correlation old
> > > > temporary
> > > > address passed preferred life time with the new preferred temporary
> > > > address.
> > > 
> > > How would you do this at the address level? (caveat: if you do it at an 
> > > upper layer, I'd probably say that this is mentioned both in the 
> > > Security Considerations and in the discussion on persitent IDs earlier 
> > > on in the document).
> > 
> > I don't think you need high level payload analysis, 5-tuple information over
> > time will enable certain correlations. I understand that this is a scale not
> > a
> > black and white issue. I am somewhat concerned that maybe the document
> > indicate
> > that the point on this scale is somewhat more on the secure side than what I
> > think it is. 
> > 
> > > 
> > > > Especially if an attacker can trigger an endpoint reconnecting to a site
> > > > where
> > > > the previous temporary address was used and thus correlate the attempt
> > > > to
> > > > force
> > > > reconnection combined detected use of a new temporary address to the
> > > > same
> > > > destination. It might even be another destination but associated with
> > > > the
> > > > same
> > > > remote site.
> > > 
> > > If the correlation happens at a higher layer, that's indeed possible -- 
> > > but out of the scope of this particular work.
> > > 
> > > 
> > > 
> > > > I have not putt this on discuss level, but my impression is that
> > > > although
> > > > beneficial the strength of its protection might be overstated in the
> > > > various
> > > > statements.
> > > 
> > > Please do let us know if you think that there's more that is to be 
> > > added, and if you have any suggestions.
> > > 
> > > Thanks!
> > > 
> > > Regards,
> 
>