Subject: [ietf-dkim] Draft DKIM minutes from IETF65

From: DKIM Chair <[email-masked]>
Date: Tue, 28 Mar 2006 08:38:27 -0500

---------------------------------------------------------
The first DKIM working group session was on Monday, 20 March 2006, from
1300 to 1500 CST, in the Cortez C/D room.

Discussion of issues for draft-ietf-dkim-threats; few issues left, open
issues covered, document should be ready for final version next week.

Discussion of issues for draft-ietf-dkim-base.  Several were minor.
Main issues:

* Issue: mailing lists.  This topic was too long to address in the
meeting, and discussion will continue on the mailing list.

* Issue: "r=" tag, specifying a "report-to" entity.  Defer
consideration to SSP document, but then we considered whether to also
have it in the key record (or something reachable through the
selector).  Further discussion to go to the mailing list.

* Issue: transition plan for new crypto algorithms, and specifically,
transition from SHA-1 to SHA-256 hashes.  Some discussion here, but
discussion ultimately deferred to the general issue of multiple
signatures.  There's also the issue that there is insufficient
experience with SHA-256 to be sure about its robustness relative to
SHA-1.  Consensus among the security folks is to let the verifier
decide which crypto is "best".  

* Issue: hashing the message separately and putting that hash into the
header, then hashing and signing the header.  In the room, consensus
for; will take to the mailing list.

* Issue: some popular mail implementations do things that make header
canonicalization of "simple" problematic.  Informative text will be
added to suggest what the signer should watch for when using "simple"
to sign.

* Lots of other minor issues, as noted above.

A handful of base issues were spilled over into the second session.

The second DKIM working group session was on Wednesday, 22 March 2006,
from 1510 to 1610 CST, in the Cortez C/D room.

We started the second DKIM session by finishing the review of the
base-spec issues with the few we hadn't gotten to on Monday.  We
briefly discussed splitting the base document (specifically to remove
references to retrieving DNS records, but there may be other things
that make sense to split out), and deferred some longer discussion to
the mailing list. 

Jim Fenton then introduced the signing policy/practices proposal and
issues; after the base document, we'll be attacking this in earnest.
The name is still in flux, with some thinking that "policy" is not the
right term, others thinking that "practices" isn't either.  We were
pointed to some work called DDDS that's been introduced in the
speermint working group, which might help us with the work (not with
the naming).

Tony Hansen introduced the DKIM Overview document that he's gotten
Phillip and Dave to work on with him.  The idea is that this document
contain informative text to explain history and decisions that it
doesn't make sense to put in the normative documents.  There was
discussion of what should go in here: some would like to have all
informative text moved here, while others point out that implementors
often don't read auxiliary documents, and everything should stay in the
base doc.  There's also the issue of how this dovetails with the DKIM
Best Practices document that the AntiSpam Research Group is planning to
do, and John Levine will work with Tony to sort that out. 

Doug Otis presented his proposal about opaque IDs and signing roles.
There was only a little discussion because time was tight.  There were
comments that this would require a lot of DNS querying, and that it
might be more interesting theoretically than practically. 

Tony briefly talked about a test message corpus that's available for
implementors to use to test their implementations. 
---------------------------------------------------------

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

---

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

In case anyone needs them, here are useful links:

Meeting materials, including agenda and slides used:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65
(search for "DKIM")

Jabber logs:
http://www.ietf.org/meetings/ietf-logs/[email-masked]/2006-03-20.html
http://www.ietf.org/meetings/ietf-logs/[email-masked]/2006-03-22.html

Audio archive:
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf65/ietf65monch2.mp3.1
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf65/ietf65wedch2.mp3.1

I will post a summary of the threats and base issues later today,
taking the items from Jim's and Eric's slides and including the
resolutions.

--

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 28 Mar 2006 10:06:34 -0500

----- Original Message -----
From: "DKIM Chair" <[email-masked]>
To: "DKIM Mailing List" <[email-masked]>
Sent: Tuesday, March 28, 2006 9:08 AM
Subject: Re: [ietf-dkim] Draft DKIM minutes from IETF65

> Audio archive:
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf65/ietf65monch2.mp3.
1
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf65/ietf65wedch2.mp3.
1

Can these be streamed?

---
Hector

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Mar 2006 18:38:38 +0200

> http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf65/ietf65wedch2.mp3.

PICKY PICKY! ;-)

Yes, I just did it with VLC.

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Mar 2006 10:07:07 -0800

On Mar 28, 2006, at 5:38 AM, DKIM Chair wrote:

>
> Doug Otis presented his proposal about opaque IDs and signing  
> roles. There was only a little discussion because time was tight.   
> There were comments that this would require a lot of DNS querying,  
> and that it might be more interesting theoretically than practically.

There was also a method to group keys.  Not every source within a  
domain is equally vetted.  A method to group keys using some  
convention to indicate properly vetted sources would allow safer  
third-party annotations, and reduce costs related to establishing  
reputations when focused upon the vetted subset.  This approach does  
not expect the recipient to be able to recognize the email-address  
and yet allows trustworthy annotations.

There was also a method to associate domains.  This could be the EHLO  
with the signing-domain, or the From email-address with the signing- 
domain.  Conventions using PTR RRsets offer a strategy to  
differentiate handling of potentially replayed messages, or messages  
signed by invalid domains.  This listing strategy would allow phished  
domains to indicate only their domain should sign their messages.   
When a domain wishes to allow a dozen of specific third-party  
signatures, annotations of trust can still indicate whether the From  
domain was within the signing-domain, and should also be affected by  
key grouping tags.  This provides far greater security than simply  
indicating third-party signatures are allowed and then expecting  
recipients to have their own white-lists.

I don't recall hearing a comment about this scheme creating excessive  
DNS queries, but as you suggested, there was no time.  The opaque- 
identifier is an option that could be used _instead_ of per-user  
keys.  The impact upon the DNS infrastructure when per-user keys are  
needed would be far greater.  As opaque-identifiers ease reporting  
and provide for opportunistic security, a means to indicate whether  
revocation is published could be possible.  If replay abuse becomes  
problematic, there must be another option available instead of per- 
user keys.  Key revocation is slowed by TTL values, and when used for  
many different users, disrupts valid emails.  Short TTLs and per-user  
keys would be highly detrimental to DNS.

Opaque-identifier revocation can be mitigated by an association of  
the EHLO domain with the signing-domain.  Even without EHLO  
mitigation, negative caching and small record size of a opaque- 
identifier compares extremely favorably to per-user keys.  This  
option could be added as a separate draft to that of the base  
document.  It would be highly beneficial to consider how a key  
grouping convention could be included in the base draft however.  A  
tag within the key, the right-most label of the key selector are  
possible solutions.  There are other schemes possible as well that  
would not disrupt backward compatibility.

-Doug

---

From: DKIM Chair <[email-masked]>
Date: Tue, 28 Mar 2006 13:44:45 -0500

I have posted the draft minutes and issues list to the IETF65 meeting
materials web site; you can find them here:
   http://www3.ietf.org/proceedings/06mar/minutes/dkim.txt

We're going to put a one-week last-call period on the minutes, so get
your comments in by the end of the day on 4 March (small changes can go
directly to me; post to the list if you want to make sure everyone sees
it).  On 5 March, we will declare them final and start taking action on
the issues list, as specified.

Doug, your note was far too detailed.  If you have some brief text that
you'd like added or changed in the minutes, post that or send it
directly to me.  But brief, for the minutes; no paragraphs of
explanation or discussion.

---

From: DKIM Chair <[email-masked]>
Date: Tue, 28 Mar 2006 14:34:14 -0500

> your comments in by the end of the day on 4 March (small changes can
> go directly to me; post to the list if you want to make sure everyone
> sees it).  On 5 March, we will declare them final and start taking
> action on the issues list, as specified.

Uh, y'all knew I meant "April" there, in both cases, not March, right?
(Thanks, Eliot...)

Barry Leiba, who doesn't know which month is which
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html