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

["Martin Stiemerling" <[e-mail]>]

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?