RE: FW: 6MAN Adoption call on draft-rafiee-6man-ssas-07

["Hosnieh Rafiee" <[e-mail]>]

Hi Christian,

If you think I did not understand the meaning of sec values, please refer to
the vulnerability that I am talking in the following draft. Secondly, my
whole research during the last years was about CGA and SeND.

http://www.ietf.org/id/draft-rafiee-6man-cga-attack-00.txt 



> 
> > Sec value ignores so just consider sec value 0. It is not different
> > what sec value you use. Attacker only uses sec value 0 and sha1 not sha2
or
> n.
> > Based on some suggestion, I am going to write an informational draft
> > about CGA possible attacks and just refer to it in SSAS.
> 
> Hosnieh,
> 
> I have witnessed many discussions of CGA that stem from a misunderstanding
> of the SEC mechanism, and this is clearly one of them. I understand that
you
> are very concerned with the CPU workload implied by the SEC mechanism,
> and thus very motivated to find an alternative. Regrettably, mathematics
stand
> between you and your goal.
> 
> The fundamental problem with the CGA approach, or any similar mechanism,
> is that the 64 bits IID makes for a very weak proof. Whatever the
mechanism,
> it will take only 2^64 attempts to break it. If we follow NIST
recommendations,
> we should aim for 80 bits of proof today, and 128 bits soon.
> 
> The CGA design addresses this problem with the SEC mechanism. The idea is
> to embed both a signature and a puzzle in the IID. The signature's size is
fixed,
> but the puzzle can be made arbitrarily complex. With the specific design
> picked for CGA, each successive increment of SEC is equivalent to adding
16
> bits to the identifier size, allowing deployments to remain secure in the
> future. On the other hand, any design that fixes the proof size to a
constant
> number, such as 64 bits, is guaranteed to become obsolete in a short time.
In
> fact, one can argue that 64 bits is already insecure today.
> 
> The puzzle has indeed a price, and the price has to be paid at the time of
> address generation. It takes 2^16 attempts to find a key suitable for
SEC=1,
> 2^32 for SEC=2, and so on. On a PC, the 2^16  attempts take a fraction of
a
> second. On a mobile phone, with a slower processor, it arguably takes
longer
> and depletes the battery somewhat. But there are probably ways to
> accelerate the process. Smartphone now have capable GPUs, the puzzle
> resolution can be trivially parallelized,  and thus could be accelerated
using
> the smart phone's GPU.
> 
> The nice part of the CGA design is that it only requires the puzzle
solving when
> the address is generated, not when address ownership is verified. That
makes
> the design asymmetric: no cost for the communication partners, some cost
at
> generation time for the owner, huge cost for the attacker.
> 
> The SEC protection works even on the collision attack. Yes, it takes an
average
> of 2^29.5 trials to find 2 keys and salts that hash to the same CGA
address,
> regardless of the value of the SEC field. But with SEC=N, each trial has a
cost of
> 2^(16*N), so the complexity of the collision attack is 2^(29.5 + 16*N).
With a
> simple 64 bit proof and no SEC, the cost would be 2^32.
> 
> Any secure CGA variant will require some form of puzzle. 64  bits is just
not
> long enough. It is also clear that there will have to be a way to make the
puzzle
> more complex over time, as attacks just get better. For that reason, I am
very
> skeptical of the SSAS design, which lacks any such puzzle and locks the
proof
> to exactly 64 bits. I don't believe we should take a fundamentally
insecure
> design as a working group item. On the other hand, your draft brings a
> number of clarifications on the SEND protocol work items, and that's very
> valuable. If you could split out that part as for example
"draft-rafiee-6man-
> send," we would be very close to consensus.


The problem is that the section that you're talking about "such as keeping
public key in the node's cache, etc) is a part of SSAS to make it more
secure and give it the security of the whole public key without increasing
complexity or playing with its performance.  It is like CGA that sec value
is a part of that. It is how the algorithm works and it is what I thought to
find a higher security values as the people who suggested CGA thought about
sec value. The security of CGA algorithm is depends on the security of hash
functions. If we assume that the attack on sec value (the new
vulnerabilities that I wrote as a draft) does not exist, with SHA1 and sec
value 1, you need to do brute force attacks maximum on 2^(31.5+16)=2^47.5
now compare this value with SSAS. We all know that for immediate deployment
of CGA, the higher sec value will not be used since nobody are willing to
wait for 3 hours for sec value 2. 
With our current situation, SSAS is more secure and faster than CGA (even
sec value 1) and if also we consider the special cases where to also keep
the public key in node's neighboring cache, then CGA cannot be comparable
with SSAS.

Secondly, you said that CGA IPR is no problem but we also saw in this
mailinglist  from other implementers  that they do not like this CGA IPR,
either it is free for sale nor not. What I understood, they do not like
something have IPR and in most cases they are not being motivated to
implement CGA with its current situation.

Thirdly, To solve the current vulnerability of CGA, you need to change the
protocol specification while in SSAS these problems are considered
beforehand you do not need to do so.


Finally, I agree that local security is really important but the question is
that what is the cost providing it? SSAS can be used for all kinds of nodes
either with limited resources, for mobile phones, etc. But CGA is not
capable since it uses higher range of battery to generate just sec value 1.
We all know that in future most devices are going to be smaller in size and
unfortunately still the battery technology is not as advanced as it can
support the heavy computation, the one like CGA so again the SeND deployment
will be stopped because nobody is willing to use it on these devices while
SSAS is for all devices either with limited resources or without. Either you
are thinking about the current day or future, we need something simple but
secure. You can improve CGA but how much?? SSAS with two process provide a
high level of security that a node can expect but CGA might be able to do
the same with considering a high cost. 


-----------smile----------
Hosnieh

BTW, unfortunately I am unable to response your emails in the next 3
upcoming days since I have to attend a conference and travelling. Please
consider delay on my responses.