Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

Douglas Foster <> Mon, 25 January 2021 12:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DF963A1171 for <>; Mon, 25 Jan 2021 04:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id leUuBO6EzZyb for <>; Mon, 25 Jan 2021 04:21:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7FB133A1170 for <>; Mon, 25 Jan 2021 04:21:49 -0800 (PST)
Received: by with SMTP id 186so7015846vsz.13 for <>; Mon, 25 Jan 2021 04:21:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=fRLJYcu8hPQFVy2OOmDbEXdvf+hn97I+vzCvmXNaMt0=; b=Z430CwyP+BkLHxaCeESaCGyKq5Hc+P+IeQ6o7P3AK4usPKNLh7BPfxnKK4pLjER+ze sY1RArk4OiXMDBgBH5zMp7vEsLALms3sYU6WAvMcV8NWRRCOImv+HVT9mvgNyV4NQ9rj GQkP/XjQ9w6P8DC4y16lOclUGeBKfTMsdTWVCGMDptePg76U1uFjGGdAX0qQON3aL2Wl hqjq2AaVesHea3V7GGi2LI2YS4BZGD3cszLZH4R+g2xmHy5R9tVtYhGn8c/3p+sX2EfS 3C2C03e4bjTBsJESTI8Kwg2lC/desOCxRehdVAZFLX/zXVuG3iTDWNNUJ0ntMXsifsmM Juag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fRLJYcu8hPQFVy2OOmDbEXdvf+hn97I+vzCvmXNaMt0=; b=ZEx+IQbv3cgEzLrsdEW3nQRzQvxvAgkKZioJBeNPVfm1CAH+6GiUCUM61ogFZpeCfz e7XW9sXDTmkXv4C/muX76guSOvtblcOojryt37ltEQI7ie+0DKi/hy3GxXZcyR4rpuGM k51DAYXMpgew8qJlMvoiLgdmzJtIjuLjGtoHZM/ON9fu03e6vLA1cFapu13fC8SRi6CF jIavsSGKBG1BysxVUdG7a4W6yJq4I04heqezSyum6bNnVO6oVsgPU4yVMdwiFN9v43Xz R1TEcsZ4OVJt2+v5lZ2tgMJmAdZueRu8YTX2gxUzISPw6BrTrOGW8lcyhrwy0Ibknapl JlKA==
X-Gm-Message-State: AOAM532/PBaNrJN7RB/0i/HFGdVivVsp9JrEvJfpU2w7L84eufNeTWTu fb345MUoJ3EdQEjKQK+MwRKwLsczG0iE8E7uE2wU6E3nMVU=
X-Google-Smtp-Source: ABdhPJzKRlIqsGjXNmD+Qivc8+tHX2dzU7FC6s2Wm+VQFhhJz/A131gY4JhzfaBlwFL+kNCo1fRHKbgIlofExGwcQ98=
X-Received: by 2002:a67:87c2:: with SMTP id j185mr160495vsd.25.1611577308089; Mon, 25 Jan 2021 04:21:48 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Mon, 25 Jan 2021 07:21:37 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000fa10f105b9b8948a"
Archived-At: <>
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Jan 2021 12:21:52 -0000

This is an interesting issue.   Perhaps we need another ticket just to
discuss how to handle signature transition.  My first thought is that it
will be more effective to announce support for ed25519 in the report
header, rather than in each message result.  Another possibility is for a
recipient to indicate support for new signatures in the DMARC policy record.

Any report recipient will have difficulty knowing how to extrapolate from a
single result or even a single report to a general rule.    John has
observed that the RUA report does not even indicate the target domain(s)
being reported.  I would think this data inadequacy should be a priority
for correction.   For any multi-server configuration, knowing that one IP
supports the new signatures does not mean that all servers do so.    The
challenge becomes knowing whether the domain is fully transitioned, and we
don't even know the domain being evaluated.

I suspect that a day will come when a research presents evidence that the
old signatures can no longer be trusted.  At that point, PCI DSS or GDPR
will require us to quickly deprecate the old signatures, and compliant
systems will simply ignore the RSA signatures.   At that point, transition
planning is simplified.

Dual signatures also create some challenges for ARC.  I don't think an ARC
Set can reasonably include signatures under both algorithms.

Doug Foster

On Mon, Jan 25, 2021 at 12:10 AM Дилян Палаузов <>

> Hello,
> lets say a site signs an email with both rsa and ed25519 algorithms. This
> site wants to know, whether the recipient can validate the ed25519
> signatures, so that in the future rsa signing for that receiving site can
> be skipped (or errors in the ed25519 implementation fixed).
> For this to work the receiving site must put in the report information
> about each aligned dkim signature, saying which public key-name was used.
> Greetings
> Дилян
> On January 25, 2021 2:25:13 AM GMT+02:00, "Brotman, Alex" <Alex_Brotman=
>> wrote:
>> Hello folks,
>> Some time ago, an issue[1] was brought to the list where which DKIM(s) being reported is not clear in RFC7489 [2].  There was a short discussion, though no clear resolution before conversation trailed off.  It seems like there were points that may need to be discussed.  One was whether the reporting SHOULD report all signatures, regardless of alignment or validity, or perhaps just the one that aligns (if there is one).  There was also another question if there should be a limit to the number of signatures reported so that it remains sane.
>> We'd like to try to get this resolved within about two weeks.  Thank you for your feedback.
>> 1:
>> 2:
>> --
>> Alex Brotman
>> Sr. Engineer, Anti-Abuse & Messaging Policy
>> Comcast
>> ------------------------------
>> dmarc mailing list
>> _______________________________________________
> dmarc mailing list