Sean Shen escribió:
Hi,
Comments in line:
My understanding is:
H1 is already there so it should be considered. (notice that H1
include both rsa-only node or ecc-only node according to the
definition of definition);
H2 is the type that can be transfered to H4: need to
generated a new CGA covering multiple keys. There is no divice
ability difference between H2 and H4. If requireing a new multi-key
CGA is not too much, it is fair to rule out H2.
mmm, i am not so sure about this
I mean, one question that i have with respect to this is whehter
validating is cheaper than signing?
I mean, wouldn't be possible that a node has not enough processing
power to generate an RSA key and sign using the key, but it is
capable of verifying RSA signatures?
(i really don't know the answer to this and maybe verifying is as
expensive as signing... i simply don't know)
For rsa, validating is cheaper than signing. So the situation you
described is possible.
ok, so do you think is reasonable to impose that all nodes
must be able to validate RSA signatures? (even light weigth nodes?)
I don't think the it's proper to impose all nodes must be able to validate
RSA signature. Especially when we are looking for general agility solutions,
we should not consider one particular algorithm different from others.
but the fact is that rsa is different cause it is alreadys pecified, and
the cga have by default an rsa key and so on
Besides, to impose rsa validation is too strong, for the nodes which only
want ECC for key size and speed reasons, this requirement is not proper.
but you mentioned that RSA validation is cheaper than rsa signing, so
maybe these light weigth nodes can do rsa valdiation...
My point is unless we properly scope the types of nodes we want to
support and what are the requirements, we are arguing in the abstract. I
guess niether you nor me can have an auhtoritative voice on this...
maybe we should ask some people more involved on these light weight
devices to figure out what are reasonable assumptions to make.
What I mean is, If an H2 can already generate an CGA associated with
one key and own another key, he can also generate an CGA
associated with two keys.
sure, this is not the case i am concerned about
Possiblly we can use this way to reduce combination of different
hosts/routers.
right
The question is that: is it proper to require "have the ability to
perform an algorithm A"<==>"have a public key for algorithm A".
For the "<==", I think it's easier to be accepted, a device should
have the ability to play the algorithm A if it has the key of
algorithm A;
right
For the "==>", I think this is fairly reasonable especially for
terminal devices. If an device want to save resouce, it
probably just
want the ability of playing one algorithm.
but i guess this depends on what resoruces are constrained in
the device.
If what is constrained is processing power, then it may make
sense to have a device that for instacne does not have a RSA
key, but it is capable of validating RSA signatures, since as
you mentioned above, validating RSA signatures is cheaper than
signing, right?
Even if what is constrained is only processing power, installing RSA only
for validating RSA signature will not help saving power compared with ECC. I
mean, if a terminal can use ECDSA for signature, it can just use ECDSA for
validation,
Comparing ECDSA validation speed and RSA validation speed is a little
complex: overall, RSA algirithm complexity increase exponentially while
ECDSA algorithm complexity increase sub-exponentialy; on the same level of
cryptographic strength, ECDSA validation is a little slower but on the same
level with RSA validation when key sizes are shorter than 300 bits, when key
sizes are over 300 bits, ECDSA validation is more and more faster than RSA
validation.
right, i am not arguing with that
I am just saying that there are 3 levels of power and CPU and memory
consuption
The lowest level if ECC only
The intermediate level is ECC and RSA validation
The highest level is ECC and RSA validation plus RSA signing (wihc
requires having a RSA key pair)
I guess the point is whehter the intermediate level is good enough or we
need to aim for the lowest level
So overall, if a terminal can use ECDSA, it does not need RSA only for
validation in order to save power. If the purpose is compatibility with old
RSA only routers, the RSA only nodes can not validate terminal's ECDSA
signature, SeND can not be performed anyway.
well, the node could trust the router and verify the prefixes and the
default gateway, but i agree that we can't do full send
regards, marcelo
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
