Auth-Results header.b: Authentication-Results Registration for Differentiating among Cryptographic Results
A small registry addition that lets a mail checker say which DKIM signature each result belongs to.
Kucherawy, M., "Authentication-Results Registration for Differentiating among Cryptographic Results", RFC 6008, DOI 10.17487/RFC6008, September 2010, <https://www.rfc-editor.org/info/rfc6008>.
@misc{rfc6008,
series = {Request for Comments},
number = 6008,
howpublished = {RFC 6008},
publisher = {RFC Editor},
doi = {10.17487/RFC6008},
url = {https://www.rfc-editor.org/info/rfc6008},
author = {M. Kucherawy},
title = {{Authentication-Results Registration for Differentiating among Cryptographic Results}},
pagetotal = 7,
year = 2010,
month = sep,
} RFC text
Contents
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6008 Cloudmark, Inc.
Category: Standards Track September 2010
ISSN: 2070-1721
Authentication-Results Registration for Differentiating
among Cryptographic Results
Abstract
This memo updates the registry of properties in Authentication-
Results: message header fields to allow a multiple-result report to
distinguish among one or more cryptographic signatures on a message,
thus associating specific results with the signatures they represent.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6008.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6.1. Improvement . . . . . . . . . . . . . . . . . . . . . . . . 4
6.2. Result Forgeries . . . . . . . . . . . . . . . . . . . . . 4
6.3. New Schemes with Small Signatures . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Appendix A. Authentication-Results Example . . . . . . . . . . . . 6
A.1. Multiple DKIM Signatures with One Failure . . . . . . . . . 6
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 7
1. Introduction
[AUTHRES] defined a new header field for electronic mail messages
that presents the results of a message authentication effort in a
machine-readable format. Absent from that specification was the
means by which the results of two cryptographic signatures, such as
those provided by [DKIM], can both have results reported in an
unambiguous manner.
Fortunately, [AUTHRES] created IANA registries of reporting
properties, enabling an easy remedy for this problem. This memo thus
registers an additional reporting property allowing a result to be
associated with a specific digital signature.
2. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
3. Discussion
A message can contain multiple signatures of a common sender
authentication mechanism, such as [DKIM]. For example, a DomainKeys
Identified Mail (DKIM) signer could apply signatures using two or
more different message canonicalization algorithms to determine the
resistance of each to being broken in transit.
By applying supported "ptype.property" combinations (cf. the ABNF in
[AUTHRES]), a result 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 unique "header.d" or "header.i"
values). This is not guaranteed, however; a single signing agent
might have practical reasons for affixing multiple signatures with
the same "d=" values while varying other signature parameters. This
means one could get a "dkim=pass" and "dkim=fail" result
simultaneously on verification, which is clearly ambiguous.
It is thus necessary either to create or to identify a signature
attribute guaranteed to be unique, such that it is possible to
unambiguously associate a result with the signature to which it
refers.
Collisions during general use of SHA1 and SHA256 are uncommon (see
[HASH-ATTACKS]), and RSA key signing mechanisms are resilient to
producing common substrings. Thus, the actual digital signature for
a cryptographic signing of the message is an ideal property for such
a unique identification. It is not, however, necessary to include
the entire digital signature in an [AUTHRES] header field just to
identify which result goes with which signature; since the signatures
will almost always be substantially different, it is anticipated that
only the first several bytes of a signature will be needed for
disambiguating results.
4. Definition
This memo adds the "header.b" reporting item to the IANA "Email
Authentication Methods" registry created upon publication of
[AUTHRES]. The value associated with this item in the header 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 being
relayed, and MUST be long enough to be unique among the results being
reported. Where the total length of the digital signature is 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
disambiguating tag, unequal authentication results are offered about
the same signature from the same trusted authserv-id, that agent
SHOULD ignore all such results.
5. IANA Considerations
Per [IANA-CONSID], the following item is added to the "Email
Authentication Methods" registry:
+------------+----------+--------+----------------+-----------------+
| Method | Defined | ptype | property | value |
+------------+----------+--------+----------------+-----------------+
| dkim | RFC4871 | header | b | full or partial |
| | | | | value of |
| | | | | signature "b" |
| | | | | tag |
+------------+----------+--------+----------------+-----------------+
6. Security Considerations
[AUTHRES] discussed general security considerations regarding the use
of this header field. The following new security considerations
apply when adding or processing this new ptype/property combination:
6.1. Improvement
Rather than introducing a new security issue, this can be seen to fix
a security weakness of the original specification: Useful information
can now be obtained from results that could previously have been
ambiguous and thus obscured or, worse, misinterpreted.
6.2. Result Forgeries
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
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
attack could cause an ambiguous result to be relayed and possibly
neutralize any benefit given to a "pass" result that would have
otherwise occurred, possibly impacting the delivery of valid
messages.
It is worth noting, however, that a false negative ("fail") can be
generated in this way, but it is extremely difficult to create a
false positive ("pass") through such an attack. Thus, a cautious
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 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.1. Normative References
[AUTHRES] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009.
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M.,
Fenton, J., and M. Thomas, "DomainKeys Identified
Mail (DKIM) Signatures", RFC 4871, May 2007.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[HASH-ATTACKS] Hoffman, P. and B. Schneier, "Attacks on
Cryptographic Hashes in Internet Protocols",
RFC 4270, November 2005.
[IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008.
Appendix A. Authentication-Results Example
This section presents an example of the use of this new item header
field to indicate unambiguous authentication results.
A.1. Multiple DKIM Signatures with One Failure
A message that had two DKIM signatures applied by the same domain,
one of which failed:
Authentication-Results: mail-router.example.net;
dkim=pass (good signature) header.d=newyork.example.com
header.b=oINEO8hg;
dkim=fail (bad signature) header.d=newyork.example.com
header.b=EToRSuvU
Received: from newyork.example.com
(newyork.example.com [192.0.2.250])
by mail-router.example.net (8.11.6/8.11.6)
for <recipient@example.net>
with ESMTP id i7PK0sH7021929;
Fri, Feb 15 2002 17:19:22 -0800
DKIM-Signature: v=1; a=rsa-sha256; s=rashani;
d=newyork.example.com;
t=1188964191; c=relaxed/simple;
h=From:Date:To:Message-Id:Subject;
bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3=
DKIM-Signature: v=1; a=rsa-sha256; s=rashani;
d=newyork.example.com;
t=1188964191; c=simple/simple;
h=From:Date:To:Message-Id:Subject;
bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
From: sender@newyork.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: meetings@example.net
Message-Id: <12345.abc@newyork.example.com>
Subject: here's a sample
Example 1: Header field reporting results from multiple signatures
added at initial signing
Here we see an example of a message that was signed twice by the
author's ADministrative Management Domain (ADMD). One signature used
"relaxed" header canonicalization, and the other used "simple" header
canonicalization; both used "simple" body canonicalization.
Presumably due to a change in one of the five header fields covered
by the two signatures, the former signature passed, while the latter
signature failed to verify. In particular, the "relaxed" header
canonicalization of [DKIM] is resilient to changes in whitespace in
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. Without the
"header.b" portion of the result, it is unclear which one passed and
which one failed.
Appendix B. Acknowledgements
The author wishes to acknowledge the following for their review and
constructive criticism of this proposal: Dave Crocker, Tony Hansen,
Eliot Lear, S. Moonesamy, and Alessandro Vesely.
Author's Address
Murray S. Kucherawy
Cloudmark, Inc.
128 King St., 2nd Floor
San Francisco, CA 94107
US
Phone: +1 415 946 3800
EMail: msk@cloudmark.com
AI ELI5
On this page
§1The Ambiguity Problem
The Authentication-Results header field (RFC 5451) reports the outcome of message authentication in a machine-readable form. It did not provide a way to report the results of two cryptographic signatures, such as those from DKIM (RFC 4871), unambiguously.
Because RFC 5451 created IANA registries of reporting properties, the fix is simple: register one more property that ties a result to a specific digital signature.
If a letter has two stamps and the checker says "one good, one bad" without saying which, you cannot tell which stamp is the bad one.
§3Why Existing Properties Are Not Enough
A message can hold several signatures from the same mechanism. For example, a signer might use two different canonicalization algorithms to see which better survives transit.
Existing ptype.property combinations like header.d or header.i can separate results only if those values differ between signatures. A signer may have good reasons to use the same d= value on several signatures, so a verifier could produce both dkim=pass and dkim=fail with nothing to tell them apart.
The actual signature is an ideal unique identifier, since collisions with SHA1 and SHA256 are uncommon. The whole signature is not needed; the first several bytes should be enough.
Writing your name on each stamp would not help if both were signed by you. The stamp's own scribble is different every time, so a few letters of it will do.
§4The header.b Item
The memo adds header.b to the IANA "Email Authentication Methods" registry. Its value MUST be at least the first eight characters of the signature (the b= tag of a DKIM-Signature) and MUST be long enough to be unique among the results reported. If the whole signature is shorter than eight characters, all of it MUST be included. Matching against the signature MUST be case-sensitive.
If an evaluating agent still sees unequal results about the same signature from the same trusted authserv-id, it SHOULD ignore all such results.
You copy the first few letters of each stamp's scribble next to its result. If the checker still gives two different answers for one stamp, you ignore them all.
§6Security Considerations
The memo argues it fixes a weakness of the original specification, since previously ambiguous results become useful.
An attacker could copy a valid signature onto a message in transit and alter part of it, producing two results for the same header.b value even if the full b= string is used. That could relay an ambiguous result and neutralize the benefit of a pass. A false negative can be generated this way, but a false positive is extremely difficult, so a cautious implementation could discard the false negative.
If a new signing scheme has signatures shorter than eight characters, the entire signature must be used. A scheme prone to collisions would make the value not useful, but the risk comes from the collisions, and the rule to ignore unequal results prevents an ambiguous result being applied.
A sneaky person might copy a good stamp and smudge it. That can create a false "bad" mark, but it is very hard to fake a "good" one.
§7Example with Two DKIM Signatures
The appendix shows a message signed twice by the same domain, newyork.example.com. One signature used relaxed header canonicalization and one used simple; both used simple body canonicalization. The header reports dkim=pass with header.b=oINEO8hg and dkim=fail with header.b=EToRSuvU.
One of the five header fields covered by the signatures presumably changed. Relaxed canonicalization tolerates whitespace changes in the header and simple does not, so the simple one failed. Without header.b, it would be unclear which signature passed and which failed.
Two stamps, same sender. One was tough against smudges and survived; the other was not and failed. The short tag says which is which.
Authentication-Results: mail-router.example.net;
dkim=pass (good signature) header.d=newyork.example.com
header.b=oINEO8hg;
dkim=fail (bad signature) header.d=newyork.example.com
header.b=EToRSuvU