This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/iot-wg@ripe.net/
[iot-wg] algorithm agility for IoT
- Previous message (by thread): [iot-wg] algorithm agility for IoT
- Next message (by thread): [iot-wg] algorithm agility for IoT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Mirjam Kuehne
mir at ripe.net
Mon Jan 21 13:23:50 CET 2019
Hi all, In case others are interested in this, here is some more information about the considerations and principles that went into RIPE Atlas: 1. RIPE Atlas Probes as IoT Devices https://labs.ripe.net/Members/kistel/ripe-atlas-probes-as-iot-devices 2. RIPE Atlas Architecture - How We Manage Our Probes https://labs.ripe.net/Members/kistel/ripe-atlas-architecture-how-we- manage-our-probes Kind regards, Mirjam Kühne RIPE NCC On 21/01/2019 13:12, Robert Kisteleki wrote: > Hi, > > I'm not sure it's applicable, but mechanisms behind RIPE Atlas, when > looked at as an IoT-like service, can also be considered as an example. > > I guess we can talk about the details offline. > > Regards, > Robert > > > On 2019-01-21 12:54, Jim Reid wrote: >> I’m working on a document at ITU Study Group 20 on algorithm agility. [So you don’t have to! :-)] The aim is to produce a Recommendation which essentially says “don’t hard-wire crypto algorithms into IoT stuff because what’s secure today could be insecure tomorrow”. For instance, building or deploying an IoT solution that can’t use anything but MD5 or DES (say) would be bad. Similarly, it would be undesirable to install a sensor network today that can’t handle tomorrow's devices because they might well use new crypto which isn’t around today. >> >> At the moment, the document cites the mechanisms used in TLS and DNSSEC as frameworks that those deploying and designing IoT infrastructure should consider. ie Continuously updated registries which add new algorithms when these become available and drop old ones which are considered unsafe or whatever. Please note that the document isn’t going to say everyone *must* use TLS and/or DNSSEC since that clearly depends on specific (unique?) use cases and requirements. Instead the document will say that people should take account of those sorts of frameworks when they are designing, procuring or operating IoT infrastructure. >> >> SG20 has said the document needs more examples of these kinds of frameworks. So I’m asking the list if they can suggest some. I’d particularly like to about potential examples from those developing IoT firmware or operating systems. Or authentication schemes for IoT. What sort of mechanisms and frameworks are available? What’s done in RIOT or the stripped down BSD/Linux stuff that underpins some IoT platforms? Anything else? >> >> The obvious example that springs to mind are dynamic SSL libraries - for instance the package managers that supply the latest version(s) of OpenSSL. Or the replacements for that which sprung up after the Heartbleed incident. However that’s a bit fuzzy. I suppose CAB Forum advice on X.509 certificates might be another. >> >> But there must be more. Any suggestions or pointers? >> >> >> _______________________________________________ >> iot-wg mailing list >> iot-wg at ripe.net >> https://mailman.ripe.net/ >> > > _______________________________________________ > iot-wg mailing list > iot-wg at ripe.net > https://mailman.ripe.net/ >
- Previous message (by thread): [iot-wg] algorithm agility for IoT
- Next message (by thread): [iot-wg] algorithm agility for IoT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ iot-wg Archives ]