Hi Christian,
thanks for your careful review, it is much appreciated
some comments below...
El 10/10/2006, a las 20:05, Christian Vogt escribió:
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.
ok
(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.
fully agree with this, however, not sure if we should include this in
the draft
i mean, we have discussed this point while writing this version of the
draft and our conclusion was that an implementation that would do this
would be really bogus so it was not worth mentioning it in the draft...
i mean, i am not sure we need to describe how people should not shoot
themselves in the foot in various ways...
(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.
i am not sure i understand this... i mean reassigning the Sec value
would result in a different implementation i.e. additional code for the
new hash function and so on, so i guess that more that a change in the
registry will be needed, but actual code is needed in the stack.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.
ok
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.
ok
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"
right
thanks again for your comments
Regards, marcelo
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
