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 protected]
https://www1.ietf.org/mailman/listinfo/int-area
