< draft-ietf-dnsop-delegation-only-00.txt		draft-ietf-dnsop-delegation-only-01.txt >
	DNSOP P. Wouters		DNSOP P. Wouters
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Updates: 4035 (if approved) W. Hardaker		Updates: 4035 (if approved) W. Hardaker
	Intended status: Informational USC/ISI		Intended status: Informational USC/ISI
	Expires: November 7, 2020 May 6, 2020		Expires: January 14, 2021 July 13, 2020
	The DELEGATION_ONLY DNSKEY flag		The DELEGATION_ONLY DNSKEY flag
	draft-ietf-dnsop-delegation-only-00		draft-ietf-dnsop-delegation-only-01
	Abstract		Abstract
	This document introduces a new DNSKEY flag called DELEGATION_ONLY		This document introduces a new DNSKEY flag called DELEGATION_ONLY
	that indicates that the particular zone will never sign zone data		that indicates that this zone will only produce delegation responses
	across a label. That is, every label (dot) underneath is considered		for data outside of its own apex (or _underscore labels). That is,
	a zone cut and must have its own (signed) delegation. Additionally,		the Answer Section for queries that do not involve the apex (or
	it indicates the zone is expecting its parent to never bypass or		_underscore labels) of the zone is empty, and only glue records in
	override the zone. DNSSEC Validating Resolvers can use this flag to		the Authority Section and Additional Section will be acceptable data
	mark any data that violates the DELEGATION_ONLY policy as BOGUS.		in the response message. Additionally, it indicates that it is not
			expected that the parent of this delegation-only zone bypasses or
			removes the delegation to this zone. DNSSEC Validating Resolvers can
			use this flag to mark any data that violates the DELEGATION_ONLY
			policy as Bogus.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 7, 2020.		This Internet-Draft will expire on January 14, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 48 ¶
	create an hierarchical trust base with the DNSSEC root public keys at		create an hierarchical trust base with the DNSSEC root public keys at
	the top, followed by Top Level domain (TLD) keys one level		the top, followed by Top Level domain (TLD) keys one level
	underneath. While the root and most TLD zones are assumed to be		underneath. While the root and most TLD zones are assumed to be
	exclusively delegation-only zones, there is currently no		exclusively delegation-only zones, there is currently no
	interoperable and automatable mechanism for auditing these zones to		interoperable and automatable mechanism for auditing these zones to
	ensure they behave as a delegation-only zone. This creates a target		ensure they behave as a delegation-only zone. This creates a target
	for malicious use of these zones - either by their owners or through		for malicious use of these zones - either by their owners or through
	coercion.		coercion.
	This document defines a mechanism for delegation-only zone owners to		This document defines a mechanism for delegation-only zone owners to
	create a DNSKEY that indicate they will only delegate the remainder		create a DNSKEY that indicates it will only delegate the remainder of
	of the DNS tree to lower-level zones. This allows for easier		the DNS tree to lower-level zones. This allows for easier delegation
	delegation policy verification and logging and auditing of DNS		policy verification and logging and auditing of DNS responses served
	responses served by their infrastructure.		by their infrastructure.
	Specifically, this document introduces a new DNSKEY flag allowing		Specifically, this document introduces a new DNSKEY flag allowing
	zone owners to commit to only signing records relating to delegation.		zone owners to commit to only signing records relating to delegation.
	If a DNSSEC validator discovers any non-delegation zone data signed		If a DNSSEC validator discovers any non-delegation zone data signed
	by a flagged key, this data can be interpreted as BOGUS.		by a flagged key, this data can be interpreted as Bogus.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. The Deep Signing problem		3. The Deep Signing problem
	The hierarchical model of DNS and DNSSEC ([RFC1034], [RFC1035],		The hierarchical model of DNS and DNSSEC ([RFC1034], [RFC1035],
	[RFC4033], [RFC4034] and [RFC4035]) comes with the property that a		[RFC4033], [RFC4034] and [RFC4035]) comes with the property that a
	zone at one point in the hierarchy can define, and therefor override,		zone at one point in the hierarchy can define, and therefor override,
	everything below it in the DNS tree. And this is possible to achieve		everything below it in the DNS tree. And this is possible to achieve
	on a per-client basis.		on a per-client basis.
	For example, the owner of the DNSSEC root key could generate a		For example, the owner of the DNSSEC root key could generate a
	specially crafted zone file that ignores the intended NS records for		specially crafted zone file that ignores the intended NS records for
	".org" and "example.org". It could place a AAAA record for		".org" and "example.org". It could place an AAAA record for
	"www.example.org" directly into the specially crafted zone, with a		"www.example.org" directly into the specially crafted root zone, with
	corresponding RRSIG signed by the root DNSKEY itself. Validating		a corresponding RRSIG signed by the root DNSKEY itself. Validating
	resolvers would find this record perfectly acceptable, as it was		resolvers would find this record perfectly acceptable, as it was
	signed by a key within the proper chain of trust (in this case, a		signed by a key within the proper chain of trust (in this case, a
	root DNSKEY). This specially crafted zone could then even be served		root DNSKEY). This specially crafted zone could then even be served
	to specific clients in an effort to subvert a portion of the DNS		to specific clients in an effort to subvert a portion of the DNS
	ecosystem for a portion of the Internet.		ecosystem for a portion of the Internet.
	Similarly, the TLD "example" could circumvent company.example for		Similarly, the TLD "example" could circumvent company.example for
	certain clients. It is important to note that this can be done		certain clients. It is important to note that this can be done
	without changing the upstream DS record or trust anchor -- the DNSKEY		without changing the upstream DS record or trust anchor -- the DNSKEY
	is (again) already in the trust path and is merely signing deeper DNS		is (again) already in the trust path and is merely signing deeper DNS
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 44 ¶
	Authoritative parent: If (and only if) an authoritative parent is a		Authoritative parent: If (and only if) an authoritative parent is a
	"delegation only" zone, it could generate a DNSKEY with the		"delegation only" zone, it could generate a DNSKEY with the
	DELEGATION_ONLY flag set, indicating a verifiable promise to the		DELEGATION_ONLY flag set, indicating a verifiable promise to the
	world that will not sign any records other than delegation records.		world that will not sign any records other than delegation records.
	Authoritative Child / Delegated Zone: child zones existing underneath		Authoritative Child / Delegated Zone: child zones existing underneath
	a marked delegation-only zone get the added benefit of knowing their		a marked delegation-only zone get the added benefit of knowing their
	parent will not (and cannot) sign DNS records within the child's		parent will not (and cannot) sign DNS records within the child's
	portion of the DNS tree using the marked DNSKEY.		portion of the DNS tree using the marked DNSKEY.
	Validating Resolver: A validating that supports verifying the		Validating Resolver: A validating resolver that supports verifying
	DELEGATION_ONLY flag is capable of rejecting or discarding any data		the DELEGATION_ONLY flag is capable of rejecting or discarding any
	from an authoritative parent that incorrectly signs non-delegation		data from an authoritative parent that incorrectly signs non-
	records too low in the DNS tree. If the validating resolver supports		delegation records too low in the DNS tree. If the validating
	a (future-defined) DNSSEC transparency audit log as well, it may		resolver supports a (future-defined) DNSSEC transparency audit log as
	submit the appropriate data to a DNSSEC transparency log that		well, it may submit the appropriate data to a DNSSEC transparency log
	appropriately tracks DNSSEC signatures.		that appropriately tracks DNSSEC signatures.
	DNSSEC Transparency Log (optional future): a DNSSEC transparency log		DNSSEC Transparency Log (optional future): a DNSSEC transparency log
	would create a non-modifiable trace of log entries submitted to it,		would create a non-modifiable trace of log entries submitted to it,
	for public verification, similar to [RFC6962]. What it chooses to		for public verification, similar to [RFC6962]. What it chooses to
	accept into its log might be only certain zone data, or any zone with		accept into its log might be only certain zone data, or any zone with
	a marked DNSKEY.		a marked DNSKEY.
	Note that without a DNSSEC Log, the DELEGATION_ONLY flag is still		Note that without a DNSSEC Log, the DELEGATION_ONLY flag is still
	useful per the discussion in the Validating Resolvers role: the		useful per the discussion in the Validating Resolvers role: the
	resolver will reject incorrectly signed, non-delegation data.		resolver will reject incorrectly signed, non-delegation data.
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 30 ¶
	DNSKEY would be considered suspicious (or at least in transition).		DNSKEY would be considered suspicious (or at least in transition).
	Circumventing this through obfuscation would require the collusion of		Circumventing this through obfuscation would require the collusion of
	their parent as well. Finally, a DELEGATION_ONLY flagged DNSKEY for		their parent as well. Finally, a DELEGATION_ONLY flagged DNSKEY for
	the root zone cannot be overridden easily, as it would require a		the root zone cannot be overridden easily, as it would require a
	trust anchor update in all validating resolvers.		trust anchor update in all validating resolvers.
	4. The DELEGATION_ONLY DNSKEY flag		4. The DELEGATION_ONLY DNSKEY flag
	This document introduces a new DNSKEY flag called DELEGATION_ONLY.		This document introduces a new DNSKEY flag called DELEGATION_ONLY.
	When this flag is set on a DNSKEY with its Secure Entry Point (SEP)		When this flag is set on a DNSKEY with its Secure Entry Point (SEP)
	flag set, the zone owner commits to not sign any data that crosses a		flag set, the zone commits to only produce Authoritative Answers for
	label down in the hierarchy. This commits a parent in the DNS		the apex (and _underscore label) records. Note that DS records and
			its DNSSEC signatures are still allowed as this data is authoritative
			at the parent, not the child. This commits a parent in the DNS
	hierarchy to only publish signed DS records and unsigned glue records		hierarchy to only publish signed DS records and unsigned glue records
	(NS and A/AAAA) for its child zones. It will no longer be able to		(NS and A/AAAA) for its child zones. It will no longer be able to
	ignore (or briefly delete, see below) a child delegation and publish		ignore (or briefly delete, see below) a child delegation and publish
	data crossing zone labels by pretending the next label is not a zone		authoritative data in its place.
	cut.
	For such a parent to take over data that belongs to its child zone,		For such a parent to take over data that belongs to its child zone,
	it has two choices. It can (temporarily) remove its own DNSKEY		it has two choices. It can (temporarily) remove its own DNSKEY
	DELEGATION_ONLY flag or it can replace the NS and DS records of its		DELEGATION_ONLY flag or it can replace the NS and DS records of its
	child zone with its own data (destinations and key references) so it		child zone with its own data (destinations and key references) so it
	can sign DNS data that belongs to its own child zone. However, both		can sign DNS data that belongs to its own child zone. However, both
	of these actions cannot be hidden, thus exposing such malicious		of these actions cannot be hidden, thus exposing such malicious
	behaviour when combined with DNSSEC Transparency logs.		behaviour when combined with DNSSEC Transparency logs.
	A zone that publishes a DNSKEY with the DELEGATION_ONLY flag also		A zone that publishes a DNSKEY with the DELEGATION_ONLY flag also
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	7. Marking zone keys DELEGATION_ONLY		7. Marking zone keys DELEGATION_ONLY
	Even before a parent DNSKEY (or the root key) has set the		Even before a parent DNSKEY (or the root key) has set the
	DELEGATION_ONLY flag, zones can already signal their own willingness		DELEGATION_ONLY flag, zones can already signal their own willingness
	to commit to being DELEGATION_ONLY zones. Any changes of that state		to commit to being DELEGATION_ONLY zones. Any changes of that state
	in a zone DNSKEY will require those zones to submit a new DS record		in a zone DNSKEY will require those zones to submit a new DS record
	to their parent. Setting the DELEGATION_ONLY flag would trigger		to their parent. Setting the DELEGATION_ONLY flag would trigger
	DNSSEC Transparency clients to start monitoring for actions by the		DNSSEC Transparency clients to start monitoring for actions by the
	zone or its parents that would be bypassing the DELEGATION_ONLY		zone or its parents that would be bypassing the DELEGATION_ONLY
	policy of the zone. Validating resolvers would mark any data in		policy of the zone. Validating resolvers would mark any data in
	violation of the DELEGATION_ONLY policy as BOGUS.		violation of the DELEGATION_ONLY policy as Bogus.
	7.1. Marking the Root DNSKEY DELEGATION_ONLY		7.1. Marking the Root DNSKEY DELEGATION_ONLY
	Once the Root DNSKEY is marked with a DELEGATION_ONLY flag and		Once the Root DNSKEY is marked with a DELEGATION_ONLY flag and
	deployed resolvers are configured with the new DNSKEY, all TLDs will		deployed resolvers are configured with the new DNSKEY, all TLDs will
	be ensured that the Root DNSKEY can no longer be abused to override		be ensured that the Root DNSKEY can no longer be abused to override
	child zone data. Until the Root KSK DNSKEY sets this flag, software		child zone data. Until the Root KSK DNSKEY sets this flag, software
	SHOULD imply this flag is always set, as this is the current		SHOULD imply this flag is always set, as this is the current
	expectation of the Root Zone.		expectation of the Root Zone.
	skipping to change at page 7, line 46 ¶		skipping to change at page 7, line 46 ¶
	Some TLDs offer a service where small domains can be hosted in-zone		Some TLDs offer a service where small domains can be hosted in-zone
	at the TLD zone itself. In that case, the TLD MUST NOT set the		at the TLD zone itself. In that case, the TLD MUST NOT set the
	DELEGATION_ONLY flag. Another solution for such TLDs is to create		DELEGATION_ONLY flag. Another solution for such TLDs is to create
	delegations for these child zones with the same or different DNSKEY		delegations for these child zones with the same or different DNSKEY
	as used in the parent zone itself.		as used in the parent zone itself.
	If a zone is publishing glue records for a number of zones, and the		If a zone is publishing glue records for a number of zones, and the
	zone that contains the authoritative records for this glue is		zone that contains the authoritative records for this glue is
	deleted, a resigning of the zone will make this orphaned glue		deleted, a resigning of the zone will make this orphaned glue
	authoritative within the zone. However, with the DELEGATION_ONLY		authoritative within the zone. However, with the DELEGATION_ONLY
	flag set, this (signed) DNSSEC data will be considered BOGUS as it		flag set, this (signed) DNSSEC data will be considered Bogus as it
	violations the commitment to only delegate. This may impact domains		violations the commitment to only delegate. This may impact domains
	that depended on this unsigned glue. Note that glue handling differs		that depended on this unsigned glue. Note that glue handling differs
	per zone. Some TLDs already remove the glue records if no		per zone. Some TLDs already remove the glue records if no
	authoritative child is left in its zone that matches these glue		authoritative child is left in its zone that matches these glue
	records.		records.
	For example, if "example.com" and "example.net" use NS records		For example, if "example.com" and "example.net" use NS records
	pointing to "ns.example.net", then if "example.net" is deleted from		pointing to "ns.example.net", then if "example.net" is deleted from
	the ".net" zone, and the previously unsigned glue of "ns.example.net"		the ".net" zone, and the previously unsigned glue of "ns.example.net"
	is now signed by the ".net" zone, the "example.com" zone will lose		is now signed by the ".net" zone, the "example.com" zone will lose
	its NS records and fail to resolve.		its NS records and fail to resolve.
	If a domain uses Empty Non Terminals (ENT), that is uses multiple		The use of Empty Non Terminals (ENT) is fine, as long as the ENT's
	labels where the label is not covered by its own delegation, then the		ends in a proper delegation with NS (and hopefully DS) records.
	DELEGATION_ONLY flag cannot be set. For example, some domains allow
	registrations straight into their zone (eg "child.example") while
	others use an ENT to categorize these (eg "child.co.example" and
	"child.ac.example"). Some TLDs contain a few ENTs marking some
	administrative or geographic region. Such TLDs must first migrate
	their ENT to fully delegated child zones before enabling the
	DELEGATION_ONLY flag.
	Some TLDs publish their nameserver (NS) records straight within their		Some TLDs publish their nameserver (NS) records straight within their
	TLD (eg "ns1.example") which makes these names indistinguishable from		TLD (eg "ns1.example") which makes these names indistinguishable from
	real delegations with respect to the DELEGATION_ONLY flag. These NS		real delegations with respect to the DELEGATION_ONLY flag. These NS
	entries would have to be moved to their own delegation zone (eg		entries would have to be moved to their own delegation zone (eg
	"ns1.nic.example")		"ns1.nic.example") which in itself cannot be a DELEGATION_ONLY zone.
	Some TLDs have a requirement for certain Fully Qualified Domain Names		Some TLDs have a requirement for certain Fully Qualified Domain Names
	(FQDN) within their TLD, such as "whois.example" or "nic.example".		(FQDN) within their TLD, such as "whois.example" or "nic.example".
	These usually appear as signed data of the TLD and not as a delegated		These usually appear as signed data of the TLD and not as a delegated
	child zone. These names would have to be converted to delegated		child zone. These names would have to be converted to delegated
	zones before enabling the DELEGATION_ONLY flag.		zones before enabling the DELEGATION_ONLY flag.
	The bind DNS software has an option called "delegation_only zones"		The bind DNS software has an option called "delegation_only zones"
	which is an option that means something completely different. It		which is an option that means something completely different. It
	refers to ignoring wildcard records in specified zones that are		refers to ignoring wildcard records in specified zones that are
	deemed delegation-only zones.		deemed delegation-only zones.
	9. Security Considerations		9. Security Considerations
	Some parental attacks cannot be detected when the validating		Some parental attacks cannot be detected when the validating
	resolver's cache is empty. Care should be taken by resolvers to not		resolver's cache is empty. Care should be taken by resolvers to not
	unnecessarily empty their cache. This is specifically important for		unnecessarily empty their cache. This is specifically important for
	roaming clients that re-connect frequently to different wireless or		roaming clients that re-connect frequently to different wireless or
	mobile data networks.		mobile data networks.
			Resolvers should be aware of DELEGATION_ONLY status of a parental
			domain and not consume Authoritative or Additional sections with data
			that is placed to attempt to bypass the DELEGATION_ONLY restriction.
			If "example.org" is a DELEGATION_ONLY zone, and a query for
			"www.example.org" results in non-authoritative data for A records for
			"www.example.org" or "mail.example.org", these records should be
			rejected as Bogus, irrespective of whether these were signed by the
			appropriate "example.org" DNSSEC key.
	This DELEGATION_ONLY mechanism is not designed to completely foil		This DELEGATION_ONLY mechanism is not designed to completely foil
	attacks (since parent's can simply change a child's referral data),		attacks (since parent's can simply change a child's referral data),
	but rather to empower transparency logging mechanisms.		but rather to empower transparency logging mechanisms.
	10. Privacy Considerations		10. Privacy Considerations
	Some of the protection offered by the DELEGATION_ONLY flag is only		Some of the protection offered by the DELEGATION_ONLY flag is only
	available when DNS resolvers report changes in the signing depth of		available when DNS resolvers report changes in the signing depth of
	high level (root or TLD) DNSKEYs to gain DNSSEC Transparency. This		high level (root or TLD) DNSKEYs to gain DNSSEC Transparency. This
	reporting can reveal that a particular node is trying to access a		reporting can reveal that a particular node is trying to access a
	skipping to change at page 9, line 50 ¶		skipping to change at page 9, line 50 ¶
	This document defines a new DNSKEY flag, the DELEGATION_ONLY flag,		This document defines a new DNSKEY flag, the DELEGATION_ONLY flag,
	whose value [TBD] has been allocated by IANA from the DNSKEY FLAGS		whose value [TBD] has been allocated by IANA from the DNSKEY FLAGS
	Registry.		Registry.
	13. Acknowledgements		13. Acknowledgements
	The authors wishes to thank Thomas H. Ptacek for his insistence on		The authors wishes to thank Thomas H. Ptacek for his insistence on
	this matter.		this matter.
	Thanks to the following IETF participants: Viktor Dukhovni, Shumon		Thanks to the following IETF participants: Viktor Dukhovni, Shumon
	Huque, Geoff Huston, Rick Lamb and Sam Weiler.		Huque, Geoff Huston, Rick Lamb Sam Weiler and Paul Vixie.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<https://www.rfc-editor.org/info/rfc1034>.		<https://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
End of changes. 17 change blocks.
	42 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/