> the second and the third paragraph in section 3.1. describes how a > downgrading attack would work and the rest of the section presents > different approachs that would not be vulnerable to those attacks and > selects one among them. Do you think that more text is needed about > downgrading attack?
Hi Marcelo, actually, I do, because the conclusion from the 2nd and 3rd paragraphs in section 3.1 is that downgrading can be prevented by encoding the hash function into the CGA (rather than specifying it as part of the CGA parameters). But this is true only under the assumption that no two encodings can be valid at the same time. You may say that this is a matter of course (which I actually do agree with). But it may not be so obvious for everyone who reads the document or even writes the CGA software. It's my personal feeling that the document should explicitly mention that CGA implementations must always be limited to a single meaning per Sec value. Regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ marcelo bagnulo braun wrote: > El 12/10/2006, a las 12:41, Christian Vogt escribió: > >> Hmm, the document first describes the deficiencies of today's CGA >> and then provides a solution. The Security Considerations section >> typically discusses any remaining security issues with the >> solution, or it explains why a typical threat that people might be >> concerned about does not apply. Since downbidding is such a >> typical threat, I thought that the Security Considerations should >> explain why the proposed solution is not vulnerable to it. But >> it's totally fine if you put the explanation elsewhere if that >> works better with the current draft structure. > > the second and the third paragraph in section 3.1. describes how a > downgrading attack would work and the rest of the section presents > different approachs that would not be vulnerable to those attacks and > selects one among them. Do you think that more text is needed about > downgrading attack? > > Regards, marcelo _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
