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

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 20 Jan 2014 02:10:20 -0800

Martin Stiemerling has entered the following ballot position for
draft-ietf-6man-stable-privacy-addresses-16: No Objection

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 http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/

----------------------------------------------------------------------
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?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 20 Jan 2014 07:43:13 -0300

Hi, Martin,

Thanks so much for your review! Please find my comments in-line...

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.

Thoughts?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 20 Jan 2014 15:36:53 +0100

Hi Fernando,

> 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