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, >
- Martin Stiemerling's No Objection on draft-ietf-6… Martin Stiemerling
- Re: Martin Stiemerling's No Objection on draft-ie… Fernando Gont
- Re: Martin Stiemerling's No Objection on draft-ie… Martin Stiemerling