Subject: RE: [ietf-dkim] Are verifiers expected to query SSP on a successfulverify?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Aug 2006 10:11:50 -0700

The verifier should check the SSP record in cases where the message is insufficiently authenticated according to its local authorization policy. This could be because:

 * There is no signature
 * The signature is present does not validate
 * The signature uses an algorithm that is deprecated by the receiver
 * The signature is not by the party that the receiver would want
 * The receiver feels like doing so

It is not simply enough to have the three level policy 'I send nothing', 'I sign nothing', 'I sign everything'. That does not allow for algorithm agility which I believe is either an explicit security area requirement now or soon will be after the SHA-1 issue is addressed.

We have to allow senders to configure their systems to securely support transitions from one algorithm to another. This affects cannonicalization, digest and signing. In addition we need an escape hole to allow senders to phase in use of DKIM rather than have it be all or nothing.

Extending the policy record from the three level system to allow the selectors to be specified is a simple fix that addresses all the problems I list above and the transition use cases.

With that extension in place any further adjustments to the policy space that may be required can be achieved through appropriate management of the key selector space.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Aug 2006 18:23:02 +0100

Phill,

Hallam-Baker, Phillip wrote:
 > That does not allow for algorithm agility which I believe is either
 > an explicit security area requirement now or soon will be after the
 > SHA-1 issue is addressed.

Don't we already have alg. agility between signers and verifiers,
via the h= and k= fields of the key record?

If so, then is what you're suggesting only of use when the signer
is different from the rfc2822.From domain?

If so, do we expect that domains like that, that don't sign for
themselves, will find it useful to be specifying the acceptable
algorithms for their signed mail?

If so, hmmm....

Or maybe I missed stuff there.

S.