[ietf-dkim] Output summary

[Hector Santos]

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 
>>> specification.
>>
>> -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
>> design.

> 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 
inconsistence.

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 
considered.

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
http://www.santronics.com
http://santronics.blogspot.com