Subject: [ietf-dkim] Strawpoll on SSP requirement 5.3.10

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Mar 2007 17:45:16 +0000

Hi All,

At today's DKIM meeting (notes to follow) we discussed
the in/exclusion of requirement 5.3.10 in ssp-reqs [1]
(the current text is below). We didn't have a clear
consensus at the meeting despite an extended discussion
and a lot of previous list traffic.

We need to decide this now in order to finish the
ssp-reqs work and to start the ssp work, so Barry and
I will collate the responses to this in a week and
we'll then make the call about what to do.

Wordsmithing is another thing, but we've discussed
this enough to decide now. So, *please* just pick
an option and don't lets divert this to discussing
a different question.

This is also Issue #1386 in the tracker [2].

Your choices:-

1) Exclude this requirement (don't mention it)
2) Include this requirement as a MUST NOT
3) Include this requirement as a MAY
4) Inlcude this requirement as a SHOULD
5) Inlcude this requirement as a MUST

The MUST/SHOULD etc. here refer to whether or not the
SSP protocol MUST/SHOULD etc. meet the requirement.

Stephen.

[1]
http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-requirements-03.txt
[2] https://rt.psg.com/Ticket/Display.html?id=1386

[PROVISIONAL] 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

            INFORMATIVE NOTE: 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: <[email-masked]>
Date: Wed, 21 Mar 2007 13:54:51 -0400

4

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Wednesday, March 21, 2007 1:45 PM
To: ietf-dkim
Subject: [ietf-dkim] Strawpoll on SSP requirement 5.3.10

Hi All,

Your choices:-

Stephen.

[1]
http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-requirements-03.
txt
[2] https://rt.psg.com/Ticket/Display.html?id=1386

         fully describing a signing practice in which multiple
signatures

            signer to describe the actual signature practice in this
case

---

From: Tony Hansen <[email-masked]>
Date: Wed, 21 Mar 2007 14:04:20 -0400

---

From: Hector Santos <[email-masked]>
Date: Wed, 21 Mar 2007 15:12:04 -0400

I prefer to vote #1.

sorry for the "comments." I'll won't debate but my reasoning is as follows:

Some of the text as written doesn't make sense.  A MUST NOT for the 
these itemize points?

The first one seems to be a compromise to appease those who might want, 
no, require a 2nd lookup in their implementation, but the author seem 
dead set to control this from happening.  Good luck!  And Its none of 
anyone's business (they have will not have any control or say in this 
process) how one who would implement configuration data. Seems totally 
misplace.

In any case, there are many things in the requirements that doesn't make 
sense and its not worth the time.  But you're polling for this one, so I 
vote to leave it out.

--
HLS

---

From: Damon <[email-masked]>
Date: Wed, 21 Mar 2007 15:30:07 -0400

4

---

From: Eric Allman <[email-masked]>
Date: Thu, 22 Mar 2007 12:05:38 +0100

1 or 3 (which I view to be semantically equivalent).

eric

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 22 Mar 2007 06:50:13 -0500

#1

Arvel

---

From: Jim Fenton <[email-masked]>
Date: Thu, 22 Mar 2007 05:43:57 -0700

> 1) Exclude this requirement (don't mention it)

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Mar 2007 05:59:36 -0700

>> 1) Exclude this requirement (don't mention it)

Ditto me

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Mar 2007 05:58:40 -0700

Ditto me

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Mar 2007 14:25:21 +0100

> 1) Exclude this requirement (don't mention it)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 22 Mar 2007 09:53:30 -0400

#1

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 22 Mar 2007 14:30:54 -0000

> 5) Inlcude this requirement as a MUST

4.

With maybe a little wordsmithing on the text, which seems a bit  
over-prescriptive.

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 22 Mar 2007 07:48:54 -0700

Option 5 MUST 

> At today's DKIM meeting (notes to follow) we discussed the 
> in/exclusion of requirement 5.3.10 in ssp-reqs [1] (the 
> current text is below). We didn't have a clear consensus at 
> the meeting despite an extended discussion and a lot of 
> previous list traffic.
> 
> We need to decide this now in order to finish the ssp-reqs 
> work and to start the ssp work, so Barry and I will collate 
> the responses to this in a week and we'll then make the call 
> about what to do.
> 
> Wordsmithing is another thing, but we've discussed this 
> enough to decide now. So, *please* just pick an option and 
> don't lets divert this to discussing a different question.
> 
> The MUST/SHOULD etc. here refer to whether or not the SSP 
> protocol MUST/SHOULD etc. meet the requirement.
> 
> Stephen.
> 
> [1]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Mar 2007 06:00:25 -0700

>> 1) Exclude this requirement (don't mention it)

Ditto me.

		Mike

---

From: Dennis Dayman <[email-masked]>
Date: Thu, 22 Mar 2007 09:26:21 -0700

---

From: John Levine <[email-masked]>
Date: 22 Mar 2007 21:12:09 -0000

---

From: Douglas Otis <[email-masked]>
Date: Fri, 23 Mar 2007 00:31:44 -0700

On Wed, 2007-03-21 at 17:45 +0000, Stephen Farrell wrote:

> 4) Include this requirement as a SHOULD

Saying SHOULD reflects the view that unless done correctly, don't do it
at all.  However, such a mechanism could prove to be highly beneficial.

-Doug