Re: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 23 January 2014 01:37 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080DE1A0343; Wed, 22 Jan 2014 17:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level:
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham
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 2Vp5vUS7atXb; Wed, 22 Jan 2014 17:37:33 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 038CE1A01B7; Wed, 22 Jan 2014 17:37:33 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7372DBE47; Thu, 23 Jan 2014 01:37:31 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pu4JF+9ndLIq; Thu, 23 Jan 2014 01:37:30 +0000 (GMT)
Received: from [10.87.48.3] (unknown [86.44.74.137]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 28E3ABE39; Thu, 23 Jan 2014 01:37:30 +0000 (GMT)
Message-ID: <52E07259.9050902@cs.tcd.ie>
Date: Thu, 23 Jan 2014 01:37:29 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT)
References: <20140123001035.19199.91573.idtracker@ietfa.amsl.com> <m3r47z8p97.wl%narten@us.ibm.com>
In-Reply-To: <m3r47z8p97.wl%narten@us.ibm.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 23 Jan 2014 01:37:36 -0000

On 01/23/2014 01:23 AM, Thomas Narten wrote:
> I have followed, but not commented on the perpass discussion. But I do
> share the concern raised by some that pushback as a result of perpass
> concerns can easily get out of hand. 
> 
> Is this a preview of what's to come?

No. Nothing is out of hand. I asked to discuss Brian's discuss.

> 
> At Wed, 22 Jan 2014 16:10:35 -0800,
> Stephen Farrell wrote:
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>
>> (0) Just modifying my disucss to discuss a part of Brian's discuss:-)
>> I'm sure we'll sort it out easily enough though. I very much do not
>> think that it'd be a good plan to store every address that has been
>> generated using this algorithm. That would be making a
>> privacy-enhancing feature damage privacy. See [1] for an example.
> 
> And can you point me to the text in the draft that suggests doing so?
> (Hint: the draft says no such thing.)

No. And I clearly said that. "to discuss a part of Brian's discuss"
clearly indicates that I am not saying that the draft says that.

> Or for that mattter, who has suggested anyone do this? (Again, AFAIK,
> no one has suggested this.)

See Brian's discuss. If that's not what he meant (and I know
the draft author also thinks it was) then it won't be a problem.
If it is, we'll discuss it briefly and sort it out.

I'll skip the text below. I'm sorry you're upset, but frankly I
don't think your upset is at all justified.

S.

> 
> Are we in hyperbole land? Can we please get back to reality?
> 
> Are we now going to require that all internal logs be scrubbed of
> potentially sensitive material? If we think we are going to stop the
> storage and recording of IP addresses on the devices that are actually
> using those addresses, that is just nuts. Think this through for a
> minute!
> 
> I'm sure the IETF could say the IP stack (as part of trying to make
> network connectivity work better) shouldn't store/cache addresses it
> has used. And maybe as a result the stack will work a little less
> efficiently but it at least won't have stored an address it recently
> used...
> 
> But then we better hope that noone bothers to look in the browser
> cache, or /var/log/messages, etc. which will likely have the same
> information and much much more...
> 
> Thomas
>