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. Regarding your question: > Is this 112 bits of symmetric encryption mandatory for even tiny > devices? 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: > 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 > <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>> wrote: > > 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. > > > 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. > > > 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: > > > 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 > ------------+---------+------------- > 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 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. > > > > 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. > > > 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 > > > Ciao > Hannes > > > On 03/06/2017 10:35 AM, Mudugodu Seetarama Raghavendra wrote: > > +1 > > > > > > Regards, > > > > Raghavendra > > > > > > > > > ------------------------------------------------------------------------ > > *From:* Lwip <lwip-boun...@ietf.org > <mailto:lwip-boun...@ietf.org>> on behalf of Rahul Jadhav > > <rahul.i...@gmail.com <mailto:rahul.i...@gmail.com>> > > *Sent:* Saturday, March 4, 2017 7:30 PM > > *To:* lwip@ietf.org <mailto:lwip@ietf.org> > > *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 <zhencao.i...@gmail.com > <mailto:zhencao.i...@gmail.com> > > <mailto:zhencao.i...@gmail.com <mailto:zhencao.i...@gmail.com>>> 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 > <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>>) > > > > 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 > > Lwip@ietf.org <mailto:Lwip@ietf.org> <mailto:Lwip@ietf.org > <mailto:Lwip@ietf.org>> > > https://www.ietf.org/mailman/listinfo/lwip > <https://www.ietf.org/mailman/listinfo/lwip> > > <https://www.ietf.org/mailman/listinfo/lwip > <https://www.ietf.org/mailman/listinfo/lwip>> > > > > > > > > > > _______________________________________________ > > Lwip mailing list > > Lwip@ietf.org <mailto:Lwip@ietf.org> > > https://www.ietf.org/mailman/listinfo/lwip > <https://www.ietf.org/mailman/listinfo/lwip> > > > > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org <mailto:Lwip@ietf.org> > https://www.ietf.org/mailman/listinfo/lwip > <https://www.ietf.org/mailman/listinfo/lwip> > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
