Tony Cheneau escribió:
Maybe it also would be interesting to differentiate nodes from their
ability to negotiate or not.
but this is up to us to define it, right?
I mean, i don't think we shou define multiple behaviour if we can avoid it.
I mean, i undersntad that a node cannot support heavy weight algorithms,
but wouldn't a node couldn't be able to retry as you proposed before?
...
(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 ?
right
i mean once we have the means to negotiate, we could use it as well for
this (but this is secondary, i guess)
Or something else ?
....
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 ?
the certs are missing i think...
I mean, you have the CGA and the certs that use a public key algorithm,
right?
...
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 ?
right
[...]
> 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 ?
right
my point is that this work needs to be coordinated with Suresh and Ana
and Sheng, who are working in the hash agility work
Regards, marcelo
Regards,
Tony Cheneau
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
