[ietf-dkim] DKIM BOF -- draft charter and agenda
The most important thing we have to do before the BOF is to get some consensus on a charter for the proposed Working Group, and set an agenda for the BOF. To the first end, let me start by posting the current version of the post-Paris draft charter. I think a few changes to it will help, and I know Stephen has some quite significant comments and changes that he'd like to see, so let's bat this around and try to wind up with something we can go with by the end of this week. The main changes that I think are needed are these: * I think the intent of this sentence has been widely misunderstood: "The working group will make only the minimal changes deemed useful to improve the viability of services that are based on these specifications." ...and I'd like the clarify it. The point is not that we want to limit discussion to moving commas. The point is that there's a significant deployment of some of this already out there, and we'd like to maintain compatibilty with that installed base, to the extent that it's reasonable to do so. If an incompatible change is Really the Right Thing, we should do it. But let's be sure that it's Really the Right Thing. So I'd like to see wording that clarifies the intent there. * I want to make it much clearer, right in the charter, that no one thinks this will "stop spam", and that that isn't the intent of the spec nor the goal of the Working Group. We do mention forgery, but I don't think we point out clearly enough that it's the forgery that this is addressing, and not other aspects of spam fighting. Stephen and I also talked about adding an informational document to the deliverables, and I'll let him talk about that some more when he responds here. Also: I know the milestones are extremely aggressive, and that's intentional. Those of us who've worked on getting this far want to move this work along *quickly*, because we believe that it's a critical component of the anti-spam/anti-phishing toolbox, and that we need it *now*. That said, let's look at those dates and accept "aggressive", but make sure they're feasible. OK, let's get started. What do you think? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam DRAFT IETF WORKING GROUP CHARTER 22 Aug 2005 0932 Domain Keys Identified Message (DKIM) CHAIRS: TBD AREA DIRECTORS: Russell Housley, Sam Hartman AREA ADVISOR: Russell Housley <[EMAIL PROTECTED]> MAILING LISTS: General Discussion: ietf-dkim@mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ DESCRIPTION OF WORKING GROUP: Forgery of headers that indicate message origin is a problem for users of Internet mail. The DKIM working group will produce standards-track specifications that permit authentication of message headers during transit, using public-key signatures and based on domain name identifiers. Keys will be stored in the responsible identity's DNS hierarchy. The specification will be based on the draft-allman-dkim-*.txt Internet-Drafts. The working group will make only the minimal changes deemed useful to improve the viability of services that are based on these specifications. The specifications will contain summaries of the threats, requirements and limitations that are associated with the specified mechanism. The DKIM working group will also address mechanisms for advertising "signing policy" so that a recipient can determine whether a valid message signature should be present. The working group will NOT consider related topics, such as reputation and accreditation systems, and message encryption. It will also NOT consider signatures which are intended to make long-term assertions (beyond the expected transit time of a message) nor signatures which attempt to make strong assertions of the identity of the message author. The working group may also study whether to adopt a work item for specifying a common mechanism to communicate the results of message verification to the message recipient. GOALS AND MILESTONES: 7/05 Issue initial Internet-Draft[s] of signature specification 10/05 Submit to IESG - for DKIM threats and requirements 2/06 Submit to IESG - DKIM signature specification 2/06 Submit to IESG - DKIM public key Resource Record 5/06 Submit to IESG - DKIM policy specification ___ ietf-dkim mailing list http://dkim.org
[ietf-dkim] Re: DKIM BOF -- draft charter and agenda
OK, I've let this simmer for a couple of days, and I think it's time to come back with my take on it, as the other BOF chair, and as someone who's worked on the specs as they currently are. I'm including Russ as a CC on this message, asking him (Hi Russ!) explicitly to comment. As I said in my previous note, I had a couple of issues with the draft charter as it was, and I agreed with some of Stephen's comments. I also agree with what Dave, Jim, Mike, and some others have said about questioning the value of a too-extensive rewrite of the charter (though that might be what I'm posting here anyway, since I tend to rewrite, when I get my hands on stuff). I think I've got a good compromise, which I'm attaching here. It keeps the general flavour of the original charter, and expands the text a bit in the areas where some have said it's lacking. I've rearranged and reworded some things, without, I hope, completely changing it. And I've revised the milestones to be what I think are feasible, and still aggressive. I left out two points (perhaps more, but I'm sure he'll point that out) that Stephen had put into his version with a "?" on them: those involving doing additional work on canonicalization and cryptographic transforms. I think the specs allow us to plug things in here, and that work on them doesn't need to be explicitly called out in the charter. If people disagree, I'm sure they'll say. Russ: What do you, who will need to approve the charter, think about this pass? Do you think it's reasonably solid, and takes into account the major comments that've been made? Would you be comfortable with a working group with this charter? Everyone: Pretty much the same questions. Does this reflect what most of us think? Does it adequately explain what we're trying to do, and not trying to do? And do the milestones seem feasible? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam DRAFT IETF WORKING GROUP CHARTER 13 Oct 2005 Domain Keys Identified Message (DKIM) CHAIRS: TBD AREA DIRECTORS: Russell Housley, Sam Hartman AREA ADVISOR: Russell Housley <[EMAIL PROTECTED]> MAILING LISTS: General Discussion: ietf-dkim@mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ DESCRIPTION OF WORKING GROUP: The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam (and is, in this context, called "spoofing"). The DKIM working group will produce standards-track specifications that allow a domain to take responsibility for having a part in the transmission of an email message, using digital signatures, and to publish "policy" information about how it uses those signatures. Taken together, these will allow receiving domains to detect (or rule out) spoofing in many circumstances. The specifications will also contain summaries of the threats, requirements and limitations that are associated with the specified mechanism. While the techniques specified by this working group will not prevent fraud or spam, they will provide a valuable tool for defense against them by allowing receiving domains to detect spoofing of known domains. What to do with that information is still left to the receiving domain, and this group makes no attempt to define that, or to establish trust relationships, or reputation of accreditation systems. The signatures will use public-key cryptography and will be based on domain name identifiers. Keys will be stored in the responsible identity's DNS hierarchy. The specifications will be based on the following Internet Drafts: * draft-fenton-dkim-threats * draft-allman-dkim-base * draft-allman-dkim-ssp which represent experimentation and consensus from a number of designers and early implementors. Because there is significant deployment on the Internet of these specifications, as part of the experimentation, the working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. The working group will NOT consider related topics, including, but not limited to, the following: * Reputation and accreditation systems. While we expect these to add value to what is defined by this working group, their development will be separate, and is out of scope for this group. * Message encryption. * Key management, including key-distribution infrastructure. * Signatures that are intended to make long-term a
Re: [ietf-dkim] Re: dkim service
John says... > Ohhh, noo, not this again. We flogged this topic at length while > arguing DK versus IIM. :-) > I think it'll be a swell idea for list software to use DKIM on > incoming messages to verify the sender, but that's the list manager's > job, not the subscribers'. Right. The idea, as I put it once, was that "If you break it, you bought it." Put less colloquially, if a mailing list that knows it's going to mangle the message receives a DKIM-signed message, it should 1. Verify the signature. 2. Apply whatever reputation service, white/black lists, spam filtering, etc that it wants to, to decide whether the message should pass on to the mailing list. 3. If it decides that it should pass, the mailing list should LEAVE the existing signature (that part is not universally agreed on, of course, but the next part is), mangle the message, and re-sign it (which is not the same as being resigned to it). The mailing list may, of course, choose to re-sign the message even if it does not mangle it, which is all the more reason to leave the original (still-valid) signature there. > Or maybe you meant remailers and forwarders rather than lists? I > think we all agree that DKIM is intended to survive those. Yea, verily, 'tis. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] Re: signature construct
John Levine wrote: Since you have to read through the whole body anyway, I don't see much advantage to a two-stage hash and sign strategy. I agree with this point. What's important to me, though, is that we be able to tell the difference between a failed signature (because the body was changed) and a bogus signature (something signed with the wrong key, or something made to look like a sig that's not). Why do I care? It may be a matter of the degree of risk I'm willing to take, and the information is useful. If I know that mybigcustomer.com signs all of its mail (because of its SSP), then I know that mail "from" mybigcustomer.com with no sig... is spoofed. That's easy. If I get mail from mybigcustomer.com with a sig that validates, I know it's good. That's easy too. If I get mail from mybigcustomer.com with a sig, or something that looks like one, and it fails validation, I need to decide what to do. There could be three reasons (maybe more, but let's say three): 1. It's valid mail that was sent through some forwarder that breaks the sig... but the changes are inconsequential. 2. It's an attack, where a spammer took a valid mybigcustomer.com sig and stuck spam onto it. 3. It's someone trying to game the system, by just sticking a bad "sig" on something... but it's spoofed. If I can rule (3) out because I can tell that the sig is a good one, but the message no longer matches it, then I can decide that perhaps mybigcustomer.com is important enough that I want it whitelisted anyway, and take the risk. This seems to me to be useful information. Do others agree? Or do we think that spammers would just use it to their advantage too much for it to be useful to us? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] Re: DKIM BOF -- draft charter and agenda
Time for the next pass, after input from several of you, on and off the list, and input from Russ as well. The attached version covers pretty much everything, and I think we might be done with the charter now. Can we close on this, and work up an agenda for the BOF? The only significant comment that I think I haven't done anything about is from Ned: you suggested including words about canonicalization and hashing, along with those about public-key crypto. I decided that the reference to p-k crypto is sufficient to specify the mechanism in the charter (distinguishing it, for instance, from looking at IP addresses, or the Farmer's Almanac), and that getting into "we canonicalize the message, take a hash of that, digitally sign that, put the result into the header..." is really what the spec is for. So I left that as it was. If you *really* think mentioning c<237>n and hashing is very important for the charter, please bring it up again. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam DRAFT IETF WORKING GROUP CHARTER 14 Oct 2005 Domain Keys Identified Message (DKIM) CHAIRS: TBD AREA DIRECTORS: Russell Housley, Sam Hartman AREA ADVISOR: Russell Housley <[EMAIL PROTECTED]> MAILING LISTS: General Discussion: ietf-dkim@mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ DESCRIPTION OF WORKING GROUP: The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam. When done illegitimately, it's called "spoofing". The DKIM working group will produce standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message and to publish "policy" information about how it applies those signatures. Taken together, these will allow receiving domains to detect (or rule out) spoofing in many circumstances. The DKIM working group will produce summaries of the threats that are addressed by the standards-track specifications, while acknowledging their limitations and scope. The DKIM working group will also produce security requirements to guide their efforts. While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a valuable tool for defense against them by allowing receiving domains to detect spoofing of known domains. The standards-track specifications will not mandate any particular action by the receiving domain when spoofing is detected. The DKIM working group will not attempt to define such actions, to establish requirements for trust relationships between domains, or to specify reputation or accreditation systems. The signatures will use public-key cryptography and will be based on domain name identifiers. Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. The specifications will be based on the following Internet Drafts: * draft-fenton-dkim-threats * draft-allman-dkim-base * draft-allman-dkim-ssp which represent experimentation and consensus from a number of designers and early implementors. Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. The resulting protocols must meet typical criteria for success. In addition to security, these include usability, scalability, ease of deployment, and cryptographic algorithm independence. To prevent this task from becoming unwieldy, several related topics are considered out of scope for the DKIM working group. These topics include: * Reputation and accreditation systems. While we expect these to add value to what is defined by the DKIM working group, their development will be separate, and is out of scope for the DKIM working group. * Message content encryption. * Additional key management protocols or infrastructure. * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. * Signatures that attempt to make strong assertions the identity of the message author, and details of user-level signing of messages (as distinguished from domain-level keys that are restricted to specific users). * Duplication of prior work in signed email, incud
Re: [ietf-dkim] Re: DKIM BOF -- draft charter and agenda
Phillip wrote: > A comment that came up internaly from folk who are not directly > involved: > > The charter says that the group will not look at key distribution > infrastructure. So they are not going to distribute keys in the DNS > after all? > > I think its just a wording issue, insert the word 'other' > appropriately. Stephen wrote: So instead of: * Additional key management protocols or infrastructure. Maybe: * Generic key management protocols or infrastructure. I think the comment that Phillip reports on was from before the last iteration, where it said > * Key management, including key-distribution infrastructure. Several people pointed out the problem in that, and we changed it to the current > * Additional key management protocols or infrastructure. I think it's fine as it currently is, yes? I don't think it needs changing again. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] Re: DKIM BOF -- draft charter and agenda
Earl Hood wrote: It may be better to state: ... Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain. I like Earl's change, and I've changed it in the master version. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
[ietf-dkim] DKIM BOF agenda
Stephen and I have put together a proposed agenda, and talked it over with Jim and Eric, who we've asked brief presentations of. Here's what we propose. When you look at it, keep in mind that the goal of this BOF is to decide whether or not to form a Working Group, and if the answer to that is "Yes," to close on a charter for it. That means that, while we don't want to shut down all discussions of the specs (indeed, some discussion of them is needed in order to answer the primary question), it is NOT the goal of the BOF to hash out issues with the specs, so we aren't allocating a large block of time for that. The "multiple signatures" issue, for instance, that was discussed here on the list, is something that we DO have to deal with in the Working Group, if it is formed, but that isn't a decision point in whether or not to form a Working Group. OK, here's the proposed agenda. Times are in minutes, items with no names are for Farrell and Leiba to present/lead. 1. Agenda & introduction (10) 2. Walk through proposed charter (15) 3. Discussion of proposed charter -- open (20) 4. Walk through threat analysis -- Fenton (15) 5. Walk through base spec -- Allman (10) 6. Walk through policy spec -- Allman (10) 7. Introduce other deliverables (10) 8. Open discussion of specs & deliverables -- open (20) 9. Decision: should a WG be formed with this charter? (10) I invite immediate comments on this, so let me know quickly if you think something important is missing, or the time balance is drastically off. I'll post it to the IETF agenda list later today (and my apologies to the people in Europe and Asia, who won't have much time to comment; we will be able to address gaps in the agenda at the start of the BOF, and, of course, you can make comments to me or to this mailing list even after I post the "official" agenda). Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIMand (eventual) IETF DKIM
Douglas Otis wrote: When the From/Sender headers do not represent the actual sender, such messages may be forfeit had the domain contained within the From/Sender published close-ended authorizations. SSP policies reduce delivery integrity for other senders! : ( I don't agree. I believe the combination of the ability to specify which header you're attesting to, combined with the ability to specify in the SSP whether you sign and whether you authorize third parties to sign (though I'm not happy with the confusion that the term "third party" has generated, I don't have a better term in mind), gives the flexibility we need to solve the problem we're trying to solve -- which, keep in mind, is a limited one. protection and makes the domain highly restricted to two-party use, but still suitable for sensitive transactions. - All originating headers match the signing-domain! I argue that "sensitive transactions" are not what DKIM is about. If one wants to protect sensitive transactions, one should use S/MIME or OpenPGP. That said, I wouldn't object to an additional, strict signing policy that lists headers and asserts that they must match. I think it'd be rather nice to say, "Only consider a message validly signed by us if the signature verifies AND ALL of the following SMTP and header fields represent our domain: HELO, MAIL-FROM, From, Sender, Reply-To [...]." What do others think of this? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM BOF agenda
For everyone's info: the BOF has now been rescheduled for Monday at 1300, which seems to conflict with nothing that would have significant attendee-overlap. We hope. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM BOF agenda
According to https://datatracker.ietf.org/public/view_meeting_agenda_text.cgi?meeting_num=64 it is still on Friday. Is the Monday firm, do you know? Yes, it is. Marcia confirmed it with Russ, Stephen, and me this morning. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
[ietf-dkim] DKIM proposed charter tweak
After some discussion with IESG/IAB folks, I have an update to the proposed DKIM charter that I want to float here. The change is to the third paragraph, and relates to our not defining actions taken by the verifier when verification fails. The thought was, and I agree, that while it's true that we want (need) to leave this up to implementers and sys admins, it's not a good idea to have people just make it up, without some guidance and analysis. So here's my proposed replacement for the third paragraph in the proposed charter: While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a tool for defense against them by allowing receiving domains to detect spoofing of known domains. The standards-track specifications will not mandate any particular action by the receiving domain when spoofing is detected. That said, with the understanding that guidance is necessary for implementers, the threat summary should document a reasonable set of possible actions and strategies, and analyze their likely effects on attacks and on normal email delivery. The DKIM working group will not attempt to establish requirements for trust relationships between domains or to specify reputation or accreditation systems. Comments ASAP, please. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM charter
DKIM Chair wrote: 2. Apart from that, since we've seen clear consensus (yes, I realize it's not anonymity Uh. *U*nanimity. Sorry. Barry ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM charter
> It appears to me that the mailing list stripped the attachment, or > maybe the attachment never made it to the list. Either way, I the > charter didn't make here. Most likely, I forgot to attach it. :-( I shouldn't try to do anything like this while running on an IETF-fried brain. Here it is, appended (not attached) below. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam - DRAFT IETF WORKING GROUP CHARTER 8 Nov 2005 Domain Keys Identified Message (DKIM) CHAIRS: TBD AREA DIRECTORS: Russell Housley, Sam Hartman AREA ADVISOR: Russell Housley <[EMAIL PROTECTED]> MAILING LISTS: General Discussion: ietf-dkim@mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ DESCRIPTION OF WORKING GROUP: The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam (when done illegitimately, it's called "spoofing"). The DKIM working group will produce standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message and to publish "policy" information about how it applies those signatures. Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain. The DKIM working group will produce a summary of the threats that are addressed by the standards-track specifications, while acknowledging their limitations and scope. The DKIM working group will also produce security requirements to guide their efforts, and will analyze the impact on senders and receivers who are not using DKIM, particularly any cases in which mail may be inappropriately labeled as suspicious or spoofed. While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a tool for defense against them by assisting receiving domains in detecting some spoofing of known domains. The standards-track specifications will not mandate any particular action by the receiving domain when a signature fails to validate. That said, with the understanding that guidance is necessary for implementers, the DKIM documents should discuss a reasonable set of possible actions and strategies, and analyze their likely effects on attacks and on normal email delivery. The DKIM working group will not attempt to establish requirements for trust relationships between domains or to specify reputation or accreditation systems. The DKIM working group will consider mailing-list behaviour that is currently deemed acceptable, will make every effort to allow such mailing lists to continue to operate in a DKIM environment, and will provide a plan for smooth transition of mailing lists that fail to operate. The specs will also advise mailing lists on how to take advantage of DKIM if they should choose to do so. The signatures will use public-key cryptography and will be based on domain name identifiers. Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. The specifications will be based on the following Internet Drafts: * draft-fenton-dkim-threats * draft-allman-dkim-base * draft-allman-dkim-ssp which represent experimentation and consensus from a number of designers and early implementors. Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. The resulting protocols must meet typical criteria for success. In addition to security, these include usability, scalability, ease of deployment, and cryptographic algorithm independence. To prevent this task from becoming unwieldy, several related topics are considered out of scope for the DKIM working group. These topics include: * Reputation and accreditation systems. While we expect these to add value to what is defined by the DKIM working group, their development will be separate, and is out of scope for the DKIM working group. * Message content encryption. * Additional key management protocols or infrastructure. * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. * Signatures that attempt to make strong assertions about the iden
Re: [ietf-dkim] Re: dkim.org (mipassoc.org/dkim) web page updated
Assertions suggested in SSP such as '~' (signs some?), '-' (third-
party?) offers questionable benefit and delay. Grading email with
respect to "partial" conformance offers a means for coercion
There does seem to be a swell of current opinion, as people think about
it and read the discussion, that any sender signing declaration (let's
consider moving away from the term "policy") should simply start with a
straight "I sign everything" (or not), which doesn't get directly
into the "what does that really mean, and who's responsible for
interpreting it" questions. At that stage, we take the "partial"
issue out of it.
That'll be a good thing for us to get back into a discussion of, when
the time comes to discuss it. I think we'll do some {SSP/SSD/whatever
we wind up calling it} discussion when we get to the threats document,
after the charter's settled. And then, of course, the bulk of it will
come later, when we're actively working on the SS{P/D/x} document.
For now, let's all think about what aspects of SS{P/D/x} we need to
consider for the threats document, and what is a matter for banging out
later in the detailed SS{P/D/x} brawl.
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
___
ietf-dkim mailing list
http://dkim.org
Re: [ietf-dkim] DKIM charter
In my view, DKIM is establishing an "implied" trust relationship between domains by the very nature of making any attempt to support or adopt the protocol. It is going to be difficult to keep the concept of "protocol trust" out of any discussions of SSP. Hm, interesting approach. The way I look at it, DKIM is providing information that could be used to define a trust relationship, but is not defining any trust relationship itself. The recipient decides whether to validate the signature, and what to do with the results of the validation. I believe this is true with or without SSP, which is why I don't think that SSP is transferring responsibility to the recipient: DKIM is giving information, the recipient domain is using that information however it chooses, and the DKIM spec does not tell it what to do with that. In other words, I don't think I read if 2821 integrated issues is out of scope or naturally part of the process. I'd have to say that updating RFC 2821 is out of scope, and anyone who participated in DRUMS will understand why. We want to finish the DKIM work in 2006, not in 2016. I'd certainly think it'd be fine to have a non-normative section (or a section in a non-normative document, such as the overview) that recommends changes to the existing standards or infrastructure. I also think it's not necessary to list everything that's not in scope, so I don't think we need to declare "updating RFC 2821" to be out of scope, explicitly. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] SSP Threat Analysis vs SSP Impact Analysis
Is it reasonable to ask if the thread considerations include impact considerations? Assuming that's "threat"... what do you mean by "impact considerations"? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] SSP Threat Analysis vs SSP Impact Analysis
Assuming that's "threat"... what do you mean by "impact considerations"? How a "known Feature or Expected Logic" may alter or effect current operations. This should not be construed as a threat unless there is an entry point that causes an expected mode of operation to run amonk. OK, that's what I thought you probably meant. At one level, this is what Sam Hartman was concerned about, when he spoke from the floor in the BOF (see the draft minutes that Stephen has posted). I guess we have three broad categories here: 1. What attacks against the email infrastructure does DKIM address? 2. What attacks will there be against DKIM, once it's deployed? 3. What effects does DKIM itself have on the email infrastructure? The "threats" document is trying to include (1) completely, and a good analysis of (2) [we can never be *complete* there, of course]. Sam was asking for more thought on (3), and especially -- which is why Russ asked us to add language about this to the charter -- with respect to mailing lists. It's not clear that (3) needs to go in the threats document, and we certainly can't be "complete" about it either, but the charter clearly commits us to looking at (3) at least somewhat (in the "mailing list" paragraph). I see it as material for the overview document, but I don't think it'd be unreasonable to include a specific item or three in the threats doc if we decide that item/those items belong there (because they're important enough to write down early, and to include with the discussion of attacks). In any case, I think the charter covers this, and it's in scope (though we have to be careful of ratholes here). Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] DKIM charter
The parenthetical seems to be a bit misplaced, and might fit better to the use of the word "legitimate". This might read more easily if broken into two sentences. Actually, the content and placement of the parenthetical is due to an attempt to correct a misunderstanding followed by awkwardness, when there were two sentences. :-) Unless others think it's unclear, I'd rather leave it as it is (though it's surely not Shakespeare). Detection of spoofing is indirect at best; I'd prefer that we emphasize the ability of DKIM to rule out spoofing. I kind of agree, but I'd rather not change that bit of text, which is another that we modified a couple of times before settling on that. I really like your suggestion in http://mipassoc.org/pipermail/ietf-dkim/2005q4/001359.html that we move away from the word "policy" and use "declaration". Should we do that here as well? Thank you. I looked at the text here, and there are only two places where we say "policy", and I can't see a good way to turn either of those directly into "declaration" without changing what they mean. The first says, "and to publish 'policy' information about how it applies those signatures." I could make it, "and to publish declarative information about how it applies those signatures," or simply, "and to publish information about how it applies those signatures." What do you (plural) think? The second one is in the definition of the deliverable, so I could change that from, "A standards-track specification for DKIM policy handling," to "A standards-track specification for DKIM signing declarations." That changes it significantly, and it worries me to change the charter text so much -- and the actual content of the document is quite up-in-the-air right now anyway. Maybe we should leave the charter text as it is, and wait until we start beating on the document before we decide whether we want to call it "policy" or "declaration" or "bad thing that we've decided not to do after all." I got a little confused by the use of "standards-track specifications" here, because the threat analysis is done before any standards-track specifications exist. Should it say "DKIM specifications" instead? Really? You don't think it's clear that it means "the standards-track specifications that we mentioned in the previous paragraph"? Well, I changed it to say "proposed standards-track specifications" in my copy. Is that better? Last sentence: "or" -> "nor" Yep; changed. The specs will also advise mailing lists on how to take advantage of DKIM if they should choose to do so. "specs" (which should probably be spelled out) is plural. Is that to say that all of the documents will say something about mailing lists? (I've spelled it out now, in my copy.) Of course it doesn't mean to say that; it means that, collectively, the documents will say that. It doesn't mean to define, at this point, which document(s) will do it. The current drafts have two DKIM RRs, one for keys and another for "policy". So that should be Resource Records. Changed. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] Re: wg formation status?
AFAIK, the charter is in the works at the IESG (but I sent Russ a note checking), and should pop out to the new-work list soon. We're looking at official wg-dom just before or after the new year if all goes well. I believe the IESG meeting (phone) where they'll discuss it and move it forward (or not) is Tuesday, IIRC. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] Re: wg formation status?
In the Threat Analysis discussions I have been struck by the difference in clarity and apparent consensus on the issues that pertain to the core functions, versus those that pertain to the "policy" functions. [...] All of this suggests that de-coupling the TA for the core functionality, from that of the policy-related enhancements, will be necessary if we are to stay on schedule. I think that that may turn out to be the case, but I'd rather see the next revision and work from there. Having not talked with Stephen about this, I'll say that I see no problem with making a reasonable effort at documenting policy-related threats, knowing that it may change and not allowing it to get in the way of the schedule... and then updating the document later, after we've done the policy work. It could turn out that the best way to have a thorough Threat Analysis document in the end is to obsolete (yes, yes, "make obsolescent") the early version. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
[ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)
> the IETF has done work on message signing before, and some of those earlier efforts (like CMS in detached signature mode) look enough like pieces of DKIM that there is question of whether DKIM not using them indicates that they do not work, that this message signing is a better point solution, that this message signing mechanism would be better over all, or none of the above. I believe the discussion Ted suggests IS in scope for the working group we're proposing to charter, and I don't believe that the charter text in question affects that. It will be up to the WG chairs to judge rough consensus on the discussion, or to decide, should it happen, when the discussion has become fruitless and wasteful of the WG's time, especially considering the short schedule that's proposed. If Russ should choose me as a co-chair of the DKIM WG, be assured that we WILL have this discussion. Be also assured that I won't let it turn into a rathole and impede progress. I believe that is the balance that has to exist in any WG, and that the ADs place a good deal of trust in the WG chairs to both allow discussions that ought to happen, and control discussions so they stay within the scope of the WG and do not get out of hand. I don't think that anything we say in the charter changes this; it is meant to provide a guide for resolving the ratholes and distractions. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
[ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)
Ted Hardie wrote: I would be happy with the text that was used in the xmpp charter: Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. I agree with Tony on the benefits of re-using this language, and it certainly works for me. Then it sounds like we have some text that we can compromise on. Jim Fenton has already said that this text covers his concerns about as well as what we had, Stephen Farrell has accepted it, and now I'm weighing in. I suggest that the IESG replace that paragraph in the proposed DKIM charter with the paragraph above, and that we move on from this topic to any others that need to be dealt with. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)
Dave Crocker wrote: and now the chairs quickly concede the change, even before getting support from the rest of the group. 'scuse me; it seemed to me that Tony Hansen and Jim Fenton counted as some of the rest of the group. It also seems to me that no one has made me the boss, so what I suggested was just that: a suggestion. You may feel free to spend more time arguing about that paragraph if you like. My opinion (and that's all it is) is that that's not useful. I understand the principle you're fighting for, Dave. And I think it will come up again, which is why you're fighting it. I think it will be better to fight it later, if necessary. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
Keith Moore wrote: OTOH, the assumption that _all_ public keys used to validate DKIM signatures will be stored in DNS is a very limiting one, because it appears to lead to either a) a constraint that policy be specified only on a per-domain basis (which is far too coarse for many domains) or Actually, the DKIM base spec does provide a mechanism for replacing the DNS keystore with something else. Look at 1.4 for a general statement, and the description of the "q=" tag in 3.5. DKIM's intended to be able to support user-level keys in a future version (there's some discussion of that in appendix A), and its design is set up specifically not to prevent that. The proposed charter puts the details of other key management systems and user-level keys out of scope so that we can contain the work at this stage, and make quick progress on the first version. It'd be entirely reasonable to recharter and attack these issues immediately after completing the first round of chartered work, if there are enough people who want to work on that. Or we can see how a while of deployment goes, and form another WG in a year or so to do it. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
[ietf-dkim] Re: The Value of Reputation
Selamat tahun baru. Bonne année to you too. I agree with Dave sometimes, and disagree sometimes. For this note, I agree with everything he says. I have a few things to add (though as I went through it trying to add more, I realized how unnecessary that was). Unless I have missed something quite basic, the proposed DKIM charter and the draft DKIM specifications do not include doing work on reputation > services. Just to add one to this: Yes, that is correct. And if the WG be chartered and if I be a co-chair, I will certainly declare any discussion of it to be out of scope. That doesn't mean it can't come up here and there, as part of other discussions, but we must not focus on it, taking time from the work to hand. I, as do others, believe that some sort (or sorts) of reputation service will be important, and should be developed. I see several ways to approach it: 1. Recharter this WG after its primary work is done. 2. Start one or more new WGs for this, beginning the chartering process as the DKIM work nears completion. 3. Work on some reputation services separately -- as I believe will happen in any case -- and bring some of them to the IETF after some experimentation. I think (1) is probably NOT the right way, but both (2) and (3) will work well. role of reputation. To say this differently, many folks seem to think you can choose a "reputation system" almost at random, and it's sure to improve your signal/noise ratio I don't think "many" people seriously think that, and hyperbole isn't useful here. Most participants here (and I base this on what people have said) think a *well designed* system will be very useful. That's why we should wait until we've finished some of the other discussions that pend here, so that we may take the time to design the reputation system(s) well. As a practical matter, _many_ folks will prefer sorting through 100 spams to losing one good email. I see darn little "market" for anything which can't get it 99% right. Actually, I have a good bit to say about this particular item in a paper I'm writing for CEAS [and so here's a shameless plug for CEAS, the Conference on Email and AntiSpam, and an urging to all to consider writing papers for it: http://ceas.cc, and click on "2006 Call for Papers"]. The bottom line is that the answer varies, and whatever infrastructure we have has to have the flexibility to support the varying needs of different customers and groups. This seems to suggest a policy requirement for all IETF work, that it anticipate and document "obvious" abuses and specify the means of > avoiding them. This feels more like a bureaucratic barrier to productive work, than a useful adjunct to the technical specifications work that the IETF tries > to perform. The suggestion seems so "obviously" reasonable that it's hard to imagine why we shouldn't do it. And yet, as Dave points out, it could just pull the reins tight on all IETF work. Our focus has to be on making sure the specifications are clear. We can (and we do) talk about some things we do NOT support and that you should NOT do... but, "obviously", we can't possibly cover all the "don't"s, and attempts to will fail, and will bring the process down with them. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ ietf-dkim mailing list http://dkim.org
Re: [ietf-dkim] Agenda updated again
I wish there were something that could be done about the conflict with the eai Email Address Internationalization BOF. yeah, that's a pretty impressive conflict to have set up. For what it's worth, it's because those arranging the EAI BOF didn't put DKIM as a conflict, probably at least partly because DKIM is in the Security Area and not everyone who spends their time in the Apps Area looks there. When we scheduled DKIM, I put IEE -- the name EAI used in Vancouver -- as a conflict, but I had no idea that they would use a different name now. And apparently Marcia wasn't able to resolve it afterward (DKIM has a long list of conflicting WGs). Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] ABNF: Sender = Originator / Operator
Douglas Otis said DKIM is not about defining the author of the message and would conflict with the charter. Regardless of what DKIM does or doesn't have to say about the author of a message, it's useful to have consistent and well defined terminology. It might be a good idea to have an informational RFC that defines all these terms (and I think Keith Moore's tried to do something like that). I like this, for the purpose of DKIM: "author" -- the entity who wrote the text "originator" -- the entity who sent the message "originating domain" -- the domain of the originator "signing domain" -- a domain that has signed the message "MTA" -- widely used term; does "operator" really say something else? "verifying domain" -- a somain that verifies the message "signer" -- an MTA/operator that has signed the message "verifier" -- an MTA/operator that verifies the message "recipient" -- a final recipient of the message "recipient's domain" -- a recipient's domain Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
[ietf-dkim] Concentrate on the threats doc
Since we have only one week now before the IETF meeting, I'd like to see us hold off on all discussion that does not have to do with open or new issues with the two documents we're currently focused on: threats and base. Getting the terminology right is important, but let's please not spend all of this next week discussing that, and omit issues with the docs. So: * Please, everyone, concentrate on reviewing the threats document. * Please look at the open issues list that Stephen posted the other day, and comment on the dispositions, giving primary importance to those against the threats doc. * If you have reviewed the threats doc and think it's ready, please say so explicitly. * After doing "threats", review the issues with the base doc from Stephen's note, and address those. This should get us ready for the sessions at the IETF meeting. I particularly want to make sure we have explicit review of the threats doc from enough participants to be sure it's ready to go to the IESG with the next update after the IETF meeting. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Core algorithm support/use, draft text v2
I didn't see any follow-up to this comment by Phill, and I think it might be useful: I believe that the best way to do this would be to introduce a signature counter so that the order of signing can be recovered even if a message has its headers reordered. This might also be a good answer to the issue of downgrade attacks during a transition period. If, say, we have a tag "n=", and the value is "i,j" (this is signature record "i" of "j"), then a sender might do this: DKIM-Signature: d=example.com; a=rsa-sha256; n=2,2 ...etc... DKIM-Signature: d=example.com; a=rsa-sha1; n=1,2 ...etc... ...and a verifier can figure out whether signatures have been reordered or stripped out. We have also talked about putting something in the key record to indicate which algorithms must be used, so a verifier can see that the signer always uses sha256, and can be suspicious if a sha256 sig isn't there, but sha1 is. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Concentrate on the threats doc
Hello? Is this microphone working? Testing... testing... Can you hear me? Repeating two things in particular: * Please look at the open issues list that Stephen posted the other day, and comment on the dispositions, giving primary importance to those against the threats doc. * If you have reviewed the threats doc and think it's ready, please say so explicitly. ...because: I particularly want to make sure we have explicit review of the threats doc from enough participants to be sure it's ready to go to the IESG with the next update after the IETF meeting. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] New issue: DKIM and mailiing lists
Dave says... So if this is going to be on the agenda, I suggest that it be specific questions or problems, with specific suggestions for specific resolutions. Agreed... see below. Mike says... And at this point, I really think what we need is data far more than we need conjecture. I'm in the beginning process of getting more data on this subject in our deployment, but don't yet have any meaningful numbers. Hopefully within the next few months though. That sounds good. I think some good data will be a good starting point, and I appreciate that Mike's working on providing some. Thanks. As I interpret the discussion that we've had with Russ, and the requirement for mailing-list consideration that was added to the charter as a result of concerns from the Vancouver BOF, I believe that an analysis of the mailing-list issues is a prerequisite to having the base spec approved as an RFC (that is, it's not something we can do later). I suggest -- and I haven't discussed this with Stephen, so, Stephen, pipe up if you disagree -- that we get a small group (up to three, I think) of participants who are concerned about this and who have appropriate experience, and work up an Internet Draft discussing the mailing-list issues. That draft would either be merged with the base spec before the latter goes to the IESG, or would be sent at the same time, as a companion document. Thoughts? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] 5 outstanding issues with the threat review
I agree with what Stephen says about these, and in particular, that as we look at the threats doc we consider carefully what belongs there, as opposed to what should be brought up in discussion of the base doc. Doug, if you decide to separate any of these out to ask that a new issue be opened, please really, really try to keep what you say concise -- I have trouble sifting through it, and I'm sure that the non-native English speakers have more trouble. Providers offering low cost or free services will not be able to adequately vet their many users, who often number in the millions. This same provider may wish to send messages from the same domain and have these messages receive a trustworthy evaluation. Perhaps these would be messages from a system administrator indicating that the user's system appears compromised or that their payment information is no longer valid. The use of trusted/non-trusted keys would permit the signing domain to both retain their trustworthy status and prevent un-vetted users within the same domain from spoofing with "trusted" messages. That's largely sales talk and I can't see any valid issue applying to the threats draft. Another expedient assessment. It's definitely not relevant to the threats doc, but I do think it could be a useful discussion to have about the base doc. We've suggested that domains that want to divide their reputation create subdomains (the sort of thing like "official.bigbank.example" vs "users.bigbank.example"), but for various reasons not all domains want to do that. It would be a reasonable discussion to have if one wanted to propose a tag in the key that defined the level of "officialness" or "trust" or some such that the signing domain places on the use of this key. That allows the domain to use selectors, rather than subdomains, to make this division. Doug's item 5 fits here too, but takes the discussion directly into the formation of reputation, which is out of this WG's scope. I'd like to see more discussion of this in a separate group that addresses reputation and accreditation standards. In any case, again, this is definitely NOT a threats doc issue. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Concerns about DKIM and mailiing lists
Hector points out something that I was planning to say about this: that it's really an issue for SSP (and so maybe that's the doc that's really held up by this discussion). Here's how I see it: From a base-spec point of view, as Dave says, we have the length tag, the list of signed headers, and the canonicalization that all help protect signatures against existing mailing-list behaviour. That means that the base spec mostly has the issue covered, and I think a brief discussion needs to be in there about what signers should consider with respect to mailing lists, and what mailing-list software developers should consider with respect to signatures. The biggest issue that existing mailing lists have is what they do to the subject header, since we particularly recommend signing the header and since so many lists (including this one) modify the header. And, in fact, many subscribers insist on that modification, even though they could filter on headers such as List-ID instead. One note here: the base spec COULD suggest that if the signature fails to verify and the subject is signed and begins with "[", that the verifier might retry after removing the "[xxx]" part. And then, much as with that part of the message that comes after the signed length, the verifier must decide what to do if the retry succeeds. But in the worst case, the list has simply invalidated the signature, and we say that this SHOULD be considered equivalent to no signature at all. Absent SSP, this is no bad thing. When we add SSP in, though, we have to consider the issue of a policy that says "we sign everything" and a mailing list that breaks the signature and does not add its own (remember, we're talking, now, about existing mailing-list software that is not DKIM-aware). I DO think the problem gets complex here, because we do not want to take this behaviour, which is now considered acceptable, and suddenly declare it to be "suspicious". And yet bad actors could take advantage of this loophole. Hector says: > SSP is what sold me on DKIM when it was first presented last year. Unfortunately, the deemphasis or movement away from SSP has made DKIM a lot harder to justify. I don't think we're de-emphasizing SSP nor moving away from it. What we've said is that DKIM signatures and keys are defined by a pretty mature spec that's gotten a lot of work put into it, but that SSP is much less mature and needs significantly more work. And that we believe DKIM has value without SSP, so the work on SSP should wait until after the base spec is done. We've allocated several months to work on SSP and, while some have opinions that differ markedly from Hector's about it, we DO aim to spend the time on it. In short, the responsible DKIM domain must have a way to tell potential verifiers and "resigners" (LS or not) how to best handle their DKIM messages. If the domain doesn't care about potential downlink problems, then it can only expect to be using a relaxed policy and therefore should not have any reasonable expectation for protection. If he wants protection, then it needs to declares the stronger, more 3PS restrictive or none/never policies. I don't think this considers the issue I discussed a couple of paragraphs up, where a signer wants to say that it signs everything, and a DKIM-unaware mailing list breaks the signature. That is the very issue that was brought up in Vancouver, and that some are quite seriously concerned about. The complexity isn't in the changes needed to mailing-list software; the complexity is in sorting it out WITHOUT causing existing mailing lists, which are considered well-behaved today, to be looked at suspiciously. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] 5 outstanding issues with the threat review
That's more of an issue of SSP, right? It's with SSP that you'd
like to subdivide the policy
Mm, I see your point, but I don't know that we want SSP changing the key
record, and that's where I'm thinking this would go ("This key is used
for Really Serious Stuff"; "This key is used for Frivolous User Stuff").
I'm not sure how to move that to SSP.
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
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
Re: [ietf-dkim] Concerns about DKIM and mailiing lists
One note here: the base spec COULD suggest that if the signature fails
to verify and the subject is signed and begins with "[", that the
verifier might retry after removing the "[xxx]" part. And then, much
as with that part of the message that comes after the signed length,
the verifier must decide what to do if the retry succeeds.
Not only would that be building a heuristic into the validation portion
of an otherwise precise security specification, it would be basing the
heuristic on an undocumented convention that is far from universal,
rather than on a a formal standard.
But in the worst case, the list has simply invalidated the signature,
and we say that this SHOULD be considered equivalent to no signature
at all. Absent SSP, this is no bad thing.
I am inclined to agree. However the [] behavior is rather common. So
we probably should consider whether it is reasonable to have DKIM
contain features that are intended to allow a signature survive mailing
list transit, when we know that the final result will usually fail.
Dave, your two comments here seem contradictory: "We shouldn't try to
handle '[]', because it'd be heuristic, but we should try to handle '[]'
because it's rather common behaviour." Do you have any ideas for
handling it that don't throw us into heuristics?
I don't think there's a problem with verifiers applying some heuristics
to this, given that (1) the signature is making a weak statement, and is
not mean to be strong security and (2) this whole evaluation (the
verification) is feeding into heuristics anyway ("What do I do with the
message, given all the input I have about it?").
I appreciate Paul's comment, though, about spammers using that to their
advantages. Maybe it's part of the next-stage heuristics, where some
hypothetical verifier considers "[ietf-dkim]" to be OK, "[Buy-Viagra]"
to be , and "[Come visit us at http://spam.example.com]"; to be
junk, using whatever next-stage heuristics it chooses.
I'm just afraid that the "[listname]" custom is sufficiently common that
if we DON'T deal with it, we're throwing away too much opportunity to
play nicely with existing well-behaved mailing lists. So I'd LIKE to
try to come up with a recommendation that helps (not a requirement, and
not perfection).
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
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
Re: [ietf-dkim] Re: Concerns about DKIM and mailiing lists, etc.
Let me try to pull this discussion back a bit... >> The verifier then simply replaces the subject text with the value >> from z= that was signed. That's one way of solving the mailing list >> subject munging problem. > > This goes far beyond the specification. While it might be useful, it > is really a heuristic and it is not part of the draft that is seeking > standardization. On the Cisco discussion: My understanding (Mike, please correct me if I misrepresent this) is that Cisco is primarily using DKIM, at least for now, to verify that mail purporting to be from cisco.com (and is TO cisco.com) is, indeed, from cisco.com. To that end, when you look at an incoming "cisco.com" message, you see one of these cases: 1. It has a valid cisco.com sig. 2. It has a failed cisco.com sig. 3. It has no cisco.com sig. For case 1, you're done, but see below. For case 2, you check SSP and see that cisco.com signs all mail, and you have to decide what to do with it (again, see below). For case 3, you check SSP and see that cisco.com signs all mail, and since this isn't signed, you toss it (or place it under other scrutiny). This is "below": To minimize the incidents of case 2, you use the z= tag in the signature, so that you can verify the sig with the ORIGINAL headers. You can then see WHICH headers changed in transit, and take action based on that. Now, z= was in IIM for that purpose, but in forming the DKIM spec we decided to label it for diagnostic/tracing purposes, and not for signature verification purposes. Of course, any implementation is free to implement. So some of the "case 2" cases now become "case 1" cases. For case 1, you have what amounts to a "reputation DB" that says "cisco.com is good." (Alternative interpretation, see next paragraph.) In any case, you can show mail with verified sigs to the users in some way that tells them that the "sending domain" (sorry Dave; we never did close on terminology here) has been verified. Whether or not you've done something special with "cisco.com" in the previous paragraph, the end user can look at "cisco.com" and "verified", and be happy. The user can also look at "nastyspammer.com" and "verified", and it's up to the user whether she's happy or not. In this case, the user's brain is providing the "reputation DB". Is that relatively close to what's happening? -- Now there's the question of whether using z= for the purpose that Cisco (and, if the option is turned on, Alt-N) is using it for is "OK". The DKIM spec does not say that that's what it for. Moreover, the DKIM spec gives a clear and well defined method for verifying sigs, and the use of z= is not part of it. So I'd say (as a participant, not in any "chair" capacity) that this doesn't meet the spec; that is, it isn't "compliant". That may be perfectly OK -- every implementation, as I said above, is free to implement. In Cisco's case, if this implementation is an internal thing, does anyone else care if it's "non-compliant"? In Alt-N's case, I'd think it ought to be clear that if the option to use z= is turned on, it deviates from compliance with the DKIM spec. Arvel, I'm curious: how do you explain that option to the administrator? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] 1193 considered harmful
I'm really astonished that an open item that had no list discussion that I can find and that is backward incompatible with -allman-01 is being "accepted". Why? As a WG chair: As we said in the IETF session and in the Jabber room, nothing "decided" at the IETF meeting is final until the issue is confirmed on the mailing list. All that was "accepted" in the meeting is that the consensus in the room was to favour this change. We are now (thank you for starting it, Mike) discussing it on the mailing list. I have for quite some time been placing a hash of the headers alone in the DKIM signature in an unassigned tag (X= in this message) to help me determine whether it's the headers or the body that broke on a failed signature. It's cheap: I just call SHAx_Final when the headers are hashed; it's unobtrusive: it doesn't require that we change our current hashing mechanism; and it doesn't bring up any nettlesome issues with l= which are tricky. As a WG participant: I don't see the problem you have, though. In particular, why is it better to store a header hash in a tag in DKIM-Signature than it is to store a body hash there? It seems to me that the combination of a BODY hash and z= will give the best diagnostic combination. l= seems a red herring (but explain, if I'm wrong), since the signer and verifier must already deal with deciding which part of the body contributes to the hash, whether they then hash it separately or not. Further, there are other reasons it might be rather nice to have the body hash. For one, it means that the verifier can start validating the sig after having read the header-terminating CRLF, without yet having to read the body, thus allowing the signature validation to be done in parallel with the reading of the body (which may be significant with large bodies). Related to that, it means that the verifier, if it has decided to trash the message, can do so by routing the body to /dev/null as soon as it's made that decision, rather than having to write the body to disk (or keep it in memory) while computing the hash. Third, as was pointed out, a sender could hash a large body once and send it multiple times, possibly saving a lot of time/effort. I don't see it as a big compatibility issue. If this be put in as a "bodyhash=" tag (yes, we'd use a single letter, but never mind that for now), a verifier could simply tell by the absence of that that this is an allman-01 signature, and could easily verify it anyway. We could even put a non-normative suggestion in the spec to that effect. So it seems to me that this doesn't harm existing implementations, because it provides a smooth transition and not an abrupt incompatibility. And it seems to me that it provides some useful benefits. As a participant, I support it. Mike, rebuttal? Others, comments? Are others worried about this introducing a damaging incompatibility? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] 1193 considered harmful
Third, as was pointed out, a sender could hash a large body once and send it multiple times, possibly saving a lot of time/effort. I'm sort of missing why this is an interesting feature. Reusing the hash of the body would only help if you were generating multiple signatures. Or using the same body in multiple messages. Suppose "Company I", say, is sending a (legitimate, opted-into) mass-mailing of a 70 MB video file to, say, 200,000 opted-in recipients. Suppose also that for some reason it has to batch these with different headers, so it can't just sign the whole message once. Saving the work of hashing that 70 MB video multiple times would be nice. I don't consider this a compelling reason (because I think most of these cases could -- and would -- just send identical messages, and could just hash once in either case)... it's just another reason beyond the others, which I do find compelling. > I suspect that the RSA signing operation overwhelms the SHAx cost by a very good bit on your average size of body. But that doesn't matter, because we're not RSA-signing the body, only the hash. So it's only the overhead of the hashing that matters. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] 1193 considered harmful
Well for one very big reason: it doesn't break current interoperability. ... This is very different from the current method, and a naive receiver would *not* compute the new signature correctly. That's correct; it would not -- the verifier would have to change to add this method of verifying, and could remove support for the allman-01 version when it's satisfied that it's not seeing them any more. You (Mike) clearly see this as more of a problem than I do. The compatibility I want to be careful to maintain is this: 1. Continue to be able to use existing DNS records. 2. Make the transition to the IETF spec easy by making sure that verifiers can verify both old and new sigs without much difficulty, and that signers can, therefore, make their transition when enough verifiers have done theirs. Even given that, I wouldn't advocate a change that means verifiers have to have two ways of verifying during the transition... if I didn't think it worth it. In this case, I do think it worth it. The method I outlined -- and have implemented for around 6 months or so -- does not break backward compatiblity and achieves the goal of determining if the breakage is in the headers or not. But it doesn't do any of the other nice things that I outlined. What would allow it, with no transition needed, would be to hash the body and put it in the header tag... and then continue to do the full-message hash as now. I think that's a non-starter, though, because it requires hashing the entire body twice (once by itself, and once with the header stuck on). Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] 1193 considered harmful
It does not break current implementations though. As Murray and Arvel's implementations can attest. Again, I didn't say your "X=" broke anything. I said that it requires a change in the signer and verifier in order to detect which of the header or body broke the signature. Well, but that's irrelevant. Mike's (correct) point is that if the verifier doesn't care about the new information provided, the verifier doesn't have to change. With the proposal on the table, all verifiers would have to migrate. I agree, though, that since the verifiers have to migrate anyway (to SHA-256), I think this is a less-than-compelling reason not to do this. The "slippery slope" reason is more compelling. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] 1193 considered harmful
I have a suggestion that I think might (ha!) satisfy everyone. That is, I THINK it will satisfy those who want the separate body hash, it will address Mike's compatibility concern, and it will not give Mark hives because of overloaded tags and burgeoning combinatorics. Suppose the base doc said this sort of thing: - ... signers MUST use a=rsa-sha256 ... ... hash the body and put the hash value in bh= ... ... hash the headers, sign that hash, put the signature into b= ... ... etc, etc, etc ... Section x.y: Backward compatibility with the pre-standard version Earlier, pre-standard implementations of DKIM used a different hash mechanism. Owing to significant deployment of that mechanism for early adoption and experimentation/refinement leading to this specification, current implementations SHOULD maintain signature-verification compatibility with the earlier version as follows: 1. Support the SHA-1 hash algorithm, and recognize and respect the a=rsa-sha1 tag. 2. Support the earlier mechanism of using a single hash, as indicated by the absence of bh=, by computing the message hash thus: to put the headers and body together for the hash here, noting that the canonicalization is identical> Verifiers MUST NOT accept a=rsa-sha1 in the presence of bh=, and MUST NOT accept the absence of bh= in the presence of a=rsa-SHA256; those combinations are contrary to this specification, and their use is NON-COMPLIANT. - What do y'all think (I picked that up in Dallas)? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
[ietf-dkim] Splitting the DKIM base doc
Dave brought up, at the Monday DKIM IETF session, the idea of splitting out the key-discovery parts from the base document. I've recently come up with a need to have the canonicalization be separately referenced. I'm throwing this out to the mailing list for discussion: Should we split the DKIM base doc into independent modules? I believe Dave has a specific idea that he might share with us... Dave? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] DKIM Working Group Summary, IETF 65
> Would it make sense to break these up into separate threads? Anyway, > here is my comments on some of these issues. It might, but mostly it would be useful to remove [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from the distribution list if there are further replies to this thread. Those addresses were only there for the official Security Area submission of the WG meeting summary. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Splitting the DKIM base doc
The next milestone should be WG last call on base in May, so if your suggestion is likely to cause that date to slip, I guess it'd be good to include a justification for that. Good point, of course. Dave and I babbled briefly at each other about this recently, and I think a split makes sense -- the benefit is keeping the independent elements isolated, allowing 1. components that can be referenced separately (and can reference each other, and 2. components that can be added or replaced as necessary; this is particularly useful for things like "how do I canonicalize the message", "how to I get the signing key", and "how do I encrypt/decrypt" (that last is already split out, by reference to RSA and SHA-x). I think the work of splitting it will be small, and won't affect the schedule, but I'll let Eric, et al, make that ultimate judgement. My inclination is to give the document editor a veto option on it, to avoid schedule problems. On the other hand, I think getting the document structure right is important. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] 1193 considered harmful
How does this address my concern? This looks like my current receiver would fail with the new signature format. That's not backward compatable. All verifiers already have to change, to support SHA-256. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] 1193 considered harmful
However we have so far preserved the ability of a pre-IETF signer to work with a post-IETF DKIM verifier. (So, Barry's statement is true, > but I'm not sure it addressed the concern. I believe my text, or a reasonable variant of it (modulo Paul's concerns, for instance) preserves this ability. Do you disagree? Perhaps, if you do, changing a SHOULD to a MUST would fix that? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] 1193 considered harmful
1) ± can determine if body or headers are broken; - because it can be done in a backward compatible fashion. 2) + can determine early on if header signature is valid; weak because you won't ordinarily have the key, and most especially not from malicious domains 3) + can hash a body once for redistribution; a fairly marginal feature that might help mass mailers, but Moore's law is just as likely to help, um, more. 4) - breaks backward compatibility 5) - no way for signer to determine when it's safe to not send -allman-01; the longer we wait for the RFC #, the bigger this problem becomes 6) - canonicalization/hashing agreement is the hardest part of the spec to get right from an interop standpoint. So the way I look at it you've got one nice benefit that can be implemented in a backward compatible way, and two benefits that are of fairly marginal utility. The downside is that we get churn in the part of the spec that's hardest to get right, and a not terribly easy way for a signer to know when it's safe to deprecate -allman-01. If (2) were more a reliable feature this would be harder call, but absent other upsides I've missed, I really don't see the overall benefit. When Mike posted this the first time, I thought he made a couple of good new points with items 2 and 5. I decided to leave my "chair" hat on and see where we went with those, and I don't think they've been adequately responded to so far. Comments addressing those are cetainly new input, and are welcome. I do think we can write the spec so that the proposed change doesn't break old signers with new verifiers. I think that's the side of compatibility that's most important. I think we cannot make old verifiers work with new signers in any case, if we encourage new signers to move to SHA-256 (unless the signers double-sign). I think Mike's still right that the advantage in item 2 is weakened by the fact that we still have to retrieve the key, and we might as well continue sucking down the message body while that happens. - Back to "chair" hat again: I agree with Stephen that we need to finish up this issue. I've seen a few posts supporting the change, so I'd like to ask specifically if anyone besides Mike thinks that we should NOT change the spec to hash the body separately as discussed. If you have not yet said that you support the change, please post here and say that you DO support the change, that you DO NOT support the change, or that you DON'T CARE. Further discussion is also fine if there's something NEW to add, but please don't rehash what's already been said. The key point is, as Mike makes clear, whether the advantages of this are worth the incompatibility that it causes. I plan to get minutes posted tomorrow, and we'll have a comment period on the minutes, including this issue. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Proposal for specifying syntax and semantics for multiple signatures
This must be done in a way to prevent bid-down attacks during transitions, I believe that Mark also has a proposal on the table for how to deal with bid-down attackes. And actually, as I recall the discussion in Dallas it seems that even Russ and EKR were not worried about this issue. The idea was that it's down to the verifier to determine which algorithms it's willing to accept, and the removal of a "stronger" signature only matters if the verifier isn't willing to accept the remaining, "weaker" one. I have no opinion on this; I'm just bringing it up to the mailing list from the session in Dallas. also must be done in a way so the recipient can unambiguously determine the order in which the signatures appeared. The downside of this are MTA's that reorder headers, which they do unless they know it's a trace header. Which they don't for DKIM since it's new. Someone else had suggested adding some sort of signature sequence field, which, if we did that, could robustly identify the order, and could make is clear which are missing. Something like this: DKIM-Signature: seq=3,1,1; ... DKIM-Signature: seq=2,2,2; ... DKIM-Signature: seq=2,1,2; ... DKIM-Signature: seq=1,1,1; ... ...where the numbers represent signer sequence, signature sequence for this signer, number of signatures that this signer added. Mike is right that we can already sign all the existing sigs when we add a new one, so it's really only the ordering that we have to worry about. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Proposal for specifying syntax and semantics for multiple signatures
Someone else had suggested adding some sort of signature sequence field, which, if we did that, could robustly identify the order, and could make is clear which are missing. Something like this: DKIM-Signature: seq=3,1,1; ... DKIM-Signature: seq=2,2,2; ... DKIM-Signature: seq=2,1,2; ... DKIM-Signature: seq=1,1,1; ... ...where the numbers represent signer sequence, signature sequence for this signer, number of signatures that this signer added. Mike is right that we can already sign all the existing sigs when we add a new one, so it's really only the ordering that we have to worry about. Somebody needs to help me out here. What problem is getting solved with this geneology exercise? I've been at this a while, and I've never had a moment where I thought "it would really be nice to know which begat what". Well, the issue is that if, say with the above example, signer #3 signs the other three signature headers, and then the next hop re-orders them, the verifier can still figure out which records signed which others. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Proposal for specifying syntax and semantics for multiple signatures
Well, the issue is that if, say with the above example, signer #3 signs the other three signature headers, and then the next hop re-orders them, the verifier can still figure out which records signed which others. So what? So the signature can survive the reordering; it's essentially a helper for canonicalization. I'm not suggesting it's critical, only that it was suggested, that we had no further discussion on it, and that it's an alternative to Paul's proposal and should be discussed together with it. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Proposal for specifying syntax and semantics for multiple signatures
So, in an attempt to move towards that, let me try to ask for opinions on this discrete part of the issue And I'd like to get us to close on two other discrete parts: 1. Whether we want to have a mechanism to let the signature survive the reordering of multiple sig headers or not. I've heard Mike and Dave say no, we don't. Is that correct? 2. Whether we want to be able to detect the removal of a signature header (as perhaps in the case of a "stronger" one and leaving a "weaker" one). I think the consensus is that we don't care about this; I'd like to confirm that. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Proposal for specifying syntax and semantics formultiple signatures
I think it depends on your "Verifier" the guys who have to make the decision with all the junk coming into the system how it will view it. ... Are we suppose to turn a blind eye to the quality of the message and just look at who is responsible? If so, then who cares what the message quality is as long as it comes from a "good person." We have to be clear about what DKIM is and isn't. DKIM is something that lets a sender say "my domain sent this message". DKIM is something that lets a verifier confirm that, and use it as part of its decision of what to do with the message. DKIM is NOT something that says ANYthing about the trustworthiness of the signer, or of the "quality" of the message. Any decisions about the quality of the message or the goodness of the source are made by the verifier, POSSIBLY using the information provided by DKIM as input, but not directly resulting from DKIM. In particular, any attempt to include that sort of information in DKIM is explicitly out of scope for this working group. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Proposal for specifying syntax and semanticsformultiple signatures
In particular, any attempt to include that sort of information in DKIM is explicitly out of scope for this working group. I thought we have moved on to SSP? SSP is not out of scope. Correct? I am referring to SSP to help answer many of these questions being raised, including this thread about nth signatures and ambiguious mandate on how it should be "Intepreted!" Well, first, we're still focusing on the base, which is supposed to be done within two months now. Second, even SSP does not aim to address the quality of the message or the trustworthiness of the signer. The closest it comes to that is that in the current formulation, the RFC822 From domain can advise the recipient that it would like them to be suspicious of messages that are not signed directly by it. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Proposal for specifying syntax and semantics formultiple signatures
DKIM is something that lets a sender say "my domain sent this message". If you went out and asked 20 non-technical people -- enough to make an interesting sample of the population -- what they think your above sentence means, I predict that all 20 would respond that the semantics were along the lines of "someone in that domain wrote the message" Yes; I was trying to be very terse, and obviously succeeded too well. The wording I usually use is "my domain put this message onto the Internet", usually clarifying that it could be an initial "put" or a relay. rather than something like "something (person/software) related to that domain *handled* the message." I like "handled". Of course, I'm sure we'd get 20 different versions of what THAT means too, so Given the predisposition folks have towards such misunderstandings, it well might be worth a distinct section of text (with a table of contents entry) that anticipates the problem and discusses it. ...that's probably worth doing, yes. Thanks, Dave, for volunteering to write the text. Post here and send to Eric when it's ready. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
[ietf-dkim] Jabber room problems
We seem to have lost the jabber room for the meeting... and I seem to have lost Stephen on a separate chat window. Let's see if we can convene some people in a different room, though I'm not sure we can work it with short notice: [EMAIL PROTECTED] If you're trying to attend the "real" jabber meeting, please try that one. At least we can try to sort out logistics from there. I'll stay in that room until 1600 GMT (1200 my time, New York). Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) 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
[ietf-dkim] Summary of jabber meeting on 2006-05-25
Before I get into the summary of the jabber meeting, I want to say this: We finished getting through the open issues, and there are just a few that need more discussion on the list. I've asked Eric to work on getting an -03 version out, after mailing list discussion of those few issues, within two weeks. That means that (1) everyone MUST read -02 and make sure that it's ready (modulo these few open items), and (2) we must get these last few items discussed and sorted through, and we must all focus on resolving our differences on them and finding a consensus that we think works. Please hold to hard lines at this point only when compromising on that item will truly be harmful. I know we can get this wrapped up and ready for Working Group Last Call on the -03 version of the document! --- We called today's jabber session to order today at 15:00 UTC, and went through the remainder of Eric's issues list, starting where we left off last week. Eric's list does mostly match with Eliot's, and we referred to Eliot's for the details of the issues. For reference, some pointers: Last week's log: http://www.ietf.org/meetings/ietf-logs/dkim/2006-05-18.html This week's log: http://www.ietf.org/meetings/ietf-logs/dkim/2006-05-25.html Eric's issues list: http://mipassoc.org/pipermail/ietf-dkim/2006q2/003640.html In attendance: Barry Leiba, Stephen Farrell, Paul Hoffman, Doug Otis, Peter Koch, Eric Allman, Mike Thomas, Jim Fenton, Dave Crocker, Tony Hansen, Bill Oxley. The bits in quotes at each issue title are quoted from Eric's list. Issue 1263: "(get rid of x=): I /think/ this has been resolved." Participants did, indeed think it has been resolved; issue should be closed. Issue 1264: "(proposed fingerprint tag description)." This was proposed by Murray, who wasn't on the jabber chat, and the participants didn't know enough about it to discuss it in Murray's absence. Issue remains open; push it back to the mailing list. Issue 1265: "(signing by parent domains)." Some see potential issues with the ability to say something like "d=example.com" and "i=sub.example.com". In particular, there's the danger of something like "d=com; i=example.com". Some think there's little benefit to allowing it, and closing the hole would be better. Others see a great benefit, allowing example.com to have one place to go for keys, while signing for many subdomains. Eric suggests this: "thought: a domain could use a CNAME for _domainkey..example.com that would point up the tree." Jim Fenton will start a thread about this on the mailing list. No resolution for now; leave open, discuss on mailing list. Issue 1266: "(sec 5.2 move recommendations for key retention to a BCP)." Lots of discussion about whether to specify a length of time or be vague about it, whether being vague is of any value to implementors, and whether it even makes sense to try to tell verifiers what they MAY or SHOULD do, since they can (and will) do whatever they want anyway. In the end it seems that a modification of Doug's proposed rewording can be acceptable to all, so Eric is going to do another pass on the wording and post it to the mailing list. Issue remains open until then. Issue 1267: "(expiry based on received time rather than current time)." Doug is happy with what's in the -02 draft on this, and no one else voiced any concern. Close. Issue 1268: "(format of t=)." The issue is whether to leave this as an integer representing seconds since 1970, or whether to change it to some more readable version, which might be easier to compare with other fields in the message. Brief discussion, which included a "not broke, don't fix it" comment. Chairs agree and suggest no change unless there's a "really good reason to change it." Much agreement, and no "really good reason," so issue is closed with no change to the spec. Issue 1269: "(body length mechanism rejections)." Looks like we're happy with what's in -02, but just as we start to move on there's more discussion along the "can't tell verifiers what to do" line. The original issue was an objection to advising verifiers to "reject", and the consensus on that, as advice, stays. In particular, we want to advise verifiers on determining whether a signature is *valid*, but leave the "what to do with it" part for another document (or local policy). Tony doesn't like the advice to ignore the signature. Others clarified that what we're really saying is to look at the other sigs in that case. Most accept current wording, but there's some unhappiness all 'round, so it&#
Re: [ietf-dkim] Issue #1265: Signing by parent domains
indeed. which prompts the obvious question: why are folks pursuing this. And I think the thread has gone on long enough with enough participants for me to say that I see strong consensus that this particular concern is not shared. This subtopic is closed. Let's look at any other reasons to remove the parent-domain point. Is there one? -- Barry Leiba, DKIM Working Group Chair ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] draft changes discussed in Thursday Jabber session
Eric Allman said the following: I've put the revised version of the draft (I called it "-03a") up on <http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-03a.html>. This has the changes we discussed yesterday, and I'm hoping that enough people will have read the relevant sections that we can discuss them in our Monday Jabber session. And so this is a reminder that we have a jabber session in about 45 minutes, as I type this. I'll be moderating, and I'm going to let Eric control the agenda, since the goal is to resolve the issues that he thinks he needs to sort out for an "official" -base-03 version. The broader goal will be to have a -base-03 submission that we can do "working group last call" on. Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Issue 1287: K... Otis, signature removal
Wait a minute, hasn't this been discussed ad nauseum with the clear consensus to leave this text in? Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified. Well, it's easy to sort out whether we've had sufficient discussion: Does anyone support Doug's request to remove this text? If you do, please respond here by Thursday's jabber chat. Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Montreal agenda, other than base
We do have draft-allman-dkim-ssp-01; is there any problem with using that as a starting point? As Stephen says, it's in our charter as a starting point. But we have to consider it *a* starting point, because we've already seen at least two more views on what a signing policy/practices/poodle should look like, and they differ enough that we need to review them as separate IDs first. I certainly expect that allman-dkim-ssp will be one of those we review. Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) 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
[ietf-dkim] jabber again today
Reminder: We have another jabber meeting scheduled for today, 8 June, at 1500 UTC. I have one hour free then, but Stephen has said he can continue it up to two hours, if that's needed. The first goal today will be to finish up the issues we missed getting to last time. Please have reviewed Eric's -base-03b document before the meeting: http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-03b.html And again, the room is "[EMAIL PROTECTED]". Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) 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
[ietf-dkim] Run away! Run away!
Stephen is in Bruxelles, with little or no Internettedness. I will be leaving for Germany tonight, and will be away from the Internet 'til Monday. The cats are away. Y'all play nice while we're gone. Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) 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
[ietf-dkim] Jabber meeting for 22 June
We will have the next jabber meeting this Thursday, 22 June, at 1500 UTC. We'll try to keep it to an hour, and the plan is to review the issue list, with the goal of being ready to submit a -base-04 draft before the Monday deadline. Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) 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
[ietf-dkim] Summary of jabber meeting of 22 June
The full jabber log can be found here: http://www.ietf.org/meetings/ietf-logs/dkim/2006-06-22.html The 22 June jabber meeting was called to order at 1500 UTC on, surprisingly, 22 June. In attendance were, in jabber-roll-call order, Barry Leiba, Dennis Dayman, Doug Otis, Eric Allman, Jim Fenton, Peter Koch, Murray Kucherawy, and Mike Thomas. The agenda was simply to go through the issues list and check status, to make sure we're on track for working-group last call of the -base-04 spec, which Eric intends to submit by the deadline of this Monday, 26 June, at 6 a.m. Pacific Time. I will list the issues here, along with the conclusion and action item(s). For details of the discussion, see the jabber log. 1286: draft-ietf-dkim-base-02 //a= algorithm ABNF 1286 will be CLOSED, change made for -base-04. 1287: base: signature removal Discussion revealed that John Levine had volunteered to give Eric some proposed text to resolve this. 1287: REMAINS OPEN, John Levine to propose text to Eric. 1288: base: signing address Jim Fenton had agreed to work with Eric on text for this. 1288: REMAINS OPEN, Jim to work with Eric on defining default in one place & referring to it later. 1289: Base-02 signature process clarification requested Some did not understand this; Barry and Jim both do, and have volunteered to propose text. 1289: REMAINS OPEN, Barry to propose text. 1291: Use of "sender" in -base Dave sent Eric text for this, but one other issue came up yesterday. Eric is OK to resolve that, so... 1291: CLOSE, fixed in -base-04 1292: draft-ietf-dkim-base-02 //g= template Much discussion of this, with decision to define a flag instead of what the issue DB suggests now: Key record will have a new flag that says that i= must be the same as d= in order to use this key. 1292: CLOSE, fix will be made in -base-04 as per above. 1293: base-02 // worst-case scenario/duration of exploit/use of deprecated Insufficient understanding of this item. Doug has posted something he says is clearer, but people hadn't read it yet. We'll all go back to the list with this one. 1293: REMAINS OPEN, study and discuss on mailing list. 1294: draft-ietf-dkim-base-02 //i= parameter conflict Only Doug wants this, but no one else agrees. Doug says that John Levine supports it, so we'll check that on the mailing list. As it stands, NO CHANGE will be made for this unless there is other support. 1294: CLOSE with no change... pending confirmation on mailing list. 1295: issue with relaxed body canonicalization? Brief discussion on whether to leave it in for now, consensus is to leave it and remove later (maybe at move to Draft Std) if it turns out to be unused. 1295: CLOSE, no change. 1296: [EMAIL PROTECTED] vs. [EMAIL PROTECTED] This is John Levine's version of what basically is the same as 1292. Let's see if John likes the answer to 1292 for this too. 1296: CLOSE, see resolution for 1292 -- subject to confirmation with JohnL. 1297: Clarification on z= Discussion about the QP thing and how to put leading blanks, already discussed on the mailing list. Eric has posted text to mailing list, but not everyone has read it. Go read. Lacking objections, we'll use that text and close this. 1297: CLOSE, accept Eric's text for -base-04. That's the end of the issues list. Doug repeated a request that he's made before: "There should be some consideration give the Security Consideration section regarding the affects of the _domainkey subdomain use." Eliot, please open a new issue for this so we can track it. So far, we've not seen support on the mailing list for putting this in, but we'll open a tracked issue for it and give it one more chance during WGLC. DKIM meeting ended at 1558 UTC. Thanks, all. -- Barry Leiba, DKIM Working Group Chair ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Base-02 //Deprecated Signature Version & New List
Douglas Otis said: There remains the issue describing a deprecated algorithm as being ignored, which is identical to treatments for obsolete algorithms (signature versions). Perhaps there could be few minutes placed on the agenda to allow an attempt to explain why this could become a problem. The solution could be as simple as defining an optional c= tag (concurrent requirement) in the key. No, I'm not convinced we need to spend more time on it, I see no support for the idea that we should, and I see several people saying we shouldn't. We decided a long time ago: 1. If a signer doesn't want to use an algorithm any more, it should simply not use it, and should cease publishing the keys that were used for it before. 2. If a verifier doesn't want to accept an algorithm any more, it should simply not accept it, and treat signatures with that algorithm as absent or invalid, depending upon how it chooses to interpret things. 3. We're left with the case where an algorithm is sufficiently compromised that an attacker can insert a valid signature with that algorithm, and yet the signer wants to keep publishing the public keys for a while because it's still within the reasonable verification time for some already-sent messages. No one thinks this is a problem worth solving because the likelihood is low, the window is small, and the signer CAN resolve it by not publishing the key and letting the legitimate signatures that remain fail. Unless there's more support for spending time on this again, it seems that Stephen and I agree that the issue is closed. Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Relaxed body canonicalization
Paul Hoffman said (abridged): [11:42:35] 1295: issue with relaxed body canonicalization? [11:43:07] i feel strongly about keeping relaxed header, but i'm neutral on relaxed body. [11:43:42] I'm sort of weakly in favor of keeping it [11:43:51] what he said [11:43:59] deleting it would simplify the code, but not by much. [11:44:07] I'd sort of like to keep options open, though with no good empirical reason [11:44:12] and maybe some rewriter we haven't anticipated yet [11:44:13] so I'm +0.1 for keeping it. [11:44:38] i'm a little stronger for that, let's say +(2/3) I definitely think relaxed body canonicalization should be removed from the -base spec unless there is a known use case. As we can see from the jabber-log excerpt, there are three opinions to keep "relaxed body", but they're weak (Murray is the strongest, and he, too, is waffling). Paul, on the other hand, is strongly in favour of dropping it. The decision from the jabber meeting was to keep it, thinking that we could drop it later if it turns out not to be used. Paul correctly points out that we could just as well drop it, and put it in later if it turns out to be needed. I'd like to see other participants weigh in; please do not remain silent and assume anything about what Stephen and I will take that to mean. I'd especially like Eric, Murray, and Mike to say whether they're swayed by what Paul said. For what it's worth, I agree with Paul. If those who've been running this stuff haven't found a real need for "relaxed body", why don't we fall on the side of simplification? Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) 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
[ietf-dkim] Working-Group Last Call on draft-ietf-dkim-base-03
Since we seem to be working out what issues remain with draft-ietf-dkim-base-03, and it's a batch of relatively small things, Stephen and I feel confident in calling for Working-Group Last Call on that document, to end the Friday AFTER the Montreal meeting -- that will be 21 July. The goal is to close out the base doc at that point and for Eric to get the next draft submitted ASAP after that... and that draft would go to the IESG. So... let's continue as we've been, with that in mind. Eric may post intermediate pre-04 drafts here if he thinks that'd be useful. Barry -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on -overview document?
I started going through the overview doc, but it wasn't clear to me whether discussion on it was welcomed yet on the list, lest it steal focus from -base. Can the chairs clarify this? The chairs think this is a fine thing to start discussing now. -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Draft minutes...
EVERYONE, PAY ATTENTION TO THIS! Please STOP using this subject line. If you have an issue to discuss, please create a new subject that describes the issue you are discussing. DO NOT USE THIS SUBJECT LINE! -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: which headers should we REQUIRE to be signed?
I liked Dave's phrasing, so I'm using his message as the anchor for my reply: If we take the view that -base should be limited to mechanism, and that it defers "policy" issues to separate specification, as well as operational preferences that develop over time, then this makes quite a bit of sense. Given the discussion during today's working group meeting, I think we should seriously consider taking Mark's suggestion seriously. I agree. I personally like the idea that we should leave the decision of which header fields to sign purely up to the signer. But that's me, not the chair, talking. As chair, I see a growing consensus to do it that way. Let's try to resolve this issue tout de suite, and move on. I'd like to hear from people who think we should have some headers as "MUST sign". I'd like to hear from those who agree with Mark and Mike, that we should not have any with "MUST". What say you? Barry -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] drop requirement to sign "From" or other "originator" headers?
Oops... I didn't get to this yet when I made my last post, so I'm sorry for adding another subject line for the same thread. I hope people have the sense to ignore me, and to post here. :-) Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Which tags are required?
Section 6.1.1 says: If the DKIM-Signature header field does not contain any of the tags listed as required in Section 3.5 the verifier MUST ignore the DKIM- Signature header field and return PERMFAIL (signature missing required tag). It would be good to list all of them in 6.1.1. While we're here, I'll point out something I missed until Paul set this sentence out separately: the sentence's negative is done badly, leaving it open to misinterpretation (it looks like it means "if NONE of them are there"). I think this works better: "If any tag listed as 'required' in Section 3.5 is missing from the DKIM-Signature header field, the verifier [...]." "Omitted" might be better than "missing"; I'm not sure. Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] More on naked CR canonicalization
(I'm just picking a random message from this thread to respond to; this isn't a specific response to this specific message.) I see a clear consensus in this discussion, and I think the issue's actually already handled in the spec. In section 5.3, we say this: Should the message be submitted to the signer with any local encoding that will be modified before transmission, such conversion to canonical form MUST be done before signing. In particular, some systems use local line separator conventions (such as the Unix newline character) internally rather than the SMTP-standard CRLF sequence. All such local conventions MUST be converted to canonical format before signing. I think it might be helpful to mention that some messages are formed with bare-CR, as well as with bare-LF, to clarify this particular situation, but beyond that we're OK. In other words, rather than making this a canonicalization issue, I suggest that we make it an issue in the normalization step of the message. (For those who aren't sure, the distinction is that the normalization step is actually permanently changing the message by putting it into normalized form, which the canonicalization is only changing the bytes that get signed, but not changing the message itself. Therefore, the normalization is only ever done once, before doing the rest of the steps for signing, and the verifier never has to know about it.) Unless we hear objections to this other than from Mike, we'll call this finished. So: Mike: Can you live with this answer, even if it's not what you'd prefer? Eric: Will you tweak that paragraph in 5.3 to mention that some messages that are considered compliant with RFC 82x fail complicance with RFC 282x in this regard and MUST be normalized? Barry -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 822/2822 or just 2822
I have seen a combination of references to 822 and 2822 in recent discussions on the list. Is the requirement that DKIM support both 822/2822 content (822 being the current standard) or is the intent that DKIM is just required to support 2822 content? I believe there are two parts to the answer to that: 1. We refer to RFC 282x, as the current standard, and that's what we're aiming to support. 2. We're trying, to the extent we reasonably can, to deal with most of what's actually out there, which includes RFC-82x-compliant stuff as well as some small subset of odd or "broken" behaviour that we consider to be common enough to be worth working with. Does anyone think that's not the right answer? Barry -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] More on naked CR canonicalization
This paragraph is rather misleading because it implies to me that you must convert to the canonical form for the *hash* function, not that you must convert the message before forwarding. OK; if you can propose a rewrite to Eric that'll make the intended meaning clearer, I'm sure he'll appreciate that. I'd still like to hear from Eric about this though. Yep; me too. He's away (and away from computers), and will be back some time next week. Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] Internationalized domain names
We should not be thinking about changing IDNA or RFC 2822 in the DKIM WG. The chairs agree, and the chairs also note that, related to this, we have said that we will also mostly not be thinking about how to work with EAI here. I say "mostly" because there's a likely outcome for much of what EAI's doing, and we shouldn't make changes to DKIM that will interoperate badly with that outcome. Barry -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Base-04 // ABNF cruft & errors
All of these in Doug's latest note seem like reasonable changes. Only one thing: The RFC2822 FWS ABNF definition carries some cruft. obs-FWS = 1*WSP *(CRLF 1*WSP); obsolete RFC822 text FWS = ([*WSP CRLF] 1*WSP) / obs-FWS Is there a reason to permit multiple CRLFs? To obsolete support, the definition should be removed after 5 years of being declared obsolete. FWS should be redefined as Revised FWS such as: R-FWS=([*WSP CRLF] 1*WSP); revised I'd rather leave the FWS definition in RFC2822, rather than putting in our own. Is there a way to say something that means "FWS from RFC2822, but NOT obs-FWS"? Barry -- Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) 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
Re: Fwd: Re: [ietf-dkim] Introducing myself
Please stop this thread with this subject line, and see my next message. -- Barry Leiba, DKIM Working Group chair ([EMAIL PROTECTED]) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Re: Canonicalization that decodes Content-Transfer-Encoding
If this discussion is to continue, please use this subject line (or another one like it that you prefer). Looking for it and keeping track of it with that "introducing myself" subject is silly. Apart from that, I'd like to see the discussion stop (though we chairs are not going to put any feet down about it yet) until there's an Internet Draft documenting a new proposed canonicalization. Then we have something clear to discuss. Also note that the base spec has completed last call and is scheduled for the next IESG telechat on 12 Dec. Charles has brought this up in last-call comments, and the IESG will be considering it, along with the work the WG has already done on canonicalization. -- Barry Leiba, DKIM Working Group chair ([EMAIL PROTECTED]) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-base-08 submitted
Most of the changes that Eric made should be non-controversial, involving clarifications and tweaking that have helped us (the draft authors and the working group chairs) explain things to the IESG. Regardless, though, of the non-controversial nature of those changes, the chairs would like the working group to review the document fully. The most changes are in two areas: The security considerations, where some significant changes went in after discussion with the Security Directorate. We hope these fall into the "non-controversial" category, and we urge the working group to object only with strong reason. Section 5.4.1, "Recommended Signature Content". Stephen has posted a pointer to the extensive IESG comments, but to summarize: there is concern in the IESG that, given no guidance at all, some signers will create perfectly compliant signatures that no verifier will accept even after verification succeeds, resulting in an interoperability problem. The new version of section 5.4.1 is thus attempting to give minimal advice, which might be modified by more specific signing policies defined later, to alleviate this concern. Please review and discuss. The chairs would like the group to complete this discussion quickly and efficiently, so that the IESG can send a final draft to the RFC editor very soon. To that end, we're setting the discussion period to a week, and we're asking that we keep any discussion of the -08 draft tightly on track. The point here is not to rehash anything that's already been discussed, to pick again at anyone's pet points, nor to go on about unimportant details. The point is to decide whether with these changes, the document remains a solid protocol that has the rough consensus of this community. As usual, when you start a discussion thread, don't use this subject line. Use something specific to the topic you're discussing. A week of discussion -- which ends on 26 January... and starts now. -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] draft-ietf-dkim-base-10 submitted
The DKIM base draft has been updated and submitted. The changes are minimal, comprising response to IESG review and some XML updates intended to smooth the rfc-editor review. And the -base-10 draft is now on its way to the RFC editor queue,[1] having passed IESG review. Many thanks to everyone who worked to get this done. And now we just wait for the RFC editor process, and the RFC number for the Proposed Standard. -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) [1] Here's the datatracker link: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14210&rfc_flag=0 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Adding SMTP client Requirements
Our next step with the SSP requirements document is to push it to the IESG (on Barry's to-do list I believe). Yep, and that's now done. Barry -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Adding SMTP client Requirements
Because DKIM has not resolved the issue of replay abuse, DKIM is indirectly promoting a dangerous means to associate domains. The DKIM WG should reconsider their strategy. Doug, will you (briefly) say what the replay scenario you're looking to address is? Thanks. Barry -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Re: Adding SMTP client Requirements
A DKIM signed message can be replayed from other SMTP clients. This is a desirable feature, but permits abuse when receivers base message acceptance upon (the reputation of) the DKIM domain. Are you talking about the scenario wherein you send a message in a legitimate way and capture the signed message (for instance, you send a message from your mail-abuse.org address to your own yahoo.com address), and then you re-send that message, perhaps as spam, from some other domain (say, spam-is-profitable.com)? Barry -- Barry Leiba, DKIM working group chair ([EMAIL PROTECTED]) 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
Re: [ietf-dkim] IETF 69 DKIM session
Next pass: MON 1520-1720 Afternoon Session II Breakout 2 SEC dkim Domain Keys Identified Mail WG This looks reasonably solid, but keep an eye on the agenda. -- Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM in the local news
The Chicago Tribune used to be THE paper of record in Chicago. It had a national reputation. THe quality of the enclosed article suggests it isn't quite at the level it used to be. Still, it's nice to see the DKIM reference... BTW, I'll point out that the "quotes" from me were not actually quotes. Jon Van took notes during conversation over lunch, and those are actually his approximations of what I said, based on his notes and his understanding. So please, no quibbling with me about the quotes. Basically, he got it mostly right and it's decent publicity. Dave, will you put it on the dkim.org page? I think the basic link is this: http://www.chicagotribune.com/business/chi-fri_netheadsjul27,0,5876748,full.story ...but I think it'll drift into the archives in 30 days, so I'm not sure how to save it. Maybe I'll print a PDF of the web page and we can post that? Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Processing SSP issues in January using jabber/concalls....
Dave Crocker said the following: Stephen Farrell wrote: Only place we're a bit off is the 30 day notice period. If we want to be strict about that then I guess we can push the dates further forward, but if everyone's ok with starting early in the new year, then I think we should be Who is the 'everyone' that you are relying on to vet the decision to do a variance? I should point out that we're off by ONE DAY on the 30-day notice issue. If you think we should toss out the 9 Jan session on that basis, OK, we will. Barry Leiba, DKIM working group chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Processing SSP issues in January using jabber/concalls....
Barry Leiba said: I should point out that we're off by ONE DAY on the 30-day notice issue. If you think we should toss out the 9 Jan session on that basis, OK, we will. Um, as y'all've noticed, my brain said "9 Jan", though Stephen said "3 Jan". So, yes, we're short a week, not a day, on the 30-day notice. Still, the rest of what I said stands: If any participants, or the ADs, think that 23 days' notice isn't sufficient, or that 3 Jan is too close to the new year, we can lose that one and start on 10 Jan. Dave, it's not clear whether you actually object to it, or whether you're just concerned that others might have a problem with it, and are noting that it's not standard procedure. Scott Kitterman said: > Personally, I'm not aware of any such complaints and I think in > an open entity such as the IETF, secret complaints should get no > weight. Well, for better or worse, there are often reasons not to make complaints public, and we do consider them, at least at the early stages. I personally think that's for the better. Eventually, if the complaint is overruled and the plaintiff wants to appeal that decision, s/he will have to go public. But we digress Barry Leiba, DKIM working group chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] SSP issues status
Stephen Farrell said... Sorry about the delay with this, Barry and I had problems syncing up over the holiday and have only now gotten this done. Stephen is being too kind. He had nothing to do with the delay; that's down to me. And thanks, Stephen, for getting the list posted to the list. Eliot has set us up for a conference call this Thursday, 17 Jan, as we'd originally scheduled back in December (actually, we'd planned to start on 10 Jan, but we didn't make that; see "delay" above). It'll go along with a jabber meeting, for which we'll use the normal DKIM jabber chat room, < [EMAIL PROTECTED] >. The conference call will be at 16:00 UTC (11:00 US Eastern, 08:00 US Pacific, 17:00 in much of Europe), and is scheduled for an hour. The call-in information is pasted below. Barry - Date/Time: January 17, 2008 at 05:00PM Europe/Amsterdam Length: 60 Frequency: once Meeting ID: 312851247 Meeting Password: Global Access Numbers: http://cisco.com/en/US/about/doing_business/conferencing/index.html (See list below.) TO ATTEND A VOICE ONLY CONFERENCE 1. Dial into Cisco Unified MeetingPlace (view the Access Numbers or link above) 2. Press 1 to attend the meeting 3. Follow the prompts to enter the Meeting ID 312851247 and join the meeting SUPPORT Information about this Conference: Contact Eliot Lear, 41448787525 Cisco IT Support Center: Attend the Voice Conference and then press #0 on your phone keypad GLOBAL ACCESS NUMBERS COUNTRYLOCATION LOCAL NUMBERTOLL FREE-FREEFONE AlgeriaAlgiers+213.21.98.9047 Argentina Buenos Aires +54.11.4341.0101 Australia Canberra +61.2.6216.0643 Melbourne +61.3.9659.4173 North Sydney +61.2.8446.5260 AustriaVienna +43.12.4030.6022 Azerbaijan Baku +994.12.437.4829 BelgiumBrussels +32.2.704.5072 Bosnia & HerzegovinaSarajevo +387.33.56.2898 Brazil Brasilia +55.613.424.0220 Rio de Janeiro +55.21.2483.6302 Sao Paulo +55.11.5508.6311 Bulgaria Sofia +359.2.937.5938 Canada Calgary+1.403.514.2435 Edmonton +1.780.441.3715 Halifax+1.902.474.0214 Kanata +1.613.254.0005 Markham+1.905.470.4810 Montreal +1.514.847.6875 Ottawa +1.613.788.7250 Quebec +1.418.634.5645 Regina +1.306.566.6410 Toronto+1.416.306.7230 Vancouver +1.604.647.2350 Winnipeg +1.204.336.6610 Chile Santiago +56.2.431.4936 China Beijing+86.10.8515.5666 Chengdu+86.28.8696.1333 Guangzhou +86.20.8519. Shanghai +86.21.2302.4333 Colombia Bogota +57.1.325.6065 Costa Rica San Jose +506.201.3617 CroatiaZagreb +385.1.462.8908 Czech Republic Prague +420.22.143.5100 DenmarkAabyhoj+45.8.939.7131 Copenhagen +45.3.958.5010 Dominican Republic Santo Domingo +45.8.939.7131 Egypt Cairo +20.22.488.5377 EstoniaTallinn+372.6.67.5998 FinlandEspoo +358.204.70.6227 France Paris +33.15.804.3116 GermanyEschborn +49.619.6773.9002 Hallbergmoos +49.811.554.3016 Greece Athens +30.210.638.1303 Hong Kong Hong Kong +852.3406.1000 HungaryBudapest +36.1.225.4621 India Bangalore +91.80.4103.3979 Chennai +1.800.102.3979 Mumbai IL & FS +91.22.4043.4030 New Delhi +91.11.4261.1088 Indonesia Jakarta+62.21.7854.7476 IrelandDublin +353.1.819.2717 Israel Netanya+972.9.892.7026 Italy Milan +39.039.629.5068 Rome +39.06.5164.4006 Japan Tokyo Akasaka +81.3.5763.9394 +0120.312271 Kazakhstan Almaty +7.327.244.2198 Korea Seoul Asem +82.2.3429.8102 LatviaPlease see Finland Number LebanonBeirut +961.1.97.7011 Malaysia Kuala Lump
Re: [ietf-dkim] Seriously.
Dave says... 1. Multiple From addresses are in the RFC2822 standard, folks. The capability was defined in RFC 733 (1977) and has been retained in every iteration up to the current RFC2822 revision work. That means that it has gone through repeated review by the email standards community. Why in the world would it be appropriate for the DKIM working group to debate its legitimacy? 2. While it is certainly useful to prune obsolete constructs, it is dangerous to assume that what a particular segment of the community is familiar with is all that ought to be allowed. Email is a very general-purpose tool for human communications. Human communications is a very, very rich space. Just because on or another person -- or lots of them -- do not use a feature does not mean its use can be ignored or denied. Yeah. I'm speaking here not as DKIM working group chair, nor as DKIM working group participant, but as a member of the IAB: in that capacity, I would look VERY skeptically at any attempt to say that DKIM doesn't have to support something that's in the RFC2822 standard, on the basis that either (1) "no one uses it" or (2) "it doesn't interoperate well in the first place". I'm sympathetic to the idea that we'd like not to spend a lot of time on an aspect that's pretty much never going to show up... on a "corner case". But saying that we can ignore that aspect is just not on. I would hope that Lisa or Chris, or both, would send up a DISCUSS if that happened. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Draft summary for IETF 71 DKIM meeting
> One thing that occurred to me after the meeting is that we didn't talk > about when last call for asp should be. Last call is usually a good > forcing function, especially since there's usually a lull after the > meeting. Aren't we pretty close to being there if not there already? Stephen and I specifically didn't want to set a date for last call yet. We'd like to get those last five (or so) issues resolved first. If discussion of those seems torpid, we'll propose leaving the document as is and going into WGLC on it. Let's see what happens. Yes, we're pretty close. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue 1550 - the name of the document (remains open *briefly*); there's still,disagreement on "Author"
> There was supposed to be a poll, can we please start > that now ? Or roll a dice for ASP, ADSP, SPAD. You'll recall, perhaps, that Stephen said we'd discuss it until the 19th (that's tomorrow), and then take a poll. So far, from the discussion, I see overwhelming support for "ADSP" (and I'm s sad that you folks didn't eat up my "FroDo" idea (which DC and I both claim, so we can have a pub fight in Dublin about that)). To Mike Thomas's concern: I'm sympathetic to the desire not to "keep" changing it, and I note that the proposal is that if we decide to change it, it will be the last change. We should consider, in our last day before the poll, whether to de-couple the DNS name from the document name. Perhaps a final change of the DNS name to, say, _SigningPractice would be suitable, and that would insulate us from any changes to the document. During the discussion of Mike's concern, there were a few messages that were unnecessarily combative (on both sides of the discussion). It's my declaration that that has stopped now. It's my hope that that won't happen again. I don't have time to watch this mailing list on a minute-to-minute basis, but I will get back to you if I see that sort of thing cropping up again. We remain polite and respectful here. We WILL start pursuing process-related remedies if things get nasty. Please do remain respectful -- we all have a lot of work to do, and we all get a bit chafed sometimes. Poll starts tomorrow. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue 1535 - clarify need for domain existence check in the decision tree (step 2)
6 days with no follow-up, so Jim Fenton said the following: > Steve, thank you for refreshing my memory on this. I would state it a > little differently now since SSP doesn't really have a "comply", that an > unsigned message from the domain bar.baz.ebay.com will be considered to > have an "Unknown" ASP unless... > > So yes, it is important that we keep this. Dave, does this satisfy you? Does anyone else have an issue with retaining step 2? I'm looking for consensus to close issue 1535 and leave the spec as it is, with step 2 in there Barry (as WG chair) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] OT: Conference on Email and Anti-Spam final call for papers
The 2008 Conference on Email and Anti-Spam submission deadline is approaching, and has been extended by a week, to 10 April. If you have any work to report on in the area of Internet messaging abuse and its prevention — not limited to email spam; see the topic list in the CfP, below — please form it into a paper by next week, and submit it. Barry -- THE FIFTH CONFERENCE ON EMAIL AND ANTI-SPAM (CEAS 2008) Thursday August 21 and Friday August 22, 2008 Microsoft Research Silicon Valley Mountain View, California <http://www.ceas.cc> FINAL CALL FOR PAPERS The Conference on Email and Anti-Spam (CEAS) invites the submission of papers for its fifth meeting. Papers are invited on all aspects of electronic communication including email, instant messaging, text messaging, and voice over internet protocol (VoIP). Topics of interest include novel applications of electronic messaging, abatement of abuses of electronic messaging, spam, spit (spam over internet telephony), spim (spam over instant messenger), phishing, identity theft via messaging, viruses, and spyware. Paper submissions can be either research papers, extended abstracts, industry reports, or law and policy papers. Submissions from practitioners and vendors are encouraged. Papers will be selected by peer review for presentation at CEAS 2008. Papers will be reviewed based on their contribution to the literature. SUGGESTED TOPICS: * Message filtering, blocking, authentication - Machine learning - Natural language processing - Adversarial learning - Challenge-response - Payment schemes - Disposable addresses - Messaging protocols - Digital signatures * Evaluation - Corpus and benchmark creation - Measures and methodologies - Comparative tests of methods or products * Analysis - Economics of spam, spit, spim, phishing, etc. - Abuse tactics and patterns - Legitimate use patterns - Historical data * Message organization and search - Advanced calendaring and scheduling - Automatic foldering - Automatic routing - Summarization - Search * Systems and network issues - Performance & scalability - Reliability & security - Archival & retrieval * User issues - User interfaces - Usability studies - Messaging in support of user activities * Social issues - Deducing social networks - Costs and benefits of messaging use and abuse - Other social impacts * Industry - Cooperation for stopping abuse - Messaging and abuse reporting standards - Interoperability * Legal issues - Spam, spit, spim and phishing, etc. - Identity theft - Privacy - Freedom of speech - Digital rights management KEY DATES: * Submission deadline: April 10, 2008 (10:59pm UTC) -- EXTENDED DATE * Notification of acceptance: June 6, 2008. * Final camera-ready version of papers: June 21, 2008 * Conference: August 21 and 22, 2008 REQUIREMENTS: Papers may be of one of two types: * Extended abstracts (up to 2 pages) may outline work in progress, exceptional papers published for different scientific communities, original research, or industry reports. * Full papers (up to 10 pages). Work may not have been previously published in, or under consideration for publication in any other conference or journal. Submissions must use the CEAS electronic system at: https://cmt.research.microsoft.com/CEAS2008/. The style for submissions and final papers is a two-column, 8.5 by 11 inch format. See http://www.ceas.cc/2008/format.htm for details. Papers will be reviewed by a committee of experts from academic and industrial research centers. Accepted papers will be made freely available on the web, and will be published on CD-ROM. Authors will retain copyright of their work. CONTACT: * The conference chair and co-chairs can be reached at [EMAIL PROTECTED] CEAS PRESIDENT * Gordon Cormack University of Waterloo http://plg.uwaterloo.ca/~gvcormac/ GENERAL CONFERENCE CHAIR: * Aleksander Kolcz Microsoft Live Labs http://ir.iit.edu/~alek/ PROGRAM CO-CHAIRS: * Andrej Bratko Jozef Stefan Institute http://ai.ijs.si/andrej/ * Barry Leiba IBM Research http://www.research.ibm.com/people/l/leiba/ * Tobias Scheffer Max Planck Institute for Computer Science http://www.mpi-inf.mpg.de/~scheffer/ -- ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Eliot Lear said the following: > By my recollection, > this topic alone has been discussed at at least two - and possibly three > - working group meetings. Please advise. This topic has definitely been discussed a number of times. And Stephen and I have discussed Dave's note from today, and think it's appropriate to continue the discussion a bit. We need to keep it focused and come to a clear conclusion -- the problem is that we don't think we really have agreement on this question. The particular point in Dave's note that troubles me, and that I don't think we have agreement on, is his third one: > 3. At least one of the sub-tree mechanisms is attempting to glean > information > from the absence of publisher action. Let me explain: ... >> c) Checking for the presence of an A record is intended to try tell >> you >> something in the absence of an explicit action by the domain owner. That's >> it's >> flaw: It is intuiting ADSP information from non-ADSP action. >> >> While there is nothing wrong with checking the A record, it's semantics >> have literally nothing (directly) to do with ADSP. I agree with that assessment, but more importantly, I think the working group doesn't yet agree on whether he's right or not. So let's clear this up with a focused discussion that gets one of the following results: * We have consensus that ADSP should explicitly say that in the absence of an ADSP record you have no information, and you treat the message as you did before DKIM/ADSP existed. Any other processing might be proposed as an extension, in another document. * We have consensus that there IS a well-defined process that we recommend following in the absence of an ADSP record, and that having the ADSP document define this is within scope for the base document. Yes, this discussion is in scope for now. Let's keep the discussion on track, and resolve this quickly. Barry, as DKIM working group chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] OT: Conference on Email and AntiSpam is next week
The Conference on Email and AntiSpam should be of interest to most of the people following the DKIM work (indeed, we had a paper about DKIM in last year's conference). This year's conference is next Thursday and Friday, 21 and 22 August 2008. We'll see invited talks by Lois Grisman, of the U.S. Federal Trade Commission's Bureau of Consumer Protection, and by Brad Taylor, Google's "Spam Czar". We'll see presentations of 23 papers about anti-spam research and operation. And we'll see posters from participants in the conference's Spam Filtering Challenge. There'll be plenty of opportunity to talk with people and share ideas. For details, see the conference's web site: http://www.ceas.cc/ I hope to see some of you in Mountain View Barry, for the CEAS 2008 Conference Chairs -- Alek Kolcz -- Andrej Bratko -- Barry Leiba -- Tobias Scheffer ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] NO DKIM "POLICY"
>> By design, a broken signature is equivalent to no signature. > > Yeah, that RFC 4871 anomaly "Failure Promotion to no signature" always > did baffled me. If either one were "better", attackers would just shift to the better one. It's simple enough to use no signature at all, if no signature is better than a broken one. Similarly, it's easy to fake a signature if that way be better. Making the cases equivalent means we don't have to try to deal with convoluted heuristics that will only be attacked anyway. But that's really a digression; please, let's not clutter the discussion with that issue again. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Change of mailing address
IBM Research has eliminated almost 200 positions, including mine, and this Thursday (26 Feb) will be my last day with IBM, after almost 32 years. I'm now looking for the next stage in my life (and any help with that will be appreciated). So, effective immediately, please discard any IBM email addresses you have for me, and exclusively use . I'll also remind everyone that if you're sending mail to the working group chairs, you can and should use the generic alias for us, (and that works for any working group, substituting the working group's name, obviously). Barry -- Barry Leiba (barryle...@computer.org) http://staringatemptypages.blogspot.com/ http://internetmessagingtechnology.org/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Handling the errata after the consensus call
> If we were to come out with a 4871bis *without* also attempting to move > it forward on the standards track, then I agree that we'd be sending a > bad message to the industry. But I don't think doing a bis without > concurrent advancement is being seriously considered -- I'm certainly > advocating moving it to Draft Standard. In other words, Tony, you're advocating option 1: put the "errata" out as an RFC that only makes updates, and reserve the 4871 replacement for an attempt to go to Draft Standard. Option 2 is the one you aren't considering seriously. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
