Personal Website of Yakov ShafranovichShafTek.org = SHAFranovich TECHnologies |
DomainKeys or DKIM, a standard for signing email which was proposed by Yahoo over 2 years ago, was finally approved by the IETF and published as RFC 4871. Congrats to all the people that made it possible.
After over a year of pre-WG work, the IETF finally chartered a new WG to work on DKIM (merger of Yahoo’s DomainKeys and Cisco’s IdenfitiedMail). John Levine has more on this.
Andy mentions a rather interesting list message from Sam Varshavchik, the author of Courier (an open source MTA licensed under the GPL):
> I was wondering if (Yahoo”s) Domainkeys is considered to be implemented in Courier.
No. Yahoo has patent claims on Domainkeys, which are not licensed under GPL-compatible terms.
For the curious, the IPR terms for DomainKeys can be found here. The actual DK license is here. To me it is unclear what exactly the problem is but of course IANAL.
UPDATE: It seems that section 3.4 is one of the culprits being similar to the advertising clause in the original BSD license (see FSF writeup).
The IETF just published a security review of MASS proposals, specifically DomainKeys and IIM (hat tip to Andrew Newton, former co-chair of MARID WG). Two main security concerns highlighted are replay attacks and DOS attacks, both of each have been mentioned in the ASRG some time ago. As for replay attacks, I actually remember discussing it with one of the DomainKeys developers who suggested the use of SPF or Sender-ID to mitigate it.
(This article was published by Circle-ID)
DISCLAIMER: I do not have any inside knowledge regarding this nor have I discussed this with any IETF folks. This is based purely on publically available information.
A few months ago, Ted Hardie (AD of Applications for the IETF) informed the MARID WG in the closure announcement as follows:
Given the importance of the world-wide email and DNS systems, it is critical that IETF-sponsored experimental proposals likely to see broad deployment contain no mechanisms that would have deleterious effects on the overall system. The Area Directors intend, therefore, to request that the experimental proposals be reviewed by a focused technology directorate. This review group has not yet been formed but, as with all directorates, its membership will be publicly listed at http://www.ietf.org/u/ietfchair/directorates.html once it has been constituted.
IETF Directorates are defined in RFC 2418 as follows:
In many areas, the Area Directors have formed an advisory group or directorate. These comprise experienced members of the IETF and the technical community represented by the area. The specific name and the details of the role for each group differ from area to area, but the primary intent is that these groups assist the Area Director(s), e.g., with the review of specifications produced in the area.
Now the directorates list does not YET list anything on this. However, now comes word from the SPF folks that something is cooking in this area. In an email to the SPF Discuss list Julian Mehnle wrote the following of the recent SPF Council meeting:
Wayne reported that within the IETF, the draft-schlitt-spf-classic-00[6] specification draft had been conveyed to the Directorate for DNS and Email Authentication (DEA), which is working in private by IETF standard policy. The DEA would contact the drafts’s authors, Meng and Wayne, for any questions and comments. Wayne also stated that he had informed all relevant IETF working groups about the draft and that the DNS groups had raised objections, mostly regarding the zone cut default mechanism, but the e-mail working groups had not expressed any disfavor. Wayne said that was working hard on another iteration of the draft.
A quick check at the IETF’s mailing list page reveals a new mailing list called “DEA-DIR” which stands for “Directorate for DNS and Email Authentication”. The list is currently private and being managed by the two ADs for the application area. The list is referenced in an email from Ted Hardie to the SPF-Council’s mailing list dated January 10th, 2005:
DEA-dir is the list Scott and I are using to as a directorate list for folks helping us review these experimental proposals. The list itself is basically there so we can get folks who have committed to reviewing the drafts to share their reviews with each other. There is no need for you two as authors to be on it; Scott and I already know where to find you to ask you questions on your draft. The dea-dir list is closed, so we can keep the discussion focused, but its members have no special status; comments from reviewers on the list and comments from outside the list are treated exactly the same in the standards process. Anyone with a comment on the drafts can send them to the ADs directly.
So, it appears that the IETF is keeping to its promise after all and is proceeding with evaluation of email authentication proposals on the experimental track via this directorate. Of course since very little public information is currently available it is hard to judge what is going on. Hopefully, the IETF will release more information and publish a list of members as promised originally. And while SPF is being reviewing by the IETF, there has been no word to whether Sender-ID is getting the same treatment.
According to a CNET article, Yahoo will begin on Monday to sign all outgoing email with DomainKeys signatures:
Yahoo on Monday will begin attaching antispam technology to all of its outgoing e-mails, hoping that other providers will follow suit. Messages from its free e-mail service will include a “Domain Key,” a system that creates a digital signature for outgoing e-mail and then lets receivers verify that the message comes from where it claims. The technology tries to thwart spam “phishing” attacks where messages pretend to originate from a familiar address and then launch viruses or social engineering hacks when opened.
A quick check with my Yahoo account reveals a DK signature:
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
b=Of+zvGE5KtBaCJoAibkTIN05XZB9//gePjpw7TkjMJs0v2/Of42HsFMwoPw2jYGDTVOv/L1OUOuulwObD4S6065WWxXyvCcF6afHz5z4TtsHiVxK/Nrmbpka3egjjSCosKyHreqhWVBHaeAvk9f88+N/UJGNEbPCAAe94yvSFyA= ;
No word on whether they will be checking incoming email as well.
According to to a post at IETF’s MAIL-SIG list by my old collegue, John Levine; Google has begun to sign outgoing email from Gmail with Yahoo’s DomainKeys signatures. This is the first large provider of email that is actually doing so (not even Yahoo has started that yet). A quick email sent from my Gmail account came with the following header:
DomainKey-Signature: a=rsa-sha1; c=nofws;
s=beta; d=gmail.com;
h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding;
b=eIN1QIuyXhq8oE9uIidZL5c/U4TjKUo3dE5ukqwB2Zd3LZ656qy1/
lPSDMEH9HcHUlmUCnjTXT6cgCoyb5p7Lfta9ywIV1Tym3dVS4gtQqvvEj
Oh6g2w2AOydQ8hlXHj1xupca7MCpVDC2YXVvSA3bz0uPCNHWgFsQS
AoqTWC9w
A DNS lookup pulls up the public key:
]$ nslookup -query=txt beta._domainkey.gmail.com
Non-authoritative answer:
beta._domainkey.gmail.com text = “t=y\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC69TURXN3oNfz+G/
m3g5rt4P6nsKmVgU1D6cw2X6BnxKJNlQKm10f8tMx6P6bN7juTR1BeD8ubaGqtzm
2rWK4LiMJqhoQcwQziGbK1zp/MkdXZEWMCflLY6oUITrivK7JNOLXtZbdxJG2y/
RAHGswKKyVhSP9niRsZF/IBr5p8uQIDAQAB”
UPDATE: After a check against the current DK spec, it seems that Google’s signatures are invalid since they are missing the “q” parameter which is required. Additionally, running the messages through Yahoo’s DK library come back as bad signatures. There is still plenty of work to be done on interoperability.
A lot of things happened this week: MAAWG meeting took place, Yahoo submitted DomainKeys to the IETF and a Microsoft submitted Caller ID draft to the IETF and SPF is merging with Caller ID via an addition of an ESMTP parameter for MAIL FROM. Architechurally speaking, I liked the idea of using ESMTP for a long time, so it looks like they are moving in the right direction (to me at least). Of course the question of what you do once authentication is used will rear its ugly head very soon, which is where reputation and trust questions will need to be addressed.
At this point, I finally feel that I personally made a difference by helping with all of these various proposals in the ASRG, and the IRTF/IETF transfer process. With CID and DomainKeys finally published, SPF and CID participating in the IETF, and the ASRG’s reputation somewhat gotten better than it was when I joined, I feel a certain sense of accomplishment about my work in the ASRG. I am hoping that my small contributions made a difference in the long term future of the Internet, and will somewhat help reduce the overall spam problem.
Yahoo has finally made public their DomainKeys draft which has also been submitted to the IETF.
Actually someone mentioned this was going to happen at today’s MAAWG meeting but I did not expect it so soon. Hopefully MSFT will follow with Caller-ID draft submitted to the IETF. It was also mentioned at MAAWG today that Eprivacy folks might be submitting their TEOS stuff as a draft to the IETF.
Suddenly everyone likes the IETF and its standards process, and are willing to participate. I wonder what happened in the past year that this change took place. I also hope that the IETF will be able to properly execute the standards process with these and not alienate the industry.
UPDATE: I forgot to thank Larry Seltzer of eWeek who posted the original message to the MARID list.
Yesterday I attended the spam workshop at NIST in DC area. Overall, I had a wonderful time and I would like to highlight some of the more interesting things I heard.
Read the rest of this entry »
|
Blog reactions to http://www.shaftek.org/
My Deli.cio.us Links
