[dns-operations] closest keys and validation policy

bmanning at vacation.karoshi.com bmanning at vacation.karoshi.com
Mon Jul 19 15:19:43 UTC 2010

On Mon, Jul 19, 2010 at 10:35:30AM +0100, Jim Reid wrote:
> 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.

	yeah... generally when employers hand you crypto tokens 
	for doing things like VPN connections, you know that dosen't
	scale at all.

> >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.

	'cept I don't trust ISC.  Don't use their TA. 
	I will trust the ICANN/Root TA, but its the last key I 
	want to use.

> 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.

	Money flows both ways.  And while not the best indicator of 
	trust, its a reliable clue.  Transitive Trust is problematic.


More information about the dns-operations mailing list