Comments are inline.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Barry Leiba
Sent: Sunday, October 18, 2009 11:55 AM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM charter update proposal
Coming back to this: I've still seen very little direct input on the
charter proposal. JD likes it. Dave made some specific comments,
which I responded to; there've been no other comments on what Dave's
said. There've been no other specific proposals for changes to the
text.
Franck suggested gathering data on whether DKIM has been useful. I
responded to that, saying that I don't think it's a necessary issue
for chartering at this stage. Agreement or disagreement with that
would be useful.
I think it would be useful to gather information but is not necessary
for rechartering. Information from large scale receivers would be the
most useful at this point as far as I'm concerned.
Bill suggested looking at extensions for additional signature
delegation, Michael Hammer agreed, and a thread branched off from
there. Is that still an active consideration for the charter, or not?
Charles wants to see something more about guidance for mailing lists.
Is that an active consideration?
I can live with it either way (consider or don't consider).
I believe that this is potentially useful but the "greek chorus" seemed
intent on drowning it out. The case that I was looking at was (A)
domains which send all their mail through a 3rd party but don't delegate
the domain/subdomain through DNS (for whatever reason). My understanding
is that this is fairly common situation, particularly for smaller
organizations. Jim demanded that if case (A) is to be considered then
case (B) must also be addressed and resolved at the same time. That is,
a large sophisticated domain such as Cisco should be able to, through
the same mechanism as (A) be able to delegate to multiple domains. There
is no logical reason for such a requirement other than to kill
discussion of (A).
John indicated that in order to have the discussion, the working
solution - along with proof that it works - must be placed on the table.
By that metric DKIM and pretty much any other standard would never have
come into existence.
So while I believe it would be useful, my ox isn't gored on this one and
few other people have stepped forward. Life is too short.
Some have opined that it's even too early to consider taking the base
DKIM protocol to Draft Standard; let's make sure we have consensus on
that point, one way or the other.
4871+5672 or 4871bis, whichever is more appropriate from the IETF
process perspective.
I say this even though I would be obliged to argue the opposite if I
used the standard that John wishes applied to ADSP. That is, there is
currently no substantive and overwhelming evidence that DKIM is
effective or useful.
I'd like to settle very soon on what, if anything, to do about
re-chartering. Please address my specific points, above, so we can
get there. And please keep the discussion focused on the charter,
without going into lengthy discussion of details of the work.
Barry, as chair
I do wish to touch on the RFC 5617 (ADSP) discussion but only within the
context of the charter and the working group. My position is that the
working group should leave well enough alone for now and allow more time
for implementation. That is, do not make any changes in the status of
RFC5617 or how the working group deals with it for the time being.
Supporting discussion:
The fact that few have deployed ADSP so far should not necessarily be
taken as an indication of a lack of support. It appears that those who
shout the loudest against ADSP are those who have done little if
anything with regard to implementing or moving to implement.
We (AGI) fully intend to implement ADSP discardable (by way of first
implementing ALL) for the 5 major domains for which we have asserted
(here and in other venues) that all mail is DKIM signed and that mail
lacking signatures or having broken signatures could be discarded.
People should also remember that we made those assertions in late
2007/early 2008.
I'd like to point out that as a sender we were an early implementer of
DKIM/4871 signing and encountered some of the arrows that a pathfinder
sometimes finds in their back. A good example of this was the ".
stuffing" issue with regard to the body length hash.
With regard to ADSP there are very similar and real risks to
implementing, particularly with a discardable assertion. For example, I
am aware of one large mail system vendor which incorrectly adds a mime
type header AFTER DKIM signing. I can understand their intent as RFC
1521 (and subsequent RFCs) say:
"Default RFC 822 messages without a MIME Content-Type header are taken
by this protocol to be plain text in the US-ASCII character set,
which can be explicitly specified as:
Content-type: text/plain; charset=us-ascii
This default is assumed if no Content-Type header field is
specified."
Assuming the default and adding the default type header - especially
after signing a message - are two different things.
This issue was pointed out to the vendor quite some time ago but has not
been addressed. Anyone using the product as an outbound border mail
system (injecting mail from other systems) runs a risk of a broken
signature.
AGI was able to be more aggressive with DKIM implementation and
discardable assertions in the absence of a solidified ADSP (or SSP)
standard precisely because we could make the discardable assertions to a
smaller group with the ability to get feedback from that smaller group
of receivers.
As far as I know there are only 3 substantive independent (3rd party)
feedback loop efforts for authenticated mail information, two of which
appear to have stalled and the third which provides limited information.
I am also aware of several IDs for authentication FBLs.
It is this type of information that will enable more senders to
confidently implement ADSP.
I have in the past been able to get some data slices from various
receivers with regard to authenticated mail. Not being able to get this
kind of feedback is an impediment to implementation all the way around
with regard to understanding "false positives".
At the risk of inciting some by mentioning SPF, I have been seeing very
interesting (positive) results as a sender in terms of the combined
impact of SPF+DKIM with regard to phishing attacks against our brands.
Unfortunately - in a weird sense - we have been successful enough in
reducing these attacks that the corpus of phishing attack submissions
(against our brands) for evaluation is getting too small to be a
meaningful sample going forward.
Mike
Michael Hammer - mhammer(_at_)ag(_dot_)com
Web Operations Security
AG Interactive/americangreetings.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html