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

[Greg Zaverucha <[e-mail]>]

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. 

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.)

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. 

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.  
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). 

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. 

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? 

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

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.  

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


Greg






---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.