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) [email protected] 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
[email protected]
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)
