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

From: <[email-masked]>
Date: Tue, 21 Jan 2014 17:40:03 +0000

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 [[email-masked]]
Sent: 21 January 2014 16:20
To: Stephen Farrell; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: <[email-masked]>
Date: Thu, 23 Jan 2014 21:58:04 +0000

is the secret key sent over th e network? at that point, it would stop being secret.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Fernando Gont [[email-masked]]
Sent: 23 January 2014 17:22
To: Eliot Lear; Stephen Farrell; Simon Perreault; The IESG
Cc: [email-masked]; [email-masked]; Wood L  Dr (Electronic Eng); [email-masked]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT)

On 01/23/2014 12:09 PM, Eliot Lear wrote:
>
> On 1/21/14, 8:08 PM, Fernando Gont wrote:
>>
>>> If keeping it, I'd say give the example and then add a
>>> security consideration that that interface might be
>>> vulnerable (e.g. 'cat /proc/net/eth0/rfcxxx-secret'
>> How about rather noting that the secret key should only be accessible by
>> the system administrator? (i.e., non-RFC2119 recommend that implementers
>> do the right thing :-) )
>
> I agree with the requirement but I think Stephen raises an important
> point, which is that it should be highlighted that the information is
> sensitive.  As such, implementations should constrain access to the
> information, to the extent practicable.  Furthermore, I understood
> Stephen's point also to be that the private key information should not
> be used for any other purpose.

It's not actually a private key in the sense of private/public key..
Just a secret key.

But yeah, I have no objections to adding some words on the topic. How
about this:

"Since the privacy of this system relies on the secrecy of the
secret_key parameter, implementations should constraint access to it to
the extent practicable (e.g., require superuser privileges to access
it). Furthermore, in order to prevent leakages of the secret_key, this
parameter should not be used for any other purposes than being a
parameter to the scheme specified in this document"

?

Thoughts?

Thanks!

Best regards,

---

From: Christian Huitema <[email-masked]>
Date: Mon, 3 Feb 2014 19:05:15 +0000

> 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 abo…

But then, for applications like that, you can also use CRC64.

-- Christian Huitema

---

From: Doug Barton <[email-masked]>
Date: Tue, 04 Feb 2014 20:17:06 -0800

On 01/21/2014 08:47 AM, Simon Perreault wrote:
> On all the platforms I know there would be no practical reason to pick
> MD5. Something better is always available and just as easy to use. I
> don't want new code to use MD5 "because it was given as an example in
> the RFC". Removing MD5 from the examples list would make me happy.

+1

Also +1 on including HMAC-SHA1 and ideally HMAC-SHA256 as explicit examples.

(This is all assuming the draft continues to advance. I continue to 
think it's at best a solution looking for a problem, and at worst a 
needless change that continues the harmful trend of fiddling with the 
spec long after we should have stopped.)

Doug