[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