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

[Michael Richardson <[e-mail]>]

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.

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