Subject: [CGA-EXT] hash function agility support in draft-kukec-csi-hash-threat-02

From: Ana Kukec <[email-masked]>
Date: Sat, 06 Sep 2008 16:33:08 +0200

Hi all,

We didn't reach the consensus about how to support hash function 
agility. We should try to reach the consensus, thus, i am sending the 
summary of analysis, possible solutions for encoding the hash functions, 
pros and cons.

The uses of hashes are the following:
a) Digital signature in X.509 certificate. Attacker can produce the 
false certificate with the same identity data and signature, and 
different key. After that, he does not have to break any other hash 
(CGA, key hash field, digital signature), just uses that new, 
unauthorized key in the generation of mentioned fields.
b) CGAs. The same as with certificate, it is enough just to break the 
CGA, and use the false key in key hash field generation and for digital 
signature signing.
c) Key hash field. Again the same thing. Attacker breaks the key hash 
and does not have to break any other hash, cause he just uses the new 
key for other fields generation.
d) Digital signature. Attacker could change some of the SeND message 
fields. However the attack is probably just theoretically possible; in 
practice it is hard to perform it since there are mostly human-readable 
fields to be signed. Attacker does not need to break any other hash, the 
hashed message can be signed with authorized key (if attacker manages to 
change the message before the SeND node starts signing it).

The question is, do we need to provide opportunity to choose different 
hash algorithms? If attacker attacks just one hash, he breaks the whole 
chain. Thus, it is enough to define just one hash algorithm in the Hash 
Algorithm option.

On the other hand, the possibility for configuring multiple hashes 
provides additional flexibility. Additionally, we could support it 
because of the possible future changes in SeND.

What are your opinions?

Ana

_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Ana Kukec <[email-masked]>
Date: Wed, 10 Sep 2008 01:25:11 +0200

Hi all,

Just to summarize the possible options about encoding hash algorithm:

a) Use the same hash algorithm as in CGA for all hashes. There is no 
bidding down attack in that case. Different algorithms then CGA 
algorithm for other hashes does not increase security.

b) Use the Hash Algorithm option to define different (or the same?) 
algorithm for all hashes. It is vulnerable to the bidding down attack, 
but provides flexibility, since in the future, SeND might be used 
without CGAs.

Any opinions? :-)

Ana

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 10 Sep 2008 02:52:28 +0200

Hi Ana,

thanks for starting the disucssion on this.

see comments in-line

> unauthorized key in the generation of mentioned fields.
right, but this is not send specific, since it affects X.509 certs in 
general.
I don't think we should aim to solve this here
imho we should use it as baseline to compare whatever solution we come 
up with

> CGA, and use the false key in key hash field generation and for digital 
same here
CGA hash agility has already been addressed in a separate document, so i 
don't see the need to deal with it here as well
With the defined CGA hash agility should be enough to deal with it, right?

> key for other fields generation.
i think this is the key issue to address here. This is seND specific and 
this is what we should aim to solve

> change the message before the SeND node starts signing it).
i am not sure about this one

> chain. Thus, it is enough to define just one hash algorithm in the Hash 
but the problem is that we may end up conditioning other operations
I mean, CGAs are used for several things, not only send, so we may not 
want to impose changing all the different protocols in chain. In 
addition, there are many parties involved, Certs are generated by the CA 
and CGAs are generated by the host itself, so it may not be a good idea 
to require that both are upgraded simultaneously

I am not sure what would be the right way to go here

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 10 Sep 2008 03:00:52 +0200

> Just to summarize the possible options about encoding hash algorithm:
right thanks

> algorithm for other hashes does not increase security.

right
actually, as someone suggested in the meeting, it is also possible to 
encode the hash function in the last 3 bits of the address, 
irrespectivly the address is a CGA or not
> but provides flexibility, since in the future, SeND might be used 
well, the scope of bidding down attacks in this case could be limited by 
admin configuration. I mean, if it is determined that a given hash 
function is insecure, then hosts simply don't accept the hash algorithm 
any more and no bidding down attack is possible

The problem is when two hash algorithms with different level of security 
must be accepted simultaneously, so during that period, the attack will 
be possible

regards, marcelo

---

From: Ana Kukec <[email-masked]>
Date: Wed, 10 Sep 2008 11:57:34 +0200

Hey Marcelo,

I agree with what you said about certificates and CGAs. For the Key Hash 
and Digital Signature, please see my questions below.

marcelo bagnulo braun wrote:
> i think this is the key issue to address here. This is seND specific 
> and this is what we should aim to solve
Right, this is SeND specific, but i see the Digital Signature field as a 
bigger issue then this field. The Key Hash field is not susceptible to 
the collision attacks, since attacker chooses both keys, right? Preimage 
attacks could be more useful, but are not feasible. But even in that 
case, if an attacker breaks key hash and produces signature with the new 
key, there is still CGA to deal with. Right?

>> fields. However the attack is probably just theoretically possible; 
>> in practice it is hard to perform it since there are mostly 
>> human-readable fields to be signed. Attacker does not need to break 
>> any other hash, the hashed message can be signed with authorized key 
>> (if attacker manages to change the message before the SeND node 
>> starts signing it).
>>
>>   
Why? AFAIU, the Digital Signature field is vulnerable to the collision 
attack.  An attacker produces two colliding messages, underlays one of 
the messages to be signed with authorized keys (through CGAs), but uses 
another message afterwards.  However, the prediction and production of 
the useful content of such two messages is just theoretically possible, 
since SeND message contains mostly human readable data. And as rfc4270 
says, the structure of at least one of two messages is predefined. What 
am i missing here?

>> The question is, do we need to provide opportunity to choose 
>> different hash algorithms? If attacker attacks just one hash, he 
>> breaks the whole chain. Thus, it is enough to define just one hash 
>> algorithm in the Hash Algorithm option.
>>
>>   
> addition, there are many parties involved, Certs are generated by the 
> CA and CGAs are generated by the host itself, so it may not be a good 
> idea to require that both are upgraded simultaneously
>
Right, that is about flexibility, we should not expect from CA and host 
to use the same algorithm. It might be useful to give opportunity to 
define separate algorithm for certs, and use CGA algorithm for other 
hashes. CGAs are used for different purposes, but CGA hash threat 
analysis and hash agility is provided by the rfc4982, we should not 
bother with that, right?

Ana

---

From: JiangSheng 66104 <[email-masked]>
Date: Wed, 10 Sep 2008 23:36:23 +0800

See my reply in lines.

Sheng

----- Original Message -----
From: marcelo bagnulo braun <[email-masked]>
Date: Wednesday, September 10, 2008 9:00 am
Subject: Re: [CGA-EXT] hash function agility	supportin draft-kukec-csi-hash-threat-02
To: Ana Kukec <[email-masked]>
Cc: [email-masked]

> Ana Kukec escribió:
> > Hi all,
> >
> > Just to summarize the possible options about encoding hash 
> algorithm:>   
> right thanks
> 

I am support to use the same hash algorithm while don't want to rule out the necessariness of a new hash algorithm option. There are some scenarios that CGA option is not necessary and SEND Signature is needed. For example, according to RFC3971, "Router Advertisement, and Redirect messages MUST contain the RSA Signature option", but CGA option is not mandate. In these cases, since no CGA hash algorithm be described, we do need a SeND option to describe the hash algorithm in SeND.