Someone pointed out that my previous message (below) listed the "simple requirements" but omitted a description of a "simpler approach" that I recommended we follow. That was actually intentional -- I thought a simpler approach would easily be derived from simple requirements.
FWIW - a strawman that seems to fulfill simpler requirements would be: - define NewSignature and NewCGA options that include the algorithm in use and are used in place of CGA and RSA Signature options when the algorithm in use is not RSA. - NewSignature and NewCGA options will be ignored by legacy nodes (i.e., conforming to RFC 3971) and thus messages carrying them will be treated as unsecured by these nodes. - specify NewSignature and NewCGA receiver processing such that a node that doesn't support said algorithm treats the message as unsecured. --julien Laganier, Julien wrote: > > 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 _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
