Hi, Tony,
Sorry for the delayed response. I recently got some problems with sending
emails to CSI and some other IETF lists; I am contacting chairs to figure it
out. Not even sure this message will show up in the CSI, but at least the
emails between individuals are still smooth and we can discuss the
techniques.
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.
Actually, there are two parts of work about PKI for SEND and CGA:
1. ECC support for SEND and CGA;
2. PKI agility for SEND and CGA.
The first work focus on the format and parameter specs for ECC usage in SEND
and CGA, this is what our draft does. The second work will focus
selection/negotiation of multiple PKI algorithms. Since PKI agility should
support not only RSA&ECC but also possible future PKI algorithms, it is not
proper for an ECC support draft (our draft) to include this work. Maybe a
future bis version of SEND&CGA is a good one to include PKI agility feature.
Michaela and I are writing a proposal for the second work and plan to
present a ppt at Dublin. We are still improving it and hope to make it
available for discussion soon. The downgrade attack is definitely an
important issue need to be considered in such work.
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 |
+------------------------+--------+
Carrying PKI algorithm information in SEC bits is an interesting idea. But I
doubt that 3 bits (2^3 possibilities) are enough, especially if we are
considering future PKI algorithms not limited to RSA&ECC. Also, the hash
function information might need more SEC values since SHA-1 is not as same
as people expected.
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.
Thanks for the good catch. We will make it uniform.
Thank you!
Sean
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
