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

Fernando Gont <> Thu, 23 January 2014 17:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ABB361A007D; Thu, 23 Jan 2014 09:49:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uQs_Qsc8xtXj; Thu, 23 Jan 2014 09:49:38 -0800 (PST)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id 440B91A0019; Thu, 23 Jan 2014 09:49:38 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <>) id 1W6OOd-0000JU-0b; Thu, 23 Jan 2014 18:48:55 +0100
Message-ID: <>
Date: Thu, 23 Jan 2014 14:22:03 -0300
From: Fernando Gont <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Eliot Lear <>, Stephen Farrell <>, Simon Perreault <>, The IESG <>
Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT)
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc:,, Lloyd Wood <>,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jan 2014 17:49:43 -0000

On 01/23/2014 12:09 PM, Eliot Lear wrote:
> On 1/21/14, 8:08 PM, Fernando Gont wrote:
>>> If keeping it, I'd say give the example and then add a
>>> security consideration that that interface might be
>>> vulnerable (e.g. 'cat /proc/net/eth0/rfcxxx-secret'
>> How about rather noting that the secret key should only be accessible by
>> the system administrator? (i.e., non-RFC2119 recommend that implementers
>> do the right thing :-) )
> I agree with the requirement but I think Stephen raises an important
> point, which is that it should be highlighted that the information is
> sensitive.  As such, implementations should constrain access to the
> information, to the extent practicable.  Furthermore, I understood
> Stephen's point also to be that the private key information should not
> be used for any other purpose.

It's not actually a private key in the sense of private/public key..
Just a secret key.

But yeah, I have no objections to adding some words on the topic. How
about this:

"Since the privacy of this system relies on the secrecy of the
secret_key parameter, implementations should constraint access to it to
the extent practicable (e.g., require superuser privileges to access
it). Furthermore, in order to prevent leakages of the secret_key, this
parameter should not be used for any other purposes than being a
parameter to the scheme specified in this document"




Best regards,
Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492