Subject: Meta comment about "3484bis and privacy addresses"

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Mar 2012 14:57:28 +0200

Folks,

I think that one error in which we have incurred at least in the couple
of years (myself included) is that we focus our discussion on
"mac-derived addresses vs privacy addresses" when the question should
really be about "stable addresses vs. temporary addresses".

Clearly, we don't want any privacy issues (whether temporary or not),
and we should do something such that all addresses do not have any
privacy issues. (FWIW, this
<http://tools.ietf.org/html/draft-gont-6man-stable-privacy-addresses> is
my proposal to tackle the problem of the privacy issues arising from our
current "stable" mac-derived addresses).

It is also clear that some folks may be arguing in favor of temporary
addresses (RFC 4941) for the wrong reasons (albeit understandable):
because we lack of stable addresses that do not have privacy issues.

So I tend to think that our debate should probably be about "stable vs.
temporary addresses", but our discussion is kind of blinded by the fact
that we currently only have "stable but privacy-harmful addresses" on
one hand, and "temporary and privacy-improved addresses" on the other.

*This* fact is what has turned our discussion into being about "public
versus privacy address", when it shouldn't: privacy should never be
compromised.

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

---

From: [email-masked]
Date: Tue, 27 Mar 2012 14:52:13 +0100

In response to coments on draft draft-zhou-6man-mhash-cga-00 

1. It can be referred to RFC3972 section 7.2
"This increases the cost of address generation approximately by
   a factor of 2^(16*Sec).  It also increases the cost of brute-force
   attacks by the same factor.  That is, the cost of creating a CGA
   Parameters data structure that binds the attacker's public key with
   somebody else's address is increased from O(2^59) to
   O(2^(59+16*Sec)).  The address generator may choose the security
   parameter Sec depending on its own computational capacity, the
   perceived risk of attacks, and the expected lifetime of the address.
   Currently, Sec values between 0 and 2 are sufficient for most IPv6
   nodes.  As computers become faster, higher Sec values will slowly
   become useful."

So though hash output length and sec parameter are two different things, 
they
can be added together to evaluate as a whole.

If have doubts, I suggest ask CFRG people to consider it.

2. when consider computation part for good guys, since it has been 
suggested to use high sec
value, 2^(16*sec) is already to big work to do 
(when sec=3, cost thousands of hours ), so it is not distinguish with plus 
3.
And it has already been proposed to delegate the generation of CGA to a 
third party when using high sec.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Mar 2012 16:21:52 +0200

Well, I think it is quite a simple trade-off. Increasing Sec increases computational effort on both sides by equal amount. Increasing the length of the hash increases computational effort only on the attacker side. As a result, the hash bits are relatively valuable.

The trade-off that we have in front of us is to choose between:

1) Status quo: RFC 4982 eats three bits for Sec, leaving 59 bits of hash length after accommodating for u and g bits as well. The good with this is that it leaves maximum size for hash. The bad is that it is less flexible for adding many new hash algorithms.

2) The proposed new approach: Eat a total of six bits, for Sec and the hash algorithm identifier. 56 bits remain. The good is that this gives more flexibility to allocate hash algorithms, including the ability to independently choose Sec and the algorithm. The bad is that the hash size is decreased.

FWIW, I'm personally in the camp that #1 is still the right approach. We've have 5 entries left:

http://www.iana.org/assignments/cga-message-types/cga-message-types.xml#cga-message-types-3

and even if we some day would run out, there would always be an opportunity to use the last bit combination (111) to denote that the algorithm value would be elsewhere in the address. I admit that my preferences are affected by my view that 59 bits is only borderline secure. So I wouldn't want to reduce it, if it can be avoided.

Jari

---

From: Dominik Elsbroek <[email-masked]>
Date: Tue, 27 Mar 2012 16:44:53 +0200

Hi Fernando,

since I got confused on the discussion in the plenary this morning: I
think we have to consider that having a temporary address like defined
in RFC 4941 does not prevent from or even mitigates the scanning
problem mentioned this morning in discussion. Scanning MAC-address
derived addresses on hosts using privacy extension keeps possible and
feasible since the privacy address is only an additional address. The
address derived by the MAC address is still reachable and a valid
address (like a have just tested on my macbook just to be sure). Thus
it is still possible to scan an IPv6 network by iterating over the
changing 24 bits.

So I don't agree with the sentence: "Clearly, temporary addresses can
help reduce the attack exposure   window, since the lifetime of each
IPv6 address is reduced when compared to that of addresses generated
with the method specified in this document." in
draft-gont-6man-stable-privacy-addresses-00.txt.

The only goal achieved by using a temporary address (_and_ using it)
is privacy in that way, a website, or any other third party service,
cannot track a user also in case of prefix changes. In my opinion
there is no security related reason to use privacy extension.

Cheers,
Dominik

On Tue, Mar 27, 2012 at 14:57, Fernando Gont <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 27 Mar 2012 15:54:08 +0100

Regards~~~

-Sujing Zhou

Jari Arkko <[email-masked]> 写于 2012-03-27 16:21:52:

> Well, I think it is quite a simple trade-off. Increasing Sec 
> increases computational effort on both sides by equal amount. 
> Increasing the length of the hash increases computational effort 
> only on the attacker side. As a result, the hash bits are 
relativelyvaluable.
> 1) Status quo: RFC 4982 eats three bits for Sec, leaving 59 bits of 
> hash length after accommodating for u and g bits as well. The good 
> with this is that it leaves maximum size for hash. The bad is that 
> it is less flexible for adding many new hash algorithms.
> 
> 2) The proposed new approach: Eat a total of six bits, for Sec and 
> the hash algorithm identifier. 56 bits remain. The good is that this
> gives more flexibility to allocate hash algorithms, including the 
> ability to independently choose Sec and the algorithm. The bad is 
> that the hash size is decreased.
> 
> and even if we some day would run out, there would always be an 
> opportunity to use the last bit combination (111) to denote that the
> algorithm value would be elsewhere in the address. I admit that my 

use 111 to denote hash algorithm is somewhere in the address, then where 
they would be,
in the subnet prefix, or in the hash output? and how many bits will it 
occupy?
that will bring us back to the current situcation I think, and worse, with 
3  additional bits
eaten just indicating that "hash algo is somewhere". 

> preferences are affected by my view that 59 bits is only borderline 
> secure. So I wouldn't want to reduce it, if it can be avoided.

59 bits is not enough for a hash, that is why sha-1 has 128 bits and even 
longer,
that is why HASH2 is introduced to compensate for the short hash length 
occupied.
Since then, why cann't we do better?

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Mar 2012 16:59:42 +0200

On 03/27/2012 04:44 PM, Dominik Elsbroek wrote:
> problem mentioned this morning in discussion. 

Exactly. That's why we need stable privacy-enhanced addresses regardless
of whether one implements RFC 4941.

> Scanning MAC-address

Agreed.

> draft-gont-6man-stable-privacy-addresses-00.txt.

What I meant is that if the attacker knows the host adresess, then
attack exposure is a bit reduced for the temporary addresses, simply
because their lifetime is shorter. But yes, this "reduced exposure" is
really debatable. The lifetime of temporary addresses is usually long
enough that, in practice, they don't really reduce exposure.

I will try to fix this in the next rev. (thanks for pointing this out!)

> cannot track a user also in case of prefix changes. 

Well, draft-gont-6man-stable-privacy-addresses addresses this point,
without the management burden usually implied by temporary addresses.

Temporary addresses could, in some sense, prevent correlation of
different activities of the same node from the same network... but
unless you use an insanely short lifetime, the lifetime is long enough
that these addresses do not prevent much of this possible "correlation".

> In my opinion

So far, there is/was, because we didn't/don't have yet standardized
stable privacy addresses...

Thanks,

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Tue, 27 Mar 2012 17:25:10 +0200

Dear all

I'm working on ETSI and ISO standardization for ITS (vehicular
communication) where location privacy at the IPv6 layer is one of big
concerns. From the viewpoint of IPv6 ITS communication, we definitely need
to preserve location privacy. Accordingly, I strongly support the method
described in this document even if the document should be improved.

Cheers.

-- 
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google.com/site/hurryon/

---

From: Brian Haberman <[email-masked]>
Date: Tue, 27 Mar 2012 11:33:49 -0400

Fernando,

> really be about "stable addresses vs. temporary addresses".

Given that the question is being driven by the work going into 3484bis, 
I disagree.  The question I asked is querying people's choice for 
preferring temporary (RFC 4941) addresses over public addresses when 
performing address selection.

The discussion of defining a new form of stable address as opposed to 
the current EUI-64-derived addressing is a separate topic.  This is 
especially relevant given the state of 3484bis (ready for WGLC).

Regards,
Brian

---

From: Christian Huitema <[email-masked]>
Date: Tue, 27 Mar 2012 21:00:09 +0000

> Well, I think it is quite a simple trade-off. Increasing Sec increases computational effort on both sides by equal amount. Increasing the length of 
> the hash increases computational effort only on the attacker side. As a result, the hash bits are relatively valuable.

Jari, the effect of sec is different on both sides. The effort is not increased "by equal amount" but rather "in the same proportion." Suppose that an attacker could crack the 59 bit hash in a day with sec=0. Adding sec = 1 means that the attacker will have to try 65536 times as many keys. The time to crack becomes 65536 hours, i.e. about 7 years. The defender will have to try 65536 instead of one to get the right sec, taking only  a fraction of a second. 

> 1) Status quo: RFC 4982 eats three bits for Sec, leaving 59 bits of hash length after accommodating for u and g bits as well. The good with this is 
> that it leaves maximum size for hash. The bad is that it is less flexible for adding many new hash algorithms.

I kind of like the status quo.

> 2) The proposed new approach: Eat a total of six bits, for Sec and the hash algorithm identifier. 56 bits remain. The good is that this gives more 
> flexibility to allocate hash algorithms, including the ability to independently choose Sec and the algorithm. The bad is that the hash size is 
> decreased.

Decreased a lot. On the other hand, if we do gain the flexibility to define new algorithms, then we can define a mandatory-to-implement algorithm that incorporates the equivalent of the "sec" strengthening.

-- Christian Huitema

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Mar 2012 23:22:59 +0200

Christian,

> Jari, the effect of sec is different on both sides. The effort is not increased "by equal amount" but rather "in the same proportion." Suppose that an attacker could crack the 59 bit hash in a day…

Right. I was imprecise in what I said. In the same proportion is right.

Jari

---

From: [email-masked]
Date: Wed, 28 Mar 2012 12:45:33 +0100

Regards~~~

-Sujing Zhou

Christian Huitema <[email-masked]> 写于 2012-03-27 23:00:09:

> Increasing the length of 
> > the hash increases computational effort only on the attacker side.
> As a result, the hash bits are relatively valuable.
> 
> Jari, the effect of sec is different on both sides. The effort is 
> not increased "by equal amount" but rather "in the same proportion."
> Suppose that an attacker could crack the 59 bit hash in a day with 
> sec=0. Adding sec = 1 means that the attacker will have to try 65536
> times as many keys. The time to crack becomes 65536 hours, i.e. 
> about 7 years. The defender will have to try 65536 instead of one to
> get the right sec, taking only  a fraction of a second. 

after attacker has cracked a CGA address, then it is in the same stand as 
the defender.
defender, as well as attacker, has to try one by one to get the right sec, 
i.e., to get a matching length of zeros,
how come attacker need extra 65536 hours but defender only needs a 
fraction of a second?
 
> > 1) Status quo: RFC 4982 eats three bits for Sec, leaving 59 bits 
> of hash length after accommodating for u and g bits as well. The 
> good with this is 
> > that it leaves maximum size for hash. The bad is that it is less 
> flexible for adding many new hash algorithms.
> 
> gives more 
> > flexibility to allocate hash algorithms, including the ability to 
> independently choose Sec and the algorithm. The bad is that the hash 
size is 
> > decreased.
> 
> Decreased a lot. On the other hand, if we do gain the flexibility to
> define new algorithms, then we can define a mandatory-to-implement 
> algorithm that incorporates the equivalent of the "sec" strengthening.

the security of a hash algo can be roughly estimated by length of its 
output,
from birthday attack, that is about 2^(59/2) or 2^(56/2)(theorical 
estimate), or less,
can you give a more precise of value of "a lot"?
I don't see flexibility in defining mandatory-to-implementing hash alg

---

From: Christian Huitema <[email-masked]>
Date: Thu, 29 Mar 2012 00:23:38 +0000

Sujin,

Your statement  “after attacker has cracked a CGA address, then it is in the same stand as the defender” is incorrect. The attacker will not need 65536 additional trials; he will need to find a matching CGA address 65536 times, and each trial is just as complex as finding a matching CGA address. The defender on the other hand can pick any CGA address he wants, so he has to perform just 65536 trials.

-- Christian Huitema

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 28, 2012 4:46 AM
To: Christian Huitema
Cc: [email-masked]; Jari Arkko
Subject: 答复: RE: about security level evaluation of draft-zhou-6man-mhash-cga-00

Regards~~~

-Sujing Zhou

> get the right sec, taking only  a fraction of a second.

after attacker has cracked a CGA address, then it is in the same stand as the defender.
defender, as well as attacker, has to try one by one to get the right sec, i.e., to get a matching length of zeros,
how come attacker need extra 65536 hours but defender only needs a fraction of a second?

> independently choose Sec and the algorithm. The bad is that the hash size is
> > decreased.
>

the security of a hash algo can be roughly estimated by length of its output,
from birthday attack, that is about 2^(59/2) or 2^(56/2)(theorical estimate), or less,
can you give a more precise of value of "a lot"?
I don't see flexibility in defining mandatory-to-implementing hash alg