rfc8945v2.txt		rfc8945.txt
	skipping to change at line 251 ¶		skipping to change at line 251 ¶
	NAME: The name of the key used, in domain name syntax. The name		NAME: The name of the key used, in domain name syntax. The name
	should reflect the names of the hosts and uniquely identify the		should reflect the names of the hosts and uniquely identify the
	key among a set of keys these two hosts may share at any given		key among a set of keys these two hosts may share at any given
	time. For example, if hosts A.site.example and B.example.net		time. For example, if hosts A.site.example and B.example.net
	share a key, possibilities for the key name include		share a key, possibilities for the key name include
	<id>.A.site.example, <id>.B.example.net, and		<id>.A.site.example, <id>.B.example.net, and
	<id>.A.site.example.B.example.net. It should be possible for more		<id>.A.site.example.B.example.net. It should be possible for more
	than one key to be in simultaneous use among a set of interacting		than one key to be in simultaneous use among a set of interacting
	hosts. This allows for periodic key rotation as per best		hosts. This allows for periodic key rotation as per best
	operational practices, as well as algorithm agility as indicated		operational practices, as well as algorithm agility as indicated
	by [BCP201].		by [RFC7696].
	The name may be used as a local index to the key involved, but it		The name may be used as a local index to the key involved, but it
	is recommended that it be globally unique. Where a key is just		is recommended that it be globally unique. Where a key is just
	shared between two hosts, its name actually need only be		shared between two hosts, its name actually need only be
	meaningful to them, but it is recommended that the key name be		meaningful to them, but it is recommended that the key name be
	mnemonic and incorporate the names of participating agents or		mnemonic and incorporate the names of participating agents or
	resources as suggested above.		resources as suggested above.
	TYPE: This MUST be TSIG (250: Transaction SIGnature).		TYPE: This MUST be TSIG (250: Transaction SIGnature).
	skipping to change at line 310 ¶		skipping to change at line 310 ¶
	an unsigned 48-bit integer containing the time the message was		an unsigned 48-bit integer containing the time the message was
	signed as seconds since 00:00 on 1970-01-01 UTC, ignoring leap		signed as seconds since 00:00 on 1970-01-01 UTC, ignoring leap
	seconds.		seconds.
	Fudge:		Fudge:
	an unsigned 16-bit integer specifying the allowed time difference		an unsigned 16-bit integer specifying the allowed time difference
	in seconds permitted in the Time Signed field.		in seconds permitted in the Time Signed field.
	MAC Size:		MAC Size:
	an unsigned 16-bit integer giving the length of the MAC field in		an unsigned 16-bit integer giving the length of the MAC field in
	octets. Truncation is indicated by a MAC size less than the size		octets. Truncation is indicated by a MAC Size less than the size
	of the keyed hash produced by the algorithm specified by the		of the keyed hash produced by the algorithm specified by the
	Algorithm Name.		Algorithm Name.
	MAC:		MAC:
	a sequence of octets whose contents are defined by the TSIG		a sequence of octets whose contents are defined by the TSIG
	algorithm used, possibly truncated as specified by the MAC Size.		algorithm used, possibly truncated as specified by the MAC Size.
	The length of this field is given by the Mac size. Calculation of		The length of this field is given by the MAC Size. Calculation of
	the MAC is detailed in Section 4.3.		the MAC is detailed in Section 4.3.
	Original ID:		Original ID:
	an unsigned 16-bit integer holding the message ID of the original		an unsigned 16-bit integer holding the message ID of the original
	request message. For a TSIG RR on a request, it is set equal to		request message. For a TSIG RR on a request, it is set equal to
	the DNS message ID. In a TSIG attached to a response -- or in		the DNS message ID. In a TSIG attached to a response -- or in
	cases such as the forwarding of a dynamic update request -- the		cases such as the forwarding of a dynamic update request -- the
	field contains the ID of the original DNS request.		field contains the ID of the original DNS request.
	Error:		Error:
	skipping to change at line 347 ¶		skipping to change at line 347 ¶
	will be empty (i.e., Other Len will be zero) unless the content of		will be empty (i.e., Other Len will be zero) unless the content of
	the Error field is BADTIME, in which case it will be a 48-bit		the Error field is BADTIME, in which case it will be a 48-bit
	unsigned integer containing the server's current time as the		unsigned integer containing the server's current time as the
	number of seconds since 00:00 on 1970-01-01 UTC, ignoring leap		number of seconds since 00:00 on 1970-01-01 UTC, ignoring leap
	seconds (see Section 5.2.3). This document assigns no meaning to		seconds (see Section 5.2.3). This document assigns no meaning to
	its contents in requests.		its contents in requests.
	4.3. MAC Computation		4.3. MAC Computation
	When generating or verifying the contents of a TSIG record, the data		When generating or verifying the contents of a TSIG record, the data
	listed in the rest of this section is passed, in the order listed		listed in the rest of this section are passed, in the order listed
	below, as input to MAC computation. The data are passed in network		below, as input to MAC computation. The data are passed in network
	byte order or wire format, as appropriate and are fed into the		byte order or wire format, as appropriate and are fed into the
	hashing function as a continuous octet sequence with no interfield		hashing function as a continuous octet sequence with no interfield
	separator or padding.		separator or padding.
	4.3.1. Request MAC		4.3.1. Request MAC
	Only included in the computation of a MAC for a response message (or		Only included in the computation of a MAC for a response message (or
	the first message in a multi-message response), the validated request		the first message in a multi-message response), the validated request
	MAC MUST be included in the MAC computation. If the request MAC		MAC MUST be included in the MAC computation. If the request MAC
	skipping to change at line 385 ¶		skipping to change at line 385 ¶
	and subsequent messages in a response that consists of multiple DNS		and subsequent messages in a response that consists of multiple DNS
	messages (e.g., a zone transfer). These are described in		messages (e.g., a zone transfer). These are described in
	Section 5.3.1.		Section 5.3.1.
	4.3.2. DNS Message		4.3.2. DNS Message
	In the MAC computation, the whole/complete DNS message in wire format		In the MAC computation, the whole/complete DNS message in wire format
	is used.		is used.
	When creating an outgoing message, the TSIG is based on the message		When creating an outgoing message, the TSIG is based on the message
	before the TSIG RR has been added to the additional section and		content before the TSIG RR has been added to the additional section
	before the DNS Message Header's ARCOUNT has been incremented to		and before the DNS Message Header's ARCOUNT has been incremented to
	include the TSIG RR.		include the TSIG RR.
	When verifying an incoming message, the TSIG is checked against the		When verifying an incoming message, the TSIG is checked against the
	message after the TSIG RR has been removed, the ARCOUNT decremented,		message after the TSIG RR has been removed, the ARCOUNT decremented,
	and the message ID replaced by the original message ID from the TSIG		and the message ID replaced by the original message ID from the TSIG
	if those IDs differ. (This could happen, for example, when		if those IDs differ. (This could happen, for example, when
	forwarding a dynamic update request.)		forwarding a dynamic update request.)
	4.3.3. TSIG Variables		4.3.3. TSIG Variables
	skipping to change at line 525 ¶		skipping to change at line 525 ¶
	use the truncated value for authentication. HMAC SHA-1 truncated to		use the truncated value for authentication. HMAC SHA-1 truncated to
	96 bits is an option available in several IETF protocols, including		96 bits is an option available in several IETF protocols, including
	IPsec and TLS. However, while this option is kept for backwards		IPsec and TLS. However, while this option is kept for backwards
	compatibility, it may not provide a security level appropriate for		compatibility, it may not provide a security level appropriate for
	all cases in the modern environment. In these cases, it is		all cases in the modern environment. In these cases, it is
	preferable to use a hashing algorithm such as SHA-256-128, SHA-		preferable to use a hashing algorithm such as SHA-256-128, SHA-
	384-192, or SHA-512-256 [RFC4868].		384-192, or SHA-512-256 [RFC4868].
	Processing of a truncated MAC follows these rules:		Processing of a truncated MAC follows these rules:
	If the MAC Size field is greater than keyed hash output length: This		If the MAC Size field is greater than the keyed hash output
	case MUST NOT be generated and, if received, MUST cause the DNS		length: This case MUST NOT be generated and, if received, MUST cause
	message to be dropped and RCODE 1 (FORMERR) to be returned.		the DNS message to be dropped and RCODE 1 (FORMERR) to be
			returned.
	If the MAC Size field equals the keyed hash output length: The		If the MAC Size field equals the keyed hash output length: The
	entire keyed hash output is present and used.		entire keyed hash output is present and used.
	If the MAC Size field is less than the larger of 10 (octets) and		If the MAC Size field is less than the larger of 10 (octets) and
	half the length of the hash function in use: With the exception of		half the length of the hash function in use: With the exception of
	certain TSIG error messages described in Section 5.3.2, where it		certain TSIG error messages described in Section 5.3.2, where it
	is permitted that the MAC Size be zero, this case MUST NOT be		is permitted that the MAC Size be zero, this case MUST NOT be
	generated and, if received, MUST cause the DNS message to be		generated and, if received, MUST cause the DNS message to be
	dropped and RCODE 1 (FORMERR) to be returned.		dropped and RCODE 1 (FORMERR) to be returned.
	skipping to change at line 657 ¶		skipping to change at line 658 ¶
	If the client does not receive TSIG records frequently enough (as		If the client does not receive TSIG records frequently enough (as
	specified above), it SHOULD assume the connection has been hijacked,		specified above), it SHOULD assume the connection has been hijacked,
	and it SHOULD close the connection. The client SHOULD treat this the		and it SHOULD close the connection. The client SHOULD treat this the
	same way as they would any other interrupted transfer (although the		same way as they would any other interrupted transfer (although the
	exact behavior is not specified).		exact behavior is not specified).
	5.3.2. Generation of TSIG on Error Returns		5.3.2. Generation of TSIG on Error Returns
	When a server detects an error relating to the key or MAC in the		When a server detects an error relating to the key or MAC in the
	incoming request, the server SHOULD send back an unsigned error		incoming request, the server SHOULD send back an unsigned error
	message (MAC size == 0 and empty MAC). It MUST NOT send back a		message (MAC Size == 0 and empty MAC). It MUST NOT send back a
	signed error message.		signed error message.
	If an error is detected relating to the TSIG validity period or the		If an error is detected relating to the TSIG validity period or the
	MAC is too short for the local policy, the server SHOULD send back a		MAC is too short for the local policy, the server SHOULD send back a
	signed error message. The digest components are:		signed error message. The digest components are:
	Request MAC (if the request MAC validated)		Request MAC (if the request MAC validated)
	DNS Message (response)		DNS Message (response)
	TSIG Variables (response)		TSIG Variables (response)
	skipping to change at line 837 ¶		skipping to change at line 838 ¶
	truncation than the minimum strength required by the policy.		truncation than the minimum strength required by the policy.
	8. Shared Secrets		8. Shared Secrets
	Secret keys are very sensitive information and all available steps		Secret keys are very sensitive information and all available steps
	should be taken to protect them on every host on which they are		should be taken to protect them on every host on which they are
	stored. Generally, such hosts need to be physically protected. If		stored. Generally, such hosts need to be physically protected. If
	they are multi-user machines, great care should be taken so that		they are multi-user machines, great care should be taken so that
	unprivileged users have no access to keying material. Resolvers		unprivileged users have no access to keying material. Resolvers
	often run unprivileged, which means all users of a host would be able		often run unprivileged, which means all users of a host would be able
	to see whatever configuration data is used by the resolver.		to see whatever configuration data are used by the resolver.
	A name server usually runs privileged, which means its configuration		A name server usually runs privileged, which means its configuration
	data need not be visible to all users of the host. For this reason,		data need not be visible to all users of the host. For this reason,
	a host that implements transaction-based authentication should		a host that implements transaction-based authentication should
	probably be configured with a "stub resolver" and a local caching and		probably be configured with a "stub resolver" and a local caching and
	forwarding name server. This presents a special problem for		forwarding name server. This presents a special problem for
	[RFC2136], which otherwise depends on clients to communicate only		[RFC2136], which otherwise depends on clients to communicate only
	with a zone's authoritative name servers.		with a zone's authoritative name servers.
	Use of strong, random shared secrets is essential to the security of		Use of strong, random shared secrets is essential to the security of
	skipping to change at line 986 ¶		skipping to change at line 987 ¶
	expensive public key cryptography and complex authentication logic.		expensive public key cryptography and complex authentication logic.
	Secure Domain Name System Dynamic Update ([RFC3007]) describes how		Secure Domain Name System Dynamic Update ([RFC3007]) describes how
	different keys are used in dynamically updated zones.		different keys are used in dynamically updated zones.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[FIPS180-4]		[FIPS180-4]
	National Institute of Standards and Technology, "Secure		National Institute of Standards and Technology, "Secure
	Hash Standard (SHS)", FIPS PUB 180-4, DOI DOI		Hash Standard (SHS)", FIPS PUB 180-4,
	10.6028/NIST.FIPS.180-4, August 2015, <https://doi.org/DOI		DOI 10.6028/NIST.FIPS.180-4, August 2015,
	10.6028/NIST.FIPS.180-4>.		<https://doi.org/10.6028/NIST.FIPS.180-4>.
	[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
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/info/rfc1035>.		November 1987, <https://www.rfc-editor.org/info/rfc1035>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at line 1023 ¶		skipping to change at line 1024 ¶
	Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",		Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
	RFC 4635, DOI 10.17487/RFC4635, August 2006,		RFC 4635, DOI 10.17487/RFC4635, August 2006,
	<https://www.rfc-editor.org/info/rfc4635>.		<https://www.rfc-editor.org/info/rfc4635>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	11.2. Informative References		11.2. Informative References
	[BCP201] Housley, R., "Guidelines for Cryptographic Algorithm
	Agility and Selecting Mandatory-to-Implement Algorithms",
	BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
	<https://www.rfc-editor.org/info/rfc7696>.
	[CVE-2017-11104]		[CVE-2017-11104]
	Common Vulnerabilities and Exposures, "CVE-2017-11104:		Common Vulnerabilities and Exposures, "CVE-2017-11104:
	Improper TSIG validity period check can allow TSIG		Improper TSIG validity period check can allow TSIG
	forgery", June 2017, <https://cve.mitre.org/cgi-bin/		forgery", June 2017, <https://cve.mitre.org/cgi-bin/
	cvename.cgi?name=CVE-2017-11104>.		cvename.cgi?name=CVE-2017-11104>.
	[CVE-2017-3142]		[CVE-2017-3142]
	Common Vulnerabilities and Exposures, "CVE-2017-3142: An		Common Vulnerabilities and Exposures, "CVE-2017-3142: An
	error in TSIG authentication can permit unauthorized zone		error in TSIG authentication can permit unauthorized zone
	transfers", June 2017, <https://cve.mitre.org/cgi-bin/		transfers", June 2017, <https://cve.mitre.org/cgi-bin/
	skipping to change at line 1129 ¶		skipping to change at line 1125 ¶
	[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms		[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
	(SHA and SHA-based HMAC and HKDF)", RFC 6234,		(SHA and SHA-based HMAC and HKDF)", RFC 6234,
	DOI 10.17487/RFC6234, May 2011,		DOI 10.17487/RFC6234, May 2011,
	<https://www.rfc-editor.org/info/rfc6234>.		<https://www.rfc-editor.org/info/rfc6234>.
	[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA		[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
	Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,		Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
	April 2013, <https://www.rfc-editor.org/info/rfc6895>.		April 2013, <https://www.rfc-editor.org/info/rfc6895>.
			[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
			Agility and Selecting Mandatory-to-Implement Algorithms",
			BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
			<https://www.rfc-editor.org/info/rfc7696>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[SHA1SHAMBLES]		[SHA1SHAMBLES]
	Leurent, G. and T. Peyrin, "SHA-1 is a Shambles", January		Leurent, G. and T. Peyrin, "SHA-1 is a Shambles", January
	2020, <https://eprint.iacr.org/2020/014.pdf>.		2020, <https://eprint.iacr.org/2020/014.pdf>.
	Acknowledgements		Acknowledgements
End of changes. 11 change blocks.
	19 lines changed or deleted		20 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/