Subject: [ietf-dkim] ISSUE: New SSP Requirement - Body Truncation Limits

From: Hector Santos <[email-masked]>
Date: Wed, 10 Jan 2007 12:43:12 -0500

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 10 Jan 2007 12:29:09 -0800

Just to be clear here, I don't want to delay DKIM-BASE either.

Nor do I want us to waste time trying to fit our design to fit the publication scheme for PROPOSED. We want to take the spec to DRAFT standard so we have a chance to refactor the documents so that we have all the parts relating to the key record in one place and all the parts relating to the policy record format in one place.

I think that we can make the design of POLICY straightforward enough that we can have one document for both.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Wednesday, January 10, 2007 3:02 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] ISSUE: New SSP Requirement - Body 
> Truncation Limits
> 
> Hallam-Baker, Phillip wrote:
> 
> >> Hector Santos wrote:
> > 
> >> 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.
> > 
> > I agree that this should be a capability, but I disagree
>  > with extending the policy specification.
> > 
> > The rules of DKIM mean that any information of this type must go
>  > into the key records. If a verifier finds a valid, trusted 
> DKIM  > signature the policy record would not normally be read.
> 
> Even better. My only reason for suggesting SSP was because I 
> didn't want to further delay DKIM-BASE.  But Yes, definitely, 
> I agree with you. The consideration should be (would be more 
> appropriate) for the key record.
> 
> > So if the feature is to be supported the only place to put it
>  > is in the key record as a key signing constraint.
> 
> +1.
> 
> 
> ---
> HLS
>