Subject: [6lo] Review of draft-sarikaya-6lo-ap-nd

From: Mohit Sethi <[email-masked]>
Date: Mon, 1 Feb 2016 11:01:07 +0200

Hi folks

Here is my review for draft-sarikaya-6lo-ap-nd-01

- Overall, I believe the draft is trying to address a valid problem.

- Before coming to the technical merits, at first glance, this proposal 
looked quite similar to CGA. While I have no horse in this race, I 
wonder why not use CGA directly (or define an extension). I understand 
that CGA spec was defined with RSA which might be unsuitable for 
constrained devices, but are there any other major differences in the 
spec? The authors say that " the cryptographic material is not embedded 
in the Interface ID (IID) in an IPv6 address but used as a correlator 
associated to the registration of the IPv6  address." What is the reason 
for not embedding? Are there any advantages to such an approach? When it 
comes to security, I would rely on an existing standards that are 
well-studied and have running code as much as possible.

- I think address spoofing is a valid problem. However, I wonder why we 
want to force the nodes to use its own MAC address. Given all the 
privacy concerns, shouldn't we just allow nodes to use a random MAC 
address. There is a trend of moving away from static MAC addresses that 
never change. For example, iOS 8 features MAC Randomization 
(http://blog.airtightnetworks.com/ios8-mac-randomization-analyzed/ ). 
Similarly, IEEE has suggested the use of MAC randomization 
(http://www.csoonline.com/article/2945044/cyber-attacks-espionage/ieee-groups-recommends-random-mac-addresses-for-wi-fi-security.html) 
and there was a presentation in IETF 93 about experiences with MAC 
address randomization in Windows 
(https://www.ietf.org/proceedings/93/slides/slides-93-intarea-5.pdf). If 
the nodes can do ECC, I am sure they can generate a random MAC address.

Given this, and the Alissa Coopers recommendation on MAC address privacy 
(https://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-08), 
won't it be just simpler to also suggest that 6LoWPAN nodes generate a 
random MAC address during registration. I think these recommendations 
holds true even if the addresses are not used beyond the 6LBR.

- Another thing that worries me a lot is crypto agility. The draft 
currently defines just one curve (P-256). There is no way of negotiating 
among nodes and routers what kind of elliptic curves are used for public 
keys. Having no crypto agility works fine for RSA which is still 
accepted to be secure. I am not sure how well this works for ECC. 
Especially when there seem to be repeated reports of vulnerabilities 
found in different curves every now and then. If you check 
http://safecurves.cr.yp.to/ then NIST P-256 is listed as unsafe. If new 
devices come with new curve parameters, how would they inter-operate? 
The lifetime of these devices is expected to be at-least 10-20 years. 
One way to resolve this is to add curve information to the CGA params. 
And one would assume that the 6LR and 6LBR support several curves and 
use the one that is chosen by the node. I think this still requires some 
thinking.

These initial comments are based on my understanding from a first glance 
of the draft and I might have missed something completely. Please 
correct me where I am wrong.

Thanks
/--Mohit

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Feb 2016 11:40:48 -0600

Hi Mohit,

We were revising the draft and ran into one issue, please see below.

On Mon, Feb 1, 2016 at 3:01 AM, Mohit Sethi <[email-masked]> wrote:
> looked quite similar to CGA. While I have no horse in this race, I wonder
> why not use CGA directly (or define an extension). I understand that CGA
> spec was defined with RSA which might be unsuitable for constrained devices,
> but are there any other major differences in the spec? The authors say that
> " the cryptographic material is not embedded in the Interface ID (IID) in an
> IPv6 address but used as a correlator associated to the registration of the
> IPv6  address." What is the reason for not embedding? Are there any
> advantages to such an approach? When it comes to security, I would rely on
> an existing standards that are well-studied and have running code as much as
> possible.
>
> - I think address spoofing is a valid problem. However, I wonder why we want
> to force the nodes to use its own MAC address. Given all the privacy
> concerns, shouldn't we just allow nodes to use a random MAC address. There
> is a trend of moving away from static MAC addresses that never change. For
> example, iOS 8 features MAC Randomization
> and there was a presentation in IETF 93 about experiences with MAC address
> randomization in Windows
> (https://www.ietf.org/proceedings/93/slides/slides-93-intarea-5.pdf). If the
> nodes can do ECC, I am sure they can generate a random MAC address.
>
> random MAC address during registration. I think these recommendations holds
> true even if the addresses are not used beyond the 6LBR.
>

> - Another thing that worries me a lot is crypto agility. The draft currently
> defines just one curve (P-256). There is no way of negotiating among nodes
> and routers what kind of elliptic curves are used for public keys. Having no
> crypto agility works fine for RSA which is still accepted to be secure. I am
> not sure how well this works for ECC. Especially when there seem to be
> repeated reports of vulnerabilities found in different curves every now and
> then. If you check http://safecurves.cr.yp.to/ then NIST P-256 is listed as
> unsafe. If new devices come with new curve parameters, how would they
> inter-operate? The lifetime of these devices is expected to be at-least
> 10-20 years. One way to resolve this is to add curve information to the CGA
> params.

This seems to be good idea. Of course not making the NS packet too big
is a concern.

> And one would assume that the 6LR and 6LBR support several curves
> and use the one that is chosen by the node. I think this still requires some
> thinking.

What would be those several curves? Is there a good alternative to the
NIST P-256 that is not unsafe?
Any text suggestions would be helpful.

Thanks,

Behcet
>
> These initial comments are based on my understanding from a first glance of
> the draft and I might have missed something completely. Please correct me
> where I am wrong.
>
> Thanks
> /--Mohit

---

From: Rene Struik <[email-masked]>
Date: Wed, 10 Feb 2016 13:48:57 -0500

>> 10-20 years. One way to resolve this is to add curve information to the CGA
RS>>
The SafeCurves criteria have to be taken with a grain of salt. There are 
no known cryptanalytic attacks on P-256 known, nor is it that hard to 
implement the P-256 curve securely. As an aside, some of the criteria on 
that website are irrelevant for signature schemes such as ECDSA (e.g., 
twist security is only a nice to have if one does somewhat sloppy DH 
computations, where one leaves out specific trivial checks on purpose, 
and not relevant for ECDSA signing; the Montgomery ladder may be a "nice 
to have" for some curves, but not so much for ECDSA and may require far 
more code size than a single implementation that implements scalar 
multiplication (for signing) and multiple scalar multiplication (for 
verification) {which I suspect the case to be for highly constrained nodes.}
The SafeCurves criteria are somewhat a mixed bag, including technical 
criteria that virtually the entire crypto community agrees on and 
criteria that seem to be more things to the author's liking and 
controversial. As case in point, the criteria remain silent on some 
implementation attacks, where the special form of the primes of some of 
the items marked as "safe" may make power analysis attacks much easier, 
thereby forcing much longer scalar multiplications than would be 
required if those attacks would not have to be considered (see, e.g., 
http://csrc.nist.gov/groups/ST/ecc-workshop-2015/papers/session6-schindler-werner.pdf). 
The latter comes down to a factor 1.5x performance hit compared to 
ignoring implementation attacks. Personally, I think especially side 
channel attacks are important for IoT devices, since these are often 
accessible to outsiders. So, there is more to this topic than a simple 
table.
<<RS
> Any text suggestions would be helpful.
RS>>
I think it would be prudent to aim for algorithm agility (i.e., one 
should not hard-code curves into the specification). One note, though: 
if one has to negotiate curves and has generic code to implement scalar 
multiplications, one most likely will not get close to advertised speeds 
for non-short-Weierstrass curves (since those speeds are highly 
dependent on code that exploit the form of very special primes to its 
extreme). For now, prudence suggests to support a list of (more than 
one) algorithm(s).
<<RS
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

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

---

From: Mohit Sethi <[email-masked]>
Date: Thu, 11 Feb 2016 06:42:46 +0200

Hi Behcet and Pascal

I think Rene is way more qualified than me to comment on the security of 
curves.

I had just given the http://safecurves.cr.yp.to/ link to highlight that 
some kind of negotiation is needed. I don't have any favorite curve that 
I want to sneak into the spec. But like Rene says, one should not 
hard-code curves into the specification.

So supporting one our two acceptable curves is fine as long as the 
communicating parties can negotiate other curves which are added later 
down the line. I recently submitted a draft on secure bootstrapping of 
IoT with EAP-NOOB https://tools.ietf.org/html/draft-aura-eap-noob-00 
which only defines one curve (Curve25519) currently but allows 
negotiation so that new curves added in future specifications can be 
negotiated.

Thanks
/--Mohit

On 02/10/2016 08:48 PM, Rene Struik wrote:
>>> wonder
>>> the
>>> currently
> The SafeCurves criteria have to be taken with a grain of salt. There 
> are no known cryptanalytic attacks on P-256 known, nor is it that hard 
> to implement the P-256 curve securely. As an aside, some of the 
> criteria on that website are irrelevant for signature schemes such as 
> ECDSA (e.g., twist security is only a nice to have if one does 
> somewhat sloppy DH computations, where one leaves out specific trivial 
> checks on purpose, and not relevant for ECDSA signing; the Montgomery 
> ladder may be a "nice to have" for some curves, but not so much for 
> ECDSA and may require far more code size than a single implementation 
> that implements scalar multiplication (for signing) and multiple 
> scalar multiplication (for verification) {which I suspect the case to 
> be for highly constrained nodes.}
> implementation attacks, where the special form of the primes of some 
> of the items marked as "safe" may make power analysis attacks much 
> easier, thereby forcing much longer scalar multiplications than would 
> be required if those attacks would not have to be considered (see, 
> e.g., 
> if one has to negotiate curves and has generic code to implement 
> scalar multiplications, one most likely will not get close to 
> advertised speeds for non-short-Weierstrass curves (since those speeds 
> are highly dependent on code that exploit the form of very special 
> primes to its extreme). For now, prudence suggests to support a list 
> of (more than one) algorithm(s).
> <<RS
>> Thanks,
>>
>> Behcet

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 11 Feb 2016 11:28:34 +0000

Hi Mohit:

This discussion is way beyond the scope of this draft. I agree that signaling the curve is of high interest here and in many places. 

Seems to me that the description of the curve belongs to a way more generic work... 

Should that be triggered in the security area?

Adding iot-dir for recommendations;

Pascal

> -----Original Message-----
> From: Mohit Sethi [mailto:[email-masked]]
> Sent: jeudi 11 février 2016 05:43
> To: Rene Struik <[email-masked]>; [email-masked]
> Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> Subject: Re: [6lo] Review of draft-sarikaya-6lo-ap-nd
> 
> Hi Behcet and Pascal
> 
> I had just given the http://safecurves.cr.yp.to/ link to highlight that some
> kind of negotiation is needed. I don't have any favorite curve that I want to
> sneak into the spec. But like Rene says, one should not hard-code curves
> into the specification.
> 
> down the line. I recently submitted a draft on secure bootstrapping of IoT
> with EAP-NOOB https://tools.ietf.org/html/draft-aura-eap-noob-00
> which only defines one curve (Curve25519) currently but allows negotiation
> so that new curves added in future specifications can be negotiated.
> 
> Thanks
> /--Mohit
> 
> >>> - Before coming to the technical merits, at first glance, this
> >>> proposal looked quite similar to CGA. While I have no horse in this
> >>> race, I wonder why not use CGA directly (or define an extension). I
> >>> understand that CGA spec was defined with RSA which might be
> >>> unsuitable for constrained devices, but are there any other major
> >>> differences in the spec? The authors say that " the cryptographic
> >>> material is not embedded in the Interface ID
> >>> (IID) in an
> >>> advantages to such an approach? When it comes to security, I would
> >>> rely on an existing standards that are well-studied and have running
> >>> code as much as possible.
> >>>
> >>> - I think address spoofing is a valid problem. However, I wonder why
> >>> we want to force the nodes to use its own MAC address. Given all the
> >>> address.
> >>> There
> >>> is a trend of moving away from static MAC addresses that never
> >>> change. For example, iOS 8 features MAC Randomization
> >>> (http://www.csoonline.com/article/2945044/cyber-attacks-espionage/ie
> >>> ee-groups-recommends-random-mac-addresses-for-wi-fi-security.html)
> >>>
> >>> (https://www.ietf.org/proceedings/93/slides/slides-93-intarea-5.pdf)
> >>> . If the nodes can do ECC, I am sure they can generate a random MAC
> >>> address.
> >>>
> >>> won't it be just simpler to also suggest that 6LoWPAN nodes generate
> >>> a random MAC address during registration. I think these
> >>> recommendations holds true even if the addresses are not used beyond
> >>> the 6LBR.
> >>>
> >>
> >>> currently defines just one curve (P-256). There is no way of
> >>> negotiating among nodes and routers what kind of elliptic curves are
> >>> used for public keys.
> >>> Having no
> >>> crypto agility works fine for RSA which is still accepted to be
> >>> secure. I am not sure how well this works for ECC. Especially when
> >>> there seem to be repeated reports of vulnerabilities found in
> >>> different curves every now and then. If you check
> >>> http://safecurves.cr.yp.to/ then NIST P-256 is listed as unsafe. If
> >>> new devices come with new curve parameters, how would they
> >>> 10-20 years. One way to resolve this is to add curve information to
> >>> the CGA params.
> > RS>>
> > be for highly constrained nodes.} The SafeCurves criteria are somewhat
> > a mixed bag, including technical criteria that virtually the entire
> > crypto community agrees on and criteria that seem to be more things to
> > the author's liking and controversial. As case in point, the criteria
> > remain silent on some implementation attacks, where the special form
> > of the primes of some of the items marked as "safe" may make power
> > analysis attacks much easier, thereby forcing much longer scalar
> > multiplications than would be required if those attacks would not have
> > to be considered (see, e.g.,
> >> This seems to be good idea. Of course not making the NS packet too
> >> big is a concern.
> >>
> >>> and use the one that is chosen by the node. I think this still
> >>> requires some thinking.
> >> What would be those several curves? Is there a good alternative to
> >> the NIST P-256 that is not unsafe?
> >>> These initial comments are based on my understanding from a first
> >>> glance of the draft and I might have missed something completely.
> >>> Please correct me where I am wrong.
> >>>
> >>> Thanks
> >>> /--Mohit

---

From: Rene Struik <[email-masked]>
Date: Thu, 11 Feb 2016 09:41:51 -0500

Dear colleagues:

At this point, I think it would be good to support algorithm agility 
(fortunately, security protocols often allow for modularity), where 
instantiations can be dealt with in a separate section. This being said, 
there may be good reasons (e.g., space constraints in the protocol) to 
pick one option.

BTW - some of the CGA schemes in the past hardly provided security at 
all, due to protocol aspects. I will try and reread the draft to refresh 
my mind and see whether the current draft avoids this.

FYI: in case one cares about referencing IETF-internal documents, RFC 
7696 provides some "agility" language here as well.

Best regards, Rene

RFC 7696 - Guidelines for Cryptographic Algorithm Agility and Selecting 
Mandatory-to-Implement Algorithms (November 2015)

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 11 Feb 2016 16:21:20 -0600

Hi Rene,

On Thu, Feb 11, 2016 at 8:41 AM, Rene Struik <[email-masked]> wrote:
> there may be good reasons (e.g., space constraints in the protocol) to pick
> one option.

This is what we want to do in our draft.

>
> BTW - some of the CGA schemes in the past hardly provided security at all,
> due to protocol aspects. I will try and reread the draft to refresh my mind
> and see whether the current draft avoids this.

Please do so.

>
> FYI: in case one cares about referencing IETF-internal documents, RFC 7696
> provides some "agility" language here as well.
>

In Russ' RFC or BCP 201, he does not prescribe negotiation for crypto
agility. He points out several ways of doing it. Currently we are
using P-256 curve, we may also recommend Curve25519.

Regards,

Behcet
>> This discussion is way beyond the scope of this draft. I agree that
>> signaling the curve is of high interest here and in many places.
>>
>>> some
>>> IoT
>>> negotiation
>>>> http://csrc.nist.gov/groups/ST/ecc-workshop-2015/papers/session6-
>>>
>>> schindler-werner.pdf).
>>>>