Folks,
Here's my current issues list. Essentially it just adds
new issues, although some of those have already been
resolved since they were raised. Let me know if I've
missed things or gotten stuff wrong.
I'll update the draft agenda to match this in a bit, so
if you're planning to raise an issue that you want to
be sure hits the agenda, please do so now.
Doug - the issues arising from your mail [1] aren't
included, but will be if you'd like to re-send taking into
account the comments you got.
Stephen.
PS: Eliot - I think this is more or less in-whack with the
rt.psg.com tracker, but if you could check too that'd be
great.
[1] http://mipassoc.org/pipermail/ietf-dkim/2006q1/002552.html
--- Notes
Note that these states were allocated wearing our WG chair hats. If someone
wants to re-open an issue then they need to get two other list participants to
also argue their case.
All OPEN issues for threats-01 and base-00 will be on the agenda in Dallas.
Eliot will create new entires in the tracker for NNNN issues.
Explanation of states used:
PROPOSE REJECT - if no-one objects within a week then this changes to
REJECT, if someone objects it changes to OPEN
REJECT - resolved issue with no changes to be made
OPEN - still up for discussion
ACCEPT - resolved issue with a consensus change yet to be made
DONE - resolved issue with consensus change applied
-- threats issues
1170 Introduction lacks the introduction of SSP new dkim Nobody 0
hsantos(_at_)santronics(_dot_)com 6 weeks ago 6 weeks
ago 0
PROPOSE REJECT no support for change, but no discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/001883.html
1171 draft-ietf-dkim-threats-00 Clarification of the DKIM mechanism new
dkim Nobody 0
dotis(_at_)mail-abuse(_dot_)org 6 weeks ago 6 weeks ago 0
I think the title above doesn't match the thread which was
"Misstatement of the..." ?
OPEN got some support, no list opposition, but not included in
threats-01
http://mipassoc.org/pipermail/ietf-dkim/2006q1/001907.html
1172 disagreement on impact and probability of Attacks Against Message
Signatures new dkim Nobody 0
dotis(_at_)mail-abuse(_dot_)org 6 weeks ago 6 weeks ago 0
OPEN some discussion, no clear consensus to change or not
http://mipassoc.org/pipermail/ietf-dkim/2006q1/001910.html
1173 Does Section 4.1.4 properly address traceability and accountability?
new dkim Nobody 0
dotis(_at_)mail-abuse(_dot_)org 6 weeks ago 6 weeks ago 0
REJECT no support for change
http://mipassoc.org/pipermail/ietf-dkim/2006q1/001909.html
1174 raft-ietf-dkim-threats-00 Limited information in a critical section
new dkim Nobody 0
dotis(_at_)mail-abuse(_dot_)org 6 weeks ago 2 days ago 0
REJECT no support for change
http://mipassoc.org/pipermail/ietf-dkim/2006q1/001908.html
1180 draft-ietf-dkim-threats-00 DKIM can be effective within the
Originator's AdmD open dkim Nobody 0
dotis(_at_)mail-abuse(_dot_)org 5 weeks ago 5 weeks ago 0
REJECT no support for change
http://mipassoc.org/pipermail/ietf-dkim/2006q1/001941.html
1181 Misleading figure in 1.1 new dkim Nobody 0
nobody(_at_)xyzzy(_dot_)claranet(_dot_)de 5 weeks ago
5 weeks ago 0
PROPOSE REJECT no support for change, editor opposed but no other
discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002471.html
1182 Eavesdropping may permit man-in-the-middle as well new dkim
Nobody 0
dotis(_at_)mail-abuse(_dot_)org 5 weeks ago 5 weeks ago 0
PROPOSE REJECT no support for change, no discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002008.html
1186 4.2 needs new Attack Item: Inconsistent Signature vs Policy Attacks
new dkim Nobody 0
hsantos(_at_)santronics(_dot_)com 5 weeks ago 5 weeks
ago 0
DONE - new SSP attack added to threats-1 (section 4.2.6)
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002015.html
1192 TLD key publication and signing new dkim Nobody 0
Mike(_dot_)Markley(_at_)bankofamerica(_dot_)com 3 weeks ago
3 weeks ago 0
DONE - new threat added to threats-01 in section 4.1.18
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002152.html
1206 Threats Issue - Large DNS records make servers targets for spoofed
source amplification attacks abuse new dkim Nobody 0
william(_at_)elan(_dot_)net
DONE - threats-01 has a new section 4.3.1 just for this.
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002435.html
NNNN Threat-00 Limiting the scope of trust
dotis(_at_)mail-abuse(_dot_)org
REJECT - no consenus on this change
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002073.html
1219 A bunch of nits on threats-01 document
Stephen Farell
ACCEPT - no real problem closing this
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002485.html
NNNN threats-01 over prescriptive about key delegation
Stephen Farell
ACCEPT - new wording agreed
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002486.html
1220 Include new "known message replay" threat?
Stephen Farell
OPEN - no discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002486.html
1222 ABNF: Sender = Originator / Operator
dhc(_at_)crocker(_dot_)net
OPEN - some discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002495.html
-- base issues
1183 carryover: draft-allman-dkim-base-01.txt - Should we have an r= tag in
either the signature or key record new dkim Nobody 0
lear(_at_)ofcourseimright(_dot_)com 5 weeks ago 5 weeks
ago 0
OPEN
no thread?
1184 carryover: Develop plan for transition of multiple crypto algs (a=)
new dkim Nobody 0
lear(_at_)ofcourseimright(_dot_)com 5 weeks ago 5 weeks
ago 0
OPEN - not much discussion of how to transition, though not much
disagreement either
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002414.html
1185 carryover: draft-allman-dkim-base-01.txt Transition sha-1 to sha-256
new dkim Nobody 0
lear(_at_)ofcourseimright(_dot_)com 5 weeks ago 5 weeks
ago 0
OPEN - not quite closed on the actual exact wording
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002414.html
1190 base-00 3.5 x= new dkim Nobody 0
nobody(_at_)xyzzy(_dot_)claranet(_dot_)de 3 weeks ago
3 weeks ago 0
REJECT - change opposed, proposer accepted leaving MUST
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002131.html
1193 base spec: instead of signing the message, sign the hash new
dkim Nobody 0
lear(_at_)ofcourseimright(_dot_)com 3 weeks ago 3 weeks
ago 0
OPEN
no (recent) thread
1194 base spec: whitespace in signature? new dkim Nobody 0
eric(_at_)sendmail(_dot_)com 3 weeks ago 3 weeks ago 0
OPEN - not sure if this is the right thread
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002464.html
1195 draft-ietf-dkim-base-00 - 3.4.6 Example (Canonicalization) new
dkim Nobody 0
hsantos(_at_)santronics(_dot_)com 2 weeks ago 2 weeks
ago 0
OPEN - no discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002148.html
1196 Base: Upgrade indication and protection against downgrade attacks
new dkim Nobody 0
MarkD+dkim(_at_)yahoo-inc(_dot_)com 2 weeks ago 2 weeks
ago 0
OPEN - lots of discussion, no clear closure
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002163.html
1200 MUST vs SHOULD in Verifier Actions section (-base) new dkim
Nobody 0
eric(_at_)sendmail(_dot_)com 2 weeks ago 2 weeks ago 0
OPEN
not sure which thread
1201 change the syntax from SPF compat to human compat new dkim
Nobody 0
MarkD+dkim(_at_)yahoo-inc(_dot_)com 2 weeks ago 2 weeks
ago 0
OPEN
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002219.html
1203 extendable RR records? new dkim Nobody 0
tony(_at_)att(_dot_)com 2 weeks ago 2 weeks ago 0
ACCEPT - the title of this issue is misleading, its really about extra
options to be specified in a DKIM TXT record
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002260.html
1204 issue with DKIM simple header algorithm and milter-based
implementations new dkim Nobody 0
tony(_at_)att(_dot_)com 2 weeks ago 2 weeks ago 0
OPEN - seemed like consensus but no clear change
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002273.html
1215 clarifications on use of l= tag
Eric Allman
OPEN - no discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002185.html
1216 signature h= and z= tags
Hector Santos
OPEN - little discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002375.html
1222 ABNF: Sender = Originator / Operator
dhc(_at_)crocker(_dot_)net
OPEN - some discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002495.html
1224 DKIM and mailing lists
Stephen Farrell
OPEN - too much discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002534.html
NNNN bunch of nits for base
Stephen Farrell
OPEN - no disussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002615.html
NNNN some process-problematic references in base
Stephen Farrell
OPEN - no discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002616.html
NNNN base editorial
Stephen Farrell
OPEN - no discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002617.html
NNNN Clarify delegation to 3rd parties
Stephen Farrell
OPEN - no discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002618.html
NNNN selectors and key rollover
Stephen Farrell
OPEN - no discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002619.htmlo
NNNN 512 too short?
Stephen Farrell
OPEN - some discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002620.html
NNNN Why is s= REQUIRED?
Stephen Farrell
OPEN - a tiny bit of discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002621.html
NNNN z= field and EAI wg
Stephen Farrell
OPEN - a tiny bit of discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002622.html
-- SSP issues
NNNN should we drop the cryptic o=. syntax for something a little more
readable?
Mark Delaney
REJECT this is a duplicate of 1201
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002219.html
NNNN should r= be localpart only?
Mark Delaney
OPEN
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002220.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html