Hi Marcelo, thanks for revising the document according to the earlier comments. The new text is technically fine IMO, although I would add the following three points regarding CGA Sec reuse to the last paragraph of section 3.1:
(1) Erroneous use of an obsolete set of CGA parameters for a given SEC value, both on the CGA owner's side and the CGA verifier's side, would not be dramatic: CGA verification would fail in the worst case and both nodes would have to revert to unprotected IPv6 addresses. This can happen only with obsolete CGA parameter sets, which would be considered insecure anyway. (2) CGA implementations must not accept two different meanings of the same Sec value as this would introduce a possibility for downgrading attacks. Specifically, an attacker may be able to find a set of CGA parameters that produces a victim's CGA with a cryptographically weak algorithm, while the victim itself has previously generated the CGA with a cryptographically stronger algorithm. (3) Optimally, new CGA implementations should include an interface via which they can 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. Feel free to copy and paste. And some editorial suggestions... > 4. CGA generation procedure > > CGAs MUST be generated according to the generation procedure defined > in the SEC registry defined in the IANA considerations section of > this document. More precisely: The corresponding Sec registry entry defines an RFC which in turn defines the CGA generation/verification procedure. > It should be noted that the CGA generation procedure may be changed > by the new procedure not only in terms of the hash fucntion used but > also in other aspects, e.g. longer Modifier values may be required if > the number of 0s required in Hash2 exceed the currently defined > bound of 112 bits. You may want to add a sentence saying that the new procedure (which potentially involves a longer Modifier value) would be described in the RFC pointed to by the corresponding Sec registry entry. The reader may otherwise wonder where the procedure is actually defined. In section 3.1, last paragraph: > interoperate properly (i.e. if an old implementation receives a CGA > generated with the new meaning of the Sec value, it will fail and the > same for a new implementation receiving a CGA generated with the new > meaning of the Sec value). In case the approach of reassigning a > Sec "and the same for a new implementation receiving a CGA generated with the s/new/old/ meaning of the Sec value" Kind regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ marcelo bagnulo braun wrote: > Hi, > > we have submitted a new version of the draft including the comments > discussed in this ml and the meeting. > > further comments on the document are welcome > > Thanks, marcelo _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
