Hello,
A colleague of mine (A. Boudguiga) and I were working on a similar
document to support multiple signature algorithms in CGA/SEND. We have
chosen a different approach in order to "select" the algorithm. I
explain why in the next paragraphs.
Your solution involves using a new ECDSA signature option instead of
the RSA one. The signature algorithm selection is not embedded in the
address and this presents a vulnerability to downgrade attacks (in the
same way as explained in RFC 4982). In SEND as defined in RFC3971,
there was no issue with the RSA signature option since there was no
choice. In case of usage of ECC signature option, an attacker can
strip off a secured message from his CGA and ECC signature options, and
instead use RSA. He then has to find a collision with the Hash1 and
Hash2 (which is not easy) and to obtain exactly the same address.
We propose another mechanism for selecting different signature
algorithms. Hash1 and Hash2 computation algorithm and RSA/ECC/whatever
signature algorithm are strongly related to the overall security level
of the CGA/SEND solution (we have seen talks about that in a previous
thread of this mailing list). RFC 4982 already redefine the semantic
of the SEC bits of the interface identifier. It is not far fetched to
actually change (again) the semantic of the SEC bits to code the value
of the tuple signature algorithm/hash algorithm/"number of 0 bits in
Hash2". It is also backward compatible with the actual SEND
specifications and RFC 4982's updates.
We propose theses values of SEC (previous values and new values):
+------------------------+--------+
| Name | Value |
+------------------------+--------+
| SHA-1_0hash2bitsRSA | 000 |
| | |
| SHA-1_16hash2bitsRSA | 001 |
| | |
| SHA-1_32hash2bitsRSA | 010 |
| | |
| SHA-1_0hash2bitsECDSA | 100 |
| | |
| SHA-1_16hash2bitsECDSA | 100 |
| | |
| SHA-1_32hash2bitsECDSA | 101 |
+------------------------+--------+
I have one other small comment: in section 4.1, when you describe the
Key Hash field. You are talking about SHA-2, it refers to the previous
SHA-256 at the beginning of the paragraph: this is confusing, IMHO it
would be better to use "SHA-256" all along your paragraph.
Best regards,
Tony Cheneau
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
