Phillip Hallam-Baker <[email protected]> writes: > The concept of the DNS is that it is an infrastructure that resolves names to > services or hosts. The DNS name is the persistent identifier.
To be fair, that may have been the original intent but the new way is that it maps a name to "something", which used to be mostly for services and hosts. These days it maps names to many things, including keys of one form or another (hence DANE, SSHFP, ...) or even policies (DMARC, SPF, ...). > Once the name has been traded in for the public key, we don't need the name > any > more, the key is authoritative. Well, yes and no... the name still may indicate whether the key is meant to still be used and active. Some security systems (including DANE) expect that if the key should no longer be used for validation, it will be removed from the DNS and thus shouldn't be used any longer. > 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. -- Wes Hardaker USC/ISI _______________________________________________ dane mailing list -- [email protected] To unsubscribe send an email to [email protected]
