On Mon, Aug 11, 2025 at 08:14:16AM -0700, Wes Hardaker wrote:
> > This means the thermostat gets a message 'add @bob.example.com to the list
> > of
> > authorized users' and that is the point that the thermostat fetches the TLSA
> > record to get Bob's private root of trust. The Bob that is added is the Bob
> > whose
> > root was advertised at the moment the authorization was issued. The device
> > doesn't care about subsequent changes of control of the handle.
>
> And this is where the above breaks down... Currently with TLSA, the
> above means that bob is a permanent member of the group without another
> direct operation to explicitly remove them again.
>
> But you're right that if you ignore that and require an explicit
> removal, then you only need lookups done add addition/removal time. But
> that's a very different security posture than how DANE was designed.
Under appropriate conditions, this can be a reasonable model for
"disconnected" use. Then DNS is a key discovery, rather than a key
lookup service. Philososphically This may line up somewhat more with
OPENPGPKEY, than TLSA.
The main downside is that revocation by replacing or removing the key in
DNS is no longer effective. That's a feature and a bug, and the design
should take that into account. Explicit key refresh may be a partial
mitigation, or perhaps "opportustic" key refresh whenever the
connectivity is available, assuming that freshness takes priority over
risks of compromise of the DNS source. Various scenarios may see the
priorities differently.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
dane mailing list -- [email protected]
To unsubscribe send an email to [email protected]
