Re: Comments on draft-bagnulo-multiple-hash-cga-01 (was Re: [Int-area] Fwd: I-D ACTION:draft-bagnulo-multiple-hash-cga-01.txt)

El 13/10/2006, a las 9:57, Christian Vogt escribió:

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

ok i see your point and i don't have a strong preference w.r.t. 
including or not including a comment about this issue.

If anyone else has an opinion on this it would be nice to hear about it.

Regards, marcelo

> 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
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area