RFC 6008

RFC 6008: Authentication-Results Registration for Differentiating among Cryptographic Results 🎀

Part 1 of 2 💅

Okay bestie, this one is from the IETF (Internet Engineering Task Force) and it's written by M. Kucherawy from Cloudmark, Inc. 💖 It's a Standards Track document, dated September 2010, and its ISSN is 2070-1721 ✨. The big plot twist is that it updates the registry of properties in the Authentication-Results header fields, so it's adding to something that already exists. It doesn't obsolete anything. Iconic behaviour for a spec 🧚

Abstract ✨

Okay so this memo tweaks the Authentication-Results: message header field registry so one report can show results for more than one cryptographic signature on a message 🦋 That way every result gets matched up with the exact signature it's talking about. No more mixed-up vibes 💅

Status of This Memo 🌸

This is an Internet Standards Track document, so it's officially a real standard, not just a vibe.

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 📚

For the current status, any errata, and how to give feedback, go to 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) as they stand on the date this document was published. Please read these carefully, because they explain your rights and restrictions for this document 🙈 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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 💖

Okay so [AUTHRES] defined a brand-new header field for email messages that shows the results of a message authentication check in a machine-readable format ✨ The one thing it didn't cover is how to report the results of two cryptographic signatures, like the ones from [DKIM], in a way that's totally unambiguous. That's the gap 😭

Lowkey the good news is that [AUTHRES] set up IANA registries of reporting properties, so fixing this is super easy 🧚 This memo registers one extra reporting property that lets a result be linked to one specific digital signature. Main character energy 👑

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 have multiple signatures from the same sender authentication mechanism, like [DKIM] 💜 For example, a DomainKeys Identified Mail (DKIM) signer could sign with two or more different message canonicalization algorithms, so they can check how well each one holds up against being broken in transit. Iykyk 🙈

Here's the thing: you can match a result to a signature using the supported "ptype.property" combos (see the ABNF in [AUTHRES]), as long as the signatures are all unique within one of the registered values. For example, every one of them has a unique "header.d" or "header.i" value 💅 But that's not guaranteed. A single signing agent might have practical reasons to attach several signatures with the same "d=" values while changing other signature parameters. So you could end up with a "dkim=pass" and a "dkim=fail" result at the same time when you verify, which is clearly ambiguous 💀

So we need to either create or identify a signature attribute that's guaranteed to be unique, so a result can be matched to the signature it refers to without any confusion 🫶

Collisions during general use of SHA1 and SHA256 are rare (see [HASH-ATTACKS]), and RSA key signing mechanisms hold up well against producing common substrings. That makes the actual digital signature of the message an ideal unique identifier ✨ It's not required to include the whole digital signature in an [AUTHRES] header field just to tell which result goes with which signature. Since signatures are almost always really different from each other, it's expected that only the first few bytes of a signature will be needed to tell results apart 🌸

4. Definition 🎀

This memo adds the "header.b" reporting item to the IANA "Email Authentication Methods" registry, which was created when [AUTHRES] was published 🧚 The value for 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) that a result is being relayed for. It MUST also be long enough to be unique among the results being reported. If the whole digital signature is less than eight characters, then the entire signature MUST be included. And matching this value against the signature itself MUST be case-sensitive 🔥

Heads up: if an evaluating agent sees unequal authentication results about the same signature from the same trusted authserv-id, even with this disambiguating tag in place, that agent SHOULD ignore all of those results 🙈

---

Part 2 is coming next, with IANA Considerations, Security Considerations, the References, and the Appendices 💜

A.1. Multiple DKIM Signatures with One Failure ✨

okay so this one is a message that got TWO DKIM signatures from the same domain, and one of them failed 💀 the whole thing is giving "two outfits, one was a mistake" energy 🎀

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

okay so in this example the author's ADministrative Management Domain (ADMD) signed the message twice 🔥 one signature used "relaxed" header canonicalization and the other used "simple" header canonicalization, but both used "simple" body canonicalization. the vibe is very "same top, two different hems" 🧚

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. like, the "relaxed" header canonicalization from [DKIM] is resilient to changes in whitespace in the header, while "simple" is not, and the "simple" one is the one that failed here 😭 whitespace drama, honestly iconic

the item registered by this memo lets an evaluation module figure out which DKIM result goes with which signature 💅 without the "header.b" portion of the result, it's unclear which one passed and which one failed, and that's just chaos 🙈

---

Appendix B. Acknowledgements 🫶

the author wants to thank these amazing people for reviewing the proposal and giving constructive criticism 💜 Dave Crocker, Tony Hansen, Eliot Lear, S. Moonesamy, and Alessandro Vesely. literally the squad 👑

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