Subject: [ietf-dkim] Proposed 1368 wording draft 1

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 2 Mar 2007 06:41:03 -0800

Since we are drafting a requirement here we do not need to give the explanation in the detail given on the list.

The signing policy statement MUST be capable of fully describing a signing practice in which multiple signatures are always provided such that the policy is of utility to any verifier is capable of verifying any of the signatures that are always provided.

Such a mechanism MUST NOT
    * Require the verifier to perform any additional DNS lookups.
    * Require duplication of configuration data
    * In particular not require the policy record to provide for the 
         description of any cryptographic or cannonicalization algorithm

Rationale: The ability to specify multiple signatures is necessary in order to permit orderly transitions to new cryptographic and canonicalization algorithms. Unless the policy language is not sufficiently expressive to allow the signer to describe the actual signature practice in this case there is an opportunity for an attacker to exploit the fact that there are verifiers that do not yet support the new algorithm.

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 02 Mar 2007 08:08:30 -0800

On Fri, 2007-03-02 at 06:41 -0800, Hallam-Baker, Phillip wrote:
> Since we are drafting a requirement here we do not need to give the
> explanation in the detail given on the list.
> 
> The signing policy statement MUST be capable of fully describing a
> signing practice in which multiple signatures are always provided such
> that the policy is of utility to any verifier is capable of verifying
> any of the signatures that are always provided.
> 

Without being able to specify the critical elements that must be found
within a superseding signature, there is no assurance that a spoofed and
unsupported signature has not replaced the stronger algorithm.  Spoofing
could be accomplished by simply listing a different query mechanism.  

> Rationale: The ability to specify multiple signatures is necessary in
> order to permit orderly transitions to new cryptographic and
> canonicalization algorithms. Unless the policy language is not
> sufficiently expressive to allow the signer to describe the actual
> signature practice in this case there is an opportunity for an
> attacker to exploit the fact that there are verifiers that do not yet
> support the new algorithm.

Perhaps I do not understand your last point then.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 02 Mar 2007 17:45:12 +0000

Thanks Phill,

Since Mike has to get -03 out by Monday I've asked him to include
(some version of) your text in that and we can do a strawpoll on
its inclusion/exclusion later on. (There isn't time before the
cutoff now.)

Once -03 has issued I'll start that strawpoll so we should have
a reasonable picture of the WG opinion before Prague unless there's
a major backlog with the I-Ds,

Cheers,
Stephen.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 05 Mar 2007 16:33:01 -0000

> any of the signatures that are always provided.

+1

>     * Require the verifier to perform any additional DNS lookups.

Yes

>     * Require duplication of configuration data

Yes, but SHOULD would be enough

>          description of any cryptographic or cannonicalization algorithm

Not clear exactly what that means. For sure you need to identify various  
cryptographic or cannonicalization algorithms that you might want to say  
you always/whatever use.

Actually, since the various tags in a Dkim-Signature between them show  
clearly what variety of such algorithms have been used, it would suffice  
for the SSP to be able to say

    "When we sign, our signatures will containg the following tags"  
(doesn't have to account for _every_ tag).

Then, if you have several ways of signing, each covered by such a set of  
tags, you can then combine those statements with a variety of AND and OR  
operators.

So that allows you to say
    "We always sign with THESE tags and THOSE tags"
which was your original example that started these threads, but it also  
leaves open other things that you might want to express in the future.

Recall, that one of the features I want to see in SSP is that the notation  
can be broad and extensible, so that it can accomodate requirements and  
exploits which noone has thought of yet.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html