Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF)

[Hannes Tschofenig <[e-mail]>]

Hi Jim,

Good discussion.

Based on what you wrote below I was actually wondering if the use of TLS or DTLS at the application layer wouldn’t even be a better solution. This way you could re-use an existing IoT device management infrastructure (which may be based on HTTP but will most likely use MQTT or CoAP) and then you add the end-to-end security on top of it for those cases where you need it. You then also do not have to worry about deploying a separate proxy.

Here is some information about this approach:
https://datatracker.ietf.org/doc/html/draft-friel-tls-atls-05

Ciao
Hannes

From: Secdispatch <[e-mail]> On Behalf Of Jim Zubov
Sent: Saturday, March 5, 2022 2:10 AM
To: [e-mail]; Hannes Tschofenig <[e-mail]>; Jim Zubov <[e-mail]>; [e-mail]; Michael Richardson <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Secdispatch] [Iotops] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF)

Hi Hannes,

Good overview of strategic approaches, let me add another dimension -
- Can the relay access any information communicated between the device and the user,
- If the answer is _no_ - can the user or some independent party verify the validity of such claim.

In case of SNIF, the setup consists of
- an IoT device capable of serving HTTPS (user friendly pages or an API), running a SNIF connector,
- a web based device manager on the user side that works with the device's HTTPS content (and expects a trusted cert),
- a SNIF relay / CA proxy server in the cloud,
- potentially, an independent observer that watches TLS transparency logs and raises an alert if any duplicate certs are found for the CNs issued by the CA proxy.

This way, the IoT device owns the private key, and there's a proof through the public trust PKI that the device manager is communicating to the authentic device.
In case if the public CA trust is not enough, the device manager can examine the public key on the cert on every connection (should be possible to do with the Forge project in regular js), and raise an alert if the key is changed (just like ssh does).

SNIF is the answer for a smart home, a security cam, or any other private IoT you don't want anybody to sniff on (pun intended).

If you're deploying a device accessable to a large group, like a public webcam, SNIF might be not a good option, it might be better to have an intermidiate proxy that handles all traffic without choking the device. But, end-to-end privacy is a lesser concern in such case.

Regarding the conversion of any existing devices to SNIF -
- serve the content on the device over HTTPS or local plain HTTP, whether it's a web page, a video stream or an API, listening on a local port (say 443)
- run a SNIF connector process to maintain the cert and to relay to incoming SNIF connections to the local port.
On March 3, 2022 6:18:48 AM EST, Hannes Tschofenig <[e-mail]<mailto:[e-mail]>> wrote:
Hi Jim,

Thanks for your response.

> There are some IoT management solutions on the market, both open source and proprietary, but as far as I can tell none of them fully follows the end to end paradigm.
[Hannes] It depends what you call end-to-end. As an IoT service provider you have to make a few decisions about how to manage and deploy IoT devices. Broadly speaking, you have three options:

  *   You  seek out to a third party to manage your devices. Needless to say that you should pick a company that you feel comfortable with. They will manage your devices and they will also offer ways to store the data obtained from the devices, to manage and distribute firmware updates, and even to perform analysis of the data (machine learning). Then, you can typically connect backend application servers to the device management offering. Of course, the details vary a lot with what you are actually doing as an IoT service provider with the IoT devices and the data.
  *   You get the software from a provider and you manage the devices on your own. This is often the case when you want to deploy an on-premise solution. Here you have to trust the provider of the device management software that the code is correct and does what it is supposed to do. In some cases you not only get the binary but also the source code. In theory, you could check what code is actually running (although I doubt that anyone really checks).
  *   Finally, you build your own device management solution (often using available open source software).
In practice, I have also seen a combination of the variants above. For example, I have seen a case where the devices were managed by a third party but the video stream of the surveillance camera was sent directly to a dedicated server managed by the IoT service provider. (There were also various techniques to prevent modifications to the device to have the video stream re-directed or the credentials changes but I think you get the idea.) The communication model there was a bit different than yours because the client initiated the communication with the video server. Hence, there was no issue with running a TLS server on the device.
On top of this, it is also common to provide special security protection for selected data. For example, firmware updates are signed by party different from the company offering the device management solution. They are, for example, singed by the company developing the code. They are still distributed by the device management infrastructure and hence you have to rely on the distribution of them but there is no chance for the device management provider to inject malicious code into the device.
From what I am seeing, the first deployment model is very popular. The approach of “designing your own solution” was popular in the early days because companies were given the impression that this IoT stuff is so simple that you can put a solution together in a weekend. It turned out that this is not quite the case (if you have a larger number of devices). Many IoT service providers also need help designing the entire solution, also the solution on the IoT device itself.
How does your solution fit into this picture?
> I believe it's worth having a universal cross-vendor solution that handles SNIF device onboarding, maintains the credentials in a local secure storage, and consolidates https based management interface hosted by individual devices through SNIF.
[Hannes] There is definitely a lot of excitement when it comes to the development of device onboarding solutions. I have to trust you that there is further interest for solutions because I haven’t checked.

> The requirements for such solution is a topic for a separate draft, although I already outlined the possible secure onboarding process in the security section.
I will re-read your security consideration section again.

Note that I am certainly not against your solution. If your approach has success, kudos to you.

Ciao
Hannes

On February 24, 2022 5:37:46 AM EST, Hannes Tschofenig <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jim,

Thanks for the quick response. The link to your website is helpful. I now understood that you would also relay the communication through the proxy, which deals with the IoT device being behind a NAT and/or firewall if the IoT device keeps the connection alive.

I wonder whether you have considered to re-use an existing device management solutions since those is widely deployed today?

Ciao
Hannes

-----Original Message-----
From: Iotops <[e-mail]<mailto:[e-mail]>> On Behalf Of Jim Zubov
Sent: Wednesday, February 23, 2022 4:17 PM
To: [e-mail]<mailto:[e-mail]>; Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>; Jim Zubov <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Michael Richardson <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF)

Thank You for your feedback Hannes, I addressed the comments below -

On February 23, 2022 5:36:15 AM EST, Hannes Tschofenig <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Jim Zubov
Sent: Friday, February 11, 2022 12:22 AM
To: [e-mail]<mailto:[e-mail]>; Michael Richardson <[e-mail]<mailto:[e-mail]>>;
Jim Zubov <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:

Jim Zubov <[e-mail]<mailto:[e-mail]>> 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   [
]     [e-mail]<mailto:[e-mail]>  http://www.sandelman.ca/        |   ruby on rails    [

________________________________

Secdispatch mailing list
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/secdispatch

--
Iotops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/iotops
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.
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.
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.