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

[Jim Zubov <[e-mail]>]

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