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