Limiting the Scope of the KEY Resource Record
draft-ietf-dnsext-restrict-key-for-dnssec-04.txt

	Dan Massey, Scott Rose
	IPSECKEY BOF 55th IETF
	Atlanta GA

KEY RR Restriction

	KEY RR now restricted to DNSSEC protocol only
		No Subtyping of KEY RR
		All other protocols (IPSEC, email, etc.) obsolete and must not be used to store key material
		All flags bits, except one, now obsolete
			“zone key” bit (bit 7 – backwards compatibility)
	Why?
		Avoid large keysets, especially at apex
		Avoid subtypes of KEY RR
			Including using SRV-like naming scheme
		Separate administration of DNSSEC and Application keys

Status of Draft and DNSSEC

	In RFC Editor’s Queue
		No RFC number yet.
	DNSSEC
		New version of DNS Security Specs in WG
		Focus on DNS only
			Not mentioning other applications/key distribution as a service of DNSSEC
			Not forbidding the storing of application key material in DNS either.

Lessons Learned from DNS KEY RR (Or:  Minefield Ahead!)

	Pitfalls to avoid when creating a new RR type to store application key material
		Avoid Subtypes
		Don’t assume DNSSEC is the right trust model
			Define and Justify why DNS and/or DNSSEC makes sense to use in an already existing trust model.
	Clearly state impact on the DNS
		Should be “minimal” (i.e. Just a data RR like TXT)
			Anything requiring a change will probably be a problem.
	Good idea to include someone with DNS experience to consult on these issues.