On Mon, Aug 11, 2025 at 11:14 AM Wes Hardaker <[email protected]> wrote:
> Phillip Hallam-Baker <[email protected]> writes: > > > 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. > It is a different model, so it is not DANCE, possibly not DANE either. It is certainly a valid model and almost certainly aligns better with user expectations. If I add @alice.gmail.com to the list of people allowed to control my HVAC, I don't expect that authorization to change if Google reassign the handle. What I was concerned about was the possibility that 24 months from now, we run into a situation where we discover that the way we want to use TLS Client Auth with handles makes us wish we had done the DANCE work slightly differently. Establishing that it is a completely different model means we don't have to worry about that.
_______________________________________________ dane mailing list -- [email protected] To unsubscribe send an email to [email protected]
