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

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.

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

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

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

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

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

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

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

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