[dns-operations] closest keys and validation policy
Jim Reid
jim at rfc1035.com
Mon Jul 19 09:35:30 UTC 2010
On 19 Jul 2010, at 05:31, bmanning at vacation.karoshi.com wrote:
> nothing precludes _anyone_ from having a "tainted" vector, be it
> my ISP, my University, my clients, my Government, or their
> contractors...
>
> for me, the root key is the last bastion, the least trustworthy key.
Fine. That's your choice. This style of verification might even scale
for all the folk you do business with. Though I doubt it. And I'm not
sure the examples above will be issuing crypto tokens that are managed
and scrutinised to the same extent as the root key. Your mileage may
vary.
> but if I am paying them money for service, there is a standard of care
> that is usually bound to some contractual (or similar) vehicle.
So where is this contractual vehicle between say you and ISC whenever
you validate against their TA for some name that a third party has
lodged there? The transitive trust issues make verification rather
awkwared too. Not that I'm suggesting that ISC would be doing anything
dodgy. Though when there are more (ad-hoc) TAs in the chain, it is
harder to verify things.
BTW, you seem to be saying that "follow the money" is a good approach
towards a security policy. If so, that tends to point towards DNSSEC
validation which flows to the root. ie You pay your registrar to send
your KSK. Registrar pays the registry to generate and sign a DS record
for that. Registry has a contractual vehicle with parent to get a DS
record for its KSK. Repeat as necessary until we hit the root.
More information about the dns-operations
mailing list