Hi Jari and Marcelo, your proposed changes to change RFC 3971 make sense. It would be good to let IPv6 nodes choose a more secure hash function than SHA-1 for CGA generation.
Two more specific comments, though. Many thanks to Mark Doll for an excellent discussion on this. (1) Since there are only 8 possible Sec values, wouldn't it make sense to recycle the semantics of these values over time? Specifically, if an old CGA SEC registry entry is found to be insecure, it could be deprecated for a certain (minimum) time, so that CGA implementations have time to migrate to a more secure combination of hash function and number of leading zero bits in Hash2. When there is need for a new combination, the oldest deprecated registry entry would eventually get replaced. Along this line, we could deprecate registry entry 0 (SHA-1 + 0 leading zero bits in Hash2) today. Optimally, new CGA implementations should include an interface via which they could be updated to registry changes. But since such changes are expected to occur only at a very low frequency, it may just be sufficient to pre-configure CGA implementations. Erroneous use of an obsolete CGA SEC combination would not be dramatic: CGA verification would fail in the worst case and nodes would have to revert to unprotected IPv6 addresses. But note this would happen only if the obsolete CGA SEC combination was considered insecure anyway. (2) Wouldn't the length of the modifier have to be defined as part of the CGA SEC registry, too? If we define the number of leading zero bits for Hash2, say N, as part of the registry, we are no longer bound to the limit of 16 * (23 - 1) = 112 bits which the 3-bit Sec parameter provides. However, the length of the modifier should be at least as long as N plus a certain number of bits for location privacy. Since this may, at some future time, exceed the limit of 112 bits, it may be good to define the modifier length as part of the IANA registry, too. Alternatively, the length of the modifier could be defined implicitly, e.g., as: |modifier| = max(128, 59 + N) This ensures that the modifier cannot be shorter than it is today (i.e., 128 bits), facilitating backward-compatibility for existing CGA implementations which use a Sec value of 0. Of course, the current 128-bit length of the modifier is likely to be sufficient for decades. It just seems that the prospective revision of RFC 3972 provides a good opportunity to make this change. Best, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
