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

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Feb 2022 14:15:46 -0500

TL;DR: Dispatch to IOTOPS.

Hi, I've reviewed your document at:

Jim Zubov <[email-masked]> wrote:
    > Please consider the following draft:
    > https://datatracker.ietf.org/doc/draft-zubov-snif/

I have three sections of comments: general ones, dispatch ones, and then some
detailed comments on the document/protocol itself.  My general comments are
intended to introduce the concept for who have not (yet?!) read the document.

GENERAL
-------
This seems to be solving a very similiar problem to the Manysecured SUIB
problem.  You can read more about SUIB at a document that is still evolving at:
      https://specs.manysecured.org/suib/SUIB-requirements

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.

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.
It does provide a useable name for the device, and it does provide for *an*
address which can be used to reach the device.  But, it essentially has
created a kind of secure TURN service which gives a global (HTTPS) name for a device,
allowing it to be reached globally.    There are some aspects of the SNIF
which seem to deal with ABUSE.

While the SNIF CA and Connection proxies could be run by a number of parties,
given that the devices need to have a pre-existing relationship with those
parties (and that provisioning of credential stage is out of scope according
to the document), it seems that it will only really be operated by the
manufacturer, or some large delegate like an ISP that sells IoT devices.
What would the economic argument/incentive for other parties to operate these
services?
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.

SNIF seems very much IPv4 NAT44 focused, and it could benefit from some
understanding of IPv6 and IPv6-over-IPv4 technologies, particularly Teredo.

DISPATCH COMMENTS
-----------------

There are a lot of issues that I have with the proposal that would need
significant work to document and/or sort out.  As such I would definitely
advise against AD sponsor.

This protocol is not really big enough to warrant it's own WG, although other
similiar sized protocols (such as ACME) have their own WG.  If ten people
from four different vendors showed up and wanted to work on this, then a new
WG might be reasonable.
Much of SNIF is about new variations of certificate enrollment.
Some of it is very similiar to draft-ietf-anima-brski-cloud.

If BEHAVE was still alive, dispatching there could make sense because it's a
also a new kind of TURN, and maybe it should just be a new variation.
Dispatch to ACME almost makes sense.
(To quote the _Broken Sword_ game: "That was almost a good idea")

It could be dispatched to ANIMA.  I don't think that it would make it through
ANIMA with the same look, but at least we have lots of RFC7030 expertise.

IOTOPS was chartered to do some IoT dispatch work, and it could be that this
document should go there.  It is not clear to me yet if SECDISPATCH has
the patience to understand the document well enough to make a decision.

DETAILED COMMENTS
-----------------

Section 2 will need a diagram for the Proxy, Relay, Connector, Client, CA.
I think that before introducing the components, a simpler walk through is
needed.

3.1: Connector speaks HTTP or HTTPS.
     It clearly has to speak HTTPS only.

     How does device learn their initUrl?
     If it is programmed into the device by the manufacturer, then basically
     it's the manufacturer's service.
     If it is provided by the end user, through an admin interface, then how
     is that interface secured?
     DHCP option?
     We have a multitude of onboarding protocols now, I suggest that
     extensions to a few of them be provided for here.

     For instance, in an RFC8995 BRSKI situation, the initURL, along with an
     optional trust anchor to validate it (if DNS-ID verification is a
     problem), could be provided in the voucher.  Of course, if one was doing
     BRSKI, then it might be better to just do BRSKI-CLOUD here.
     This flow:
     https://www.ietf.org/archive/id/draft-ietf-anima-brski-cloud-02.html#name-voucher-request-handled-by-
     is essentially exactly what is needed here.

3.2:
     "Any key algorithm acceptable by the CA can be used, generally RSA-4096 is recommended."
     I would not recommend RSA-4096.  Effective security of RSA keys does not
     go up linearly with size. 4096 bits just uses a lot of space for very
     little benefit.  ECDSA, EDDSA would be better recommendations.

     The Connector flow where it allocates a CN is essentially the CSRattrs
     problem that LAMPS is clarifying in RFC7030 with the
     https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030-csrattrs/
     which has been neglected since IETF112, but I hope will be adopted at IETF113.

3.3: generally, GET is a bad idea for something that allocates something.
     Either use X-SNIF-CN:, or the payload, not both.  DRY.
     text/plain is probably the wrong choice for a mime type here.

3.4: PUT is an interesting choice.  It's not wrong though.
     Having a 201 reply where one can collect a status report is nice.
     I wish that RFC7030 did that.

3.5: as I understand it, the certificate is actually retrived from the
     DN/dnsName that was allocated using http.
     That seems to imply that http can never be used with the device?
     (I don't think it should, but...)
     At least this should be in /.well-known.

section 4 deals with the relay protocol.
        I didn't look at that deeply at this.
        It seems pretty complex, and as long as this is greenfield, why not
        use HTTP/2 and/or QUIC so that multiple requests can be sent over a
        single pinhole?

This entire part is very very much IPv4 focused.
IPv6 devices shouldn't need any of this.

But, perhaps more to the point, UPnP pretty much already does this.
So does Teredo.

section 4.6 on ABUSE Management is an interesting addition.
This part should be coordinated against what DOTS WG has already built.
I found your security considerations section to be well written.

I'm not sure I understand the IANA registration of "snif", etc.
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?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Jim Zubov <[email-masked]>
Date: Wed, 09 Feb 2022 18:41:57 -0500

Thank You for the feedback Michael,

my comments are below.

(replying to all lists the response has been copied to, if it's a flooding issue - everyone pls lmk)

>      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

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 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.
The draft describes SNIF connection through a dedicated end-to-end relay (external IP), which may be used for local-to-local too. But I was also looking for possibilities of a true local connection - and I have 2 options -
* 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.
* 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 -
https://github.com/vesvault/VESmail-apple (vmVPN module)
https://github.com/vesvault/snif-tunl (IPv4 local terminator, required by the one above, can extend to v6)

> which seem to deal with ABUSE.

In fact, not just HTTPS, but any protocol over TLS - imaps, smtps etc, or any custom ports, as long as the connection is over TLS. In theory it's possible to extend to STARTTLS based protocols too.

> 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.

> 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.

>      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.

HTTP makes the management easier - the HTTP host is the base name of the CN which points to the CA Proxy, i specifically recommend using a wildcard CN in the Security section.

The CN Allocation request MAY be sent over plain HTTP too - the returned CN is uniquely generated, and is useless until the cert is issued to it. There's only one shot of uploading the CSR, if the intruder does it first - the SNIF Connector will get an error, and will have to hard reset and get another CN.

>      extensions to a few of them be provided for here.

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.

In case of a device with limited user interaction (as most IoT are), the initUrl will be unique per device, and contain a kind of private ID, to work in conjunction with a unique public ID in a link (QR code) given to the user. I outlined it in the Security section without excessive details, it might be a topic for a separate document.

Some dynamic extensions are definitely a possibility.

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.

>      which has been neglected since IETF112, but I hope will be adopted at

> IETF113.

Agreed, CSRattrs can be used. I just don't see anything besides CN that should be controlled by the CA Proxy, there are no other requirements on a CSR that SNIF Connector can benefit from accepting dynamically instead of being pre-set.

>      text/plain is probably the wrong choice for a mime type here.

The allocation returns a unique random CN, without obligations to ever issue a certificate to, but is a prerequisite for the CSR submission - e.g. https://snif.snif.xyz:4443/

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.

>      I wish that RFC7030 did that.

The point is - if the SNIF Connector gets 201 then it's ok to proceed. Otherwise - retry, and/or hard reset to get a new CN.

>      At least this should be in /.well-known.

The DNS points to the SNIF server (Relay / CA Proxy). Therefore, HTTP request goes to the server, and downloads the issued and cached cert (or 503 to try later). HTTP, or any other plain protocol, cannot be relayed to the device, at least within the SNIF paradigm.

The domain verification with the CA can be done either through HTTP or DNS, as the CA Proxy has control over both. In case of Let's Encrypt, a wildcard cert can only be verified with DNS.

>         single pinhole?

It could be, SNIF can be potentially extended to do it. My objective was to simplify the implementation of SNIF Connector on a device. Within the scope of the document, the SNIF Connector opens a Service Connection TCP, sends a plain SNIF ACCEPT, and hands the entire socket over off to the TLS server process. No multiplexing, less headache in many ways.

> So does Teredo.

In case of a clear static IPv6 you don't need SNIF. In real life the IoT device IP is likely to be dynamic, there might be firewalls that drop incoming SYN and whatnot. Relying on nothing but outgoing TCP connections is probably the safest way to deal with existing infrastructure, this is what SNIF is for.

Good to hear, thanks.

> 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.

>
>
> --
> Michael Richardson <[email-masked]>   . o O ( IPv6 IÃ¸T consulting
> )

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Feb 2022 13:02:48 -0500

> 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.

    > 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.

    > * 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.

    > 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?

    > 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.

    > sent over a plain connection.

Yes, but there are privacy concerns which will become a pain, so better to
just say HTTPS here.

    > 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.

    > 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.

    > 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.

    > 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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Jim Zubov <[email-masked]>
Date: Thu, 10 Feb 2022 18:21:58 -0500

Thanks for the feedback again, my comment are below.
I submitted a new version of the draft to reflect some changes.

>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.

>  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.

>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.

>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.

>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.

>Yes, but there are privacy concerns which will become a pain, so better to

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.

>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.

>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.

>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.

>You have already allocated TCP port 7123 to the SNIF *service*, so that's

It's actually called "Service Names" in IANA terminology, sorry for the confusion. I updated in the draft.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Feb 2022 10:36:15 +0000

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.

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.

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.
(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).
(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?

Ciao
Hannes

-----Original Message-----
From: Secdispatch <[email-masked]> On Behalf Of Jim Zubov
Sent: Friday, February 11, 2022 12:22 AM
To: [email-masked]; Michael Richardson <[email-masked]>; Jim Zubov <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF)

On February 10, 2022 1:02:48 PM EST, Michael Richardson <[email-masked]> wrote:
>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.

>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

>Yes, but there are privacy concerns which will become a pain, so better
>to just say HTTPS here.

>You have already allocated TCP port 7123 to the SNIF *service*, so
>that's great.

_______________________________________________
Secdispatch mailing list
[email-masked]
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.

---

From: Jim Zubov <[email-masked]>
Date: Wed, 23 Feb 2022 10:17:14 -0500

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

>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/a…

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.

>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.
>(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.

>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.

>Hannes

Any further questions/suggestions are welcome.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Feb 2022 10:37:46 +0000

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 <[email-masked]> On Behalf Of Jim Zubov
Sent: Wednesday, February 23, 2022 4:17 PM
To: [email-masked]; Hannes Tschofenig <[email-masked]>; Jim Zubov <[email-masked]>; [email-masked]; Michael Richardson <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Iotops] [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF)

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

>To: [email-masked]; Michael Richardson <[email-masked]>;
>Jim Zubov <[email-masked]>; [email-masked]; [email-masked]
>Subject: Re: [Secdispatch] I-D: Deploying Publicly Trusted TLS Servers
>on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF)
>
>>Yes, but there are privacy concerns which will become a pain, so
>>better to just say HTTPS here.
>

--
Iotops mailing list
[email-masked]
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.

---

From: Jim Zubov <[email-masked]>
Date: Thu, 24 Feb 2022 09:42:57 -0500

Thanks Hannes,
I just want to emphasize once again that the relay is end to end TLS.
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. 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.
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.