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

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)

>
> TL;DR: Dispatch to IOTOPS.
>
> Hi, I've reviewed your document at:
>
> Jim Zubov <[e-mail]> 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.

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

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

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.


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

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.

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


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

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.

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

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.

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

>

Some dynamic extensions are definitely a possibility.

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

>

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

>

Good to hear, thanks.

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

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 <[e-mail]>   . o O ( IPv6 IøT consulting
> )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>