The Secure Neighbor Discovery (SEND) Hash Threat Analysis
draft-ietf-csi-hash-threat-12
Note: This ballot was opened for revision 12 and is now closed.
Pasi Eronen Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2010-03-10)
Unknown
Based on the SecDir reviews by Julien Laganier and Paul Hoffman, it seems this document needs a major rewrite (and one of the authors seems to agree): http://www.ietf.org/mail-archive/web/secdir/current/msg01540.html http://www.ietf.org/mail-archive/web/secdir/current/msg01537.html http://www.ietf.org/mail-archive/web/secdir/current/msg01536.html
Jari Arkko Former IESG member
Yes
Yes
(2010-03-10)
Unknown
Well written document, thanks. I had a few comments though: Term ADD not defined. > Theoretically this attack could harm > SEND, but in real-world situation is to achieve it. ... is hard to achieve it? > From the security > point of view, at the moment, this solution is more reasonable > then defining different hash algorithm for each hash. ... than defining ...? > The computation of the Digital Signature field is described > [rfc3971]. ... described in? > The computation of the Digital Signature field is described > [rfc3971]. It is produced as the SHA-1 hash over the IPv6 addresses, > the ICMPv6 header, the ND message and other fields, e.g. the Message > Type Tag and ND options, and signed with the sender's private key. > Private key corresponds to the public key in the CGA parameters > structure. It is usually authorized through CGAs. The signature field simply binds the private and public key together. It works for both CGA and certificate-based SEND. Indeed, routers use the certificate-based mode in practice exclusively. > o The third possible solution is to encode the algorithm in the CGA. > This would reduce the strength of the CGA and make it vulnerable > to brute force attacks. ... and also bidding down attacks, if I'm not mistaken. If the hash algorithm is part of the CGA parameters structure, simply choose a hash algorithm that is completely broken and find a value that matches the victim's address AND uses the bad algorithm within the CGA parameters structure. > o Possible solution is also the hybrid solution which would require > the hash algorithm to be the same as CGA, if CGA option is > present, and to use the Hash agility option if the CGA option is > not present. In such way, SEND is not bound exclusively to CGA. Isn't there also a hybrid solution where the hash is in the address bits for CGA based addresses, and all certificate-related hash operations are in the certificate? But maybe I'm missing something obvious. > o None of the previous solutions supports the negotiation of the > hash function. One of possible solutions is the negotiation > approach for the SEND hash agility based on the Supported > Signature Algorithm option described in [sig-agility]. I would have noted the bidding-down issue already here (as you do for some other alternatives). > The negotiation approach for the hash agility in SEND based on the > 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. Perhaps some mitigation can be offered, but policy really isn't a solution to the bidding down problem. Anyway, the security consideration section kind of ends without making a conclusion. My conclusion -- perhaps not surprisingly! -- is that the RFC 4982 approach seems to be valid approach. And this is what current standards track specifications say. Do the authors of this document want to change that situation, or not? It would be useful to draw a conclusion.
Ralph Droms Former IESG member
(was Discuss, Yes)
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2010-03-11)
Unknown
There are a couple of minor warnings reported by idnits, and it would be good to fix these if a new revision of the document is being prepared. --- Section 3.2 s/concer/concern/ --- Section 3.2 Even though real-world scenarios make SEND immune to recent hash attacks introduced through X.509 certificates, theoretically they are possible. This feels like a contradiction or is confusing. If the attacks are possible, do we need to worry about them? If SEND is immune, we do not need to worry even if the attacks are easy and possible. If we *do* need to worry about them, then obviously SEND isn't immune.
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
(2010-03-11)
Unknown
There are a significant number of typos in the document that detract from its readability. Abstract The first use of the acronym ‘SEND’ should be spelled out: /SEND/SEcure Neighbor Discovery (SEND)/ /Current SEND specification/The current SEND specification/ /for the hash algorithm agility/for hash algorithm agility/ /to provide analysis/to provide an analysis/ Section 1 /Cryptographically Generated Addresses (CGA)/Cryptographically Generated Addresses (CGAs)/ /Authorizaton Delegation Discovery/Authorization Delegation Discovery/ /variaty/variety/ /First hash attacks/The initial hash attacks/ /significantlly/significantly/ /Depending on the way how the Internet protocol uses the hash algorithm, Internet protocol can be affected/Depending on how the SEND protocol relies on the hash algorithm, Internet Protocol (IPv6) operation can be affected/ Section 3 /Up to date, all demonstrated attacks are attacks against a collision-free property./To date, all demonstrated attacks are attacks against the collision-free property./ /underlaying hash function/underlying hash function/ /no matter of the hash algorithm weaknesses/no matter the weaknesses of the hash algorithm/ /fingerprints/or fingerprints/ /on SEND by the cases of use/on SEND by the use cases/ /support the hash agility/support hash agility/ Section 3.2 /Router sends to a host/A router sends to a host/ /Potential problem for the attacker/The potential problem for the attacker/ /allowe/allow/ /does not allowe to provide/does not allow/ /biggest concer are/the biggest concerns are/ /such human-readble data such would prevent attacks/such human-readable data would prevent attacks / Section 3.3 /is described [rfc3971]/is described in [rfc3971]/ /Private key corresponds/The private key corresponds/ /The Digital Signature field the example of the non-repudiation digital singature/The Digital Signature field is an example of a non-repudiation digital signature/ /Possible attacks on such explicit digital signature/A possible attack on the Digital Signature field/ /He underlays one of the messages to be signed/The attacker signs one of the messages/ /but in real-world situation is to achieve it/but in real-world situations it seems difficult to achieve/ Section 3.4 /the integrity protection/integrity protection/ /the collision attacks/collision attacks/ /a non human-readable data/non human-readable data/ Section 4 /Previous section/The previous section/ /SEND context prevents/The SEND context prevents/ /The most effective and secure would be/The most effective and secure solution would be/ Section 6 /offeres/offers/ /by providing solution for the hash agility support/by providing a solution to support hash agility/
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2010-03-09)
Unknown
COMMENT: AD, this document needs a ballot issued. List of editorial nits sent directly to the authors.
Ron Bonica Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2010-03-10)
Unknown
Assuming Informational RFC. The Gen-ART Review by Pete McCann on 2010-03-09 included some editorial comments. Please consider them if an update to this document is needed for any reason.
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
(2010-03-11)
Unknown
Please review the references to RFC 5709; some of these probably should be included as well.