This is to document some research related to this issue: IANA Registry ------------------- After reviewing the IANA registry, these headers appear to be appropriate only for a message originator, and are therefore candidates for inclusion in an originator's DKIM signature:
Accept-Language Bcc Cc Content-Return Date Disposition-Notification-Options Disposition-Notification-To Encoding Expires Expiry-Date >From Importance In-Reply-To Message-Context References Reply-To Subject Supersedes To Conversely, these headers appear inappropriate for use by a message originator, and are therefore never appropriate for an originator's DKIM signature ARC-Authentication-Results ARC-Message-Signature ARC-Seal Authentication-Results Downgraded-Final-Recipient Downgraded-In-Reply-To Downgraded-Message-Id Downgraded-Original-Recipient Downgraded-References PICS-Label Received Received-SPF There are, of course, many others which I have not put in either group. Operational Usage ------------------------- I have also sample some messages to see what fields are included in those message signatures. What immediately becomes clear is that there is a wide variety in the headers being included. 1) These fields are used with some frequency in observed signatures, but I withhold judgement as I am not fluent in MIME. mime-version content-type content-transfer-encoding; 2) Some senders also use duplicate entries in the field list to enforce architectural uniqueness. This seems like a best practice: From, To, Subject, Date, Reply-To, Message-id 3) Some mass mailers use List-* headers to identify their mailing list and include those fields in the signature. This will of course cause the signature to fail if the message is delivered to a mailing list, but that is a risk they are willing to take. 4) My sample demonstrated that there are common omissions: "date", "to", "cc", and "subject" are part of the user presentation, and should be protected. In my sample, "subject" was the only one of these headers that was always included. "reply-to" must be protected to prevent replies from being misdirected. Malicious tampering with this header is probably the most worrisome "message-id" needs to be protected for "in-reply-to" to provide correct conversational grouping of replies. "in-reply-to" also needs to be protected for correct conversational grouping of replies Design Considerations ------------------------------ DMARC PASS is understood to mean that the original document is preserved in all important respects, which includes user-visible content and function-affecting content such as reply-to. Therefore, an adequate DKIM signature should include the minimum list of fields needed to accomplish this purpose. Our document needs to help administrators know what headers to include. Alternatives to specifying a minimum list ----------------------------------------------------- 1) Malicious in-transit modifications are rare, and DKIM signature construction is mostly adequate, so the likelihood of a successful attack is low. Round down to zero, say nothing about the potential for inadequate signature construction, and hope nobody complains during subsequent review. 2) Document the concern that poorly constructed signatures could be a problem, and advise evaluators to create their own defense rules to handle the risk. This seems certain to create interoperability problems, because a message sender must anticipate and satisfy the unpublished requirements of each recipient Those evaluator requirements may even be mutually incompatible. I don't see that either of these alternatives are acceptable. Doug Foster On Sat, Oct 29, 2022 at 1:30 AM Neil Anuskiewicz <n...@marmot-tech.com> wrote: > > > On Oct 27, 2022, at 10:46 PM, Murray S. Kucherawy <superu...@gmail.com> > wrote: > > > On Thu, Oct 27, 2022 at 4:16 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Murray raised the issue of a signature which produces PASS, but lacks >> trust because it is constructed with weak coverage, such as omitting the >> Subject or including an L=valuie clause. >> >> DKIM was designed to be flexible so that it could be used for many >> purposes. DMARC is a specific purpose and therefore it needs a more >> specific definition of what a signature should and should not contain. I >> am proposing that we ensure that all signatures used for DMARC follow a >> content standard so that all compliant signatures are equally trustworthy. >> >> For DMARC, an aligned DKIM PASS should preserve the originator's content, >> identity, and disposition instructions. Any header that might >> legitimately be added or removed by a downstream MTA should not be included >> in the original DKIM signature, as these are likely to produced false DKIM >> FAIL. >> >> Here is a first-pass list of headers that meet these objectives: >> >> Date >> To >> From >> Subject >> Body (absence of L=value) >> Reply-To >> In-Reply-To >> Authenticated-As >> >> > This feels like a layering violation to me, if we accept the model that > DMARC is a layer atop DKIM. > > Also, DKIM already provides advice of this nature. RFC 4871 actually > listed the header fields we thought SHOULD be signed, but this was removed > in RFC 6376 in favor of more general guidance to select header fields that > preserve the intent of the message. I think that's enough for DMARC. > > Finally, "Authenticated-As" isn't a known header field (or, at least, it's > not in the registry). > > > DKIM can do whatever it wants. It can sign with unaligned domains, it can > sign whatever it wants. DMARC as the policy layer can be choosy. It can > decide that the signing domain must align with the Header From. Nobody > suggests that’s not DMARC’s turf to pass judgements signing domains. > > DMARC’s job is to flat out prevent unauthorized spoofing. It’s not a > stretch to imagine some higher signature standard without feeling like > you’re on DKIM’s turf. > > Neil >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
