[ietf-dkim] Output summary
hsantos at isdg.net
Thu Apr 28 13:19:18 PDT 2011
Murray S. Kucherawy wrote:
>>> The only utility in revealing failed signature information is forensics.
>>> That sort of debugging function doesn't need to go in a protocol
>> -1. It is not a debugging function.
>> It is about security (RFC4686) and deployments considerations
>> (RFC5863, see Section 7.3).
> Neither of those citations give any value to a failed signature.
Sure it does. DKIM explicits states that a failed signature is too be
promoted (or demoted depending on your perspective) to a unsigned
message. Policy security covers that.
But I also agreed that this becomes a flaw in DKIM as there is
forensic value to failure, especially when there is no policy. The
difference is the strong deterministic nature for the existence of
policy - "I declared it, don't question it." Thats the premise of an
explicitly declared policy.
>> See RFC5585 Figure 1 DKIM Service Architecture. The AUID is needed for
>> the major CSP (Checking Signing Practice) black box flow in the DKIM
> Since ADSP is predicated on the SDID, the AUID is not useful
> here. Moreover, the AUID in a failed signature is not useful as
> it could have been modified.
Thats a different issue altogether.
> And, once again, DKIM delivers those values but does not use them.
> You're talking about making a filtering decision based on them.
> Those happen in different layers. It's fine to have other layers
> do other amazing things, but we're trying to stay focused on this one.
I am not speaking of filtering and I understand the focus is output
isolated to a limited DKIM strict set.
The question is where that summary section is DKIM correct and/or
sufficient for proper DKIM Mail Integration implementation?
Limited to the two outputs (status and SDID), I believe it is not.
Rolf asked the question I have pointed out many times about the
So again from a "strict dkim" standpoint, I lean towards AUID being a
mandatory input and output. This is reinforces with the Security,
Overview and Deployment documents.
And optionally from more DKIM mail integration standpoint, if we want
to prepare for A-R, semantics about those "extended" output might be
I just think that for the sake of completing RFC4871bis, we have too
many WG-man-years of deployment and experience and limited it to a
strict DKIM definition is outdated.
So I suggest to find some WGLC compromise that finishes the job and
still makes RFC4871bis useful for today's DKIM deployment requirements.
Can that be done? I don't know.
Hector Santos, CTO
More information about the ietf-dkim