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?)
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?
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?
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
...
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?
Regards, marcelo
Best,
Sean
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
