Hi,
Comments inline.
[...]
> 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 have
H4 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.
> > 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.
(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.
> > 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 support
or not certain combination of hash/signature. Negotiation process would
be on those couples. Does that seem reasonable ?
Regards,
Tony Cheneau
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
