[dmarc-discuss] Multiple DKIM Signature Reporting in DMARC
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: kitterman.com pass 201803r kitterman.com fail 201803e 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. 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. 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)
Re: [dmarc-discuss] Multiple DKIM Signature Reporting in DMARC
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: kitterman.com pass 201803r kitterman.com fail 201803e 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 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)
Re: [dmarc-discuss] Multiple DKIM Signature Reporting in DMARC
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: > > > > > > > > > > kitterman.com > > pass > > 201803r > > > > > > > > > > kitterman.com > > fail > > 201803e > > > > > > > > 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)
Re: [dmarc-discuss] Multiple DKIM Signature Reporting in DMARC
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: > > > > > > > > > > > > > > > kitterman.com > > > pass > > > 201803r > > > > > > > > > > > > > > > kitterman.com > > > fail > > > 201803e > > > > > > > > > > > > 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 me
Re: [dmarc-discuss] Multiple DKIM Signature Reporting in DMARC
On 01/05/18 06:47, Brandon Long via dmarc-discuss wrote:
Another question would be, should we add the algorithm to the dkim
section to differentiate?
This is beginning to feel like "what parts of Authentication-Results
should appear in ?".
Does it make sense to:
* Add header.{a,c,s} to
https://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-methods
* Add corresponding element definitions to
?
(Is this over-engineering?)
- Roland
On Sat, Apr 21, 2018 at 11:43 PM Scott Kitterman via dmarc-discuss
mailto: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:
> >
> >
> >
> >
> > kitterman.com
> > pass
> > 201803r
> >
> >
> >
> >
> > kitterman.com
> > fail
> > 201803e
> >
> >
> >
> > 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=@ki
