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

[Hallam-Baker, Phillip]

> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Hector Santos

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


The only circumstance in which we expect that the policy record will be read is when the verifier has not found a signature it trusts, i.e. :

1) There are one or more signatures that do not verify
2) The verifier does support the signature algorithm
3) The verifier does not consider the signature algorithm sufficiently secure


So if the feature is to be supported the only place to put it is in the key record as a key signing constraint.

I don't see any reason not to extend the key record to support policy objectives. We defined an extensible framework, our specification has only got to stage 1 of a three stage process. If people want all the keyrecord stuff to be in one document we can address this when we refactor the documents during the DRAFT standard stage. This does not force a recycle at PROPOSED unless we introduce new MUST criteria that are not in either PROPOSED standard.


At this point the only useful DKIM policy record I can see is 'All documents from this domain carry a DKIM signature header with a key selector that conforms to this constraint'.

This indicates to me that we should not be discussing a DKIM policy record perse but instead a policy record for outbound email that has a simple, extensible syntax that allows us to make other statements we might want to make, e.g. 'this email address is a phishing target', 'please report verification failures here', 'the outbound edge gateway always offers SSL', etc.


In other words the DKIM policy language has the following atomic statements:

DKIM               All mail carries a DKIM signature
DKIM=<suffix>      All mail carries a DKIM signature with 
                       a selector that ends in .<suffix>

If people want to allow for the case where signatures are applied less than 100% of the time we might define 'TESTING-DKIM' as a tag.

If people want to have a policy but allow some mail to go out effectively unsigned then we could introduce a NULL key record which has a selector but no data and is not therefore considered a trustworthy algorithm by any sensible verifier.