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?
- Roland
_______________________________________________
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)
