[ietf-dkim] Re: canonicalized null body and dkim

[Hector Santos]

Frank Ellermann wrote:
> Hector Santos wrote:
> 
>> I'm not grasping the problem.
> 
> Apparently the canonicalization of "no body" (no CRLF CRLF) is
> different from "empty body" (only CRLF CRLF).  It's odd enough
> to mention it in the spec. (maybe as note or example).
>  
>> I think the issue is being overblown.
> 
> If your implementation treats "no body" like "empty body" and
> other implementations don't we've to agree on one way to get
> this right.  Or rather Eric has to describe it unambiguously.

Doesn't both translate to a <CRLF> for the SIMPLE c14n?

 From a signing standpoint, the signer implementation can decide for 
itself if it wants to sign a DKIM NULL MESSAGE (one that canonicalizes 
to <CRLF> only).  So here, you will have either l=0 or l=2.

 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.

In any case, algorithm wise, I think it is clear at this point, with 
Eric's additional changes.

---
HLS