Hello CSI people,
As part of a off-list discussion between Jean-Michel and I (concerning
his previous mail on the list), I would bring a question to the people
here.
It appears there are several approaches proposed to indicate the
algorithms that should be used for creation of the Key Hash field and
Digital Signature field of the RSA Signature Option. I think it would be
good to only find one kind of approach among the different documents.
Here are the current approaches:
1) The approach proposed in draft-ietf-dhc-secure-dhcpv6 (to secure a
Signature Option that is really similar to the RSA Signature Option
defined in RFC 3971) is to use uncorrelated values. More specificaly,
the hash function for the Key Hash field is stored in a HA-id-KH field,
the hash function for the Signature field is stored in a HA-id field and
the Signature Algorithm is stored in a SA-id field.
Advantages:
- it allows a great flexibility
Disadvantages:
- it seems to be up for the administrator to find out which combination
of values are safe to use
- binding down attack (could be mitigated by a local policy)
2) The approach proposed in draft-cheneau-csi-send-sig-agility, is to
use a single value that refers to a predefined tuple of (hash function
for the Key Hash field, hash function for the Digital Signature field,
signature algorithm for the digital signature field). We also chose to
force the hash function for the Key Hash field and for the Digital
Signature field to be equals.
Advantages:
- better coherence between hash value and signature algorithm. Some
combination like SHA-1/ECC might not make sense.
- on an administrator perspective, it seems easier to authorise only a
set of "value" (i.e. hash function and algorithm) rather than a
combination of multiple values (previous solution)
- you can encode it using less bits
Disadvantages:
- binding down attack (mitigated by a local policy)
I think some people of the list (like the authors of
draft-ietf-csi-hash-threat) might have opinions on this.
Of course, I see most of the advantages on my solution, this is why I
bring it to the list, so that we obtain more pro and cons for each
solution (or maybe a third one).
Regards,
Tony
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
