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

[<[e-mail]>]

See (and cite) RFC6151 section 2.

MD5 is still useful as a checksum for really big files, where you're looking for accidental differences introduced by errors, and MD5's efficiency of computation is a win. But that says nothing about being tamper-proof. Think of it as a big CRC32, and CRC32 is not seen as having security properties.

In an explicit crypto hash context where you're relying on the security properties, don't use MD5.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Fernando Gont [[e-mail]]
Sent: 21 January 2014 16:20
To: Stephen Farrell; The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; Wood L  Dr (Electronic Eng)
Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT)

Hi, Stephen,

(Lloyd CC'ed, since IIRC he did work on the MD5 stuff)

Thanks so much for your input! -- Please find my responses in-line...

On 01/21/2014 12:52 PM, Stephen Farrell wrote:
> (1) Section 5: Why mention only MD5 and SHA1? Why not
> HMAC-SHA256?

They are just examples. I guess we could add HMAC-SHA256, too. I have no
objections to that.


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

mm.. what's the attack you have in mind with these MD5 collisions?


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

To some extent, the idea is that you'd do MD5 or better. But at the end
of the day, if MD5 is too much for you, even something weaker than MD5
would be better than the "embed the MAC address" thing we do today.



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

That's one of the reasons MD5 is listed: most systems already implement it.



> (2) Why might a sys admin want to display the
> secret key?

e.g., you want a replacement system to generate the same addresses.


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

Just double-checking: you argue that if it can be changed, systems would
use the same key for other purposes, and hence it would leak out?



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

As noted in the I-D, for obvious reasons the security of this system
relies on the secret key being secret.


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

To be quite honest, I think that MD5 is perfectly fine for this use case
(for instance, it's not unusual for nodes to randomize the TCP SEQ with
MD5). And since other hash functions are mentioned, one would expect
that a developer that has something better available, would go for
something better.

That said, I'm not "married" with MD5, and wouldn't care myself if it's
ditched.

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492