< draft-osterweil-dane-ipsec-01.txt		draft-osterweil-dane-ipsec-02.txt >
	DANE E. Osterweil		DANE E. Osterweil
	Internet-Draft G. Wiley		Internet-Draft G. Wiley
	Intended status: Standards Track VeriSign, Inc.		Intended status: Standards Track T. Okubo
	Expires: March 1, 2015 D. Mitchell		Expires: September 25, 2015 R. Lavu
	Singularity Networks		A. Mohaisen
	A. Newton		VeriSign, Inc.
	American Registry for Internet		March 24, 2015
	Numbers
	August 28, 2014
	Opportunistic Encryption with DANE Semantics and IPsec: IPSECA		Opportunistic Encryption with DANE Semantics and IPsec: IPSECA
	draft-osterweil-dane-ipsec-01		draft-osterweil-dane-ipsec-02
	Abstract		Abstract
	The query/response transactions of the Domain Name System (DNS) can		The query/response transactions of the Domain Name System (DNS) can
	disclose valuable meta-data about the online activities of DNS'		disclose valuable meta-data about the online activities of DNS'
	users. The DNS Security Extensions (DNSSEC) provide object-level		users. The DNS Security Extensions (DNSSEC) provide object-level
	security, but do not attempt to secure the DNS transaction itself.		security, but do not attempt to secure the DNS transaction itself.
	For example, DNSSEC does not protect against information leakage, and		For example, DNSSEC does not protect against information leakage, and
	only protects DNS data until the last validating recursive resolver.		only protects DNS data until the last validating recursive resolver.
	Stub resolvers are vulnerable to adversaries in the network between		Stub resolvers are vulnerable to adversaries in the network between
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 45 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 March 1, 2015.		This Internet-Draft will expire on September 25, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the
			Copyright (c) 2015 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 28 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. What IPSECA Adds to DNSSEC Transactions . . . . . . . . . 4		1.1. What IPSECA Adds to DNSSEC Transactions . . . . . . . . . 4
	1.2. IP-Centric IPsec Tunnel Discovery Using IPSECKEY . . . . . 4		1.2. IP-Centric IPsec Tunnel Discovery Using IPSECKEY . . . . . 4
	1.3. Service-Centric IPsec Tunnel Discovery Using IPSECA		1.3. Service-Centric IPsec Tunnel Discovery Using IPSECA
	and DANE . . . . . . . . . . . . . . . . . . . . . . . . . 5		and DANE . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. The IPSECA Resource Record . . . . . . . . . . . . . . . . . . 6		2. The IPSECA Resource Record . . . . . . . . . . . . . . . . . . 6
	2.1. IPSECA RDATA Wire Format . . . . . . . . . . . . . . . . . 7		2.1. IPSECA RDATA Wire Format . . . . . . . . . . . . . . . . . 7
	2.1.1. The Usage Field . . . . . . . . . . . . . . . . . . . 7		2.1.1. The Usage Field . . . . . . . . . . . . . . . . . . . 7
	2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 7		2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 7
	2.1.3. The Matching Field . . . . . . . . . . . . . . . . . . 8		2.1.3. The Matching Field . . . . . . . . . . . . . . . . . . 8
	2.1.4. The Gateway Type Field . . . . . . . . . . . . . . . . 8		2.1.4. The Certificate Assocation Data Field . . . . . . . . 8
	2.1.5. The Gateway Field . . . . . . . . . . . . . . . . . . 9		2.2. IPSECA RR Presentation Format . . . . . . . . . . . . . . 9
	2.1.6. The Certificate Assocation Data Field . . . . . . . . 9		2.3. Domain Names used for IPSEC Records . . . . . . . . . . . 9
	2.2. IPSECA RR Presentation Format . . . . . . . . . . . . . . 10		2.4. IPSECA RR Examples . . . . . . . . . . . . . . . . . . . . 9
	2.3. Domain Names used for IPSEC Records . . . . . . . . . . . 10		2.4.1. OE to a DNS Name Server Example . . . . . . . . . . . 9
	2.4. IPSECA RR Examples . . . . . . . . . . . . . . . . . . . . 10		3. Operational Considerations . . . . . . . . . . . . . . . . . . 11
	2.4.1. OE to a DNS Name Server Example . . . . . . . . . . . 10		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	3. Operational Considerations . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5.1. Interactions . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5.2. Last Mile Security Analysis . . . . . . . . . . . . . . . 12
	5.1. Interactions . . . . . . . . . . . . . . . . . . . . . . . 13		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	5.2. Last Mile Security Analysis . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		7.2. Informative References . . . . . . . . . . . . . . . . . . 14
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 14		Appendix A. Name Server OE Configuration Example . . . . . . . . 15
	7.2. Informative References . . . . . . . . . . . . . . . . . . 15		Appendix B. Recursive Resolver OE Configuration Example . . . . . 16
	Appendix A. Name Server OE Configuration Example . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
	Appendix B. Recursive Resolver OE Configuration Example . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	The query/response transactions of the Domain Name System (DNS)		The query/response transactions of the Domain Name System (DNS)
	[RFC1035] can disclose valuable meta-data about the online activities		[RFC1035] can disclose valuable meta-data about the online activities
	of DNS' users. The DNS Security Extensions' (DNSSEC's) [RFC4033],		of DNS' users. The DNS Security Extensions' (DNSSEC's) [RFC4033],
	[RFC4034], [RFC4035] core services (integrity, source authenticity,		[RFC4034], [RFC4035] core services (integrity, source authenticity,
	and secure denial of existence) are designed to secure data in DNS		and secure denial of existence) are designed to secure data in DNS
	transactions by providing object-level security, but do not attempt		transactions by providing object-level security, but do not attempt
	to secure the DNS transaction itself. For example, DNSSEC does not		to secure the DNS transaction itself. For example, DNSSEC does not
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 10 ¶
	The IPSECA resource record is modeled heavily off of the IPSECKEY RR		The IPSECA resource record is modeled heavily off of the IPSECKEY RR
	[RFC4025], but it differs in significant ways. The format of IPSECA		[RFC4025], but it differs in significant ways. The format of IPSECA
	is harmonized with the architectural direction set by other DANE work		is harmonized with the architectural direction set by other DANE work
	[RFC6698], [I-D.draft-ogud-dane-vocabulary].		[RFC6698], [I-D.draft-ogud-dane-vocabulary].
	2.1. IPSECA RDATA Wire Format		2.1. IPSECA RDATA Wire Format
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Usage | Selector | Matching | Gateway Type |		| Usage | Selector | Matching | /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
	| Gateway |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| /		| /
	/ Certificate Association Data /		/ Certificate Association Data /
	/ /		/ /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
	Figure 1		Figure 1
	2.1.1. The Usage Field		2.1.1. The Usage Field
	The meaning, semantics, and interpretation of the Usage field of the		The meaning, semantics, and interpretation of the Usage field of the
	skipping to change at page 8, line 35 ¶		skipping to change at page 8, line 35 ¶
	+-------+-----------+--------------------------+-----------+		+-------+-----------+--------------------------+-----------+
	| 0 | Full | No hash used | [RFC6698] |		| 0 | Full | No hash used | [RFC6698] |
	| 1 | SHA2-256 | 256 bit hash by SHA2 | [RFC6698] |		| 1 | SHA2-256 | 256 bit hash by SHA2 | [RFC6698] |
	| 2 | SHA2-512 | 512 bit hash by SHA2 | [RFC6698] |		| 2 | SHA2-512 | 512 bit hash by SHA2 | [RFC6698] |
	| 3-254 | | Unassigned | |		| 3-254 | | Unassigned | |
	| 255 | PrivMatch | Reserved for Private Use | [RFC6698] |		| 255 | PrivMatch | Reserved for Private Use | [RFC6698] |
	+-------+-----------+--------------------------+-----------+		+-------+-----------+--------------------------+-----------+
	Table 3: TLSA Matching Types		Table 3: TLSA Matching Types
	2.1.4. The Gateway Type Field		2.1.4. The Certificate Assocation Data Field
	The Gateway Type field follows similar logic to that spacified in
	[RFC4025], Section 2.3:
	"The gateway type field indicates the format of the information
	that is stored in the gateway field.
	The following values are defined:
	1. No gateway is present
	2. A 4-byte IPv4 address is present
	3. A 16-byte IPv6 address is present
	4. A wire-encoded domain name is present. The wire-encoded
	format is self-describing, so the length is implicit. The
	domain name MUST NOT be compressed. (see section 3.3 of
	RFC1035 [[RFC1035]])."
	2.1.5. The Gateway Field
	The Gateway field follows the similar logic to that specified in
	[RFC4025], Section 2.5:
	"The gateway field indicates a gateway to which an IPsec tunnel
	may be created in order to reach the entity named by this
	resource record.
	There are three formats:
	A 32-bit IPv4 address is present in the gateway field. The data
	portion is an IPv4 address as described in section 3.4.1 of
	[RFC1035]. This is a 32-bit number in network byte order.
	A 128-bit IPv6 address is present in the gateway field. The data
	portion is an IPv6 address as described in section 2.2 of
	[RFC3596]. This is a 128-bit number in network byte order.
	The gateway field is a normal wire-encoded domain name, as
	described in section 3.3 of [RFC1035]. Compression MUST NOT be
	used."
	It is at the gateway specified in this field that any key exchange
	should be conducted.
	2.1.6. The Certificate Assocation Data Field
	The meaning, semantics, and interpretation of the Certificate		The meaning, semantics, and interpretation of the Certificate
	Association Data field of the IPSECA resource record follow the		Association Data field of the IPSECA resource record follow the
	specification of the same field in the TLSA resource record,		specification of the same field in the TLSA resource record,
	described in Section 2.1.4 of [RFC6698]:		described in Section 2.1.4 of [RFC6698]:
	"This field specifies the 'certificate association data' to be		"This field specifies the 'certificate association data' to be
	matched. These bytes are either raw data (that is, the full		matched. These bytes are either raw data (that is, the full
	certificate or its SubjectPublicKeyInfo, depending on the		certificate or its SubjectPublicKeyInfo, depending on the
	selector) for matching type 0, or the hash of the raw data for		selector) for matching type 0, or the hash of the raw data for
	skipping to change at page 11, line 10 ¶		skipping to change at page 10, line 10 ¶
	Suppose a DNS zone example.com is served by the name servers		Suppose a DNS zone example.com is served by the name servers
	ns1.example.com and ns2.example.com. If the zone operators want to		ns1.example.com and ns2.example.com. If the zone operators want to
	advertise their willingness to offer OE to their name servers using		advertise their willingness to offer OE to their name servers using
	IKEv2 [RFC5996], then the following domain names MUST be placed under		IKEv2 [RFC5996], then the following domain names MUST be placed under
	the example.com zone (the contents of the resource records, below,		the example.com zone (the contents of the resource records, below,
	are exemplary only and MAY have whatever values a zone operator		are exemplary only and MAY have whatever values a zone operator
	chooses):		chooses):
	_53.ns1.example.com. IN IPSECA (		_53.ns1.example.com. IN IPSECA (
	0 1 1 ns1.example.com		0 1 1 edeff39034cd2ee83446633a9fba
	edeff39034cd2ee83446633a9fba
	d815a579134ecd7636e51af92ec7		d815a579134ecd7636e51af92ec7
	207fd490 ) ; Verify IPsec for DNS txns		207fd490 ) ; Verify IPsec for DNS txns
	_53.ns2.example.com. IN IPSECA (		_53.ns2.example.com. IN IPSECA (
	0 1 1 tunnel2.example.com		0 1 1 edeff39034cd2ee83446633a9fba
	edeff39034cd2ee83446633a9fba
	d815a579134ecd7636e51af92ec7		d815a579134ecd7636e51af92ec7
	207fd490 ) ; Verify IPsec for DNS txns		207fd490 ) ; Verify IPsec for DNS txns
	This example illustrates how a zone MAY indicate where an SPD entry		This example illustrates how a zone MAY indicate where an SPD entry
	and SA establishment endpoints exist for its name servers (note, they		and SA establishment endpoints exist for its name servers (note, they
	are not required to be the name servers themselves). Here, each name		are not required to be the name servers themselves). Here, each name
	server is mapped to a tunnel end point (ns1.example.com acts as its		server is a tunnel end point, and these two name servers are mapped
	own endpoint, and ns2.example.com points to another gateway), and		to service ports for DNS (port 53). The IPSECA records above
	these two name servers are mapped to service ports for DNS (port 53).		indicate that they verify the CA who must have issued the IPsec
	The IPSECA records above indicate that they verify the CA who must		certificate used and they represent a SHA256 hash of that
	have issued the IPsec certificate used and they represent a SHA256		certificate's SPKI.
	hash of that certificate's SPKI.
	Alternately, suppose an enterprise wants to configure OE for DNS		Alternately, suppose an enterprise wants to configure OE for DNS
	transactions between its desktop clients and its recursive resolver.		transactions between its desktop clients and its recursive resolver.
	In this case, if the enterprise has configured their desktop clients		In this case, if the enterprise has configured their desktop clients
	(perhaps through DHCP) to forward their DNS queries to a caching		(perhaps through DHCP) to forward their DNS queries to a caching
	recursive resolver at the IP address 192.168.1.2, then the following		recursive resolver at the IP address 192.168.1.2, then the following
	IPSECA mapping should be placed in an internally managed DNS reverse		IPSECA mapping should be placed in an internally managed DNS reverse
	zone:		zone:
	_53.2.1.168.192.in-addr.arpa. IN IPSECA (		_53.2.1.168.192.in-addr.arpa. IN IPSECA (
	3 0 2 192.168.1.2		3 0 2 8f6ea3c50b5c488bef74c7c4a17a
	8f6ea3c50b5c488bef74c7c4a17a
	24e8b0f4777d13c211a29223b69a		24e8b0f4777d13c211a29223b69a
	ea7a89184ac4d272a2e3d9760966		ea7a89184ac4d272a2e3d9760966
	fb3f220b39f7fdfb325998289e50		fb3f220b39f7fdfb325998289e50
	311ce0748f13c1ed ) ; Verify data in IKEv2 SA		311ce0748f13c1ed ) ; Verify data in IKEv2 SA
	This example illustrates how a caching recursive resolver MAY		This example illustrates how a caching recursive resolver MAY
	indicate where it will accept IPsec tunnel establishment and what the		indicate where it will accept IPsec tunnel establishment and what the
	certificate used for a SA should be. Here the DNS service port and		certificate used for a SA should be. Here the DNS service port and
	the IPSECA records describe the nature of the authentic certificate		the IPSECA records describe the nature of the authentic certificate
	that SHOULD be used in an SA with this endpoint. In this example,		that SHOULD be used in an SA with this endpoint. In this example,
	skipping to change at page 18, line 4 ¶		skipping to change at page 16, line 40 ¶
	</STUBBED OUT SECTION>		</STUBBED OUT SECTION>
	Authors' Addresses		Authors' Addresses
	Eric Osterweil		Eric Osterweil
	VeriSign, Inc.		VeriSign, Inc.
	Reston, VA		Reston, VA
	USA		USA
	Email: eosterweil@verisign.com		Email: eosterweil@verisign.com
	Glen Wiley		Glen Wiley
	VeriSign, Inc.		VeriSign, Inc.
	Reston, VA		Reston, VA
	USA		USA
	Email: gwiley@verisign.com		Email: gwiley@verisign.com
			Tomofumi Okubo
			VeriSign, Inc.
			Reston, VA
			USA
	Dave Mitchell		Email: tomokubo@Verisign.com
	Singularity Networks
	San Francisco, CA		Ramana Lavu
			VeriSign, Inc.
			Reston, VA
	USA		USA
	Email: dave@singularity.cx		Email: RLavu@verisign.com
	Andrew Newton		Aziz Mohaisen
	American Registry for Internet Numbers		VeriSign, Inc.
	3635 Concorde Parkway		Reston, VA
	Chantilly, VA
	USA		USA
	Email: andy@arin.net		Email: amohaisen@verisign.com
End of changes. 17 change blocks.
	100 lines changed or deleted		51 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/