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

"Stephen Farrell" <> Tue, 21 January 2014 15:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8CD931A0369; Tue, 21 Jan 2014 07:52:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AG15AcFoZZ6R; Tue, 21 Jan 2014 07:52:53 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 86EDA1A0368; Tue, 21 Jan 2014 07:52:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Stephen Farrell <>
To: The IESG <>
Subject: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Tue, 21 Jan 2014 07:52:53 -0800
X-Mailman-Version: 2.1.15
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jan 2014 15:52:55 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-6man-stable-privacy-addresses-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


(1) Section 5: Why mention only MD5 and SHA1? Why not
HMAC-SHA256? As-is, implementers are likely to get this
wrong in various ways, e.g. allowing MD5 collisions to
be generated on purpose with different inputs perhaps
as a way to assign blame to an innocent victim.  If
HMAC-MD5 or better (*) HMAC-SHA256 were recommended
instead, it is far more likley that implementers will
do the right thing and it seems just as easy to do
today's right thing as what's mentioned here. 

   (*) Even though HMAC-MD5 is still ok, its better
   (for audit reasons) if we reduce the number of
   copies of MD5 runtime code on systems and do not
   introduce new instances of that code.

(2) Why might a sys admin want to display the
secret key? If there's a reason shouldn't you say
so that coders don't do the wrong thing? The 
concern is that once established, this key might
be re-used for other purposes and display might
then become an interesting attack vector.


- Probably not worth investigating, but I'd wonder if a
bad-actor with the 64 bit prefix to play about with
could force an IID on a node that used plain MD5 with a
guessable or known secret_key. I don't think that's
doable today but its yet another reason to avoid very
outdated hash functions like md5. This is a non-issue
if discuss#1 is resolved by ditching MD5.