Re: [CGA-EXT] WGLC for draft-ietf-csi-hash-threat-05.txt

[Jean-Michel Combes <[e-mail]>]

Hi,

here are my comments regarding this draft:

                       SeND Hash Threat Analysis

<JMC>
To be compliant with RFC 3971 terminology:
s/SeND/SEND
<JMC>

   This document analysis the use of hashes in SeND, possible threats

<JMC>
s/SeND/SEND
<JMC>

   and the impact of recent attacks on hash functions used by SeND.

<JMC>
s/SeND/SEND
<JMC>

   Current SeND specification [rfc3971] uses the SHA-1 [sha-1] hash

<JMC>
s/SeND/SEND
<JMC>

   algorithm and PKIX certificates [rfc5280] and does not provide

<JMC>
To cover at the same time PKI (i.e. pkix WG) certificates, actually
used for SEND, and RPKI (i.e. sidr WG) certificates, used in the next
version of SEND, maybe:
s/PKIX certificates/X.509 certificates
<JMC>

   support for the hash algorithm agility.  The purpose of the document
   is to provide analysis of possible hash threats and to decide how to
   encode the hash agility support in SeND.

<JMC>
s/SeND/SEND
<JMC>


1.  Introduction

   SEND [rfc3971] uses the SHA-1 hash algorithm to generate the contents
   of the Key Hash field and the Digital Signature field of the RSA
   Signature option.  It also uses a hash algorithm (SHA-1, MD5, etc.)

<JMC>
On one side, there is no text on use of SHA-1 to generate a CGA and,
OTOH, section 2.1 explains the analysis on the CGA generation. Maybe:
s/SEND [rfc3971] uses the SHA-1 hash algorithm to generate the
contents of the Key Hash field and the Digital Signature field of the
RSA Signature option./Secure Neighbor Discovery (SEND) [rfc3971] uses
the SHA-1 hash algorithm to generate Cryptographically Generated
Addresses (CGA) [rfc3972], the contents of the Key Hash field and the
Digital Signature field of the RSA Signature option.
<JMC>

   in the PKIX certificates [rfc5280] used for the router authorization

<JMC>
Same comment as above.
To cover at the same time PKI (i.e. pkix WG) certificates, actually
used for SEND, and RPKI (i.e. sidr WG) certificates, used in the next
version of SEND, maybe:
s/PKIX certificates/X.509 certificates
<JMC>

   in the ADD process.  Recently there have been demonstrated attacks
   against the collision free property of such hash functions
   [sha1-coll], and attacks against the PKIX X.509 certificates that use

<JMC>
Same comment as above.
To cover at the same time PKI (i.e. pkix WG) certificates, actually
used for SEND, and RPKI (i.e. sidr WG) certificates, used in the next
version of SEND, maybe:
s/PKIX X.509 certificates/X.509 certificates
<JMC>

   the MD5 hash algorithm [x509-coll] This document analyzes the effects
   of those attacks and other possible hash attacks on the SEND
   protocol.  The document proposes changes to make it resistant to such
   attacks.

2.  Impact of collision attacks on SeND

<JMC>
s/SeND/SEND
<JMC>

   Due to the hash attacks demonstrated on the aforesaid hash algorithms
   a study was performed to assess the threat of these attacks on the
   cryptographic hash usage in internet protocols [rfc4270].  This
   document analyzes the hash usage in SEND following the approach
   recommended by [rfc4270] and [new-hashes].

<JMC>
Maybe:
s/This document analyzes the hash usage in SEND following the approach
recommended by [rfc4270] and [new-hashes]./This document analyzes the
hash usage in SEND following the recommended approach
[rfc4270][new-hashes].
<JMC>

   The basic cryptographic properties of a hash function are that it is
   both one-way and collision free.  There are two attacks against the
   one-way property, the first-preimage attack and the second-preimage
   attack.  In the first-preimage attack, given a knowledge of a
   particular value hash(m), an attacker finds an input message m' such
   that hash(m') yields hash(m).  The second-preimage attack deals with

<JMC>
IMHO, for someone not familiar with cryptography, the use of "m" in
hash(m) may be confusing. Maybe:
s/In the first-preimage attack, given a knowledge of a particular
value hash(m), an attacker finds an input message m' such that
hash(m') yields hash(m)./In the first-preimage attack, given a
knowledge of a particular Hash value h, an attacker finds an input
message m such that yields Hash(m)=h.
<JMC>

   the fixed messages.  Given a knowledge of a fixed value m used as the
   input message to the hash function, an attacker finds a different
   value m' that yields hash(m)=hash(m').  Supposing that the hash

<JMC>
Just for the mathematical logic, maybe:
s/Given a knowledge of a fixed value m used as the input message to
the Hash function, an attacker finds a different value m' that yields
hash(m)=hash(m')./Given a knowledge of a fixed value m used as the
input message to the Hash function, an attacker finds a different
value m' that yields Hash(m')=Hash(m).
<JMC>

   function produces an n-bit long output, since each output is equally
   likely, an attack takes an order of 2^n operations to be successful.
   Due to the birthday attack, if the hash function is supplied with a
   random input, it returns one of the k equally-likely values, and the
   number of operations can be reduced to the number of 1.2*2^(n/2)
   operations.  However, attacks against the one-way property are not
   feasible yet [rfc4270].  Up to date, all demonstrated attacks are
   attacks against a collision-free property, in which an attacker
   produces two different messages m and m' such that hash(m)=hash(m').
   The rest of the document deals with the collision attacks.

<JMC>
As there is text in section 2.1, 2.4 about preimage attack, maybe:
s/The rest of the document deals with the collision attacks./The rest
of the document mainly deals with the collision attacks.
<JMC>

   We will analyze the impact of hash attacks on SeND case by case in

<JMC>
s/SeND/SEND
<JMC>

   this section.  Through our analysis, we also discuss whether we
   should support the hash agility in SeND.

<JMC>
s/SeND/SEND
<JMC>

2.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 the CGA specification
   [rfc4982], which also enables CGAs to support the hash agility.  CGAs
   provide the proof-of-ownership of the private key corresponding to
   the public key used to generate the CGA.  CGAs do not deal with the

<JMC>
"CGAs provide the proof-of-ownership of the private key corresponding
to the public key used to generate the CGA."
IMHO, this sentence is unclear. What do you mean by "CGAs"? Because,
AFAIK, only the RSA Signature Option (which is not a part of CGA
specification, i.e. RFC 3972) provides the proof-of-ownership of the
generated CGA: the public key used to generate the CGA is really owned
by the sender because this last one has correctly signed the ND
message and so he owns the private key associated to the public key.
Or did I miss something?
<JMC>

   non-repudiation feature, while collision attacks are mainly about
   affecting the non-repudiation feature, i.e. in the collision attack
   against the CGA both of the CGA Parameters sets are choosen by an
   attacker, which is not useful in the real-world scenarios.

<JMC>
"which is not useful in the real-world scenarios"
Out of curiosity, may you explain to me why you have such a conclusion?
<JMC>

   Therefore, as [rfc4982] points out CGA based protocols, including
   SeND, are not affected by the recent collision attacks.  Regarding

<JMC>
s/SeND/SEND
<JMC>

   the pre-image attacks, if pre-image attacks were feasible, an
   attacker would manage to find the new CGA Parameters based on the
   associated, victim's CGA, and produce the Key Hash field and the
   Digital Signature field afterwards using the new public key.  Since
   the strength of all hashes in SEND depends on the strength of the
   CGA, the pre-image attack is potentially dangerous, but it is not yet
   feasible.

<JMC>
s/pre-image/preimage
<JMC>

2.2.  Attacks against PKIX certificates in ADD process

<JMC>
s/PKIX certificates/X.509 certificates
<JMC>

   The second use of hash functions is for the router authorization in
   the ADD process.  Router sends to a host a certification path, which
   is a path between a router and the hosts's trust anchor, consisting
   of PKIX certificates.  Researchers demonstrated attacks against PKIX

<JMC>
s/hosts's/host's
s/PKIX certificates/X.509 certificates
<JMC>

   certificates with MD5 signature, in 2005 [new-hashes] and in 2007
   [x509-coll].  In 2005 were constructed the original and the false
   certificate that had the same identity data and the same digital
   signature, but different public keys [new-hashes].  The problem for
   the attacker is that two certificates with the same identity are not
   actually useful in real-world scenarios, because the Certification
   Authority is not allowed to provide such two certificates.  In

<JMC>
"because the Certification Authority is not allowed to provide such
two certificates."
Warning: AFAIK, there are methods, today, to get and to use such a
certificate from a CA (e.g. use of the "wildcard" or "null prefix"
method in the CN). That's already be done for SSL.
<JMC>

   addition, 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.  In 2007 were demonstrated certificates which differ in
   the identity data and in the public key, but still result in the same
   signature value.  In such attack, even if an attacker produced such
   two certificates in order to claim that he was someone else, he still
   needs to predict the content of all fields appearing before the
   public key, e.g. the serial number and validity periods.  Although a
   relying party cannot verify the content of these fields (each
   certificate by itself is unsuspicious), the Certification Authority
   keeps track of those fields and it can reveal the false certificate
   during the fraud analysis.  Regarding certificates in SeND,

<JMC>
s/SeND/SEND
<JMC>

   potentially dangerous are attacks against the X.509 certificate
   extensions.  For example, an attack against the IP address extension
   would enable the router to advertize the changed IP prefix range,
   although, not broader than the prefix range of the parent certificate
   in the ADD chain.

   The public-private key pair associated to the Router Authorization
   Certificate in the ADD process is used both for the CGA generation
   and for the message signing.  Since in the future CGAs might be used

<JMC>
"both for the CGA generation and for the message signing."
I assume you mean when the router uses also CGA Option. Correct?
<JMC>

   only with certificates, attacks against certificates are even more
   dangerous.  Generally, the most dangerous are attacks against middle-
   certificates in the certification path, where for the cost of the one
   false certificate, an attacker launches an attack on multiple
   routers.  Regarding the attacks against certificates in SEND, the
   only attack that SEND is not suspectable to, is an attack against the
   Trust Anchor's certificate because it is not exchanged in SeND

<JMC>
s/SeND/SEND
<JMC>

   messages, i.e. it is not the part of the certification path in the
   ADD process.



2.4.  Attacks against the Key Hash field in the RSA Signature option

   The Key Hash field is a SHA-1 hash of the public key from the CGA
   Parameters structure in the CGA option.  The pre-image attack against

<JMC>
s/pre-image/preimage
<JMC>

   the Key Hash field is potentially dangerous, as in the case of all
   other hashes in SEND, because the Key Hash field contains a non
   human-readable data.  However the Key Hash field is not suspectable
   to the collision attack, since in the collision attack an attacker
   itself chooses both keys, k and k', where hash(k) = hash(k').  The
   reason for the former is that the associated public key is already
   authorized through the use of CGAs, and possibly the certification
   path in the ADD process.



3.  Support for the hash agility in SeND

<JMC>
s/SeND/SEND
<JMC>

   While all of analyzed hash functions in SeND are theoretically

<JMC>
s/SeND/SEND
<JMC>

   affected by hash attacks, these attacks indicate the possibility of
   future real-world attacks.  In order to increase the future security
   of SeND, the following possible approaches can be used.

<JMC>
s/SeND/SEND
<JMC>

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

<JMC>
s/possibilty/possibility
s/SeND/SEND
<JMC>

      We could decide to use by default the same hash function in SeND

<JMC>
s/SeND/SEND
<JMC>

      as in CGA.  The security of all hashes in SeND depends on CGA, ie.

<JMC>
s/SeND/SEND
<JMC>

      if an attacker could break CGA, all other hashes are automatically
      broken.  From the security point of view, at the moment, this
      solution is more reasonable then defining different hash algorithm
      for each hash.  Additionally, if using the hash algorithm from the
      CGA, no bidding down attacks are possible.  On the other hand,
      this solution introduces the limition for SEND to be used

<JMC>
s/limition/limitation
<JMC>

      exclusively with CGAs.

   o  Another solution is to incorporate the Hash algorithm option into
      the SeND message.  However, if the algorithm is defined in the

<JMC>
s/SeND/SEND
<JMC>

      Hash algorithm option in the SeND message, it is vulnerable to the
      bidding down attack.

<JMC>
s/SeND/SEND
<JMC>

4.  Security Considerations

   This document analyzes the impact of hash attacks in SeND and offeres

<JMC>
s/SeND/SEND
s/offeres/offers
<JMC>

   a higher security level for SeND by providing solution for the hash

<JMC>
s/SeND/SEND
<JMC>

   agility support.

   The negotiation approach for the hash agility in SeND based on the

<JMC>
s/SeND/SEND
<JMC>

   Supported Signature Algorithms option is vulnerable to bidding-down
   attacks, which is usual in the case of any negotiation approach.
   This issue can be mitigated with the appropriate local policies.





Hope that helps.

Best regards.

JMC.

2010/1/22 marcelo bagnulo braun <[e-mail]>es>:
> Hi,
>
> This is WGLC for draft-ietf-csi-hash-threat-05.txt.
> Please read the document and provide comments. The WGLC will close on the
> 8th of february.
>
> the draft can be found at:
>
> http://tools.ietf.org/id/draft-ietf-csi-hash-threat-05.txt
>
> Regards, marcelo
>
> _______________________________________________
> CGA-EXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cga-ext
>