Subject: [CGA-EXT] Review of draft-cheneau-csi-send-sig-agility-01

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 21 May 2010 10:10:27 -0700

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

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 21 May 2010 12:47:15 -0700

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.
> 
> - 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-masked]
> https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Tony Cheneau <[email-masked]>
Date: Mon, 24 May 2010 15:27:39 +0200 (CEST)

Hello Julien,

Thank you for reviewing our document.

Comments below:

> 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…
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 "…
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 w…
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…
I think we agree on the fall-back mechanism.

> - 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 RFC39…
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

---

From: Tony Cheneau <[email-masked]>
Date: Mon, 24 May 2010 15:30:11 +0200 (CEST)

Hello Julien,

[...]
> - 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.
I would need several clarifications on this sentence:
- I do not see why we should define a NewCGA option. RFC 3971 defines a
   CGA Option that carries a CGA PDS (defined in RFC 3972) that is
   agnostic of the Public Key type. As long as the Public Key can be
   formatted as a DER-encoded ASN.1 structure of type
   SubjectPublicKeyInfo, this is not a problem. Did I miss something ? 
- concerning the NewSignature, do you think we should define a new one
   per Signature Algorithm ? So there will be one for RSA (already
   exists), one for ECDSA, as long as there is free value on the "IPv6
   Neighbor Discovery Option Formats" registry. Or do you think there is
   actually some value in our solution that defines an "Universal"
   Signature option that indicates the type of Digital Signature it
   carries.
   Since there is already a reserved field in the RSA Signature Option, I
   would not see why we could not use this field to do just that. Legacy
   nodes will try to process the option and fail when it is not RSA.
   Signature Agility enabled nodes will just do fine. What is you opinion
   on this ?

> - specify NewSignature and NewCGA receiver processing such that a node that doesn't support said algorithm treats the message as unsecured.

Thanks (again) for your comments.

Regards,
 	Tony

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 24 May 2010 10:14:13 -0700

Hello Tony,

[ cutting through ] 

Tony Cheneau wrote:
> > - 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
> the signature it is protected with. 

If you can verify the signature you support the algorithm. If you cannot verify the signature you do not support the algorithm. This is orthogonal to your choice of algorithm to generate a CGA.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 24 May 2010 10:22:04 -0700

Tony Cheneau wrote:
> > - 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.
>

If the public key algorithm in use is signaled elsewhere (e.g. via an algorithm field in the NewSignature option) then it seems that current CGA option would be enough.

>    per Signature Algorithm ? 

No. We should define a NewSignature option with a field encoding the signature algorithm. (Seems that's what you call "Universal" as below.)

>    So there will be one for RSA (already
>    Neighbor Discovery Option Formats" registry. Or do you think there
>    is actually some value in our solution that defines an "Universal"
>    Since there is already a reserved field in the RSA Signature Option,
>    I would not see why we could not use this field to do just that.
>    Legacy nodes will try to process the option and fail when it is not RSA.
>    Signature Agility enabled nodes will just do fine. What is you
>    opinion on this ?

--julien