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

Fernando Gont <> Sat, 25 January 2014 21:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CDA4A1A005F; Sat, 25 Jan 2014 13:31:17 -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 ZzcUxrFkS7VK; Sat, 25 Jan 2014 13:31:15 -0800 (PST)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id 33B8A1A003A; Sat, 25 Jan 2014 13:31:14 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <>) id 1W7Anp-0002M1-UX; Sat, 25 Jan 2014 22:30:10 +0100
Message-ID: <>
Date: Sat, 25 Jan 2014 18:27:59 -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: Brian E Carpenter <>
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 <>, Eliot Lear <>, The IESG <>,, Stephen Farrell <>
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: Sat, 25 Jan 2014 21:31:18 -0000

On 01/25/2014 05:39 PM, Brian E Carpenter wrote:
> On 24/01/2014 06:22, Fernando Gont wrote:
> ...
>> "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"
> Nobody could conceivably object to that, but I do wonder whether the
> statement "Secret keys should be kept secret" doesn't belong in a much
> more generic document than this one. Actually a BCP on pitfalls surrounding
> secret keys and how to protect them would be very valuable, but doesn't
> belong in this WG.

I agree with you.

I'd say I would have probably objected against adding this (with the
argument "well, this should be obvious to everyone"). But then I recall
having a conversation with a folk working on TCP SEQ randomization
(using a similar scheme) for a popular OS, and apparently they were
employing a constant secret key for all their systems. Hence, "sometimes
it's not bad to clarify what you might deem as obvious".

P.S.: And while at times it's easy to blame the guy doing the
implementation, the truth is that at times the same folk is working on
so much stuff that he kind of blindly implements whatever is in the
spec, without much analysis. So... better fail on the safe side.


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