draft-kucherawy-authres-header-b-02.txt		draft-kucherawy-authres-header-b-03.txt
	Individual submission M. Kucherawy		Individual submission M. Kucherawy
	Internet-Draft Cloudmark, Inc.		Internet-Draft Cloudmark, Inc.
	Intended status: Standards Track May 27, 2010		Intended status: Standards Track June 9, 2010
	Expires: November 28, 2010		Expires: December 11, 2010
	Authentication-Results Registration For Differentiating Among		Authentication-Results Registration For Differentiating Among
	Cryptographic Results		Cryptographic Results
	draft-kucherawy-authres-header-b-02		draft-kucherawy-authres-header-b-03
	Abstract		Abstract
	This memo updates the registry of properties in Authentication-		This memo updates the registry of properties in Authentication-
	Results: message header fields to allow a multiple-result report to		Results: message header fields to allow a multiple-result report to
	distinguish among one or more cryptographic signatures on a message,		distinguish among one or more cryptographic signatures on a message,
	thus associating specific results with the signatures they represent.		thus associating specific results with the signatures they represent.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 November 28, 2010.		This Internet-Draft will expire on December 11, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	skipping to change at page 2, line 14		skipping to change at page 2, line 14
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
	6.1. Improvement . . . . . . . . . . . . . . . . . . . . . . . . 4		6.1. Improvement . . . . . . . . . . . . . . . . . . . . . . . . 4
	6.2. Result Forgeries . . . . . . . . . . . . . . . . . . . . . 4		6.2. Result Forgeries . . . . . . . . . . . . . . . . . . . . . 5
			6.3. New Schemes with Small Signatures . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 5		7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
	7.2. Informative References . . . . . . . . . . . . . . . . . . 5		7.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Appendix A. Authentication-Results Examples . . . . . . . . . . . 5		Appendix A. Authentication-Results Examples . . . . . . . . . . . 6
	A.1. Multiple DKIM Signatures with One Failure . . . . . . . . . 6		A.1. Multiple DKIM Signatures with One Failure . . . . . . . . . 6
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 7		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	[AUTHRES] defined a new header field for electronic mail messages		[AUTHRES] defined a new header field for electronic mail messages
	that presents the results of a message authentication effort in a		that presents the results of a message authentication effort in a
	machine-readable format. Absent from that specification was the		machine-readable format. Absent from that specification was the
	means by which the results of two cryptographic signatures, such as		means by which the results of two cryptographic signatures, such as
	those provided by [DKIM], can both have results reported in an		those provided by [DKIM], can both have results reported in an
	skipping to change at page 3, line 40		skipping to change at page 3, line 40
	can be associated with a given signature provided the signatures are		can be associated with a given signature provided the signatures are
	all unique within one of the registered values (e.g. all of them had		all unique within one of the registered values (e.g. all of them had
	unique "header.d" or "header.i" values). This is not guaranteed,		unique "header.d" or "header.i" values). This is not guaranteed,
	however; a single signing agent might have practical reasons for		however; a single signing agent might have practical reasons for
	affixing multiple signatures with the same "d=" values while varying		affixing multiple signatures with the same "d=" values while varying
	other signature parameters. This means one could get a "dkim=pass"		other signature parameters. This means one could get a "dkim=pass"
	and "dkim=fail" result simultaneously on verification which is		and "dkim=fail" result simultaneously on verification which is
	clearly ambiguous.		clearly ambiguous.
	It is thus necessary either to create or to identify a signature		It is thus necessary either to create or to identify a signature
	attribute guaranteed to be unique such that unambiguous association		attribute guaranteed to be unique, such that it is possible to
	of a result with the signature to which it refers is possible.		unambiguously associate a result with the signature to which it
			refers.
	It is known that SHA1 and SHA256 hash spaces are resilient to		It is known that SHA1 and SHA256 hash spaces are resilient to
	collisions, and further that RSA key signing mechanisms are similarly		collisions, and further that RSA key signing mechanisms are similarly
	resilient to common substrings. Thus, the actual digital signature		resilient to common substrings. Thus, the actual digital signature
	for a cryptographic signing of the message is an ideal property for		for a cryptographic signing of the message is an ideal property for
	such a unique identification. It is not however necessary to include		such a unique identification. It is not however necessary to include
	the entire digital signature in an [AUTHRES] header field just to		the entire digital signature in an [AUTHRES] header field just to
	identify which result goes with signature; since the signatures will		identify which result goes with signature; since the signatures will
	almost always be substantially different, it is anticipated that only		almost always be substantially different, it is anticipated that only
	the first several bytes of a signature will be needed for		the first several bytes of a signature will be needed for
	disambiguating results.		disambiguating results.
	4. Definition		4. Definition
	This memo adds to the "Email Authentication Method Name Registry",		This memo adds to the "Email Authentication Method Name Registry",
	created by IANA upon publication of [AUTHRES], the "header.b"		created by IANA upon publication of [AUTHRES], the "header.b"
	reporting item. The value associated with this item in the header		reporting item. The value associated with this item in the header
	field MUST be at least the first eight characters of the digital		field MUST be at least the first eight characters of the digital
	signature (the "b=" tag from a DKIM-Signature) for which a result is		signature (the "b=" tag from a DKIM-Signature) for which a result is
	being relayed, and MUST be long enough to be unique among the results		being relayed, and MUST be long enough to be unique among the results
	being reported. Matching of the value of this item against the		being reported. Where the total length of the digital signature is
	signature itself MUST be case-sensitive.		fewer than eight characters, the entire signature MUST be included.
			Matching of the value of this item against the signature itself MUST
			be case-sensitive.
	If an evaluating agent observes that, despite the use of this		If an evaluating agent observes that, despite the use of this
	disambiguating tag, unequal authentication results are offered about		disambiguating tag, unequal authentication results are offered about
	the same signature from the same trusted authserv-id, that agent		the same signature from the same trusted authserv-id, that agent
	SHOULD ignore all such results.		SHOULD ignore all such results.
	5. IANA Considerations		5. IANA Considerations
	Per [IANA-CONSIDERATIONS], the following item is added to the "Email		Per [IANA-CONSIDERATIONS], the following item is added to the "Email
	Authentication Method Name Registry":		Authentication Method Name Registry":
	skipping to change at page 4, line 44		skipping to change at page 4, line 47
	6. Security Considerations		6. Security Considerations
	[AUTHRES] discussed general security considerations regarding the use		[AUTHRES] discussed general security considerations regarding the use
	of this header field. The following new security considerations		of this header field. The following new security considerations
	apply when adding or processing this new ptype/property combination:		apply when adding or processing this new ptype/property combination:
	6.1. Improvement		6.1. Improvement
	Rather than introducing a new security issue, this can be seen to fix		Rather than introducing a new security issue, this can be seen to fix
	a security weakness of the original specification in that useful		a security weakness of the original specification: Useful information
	information can now be obtained from results that could previously		can now be obtained from results that could previously have been
	have been ambiguous and thus obscured or, worse, misinterpreted.		ambiguous and thus obscured or, worse, misinterpreted.
	6.2. Result Forgeries		6.2. Result Forgeries
	An attacker could copy a valid signature and add it to a message in		An attacker could copy a valid signature and add it to a message in
	transit, modifying some portion of it. This could cause two results		transit, modifying some portion of it. This could cause two results
	to be provided for the same "header.b" value even if the entire "b="		to be provided for the same "header.b" value even if the entire "b="
	string is used in an attempt to differentiate the results. This		string is used in an attempt to differentiate the results. This
	attack could cause an ambiguous result to be relayed and possibly		attack could cause an ambiguous result to be relayed and possibly
	neutralize any benefit given to a "pass" result that would have		neutralize any benefit given to a "pass" result that would have
	otherwise occurred, possibly impacting the delivery of valid		otherwise occurred, possibly impacting the delivery of valid
	messages.		messages.
	It is worth noting, however, that a false negative ("fail") can be		It is worth noting, however, that a false negative ("fail") can be
	generated in this way, but it is extremely difficult to create a		generated in this way, but it is extremely difficult to create a
	false positive ("pass") through such an attack. Thus, a cautious		false positive ("pass") through such an attack. Thus, a cautious
	implementation could discard the false negative in that instance.		implementation could discard the false negative in that instance.
			6.3. New Schemes with Small Signatures
			Should a new signing scheme be introduced with a signature whose
			length is less than eight characters, Section 4 specifies that the
			entire signature must be used. The obvious concern in such a case
			would be that the signature scheme is itself prone to collisions,
			making the the value reported by this field not useful. In such
			cases, the risk is created by the likelihood of collisions and not by
			this mechanism; furthermore, Section 4 recommends the results be
			ignored if that were to occur, preventing the application of an
			ambiguous result.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[AUTHRES] Kucherawy, M., "Message Header Field for		[AUTHRES] Kucherawy, M., "Message Header Field for
	Indicating Message Authentication Status",		Indicating Message Authentication Status",
	RFC 5451, April 2009.		RFC 5451, April 2009.
	[DKIM] Allman, E., Callas, J., Delany, M., Libbey,		[DKIM] Allman, E., Callas, J., Delany, M., Libbey,
	M., Fenton, J., and M. Thomas, "DomainKeys		M., Fenton, J., and M. Thomas, "DomainKeys
	skipping to change at page 6, line 41		skipping to change at page 7, line 4
	bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;		bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
	b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=		b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
	From: sender@newyork.example.com		From: sender@newyork.example.com
	Date: Fri, Feb 15 2002 16:54:30 -0800		Date: Fri, Feb 15 2002 16:54:30 -0800
	To: meetings@example.net		To: meetings@example.net
	Message-Id: <12345.abc@newyork.example.com>		Message-Id: <12345.abc@newyork.example.com>
	Subject: here's a sample		Subject: here's a sample
	Example 1: Header field reporting results from multiple signatures		Example 1: Header field reporting results from multiple signatures
	added at initial signing		added at initial signing
	Here we see an example of a message that was signed twice at by the		Here we see an example of a message that was signed twice at by the
	author's ADMD. One signature used "relaxed" header canonicalization		author's ADMD. One signature used "relaxed" header canonicalization
	and the other used "simple" header canonicalization; both used		and the other used "simple" header canonicalization; both used
	"simple" body canonicalization.		"simple" body canonicalization.
	Presumably due to a change in one of the five header fields covered		Presumably due to a change in one of the five header fields covered
	by the two signatures, the former signature failed to verify while		by the two signatures, the former signature failed to verify while
	the latter passed. The item registered by this memo allows an		the latter passed. In particular, the "relaxed" header
	evaluation module to determine which DKIM result goes with which		canonicalization of [DKIM] is resilient to changes in whitespace in
	signature.		the header while "simple" is not, and the latter is the one that
			failed in this example.
			The item registered by this memo allows an evaluation module to
			determine which DKIM result goes with which signature.
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	The author wishes to acknowledge the following for their review and		The author wishes to acknowledge the following for their review and
	constructive criticism of this proposal: Dave Crocker, Eliot Lear, S.		constructive criticism of this proposal: Dave Crocker, Tony Hansen,
	Moonesamy, Alessandro Vesely.		Eliot Lear, S. Moonesamy, Alessandro Vesely.
	Author's Address		Author's Address
	Murray S. Kucherawy		Murray S. Kucherawy
	Cloudmark, Inc.		Cloudmark, Inc.
	128 King St., 2nd Floor		128 King St., 2nd Floor
	San Francisco, CA 94107		San Francisco, CA 94107
	US		US
	Phone: +1 415 946 3800		Phone: +1 415 946 3800
End of changes. 12 change blocks.
	20 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/