Subject: [ietf-dkim] Draft DKIM agenda for Dallas.

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2006 16:50:46 +0000

Hi all,

Here's a draft agenda for Dallas.

The main idea is to only discuss threats and base in the first session.
Therefore any SSP related issues, presentations, proposals etc are for
the 2nd session. Same applies for any liaison type slots requested.
If discussion of base takes more time, then that item will carry over
to the second session.

Anyone who wants to get on the agenda please mail the chairs with
your topic, how long you think you need and where it fits (one of
items 3,5,8 or 9).

Note that we plan to start the WG last call for the threats document
before the meeting (assuming Jim has a chance to re-issue before
the I-D cutoff). We plan to have the WG last call run to the end of
the meeting, and then (all going well) to submit a version to the AD
just after Dallas.

Regards,
Stephen & Barry.

session 1

1. agenda bashing (chairs, 5)
2. threats (Fenton, 40)
	- discuss and close (modulo list ok) all remaining issues
3. AOB related to threats (?, 10)
4. base (Allman, 50)
	- discuss each open issue
5. AOB related to base (?, 15)

session 2

6. agenda bash (chairs, 5)
7. SSP (Allman, 20)
	- open issues and options
8. AOB related to SSP (?, 15)
9. AOB generally (?, 20)

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Feb 2006 09:11:19 -0800

> the 2nd session. 

Sounds good.

> 8. AOB related to SSP (?, 15)

AOB mean Any Other Business?

So the allocations for Fenton on Threats and Allman on Base are supposed to be 
about direct discussion intended to close open issues, rather than tutorial or 
explanation work?

If so, the allocation for the first session sounds great.  It nicely focuses on 
the priority of our initial deliverables and nicely presumes that those 
participating are already well-versed in the details of the documents.

One thought:

I suggest is that we consider agreeing -- before the meeting -- that the agenda 
of the second session depends entirely upon completion of the first session's 
tasks.

That is, I suggest that we strictly adhere to the first session's schedule, even 
if -- for example -- it means terminating the Threats discussion before we have 
closed everything.  And then the first priority of the second session is to 
continue anything pending from the first session, until the first session topics 
are completed.  And *then* we can move to SSP.

This might seem entirely obvious and/or picking at too much detail and/or like 
something to wait and see, and perhaps consider during the session.

However I think the vagaries of the ietf-dkim group make it worth agreeing our 
agreeing about this prioritization beforehand. That way we needn't spend time 
debating it during either session.

Given our tendency to slip into SSP discussion, the more clear we are that we 
need to finish Threats and Core, first, the better.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 21 Feb 2006 13:32:45 -0600

> I suggest is that we consider agreeing -- before the meeting -- that
 > the agenda of the second session depends entirely upon completion of
 > the first session's tasks.

I agree.  We have such a tight timeframe to complete these tasks that if 
we are to have any hope of meeting it we must concentrate our efforts 
rather than wander around too much.  Just my view.

-- 
Arvel

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2006 20:20:36 +0000

> AOB mean Any Other Business?

Yep.

> So the allocations for Fenton on Threats and Allman on Base are supposed 
> to be about direct discussion intended to close open issues, rather than 
> tutorial or explanation work?

Yep.

> I suggest is that we consider agreeing -- before the meeting -- that the 
> agenda of the second session depends entirely upon completion of the 
> first session's tasks.

That was our intent, but its probably a good idea to be very clear about
it like this, so thanks for the clarification.

S.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Feb 2006 09:03:49 +0100

For those keeping score, here are the open issues.

*1170 <https://rt.psg.com/Ticket/Display.html?id=1170>* 	* Introduction
lacks the introduction of SSP
<https://rt.psg.com/Ticket/Display.html?id=1170>* 	new 	dkim 	Nobody 	0

	[email-masked] 	4 weeks ago 	
	4 weeks ago 	0
*1171 <https://rt.psg.com/Ticket/Display.html?id=1171>*
*draft-ietf-dkim-threats-00 Clarification of the DKIM mechanism
<https://rt.psg.com/Ticket/Display.html?id=1171>* 	new 	dkim 	Nobody 	0

	[email-masked] 	4 weeks ago 	
	4 weeks ago 	0
*1172 <https://rt.psg.com/Ticket/Display.html?id=1172>* 	*disagreement
on impact and probability of Attacks Against Message Signatures
<https://rt.psg.com/Ticket/Display.html?id=1172>* 	new 	dkim 	Nobody 	0

	[email-masked] 	4 weeks ago 	
	4 weeks ago 	0
*1173 <https://rt.psg.com/Ticket/Display.html?id=1173>* 	*Does Section
4.1.4 properly address traceability and accountability?
<https://rt.psg.com/Ticket/Display.html?id=1173>* 	new 	dkim 	Nobody 	0

	[email-masked] 	4 weeks ago 	
	4 weeks ago 	0
*1174 <https://rt.psg.com/Ticket/Display.html?id=1174>*
*raft-ietf-dkim-threats-00 Limited information in a critical section
<https://rt.psg.com/Ticket/Display.html?id=1174>* 	new 	dkim 	Nobody 	0

	[email-masked] 	4 weeks ago 	
	4 weeks ago 	0
*1180 <https://rt.psg.com/Ticket/Display.html?id=1180>*
*draft-ietf-dkim-threats-00 DKIM can be effective within the
Originator's AdmD <https://rt.psg.com/Ticket/Display.html?id=1180>*
open 	dkim 	Nobody 	0

	[email-masked] 	3 weeks ago 	
	3 weeks ago 	0
*1181 <https://rt.psg.com/Ticket/Display.html?id=1181>* 	*Misleading
figure in 1.1 <https://rt.psg.com/Ticket/Display.html?id=1181>* 	new
dkim 	Nobody 	0

	[email-masked] 	3 weeks ago 	
	3 weeks ago 	0
*1182 <https://rt.psg.com/Ticket/Display.html?id=1182>* 	*Eavesdropping
may permit man-in-the-middle as well
<https://rt.psg.com/Ticket/Display.html?id=1182>* 	new 	dkim 	Nobody 	0

	[email-masked] 	3 weeks ago 	
	3 weeks ago 	0
*1183 <https://rt.psg.com/Ticket/Display.html?id=1183>* 	*carryover:
draft-allman-dkim-base-01.txt - Should we have an r= tag in either the
signature or key record
<https://rt.psg.com/Ticket/Display.html?id=1183>* 	new 	dkim 	Nobody 	0

	[email-masked] 	3 weeks ago 	
	3 weeks ago 	0
*1184 <https://rt.psg.com/Ticket/Display.html?id=1184>* 	*carryover:
Develop plan for transition of multiple crypto algs (a=)
<https://rt.psg.com/Ticket/Display.html?id=1184>* 	new 	dkim 	Nobody 	0

	[email-masked] 	3 weeks ago 	
	3 weeks ago 	0
*1185 <https://rt.psg.com/Ticket/Display.html?id=1185>* 	*carryover:
draft-allman-dkim-base-01.txt Transition sha-1 to sha-256
<https://rt.psg.com/Ticket/Display.html?id=1185>* 	new 	dkim 	Nobody 	0

	[email-masked] 	3 weeks ago 	
	3 weeks ago 	0
*1186 <https://rt.psg.com/Ticket/Display.html?id=1186>* 	*4.2 needs new
Attack Item: Inconsistent Signature vs Policy Attacks
<https://rt.psg.com/Ticket/Display.html?id=1186>* 	new 	dkim 	Nobody 	0

	[email-masked] 	3 weeks ago 	
	3 weeks ago 	0
*1190 <https://rt.psg.com/Ticket/Display.html?id=1190>* 	*base-00 3.5 x=
<https://rt.psg.com/Ticket/Display.html?id=1190>* 	new 	dkim 	Nobody 	0

	[email-masked] 	9 days ago 	
	9 days ago 	0
*1192 <https://rt.psg.com/Ticket/Display.html?id=1192>* 	*TLD key
publication and signing
<https://rt.psg.com/Ticket/Display.html?id=1192>* 	new 	dkim 	Nobody 	0

	[email-masked] 	7 days ago 	
	7 days ago 	0
*1193 <https://rt.psg.com/Ticket/Display.html?id=1193>* 	*base spec:
instead of signing the message, sign the hash
<https://rt.psg.com/Ticket/Display.html?id=1193>* 	new 	dkim 	Nobody 	0

	[email-masked] 	7 days ago 	
	7 days ago 	0
*1194 <https://rt.psg.com/Ticket/Display.html?id=1194>* 	*base spec:
whitespace in signature?
<https://rt.psg.com/Ticket/Display.html?id=1194>* 	new 	dkim 	Nobody 	0

	[email-masked] 	7 days ago 	
	7 days ago 	0
*1195 <https://rt.psg.com/Ticket/Display.html?id=1195>*
*draft-ietf-dkim-base-00 - 3.4.6 Example (Canonicalization)
<https://rt.psg.com/Ticket/Display.html?id=1195>* 	new 	dkim 	Nobody 	0

	[email-masked] 	6 days ago 	
	6 days ago 	0
*1196 <https://rt.psg.com/Ticket/Display.html?id=1196>* 	*Base: Upgrade
indication and protection against downgrade attacks
<https://rt.psg.com/Ticket/Display.html?id=1196>* 	new 	dkim 	Nobody 	0

	[email-masked] 	6 days ago 	
	6 days ago 	0
*1200 <https://rt.psg.com/Ticket/Display.html?id=1200>* 	*MUST vs SHOULD
in Verifier Actions section (-base)
<https://rt.psg.com/Ticket/Display.html?id=1200>* 	new 	dkim 	Nobody 	0

	[email-masked] 	4 days ago 	
	4 days ago 	0
*1201 <https://rt.psg.com/Ticket/Display.html?id=1201>* 	*change the
syntax from SPF compat to human compat
<https://rt.psg.com/Ticket/Display.html?id=1201>* 	new 	dkim 	Nobody 	0

	[email-masked] 	4 days ago 	
	4 days ago 	0
*1203 <https://rt.psg.com/Ticket/Display.html?id=1203>* 	*extendable RR
records? <https://rt.psg.com/Ticket/Display.html?id=1203>* 	new 	dkim
Nobody 	0

	[email-masked] 	24 hours ago 	
	24 hours ago 	0
*1204 <https://rt.psg.com/Ticket/Display.html?id=1204>* 	*issue with
DKIM simple header algorithm and milter-based implementations
<https://rt.psg.com/Ticket/Display.html?id=1204>* 	new 	dkim 	Nobody 	0

	[email-masked] 	1 min ago 	
	1 min ago 	0