Subject: [ietf-dkim] Issues summary from IETF65 meeting

From: DKIM Chair <[email-masked]>
Date: Tue, 28 Mar 2006 12:05:50 -0500

Here is the promised summary of the issues presented at IETF65, and my
interpretation of the resolution.  I've made a vague distinction here
between "Open", meaning that the issue still needs work, and
"Accepted", meaning that the issue's accepted and is being resolved,
and the resolution will be confirmed on the mailing list when the
related text (or the next iteration of the draft) is posted.

Items with a status of "Close" or "Reject" will be closed when the
minutes are accepted (I will merge this into the minutes).  Items with
a status of "Accept" are essentially resolved, and will be closed after
review of the associated text.  Items marked "Open" need further
discussion here.

-------------------------------------------------------
Threats issues:

1171: Clarification of the DKIM mechanism in introduction
Close, use current text

1172: Impact of signed message replay
Reject, consensus to leave as "Low"

1221: ABNF: Sender = Originator / Operator
Accept, Dave will give Jim a list of changes

Base issues:

1183: Should we have an r= tag in either the signature or key record
Open, take to mailing list

1184: Develop plan for transition of multiple crypto algs (a=)
Open, take to mailing list

1185: Transition sha-1 to sha-256
Accept, proposed wording

1193: instead of signing the message, sign the hash
Open, take to mailing list

1194: whitespace in signature?
Accept, check grammar for CFWS vs FWS

1195: 3.4.6 Example (Canonicalization)
Open, Hector must provide text, Paul will describe examples he'd like
to see

1196: Upgrade indication and protection against downgrade attacks
Open, some support for list of what I sign, some think it doesn't
matter; security area suggest that verifier decides what's OK

1200: MUST vs SHOULD in Verifier Actions section
Accept, Eric will propose text changes

1201: change the syntax from SPF compat to human compat
SSP issue, deferred until then

1203: extendable RR records
Accept, editorial issue for Eric

1204: issue with DKIM simple header algorithm and milter-based
implementations
Accept, Eric will add text warning about this issue with "simple"

1215: clarifications on use of l= tag
Close, Eric has edited text

1216: signature h= and z= tags
Open; clarify, h= required, z= optional and diagnostic, independent
(decoupled); take to mailing list

1222: ABNF: Sender = Originator / Operator
Accept, Dave will give Eric a list of changes

1224: DKIM and mailing lists
Open, continue on mailing list

1226: 512 too short?
Accept, use Russ's text

1227: bunch of nits for base
Accept, editorial issues for Eric

1228: Why is s= REQUIRED?
Reject, consensus NOT to have default selector

1229: z= field and EAI wg
Open, investigate EAI work

1230: selectors and key rollover
Close, leave as is, ASRG may discuss in BCP

1231: some process-problematic references in base
Open, must address as RR doc forms (Authentication-Results already
handled)

1235: Clarify delegation to 3rd parties
Accept, Eric will propose wording to clarify

1236: Analyzing Failures: List of Possible Reasons
Accept, Eric will edit

Extra: x= and clock skew
Resolution unclear; remove x=?; recommend (secure) NTP?
I think we need to open an issue on this one, Eliot.
-------------------------------------------------------

Corrections welcome....

For completeness, let me add two new issues that have been opened since
IETF65:

-------------------------------------------------------
1247: threats... (EKR) review of threats-01
Accept, Jim resolving, reviewing with EKR

1255: base... optional exponent needed or not?
Open, discuss on mailing list
-------------------------------------------------------

Barry Leiba, DKIM Working Group co-chair  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html