Archive

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 Дилян Палаузов <dilyan.palauzov@aegee.org>
wrote:

> 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=
> 40comcast.com@dmarc.ietf.org> 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: https://mailarchive.ietf.org/arch/msg/dmarc/9-V596yl2BBaUzCNaDZB1Tg1s4c/
>> 2: https://tools.ietf.org/html/rfc7489#section-7.2
>>
>> --
>> Alex Brotman
>> Sr. Engineer, Anti-Abuse & Messaging Policy
>> Comcast
>> ------------------------------
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>

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