In regards to the recent threads regarding NULL/EMPTY messages, and
this thought in my last message:
> From a verification standpoint, the verifier has the design option
> to look at the l=X value to check for any DKIM NULL MESSAGE
> consideration.
>
> l=0 no hashing, bh= should be blank or not available
> l=1 SHOULD NOT HAPPEN. invalid verification
> l=2 DKIM NULL MESSAGE (see note 1)
>
> Note 1:
>
> The question here is whether we *SHOULD* allow a DKIM NON-NULL MESSAGE
> to have a l=2 value. It is kinda ridiculous and it is the worst case
> scenario for the Truncation Threat that is already documented in the
> threats document. Example, even is a body canonicalizes to:
>
> 12345678<CR><LF>
> 12345678<CR><LF>
> 12345678<CR><LF>
> 12345678<CR><LF>
> <CR><LF>
>
> Is a l=2 acceptable which means only the first 2 bytes are
> feed into the hashing engine?
>
> Maybe we can't do anything about this and it is what it is.
I was thinking it might make sense to allow the SSP DOMAIN to define a
policy attribute in its SSP record which exposes the expectation for
body truncations.
In other words, should hashing be expected to be on the entire BODY or
is partial hashing of the BODY be allowed?
I can see where many DOMAINS will not wish to allow for partial hashing.
By having a SSP policy attribute which defines this expectation, it will
remove the Truncation Security Threat Entry Point for this DKIM domain.
What this means is that if the policy says NO TRUNCATION ALLOWED, then
the L=X value can not be less than the total size of the DKIM
canonicalized message.
Comments?
---
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html