>>>>>> 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...
Yes, they can do it if power consumption is the only constraint. > >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. > Light weight devices venders and CHES conference people will be interested in this. Wider comments will be helpful, I will go ahead and explore. >> >>>> 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 Personally I think this depend on different devices, also depend on an vendor's preference: an Certicom product probably don't want RSA at all, an EMC product may not like ECDSA either, an third vendor might try to gain best compatibility if device ability alowed... I think this is a important one, we will include this question in the draft for more comments. > >> 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 > best, Sean _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
