Thank You for your feedback Hannes, I addressed the comments below - On February 23, 2022 5:36:15 AM EST, Hannes Tschofenig <[email protected]> wrote: >Hi all, > >Thanks for this contribution, Jim. > >Reading through the document I agree that the SUIB topic discussed in the >IOTOPS WG appears relevant. I also wonder whether the work in the DANISH group >(see https://datatracker.ietf.org/wg/danish/about/) is relevant.
Agreed about SUIB, not quite sure about DANISH. DANISH is about certificate based authentication and PKI extensions, while SNIF is about end-to-end relayed trusted TLS that relies on the standard PKI. > >Regarding the use in IoT I have a question for my understanding. > >In a nutshell, you introduce a proxy that allocates a hostname and requests a >creation of a certificate on behalf of the IoT device. Correct, plus an e2e TLS relay. > >To get this to work you rely on three assumptions: >(1) There has to be a communication infrastructure that associates the >"anonymous" hostname with a specific device and conveys these identifiers to >the relevant parties. Each device is configured with an initUrl pointing to a specific CA proxy that allocates a random hostname (a CN to be more accurate), normally a subdomain of a master domain that has a wildcard DNS record pointing to the CA proxy. Example - the initUrl for public experimental use - https://snif.snif.xyz:4443 The allocated wildcard CN is a subdomain of the master domain snif.xyz >(2) You assume that a party that wants to contact the IoT device is able to >reach the device (i.e. the IoT device is not behind a firewall or NAT). Both the IoT device and the client connect to the SNIF relay. The whole purpose of SNIF is to be able to work from behind NAT / firewall /etc, and it's been confirmed to work in pre-production. In fact I had a minor hickup with Fortigate in the process of testing which has been resolved. There are simplified diagrams on https://snif.host to illustrate the concept. >(3) Someone operating IoT devices has to trust the proxy since it is easy for >the proxy to associate a hostname with a public key that was created by the >proxy (rather than the end device). This essentially allows the proxy to >impersonating the IoT device. > >Is my understanding correct? Yes, I mentioned this vulnerability in the security section. The answer is - watch the public TLS transparency logs, any party can do it. If any overlapping CNs are found - the CA proxy is permanently compromised, - do not use random CA proxies owned by unknown parties. > >Ciao >Hannes Any further questions/suggestions are welcome. > >-----Original Message----- >From: Secdispatch <[email protected]> On Behalf Of Jim Zubov >Sent: Friday, February 11, 2022 12:22 AM >To: [email protected]; Michael Richardson <[email protected]>; Jim >Zubov <[email protected]>; [email protected]; [email protected] >Subject: Re: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT >Devices Using SNI-based End-to-End TLS Forwarding (SNIF) > >Thanks for the feedback again, my comment are below. >I submitted a new version of the draft to reflect some changes. > >On February 10, 2022 1:02:48 PM EST, Michael Richardson ><[email protected]> wrote: >> >>Jim Zubov <[email protected]> wrote: >> >> This was also on the IETF112 IOTOPS WG agenda: >> >> slides: >> >> >> https://datatracker.ietf.org/meeting/112/materials/slides-112-iotops-suib-browsing-local-web-resources-in-a-secure-usable-manner-iot-device-configuration-as-a-special-case-00 >> >> video: https://youtu.be/OIlJrUvwDcI?t=1649 >> >> >> >> and we hope to return at IETF113. >> >> > Right, looks like SUIB is working on a similar problem. Thanks for >> > pointing this out. In particular, the "Sol #6 Device name DNS" slide >> > looks quite similar to SNIF CA Proxy (Section 3). However, SUIB pursues >> > bigger infrastructural goals such as changing the localhost TLS >> > connection policies (I totally agree and really appreciate the effort), >> > while SNIF is a functioning solution within the existing >> > infrastructure, tested and proven to work in pre-production. >> >>The slides may be too vague. Changing the TLS policies is a possible >>solution, but probably an impractical one. Nevertheless, many people >>(not steeped in the arts, and often failling into the PHB category) >>think that it is an obvious solution, so we list it in order to explain why >>it won't work. > >Yes, still sad that localhost slipped through the cracks when the original >security standards were written. > >> >> >> The SUIB problem addresses the challenge of connecting *locally* to a >> >> device, >> >> and doing it securely. For this to be possible with RFC6125-DNS-ID >> >> standard >> >> browser, we need a name for the device, and we need a way to translate >> >> that >> >> name into a locally reachable IP address. >> >> >> >> The SNIF proposal does not quite solve the above problem. >> >> > In fact, I originally designed SNIF to solve this specific problem - >> > local-to-local trusted TLS connections. >> >>Ah, very nice to know. >> >> > * Issue a wildcard cert through SNIF CA Proxy >> > (e.g. CN=*.domain.snif.xyz), set a DNS record for >> > localhost.domain.snif.xyz to point to localhost's IPv4/v6, and use >> > https://localhost.domain.snif.xyz (or other app protocol - imaps >> > etc). However, looks like some clients treat the localhost IP as >> > inherently unsecure, and issue a warning ever is the cert is perfectly >> > valid. The option is still possible, but the applicability might be >> > limited. >> >>The process we described at >> >>https://specs.manysecured.org/suib/Solutions/dnsname-embedded-solution >> >>also uses a wildcard cert, but has a magic authoritative DNS server >>that translates the left-most label into an A or AAAA record. It's >>rather a cute hack, but at least: >> a) it's cachable >> b) it could even be calculated locally, if one ignores DNSSEC. > >Yes, using a local network IP instead of a localhost IP is actually a smart >idea. >However, inlining the local IP in the hostname, as SUIB does, means you'll >have to change the hostname in your client every time your network is changed. >I have an thought for SNIF improvement - SNIF connector sends a SNIF DNS >command to set a dynamic DNS A/AAAA for a certain hostname within the CN >wildcard, and the CA proxy updates the DNS accordingly. This way the hostname >can be permanent, but with dynamic DNS. >Another problem - most platforms won't let you bind to port < 1024 unless >you're a root. Might be ok for a device manufacturer, but is a potential show >stopper for any user space app. Relayed SNIF works around this problem since >the listening ports are on the relay. > > >> >> > * Another option is to override the IP routing rules. It is totally >> > possible on iOS and Mac through a userspace VPN (only one VPN per >> > device though - beware of possible conflicts). In fact I have a >> > functioning solution for it, in beta now - >> >>That doesn't really scale to many different domains. > >Totally agreed, I just mentioned that this option works for *some* cases, >tun/tap a is possible option too if you're a root. > >> >> >> Still, if SNIF is replacing a manufacturer proprietary call-home >> protocol, >> >> there could be advantages from having well reviewed code bases, and >> >> potentially an ecosystem of SNIF Providers that manufacturers could >> >> outsource >> >> >> to. Azure/Amazon/... could easily run such services. >> >> > I see two options - a SNIF server implemented by each vendor for their >> > own devices/services, or a bigger SNIF SaaS implemented by a trusted >> > provider, used by vendors. >> >>Yes, but what's the financial motive for this provider? > >(1) For a vendor to run their own SNIF server: market as a true auditable >end-to-end for IoT devices they offer. >(2) For a vendor using SNIF SaaS: market as (1) backed by {TrustedBigName} >(3) For a {TrustedBigName} to run SNIF SaaS: collect fees from (2) for using >their service and big name. > >As a matter of fact, SNIF relay is light on server resources. I've been >running it on a minimum DigitalOcean virtual server for months with more than >a dozen connectors, the server load is a fraction of a percent. Of course if >somebody connects IoT cameras they can generate some traffic, but IoT vendors >already handle it through their proprietary relays. > >> >> >> SNIF seems very much IPv4 NAT44 focused, and it could benefit from some >> >> understanding of IPv6 and IPv6-over-IPv4 technologies, >> particularly >> >> >> Teredo. >> >> > SNIF is not exactly focused on v4, it works fine with v6 as well. It's >> > designed to work around NAT, that's true. However, IPv6 networks may >> > pose issues too - firewalls etc, which will prevent to directly accept >> > incoming TCP on IPv6 address. >> >>Teredo could be used instead and allows the relay to be stateless and >>distributed, and devolves to ordinary IPv6 when it is present. > >Yes, but Teredo is IPv6 specific, the world is not strictly IPv6 yet. And it's >a system level solution, while SNIF works fine in a user space. > >> >> >> It clearly has to speak HTTPS only. >> >> > I specified HTTP because PKCS#10 and X.509 are inherently secure to be >> > sent over a plain connection. >> >>Yes, but there are privacy concerns which will become a pain, so better >>to just say HTTPS here. > >I respectfully disagree, still think HTTP is an easier answer for SNIF. The >problem with HTTPS is - SNIF relay (usually) routes https port to SNIF >connectors, and does not serve it within the server. Having a dedicated >hostname or an alternate port means than SNIF connectors need additional >configuration options, or additional discovery protocols. On the other hand, >HTTP allows to derive all API URLs deterministically from the CN. >I addressed the possible security concerns in more details and amended the >Security section in the draft. > > >> >> > The best option is the manufacturer I believe. The manufacturer can >> > have either their own SNIF server, or work with a trusted SaaS. This >> > way it's zero setup for the end user, and doesn't need any >> > infrastructure additions. >> >>Agreed, the manufacturer has to provision a credential. > >Yes I proposed some outlines in the security section, more detailed specs are >probably better to describe in a separate draft. > >> >> > Sure, elliptic curves are better, but some old school clients may have >> > problems with them. It may make sense to not mention the recommended >> > algorithm in the draft, and just to follow the CA's recommendations. >> >>ECDSA acceleration is pretty much ubiquitous, while RSA is not. > >Honestly I don't think acceleration is such a big deal, most of TLS job is >symmetric ciphers anyway. But I agree - it's better to follow the CA >suggestions and industry practices. > >> >> > I believe there's no security issue, as long as the CN entropy is >> sufficient. >> >> > I specified the X-SNIF-CN: as mandatory, and text/plain body as an >> > optional duplicate of it. To make it cleaner, I can remove the body >> > from the specs and say the response body is to be ignored. >> >>If both are present, and they don't match, then there is confusion. >>So just go with one. I think that it should actually be a JSON or CBOR >>payload return. > >Agreed, I removed the response body from the draft, going with the header. > > >> >> >> They *aren't* what IANA would call "IP protocols", which would be >> things >> >> like >> >> TCP, UDP, SCTP, ESP, ... >> >> >> Has IANA *already* registered port 7123 then? >> >> > It's not an IP protocol. It's a service that listens on TCP 7123, I >> > registered with IANA based on a previous version of the document, >> > before I turned it into an I-D. >> >>I think you should drop the "snif-*" sentence as it makes no sense. >>You have already allocated TCP port 7123 to the SNIF *service*, so >>that's great. > >It's actually called "Service Names" in IANA terminology, sorry for the >confusion. I updated in the draft. > > > >> >>-- >>] Never tell me the odds! | ipv6 mesh networks [ >>] Michael Richardson, Sandelman Software Works | IoT architect [ >>] [email protected] http://www.sandelman.ca/ | ruby on rails >>[ >> > >_______________________________________________ >Secdispatch mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/secdispatch >IMPORTANT NOTICE: The contents of this email and any attachments are >confidential and may also be privileged. If you are not the intended >recipient, please notify the sender immediately and do not disclose the >contents to any other person, use it for any purpose, or store or copy the >information in any medium. Thank you. > >_______________________________________________ >Secdispatch mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/secdispatch _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
