Subject: [CGA-EXT] about draft-cheneau-cga-pk-agility-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 11 Mar 2009 12:29:00 +0100

Hi,

I have read this document and i have some questions.

In the introduction you state:

  The secure neighbor discovery usage scenarios have recently been
   extended to include environments with mobile or nomadic nodes.  These
   nodes can often be limited in power and memory capabilities, and thus
   may only be able to support lightweight public key cryptography; that
   is, RSA-based public keys and algorithm support may not be feasible.

But the proposed solution still requires to have an RSA key in the 
Public Key field of the CGA PDS, right?

So, i am confused about how the goal of not having RAS keys is achieved 
with this apporach

next:

  The secure neighbor discovery usage scenarios have recently been
   extended to include environments with mobile or nomadic nodes.  These
   nodes can often be limited in power and memory capabilities, and thus
   may only be able to support lightweight public key cryptography; that
   is, RSA-based public keys and algorithm support may not be feasible.

i am not sure this belongs to this doc or to the send one

then it reads:

   However , it should be noted that the resulting security level of a
   multiple-key CGA is only that of the weakest key.  Therefore, the
   requirement remains that every key in use should have a security
   level matching or exceeding that of a 384-bit RSA key.

I am not sure this is true
I mean, this depends on how the receiving node is implemented, right? I 
mean, if the receiver only acceptes keys with a given length, then it 
won't accept signatures with other shorter keys, even if the keys are 
part of the CGA.

Regards, marcelo

---

From: Tony Cheneau <[email-masked]>
Date: Wed, 11 Mar 2009 15:54:22 +0100 (CET)

Hello Marcelo,

Thanks for your comments.

Comments inline:

> But the proposed solution still requires to have an RSA key in the Public Key 
> field of the CGA PDS, right?
No, it won't. The Public Key field in the CGA PDS can contain a RSA
Public Key, but it can also contain another type of Public Key (for
example, ECC). The document draft-cheneau-cga-pk-agility-00 only
contains necessary materials to allow multi-key CGA. In the companion
document draft-cheneau-send-sig-agility-00, we explain how to use these
multi-key CGA with SEND.
The main idea is that we want to keep backward compatibility with
RFC3971 nodes, three cases here:
- we have a multi-CGA containing at least one RSA Public Key. The RSA
   Public Key is stored in the Public Key field of the CGA PDS. So
   RFC3971 will at least be able to read this Public Key. In this case,
   the advantage is not in generating this multi-CGA, but in the
   possibility of using a Signature Algorithm different than RSA with
   SEND, where it can save some CPU.
- we have a multi-CGA containing no RSA Public Key. Any of the Public
   Key can be stored in the Public Key field of the CGA PDS. RFC3971
   nodes won't be able to communicate with us anyway.
- a CGA based on a single signature algorithm (which may not be RSA).

> So, i am confused about how the goal of not having RAS keys is achieved with 
> this apporach
This is indeed confusing, as we advocate for using something else that
RSA and still we talk about storing RSA in the Public Key field of the
CGA PDS. This is only for transitional phases and interactions with
RFC 3971 nodes. In homogeneous network, CGA will only need to be formed
from a single type of Public Key, that may not be RSA.

> i am not sure this belongs to this doc or to the send one
We will change it. It doesn't fit well in this document as we intent it
to define an extension field that is usable for CGA based protocols (and
not restricted to SEND).

> I mean, this depends on how the receiving node is implemented, right? I mean, 
> if the receiver only acceptes keys with a given length, then it won't accept 
> signatures with other shorter keys, even if the keys are part of the CGA.
Yes, this is a problem that belong to the send-sig-agility draft and
will be described in more details the next version of the draft.
In this document, we only state that the Public Keys carried in this new
extension field should not be weaker than a equivalent 384-bit RSA key.
The issue arise with multi-key CGA, where a CGA can have Public Keys of
different security level.

I hope I answered your questions/comments.

Regards,
 	Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 13 Mar 2009 10:52:21 +0100

> document draft-cheneau-send-sig-agility-00, we explain how to use these

I haven't read draft-cheneau-send-sig-agility-00 yet (i was supposed to 
do that today, but life got more complicated..)
but what you are saying doesn't make a lot of sense to me
In draft-cheneau-cga-pk-agility-00 yo define how to include multiple 
keys in CGAs
 From rfc3972, it is reccomended to use RSA. I guess that if a different 
reccomendation will be made, this should be done in the document 
referring to the CGA rahter than in the document referring send, if you 
see what i mean

> - a CGA based on a single signature algorithm (which may not be RSA).
all this makes sense to me, but it is not obvious from reading 
draft-cheneau-cga-pk-agility-00

>> So, i am confused about how the goal of not having RAS keys is 
>> achieved with this apporach

makes sense to me
this should be clarified in the draft though
> to define an extension field that is usable for CGA based protocols (and
ok

>> I mean, this depends on how the receiving node is implemented, right? 
>> I mean, if the receiver only acceptes keys with a given length, then 
>> it won't accept signatures with other shorter keys, even if the keys 
>> are part of the CGA.
i agree with this

> I hope I answered your questions/comments.
thnaks, marcelo