I have reviewed "Signature Algorithm Agility in the Secure Neighbor Discovery Protocol" and have the following comments. I am not going to comment on the specifics of the protocol extension because I disagree with the overall approach.
I do not think it's reasonable for an extension to a relatively simple security protocol (SEND) to introduces 4 different types of hosts, 4 different type of routers, some of which are said to be "hard to secure" and recommended to avoid, while another who rely on unspecified redirection mechanisms between CGAs, and some combinations of these hosts and routers leading to undetectable failure modes (at least from what I understood.) I think most of the complexity and drawbacks of the proposal stems from the requirement that signature agile nodes be able to negotiate a common signature algorithm, which I think is unreasonable when the protocol employs multicast/broadcast (thus reaches multiples nodes which might support different algorithms) and when the algorithm is somehow "hardcoded" in the CG address used by a node thus adding an additional level of constraint. In this situation, the only reasonable chance for ND to operate securely is that most of the nodes on a link support the same signature algorithm (e.g., ECDSA), other minority nodes falling back to mixed mode. In light of this, I recommend a simpler approach to be taken based on two simple requirements: - it shall be possible for a node supporting the signature agility extension to use a public key algorithm other than RSA for generation/verification of a signature/CGA. - an ND message sent from a CGA based on a public key algorithm that is not supported by the receiver, and signed using that same algorithm shall be treated as insecure by the receiver as per RFC3971, i.e., it shall not be discarded. --julien _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
