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

From: Jim Zubov <[email-masked]>
Date: Tue, 08 Feb 2022 13:17:28 -0500

Please consider the following draft:

https://datatracker.ietf.org/doc/draft-zubov-snif/

The document describes a set of protocols for publicly trusted serverless TLS that can be used as an end-to-end IoT security solution.

The solution had been tested in pre-production. The complete source code is in the public domain -

https://github.com/vesvault/snif

Any feedback, suggestions, and recommendations of an IETF group adoption are welcome.

Thank You -

Jim Zubov
VESvault Corp
CTO / Co-founder

---

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:

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Feb 2022 12:05:53 -0800

Document: draft-zubov-snif-04.txt

OVERALL
As I understand it the problem statement here is that you
have a back-end IoT server which is not publicly addressable
and you want to have a front-end proxy server which:

1. Assigns the back-end-server a hostname

2. Acquires publicly available WebPKI certificates on its
   behalf

3. Serves as a reverse proxy for the server at the TCP
   layer (and presumably eventually at the UDP layer).

The problem of acquiring WebPKI certificates for non-publicly
addressable devices is a pretty common one and applies to
a number of enterprise use cases, not just WebPKI.

However, it seems to me that your situation is different because you
want the device to be accessible, it just isn't publicly
addressable. This suggests to me that there is a simpler approach:

- When a device first connects to the proxy, assign it a
  hostname and establish a credential (e.g., a random
  key) bound to the hostname (effectively #1 above)

- Allow the device to connect to the proxy and authenticate with the
  credential and then route any TLS or HTTP connections to the
  hostname to that device (a generalization of #3).

If you just do this, then you shouldn't need any other mechanism
because the device will be able to fulfill the ordinary ACME HTTP
Challenge (RFC 8555; S 8.3) and the ALPN challenge (RFC 8737) without
any additional effort by the proxy. In particular, the proxy will
not need to engage with ACME because the back-end server can
do that.

Second, I don't think you need to define a new proxy protocol. While
MASQUE isn't currently specified for this kind of server application,
it seems like a natural extension and MASQUE would handle all the
transport mechanics for you, thus making life a lot simpler.

DETAILED COMMENTS
A number of the design choices here seem suboptimal. These would
mostly go away if you adopted the strategy I propose above. However,
I note them in case you do not do so.

* If I am reading this protocol correctly, there is no way to
  change the private key of a server in a given name. If that's
  correct, it seems suboptimal.

* It seems like you are establishing a new TCP connection to
  the device for each incoming TCP connection. That is not
  going to have great performance. I would instead mux all
  the data over a single connection (see MASQUE, supra).

* It seems like you are having the relay connect to the device.
  That is going to be a problem if the device is behind a
  NAT or any kind of stateful inspection filter. Instead,
  I would have all connections be outgoing.

* Requiring the Relay to validate the server's TLS certificate,
  as defined in S 4.2, makes the Relay much more complicated
  as it has to have a WebPKI stack in it.

I also, I don't understand this text:

   Since each certificate issued by a CA remains on the certificate
   transparency public records, it is RECOMMENDED for SNIF CA Proxy to
   only issue Certificates with a wildcard CN.  This way, the actual
   Connector's hostname (Section 3.2) will not be listed on the public
   records.

Can you provide an example of what you mean here? If the Connectors
are named a.example.com, b.example.com, and c.example.com, you obviously
cannot issue any of them *.example.com. OTOH, if you have them have
<something>.a.example.com and <something-else>.b.example.com, then
how does it help to issue *.a.example.com?

SECDISPATCH QUESTIONS
I think the next steps here are to resolve what problem is being
solved. In particular, if what I propose above will work, then
this should go to MASQUE with a limited scope of defining incoming
connections. If not, then I think we need to get clearer on why
it won't.

-Ekr

On Tue, Feb 8, 2022 at 10:18 AM Jim Zubov <[email-masked]>
wrote:

> The document describes a set of protocols for publicly trusted serverless
> TLS that can be used as an end-to-end IoT security solution.
>

---

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

Thank You for the feedback Eric,
My comments are below -

>   layer (and presumably eventually at the UDP layer).

A clarification on #3 - the SNIF relay relays the traffic on a TCP+TLS socket (in theory also extendable to UDP+DTLS) based on the SNI record in the client's handshake. From the client's point of view, the SNIF relay responds like a regular TLS server, while all the traffic is actually being relayed from/to the SNIF connector on the device.

>  hostname to that device (a generalization of #3).

I think this approach misses the most important point of SNIF - end-to-end. The SNIF relay doesn't have access to any private keys in principle, thus it acts as a dumb TLS relay without being able to access the payload.

>not need to engage with ACME because the back-end server can

ALPN involves communications to the target hostname using a self-signed certificate. SNIF relay is designed to not allow any self-signed, or otherwise not publicly trusted, certificates, it makes security audit a whole lot easier. Therefore, a trusted certificate needs to be negotiated through the CA proxy (or by other means) before being able to accept any relayed connections to the hostname.

>transport mechanics for you, thus making life a lot simpler.

The reason I use a separate TCP socket for each connection is to simplify the implementation of SNIF connector in conjunction with a server process on the IoT device. Using snif-srv, the connector opens a TCP socket, sends a SNIF ACCEPT message in plain text, and immediately hands the socket off to the process which will start TLS negotiation as a server peer, just like a regular server would do after accepting the socket. It's possible to design the control and multiple service connections to be multiplexed over QUIC, and use a software demux, and possibly fifos, on the connector side to interact with the server processes, but I believe separate TCPs is a cleaner answer in a resource constrained IoT environment. 

>  correct, it seems suboptimal.

The private key is regenerated when you hard reset the device, along with allocating a new CN. The former CN gets permanently retired. The rule is - 1 CN == 1 private key. It's for the security audit purpose - if you ever find certs with same or overlapping CNs but different public keys - the CA proxy is permanently compromised and cannot be trusted anymore.

>  the data over a single connection (see MASQUE, supra).

See comments above regarding multiplexing.

>  I would have all connections be outgoing.

No. All connections are outgoing from the device. Works fine with NAT and (reasonable) firewalls, I have a pre-production instance that I'm actually using to send this email.

>  as it has to have a WebPKI stack in it.

The relay runs on a server, Linux usually. It's not a problem to validate a certificate on a Linux server, you have PKI roots in any standard installation.

>how does it help to issue *.a.example.com?

A real example:
CN = *.snif-054e2fa720a6-7d8cf7d2.snif.xyz
Hostname = rf205699c9be3.snif-054e2fa720a6-7d8cf7d2.snif.xyz

The CN is listed on public transparency logs, the hostname is not. It's an extra step to safeguard the hostname from DoS attempts.

>connections. If not, then I think we need to get clearer on why

I still doubt the relevance of MASQUE, see comments above.

Any further comments are welcome.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Feb 2022 16:10:25 -0800

On Thu, Feb 24, 2022 at 3:22 PM Jim Zubov <[email-masked]>
wrote:

> A clarification on #3 - the SNIF relay relays the traffic on a TCP+TLS
> socket (in theory also extendable to UDP+DTLS) based on the SNI record in
> the client's handshake. From the client's point of view, the SNIF relay
> responds like a regular TLS server, while all the traffic is actually being
> relayed from/to the SNIF connector on the device.
>

Yes, I understand this. That's why I said "at the TCP layer"/

> I think this approach misses the most important point of SNIF -
> end-to-end. The SNIF relay doesn't have access to any private keys in
> principle, thus it acts as a dumb TLS relay without being able to access
> the payload.
>

What I am proposing also has this property.

- For TLS, the proxy behaves as in your document, switching on SNI (though
not validating the certificate) and forwarding the encrypted data.
- For HTTP, the proxy behaves much the same way but switches on the Host:
header.

Therefore it is end-to-end for any encrypted traffic.

> ALPN involves communications to the target hostname using a self-signed
> certificate. SNIF relay is designed to not allow any self-signed, or
> otherwise not publicly trusted, certificates, it makes security audit a
> whole lot easier. Therefore, a trusted certificate needs to be negotiated
> through the CA proxy (or by other means) before being able to accept any
> relayed connections to the hostname.
>

I understand that this is part of your design, but I don't see that it
provides much security value. Because the proxy assigns the hostnames, it
already knows which IoT device is associated with which hostname, so it can
use that information directly without having to examine the server's
certificate. Regardless, you could use the HTTP ACME Challenge without
allowing self-signed certs.

> The reason I use a separate TCP socket for each connection is to simplify
> the implementation of SNIF connector in conjunction with a server process
> on the IoT device. Using snif-srv, the connector opens a TCP socket, sends
> a SNIF ACCEPT message in plain text, and immediately hands the socket off
> to the process which will start TLS negotiation as a server peer, just like
> a regular server would do after accepting the socket. It's possible to
> design the control and multiple service connections to be multiplexed over
> QUIC, and use a software demux, and possibly fifos, on the connector side
> to interact with the server processes, but I believe separate TCPs is a
> cleaner answer in a resource constrained IoT environment.
>

Hmm... It's not clear to me why you think that this uses fewer resources.
Can you explain why you think that?

> The private key is regenerated when you hard reset the device, along with
> allocating a new CN. The former CN gets permanently retired. The rule is -
> 1 CN == 1 private key. It's for the security audit purpose - if you ever
> find certs with same or overlapping CNs but different public keys - the CA
> proxy is permanently compromised and cannot be trusted anymore.
>

This seems like an unfortunate set of properties, for several reasons:

1. You then need to disseminate new domain names if you ever want to change
your key.
2. It means you can't have two keys for the same server name, so (for
instance) you can't easily change from RSA to ECDSA.

Of course you could have "a.b.example.com" and "c.b.example.com" and issue
two certificates with "*.b.example.com" but now you are back to the same
problem of two keys with one name.

Incidentally, it's not clear to me that this inference about the CA proxy
is correct. We know that it is possible under certain conditions to use
network-level attacks to get certificates misissued. In this case, you
could have two certificates for one name with no malfeasance by the proxy.

> See comments above regarding multiplexing.

I don't really agree, but I don't think we can defer this point.

> No. All connections are outgoing from the device. Works fine with NAT and
> (reasonable) firewalls, I have a pre-production instance that I'm actually
> using to send this email.
>

OK. This was not clear to me.

> The relay runs on a server, Linux usually. It's not a problem to validate
> a certificate on a Linux server, you have PKI roots in any standard
> installation.
>

It's certainly more work to validate than not. For instance, how do you
handle revocation?

> The CN is listed on public transparency logs, the hostname is not. It's an
> extra step to safeguard the hostname from DoS attempts.
>

Thanks for the explanation.

-Ekr

---

From: Jim Zubov <[email-masked]>
Date: Thu, 24 Feb 2022 22:22:23 -0500

>Therefore it is end-to-end for any encrypted traffic.

Basically, everything boils down to 2 questions -
1. who has access to the private key,
2. who interacts with the CA to issue the cert

When the solution is end-to-end - the answer to (1) is always - only the device itself.
Let's review (2) assuming the CA speaks ACME. There are 3 common challenge types - HTTP, DNS and ALPN.
HTTP: Need to either relay plain HTTP from/to the device, or the proxy to serve HTTP. 
DNS: Need to either relay DNS from/to the device, or the proxy to serve DNS.
ALPN: Need to either relay TLS to a device with a self-signed cert, authenticated by means other than the cert, or the proxy to route specific hostname to TLS with a self-signed cert hosted by the proxy itself.
I follow simple security rules in SNIF design which I believe are reasonable - the control connection MUST present a valid certificate that matches the hostname, and the service connection MUST be TLS with the same certificate. According to these rules, plain HTTP is out, self-signed cert is out, relayed DNS would involve some new protocol layer.
I believe the answer converges on the proxy serving the challenge, either HTTP or DNS. And the way to submit a CSR is to generate it on the device and pass it to the proxy, so the proxy initiates and completes ACME challenge without involving the device in this process. The proxy receives and caches the trusted cert once it's issued, and the device downloads it. Similarly, the renewals are handled by the proxy using the previously cached CSR.
As an additional benefit of such design, the proxy may switch between CAs, or use any applicable protocols, whether ACME or something else, without any modification to the SNIF connector on the device.
And, I don't specify relaying plain HTTP through SNIF - it's possible in theory based on the Host header, but it's apriori not end-to-end, not much useful it today's world, and using it for ACME challenge involves designing additional mechanisms and violating the paradigms, as I mentioned earlier.

>allowing self-signed certs.

Yes, the proxy knows the hostname. But it doesn't have the private key, thus cannot use the cert. And if it issues a duplicate cert - it's auditable through the transparency logs (more on it later).
As for the proxy knowing the identity of the IoT device - it depends on how the initUrl and the cert issue authorization are implemented, I left it to the liberty of the implementor in the draft.

>Can you explain why you think that?

Sure. TCP has been around for ~50 years, is implemented in every modern OS, has been tested, refined and optimized for decades.
QUIC, on the other side, is still one foot in a petri dish. No disrespect here, but a TCP socket is a standard OS call while QUIC needs libraries to be supported, and either more libraries to route it to a socket/fd like fifos, or more libraries to handle the stream outside of a normal socket by a server process. I believe it makes sense to stick with a lightweight and reliable solution. The benefit of QUIC that I see is less stress on a NAT router, but multiple TCP sockets work just fine in the wild, I've been testing SNIF for months now.

>1. You then need to disseminate new domain names if you ever want to change

If the IoT device has an interactive browser - it's simple. If it doesn't - the onboarding is outlined in the security section, and is the topic of my next draft in more details.

>instance) you can't easily change from RSA to ECDSA.

If you want to experiment with algorithms - hard reset the device to rekey it. I believe makes sense. And, a combo RSA+EC is always an option.

>could have two certificates for one name with no malfeasance by the proxy.

When any duplicate CN is detected - raise an alert, investigate, revoke wrong certs, keep a record of the case.
If any new duplicates are detected - wash, rinse, repeat.
But if the proxy is compromised too often, whether for network reasons or not - it's a lousy proxy that cannot be trusted, hope you agree.

>It's certainly more work to validate than not. For instance, how do you

OCSP. To save resources, the SNIF relay may require connectors to staple OCSP, and reject otherwise.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Feb 2022 19:57:57 -0800

Hi Jim,

I'm going to respond to this message, but I don't think we're saying much
new
here, so I'll probably stop after that. There will be plenty of time to
discuss
disposition during the SECDISPATCH meeting.

> DNS: Need to either relay DNS from/to the device, or the proxy to serve

Or to have the proxy *configure* the DNS (which it will have to anyway,
because it controls the zone) but we can ignore that for the moment, as I
agree that we want to support non-DNS challenge types.

ALPN: Need to either relay TLS to a device with a self-signed cert,
> authenticated by means other than the cert, or the proxy to route specific
> hostname to TLS with a self-signed cert hosted by the proxy itself.
>
I follow simple security rules in SNIF design which I believe are
> reasonable - the control connection MUST present a valid certificate that
> matches the hostname, and the service connection MUST be TLS with the same
> certificate. According to these rules, plain HTTP is out, self-signed cert
> is out, relayed DNS would involve some new protocol layer.
>

Yes but my point is that these rules are to some extent arbitrary and they
result in a lot of complexity in the rest of the system. And if you relax
them, then you are left with a simple proxy system that seems to have
roughly the same security properties. So I think you need a stronger
argument than that these rules are reasonable. Rather, you need to argue
that they produce a better system, which I don't see you doing here. The
only real benefit I see you list is:

> As an additional benefit of such design, the proxy may switch between
CAs, or use any applicable protocols, whether ACME or something else,
without any modification to the SNIF connector on the device.

It's not clear to me that this is an advantage. It seems to me one could
just as easily argue it was a disadvantage because it makes it impossible
for the device to select its own CA and ACME methods.

> Yes, the proxy knows the hostname. But it doesn't have the private key,
> thus cannot use the cert. And if it issues a duplicate cert - it's
> auditable through the transparency logs (more on it later).
> As for the proxy knowing the identity of the IoT device - it depends on
> how the initUrl and the cert issue authorization are implemented, I left it
> to the liberty of the implementor in the draft.

I think perhaps you're misunderstanding me. As far as I can tell, there are
only two reasons for the proxy to look at the data coming to it at all:

1. To route to the right device via the SNI
2. To authenticate that the device it is routing to is the correct one
authorized for that name (and hence associated with the SNI).

My point is that (2) can be just as handily done by having the device
authenticate to the proxy via some non-certificate mechanism: the proxy
doesn't need to authenticate the device via the WebPKI because it knows a
priori which device has which name. The consequence of that change is that
the proxy need not do any TLS cert validation and can simply switch on SNI
without looking at the rest of the handshake.

> Sure. TCP has been around for ~50 years, is implemented in every modern
> OS, has been tested, refined and optimized for decades.
> QUIC, on the other side, is still one foot in a petri dish. No disrespect
> here, but a TCP socket is a standard OS call while QUIC needs libraries to
> be supported, and either more libraries to route it to a socket/fd like
> fifos, or more libraries to handle the stream outside of a normal socket by
> a server process. I believe it makes sense to stick with a lightweight and
> reliable solution. The benefit of QUIC that I see is less stress on a NAT
> router, but multiple TCP sockets work just fine in the wild, I've been
> testing SNIF for months now.
>

I would make two points here:

1. MASQUE is specified to work over H2, not just QUIC. H2 is very widely
used, so I don't think there's much concern about stability.
2. The Internet is a complicated place and just because you are not seeing
issues in your environment does not mean that there will not be issues in
others.

> If you want to experiment with algorithms - hard reset the device to rekey
> it. I believe makes sense. And, a combo RSA+EC is always an option.
>

This is inconsistent with essentially all modern TLS practice for upgrading,
which is to have the server able to run multiple algorithm profiles and
have the client and server negotiate an acceptable intersection. That
seems like a big regression to take, and will create real interop issues
during periods of transition, for instance, when some clients only
support A and some support A+B.

I'm not sure what you mean by "combo RSA + EC". It's true that you
can run RSA with EC key establishment, but what I'm talking about is
having both an RSA and an EC certificate. To the best of my knowledge
it is not possible to get a WebPKI certificate with both algorithms and it's
very unclear what the semantics of such a certificate would be.

I'm going to stop here because I don't think the rest of this is that useful
to try to nail down at this time.

-Ekr