Subject: [CGA-EXT] about draft-kukec-csi-hash-threat-02

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 17 Sep 2008 17:57:30 +0200

Hi,

I have read the draft and i have the following comments:

First overall comment, i understand that the analysis of the attacks 
affecting the hash functions are only about collision attacks, right? I 
mean, we don't make the analysis of what could happen if other attacks 
affecting other properties of the hash fucntion were possible, right?

However, in the section about the recommendation, i understand the 
analysis is broader and we do perform an analysis about what type of 
attacks woudl be possible to the new extension if the has function was 
completely broken, right?

In section 3.2. Attacks against PKIX certificates in ADD process it reads

   Additionally, since identity field
   is humane readable data, certificates are not affected by collision
   attacks in practice.

I don't understand this sentence, could you expand?

   Implementations SHOULD use human-readable
   certificate extensions only if SeND certificate profile demands.

I don't understand this recommendation, could you expand?

In the same section, it first states:

   In 2005 they succeeded to construct the original and the false
   certificate that had the same identity data and digital signature,
   but different public keys [new-hashes].

and then it states*
*
   In 2007 were demonstrated certificates with the same identity data
   and signatures, which differed only in public keys.

I don't understnad the difference between the attack in 2005 and the one 
in 2007, could you explain that?
 From the text that follows, that reads:
   Such attacks are
   potentially more dangerous, since attacker can decide about contents
   of human readable fields, and produce for example certificates with
   the same signatures, but different identities or validity periods.

It seems to me that the description of the attack of 2007 is wrong, 
since the two certificates not only differ in the public keys. However, 
if that is the case, i don't understnad why the attack in 2007 is worse 
than the one in 2005. I mean, if you can generate two certs that only 
differen in the pk, then you can generate any two certificates that 
differ in whatever you want, since the most restricitve situation is 
when you can only change the pk afaiu.

I find the section on the analysis on the certificates a bit 
inconclusive. I mean, you describe a set of attacks, which all of them 
are about to create two certs with more or less similar data and with 
different pk. Do these attacks have some implications in send? How would 
an attacker launch an attack to send using that?
My understnading is that no new attack against send is possible because 
of that. I mean, this basically affects non repudiation and send does 
not provides or uses non repudiation features afaict.

So, i would like to suggest to try to understand if these attacks 
against certificates have some implication in send security and if there 
are new attacks that can be launched against send and include that in 
the document.

In section 3.3. Attacks against Digital Signature in RSA Signature 
option it reads

   However, the problem for the attacker is that they are
   very hard to predict the useful input data.

why is that?

   It minimizes the
   possibility for a real-world collision attack

what minimizes the possibility? please rephrase

   and the fact that in
   order to perform a succesful real-world attack he can not change a
   human-readable data.

how is that? SeND is exectued without human intervention, so i am not 
sure this argument applies
(in addition, rephrase this cause it is hard to understand, in 
particular, it is hard to follow the linking with the previous sentence)

   But we also have to take into account that a
   variant of SHA-1 was already affected by recent collision attacks and
   we have to prepare for future improved attacks.

This seems that was left unfinished

Again, this section seems inconlcusive to me.
suppose that an attacker could actually do what you describe, what would 
be the actual impact of the attack? I mean, would it be able to affect 
send in some way?
Again, i think not, cause send does not relies in non repudiation afaict
I think additional text is needed to describe the impact on the send 
protocol of the described attack

In section 3.4. Attacks against Key Hash in RSA Signature option

   a non human-readable data.  But the problem for the attacker is that
   a public key, which is input data is authorized through CGAs, and
   sometimes additionally through a certification path if peer has
   configured trust anchor.  For the succesful attack, attacker has to
   break both SHA-1 hashed public key, as well as corresponding CGA and
   possibly a certification path.  Otherwise, changed key pair will be
   detected in the process of CGA verification.

But if i manage to generate the hash colision, i will probably want to 
use a different pk, one that i have the private key for, right?

So, i am not sure you also need to break the pk in order to lauch some 
attack here

Again, i think the section is inconclusive, Again, i think the collision 
attack affect non repudiation so i would like to have an analysis of non 
repudiation in send and see if it is possible to launch an attack that 
affect send. If not i would like to have some conclusion about this

Later on in 4. Support for the hash agility in SeND

   While all of analyzed hash functions in SeND are theoretically
   affected by recent collision attacks, these attacks indicate the
   possibility of future real-world attacks.

please rephrase, it is not clear to me what you mean

besides, i don't think the attacks actually affect send, since they only 
affect non repudiation afaict and send does not relies on non 
repudiation afaict

later on it reads:

   We could decide to
   use by default the same hash function in SeND as in CGA, but this
   solution is architecturally strange and it does not really increase
   the security since the difficulty for attackers remain to break one
   single hash function.  Furthermore, it may even reduce the security
   level by providing more relevant information of the hash function.
   On the other side, the use of two different hash algorithms makes
   attacker's life harder.

I am not sure i follow the line of reasoning here
If a hash function can be attacks, it is bad to use it, in one or in two 
palces, is still the same casue it is broken. So if you are using the 
same function in the two places you are in a very bad shape indeed. But 
if you are using it in only one place, you are worse than if you are not 
using it at all, so i don't see how the above point applies

I would simply suggest to remove the last sentence

later on...

   Another solution is to incorporate the hash function option into SeND
   message.  By putting a new hash function option in SeND message
   before RSA Signature option, attacker will have to break both the
   signature and the hash input at the same time since the new option
   will be input field for the Digital Signature in RSA Signature
   option.  However, we can not avoid a downgrade attack totally because
   peer might be using just ND and not SeND.

i don't follow that
A downgrade attack would be performed in a different way imho
AFAIU, a downgrading attack would be performed by the attacker changing 
the hash function to an weaker hash fucntion that it can crack and then 
simply changing the content of the message.
the downgrading attack is not possible because some nodes use just ND 
but because you are using the hash function to sign the hash function 
that you are using, so breaking the hash function allows you to break 
the signature for it, so you can change the hash fucntion you are 
claiming to use.

Question, wouldn't it be possible to modifiy the signature, so that the 
hash algorithm field is not signed using a hash function at all? i.e. is 
directly encrypted wihtout performing a hash before so, that in order to 
change the hash funtion field you need to break the pk encryption but 
not the hash algorithm?

(not sure if you are following what i am saying here, but i think it may 
be possible)

regards, marcelo

  A completely safe solution
   here does not exist.  A new hash function option in SeND message is a
   reasonable and the best solution for the hash algorithm agility
   support in SeND.

   Each implementation SHOULD use different hash or signature algorithms
   for each of the relevant fields (Key Hash field, Digital Signature,
   PKIX signature algorithm).  Since all algorithms are in different
   procedures, making them the same does not make those procedures
   simpler, but making them different complicates possible attacks.

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

---

From: Ana Kukec <[email-masked]>
Date: Fri, 19 Sep 2008 19:15:27 +0200

Hey Marcelo,

There is a new version of draft (draft-ietf-csi-hash-threat-00), most 
paragraphs are changed compared to draft-kukec-csi-hash-threat-02. Below 
are the comments for those parts of text which did not change. I think 
other questions are, at least partly, answered in the new parts of text.

Thank you for the comments, and please see my comments below, and in the 
new version of draft.

marcelo bagnulo braun wrote:
> affecting the hash functions are only about collision attacks, right? 
> I mean, we don't make the analysis of what could happen if other 
> attacks affecting other properties of the hash fucntion were possible, 
> right?
Right.
> completely broken, right?

Right. Scenarios in which the hash is completely broken are also 
described, but just for the  comparation purposes. That is something 
what we were talking in Philadelphia -- do we have to solve all the 
attacks or just the attacks which are up to date possible in practice. 
We decided to mention in the draft all the attacks (including just 
theoretically possible ones), but to solve just practically possible 
attacks.

> I don't understand this sentence, could you expand?
Is something like this better..?
"Attacks against the human-readable fields demand much more effort than 
the attacks against non human-readable fields, such as a public key 
field. In case of the identity field, an attacker is faced with the 
problem of the prediction and the generation of the false but meaningful 
identity data, which at the end might be revealed by the Certification 
Authority. Thus, in practice, collision attacks do not affect non 
human-readable parts of the certificate."

> I don't understand this recommendation, could you expand?
It should be something like this: "Implementations MUST use 
human-readable certificate extensions in accordance with 
[draft-krishnan-cert-eku..]."

> I don't understnad the difference between the attack in 2005 and the 
> one in 2007, could you explain that?

Oh, typo. In 2005 - the same distinguished names, while in 2007 - 
different distinguished names.

> since the two certificates not only differ in the public keys. 
> However, if that is the case, i don't understnad why the attack in 
> 2007 is worse than the one in 2005. I mean, if you can generate two 
> certs that only differen in the pk, then you can generate any two 
> certificates that differ in whatever you want, since the most 
> restricitve situation is when you can only change the pk afaiu.

I am not sure i understand the last sentence. 2005 certificates differ 
only in public keys. The resulting hash value in 2005 attack is a random 
string. The only X.509 cert field in which such random string can be 
placed is pk. You can not generate any two certs that differ in whatever 
you want. And if you have two certificates that differ only in pk, i 
don't see what could you do with them. Those certificates has the same 
identities, the same validity periods, everything. The only thing you 
can do is to blame Certification Authority for the issuance of two 
certificates with different keys.

In 2007 the Intermediate Hash Value is extended in the way that it can 
be placed in the X.509 human-readable field. So, you can claim you are 
someone else, you could change validities, etc. Which is potentially 
more dangerous, right?

> different pk. Do these attacks have some implications in send? How 
> would an attacker launch an attack to send using that?
> My understnading is that no new attack against send is possible 
> because of that. I mean, this basically affects non repudiation and 
> send does not provides or uses non repudiation features afaict.
>
> against certificates have some implication in send security and if 
> there are new attacks that can be launched against send and include 
> that in the document.

IMO, the attacks which affect just pk do not have implications in send. 
But, attacks which affect human-readable data have implications in send. 
For example, the changed set of IP prefixes in the rfc3779 IP address 
extension, changed validity period. Up to date, no such attack has been 
demonstrated, but 2007 attack against identity field is on the way to 
such attacks.

> particular, it is hard to follow the linking with the previous sentence)
My understanding is that, taking into account demonstrated collision 
attacks, it is hard to generate two useful, meaningful human-readable 
fields. Because, in the recent collision attacks, at least on of two 
messages has predefined shape, as described in section  2.1, rfc4270.

>
> Question, wouldn't it be possible to modifiy the signature, so that 
> the hash algorithm field is not signed using a hash function at all? 
> i.e. is directly encrypted wihtout performing a hash before so, that 
> in order to change the hash funtion field you need to break the pk 
> encryption but not the hash algorithm?
>
> (not sure if you are following what i am saying here, but i think it 
> may be possible)
>
Yes, i think it may be possible, with both the hash algorithm field, and 
the digital signature field. Should we analyze this case?

Ana

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 19 Sep 2008 22:22:36 +0200

Hi Ana,

Ana Kukec escribió:
> paragraphs are changed compared to draft-kukec-csi-hash-threat-02. 
oops, i guess i need to read that one next

> Below are the comments for those parts of text which did not change. I 
> think other questions are, at least partly, answered in the new parts 
> of text.
>
ok, thanks

> Thank you for the comments, and please see my comments below, and in 
> the new version of draft.
>
>> attacks affecting other properties of the hash fucntion were 
>> possible, right?
> Right.
>>
>> attacks woudl be possible to the new extension if the has function 
>> was completely broken, right?
>
I still don't understand

the analysis you have made is basically about collision attacks

However, when we consider how to encode the hash function in send, we 
also consider the attacks against other properties of the hash function, 
in particular to the preimage attacks. I mean, bidding down attacks 
being considered are not about collision free, but about the preimage 
attacks afacit, right?

> "Attacks against the human-readable fields demand much more effort 
> than the attacks against non human-readable fields, such as a public 
> key field. In case of the identity field, an attacker is faced with 
> the problem of the prediction and the generation of the false but 
> meaningful identity data, which at the end might be revealed by the 
> Certification Authority. Thus, in practice, collision attacks do not 
> affect non human-readable parts of the certificate."

much clearer
> [draft-krishnan-cert-eku..]."

So basically what you are saying is that the it is better to use only 
human readable fields because they are harder to attack.
A couple of comments.
First, as i understand it, send certificates are never exposed to the 
users, so, i am not sure who would verify that the fields are indeed 
human readable.

Second, i am not sure that this spec is a standard specification, so i 
am not sure that normative lenguage is to be used in the document

> only in public keys. The resulting hash value in 2005 attack is a 
> random string. The only X.509 cert field in which such random string 
> can be placed is pk. You can not generate any two certs that differ in 
> whatever you want. And if you have two certificates that differ only 
> in pk, i don't see what could you do with them. Those certificates has 
> the same identities, the same validity periods, everything. The only 
> thing you can do is to blame Certification Authority for the issuance 
> of two certificates with different keys.
>
ok, makes sense

>> inconclusive. I mean, you describe a set of attacks, which all of 
>> them are about to create two certs with more or less similar data and 
>> with different pk. Do these attacks have some implications in send? 
>> How would an attacker launch an attack to send using that?
> IMO, the attacks which affect just pk do not have implications in 
> send. But, attacks which affect human-readable data have implications 
> in send. For example, the changed set of IP prefixes in the rfc3779 IP 
> address extension, changed validity period. Up to date, no such attack 
> has been demonstrated, but 2007 attack against identity field is on 
> the way to such attacks.
>
so you should analyze the impact in send of these potentially possible 
attacks and write them down in the document

> Yes, i think it may be possible, with both the hash algorithm field, 
> and the digital signature field. Should we analyze this case?
>
please do

regards, marcelo

---

From: Ana Kukec <[email-masked]>
Date: Fri, 19 Sep 2008 23:03:56 +0200

> being considered are not about collision free, but about the preimage 

Right, it is. In the new version of draft, in the analysis part, are 
considered both the preimage and collision attacks. IMO, it might be 
useful to analyze both attacks, to clarify things more precisely, and 
also because of some possible future attacks. Contrary to the analysis 
part, IMO, the solution part should be based on the collision attacks. 
The downgrade attack is mentioned at the end, just as one additional plus.
Do you agree for the analysis part to include both collision and 
preimage attack analysis? And, do you agree that the solution should be 
based on collision attacks only?

>> human readable fields because they are harder to attack.

No. Just that non-human readable fields demand less effort to break 
them, since, it is easier to extend the IHV value to a random string, 
than to a meaningful data.

> attacks and write them down in the document

Ok, it will be added in the next version.
>> and the digital signature field. Should we analyze this case?
Ok, it will be added also.

Thank you,
Cheers

Ana