Subject: Re: [Iotops] Secure browsing local web resources

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Dec 2021 19:28:28 -0500

sorry to pull an email thread out from a month ago.

Ash Wilson <ash.wilson=[email-masked]> wrote:
    > We had a brief discussion at IETF 110 in the DANISH BoF (which has evolved
    > into the DANCE WG) about how DNS-SD/mDNS might work to tie link-local
    > identities to DANE DNS records. This would give you the ability to have a
    > universal server identifier/public key in DNS which the IoT TLS server
    > could claim and prove to a client device. The downside here is that DANE is
    > not currently browser-supported, though it is supported in various TLS
    > libraries.

Leaving aside the implementation challenges (we can't even get LL-IPv6 into browsers...)

What exactly would you put into the certificate here?
How would the tie-in work?  I'm not actually sure I think we need DANE.

If one put ethernet addresses into the certificate, and one did traditional
SLAAC to derive L3 Link-Local addresses (for the device) from that, then it
would trivially (with current APIs) link getpeername(2) to what the browser
sees in the certificate.

There would be privacy implications doing this that would require RCM to fully
solve.

How would DANE help?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Nick Allott <[email-masked]>
Date: Fri, 24 Dec 2021 10:41:00 +0000

Following up on my earlier commitment to share drafts on the potential
solution space. (Apologies for delay: approvals took some time, plus just
had a dose of virus)

https://manysecured.org/drafts/specs/ManySecured-SUIB/problem-overview

On the above link please find the current draft documents that have been
worked on within the IOTSF/ManySecured community.

I must emphasise that this is work in progress. The intent of these
documents is to

 - better explain/communicate the technical aspects of the problem
 - explore what a solution might look like and the qualities it needs to
possess
 - move forward some technical solutions

We still believe this to be a problem of utmost importance: it is the de
facto standard method of provisioning/configuring home IOT devices and it
is inherently insecure.

Following on from the conversations at the IOTOPS meeting, if there are any
known solutions to the problem, it would be good to know. And/or any
mitigating mechanisms to reduce the exposure.

We suspect, the only real way so of solving this issue, is to create a new
class of browser, which has well defined semantics for securely negotiating
TLS sessions on local internet connection.
But to do this at scale and reliably, we need a different model for the
provisioning of local certificates, and new set of browser guidelines to
define how the browser interacts with the local certificate ecosystem.
(ie it seems clear the current CA/Browser guidelines are not designed for
this use case). But this is still a partially formed conjecture at this
stage.

The source markdown documents are available on this public repo:
https://github.com/TechWorksHub/ManySecured-WGs/tree/main/ManySecured-SUIB
(linked to in the the HTML documents)

What do people think?

Cheers

Nick

On Mon, 22 Nov 2021 at 10:30, Esko Dijk <[email-masked]> wrote:

> Hi Nick,
>
> Agree with the problem as stated in your email and slides. (The latter
> explore some interesting solutions.)
> A solution in IETF scope may be some class of "IoT" server certificate
> that is trusted only in link-local scope, also by browsers. (Trusted enough
> to allow the user to view the page.)
> This could be an IDevID-type certificate.
>
> For enhanced security the browser could even be instructed in some way (QR
> code? 4-letter code?) to temporarily trust all IDevID certificates from
> vendor X for the duration of the browser tab being open.
>
> regards
> Esko
>
> IoTconsultancy.nl  |  Email/Teams: [email-masked]
>
>
>
> -----Original Message-----
> From: Iotops <[email-masked]> On Behalf Of Nick Allott
> Sent: Friday, November 19, 2021 15:47
> To: [email-masked]
> Subject: [Iotops] Secure browsing local web resources
>
> Thanks for the opportunity to present last week. Pleased it generated some
> discussion! [1]. The slides [2] I note neglected to include the reference
> to the CA/Brower forum[3] guidelines (7.1.4.2.1) which help understand the
> problem.
>
> Accessing local web base resources locally and securely, we think is an
> important problem to address. The IETF community is better placed than
> most/all to qualify and refine this requirement and help develop and
> evaluate the potential solutions.
>
> These are the active questions we have, which it would be useful to get
> confirmed (or refuted)
>
> 1. There is a problem: there is a clearly defined issue.
> a) Bootstrapping a TLS connection between a browser and a local web
> resource (IOT or not) on local internet (reserved IP address/Private Use)
> is hard to do
> b) Given (a) sniffing administrative passwords for local resource (e.g.
> IOT), an otherwise intercepting traffic is relatively easy to do and
> therefore a serious internal threat
>
> 2. It's a pervasive problem: the problem currently manifests itself on
> many/most consumer routers and many/most IOT devices that connect via Wifi
> and/or cabled IP.
>
> 3. There is no known best practice for practically and securely
> authenticating local web clients against, local IP based IOT devices
>
> We would be delighted in ether outcome: either agreement in the statements
> above, or a clear refutation of any of the issues.
>
> We hope to publicise the internal document outlining a potential solution
> space next week. We are just cleaning the docs and making ready for
> comment. I will follow up with the links asap, which assuming there is
> agreement an issue exists - may help plant some seeds on how it can be
> addressed
>
>
> But in the interim, there are further comments/discussion that help
> calibrate the problem, that would be great.
>
> Also reminder, public facing paper on the problem [4]
>
> [1] https://jabber.ietf.org/jabber/logs/iotops/2021-11-12.html
> [2]
> https://datatracker.ietf.org/doc/slides-112-iotops-suib-browsing-local-web
> -resources-in-a-secure-usable-manner-iot-device-configuration-as-a-special
> -case/
> <https://datatracker.ietf.org/doc/slides-112-iotops-suib-browsing-local-web-resources-in-a-secure-usable-manner-iot-device-configuration-as-a-special-case/>
> [3] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf
> [4]
> https://manysecured.net/wp-content/uploads/2021/03/MS-Secure-Intranet-Brow
> ser-WG.pdf
> <https://manysecured.net/wp-content/uploads/2021/03/MS-Secure-Intranet-Browser-WG.pdf>
>
> Nick Allott
> nquiringminds
>
> --
> Iotops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iotops
>

---

From: Ash Wilson <[email-masked]>
Date: Fri, 24 Dec 2021 09:49:43 -0800

Hi Michael,

For a device with DANE ID a1b2c3._device.mfr.example, with an HTTPS service:

  mDNS Announce:
      The device announces its own IP at ${HASH}.local where ${HASH} is a
truncated hash of the DANE ID (using an approach like
https://datatracker.ietf.org/doc/html/rfc8162#section-3, but hashing the
entire DANE ID)

  IP address resolution:
      If there are no A or AAAA DNS records for a1b2c3._device.mfr.example,
the client device uses ${HASH}.local for IP address lookup.
      It may be worthwhile to signal via a TXT (or some other) record at
a1b2c3._device.mfr.example that the device is expected to announce using
this pattern over mDNS. Only use mDNS for IP lookup if the responsible
organization (domain owner) indicates such behavior is expected, and if
there is no conflicting SRV record configured.

  Establishing a connection:
      Client software establishes a TLS session with the device using the
IP address from mDNS, the DANE ID for SNI, and verifies the presented
server certificate against the TLSA record at a1b2c3._device.mfr.example.

It's worth noting that
https://datatracker.ietf.org/doc/html/rfc7673#section-4.1 describes what
might be an easier and more flexible way to convey the mDNS name, using an
SRV record, instead of computing the ${HASH}.local identifier within the
client software.

On Thu, Dec 23, 2021 at 4:28 PM Michael Richardson <[email-masked]>
wrote:

> Dance mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dance
>

-- 

*Ash Wilson * | Technical Director
*e:* [email-masked]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Dec 2021 16:19:41 -0500

> For a device with DANE ID a1b2c3._device.mfr.example, with an HTTPS

...

    > the client device uses ${HASH}.local for IP address lookup.

My reading of RFC6763 suggests that the lookup for ${HASH}.local could return
a SRV record specifying where to connect, and the reference could be a FQDN
("a1b2c3._device.mfr.example"), and there could be a AAAA (A) RR returned as
additional data.   I investigated trying to configure this, but no software I
found could comprehend it without a lot of rework.

    > server certificate against the TLSA record at a1b2c3._device.mfr.example.

So, I think that you've just described an entirely new RFC6125 mechanism.
This is where I think that we get into trouble.

I'm not I see what DANE contributes anything here.  Wouldn't everything be
the same if the server certificate was transmitted inband?  If the client
knows to map the ${HASH}.local to a1b2c3._device.mfr.example, then aren't we done?

    > SRV record, instead of computing the ${HASH}.local identifier within the

I wonder if I'm describing the same thing above.