Subject: [CGA-EXT] new version of "Send Hash Threat Analysis"

From: Ana Kukec <[email-masked]>
Date: Tue, 01 Jul 2008 15:33:52 +0200

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-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Julien Laganier <[email-masked]>
Date: Tue, 1 Jul 2008 16:24:22 +0200

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.

---

From: Julien Laganier <[email-masked]>
Date: Wed, 2 Jul 2008 12:17:29 +0200

Hi Sheng, 

If I can generate a public-private key pair that yields an arbitrary CGA 
(attack against your A below), then I can impersonate that CGA's owner 
by simply signing with that public-private key pair -- no need to break 
the digital signature algorithm (your B).

--julien

On Wednesday 02 July 2008, Sheng Jiang wrote:
> 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-masked]
> *[mailto:[email-masked]] On Behalf Of Julien Laganier
> *Sent: Tuesday, July 01, 2008 10:24 PM
> *To: [email-masked]; [email-masked]
> *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-masked]
> *> https://www.ietf.org/mailman/listinfo/cga-ext
> *
> *
> *
> *_______________________________________________
> *CGA-EXT mailing list
> [email-masked]
> *https://www.ietf.org/mailman/listinfo/cga-ext
> *

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 02 Jul 2008 18:40:57 +0800

Hi, Julien,

Your example is correct. However, it is misleading. You were talking about you have
found a collisional public-private key pair. In that case, no matter how strong the
hash algorithms are, you can break the whole security system. Our assumption here
is: based on a collision free public-private key pair, whether one hash algorithm
with two results or two hash algorithms with two results are stronger. My choice is
the latter.

Best regards,

Sheng JIANG, Ph.D.

IP Research Department, Networking Research Department, Network Product Line, Huawei
Technologies Co. Ltd.

*-----Original Message-----
*From: julien laganier [mailto:[email-masked]] On 
*Behalf Of Julien Laganier
*Sent: Wednesday, July 02, 2008 6:17 PM
*To: Sheng Jiang
*Cc: [email-masked]; [email-masked]
*Subject: Re: [CGA-EXT] Hash Agility in SEND (Was: new version 
*of "Send Hash Threat Analysis")
*
*Hi Sheng, 
*
*If I can generate a public-private key pair that yields an 
*arbitrary CGA (attack against your A below), then I can 
*impersonate that CGA's owner by simply signing with that 
*public-private key pair -- no need to break the digital 
*signature algorithm (your B).
*
*--julien
*
*On Wednesday 02 July 2008, Sheng Jiang wrote:
*> 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-masked]
*> *[mailto:[email-masked]] On Behalf Of Julien Laganier
*> *Sent: Tuesday, July 01, 2008 10:24 PM
*> *To: [email-masked]; [email-masked]
*> *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-masked]
*> *> https://www.ietf.org/mailman/listinfo/cga-ext
*> *
*> *
*> *
*> *_______________________________________________
*> *CGA-EXT mailing list
*> [email-masked]
*> *https://www.ietf.org/mailman/listinfo/cga-ext
*> *
*
*
*

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 02 Jul 2008 14:49:46 +0800

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-masked] 
*[mailto:[email-masked]] On Behalf Of Julien Laganier
*Sent: Tuesday, July 01, 2008 10:24 PM
*To: [email-masked]; [email-masked]
*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-masked]
*> https://www.ietf.org/mailman/listinfo/cga-ext
*
*
*
*_______________________________________________
*CGA-EXT mailing list
[email-masked]
*https://www.ietf.org/mailman/listinfo/cga-ext
*

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 2 Jul 2008 14:25:51 +0200

Hi,

> Has anybody an opinion on the topic?

At first sight, I agree with you for NA/NS/RS messages when CGA option is used.
Now, I must admit I have no opinion for RA messages when CGA option is
used because, at least for me, the specifications are not enough clear
for the moment (cf.
http://www.ietf.org/mail-archive/web/cga-ext/current/msg00102.html).

Cheers.

JMC.

---

From: Julien Laganier <[email-masked]>
Date: Wed, 2 Jul 2008 14:28:21 +0200

Sheng,

I am not talking about finding a collisional public-private key pair, 
whatever that is. 

I'm talking about a CGA hash function with broken pre-image resistance.

Given a CGA CGA1 generated (via the hash function) from a public-private 
key pair PK1/SK1, if can find a preimage to the CGA1, I can extract 
from the preimage another public-private key pair PK2/SK2 that yields 
the same CGA CGA1, and thus I can impersonate that CGA CGA1 by signing 
messages with the public-private key pair PK2/SK2.

There's no need to break anything in the SEND specification, neither the 
digital signature algorithm, or the hashes. I simply break the hash 
function used for CGA generation.

--julien

On Wednesday 02 July 2008, Sheng Jiang wrote:
> Hi, Julien,
>
> Your example is correct. However, it is misleading. You were talking
> about you have found a collisional public-private key pair. In that
> case, no matter how strong the hash algorithms are, you can break the
> whole security system. Our assumption here is: based on a collision
> free public-private key pair, whether one hash algorithm with two
> results or two hash algorithms with two results are stronger. My
> choice is the latter.
>
> Best regards,
>
> Sheng JIANG, Ph.D.
>
> IP Research Department, Networking Research Department, Network
> Product Line, Huawei Technologies Co. Ltd.
>
>
> *> 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
> *> are use together, the attacker has to break all algorithms to
> break *> the security system.
> *>
> *> Best regards,
> *>
> *> Sheng
> *>
> *> *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.
> *> *
> *> 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.
> *> *
> *> *>    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
> *> 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 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,
> *> 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.
> *> *>
> *> *> different procedures, making them the same does not make those
> *> *> procedures simpler, but making them different complicates
> *possible *>
> *> attacks.
> *> *
> *> *
> *> 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

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 02 Jul 2008 21:04:06 +0800

Hi, Julien,

What you describe is exactly collisional public-private  key pair. You find another
key pair that just happens to match the result from key pair 1. You break one of the
two assumptions for hash function [rfc4270]. Yes, in your case, multiple hash
functions does not help and "the system can't be stronger than the weakest of its
components".

However, even so, it does not means we should forbid or restrict the usage of
multiple hash function. The second stronger hash function does not do any harm in
your case and may help when we face other kind of threats.

Best regards,

Sheng JIANG, Ph.D.

*-----Original Message-----
*From: julien laganier [mailto:[email-masked]] On 
*Behalf Of Julien Laganier
*Sent: Wednesday, July 02, 2008 8:28 PM
*To: [email-masked]; Sheng Jiang
*Cc: [email-masked]
*Subject: Re: [CGA-EXT] Hash Agility in SEND (Was: new version 
*of "Send Hash Threat Analysis")
*
*Sheng,
*
*I am not talking about finding a collisional public-private 
*key pair, whatever that is. 
*
*I'm talking about a CGA hash function with broken pre-image resistance.
*
*Given a CGA CGA1 generated (via the hash function) from a 
*public-private key pair PK1/SK1, if can find a preimage to the 
*CGA1, I can extract from the preimage another public-private 
*key pair PK2/SK2 that yields the same CGA CGA1, and thus I can 
*impersonate that CGA CGA1 by signing messages with the 
*public-private key pair PK2/SK2.
*
*There's no need to break anything in the SEND specification, 
*neither the digital signature algorithm, or the hashes. I 
*simply break the hash function used for CGA generation.
*
*--julien
*
*On Wednesday 02 July 2008, Sheng Jiang wrote:
*> Hi, Julien,
*>
*> Your example is correct. However, it is misleading. You were talking 
*> about you have found a collisional public-private key pair. In that 
*> case, no matter how strong the hash algorithms are, you can 
*break the 
*> whole security system. Our assumption here is: based on a collision 
*> free public-private key pair, whether one hash algorithm with two 
*> results or two hash algorithms with two results are stronger. My 
*> choice is the latter.
*>
*> Best regards,
*>
*> Sheng JIANG, Ph.D.
*>
*> IP Research Department, Networking Research Department, Network 
*> Product Line, Huawei Technologies Co. Ltd.
*>
*>
*> *-----Original Message-----
*> *From: julien laganier [mailto:[email-masked]] On *Behalf 
*> Of Julien Laganier
*> *Sent: Wednesday, July 02, 2008 6:17 PM
*> *To: Sheng Jiang
*> *Cc: [email-masked]; [email-masked]
*> *Subject: Re: [CGA-EXT] Hash Agility in SEND (Was: new version *of 
*> "Send Hash Threat Analysis")
*> *
*> *Hi Sheng,
*> *
*> *If I can generate a public-private key pair that yields an 
**arbitrary 
*> CGA (attack against your A below), then I can *impersonate 
*that CGA's 
*> owner by simply signing with that *public-private key pair 
*-- no need 
*> to break the digital *signature algorithm (your B).
*> *
*> *--julien
*> *
*> *On Wednesday 02 July 2008, Sheng Jiang wrote:
*> *> 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-masked]
*> *> *[mailto:[email-masked]] On Behalf Of Julien 
*Laganier *> 
*> *Sent: Tuesday, July 01, 2008 10:24 PM *> *To: [email-masked]; 
*> [email-masked]
*> *> *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-masked]
*> *> *> https://www.ietf.org/mailman/listinfo/cga-ext
*> *> *
*> *> *
*> *> *
*> *> *_______________________________________________
*> *> *CGA-EXT mailing list
*> *> [email-masked]
*> *> *https://www.ietf.org/mailman/listinfo/cga-ext
*> *> *
*> *
*> *
*> *
*>
*>
*>
*> _______________________________________________
*> CGA-EXT mailing list
*> [email-masked]
*> https://www.ietf.org/mailman/listinfo/cga-ext
*
*
*

---

From: Julien Laganier <[email-masked]>
Date: Wed, 2 Jul 2008 15:28:48 +0200

Sheng,

It seems you agree using different hash functions for SEND and CGA 
doesn't improve security.

Using the same hash functions for SEND and CGA does provide the useful 
security feature that the hash function is encoded in the address (via 
RFC4982) and thus no bidding down attacks are possible.

Since using a Hash algorithm option in the SEND protocol does not 
provide any security feature and does not protect against bidding down 
attacks leading to use of a broken hash function in SEND, it does harm.

Thus it's my opinion that we shall specify that SEND use the same hash 
function than that of the CGA.

--julien

On Wednesday 02 July 2008, Sheng Jiang wrote:
> Hi, Julien,
>
> What you describe is exactly collisional public-private  key pair.
> You find another key pair that just happens to match the result from
> key pair 1. You break one of the two assumptions for hash function
> [rfc4270]. Yes, in your case, multiple hash functions does not help
> and "the system can't be stronger than the weakest of its
> components".
>
> However, even so, it does not means we should forbid or restrict the
> usage of multiple hash function. The second stronger hash function
> does not do any harm in your case and may help when we face other
> kind of threats.
>
> Best regards,
>
> Sheng JIANG, Ph.D.
>
> *I'm talking about a CGA hash function with broken pre-image
> resistance. *
> *> Your example is correct. However, it is misleading. You were
> talking *> about you have found a collisional public-private key
> pair. In that *> case, no matter how strong the hash algorithms are,
> you can *break the
> *> whole security system. Our assumption here is: based on a
> collision *> free public-private key pair, whether one hash algorithm
> with two *> results or two hash algorithms with two results are
> stronger. My *> choice is the latter.
> *>
> *> Best regards,
> *>
> *> Sheng JIANG, Ph.D.
> *>
> *> *From: julien laganier [mailto:[email-masked]] On
> *Behalf *> Of Julien Laganier
> *> *> However, we should also allow/support that they use different
> *> *> algorithms through we may not recommended it.
> *> *>
> *> 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,
> *> *> *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
> *> this case) with *> similar security *strength for both CGA and
> SEND. *> *> *
> *> we suggest the support for the *hash and *> *> algorithm agility
> in *> SeND.
> *> *> *>
> *> 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
> *> *solution *> here *> does not exist.  A new hash function option
> in *> SeND *message is *> a *> reasonable and the best solution *for
> the hash
> *> *> *>    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.
> *> *> *
> *> *> *

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 02 Jul 2008 18:45:00 -0400

Hi Julien,

> Has anybody an opinion on the topic?

I do :-). I agree with you conceptually, but there might be a point in 
time (near future) where SEND may be used without CGAs. And hence we 
cannot just state "use the same hash function as CGA". With this in 
mind, do you agree with us?

Cheers
Suresh

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 03 Jul 2008 10:33:56 +0800

Julien,

I can agree with you under the circumstance that SEND uses CGA. But SEND does not
depend on CGA. There are many scenarios the CGA option may unattended. Therefore,
the hash function and its description option in SEND must be INDEPENDENT from CGA
hash function. It may happen to be the same hash function with CGA hash function or
not.

Sheng

*-----Original Message-----
*From: julien laganier [mailto:[email-masked]] On 
*Behalf Of Julien Laganier
*Sent: Wednesday, July 02, 2008 9:29 PM
*To: Sheng Jiang
*Cc: [email-masked]; [email-masked]
*Subject: Re: [CGA-EXT] Hash Agility in SEND (Was: new version 
*of "Send Hash Threat Analysis")
*
*Sheng,
*
*It seems you agree using different hash functions for SEND and 
*CGA doesn't improve security.
*
*Using the same hash functions for SEND and CGA does provide 
*the useful security feature that the hash function is encoded 
*in the address (via
*RFC4982) and thus no bidding down attacks are possible.
*
*Since using a Hash algorithm option in the SEND protocol does 
*not provide any security feature and does not protect against 
*bidding down attacks leading to use of a broken hash function 
*in SEND, it does harm.
*
*Thus it's my opinion that we shall specify that SEND use the 
*same hash function than that of the CGA.
*
*--julien
*
*On Wednesday 02 July 2008, Sheng Jiang wrote:
*> Hi, Julien,
*>
*> What you describe is exactly collisional public-private  key pair.
*> You find another key pair that just happens to match the result from 
*> key pair 1. You break one of the two assumptions for hash function 
*> [rfc4270]. Yes, in your case, multiple hash functions does not help 
*> and "the system can't be stronger than the weakest of its 
*components".
*>
*> However, even so, it does not means we should forbid or restrict the 
*> usage of multiple hash function. The second stronger hash function 
*> does not do any harm in your case and may help when we face 
*other kind 
*> of threats.
*>
*> Best regards,
*>
*> Sheng JIANG, Ph.D.
*>
*> IP Research Department, Networking Research Department, Network 
*> Product Line, Huawei Technologies Co. Ltd.
*>
*>
*> *-----Original Message-----
*> *From: julien laganier [mailto:[email-masked]] On *Behalf 
*> Of Julien Laganier
*> *Sent: Wednesday, July 02, 2008 8:28 PM
*> *To: [email-masked]; Sheng Jiang
*> *Cc: [email-masked]
*> *Subject: Re: [CGA-EXT] Hash Agility in SEND (Was: new version *of 
*> "Send Hash Threat Analysis")
*> *
*> *Sheng,
*> *
*> *I am not talking about finding a collisional public-private *key 
*> pair, whatever that is.
*> *
*> *I'm talking about a CGA hash function with broken pre-image 
*> resistance. * *Given a CGA CGA1 generated (via the hash 
*function) from 
*> a *public-private key pair PK1/SK1, if can find a preimage to the 
*> *CGA1, I can extract from the preimage another public-private *key 
*> pair PK2/SK2 that yields the same CGA CGA1, and thus I can 
*> *impersonate that CGA CGA1 by signing messages with the 
*> *public-private key pair PK2/SK2.
*> *
*> *There's no need to break anything in the SEND 
*specification, *neither 
*> the digital signature algorithm, or the hashes. I *simply break the 
*> hash function used for CGA generation.
*> *
*> *--julien
*> *
*> *On Wednesday 02 July 2008, Sheng Jiang wrote:
*> *> Hi, Julien,
*> *>
*> *> Your example is correct. However, it is misleading. You were 
*> talking *> about you have found a collisional public-private 
*key pair. 
*> In that *> case, no matter how strong the hash algorithms 
*are, you can 
*> *break the *> whole security system. Our assumption here is: 
*based on 
*> a collision *> free public-private key pair, whether one hash 
*> algorithm with two *> results or two hash algorithms with 
*two results 
*> are stronger. My *> choice is the latter.
*> *>
*> *> Best regards,
*> *>
*> *> Sheng JIANG, Ph.D.
*> *>
*> *> IP Research Department, Networking Research Department, 
*Network *> 
*> Product Line, Huawei Technologies Co. Ltd.
*> *>
*> *>
*> *> *-----Original Message-----
*> *> *From: julien laganier [mailto:[email-masked]] On 
*> *Behalf *> Of Julien Laganier *> *Sent: Wednesday, July 02, 
*2008 6:17 
*> PM *> *To: Sheng Jiang *> *Cc: [email-masked]; 
*> [email-masked]
*> *> *Subject: Re: [CGA-EXT] Hash Agility in SEND (Was: new 
*version *of 
*> *> "Send Hash Threat Analysis") *> * *> *Hi Sheng, *> * *> *If I can 
*> generate a public-private key pair that yields an **arbitrary *> CGA 
*> (attack against your A below), then I can *impersonate *that 
*CGA's *> 
*> owner by simply signing with that *public-private key pair
*> *-- no need
*> *> to break the digital *signature algorithm (your B).
*> *> *
*> *> *--julien
*> *> *
*> *> *On Wednesday 02 July 2008, Sheng Jiang wrote:
*> *> *> 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-masked]
*> *> *> *[mailto:[email-masked]] On Behalf Of Julien 
**Laganier 
*> *> *> *Sent: Tuesday, July 01, 2008 10:24 PM *> *To: 
[email-masked]; 
*> *> [email-masked]
*> *> *> *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-masked]
*> *> *> *> https://www.ietf.org/mailman/listinfo/cga-ext
*> *> *> *
*> *> *> *
*> *> *> *
*> *> *> *_______________________________________________
*> *> *> *CGA-EXT mailing list
*> *> *> [email-masked]
*> *> *> *https://www.ietf.org/mailman/listinfo/cga-ext
*> *> *> *
*> *> *
*> *> *
*> *> *
*> *>
*> *>
*> *>
*> *> _______________________________________________
*> *> CGA-EXT mailing list
*> *> [email-masked]
*> *> https://www.ietf.org/mailman/listinfo/cga-ext
*> *
*> *
*> *
*
*
*

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 02 Jul 2008 14:49:46 +0800

Hi, Julien,

Best regards,

Sheng

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Jul 2008 11:19:15 +0200

Hi Suresh and Sheng,

On Thursday 03 July 2008, Sheng Jiang wrote:
>
> I can agree with you under the circumstance that SEND uses CGA. But
> SEND does not depend on CGA. There are many scenarios the CGA option
> may unattended. Therefore, the hash function and its description
> option in SEND must be INDEPENDENT from CGA hash function. It may
> happen to be the same hash function with CGA hash function or not.

On Thursday 03 July 2008, Suresh Krishnan wrote:
>
> I agree with you conceptually, but there might be a point in time
> (near future) where SEND may be used without CGAs. And hence 
> we cannot just state "use the same hash function as CGA". With this
> in mind, do you agree with us?

Two points here:

- the current SEND specification does depend on CGA, and CSI is not 
chartered to extend SEND to support use non-CGAs IP addresses.

- we do not necessarily need to use CGAs with SEND to rely on RFC4982 
hash algorithm types in SEND. It's possible to define another format of 
addresses (e.g. SNCGA - SEND Non-Cryptographically Generated Addresses) 
that has three bits reserved in the IID to encode RFC4982 SEC parameter 
encoding the hash algorithm to be used with SEND, while other bits in 
the IID are chosen freely.

--julien

On Wednesday 02 July 2008, Julien Laganier wrote:
> Using the same hash functions for SEND and CGA does provide the
> useful security feature that the hash function is encoded in the
> address (via RFC4982) and thus no bidding down attacks are possible.
>
> provide any security feature and does not protect against bidding
> down attacks leading to use of a broken hash function in SEND, it
> does harm.
>
> Thus it's my opinion that we shall specify that SEND use the same
> hash function than that of the CGA.
>
> --julien
>
> > You find another key pair that just happens to match the result
> > from key pair 1. You break one of the two assumptions for hash
> > function [rfc4270]. Yes, in your case, multiple hash functions does
> > not help and "the system can't be stronger than the weakest of its
> > components".
> >
> > However, even so, it does not means we should forbid or restrict
> > the usage of multiple hash function. The second stronger hash
> > function does not do any harm in your case and may help when we
> > face other kind of threats.
> >
> > Best regards,
> >
> > Sheng JIANG, Ph.D.
> >
> > pair. In that *> case, no matter how strong the hash algorithms
> > are, you can *break the
> > collision *> free public-private key pair, whether one hash
> > algorithm with two *> results or two hash algorithms with two
> > results are stronger. My *> choice is the latter.
> > *>
> > *> Best regards,
> > *>
> > *> Sheng JIANG, Ph.D.
> > *>
> > *> *Cc: [email-masked];
> > [email-masked] *> *Subject: Re:
> > [CGA-EXT] Hash Agility in SEND (Was: new version *of *> "Send Hash
> > Threat Analysis")
> > *> *
> > *> *Hi Sheng,
> > *> *
> > *> *> 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.
> > *> *>
> > 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,
> > *> 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,
> > *> *> function *>    option with something that can not be changed
> > at *> all, *> like *> [rfc4982] does for CGA - encoding the hash
> > *function *>
> > *> architecturally strange *> and it does not really *> increase
> > the *> security since the difficulty *> for attackers remain to *>
> > *break one
> > hash *> *> function. On the *other side, *> the use of two
> > different hash *> *algorithms *> makes attacker's life *> harder.
> > *> *> *>
> > 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
> > *> *> *> The new version of draft-kukec-csi-hash-threat is
> > submitted. *> *> *Comments
> > *> *> *> are welcome!
> > *> *> *>
> > *> *> *> This document analysis the use of hashes in SeND,
> > *possible *> *threats *> and *> the impact of recent attacks on
> > hash *functions used
> > *> 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

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 08 Jul 2008 10:18:00 +0800

Hi, Julien,

I still insist SEND hash algorithm should be independent from CGA hash algorithm.
There are some scenarios that CGA option is not necessary and SEND Signature is
needed. In these cases, define SEND hash algorithm should be the same with CGA hash
algorithm does not make sense. For example, according to RFC3971, "Router
Advertisement, and Redirect messages MUST contain the RSA Signature option", but CGA
option is not mandate.

One more point, actually there are two hash algorithms within SEND: the hash
algorithm of Key Hash and the hash algorithm of Digital Signature. The hash
algorithm of Digital Signature is bound to the Signature algorithm. So far,
RSASSA-PKCS1-v1_5 signature algorithm has only two hash algorithms: MD5 and SHA-1.
It means if CGA uses other hash algorithm, such as SHA-256, HA-KH may be able to
adopt the same hash algorithm; HA-DS is NOT able to adopt the same hash algorithm at
all.

Besides the above, different algorithms could be useful for future uses and testing
purposes. While our whole support for hash agility is future-oriented (current SEND
or CGA is not affected by the current attacks), we should take the future usage into
account.

Best regards,

Sheng JIANG, Ph.D.

*-----Original Message-----
*From: julien laganier [mailto:[email-masked]] On 
*Behalf Of Julien Laganier
*Sent: Thursday, July 03, 2008 5:19 PM
*To: [email-masked]; Sheng Jiang; Suresh Krishnan
*Cc: [email-masked]
*Subject: Re: [CGA-EXT] Hash Agility in SEND (Was: new version 
*of "Send Hash Threat Analysis")
*
*Hi Suresh and Sheng,
*
*On Thursday 03 July 2008, Sheng Jiang wrote:
*>
*> I can agree with you under the circumstance that SEND uses CGA. But 
*> SEND does not depend on CGA. There are many scenarios the CGA option 
*> may unattended. Therefore, the hash function and its description 
*> option in SEND must be INDEPENDENT from CGA hash function. It may 
*> happen to be the same hash function with CGA hash function or not.
*
*On Thursday 03 July 2008, Suresh Krishnan wrote:
*>
*> I agree with you conceptually, but there might be a point in time 
*> (near future) where SEND may be used without CGAs. And hence 
*we cannot 
*> just state "use the same hash function as CGA". With this in 
*mind, do 
*> you agree with us?
*
*Two points here:
*
*- the current SEND specification does depend on CGA, and CSI 
*is not chartered to extend SEND to support use non-CGAs IP addresses.
*
*- we do not necessarily need to use CGAs with SEND to rely on 
*RFC4982 hash algorithm types in SEND. It's possible to define 
*another format of addresses (e.g. SNCGA - SEND 
*Non-Cryptographically Generated Addresses) that has three bits 
*reserved in the IID to encode RFC4982 SEC parameter encoding 
*the hash algorithm to be used with SEND, while other bits in 
*the IID are chosen freely.
*
*--julien
*
*On Wednesday 02 July 2008, Julien Laganier wrote:
*> Sheng,
*>
*> It seems you agree using different hash functions for SEND and CGA 
*> doesn't improve security.
*>
*> Using the same hash functions for SEND and CGA does provide 
*the useful 
*> security feature that the hash function is encoded in the 
*address (via 
*> RFC4982) and thus no bidding down attacks are possible.
*>
*> Since using a Hash algorithm option in the SEND protocol does not 
*> provide any security feature and does not protect against 
*bidding down 
*> attacks leading to use of a broken hash function in SEND, it does 
*> harm.
*>
*> Thus it's my opinion that we shall specify that SEND use the 
*same hash 
*> function than that of the CGA.
*>
*> --julien
*>
*> On Wednesday 02 July 2008, Sheng Jiang wrote:
*> > Hi, Julien,
*> >
*> > What you describe is exactly collisional public-private  key pair.
*> > You find another key pair that just happens to match the 
*result from 
*> > key pair 1. You break one of the two assumptions for hash function 
*> > [rfc4270]. Yes, in your case, multiple hash functions does 
*not help 
*> > and "the system can't be stronger than the weakest of its 
*> > components".
*> >
*> > However, even so, it does not means we should forbid or 
*restrict the 
*> > usage of multiple hash function. The second stronger hash function 
*> > does not do any harm in your case and may help when we face other 
*> > kind of threats.
*> >
*> > Best regards,
*> >
*> > Sheng JIANG, Ph.D.
*> >
*> > IP Research Department, Networking Research Department, Network 
*> > Product Line, Huawei Technologies Co. Ltd.
*> >
*> >
*> > *-----Original Message-----
*> > *From: julien laganier [mailto:[email-masked]] 
*On *Behalf 
*> > Of Julien Laganier
*> > *Sent: Wednesday, July 02, 2008 8:28 PM
*> > *To: [email-masked]; Sheng Jiang
*> > *Cc: [email-masked]
*> > *Subject: Re: [CGA-EXT] Hash Agility in SEND (Was: new version *of 
*> > "Send Hash Threat Analysis")
*> > *
*> > *Sheng,
*> > *
*> > *I am not talking about finding a collisional public-private *key 
*> > pair, whatever that is.
*> > *
*> > *I'm talking about a CGA hash function with broken pre-image 
*> > resistance. * *Given a CGA CGA1 generated (via the hash function) 
*> > from a *public-private key pair PK1/SK1, if can find a preimage to 
*> > the *CGA1, I can extract from the preimage another public-private 
*> > *key pair PK2/SK2 that yields the same CGA CGA1, and thus I can 
*> > *impersonate that CGA CGA1 by signing messages with the 
*> > *public-private key pair PK2/SK2.
*> > *
*> > *There's no need to break anything in the SEND specification, 
*> > *neither the digital signature algorithm, or the hashes. I *simply 
*> > break the hash function used for CGA generation.
*> > *
*> > *--julien
*> > *
*> > *On Wednesday 02 July 2008, Sheng Jiang wrote:
*> > *> Hi, Julien,
*> > *>
*> > *> Your example is correct. However, it is misleading. You were 
*> > talking *> about you have found a collisional public-private key 
*> > pair. In that *> case, no matter how strong the hash 
*algorithms are, 
*> > you can *break the *> whole security system. Our 
*assumption here is: 
*> > based on a collision *> free public-private key pair, whether one 
*> > hash algorithm with two *> results or two hash algorithms with two 
*> > results are stronger. My *> choice is the latter.
*> > *>
*> > *> Best regards,
*> > *>
*> > *> Sheng JIANG, Ph.D.
*> > *>
*> > *> IP Research Department, Networking Research Department, Network 
*> > *> Product Line, Huawei Technologies Co. Ltd.
*> > *>
*> > *>
*> > *> *-----Original Message-----
*> > *> *From: julien laganier [mailto:[email-masked]] On 
*> > *Behalf *> Of Julien Laganier *> *Sent: Wednesday, July 02, 2008 
*> > 6:17 PM *> *To: Sheng Jiang *> *Cc: [email-masked]; 
*> > [email-masked] *> *Subject: Re:
*> > [CGA-EXT] Hash Agility in SEND (Was: new version *of *> "Send Hash 
*> > Threat Analysis") *> * *> *Hi Sheng, *> * *> *If I can generate a 
*> > public-private key pair that yields an **arbitrary *> CGA (attack 
*> > against your A below), then I can *impersonate *that CGA's 
**> owner 
*> > by simply signing with that *public-private key pair
*> > *-- no need
*> > *> to break the digital *signature algorithm (your B).
*> > *> *
*> > *> *--julien
*> > *> *
*> > *> *On Wednesday 02 July 2008, Sheng Jiang wrote:
*> > *> *> 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-masked] *> *> 
*> > *[mailto:[email-masked]] On Behalf Of Julien 
**Laganier *> 
*> > *> *Sent: Tuesday, July 01, 2008 10:24 PM *> *To: 
[email-masked]; 
*> > *> [email-masked]
*> > *> *> *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-masked]
*> > *> *> *> https://www.ietf.org/mailman/listinfo/cga-ext
*> > *> *> *
*> > *> *> *
*> > *> *> *
*> > *> *> *_______________________________________________
*> > *> *> *CGA-EXT mailing list
*> > *> *> [email-masked]
*> > *> *> *https://www.ietf.org/mailman/listinfo/cga-ext
*> > *> *> *
*> > *> *
*> > *> *
*> > *> *
*> > *>
*> > *>
*> > *>
*> > *> _______________________________________________
*> > *> CGA-EXT mailing list
*> > *> [email-masked]
*> > *> https://www.ietf.org/mailman/listinfo/cga-ext
*> > *
*> > *
*> > *
*>
*> _______________________________________________
*> CGA-EXT mailing list
*> [email-masked]
*> https://www.ietf.org/mailman/listinfo/cga-ext
*
*
*

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 8 Jul 2008 15:38:43 +0200

Hi,

2008/7/1 Ana Kukec <[email-masked]>:
> The new version of draft-kukec-csi-hash-threat is submitted. Comments are
> welcome!
>

Please see my inline comments.

>                       SeND Hash Threat Analysis
>                     draft-kukec-csi-hash-threat-02
>

[snip]

>
> 1.  Introduction
>
>   SEND [rfc3971] uses the SHA-1 hash algorithm to generate the contents
>   of the Key Hash and the Digital Signature fields of the RSA
>   signature.  It also uses a hash algorithm (SHA-1,MD5 etc.) in the
>   PKIX certificates [rfc3280] used for router authorization.  Recently
>   there have been demonstrated attacks against the collision free
>   property of such hash functions [sha1-coll].  There have also been
>   attacks on the PKIX X.509 certificates that use the MD5 hash
>   algorithm [x509-coll] that allow an attacker to generate two
>   different certificates with different distinguished names and
>   different public keys that contain identical signatures.  This
>   document analyzes the effects of such attacks on the SEND protocol
>   and proposes changes to make it resistant to such attacks.
>
>

IMHO, the reference/text to the attacks on hash functions used for the
certificate generation is out of scope because this issue is/should be
studied in the PKIX WG and is not strictly linked to SEND: there is
the same issue when certs are used with other security services (e.g.
IPsec).

[snip]

>
> 3.1.  Attacks against CGAs in stateless autoconfiguration
>
>   Hash functions are used in the stateless autoconfiguration process
>   that is based on CGAs.  Impacts of collision attacks on current uses
>   of CGAs are analyzed in the update of CGA specification [rfc4982],
>   which also enables CGAs to support hash agility.  CGAs provide proof-
>   of-ownership of the private key corresponding to the public key used
>   to generate CGA, and they don't deal with the non-repudiation
>   feature, while collision attacks are mainly about affecting non-
>   repudiation feature.  While SeND is CGA based protocol, we are sure
>   that the node that signs the message is the same as the node that
>   creates the message and associated hash.  So, as [rfc4982] points out
>   CGA based protocols, including SeND, are not affected by the recent
>   collision attacks.
>

IMHO, it would be better to speak about "CGA generation" than "CGAs in
stateless autoconfiguration" because:
- The hash function is used during the CGA generation (i.e. RFC 3972)
- CGA may be used with stateful mechanisms (e.g. IKEv2)

> 3.2.  Attacks against PKIX certificates in ADD process

Please see my previous comment about my feeling that attacks against
hash functions in certs are out of scope.

[snip]

> 3.3.  Attacks against Digital Signature in RSA Signature option
>
>   Digital signature in RSA Signature option is produced as the SHA-1
>   hash of IPv6 addresses, ICMPv6 header, ND message and other fields
>   like Message Type Tag and ND options [rfc3971], and is signed with
>   the sender's private key, which corresponds to the public key from
>   the CGA parameters structure and is authorized usually through CGAs.
>   The possible attack on such explicit digital signature is typical
>   non-repudiation attack.  Attacker could generate a false message with
>   the same hash and sign that false hashed message with authorized
>   private key.  However, the problem for the attacker is that they are
>   very hard to predict the useful input data.  It minimizes the
>   possibility for a real-world collision attack and the fact that in
>   order to perform a succesful real-world attack he can not change a

s/succesful/successful

[snip]

> 3.4.  Attacks against Key Hash in RSA Signature option
>
>   Key Hash field in the RSA Signature option is a SHA-1 hash of the
>   public key from the CGA parameters structure in the CGA option of
>   SeND message.  Key Hash field is a typical example of data
>   fingerprinting, which is potentially dangerous because input field is
>   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

s/succesful/successful

[snip]

> 4.  Support for the hash agility in SeND

[snip]

>   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.

s/possibilty/possibility

[snip]

> 4.1.  Hash algorithm option
>
>   In order to provide hash algorithm agility, each SeND implemenation

s/implemenation/implementation

[snip]

>   Hash Algorithm for Key Hash field (HA-KH)
>
>      Hash algorithm used for producing the Key Hash field in the RSA
>      Signature option.  SEND [rfc3971] uses SHA-a.  In order to provide

s/SHA-a/SHA-1

[snip]

>
>   Reserved
>
>      Field reserved for future uses.  The value MUST be initialized to
>      zero by the sender, and MUST be ignored by the recepient.

s/recepient/recipient

[snip]

>
> 5.  Security Considerations
>
>   This document analyzes the impact of hash attacks in SeND and offeres

s/offeres/offers

[snip]

Best regards.

JMC.