Subject: Re: [Lwip] WGLC for draft-ietf-lwig-crypto-sensors-02

From: Rahul Jadhav <[email-masked]>
Date: Sat, 4 Mar 2017 23:00:24 +0530

The draft provides useful information to implementors about different
challenges related to security aspects especially towards using low-end
hardware. The deployment model described with the experiences will prove
helpful to implementors. Will be helpful to take this work forward.

Regards,
Rahul

On 22 February 2017 at 08:45, Zhen Cao <[email-masked]> wrote:

> Hello everyone,
>
> This email starts the WGLC for draft-ietf-lwig-crypto-sensors-02
> (https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-02)
>
> Could you help review the document and send your comments to the
> mailing list. Thank you in advance.
>
> The WGLC will end in two weeks from now.
>
> BR,
> Zhen
>
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>

---

From: Mudugodu Seetarama Raghavendra <[email-masked]>
Date: Mon, 6 Mar 2017 09:35:07 +0000

+1

Regards,

Raghavendra

________________________________
From: Lwip <[email-masked]> on behalf of Rahul Jadhav <[email-masked]>
Sent: Saturday, March 4, 2017 7:30 PM
To: [email-masked]
Subject: Re: [Lwip] WGLC for draft-ietf-lwig-crypto-sensors-02

The draft provides useful information to implementors about different challenges related to security aspects especially towards using low-end hardware. The deployment model described with the experiences will prove helpful to implementors. Will be helpful to take this work forward.

Regards,
Rahul

On 22 February 2017 at 08:45, Zhen Cao <[email-masked]<mailto:[email-masked]>> wrote:
Hello everyone,

BR,
Zhen

_______________________________________________
Lwip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lwip

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 6 Mar 2017 14:36:09 +0100

Hi all,

as I mentioned in the past I consider this document problematic.

The selected hardware gives the impression that IoT devices need very
low requirements. This gives inexperienced readers the wrong impression.

At no point in the document it explains why a typical software stack
required for an IoT device would fit on hardware that has 2 kB of SRAM,
and 32 kB of flash memory. What did you put on that device? (CoAP, DTLS,
Resource Directory, SENML -- protocol talk about in Section 9) I suspect
that there is no firmware update mechanism in place, which is a
typically demanded feature for IoT devices in order to address bugs.

Other IETF publications recommend key sizes of at least 112 bits
(symmetric). Here is the relevant table from RFC 4492:

                       Symmetric  |   ECC   |  DH/DSA/RSA
                      ------------+---------+-------------
                           80     |   163   |     1024
                          112     |   233   |     2048
                          128     |   283   |     3072
                          192     |   409   |     7680
                          256     |   571   |    15360

The document, however, describes RSA key sizes of 64, 128, 512 and 2014
bits! It makes no sense to illustrate performance, and memory
requirements of key sizes that shouldn't be used in today's IoT hardware.

The document says that it describes smart object implementation
experience but clearly this is far away from real world product
experience. The need for a random number generator is essentially
missing and a reference to a software library does not help either.

I believe you have started with some hardware and then created the
software & performance measurements. The recommended approach is,
however, to first think about security and the requirements and
subsequently think about what hardware supports the security
requirements and therefore mitigates the threats.

The document references several work in progress specifications. Also
the pointers to specifications like HIP or IPsec for use with IoT
devices is misleading since they are not reflecting industry practice.
They are at best university research projects.

Ciao
Hannes

On 03/06/2017 10:35 AM, Mudugodu Seetarama Raghavendra wrote:
> +1
> 
> 
> Regards,
> 
> Raghavendra
> 
> 
> 
> ------------------------------------------------------------------------
> *From:* Lwip <[email-masked]> on behalf of Rahul Jadhav
> <[email-masked]>
> *Sent:* Saturday, March 4, 2017 7:30 PM
> *To:* [email-masked]
> *Subject:* Re: [Lwip] WGLC for draft-ietf-lwig-crypto-sensors-02
>  
>     (https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-02
>     <https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-02>)
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/lwip>
> 
> 
> 
>

---

From: Zhen Cao <[email-masked]>
Date: Thu, 9 Mar 2017 18:02:17 +0800

Hi Hannes,

Thanks for the frank points, which are helpful to make documents more
impactful.  Please see my discussion in-line.

On Mon, Mar 6, 2017 at 9:36 PM, Hannes Tschofenig <[email-masked]
> wrote:

> low requirements. This gives inexperienced readers the wrong impression.

I do not think this leads to any incorrect impressions.  It clearly states
the platform that this work has been carried out, and by informed selection
of crypto libraries, security functions can be enabled on such IoT
devices.  It's much better than the other opposite impression that security
is costly and could be avoid as far as we can.

> (symmetric). Here is the relevant table from RFC 4492:

Is this 112 bits of symmetric encryption mandatory for even tiny devices?
If this is only a recommended value, we can encourage the contributors to
generate some reference benchmarks for longer asymmetric key values.

>                        Symmetric  |   ECC   |  DH/DSA/RSA

The recommended approach is definitely right for any product design.  But
considering the various requirements with different security needs, it is
pretty hard to cover all of them in one draft.   How about to also include
some discussion of the limitations of doing this in other scenarios that
may break security.

> They are at best university research projects.

Thanks for checking this.  I think Mohit can try to figure out and change
these inappropriate citations .

Will wait for @Mohit's response anyway.

Best regards,
Zhen

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 9 Mar 2017 12:21:06 +0100

Hi Zhen,

thanks for the quick response.

Here is how I read the document: Many years ago we played around with
some hardware, which happened to be in the office. We ran some security
tests and the results for state-of-the-art crypto was extremely slow.
Hence, we added other performance measurements using key length that
nobody would be able to use. Then, it looked much better.

All security recommendations I have read suggest to use 112-bits+ keys
for modern implementations.

> Is this 112 bits of symmetric encryption mandatory for even tiny

A clear "yes" also for tiny IoT devices.

What I am still missing is a response to my question about the actual
software stack being used on that device.

Ciao
Hannes

On 03/09/2017 11:02 AM, Zhen Cao wrote:
> On Mon, Mar 6, 2017 at 9:36 PM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi all,
> 
> I do not think this leads to any incorrect impressions.  It clearly
> states the platform that this work has been carried out, and by informed
> selection of crypto libraries, security functions can be enabled on such
> IoT devices.  It's much better than the other opposite impression that
> security is costly and could be avoid as far as we can. 
> 
> 
> Is this 112 bits of symmetric encryption mandatory for even tiny
> devices? If this is only a recommended value, we can encourage the
> contributors to generate some reference benchmarks for longer asymmetric
> key values. 
>  
> 
> 
> The recommended approach is definitely right for any product design. 
> But considering the various requirements with different security needs,
> it is pretty hard to cover all of them in one draft.   How about to also
> include some discussion of the limitations of doing this in other
> scenarios that may break security. 
>  
> 
> 
> Thanks for checking this.  I think Mohit can try to figure out and
> change these inappropriate citations . 
> 
>     > *From:* Lwip <[email-masked]
>     <mailto:[email-masked]>> on behalf of Rahul Jadhav
>     > <[email-masked] <mailto:[email-masked]>>
>     > *To:* [email-masked] <mailto:[email-masked]>
>     > On 22 February 2017 at 08:45, Zhen Cao <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Hello everyone,
>     >
>     <https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-02>
>     >     <https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-02
>     <https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-02>>)
>     >
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >     <https://www.ietf.org/mailman/listinfo/lwip
>     <https://www.ietf.org/mailman/listinfo/lwip>>
>     >
>     >
>     >
>     >

---

From: Mohit Sethi <[email-masked]>
Date: Thu, 9 Mar 2017 15:06:39 +0200

Hi Hannes

I had refrained from responding earlier because there was an ongoing 
discussion about this draft within the IoT directorate. I wanted to wait 
for it to conclude before responding. But in any case, here is my response:

This is how you want to solve the IoT security problem:
Use ARM chips -> Run the mbed OS -> Use TLS/DTLS only for security -> 
add Trustzone based attestation for some extra features.

Since we already have these tools in place, IoT security is solved and 
we should all move on. Unfortunately, while you may choose to close your 
eyes and ignore reality, others can't. The fact is that other 
platforms/protocols/OS exist, are needed and are used by folks out there.

At no point do we suggest in the draft that using bad curves and small 
key sizes is good. In fact, I have said it earlier and I say it again, I 
am totally ok with removing the numbers for RSA key sizes less than 
2048-bits. Recently in the ACE working group (for which you are 
co-chair) there was a suggestion from M St. Johns that 1024-bit RSA 
might perform better than ECDSA at similar security levels: 
https://mailarchive.ietf.org/arch/msg/ace/znba10pRL5c3D1aa9_azz9uyeAM. 
The numbers in our draft came in handy to show that it is not the case 
on the platform tested. The numbers are in the draft only for reference 
(and can be removed).

At no point is it suggested that you shouldn't do software updates for 
your IoT devices. In fact this draft is talking about public-key crypto 
on IoT devices. You would typically use some signature verification for 
firmware and software updates. If I write a draft on performance of 
HTTP, would you ask me whether my machine had software updates or not? 
The draft does not try to build a product. At least not this draft.

The draft also clearly recommends you to choose a 32-bit platform. We 
simply show that if you can do public-key crypto on an 8-bit platform, 
you can do it much faster and more efficiently on a 32-bit platform:

> A recent trend in microcontrollers
>     is the introduction of 32-bit CPUs that are becoming cheaper and more
>     easily available than 8-bit CPUs, in addition to being more easily
>     programmable.

I am fine with removing the numbers that you don't like. But in 
principle I like drafts that actually implement something than the other 
high-level so-called "guidance" documents.

Regarding the stack, the draft does say that we use an ATmega2560 board, 
on which we implement message signing with public-key cryptography, 
CoAP, DHCP, UDP, IP, Ethernet. Yes, all this in less than 8 kB of RAM. 
And no, we don't say that this is enough for a real product. You would 
need more memory in a real product because you will have other things 
such as software updates etc. and other favorite features.

If you have suggestions on how the text can be rephrased better, I am 
more than open to feedback.

Thanks
Mohit
On 03/09/2017 01:21 PM, Hannes Tschofenig wrote:
>> devices?