hi, Comments in line: > >> > mmm, but the problem is that one of the motivations for all > this cryptp > >> > agility work is that we will have some nodes with very > limited resources > >> > and that they cannot execute RSA much less they will be able > to execute > >> > multiple algorithms. I don't know if we can assume that they > can > >> > validate using multiple algorithms though.... (i.e. don't > know if they > >> > are H1 or H2) > >> > So, i think we will have at least 3 type of nodes: > >> > We will have cureent send nodes, that are H1 for hosts and > R1 for > >> > routers > >> > We will have new types of nodes that will only support one > crypto suite > >> > but will not be RSA (these are the limited devices). I don't > know if we > >> > will have R1 of these too, or will only be hosts... > >> > We will also then have some normal nodes will be H1, H2, H3 > or H4 or R1 > >> > or R2 or R3 is up to us to decide. > >> > In other words, H1 are a reality, then new resource limited > nodes will > >> > be either H1 or H2 (not clear to me) > >> > Then we need to understnad if there is a case for the other > options, H3 > >> > or H4 or we cna simply rule out some of these... > >> > > >> Hum, I indeed wasn't clear. To me, a H4 node is a node that is > capable>> of handling multiple cryto suites and have multiple > public keys linked > >> to its CGA. It is only "capable of", meaning that it can also > choose to > >> use only one crypto suite, hence one public key. So the > lightweight node > >> are only showing capabilities of H1 node + negotiation > support, while > >> having the same set of capabilities as H4 type nodes. > >> > >> Simply put, if we specify the behavior of H4 type nodes, by > using a > >> small subset of their capabilities, we can emulate H2 and H1 > type nodes. > > > > mmm, maybe, not sure if it the clearer approach though. > > having explicitly called out the different common cases, would > provide some > > clarity, i guess > I was just trying to show why (to my mind) it may be preferable to > haveH4 type nodes functionality from the start in the protocol. > I agree with you to split the nodes into different categories. > Maybe it also would be interesting to differentiate nodes from their > ability to negotiate or not.
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. H3: According to previous discussions, I also agree that H3 can be ruled out. H4: I think this is the type gaining best compatibility. > >> > > H4 type are only required during a transition phase, once > a specific > >> > > crypto suite is adopted, they will act as H2 type of nodes. > >> > not really cause they are likely to be able to interact with > multiple > >> > types of H1 nodes. I mean an H$ node not only can validate > multiple H1 > >> > nodes, but its credentials can be validated by different H1 > nodes, which > >> > is soemthing that a H2 node cannot provide > >> This is true. But in a wide deployment of similar nodes, it > may be more > >> preferable to only carry one type of Public Key in order to > save the > >> bandwidth. We should at least allow this behavior. > >> > > > > sure, if we can handle a single pk, that is clearly preferred > > but i think that a scenario where ECC and RSA need to be used > simultaneously > > may not be too rare > > I mean, RSA cause it is the most common algorithm and cause the > certs are > > likely to use RSA > > ECC for the lighweight nodes > Right. 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. 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). > > (Moreover, you can also have the cases of different key lenghts, > not sure how > > it fits in all this...) > You mean something like a node generating its CGA with a 384-bit > RSA PK > and a 1024-bit RSA PK. When the node is sending packet, neighbors may > decide not to listen to the "not strong enough" 384-bit RSA ? > Or something else ? > > > >> > > We can rule out H3 type as it is really hard to bind two > CGA > >> > > addresses > >> > > together (you have to prove you know the two secret, and > sometime, > >> > > you > >> > > can't prove it to a node that don't support the correct > crypto > >> > > suite). > >> > > >> > i think i agree we could rule out H3, but i woudl preffer to > keep in the > >> > dicussion for a while, to see if someone can come up with a > reason for > >> > that > >> > please note that i am not sure we can rule out R3 though... > >> OK. > >> > >> > > I am not sure R2 will work. Only one certificate, > validating multiple > >> > > crypto suite: this involves multiple keys, right? How do > we link the > >> > > certificate and the multiple keys ? > >> > > >> > > >> > R2 means that the router has a single certificate, but > himself is able > >> > to validate multiple crypto suites. That would acually make > sense to > >> > me... i mean, i am not sure we will be able to get people to > deploy > >> > multiple certificates in parallel.... > >> That makes sense. I will read more on certificate to > understand how we > >> can do that. For now, I'm wondering how a node can check a > certificate>> if it doesn't support the Signature Algorithm of > the certificate. > > > > 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? > > > >> > > R3 seems more fitted. Routers being more powerful. > >> > > > >> > The problem with R3 is that you need multiple certs per > router and i am > >> > not sure how realistic that is from a deployment perspective... > >> Right. > >> > >> > >> > > In our draft, in the best case scenario (which I believe > would be the > >> > > more > >> > > common), we have 2 messages (as many as in SEND), when > things goes > >> > > wrong, > >> > > we have 3 messages. > >> > > Basically, good case is just like: > >> > > - Node A supports Type 1 and Type 2 crypto suite (in this > preference>> > > order) > >> > > - Node B supports Type 1 and Type 3 crypto suite (in this > preference>> > > order) > >> > > - Node A send a NS signed with Type 1 to Node B. The > Supported > >> > > Signature > >> > > Algorithm option indicates which Type of crypto suite > Node A > >> > > supports. > >> > > - Node B verify the signature, everything is OK, it > builds up a NA > >> > > signing > >> > > with Node A preferred crypto suite (First crypto suite to > appear in > >> > > the > >> > > list inside the Supported Signature Option): Type 1. > >> > > - Node A receives the message and checks the signature. > >> > > > >> > > >> > As i mentioned in my reply to the other email, you should > note that a > >> > node can support a set of crypto suites that it can validate > and a > >> > different set of crypto suites that it has credentials. > >> > I mean, for instance a node may have only a RSA CGA but it > is able to > >> > validate both ECC and RSA > >> > So, how do you express the difference? > >> > you need to express it? > >> Yes, good comment. We need to express in some specific cases. > Still, we > >> can use the same "Supported Signature Algorithm" option and > use a flag > >> to differentiate between crypto suite it uses to build > addresses and > >> others. > >> > > well, i was just noting that there are different roles > > not sure if we need to idnetify them but seemed to me that the > disucssion was > > getting a bit confused about this > Yes, you were outlining that they may be different part to negotiate. > Here is what I think should be negotiated for crypto agility: > - does a node can check crypto suite X, Y ? > - does a node possess a CGA using crypto suite X,Y (in order for > another node to be able to check it) ? > - does a node offer long enough keys so I can trust them ? > > Do you agree ? > > >> [...] > >> > >> > > > Another option is for a host of type H4 communicate > with a host > >> > > of type > H1. In this case, if one of the public keys > used by the H4 > >> > > host is > supported by the H1 host, the communication > could be > >> > > possible, but hte > problem is how to choose which is the > right > >> > > public key to use to sign > the messages. > >> > > Not a trivial problem. If a H4 type node send a message > to a node he > >> > > knows nothing of, after a timeout delay, it may try to > resent the > >> > > packet > >> > > using a H1 type mechanism. Basically, here, it means that > we will > >> > > sign > >> > > using with a RSA signature using a RSA Public Key located > in the > >> > > Public > >> > > Key field of the CGA PDS. > >> > > > >> > right, but it can resend signing it with a different key if > itfinds out > >> > that the other node supports a different algorithm, right? > >> Yes. It means that the H4 type node will be able to emulate > the behavior > >> of a H1 > >> type node if it supports the same cryto suite. In our current > solution,>> we use the Public Key field of the CGA PDS to store > the Public Key that > >> can be used with H1 type nodes (e.g. store a RSA key to > communicate with > >> RFC3971 nodes). > > > > mmm, do you mean that you change the CGA Parameter data > strcuture? i.e. that > > you change the key you store in the Public key filed? > > If that's the case, this is a problem cause changing the order > of the keys > > would result in a different CGA > > but maybe i am misunderstanding soemthing > No, we don't change it. When building the CGA, we choose the > Public Key > that will be in the Public Key field of the CGA PDS. This Public > Key is > somewhat the "fallback" Public Key. The "limitation" is that the > CGA PDS > can only carry one Public Key this way and that the Public Key will > remain the same during all the CGA lifetime. > To illustrate, if I were to build just now a CGA, I will put a RSA > Public Key inside the Public Key field, just to assure backward > compatibility with RFC3971 nodes (even if I don't plan to use it but > rather an ECC PK stored in CGA PDS extension fields)). > > Is it more clearer ? > > > >> [...] > >> > one more question, how does hash agility fits into all this? > >> We are pretty independent of this work right now, but it is > clear that > >> the security level of a CGA is related to the hash algorithm > and to the > >> length of its Public Key(s). > >> > > but when we talk about crypto suites, wouldn't that include the > hash > > algorithm as well? > I thought you were originally speaking of the RFC4982. Now I realise > that you may be speaking of the hash algorithm used to compute the > signature. This hash algorithm is totally bound to the type of > Signature Algorithm that is used. Some standards are recommending > a set > of specific Hash function to compute the signature. This is the > case for > PKCS#1 v1.5 used in SEND (which propose MD2, MD5, SHA-1, SHA-256, > SHA-384, SHA-512). RFC3971 decided to use SHA-1. We could decide to > impose couple of value like (RSA,SHA1), (ECDSA,SHA1), (ECDSA,SHA-256) > and it would be up to the receiver to decide whether it want to > supportor not certain combination of hash/signature. Negotiation > process would > be on those couples. Does that seem reasonable ? There are Hash functions bounded within signature algorithm and also Hash funtions used by 3972 and 3971(for example, when generating a CGA). For the Hash functions bounded within signature algorithms, I think it's proper to just refer to other PK standards. For the agility of hash functions used by 3972 and 3971, we haven't yet considered to solve it together with signature agility. But I think it worth discussions. Sean _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
