Comments are inline. > -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.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 - mham...@ag.com Web Operations Security AG Interactive/americangreetings.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html