Subject: [ietf-dkim] Call for agenda items

From: Barry Leiba <[email-masked]>
Date: Fri, 9 Jul 2010 12:56:30 -0400

Stephen and I need to make up an agenda for the WG meeting in
Maastricht.  We're scheduled to meet for 2.5 hours, on Wednesday
afternoon (28 July) from 13:00 to 15:30 CET (11:00 to 13:50 UTC).

We'll be talking about draft-ietf-dkim-mailinglists[1], of course.
Doug has asked for time to discuss draft-otis-dkim-tpa-label[2].
I have those on the list below; everyone please review those drafts
before the meeting.

I'd like to hear about other agenda items people have to propose, or
any other comments about the skeleton agenda below.  I'd also like a
sort of "show of hands" to let me know who's going to be attending in
person, and who will participate remotely, using the audio stream or
jabber.  Please reply to this thread with answers to these questions,
and other issues directly related to the Maastricht meeting.  (Please
take any other discussion to a separate thread.)

Here's a skeleton agenda, with no times on it yet:
1. Welcome and announcements.
2. Working group status and new charter.
3. Discussion of work item 1, RFC 4871 to Draft Standard.
    - considerations due to draft-housley-two-maturity-levels[3]
4. Discussion of work item 2, data collection for DKIM base.
5. Discussion of work item 3, data collection for ADSP.
6. Discussion of work item 5, draft-ietf-dkim-mailinglists[1].
7. Discussion of draft-otis-dkim-tpa-label[2]
8. Any other business.

-- Note that work item 4 depends upon 2 and 3, so I'm not scheduling
discussion of that at this time.

Barry, as chair

[1] http://tools.ietf.org/html/draft-ietf-dkim-mailinglists
[2] http://tools.ietf.org/html/draft-otis-dkim-tpa-label
[3] http://tools.ietf.org/html/draft-housley-two-maturity-levels
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 9 Jul 2010 13:27:29 -0600

On Jul 9, 2010, at 10:56 AM, Barry Leiba wrote:

> I'd also like a
> jabber.

I'll be there in person.

> 8. Any other business.

I haven't actually started on a draft yet, but I and some co-workers and colleagues have been thinking a lot about a standard for per-domain DKIM statistics reporting -- aggregate statistics for both successes and failures, without the message content attached.  This would obviously build on Murray's DKIM reporting extensions in the MARF WG, but since it's in aggregate it probably wouldn't fit in that WG anymore.  Would it fit here?

Also: have we beaten the recent ADSP arguments into the ground, or is there something we could accomplish in person that we didn't on the list?

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: Douglas Otis <[email-masked]>
Date: Fri, 09 Jul 2010 16:36:10 -0700

I hope to attend in person, barring any volcano's ash plum of course. :^)

The motivation to enhance ADSP is to overcome well established 
weaknesses inherent in ADSP's current form.  These weaknesses 
significantly limit where ADSP might be applied.  These limitations also 
create the unintended consequence of causing adoption of bad 
anti-phishing practices.

Since a principle motivation for ADSP is to assist in mitigating 
phishing related abuse, the mailing-list recommendation for phished 
domains to use sub-domains with non-restrictive policies is a recipe for 
increasing the number of victims, and for increasing the administrative 
costs in mitigating abuse.  As a community, we can do better.

Not all efforts at combating abuse are based upon profit motives.  
Believe it or not, those offering reputation services still confront 
litigation issues, even today.  In the past, these issues caused our our 
free service to become subscription based.  In light of the ongoing 
liabilities, offering recommendations that presume a sender's DKIM 
compliance is even more perilous.  Should such a service err on 
protecting subscribers, or limit recommendations to vanishingly few domains?

This information MUST come from senders, which is why ADSP was 
developed.  No reputation service can offer a comprehensive solution, 
especially when sending domains are increased in number as a result of 
unintended problems caused by third-party services.

The Internet represents a large community of individuals willing to 
implement comprehensive solutions able to overcome vexing issues.  These 
solutions are not always driven solely by profit motives.  The TPA-Label 
scheme is intended to provide email communities the tools for reducing a 
domain's attack surface.  ADSP, as currently defined, does just the 
opposite. Doing the right-thing with respect to authentication, is a 
different criteria than those related to spam.  While reputation might 
mitigate spam related abuses, fast-flux strategies give a major 
advantage to those phishing for victims.

Before ADSP becomes a suitable tool for dealing with this issue, it must 
become more comprehensive, and not lead to greater unrestricted 
sub-domain use.  To avoid this vexing issue, ADSP must include a 
third-party authorization scheme.  While a provider such as Gmail might 
be unable to assert a restrictive ADSP policy, their customers certainly 
could.  In other words, ADSP could become suitable for any DKIM signing 
domain, as determined by the Author Domain.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 10 Jul 2010 09:42:58 -0700

> person, and who will participate remotely, using the audio stream or

i.p.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Sat, 10 Jul 2010 09:42:12 -0700

> take any other discussion to a separate thread.)

I plan on attending remotely via the audio stream and Jabber.

-Jim

---

From: John Levine <[email-masked]>
Date: 11 Jul 2010 04:22:27 -0000

>person, and who will participate remotely, using the audio stream or

remote

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 12 Jul 2010 11:15:18 -0400

> person, and who will participate remotely, using the audio stream or

possible remote, as I'll be on vacation that week in DC.

-- 
Jeff Macdonald
Ayer, MA

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 12 Jul 2010 11:21:46 -0400

On Fri, Jul 9, 2010 at 3:27 PM, J.D. Falk <[email-masked]>wrote:

>
>
> Also: have we beaten the recent ADSP arguments into the ground, or is there
> something we could accomplish in person that we didn't on the list?
>
>

I have yet to re-read Doug's latest draft, but I believe that the concept of
tying 3rd party signatures to 1st party signatures needs to be explored now.
I'm even at the point where I wished the DKIM draft had an explicate rule
that forbid the concept of a 1st party signature (where d= is the same as
RFC5322From domain).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Jul 2010 09:07:44 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Barry Leiba
> Sent: Friday, July 09, 2010 9:57 AM
> To: IETF DKIM WG
> Subject: [ietf-dkim] Call for agenda items
> 

+1 on the agenda, and I'll be there in person.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 23 Jul 2010 10:02:29 -0400

I have updated the agenda on the meeting materials site with some sketchy times:
https://datatracker.ietf.org/meeting/78/materials.html

I am not planning to use slides for this meeting, so remote
participants will mostly not have to worry about following slides. The
agenda and our voices will be the order of the day.  That said, if
anyone does have slides they want to present, please get them to me by
email <[email-masked]> by the end of day on Monday.  I will
close submissions hard on Monday evening, and I will really appreciate
it if people can get them to me as early as possible.

Barry, as chair

---

From: Douglas Otis <[email-masked]>
Date: Fri, 23 Jul 2010 16:42:21 -0700

First, I would like to thank those who offered feedback, since this 
input is extremely valuable.  I owe them a beer at least.

This draft update can not be submitted until after the meeting, but for 
those interested, it is available at:
http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-05bis-a.html
http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-05bis-a.txt

These updates addressed many of the non-technical issues that were noted 
in feedback received.  I still hope to add more examples.

An issue drawing some heat was related to whether transparent 
authorizations will be facilitated.  I have added the term "informal" 
third-party services as a group that includes mailing-lists, which 
better describes the rationale.  Even when mailing-lists lack individual 
message authentication, having a certain means, via added header 
fields,  to direct messages to specific folders discourages abuse and 
exploitation.

Better ABNF descriptions were provided, with a complete description of 
the label encoding process. It did not change, since it follows network 
order and IETF bit order conventions. :^)

In addition to breaking out each alternative confirmation method, a 
place holder was included for a method to deal with various types of 
IPv6 exchanges without there being a suitable strategy for dealing with 
this issue.  Much of the IPv4 space is blocked-off based on reverse PTR 
records or AS assertions indicating residential assignment.  There is no 
practical method for tracking reverse space in IPv6.  Dealing with 
tunnels and carrier grade network address translators also impairs 
confirmation tactics normally used in the IPv4 address space.  A small 
effort to define a protocol employing DKIM keys to sign SMTP-AUTH 
challenges could prove to be a workable means for confirming client domains.

This assumption has been partially fleshed out in the updated draft.  
Another draft describing this approach, or perhaps use of TLS could be 
started.  Cert cost is unlikely much of an abuse deterrent, but I could 
be wrong.  Using DKIM keys to answer a SMTP-AUTH challenges will have 
less of an impact on resources.

TLS encodes messages in the public exchange and is a current standard, 
but there is no conventional basis yet to authenticate the client.  It 
also seems bad actors will be in a better position to handle increased 
overhead, so perhaps less is more.

There is also the issue related to the best method for introducing new 
ADSP dkim tag values.  Should additional values be separated with white 
space, or ";"?  It did not seem clearly defined in the ADSP draft.  It 
might require some experimentation to discover what works best.

-Doug