Re: [6lowpan] Comments on draft-sarikaya-6lowpan-cgand-00

[Behcet Sarikaya <[e-mail]>]

Hi Greg,
  Thanks for your careful reading. My replies below.



> Comments on draft-sarikaya-6lowpan-cgand-00
> "Lightweight Secure Neighbor  Discovery for Low-power and Lossy Networks"
> 
> I think the draft is a good  idea, providing an important security feature
> to neighbor discovery. The  draft proposes a protocol called LSEND: 
Lightweight
> Secure Neighbor  Discovery. 

Thanks for the comments.


> 
> Here are some comments on the draft. 
> 
> The introduction  could do a better job of describing how LSEND relates to 
>other
> drafts.   LSEND is very close to SEND (RFC 3971) but uses ECDSA instead of 
RSA.
> SEND  was designed to secure ND (RFC 2641) but RFC 2641 was obsoleted by RFC
> 4861.  Do the changes from 2641 to 4861 break SEND?  Can the SEND protocol  be
> used with the 6lowpan version of neighbor discovery, described  in
> draft-ietf-6lowpan-nd-15? (It appears so, LSEND + draft-ietf-6lowpan-nd-15  is
> described in Section 5.)

This should be RFC 2461 not 2641.

Section 11.2 in 4861 says that SEND is one possible protocol to use for 4861 or 
ND. As we explained in Section 3, SEND as is can not be used so we need LSEND.

> 
> In Section 1, an additional motivation is  that key generation (required for 
>CGA
> on low power hosts) is computationally  much cheaper with ECDSA than RSA. 

OK

> 
> The references for ECDSA (there are  two: SEC 1 and FIPS 186-3) should both
> appear in one place, I'd suggest under  "Digital Signature" in Section 4.1, 
>page
> 5. The reference to SEC 1 should  also be updated to version 2.0 (May 2009).
> Since SEC 1 is specifying ECDSA  for use with LSEND, I think it should be a
> normative reference.  

OK

> A  reference to the SECG standard "SEC 2: Recommended Elliptic Curve  Domain
> Parameters version 2.0" could also be added as an informative  reference since
> it contains relevant information about the EC domain  parameters used by LSEND
> (the named curved secp256r1). 
> 

OK

> In Section  4.2, the Key Hash is computed with SHA-2 instead of SHA-1 because 
>of
> the  weakness of SHA-1.   From what I can tell, the Key Hash field is  not
> authenticated (signed), since the Digital Signature Option signs the  
preceding
> options (c.f., Section 5.2 of SEND, RFC 3971), and some other  information, 
but
> not the Key Hash.  From RFC 3971, the purpose of the  Key Hash is "to 
associate
> the signature to a particular key known by the  receiver". Since the Key Hash 
>is
> being used only to help the receiver use the  right key, and could be modified
> in transit, I don't think it needs to be  computed with a cryptographic hash
> function at all, even just truncating the  public key to 128 bits would be OK.
> That said, I don't see a problem with  using SHA-2 here, since it must be
> implemented for ECDSA anyway. I just think  the text is misleading by saying 
>the
> Key Hash is computed with SHA-2 for  security reasons.  Following the same
> reasoning, LSEND could reduce the  size of Key Hash to 64 or 48 bits to save
> bandwidth, if desired. 

Yes, as it has recently been debated on the CoAP list, SHA-2 is the way to go.
As for Key Hash, in our draft, it is used as in 3971 except SHA-2. Reducing its 
size can be considered.

> In  Section 4.2 the sequence of octets to be signed is given by Section 5.2  
of
> RFC 3971 (SEND).  The first input is a "CGA Message Type Tag for  SEND", a
> 128-bit constant.  Should LSEND define its own CGA Message Type  Tag? 
> 

Good point!
We had assumed the same value as SEND. Why not a new value? Just now I generated 
one 0xE8C47FB7FD2BB885DAB2D31A0F2808B4


> Figure 1, caption: LLA is undefined in this document. 

Good catch. It should be LLN.


> 
> Section 5.1. For the given domain parameters, an 88-octet ECC public key  is 
>not
> using point compression, as defined in RFC 5480, Section 2.2. By using  point
> compression the size of the public key is reduced by 32 octets, to 56.  
Section
> 4.3 should specify that point compression be used when describing how  the
> public key is to be encoded.  

Agreed.

> 
> General comment: The fast  verification feature of ECDSA would be applicable 
>for
> this draft. The ECDSA  signing algorithm is not changed, but verification is
> implemented with an  equivalent computation that is more efficient.  The
> verification  efficiency is even greater if the signer includes one bit of
> ``side  information'' as a convenience to the verifier.  In LSEND this extra  
>bit
> could come from the reserved bits in the Signature option header, or the  Key
> Hash could be reduced from 128 bits to 127 bits.  If a particular  signer or
> verifier does not implement the fast verify techniques, they may  still
> interoperate with those that do.  The fast verify convention will  allow 
border
> routers to process a larger number of signatures. 
> Page 12 of  this paper describes the verification  technique:
> http://www.cacr.math.uwaterloo.ca/techreports/2005/cacr2005-28.pdf
> This  draft is also on the subject of fast  verification:
> http://tools.ietf.org/html/draft-struik-ecc-efficiencies-00

OK, I understand. Of course this feature (accelerated verification) could be 
incorporated if there is enough interest. 


Regards,

Behcet