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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 21 Jan 2014 07:52:53 -0800

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.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Jan 2014 13:20:51 -0300

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:
> 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
> as a way to assign blame to an innocent victim. 

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

> If

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.

>    introduce new instances of that code.

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

> secret key? 

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

> If there's a reason shouldn't you say

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?

> 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

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: Simon Perreault <[email-masked]>
Date: Tue, 21 Jan 2014 11:47:18 -0500

It said "DISCUSS" at the top, so I'll do just that...

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

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.

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

Good reason IMHO.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Hannes Frederic Sowa <[email-masked]>
Date: Tue, 21 Jan 2014 17:51:29 +0100

> the RFC". Removing MD5 from the examples list would make me happy.

As soon as we implement that in the kernel, we can use SHA-1 and MD-5, all
other algorithms have a dependency on the crypto-api or must be restructured.

Btw. for my linux PoC I used SHA-1:

http://patchwork.ozlabs.org/patch/300938/ (maybe the comments there could be
helpful as well).

Greetings,

  Hannes

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Jan 2014 14:27:04 -0300

Hi, Simon,

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

> the RFC". Removing MD5 from the examples list would make me happy.

Stephen: Would juust removing MD5 address your DISCUSS?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Jan 2014 15:05:55 -0300

On 01/21/2014 02:40 PM, [email-masked] wrote:
> 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.

Thanks Lloyd. :-)

So it seems clear that MD5 should be removed as an example. Now the
question seems to be whether should actually ditch MD5....

Thanks,

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Jan 2014 18:12:03 +0000

> the RFC". Removing MD5 from the examples list would make me happy.

Right - give good examples and don't give bad ones is the
easy fix. HMAC-SHA1 and HMAC-SHA256 would be good ones to
give. (And if you have sha1 then you can easily use HMAC-SHA1.)

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

Was that mentioned in the requirements? Seems a little less
likely but I guess it could be one.

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'
doesn't give me a nice warm security fuzzy feeling:-)
and needs to be protected.

Another easy fix if needed. (Apologies if that's there
already and I missed it.)

S.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Jan 2014 16:08:56 -0300

> give. (And if you have sha1 then you can easily use HMAC-SHA1.)

Ok. If you know of the URLs for the proper references, please do let me
know.

> Was that mentioned in the requirements? 

I will check :-)

> 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 :-) )

Thanks!

Best regards,

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Jan 2014 16:09:27 +0100

Fernando,

> the system administrator? (i.e., non-RFC2119 recommend that implementers

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.

But maybe I misunderstood.

Eliot

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2014 14:22:03 -0300

> 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: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2014 19:03:58 -0300

On 01/23/2014 06:58 PM, [email-masked] wrote:
> is the secret key sent over th e network? at that point, it would stop being secret.

Nope. Randomly selected and stored on the node upong systems installation.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Jan 2014 09:39:10 +1300

On 24/01/2014 06:22, Fernando Gont wrote:
...
> parameter to the scheme specified in this document"

Nobody could conceivably object to that, but I do wonder whether the
statement "Secret keys should be kept secret" doesn't belong in a much
more generic document than this one. Actually a BCP on pitfalls surrounding
secret keys and how to protect them would be very valuable, but doesn't
belong in this WG.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 25 Jan 2014 18:27:59 -0300

> secret keys and how to protect them would be very valuable, but doesn't

I agree with you.

I'd say I would have probably objected against adding this (with the
argument "well, this should be obvious to everyone"). But then I recall
having a conversation with a folk working on TCP SEQ randomization
(using a similar scheme) for a popular OS, and apparently they were
employing a constant secret key for all their systems. Hence, "sometimes
it's not bad to clarify what you might deem as obvious".

P.S.: And while at times it's easy to blame the guy doing the
implementation, the truth is that at times the same folk is working on
so much stuff that he kind of blindly implements whatever is in the
spec, without much analysis. So... better fail on the safe side.

Thanks!

Best regards,

---

From: Christian Huitema <[email-masked]>
Date: Sun, 26 Jan 2014 00:53:24 +0000

> it's not bad to clarify what you might deem as obvious".

That's actually a tradeoff in Fernando's algorithm.  In order to guarantee reuse of the same IPv6 address at the same location, the system only has to remember the secret key. But if the secret key is disclosed to an attacker, the attacker can predict the IPv6 address that will be used by that system at any future location.

There are other possible designs that don't make the same tradeoff. For example, systems could maintain a list of visited locations and associated IPv6 addresses. When they visit a location not in the list, they can pick a random number for their IID. The system will require more memory, but will have the property that future addresses will be unpredictable, even if an attacker manages to obtain the list of previously used addresses and locations.

-- Christian Huitema