[ietf-dkim] Slides for -base discussion this afternoon

Mon Mar 20 08:36:35 PST 2006

Enclosed are the slides for the -base discussion this 
afternoon/Wednesday (hopefully not to be modified too much).  They 
are in .txt and .ppt formats.

eric
-------------- next part --------------
DKIM -base Open Issues
Eric Allman
IETF 65
March 20, 2006

carryover: draft-allman-dkim-base-01.txt - Should we have an r= tag in either the signature or key record
1183	lear at ofcourseimright.com	OPEN
no thread?
There is a thread on making r= localpart only (from Mark D)

carryover: Develop plan for transition of multiple crypto algs (a=)
1184	lear at ofcourseimright.com	OPEN
not much discussion of how to transition, though not much disagreement either
3/9: ?Not much discussion; not much disagreement?
http://mipassoc.org/pipermail/ietf/dkim/2006q1/002414.html

carryover: draft-allman-dkim-base-01.txt Transition sha-1 to sha-256
1185	lear at ofcourseimright.com	OPEN
not quite closed on the actual exact wording
[I think we had converged on MUST accept either, SHOULD generate sha-256]
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002414.html

base spec: instead of signing the message, sign the hash
1193	lear at ofcourseimright.com	OPEN
no (recent) thread
Summary: Hash the body, store that in header, hash and sign the header
Hash could be in DKIM-Signature or another header field

base spec: whitespace in signature?
1194	not sure if this is the right thread	OPEN
?Need to use appropriate folding rules for signature line (CFWS, et al)?
http://mipassoc.org/pipermail/ietf/dkim/2006q1/002464.html
(Message not found)

draft-ietf-dkim-base-00 - 3.4.6 Example (Canonicalization)
1195	hsantos at santronics.com	OPEN
no discussion
?1) Please note "relaxes" typo in 3.4.6 example:
"Assuming a "c=relaxes/relaxed" canonicalization algorithm, a message reading:?  [Fixed]
?2) Consider adding more examples to illustrate our possible algorithms and combinations.?
http://mipassoc.org/pipermail/ietf/dkim/2006q1/002148.html

Base: Upgrade indication and protection against downgrade attacks
1196 	MarkD+dkim at yahoo-inc.com	OPEN
lots of discussion, no clear closure
Summary: add tag in selector record indicating lowest algorithm that will ever be used for signing
http://mipassoc.org/pipermail/ietf/dkim/2006q1/002163.html

MUST vs SHOULD in Verifier Actions section (-base)
1200 	eric at sendmail.com	OPEN
?There are several places in the Verifier Actions section of draft-ietf-dkim-base-00 that say that a verifier MUST ignore bad or malformed signatures. This is really a local policy question, and we have been trying to stay out of that. Shall we change these to SHOULDs, or even just change these to read something like "Bad or malformed signatures MAY be ignored. This is a local policy decision and beyond the scope of this document."??

change the syntax from SPF compat to human compat
1201	MarkD+dkim at yahoo-inc.com 	OPEN
See 1217: SSP: should we drop the cryptic o=. syntax for something a little more readable?
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002219.html
Really not appropriate for this session ? SSP-specific?
extendable RR records?
1203 	tony at att.com  	ACCEPT
the title of this issue is misleading, its really about extra options to be specified in a DKIM TXT record
?We allow extra options to be specified in a DKIM-Signature header, but do not allow extra options to be specified in a DKIM TXT record. (I don't recall this being discussed before, but just may not remember it.)  Should we? If not, how would we do upwardly-compatible changes without requiring multiple DNS entries for both an old and new entry.?
[Described as part of tag-list syntax, ?3.2: ?Unrecognized tags MUST be ignored.?]
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002260.html

issue with DKIM simple header algorithm and milter-based implementations
1204 	tony at att.com 	OPEN
seemed like consensus but no clear change
Q about milter handling of white space around colons in headers
[I have a sendmail patch to fix this]
http://mipassoc.org/pipermail/ietf/dkim/2006q1/002273.html

clarifications on use of l= tag
1215	Eric Allman	OPEN
no discussion
http://mipassoc.org/pipermail/ietf/dkim/2006q1/002185.html (bad URL)
(item was confirmation of language inserted into draft)

signature h= and z= tags
1216	Hector Santos	OPEN
little discussion
Can the lists differ?  [probably SHOULD NOT]
If they do, which one wins?  [h=]
Why so complex?
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002375.html

ABNF: Sender = Originator / Operator
1222	dhc at crocker.net	OPEN
(also listed as 1221)
some discussion
Summary: never use the word ?sender? ever again (use ?originator? or ?operator? instead)
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002495.html

DKIM and mailing lists
1224	Stephen Farrell	OPEN
too much discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002534.html
http://www.sympa.org/wiki/doku.php?id=dkim_and_mailing_lists
http://mipassoc.org/pipermail/ietf-dkim/2006q1/001839.html

512 too short?
1226	Stephen Farrell	OPEN
some discussion
Summary: RSA key size should be 1024 minimum
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002620.html

bunch of nits for base
1227	Stephen Farrell	OPEN
no discussion
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002615.html

Why is s= REQUIRED?
1228	Stephen Farrell	OPEN
a tiny bit of discussion
Summary: shouldn?t there be a default selector?
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002621.html

z= field and EAI wg
1229	Stephen Farrell	OPEN
a tiny bit of discussion
?Even if it doesn't hit anywhere else, presumably the EAI work will have to be taken into account for the z= field, with potential changes being required to the current ABNF??
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002622.html

selectors and key rollover
1230	Stephen Farrell	OPEN
no discussion
Summary: Version numbers on selector names
Multiple keys per selector
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002619.html

some process-problematic references in base
1231	Stephen Farrell	OPEN
no discussion
Summary: Search for DKK first creates problematic reference (skip this and revise doc later?)
Authentication-Results  [should already be gone]
?6.6 (MUA Considerations) ? necessary/useful?
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002616.html

Clarify delegation to 3rd parties
N001	Stephen Farrell	OPEN
no discussion
?I'd like there to be a very clear consensus as to what's included here, e.g. we are not going to mandate who generates keys, so we thus cannot say whether a private key is being used for >1 sending domain. As it is, the feature is mentioned a number of times, without ever really saying what's to be supported.
?That may create potential holes. The problem is that there might be many of those.  Is there any way that this feature could be separated out into some kind of extension spec? Anyway, perhaps a section specific to delegation should be added??
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002618.html

base editorial
N002	Stephen Farrell	OPEN
no discussion
Move ?some of the text here? [?] to overview document
Provide examples at the beginning of the document to make it easier to understand
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002617.html

Analyzing Failures: List of Possible	Reasons
N003	Hector Santos	OPEN
?I think section 6.5 is a good step but we need a section that is dedicated to all the possible reasons for failures as we KNOW it to possibly to occur.  I think there should a special section:
		6.6 List of Possible Failures ??
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002694.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DKIM-base-IETF65.ppt
Type: application/vnd.ms-powerpoint
Size: 56320 bytes
Desc: not available
Url : http://mipassoc.org/pipermail/ietf-dkim/attachments/20060320/da1ba1b3/DKIM-base-IETF65-0001.ppt