Hi Christian,

El 12/10/2006, a las 9:56, Christian Vogt escribió:

Hi Marcelo!

<snip>

(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...

Good point.  Maybe the security considerations is a better place to
discuss this.  The security considerations should in any case discuss
the issue of downbidding attacks IMO

but all the document discuss security issues, so we could say that all the document is security considerations (that is basically what it says in the security considerations section...)

I am not sure what is the usual approach for this type of documents where all the content is security related... do they usually contain a sort of summary in the security consideration section or do they just mention that all the document is about security and that's it?

i am ok with any of the approaches, just that this one was easier :-)

---basically saying that no
downbidding threat exists---, so it could be briefly mentioned there
that the inability to pursue a downbidding attack hinges on
implementations not accepting two different meanings of the same Sec value.


don't know... does anyone else has an opinion?

thanks, marcelo


(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.

I see your point.  That's correct.

<snip>

Take care,
- 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

Reply via email to