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. 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.
>> 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. 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. > >> This equivalence will certainly make problems easier, :). >not really >if we can asusme that all the nodes can validate rsa >signatures (even if they don't have an rsa key), this really >simplifies the problem imho > >> But probably we >> should include this question in the draft to ask the wg whether we >> have that luxury. >> >> >> >>>> H3: According to previous discussions, I also agree that H3 >>>> >>> can be ruled out. >>> >>>> H4: I think this is the type gaining best compatibility. >>>> >>>> >>>> >>> ... >>> >>>> I believe the benefit of carrying multiple signatures: >>>> >>> possiblly save message round in negotiation, also easy for RADV >>> message. Clearly there will be a tradeoff of bandwidth and >>> negotiation simplicity, so I don't know. >>> >>>> >>>> >>> i think we need some numbers here.... >>> how many signatures can be carried in a SEND packet? >>> >> >> >>>> Also I want to point out that the rsa signature has to be >>>> >>> the first one for compatibility with rsa-only node. And we have to >>> change the law in 3971 that all the options after signature option >>> should be ignored (ignored for both signature verification and NDP >>> processing purposes). >>> >>>> >>>> >>> don't understand what do you mean here, could you expand? >>> >> What I mean is that: as defined in 3971, the receiver MUST >ignore any >> options that come after the first RSA Signature option. >(The options >> are ignored for both signature verification and NDP processing >> purposes.) So This law has to be changed if new SeND message want to >> carry multiple signatures, don't know yet whether it can >cause trouble. >> >right, this needs to be changed if we want to inlcude multiple >signatures but i guess we will need to update rfc3971 to >support crypto agility, so no problem here > >> For the order of these signatures on a SeND message, (if rsa >signature >> is >> used) the RSA signaure should be the first one, otherwise an old >> RSA-only node can not recognize ECC PDS & signature options >before the >> rsa signature option. >right >> If we define an order for signature option positions, > >why do we need an order in addition to keeping rsa first? What I mean is that keeping rsa first itself is an ordering action. >> this order >> may not match the order of user's preference of different >algorithms, >> maybe it's doable, I haven't think of other negative reasons, but >> seems to me it's not an very comfortable way. >> >> >don't see a problem here Ok. So the only tradeoff is about bandwidth and negotiation simplicity. > >> >>> ... >>> >>>>>> but there are two cases here: >>>>>> suppose the cert is signed with RSA -one case is that the node >>>>>> that has a ECC based CGA, and only >>>>>> >>>>>> >>>>> supports ECC >>>>> >>>>> >>>>>> validation. So no luck here. This node cannot read the cert >>>>>> - a different case is a node that has an ECC CGA but it is also >>>>>> >>>>>> >>>>> able to >>>>> >>>>> >>>>>> validate RSA signatures (even though it doens't have a RSA >>>>>> >>>>>> >>>>> public key). there >>>>> >>>>> >>>>>> is no problem here. The node can understand and validate the cert >>>>>> >>>>>> makes sense? >>>>>> >>>>>> >>>>> It totally makes sense. >>>>> >>>>> >>>> For the second case described above: if this router is >>>> >>> talking to a ecc-only node, no problem; if this router is >talking to >>> a old rsa-only host, the router can trust the host, but the >host can >>> not trust the router because the host don't understand ecc. >So can we >>> conclude that knowing an extra rsa in this case does not help? >>> >>>> >>>> >>> not sure i understand >>> in the case we were cosndiering above, the cert is signed with RSA, >>> so if the node understand RSA it can validate the cert, so problem >>> solved... >>> >> I guess what you mean is that two sides can trust each other >by using >> different signatures as long as both sides can validate what >they received. >> > >right >> For example, one side use RSA signature, the other side use ECDSA, >> when they are both able to validate two algorithms, SeND can be >> performed. Is my understanding correct? >> >yes > >> If we allow this happen, what if one algorithm is not safe anymore, >> then one node can not enforce to use a secure algorithm and >the other >> node can choose the unsecure algorithm. >> >> >that's what you need the negotiation for, right? >I mean, this is the same than with CGAs right? Ok, agree. Negotions will work here. A node can indicate the accepted algorithms and reject unaccepted. best, Sean _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
