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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 22 Oct 2020 01:23:21 -0700

Magnus Westerlund has entered the following ballot position for
draft-ietf-6man-rfc4941bis-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/

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

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.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Oct 2020 11:44:21 -0300

Hello, Magnus,

Thanks so much for your review! In-line....

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

> destination. It might even be another destination but associated with the same

If the correlation happens at a higher layer, that's indeed possible -- 
but out of the scope of this particular work.

> beneficial the strength of its protection might be overstated in the various

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,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 23 Oct 2020 12:35:10 +0000

Hi Fernando,

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. 

Cheers

Magnus

> Security Considerations and in the discussion on persitent IDs earlier 

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.

---

From: [email-masked]
Date: Fri, 23 Oct 2020 14:59:16 +0200

Magnus,

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Oct 2020 08:14:06 +0000

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, [email-masked] wrote:
> 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.
> 
> 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.
> 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.
> 
> 
> > 
> > > > important issues. However, what was advanced traffic analysis 10 years
> > > > ago
> > > > is
> > > > the previous temporary address was used and thus correlate the attempt
> > > > to
> > > > force
> > > > destination. It might even be another destination but associated with
> > > > the
> > > > same
> > > > remote site.
> > >