Subject: [Int-area] about draft-bagnulo-multiple-hash-cga-00

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 20 Jul 2006 16:07:07 +0300

Hi,

During the presentation of the draft in the Int area meeting there was 
quite a lot of feedback. First of all i would like to thank for so many 
constructive comments (this was an unusual experience for me at ietf 
:-)
As i understood most folks thought that it was a good idea to enable 
multiple hash support in the CGAs and that the proposed approach for 
supporting it was acceptable.

As i recall there was only one comment left for further discussion 
(please if there was another issue for discussion let me know and i 
will address it in the ml). The open issue was Gabriel question about 
supporting multiple public key algorithms and in case that we want to 
do this, whether this needs to be done in this draft/registry.

As you know, draft-bagnulo-multiple-hash-cga-00 is proposing the 
creation of a registry for the Sec values, so that the hash function 
can be encoded in the address itself, in order to prevent the so-called 
downgrading attacks. The registry will also contain the associated Sec 
parameter value for the assigned value.

The question raised by Gab is, in case we want to support multiple 
public key algorithms, do we need to encode them in the address itself?

After discussing this with Gab, my understanding is that the public key 
algorithm does not need to be encoded in the address itself, since this 
is not required to prevent downgrading attacks that may sprig from 
using weaker public key algorithms (please Gab correct me if my 
understanding is inaccurate).

In order to support multiple public Key algorithms, it is enough to 
define a CGA extension that contains the public key algorithm used (and 
maybe the correspondent key) and to use it as an input to the hash, 
rather than encode in address bits. This is so, because a downgrading 
attack using an alternative (weaker) public key function is no 
different than an attack based on finding an alternative public key 
(using the same algorithm). In order to attack a CGA using an 
alternative (weaker) public key algorithm, the attacker needs to find a 
CGA parameter data structure which hash output collides with the target 
CGA. In order to do that the attacks will probably try with alternative 
modifiers rather than try with alternative pubic keys (since it is 
cheaper as the modifier can be any value and its generation is simply 
adding 1 to the previous value).

So, from this, it results that in order to prevent downgrading attacks 
only the hash function needs to be included in the address itself, and 
other information (including alternative public key algorithms) can be 
included as CGA extensions. So no modifications to the draft will be 
made in order to support alternative public key functions.

I hope this addresses the point raised in the meeting

Comments?

Regards, marcelo

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area