Subject: [6lo] I-D Action: draft-ietf-6lo-ap-nd-03.txt

From: [email-masked]
Date: Thu, 21 Sep 2017 04:42:08 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes WG of the IETF.

        Title           : Address Protected Neighbor Discovery for Low-power and Lossy Networks
        Authors         : Behcet Sarikaya
                          Pascal Thubert
                          Mohit Sethi
	Filename        : draft-ietf-6lo-ap-nd-03.txt
	Pages           : 17
	Date            : 2017-09-21

Abstract:
   This document defines an extension to 6LoWPAN Neighbor Discovery RFC
   6775.  Nodes supporting this extension compute a cryptographic Owner
   Unique Interface ID and associate it with one or more of their
   Registered Addresses.  Once an address is registered with a
   Cryptographic ID, only the owner of that ID can modify the anchor
   state information of the Registered Address, and Source Address
   Validation can be enforced.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-03
https://datatracker.ietf.org/doc/html/draft-ietf-6lo-ap-nd-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Sep 2017 11:57:32 +0000

This update implements Charlie's editorial suggestions and solves the issues that he found during his in depth review. Thanks a bunch Charlie!

Dear chairs: The document is now ready for a SECAREA review prior to last call. Would it be possible to trigger it?

Thanks for all

Pascal

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: jeudi 21 septembre 2017 13:42
To: [email-masked]
Cc: [email-masked]
Subject: [6lo] I-D Action: draft-ietf-6lo-ap-nd-03.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: Rene Struik <[email-masked]>
Date: Thu, 21 Sep 2017 10:00:23 -0400

Hi Pascal:

I had a quick glance at the document, just to see which type of crypto 
was being recommended. {For now, I did not review anything else yet.}

The document includes the option of using Curve25519, as defined in RFC 
7748, for signing. In my mind, this should be Ed25519, as defined in RFC 
8032.

Notes:
1) Curve25519 is a so-called Montgomery curve, whereas Ed25519 is a 
(twisted) Edwards curve. Both can be thought of as being the same thing 
mathematically, since a point of Ed25519 can be viewed as simply another 
representation of a point of Curve25519 (i.e., both are isomorphic, in 
math speak). However, Ed25519 is unambiguously specified, see RFC 8032, 
Section 5.1, whereas the use of Curve25519 with signatures in not (at 
least not with IETF or NIST documents).
2) Please note that RFC 8032 also suggests some flavors of Ed25519 (with 
ctx, ph suffix). I would not recommend using the ctx flavor and do not 
have an opinion on whether one should use the ph (also known as 
pre-hashing) flavor (the latter depends on I/O restrictions of 
implementations).

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Mohit Sethi <[email-masked]>
Date: Thu, 21 Sep 2017 17:15:51 +0300

Hi Rene,

Thanks for pointing out. This is a case me trying to be too efficient in 
updating the draft. This is rather critical and will be fixed in the 
next iteration.

It would be good to know if others have any opinion on the mode of Ed25519.

--Mohit

On 09/21/2017 05:00 PM, Rene Struik wrote:
> The document includes the option of using Curve25519, as defined in 
> RFC 7748, for signing. In my mind, this should be Ed25519, as defined 
> in RFC 8032.
>
> Notes:
> (twisted) Edwards curve. Both can be thought of as being the same 
> thing mathematically, since a point of Ed25519 can be viewed as simply 
> another representation of a point of Curve25519 (i.e., both are 
> isomorphic, in math speak). However, Ed25519 is unambiguously 
> specified, see RFC 8032, Section 5.1, whereas the use of Curve25519 
> with signatures in not (at least not with IETF or NIST documents).
> 2) Please note that RFC 8032 also suggests some flavors of Ed25519 
> (with ctx, ph suffix). I would not recommend using the ctx flavor and 
> do not have an opinion on whether one should use the ph (also known as 
>> This update implements Charlie's editorial suggestions and solves the 
>> issues that he found during his in depth review. Thanks a bunch Charlie!
>>
>> Dear chairs: The document is now ready for a SECAREA review prior to 
>> last call. Would it be possible to trigger it?
>>
>> Thanks for all
>>
>> Pascal
>>
>> This draft is a work item of the IPv6 over Networks of 
>> Resource-constrained Nodes WG of the IETF.
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Sep 2017 14:36:13 +0000

Thanks a bunch René!

Mohit, you can trust René on this. I'd rather make the change before the SEC DIR review. Can you please make it and republish?

Thanks in advance : )

Pascal

-----Original Message-----
From: Mohit Sethi [mailto:[email-masked]] 
Sent: jeudi 21 septembre 2017 16:16
To: Rene Struik <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [6lo] FW: I-D Action: draft-ietf-6lo-ap-nd-03.txt

Hi Rene,

Thanks for pointing out. This is a case me trying to be too efficient in updating the draft. This is rather critical and will be fixed in the next iteration.

--Mohit