Where does the operational guidance go? A simple review of actual messages demonstrates that there is a need for guidance. It would seem to me that a sentence or two, elucidating principles and providing guidance (not mandate), would solve the problem now.
If we leave it to each implementation to develop a policy, we are implicitly hoping that none actually do. If every implementation creates its own definition of "inadequate signature", we will have an ugly mess. DF Doug On Sun, Oct 30, 2022 at 11:13 AM Scott Kitterman <skl...@kitterman.com> wrote: > > > On October 29, 2022 5:30:07 AM UTC, 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. > > -1 or more. > > It's up to the DKIM validation software to validate DKIM signatures based > on local policy requirements. The output of the DKIM protocol is a signing > domain and a verification result. > > Having DKIM specific requirements in DMARC would be an architectural > problem. These tend to cause problems in the long run and should be > avoided. > > If this is a problem, some kind of operations guidance is the appropriate > place to solve it (e.g. if using DKIM with DMARC the following DKIM > configuration is recommended ...). DMARCbis is not the place for it. > > Scott K > > _______________________________________________ > 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
