I believe it would go in a separate applicability statement if it were going to be in an IETF document.
Scott K On October 30, 2022 5:54:20 PM UTC, Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote: >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
