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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 22 Jan 2014 16:10:35 -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:
----------------------------------------------------------------------

(0) Just modifying my disucss to discuss a part of Brian's discuss:-)
I'm sure we'll sort it out easily enough though. I very much do
not think that it'd be a good plan to store every address that
has been generated using this algorithm. That would be making a
privacy-enhancing feature damage privacy. See [1] for an example.

   [1]
http://www.theguardian.com/technology/2011/apr/20/iphone-tracking-prompts-privacy-fears

(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: Thomas Narten <[email-masked]>
Date: Wed, 22 Jan 2014 20:23:48 -0500

I have followed, but not commented on the perpass discussion. But I do
share the concern raised by some that pushback as a result of perpass
concerns can easily get out of hand. 

Is this a preview of what's to come?

At Wed, 22 Jan 2014 16:10:35 -0800,
Stephen Farrell wrote:
> I'm sure we'll sort it out easily enough though. I very much do not
> think that it'd be a good plan to store every address that has been
> generated using this algorithm. That would be making a

And can you point me to the text in the draft that suggests doing so?
(Hint: the draft says no such thing.)

Or for that mattter, who has suggested anyone do this? (Again, AFAIK,
no one has suggested this.)

Are we in hyperbole land? Can we please get back to reality?

Are we now going to require that all internal logs be scrubbed of
potentially sensitive material? If we think we are going to stop the
storage and recording of IP addresses on the devices that are actually
using those addresses, that is just nuts. Think this through for a
minute!

I'm sure the IETF could say the IP stack (as part of trying to make
network connectivity work better) shouldn't store/cache addresses it
has used. And maybe as a result the stack will work a little less
efficiently but it at least won't have stored an address it recently
used...

But then we better hope that noone bothers to look in the browser
cache, or /var/log/messages, etc. which will likely have the same
information and much much more...

Thomas

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Jan 2014 01:37:29 +0000

> Is this a preview of what's to come?

No. Nothing is out of hand. I asked to discuss Brian's discuss.

> (Hint: the draft says no such thing.)

No. And I clearly said that. "to discuss a part of Brian's discuss"
clearly indicates that I am not saying that the draft says that.

> no one has suggested this.)

See Brian's discuss. If that's not what he meant (and I know
the draft author also thinks it was) then it won't be a problem.
If it is, we'll discuss it briefly and sort it out.

I'll skip the text below. I'm sorry you're upset, but frankly I
don't think your upset is at all justified.

S.