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

otroan@employees.org Fri, 23 October 2020 12:59 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8EB3A0C7A; Fri, 23 Oct 2020 05:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wttZuplW3kBK; Fri, 23 Oct 2020 05:59:22 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181743A0ADD; Fri, 23 Oct 2020 05:59:21 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:9724:4de7:5f7b:c89b:a40a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id D8B804E11D89; Fri, 23 Oct 2020 12:59:20 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 262764234EEC; Fri, 23 Oct 2020 14:59:16 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: Magnus Westerlund's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)
From: otroan@employees.org
In-Reply-To: <2c3e19f09c18ddb3bbec881102ff54d84572af51.camel@ericsson.com>
Date: Fri, 23 Oct 2020 14:59:16 +0200
Cc: "fgont@si6networks.com" <fgont@si6networks.com>, "iesg@ietf.org" <iesg@ietf.org>, 6man WG <ipv6@ietf.org>, "draft-ietf-6man-rfc4941bis@ietf.org" <draft-ietf-6man-rfc4941bis@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AF857A15-A1E0-44F1-B741-E98B07277324@employees.org>
References: <160335500152.2379.13344186464354332427@ietfa.amsl.com> <db074a10-8feb-3fc3-4e1a-910674e8628d@si6networks.com> <2c3e19f09c18ddb3bbec881102ff54d84572af51.camel@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Pm2xqKoR5vWcIr2YPk0bIQQr9cA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Oct 2020 12:59:24 -0000

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,