Sheng JIANG, Ph.D.
IP Research Department, Networking Research Department, Network Product Line,
Huawei
Technologies Co. Ltd.
*-----Original Message-----
*From: marcelo bagnulo braun [mailto:[EMAIL PROTECTED]
*Sent: Wednesday, July 02, 2008 7:28 PM
*To: JiangSheng 66104
*Subject: [Fwd: CGA-EXT post from [EMAIL PROTECTED]
*requires approval]
*
*could you resend this with the email address that you are
*subscribed to the ml?
*
*
*-------- Mensaje original --------
*Asunto: CGA-EXT post from [EMAIL PROTECTED]
*requires approval
*Fecha: Wed, 02 Jul 2008 04:13:32 -0700
*De: [EMAIL PROTECTED]
*Para: [EMAIL PROTECTED]
*
*
*
*As list administrator, your authorization is requested for the
*following mailing list posting:
*
* List: [email protected]
* From: [EMAIL PROTECTED]
* Subject: RE: [CGA-EXT] Hash Agility in SEND (Was: new
*version of "Send Hash Threat Analysis")
* Reason: Post by non-member to a members-only list
*
*At your convenience, visit:
*
* https://www.ietf.org/mailman/admindb/cga-ext
*
*to approve or deny the request.
*
*
*
--- Begin Message ---
Hi, Julien,
I can agree with you that SEND and CGA may use the same hash function.
Actually, in
the current protocol, they do use the same sha-1. However, we should also
allow/support that they use different algorithms through we may not recommended
it.
I don't agree with your statement "the security of the resulting system can't be
stronger than the weakest of its components". Actually, in many cases, it may be
opposite: the strongest component decides the attacker's difficulty. Let's put
it
into a concrete example here, say, SEND uses algorithm B that stronger than
algorithm A in CGA and there is an attacker who can break algorithm A but not B.
Then, the attacker may produce a faked CGA option, but because he cannot
produce a
faked SEND signature option that use algorithm B, he can still get through the
SEND
verification. When multiple algorithms are use together, the attacker has to
break
all algorithms to break the security system.
Best regards,
Sheng
*-----Original Message-----
*From: [EMAIL PROTECTED]
*[mailto:[EMAIL PROTECTED] On Behalf Of Julien Laganier
*Sent: Tuesday, July 01, 2008 10:24 PM
*To: [email protected]; [EMAIL PROTECTED]
*Subject: [CGA-EXT] Hash Agility in SEND (Was: new version of
*"Send Hash Threat Analysis")
*
*
*Hello Ana, CSI'ers,
*
*I think I disagree with the paragraph of the draft copied
*below my note.
*
*To me it seems OK to specify that SEND should use the same
*hash function than CGA. Since they are used together to
*provide security, and since the security of the resulting
*system can't be stronger than the weakest of its components,
*the maximum level of security can be reached by choosing
*mechanisms (hash functions in this case) with similar security
*strength for both CGA and SEND.
*
*Improving the security level of only one of the component
*would not increase the overall security of the system.
*
*Has anybody an opinion on the topic?
*
*--julien
*
*> 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. In order to
*increase the
*> future security of SeND, we suggest the support for the hash and
*> algorithm agility in SeND.
*>
*> The most effective and secure would be to bind the hash function
*> option with something that can not be changed at all, like
*> [rfc4982] does for CGA - encoding the hash function information into
*> addresses. But, there is no possibilty to do that in SeND. 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.
*>
*> 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. 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.
*
*
*On Tuesday 01 July 2008, Ana Kukec wrote:
*> The new version of draft-kukec-csi-hash-threat is submitted.
*Comments
*> are welcome!
*>
*> Filename: draft-kukec-csi-hash-threat
*> Revision: 02
*> Title: SeND Hash Threat Analysis
*> Creation_date: 2008-07-01
*> WG ID: Independent Submission
*> Number_of_pages: 15
*>
*> Abstract:
*> This document analysis the use of hashes in SeND, possible
*threats and
*> the impact of recent attacks on hash functions used by SeND.
*> Current SeND specification [rfc3971] uses SHA-1 [sha-1] hash
*algorithm
*> and PKIX certificates [rfc3280] and does not provide support for the
*> hash algorithm agility. Based on previous analysis, this document
*> suggests multiple hash support that should be included in the SeND
*> update specification.
*>
*>
*> Ana
*>
*> _______________________________________________
*> CGA-EXT mailing list
*> [email protected]
*> https://www.ietf.org/mailman/listinfo/cga-ext
*
*
*
*_______________________________________________
*CGA-EXT mailing list
[EMAIL PROTECTED]
*https://www.ietf.org/mailman/listinfo/cga-ext
*
--- End Message ---
--- Begin Message ---
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
--- End Message ---
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
