Re: Martin Stiemerling's No Objection on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)

Martin Stiemerling <mls.ietf@gmail.com> Mon, 20 January 2014 14:36 UTC

Return-Path: <mls.ietf@gmail.com>
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 54EBE1A0175; Mon, 20 Jan 2014 06:36:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Level:
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_OFF=2.3, SPF_PASS=-0.001] autolearn=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 uDHdsWCWz3IF; Mon, 20 Jan 2014 06:36:56 -0800 (PST)
Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id A2DBC1A015B; Mon, 20 Jan 2014 06:36:55 -0800 (PST)
Received: by mail-ee0-f41.google.com with SMTP id e49so3524286eek.0 for <multiple recipients>; Mon, 20 Jan 2014 06:36:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fjSEBRWr9Rxmi11mw4WOHqQ1gx8iyk8mjLuCV17GxiY=; b=IZ/XIfKSMpbmcOVtk28DT09PHGCjLbuESeyAuF2Nw8l6h0/jKOiBWvTb/vhbjzx1t2 TzrC+59/Hs4r+5wZIxPyMq+VdDTWsbHyAMFJTIqLNmaWTPLCP7s2nyOCoHNMD1WxGLdO jiXWkUdfDv0JADtQUlNYjz+4g3KolW6sdJazMgp43950AGdq5o6JQB9Qvy06BKvpmtVk OMEzW92bd2RutTgl60ZX8chmU+YWsCpz/nsN5SomdxTrG0E0Rea0dpzoEkoSwGV8FGkA ezcvqLlABLY09K9M74i4N0LV/SB2YH+3YwTtAWmv1k1F3r2doQKUR+0x9aIIR06o0pEj JSqQ==
X-Received: by 10.14.178.65 with SMTP id e41mr2629044eem.79.1390228615425; Mon, 20 Jan 2014 06:36:55 -0800 (PST)
Received: from [10.1.1.137] (mito.netlab.nec.de. [195.37.70.39]) by mx.google.com with ESMTPSA id l4sm3765520een.13.2014.01.20.06.36.54 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Jan 2014 06:36:54 -0800 (PST)
Message-ID: <52DD3485.1040107@gmail.com>
Date: Mon, 20 Jan 2014 15:36:53 +0100
From: Martin Stiemerling <mls.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>, The IESG <iesg@ietf.org>
Subject: Re: Martin Stiemerling's No Objection on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)
References: <20140120101020.1584.34146.idtracker@ietfa.amsl.com> <52DCFDC1.3080100@gont.com.ar>
In-Reply-To: <52DCFDC1.3080100@gont.com.ar>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: 6man-chairs@tools.ietf.org, ipv6@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: Mon, 20 Jan 2014 14:36:57 -0000

Hi Fernando,

On 01/20/2014 11:43 AM, Fernando Gont wrote:
> Hi, Martin,
>
> Thanks so much for your review! Please find my comments in-line...
>
>
> On 01/20/2014 07:10 AM, Martin Stiemerling wrote:
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Section 2., paragraph 4:
>>
>>>     Note that the result of F() in the algorithm above is no more
>> secure
>>>     than the secret key.  If an attacker is aware of the PRF that is
>>>     being used by the victim (which we should expect), and the attacker
>>>     can obtain enough material (i.e. addresses configured by the
>> victim),
>>>     the attacker may simply search the entire secret-key space to find
>>>     matches.  To protect against this, the secret key should be of a
>>>     reasonable length.  Key lengths of at least 128 bits should be
>>>     adequate.  The secret key is initialized at system installation
>> time
>>>     to a pseudo-random number, thus allowing this mechanism to be
>> enabled
>>>     /used automatically, without user intervention.
>>
>>    Isn't there a requirement (MUST) or at least a recommendation
>> (RECOMMENDED) to say something about the minimum length of the secret
>> key? Just to let implementers know from what length on the secret is
>> 'safe' as input?
>
> I think we could change:
>
>   "To protect against this, the secret key should be of a
>    reasonable length.  Key lengths of at least 128 bits should be
>    adequate."
>
> to:
>
>   "To protect against this, the secret key SHOULD be of at least
>    128 bits."
>
>
> However, this is intertwined with the choice of F(), which we're not
> specifying (since it represents a tradeoff). So, while I see your point,
> I'm not sure whether that would make sense.

I'm also torn, but I would add a minimum recommendation, so that 
implementers have a lower limit to start from. Your text proposal is 
good and better than 'reasonable length'.

Thanks,

   Martin

>
> Thoughts?
>
> Thanks!
>
> Best regards,
>