Hello Julien,
Thank you for reviewing our document.
Comments below:
On Fri, 21 May 2010, 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.
OK.
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.)
It appears, from your comment and Jean-Michel's review that this part of
the document (section 2.1.1 and 2.1.2) is currently quite confusing.
Section 2.1.1 is about what we might expect the nodes to do. Not about
what we actually do here in this document. It is just a classification
work so we can state what can be done, with some drawbacks, and what we
actually propose here in this document (H1, H2, R1, R2 and R4 type nodes).
I am currently reworking these sections so, hopefully, the text will be
less confusing in the future.
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.
I somewhat agree with you. Too much negotiation will be a burden on the
nodes and can involve security issues.
However, I would like to say, that: for routers, the multicast scenario
seems fairly easy. A router can generate two CGA addresses, one based
on RSA, the other one on ECC and send regularly messages signed with
both algorithm. Both addresses are viewed as separate entities and it
only involves the router sending twice as much Router Advertisement
messages.
Also, we are currently shifting the usage of the Supported Signature Option.
It was previously an option to perform negotiation. Now, it is more
focused on diagnostic (i.e. it helps an administrator of a node to
understand why it fails to communicate with neighboring nodes).
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.
I think we agree on the fall-back mechanism.
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.
I agree with this point, but I will add a little nuance here: a RSA node
could sign using RSA/SHA-1 or RSA/SHA-256.
- 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.
I do not see why I should threat a message as insecure if I can verify
the signature it is protected with. This has nothing to do with the
algorithm I can sign with (which are linked to the CGA or the
Public Key that is pointed by the Key Hash field of the XXX Signature
Option). I think it just depends on the capabilities of a node (crypto
library, CPU power, etc).
Thanks for your really appreciated inputs.
Regards,
Tony
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
