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

Christian Vogt <chvogt@tm.uka.de> Fri, 13 October 2006 07:58 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYHve-0000PH-5g; Fri, 13 Oct 2006 03:58:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYHvc-0000Oy-EU for int-area@ietf.org; Fri, 13 Oct 2006 03:58:00 -0400
Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYHvV-0006Md-Si for int-area@ietf.org; Fri, 13 Oct 2006 03:58:00 -0400
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GYHvI-0007FA-UG; Fri, 13 Oct 2006 09:57:48 +0200
Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GYHvI-0001ri-5K; Fri, 13 Oct 2006 09:57:40 +0200
Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 471DAB52E; Fri, 13 Oct 2006 09:57:39 +0200 (CEST)
Message-ID: <452F46F2.40407@tm.uka.de>
Date: Fri, 13 Oct 2006 09:57:38 +0200
From: Christian Vogt <chvogt@tm.uka.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.7) Gecko/20060911 SUSE/1.5.0.7-0.1 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
Subject: Re: Comments on draft-bagnulo-multiple-hash-cga-01 (was Re: [Int-area] Fwd: I-D ACTION:draft-bagnulo-multiple-hash-cga-01.txt)
References: <40dc605df2956ceedc6e48599d336482@it.uc3m.es> <452BE0FB.5000602@tm.uka.de> <794a8143ab6a46b4575fcd74c41fe7ad@it.uc3m.es> <452DF512.20001@tm.uka.de> <45f114e2f7cdcedf4e633e34c96a04d0@it.uc3m.es> <452E1BDE.1000303@tm.uka.de> <fdadf8d3ac68a522e2bbc2a14a32fe54@it.uc3m.es>
In-Reply-To: <fdadf8d3ac68a522e2bbc2a14a32fe54@it.uc3m.es>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Spam-Score: -4.3 (----)
X-Spam-Status: No
X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.1 AWL AWL: From: address is in the auto white-list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: Mark Doll <doll@tm.uka.de>, INT Area <int-area@ietf.org>
X-BeenThere: int-area@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@lists.ietf.org>
List-Help: <mailto:int-area-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=subscribe>
Errors-To: int-area-bounces@lists.ietf.org

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