Another question would be, should we add the algorithm to the dkim section to differentiate?
On Sat, Apr 21, 2018 at 11:43 PM Scott Kitterman via dmarc-discuss < dmarc-discuss@dmarc.org> wrote: > On Sunday, April 22, 2018 02:12:33 PM Roland Turner via dmarc-discuss > wrote: > > On 21/04/18 05:36, Scott Kitterman via dmarc-discuss wrote: > > > As most of you already know, the DCRUP working group is adding a new > > > signature algorithm to DKIM. I have been sending dual > > > rsa-sha256/ed25519-sha256 signed mail for some time and I have notice > an > > > oddity in DMARC reporting.> > > > Typically, I'll see something like this XML snippet: > > > <auth_results> > > > > > > <dkim> > > > > > > <domain>kitterman.com</domain> > > > <result>pass</result> > > > <selector>201803r</selector> > > > > > > </dkim> > > > <dkim> > > > > > > <domain>kitterman.com</domain> > > > <result>fail</result> > > > <selector>201803e</selector> > > > > > > </dkim> > > > > > > The first one is the rsa-sha256 signature and the second, marked fail, > is > > > the ed25519-sha256 signature (I can tell based on the selector). In > all > > > cases I've checked, the correct (DMARC pass) result was obtained, but I > > > don't think this is the best way to report it. > > > > It would be helpful for the receiver to explain that the problem is an > > interoperability one rather than an asserted failure of an implemented > > algorithm, certainly. > > > > > RFC 6376 says: > > >> 3.3.4. Other Algorithms > > >> > > >> Other algorithms MAY be defined in the future. Verifiers MUST > ignore > > >> any signatures using algorithms that they do not implement. > > > > > > I'm not sure reporting a failure is consistent with "MUST ignore". In > any > > > case, I think it would be useful to distinguish between DKIM evaluation > > > failed and not evaluated due to unknown algorithm in DMARC reporting. > > > > There are half a dozen things which must be ignored if not supported > > (canonicalisations, etc.), but the obligation to ignore doesn't appear > > to imply an obligation not to report by whatever means are appropriate, > > only that the ignored elements must be removed from consideration prior > > to computing a pass. > > > > More directly, in 6.3 Interpret Results/Apply Local Policy: > > > If the email cannot be verified, then it SHOULD be treated the same > > > as all unverified email, regardless of whether or not it looks like > > > it was signed. > > > > This would appear to encourage treating 3.3.4 cases in the same way as > > all unverified email, i.e. reporting a fail, as the example you quote > > does. I do note that RFC 7601 - whose results RFC 7489 uses - > > establishes separate criteria for none, fail, policy, and neutral. It > > might be argued that neutral is a better fit for reporting the use of a > > signature algorithm not supported by the verifier: > > > > none: The message was not signed. > > > > pass: The message was signed, the signature or signatures were > > acceptable to the ADMD, and the signature(s) passed verification > > tests. > > > > fail: The message was signed and the signature or signatures were > > acceptable to the ADMD, but they failed the verification test(s). > > > > policy: The message was signed, but some aspect of the signature or > > signatures was not acceptable to the ADMD. > > > > neutral: The message was signed, but the signature or signatures > > contained syntax errors or were not otherwise able to be > > processed. This result is also used for other failures not > > covered elsewhere in this list. > > > > > > Would using neutral with some explanatory text in a human_result element > > suit, or would you advocate the addition of "unsupported" (or similar) > > to 7601 and 7489? > > I think neutral is reasonable. I'd add to the definition above that the > signature was not used for DMARC evaluation. Neutral is what multiple > implementations already report in their authentication results header > fields > for these signatures: > > Authentication-Results: mx.google.com; > dkim=neutral (no key) header.i=@kitterman.com header.s=201803e > header.b=hxFQlnEt; > > Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral > reason="invalid (unsupported algorithm ed25519-sha256)" > header.d=kitterman.com header.b=INr2EzUJ; > > Scott K > > > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well > terms (http://www.dmarc.org/note_well.html) >
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
