Re: [ksk-rollover] IoT devices and KSK rollover
On Mon, 1 Jul 2019, Michael Casadevall wrote:
As for DoT/DoH, none of the above changes as there are no wire protocol changes to DNS in either of these use cases, and the cost of implementation is stupidly high. First off, it's impossible to deploy DoT/DoH in an internal network that uses RFC1918 address space (aka 10.0.0.0/8, 172.16.0.0/20, 192.168.0.0/16) as CA/B forum CAs can't issue certificates for this address space;
what prevents you from requesting a certificate on an internet connect IP using ACME, and then moving or also using it on the internal IP pointed to by internal only split DNS ?
Device manufactors also need to update their devices to update their root store from time to time.
I guess it really depends on your definition of IoT.
It should also be noted that the current Mozilla NSS root store is approximately 250 KiB in size uncompressed.
Why would an IoT device need the whole firefox or other vendor root CA store? Again, it really depends on what you call an IoT device.
There are major issues with DoH/DoT in general, but a lot of devices in general are going to simply incapable of supporting it because the cost of full TLS support + full set of CA root certificates is simply too high in terms of flash storage.
Maybe IoT devices shouldn't need to talk to the internet at large? And their trust model can be minimzed to the little things it needs? Paul
Replies inline. On 7/1/19 1:47 PM, Paul Wouters wrote:
On Mon, 1 Jul 2019, Michael Casadevall wrote:
As for DoT/DoH, none of the above changes as there are no wire protocol changes to DNS in either of these use cases, and the cost of implementation is stupidly high. First off, it's impossible to deploy DoT/DoH in an internal network that uses RFC1918 address space (aka 10.0.0.0/8, 172.16.0.0/20, 192.168.0.0/16) as CA/B forum CAs can't issue certificates for this address space;
what prevents you from requesting a certificate on an internet connect IP using ACME, and then moving or also using it on the internal IP pointed to by internal only split DNS ?
Most home networks (and a depressing number of corporate networks) on the offhand chance they do dynamic DNS use .local, .lan, or .home. Active Directory is a big offender here since Windows SBS was hardcoded to only allow .local domains for years, and Microsoft's official advice was to use .local unless you had a domain name for your practice up until ~2008. CA/B only allows issuance of certificates that have a publicly resolvable domain name that you can verify ownership of (or ownership of a specific public IP address that you have allocated to you). Furthermore, using a domain name to point at your DNS system has a bootstrapping problem (which can be resolved via traditional DNS but is very much non-ideal).
Device manufactors also need to update their devices to update their root store from time to time.
I guess it really depends on your definition of IoT.
For "higher end" devices running Linux, it is extremely common for the entire OS to be stored as a read-only squashfs image with a few directories in persistant flash marked read/write. I have yet to see any device that has a root certificate store put it anywhere read/writable (and the config paths that read these images are often hard coded). For lower end devices, the situation is far worse. One specific project I worked on as a contractor was built around a Cortex-M3 running in 16-bit Thumb mode; it had 128 kilobytes of working memory, 256 kb of executable/addressable flash (I think), and 8 MiB of "storage" flash (that could be read or written to, but not executed) that had to be manually paged into working memory (aka, it wasn't in the memory map). This was built around the WiCED RTOS and TCP/IP functionality was provided by an add-on card that had wifi and used AT commands to make TCP/IP and UDP connections (similar to https://www.itead.cc/wiki/ESP8266_Serial_WIFI_Module). The device by default used Amazon's IoT service to push and receive configuration settings, and could also connect to a customers on-premise location. These operations were done with TLS and HTTPS (with plans to also support MQTT at the time I left). Due to the way the onboard TLS stack, the root certificate storage had to be either in RAM or the executable/addressable flash memory. WiCED used ~20-30 KiB of onboard memory, and the TLS stack used up to 90 KiB (aka, almost everything the device had). Ultimately, I was forced to hardcode in the roots Amazon was using, and there was a large question mark with this device on how to handle customer based installs short of telling them to build certs from a specific CA, and I couldn't convince management we needed a more powerful board. I choose not to renew my contract, but I suspect their solution was to just disable all TLS validation.
It should also be noted that the current Mozilla NSS root store is approximately 250 KiB in size uncompressed.
Why would an IoT device need the whole firefox or other vendor root CA store? Again, it really depends on what you call an IoT device.
Because if you're supporting more than a single HTTPS site or resource that requires TLS, need to access third party websites, or access customer hosted equipment (for example, to download configuration information, submit results, etc), you can't know in advance what CA has signed your customer stuff, and it's the height of user unfriendly where you need to download your webservers root certificate and upload it to your device. Real world example: I'm an Internet enabled scanner. I want to have an IoT device that sends email to a given host. Due to privacy concerns, the information I send should not pass through the vendors servers. The SMTP relay my IT admin setup requires use of a username and password + STARTTLS. I have no idea what root certificate(s) their servers chain up to. I've encountered these devices at more than one customer's site, and can easily be called IoT devices. There are plenty of other cases I can come up with where you need an entire root store beyond DoH/DoT.
There are major issues with DoH/DoT in general, but a lot of devices in general are going to simply incapable of supporting it because the cost of full TLS support + full set of CA root certificates is simply too high in terms of flash storage.
Maybe IoT devices shouldn't need to talk to the internet at large? And their trust model can be minimzed to the little things it needs?
IoT devices should be well designed, secured and be regularly updated too. Sadly, we don't live in that world. We live in a world where vendors leave root enabled telnet on out of the box. This should be a rather enlightening read: https://jelmertiete.com/2016/03/14/IoT-IP-camera-teardown-and-getting-root-p... The state of IoT is just sad and depressing. Michael
Michael Casadevall <michael@casadevall.pro> 于2019年7月2日周二 上午5:02写道：
Replies inline.
On 7/1/19 1:47 PM, Paul Wouters wrote:
On Mon, 1 Jul 2019, Michael Casadevall wrote:
As for DoT/DoH, none of the above changes as there are no wire protocol changes to DNS in either of these use cases, and the cost of implementation is stupidly high. First off, it's impossible to deploy DoT/DoH in an internal network that uses RFC1918 address space (aka 10.0.0.0/8, 172.16.0.0/20, 192.168.0.0/16) as CA/B forum CAs can't issue certificates for this address space;
what prevents you from requesting a certificate on an internet connect IP using ACME, and then moving or also using it on the internal IP pointed to by internal only split DNS ?
Most home networks (and a depressing number of corporate networks) on the offhand chance they do dynamic DNS use .local, .lan, or .home. Active Directory is a big offender here since Windows SBS was hardcoded to only allow .local domains for years, and Microsoft's official advice was to use .local unless you had a domain name for your practice up until ~2008. CA/B only allows issuance of certificates that have a publicly resolvable domain name that you can verify ownership of (or ownership of a specific public IP address that you have allocated to you).
Furthermore, using a domain name to point at your DNS system has a bootstrapping problem (which can be resolved via traditional DNS but is very much non-ideal).
Device manufactors also need to update their devices to update their root store from time to time.
I guess it really depends on your definition of IoT.
For "higher end" devices running Linux, it is extremely common for the entire OS to be stored as a read-only squashfs image with a few directories in persistant flash marked read/write. I have yet to see any device that has a root certificate store put it anywhere read/writable (and the config paths that read these images are often hard coded).
For lower end devices, the situation is far worse. One specific project I worked on as a contractor was built around a Cortex-M3 running in 16-bit Thumb mode; it had 128 kilobytes of working memory, 256 kb of executable/addressable flash (I think), and 8 MiB of "storage" flash (that could be read or written to, but not executed) that had to be manually paged into working memory (aka, it wasn't in the memory map).
This was built around the WiCED RTOS and TCP/IP functionality was provided by an add-on card that had wifi and used AT commands to make TCP/IP and UDP connections (similar to https://www.itead.cc/wiki/ESP8266_Serial_WIFI_Module).
The device by default used Amazon's IoT service to push and receive configuration settings, and could also connect to a customers on-premise location. These operations were done with TLS and HTTPS (with plans to also support MQTT at the time I left).
+1, for cheaper chips, they may not store whole chain certificates content to save the memory size.
Due to the way the onboard TLS stack, the root certificate storage had to be either in RAM or the executable/addressable flash memory. WiCED used ~20-30 KiB of onboard memory, and the TLS stack used up to 90 KiB (aka, almost everything the device had).
Ultimately, I was forced to hardcode in the roots Amazon was using, and there was a large question mark with this device on how to handle customer based installs short of telling them to build certs from a specific CA, and I couldn't convince management we needed a more powerful board. I choose not to renew my contract, but I suspect their solution was to just disable all TLS validation.
It should also be noted that the current Mozilla NSS root store is approximately 250 KiB in size uncompressed.
Why would an IoT device need the whole firefox or other vendor root CA store? Again, it really depends on what you call an IoT device.
Because if you're supporting more than a single HTTPS site or resource that requires TLS, need to access third party websites, or access customer hosted equipment (for example, to download configuration information, submit results, etc), you can't know in advance what CA has signed your customer stuff, and it's the height of user unfriendly where you need to download your webservers root certificate and upload it to your device.
Real world example: I'm an Internet enabled scanner. I want to have an IoT device that sends email to a given host. Due to privacy concerns, the information I send should not pass through the vendors servers. The SMTP relay my IT admin setup requires use of a username and password + STARTTLS. I have no idea what root certificate(s) their servers chain up to.
I've encountered these devices at more than one customer's site, and can easily be called IoT devices. There are plenty of other cases I can come up with where you need an entire root store beyond DoH/DoT.
There are major issues with DoH/DoT in general, but a lot of devices in general are going to simply incapable of supporting it because the cost of full TLS support + full set of CA root certificates is simply too high in terms of flash storage.
Maybe IoT devices shouldn't need to talk to the internet at large? And their trust model can be minimzed to the little things it needs?
IoT devices should be well designed, secured and be regularly updated too. Sadly, we don't live in that world. We live in a world where vendors leave root enabled telnet on out of the box. This should be a rather enlightening read:
https://jelmertiete.com/2016/03/14/IoT-IP-camera-teardown-and-getting-root-p...
The state of IoT is just sad and depressing. Michael _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (4)
-
Dave Lawrence -
Lanlan Pan -
Michael Casadevall -
Paul Wouters