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 <auth_results><dkim>?".
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 <auth_results><dkim>
?
(Is this over-engineering?)
- Roland
------------------------------------------------------------------------
On Sat, Apr 21, 2018 at 11:43 PM Scott Kitterman via dmarc-discuss
<dmarc-discuss@dmarc.org <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:
> > <auth_results>
> >
> > <dkim>
> >
> > <domain>kitterman.com
<http://kitterman.com></domain>
> > <result>pass</result>
> > <selector>201803r</selector>
> >
> > </dkim>
> > <dkim>
> >
> > <domain>kitterman.com
<http://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 <http://mx.google.com>;
dkim=neutral (no key) header.i=@kitterman.com
<http://kitterman.com> header.s=201803e
header.b=hxFQlnEt;
Authentication-Results: ietfa.amsl.com <http://ietfa.amsl.com>
(amavisd-new); dkim=neutral
reason="invalid (unsupported algorithm ed25519-sha256)"
header.d=kitterman.com <http://kitterman.com> header.b=INr2EzUJ;
Scott K
_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org <mailto: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)
_______________________________________________
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)
