Subject: Re: [Dance] [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: 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.