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: > > 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? 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? 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. > > 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? 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." > > Implementations SHOULD use human-readable > certificate extensions only if SeND certificate profile demands. > > > 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..]." > > 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? Oh, typo. In 2005 - the same distinguished names, while in 2007 - different distinguished names. > 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 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? > > 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. 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. > > 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) 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 _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
