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

["Stephen Farrell" <[e-mail]>]

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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------



(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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


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