Re: [ietf-dkim] detecting header mutations after signing
On 10/19/2010 1:33 PM, John R. Levine wrote: Re Security Considerations, it's better than nothing, Not necessarily. The current issue is part of a much larger one. We will not be dealing with that larger set of security details because it is out of scope. Dealing with a narrow piece of it, in a very narrow specification, gives the patina of dealing with something, without the substance. So it establishes a false sense of resolving a security issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/18/2010 3:31 AM, Ian Eiloart wrote: --On 15 October 2010 11:53:51 -0400 Dave CROCKERd...@dcrocker.net wrote: On 10/15/2010 11:40 AM, Mark Delany wrote: Well, if you want to introduce semantic changes why not just change the meaning of h=from:to: to be semantically identical to h=from:from:to:to: This would mean that it is /never/ ok to add a listed header field after signing. Adding would /always/ break the signature. I assumed that the proposal applied only to headers rfc5322 says cannot be duplicated. That is a constraint that was not stated. Specifications do not allow assuming. As offered, the modification would have the effect that I stated and /not/ the one you state. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
Well, if you want to introduce semantic changes why not just change the meaning of h=from:to: to be semantically identical to h=from:from:to:to: ... I assumed that the proposal applied only to headers rfc5322 says cannot be duplicated. That is a constraint that was not stated. It is now. This probably requires a substantive change to the specification. I'm not clear whether it would force the spec to re-cycle at Proposed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] How MUAs render mail
On 10/18/2010 11:01 AM, Wietse Venema wrote: Does DKIM control text-to-voice conversion, ... Obviously these two are among the more lossy transformations. But even text-to-screen conversion, ... Folks, This is all slightly surreal. There is a premise that is motivating the proponents of giving instructions to MUA designers about DKIM outcomes. The premise is that providing DKIM information will be useful, and possibly that providing /more/ DKIM information will be more useful. (There is also some unfortunate vagueness about the actual meaning of some of this information.) This has nothing to do with layer violations, architectural purity or even the intractability of gaining change to MUAs. It has to do with the cognitive models employed for MUA design. The premise is wrong. Or rather, the premise is naive and probably wrong. The premise is based on a model of typical users that has nothing to do with /actual/ typical users. Folks making assertions about what MUAs should do need to gain some background in UXE and usability design, starting with cognitive models for UIs. They should pay particular attention to the repeated observation that users understand little of what they see from the system and care about understanding it little. (This observation is not specific to MUAs or even computer interface design. The design of control environments often is more a task of /reducing/ information than of increasing it, due to limitations of human processing, especially in real time.) This working group can, at best, recite a list of information that is available to MUAs. The instant this group starts to make normative statements about the use of that information, it is entering into territory about which it lacks sufficient expertise. Moving from the slightly cautious probably wrong above, I'll revert to the sentence before it, concerning the idea that marking validated versus invalidated information will somehow be useful for typical users. It's simply and plainly wrong. As a small example of how peculiar the current line of advocacy is, I'll suggest a simple example: Alice sends Bob a message. Alice diligently signs all the right header fields and all of the body. Bob's MUA is sophisticated and up to date, so it displays the message with this extra information about the validity of the message. What is the actual value of this marking, given that Alice is really a spammer? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] sophistry is bad, was Data integrity claims
On 10/16/2010 10:26 AM, John R. Levine wrote: Yes, it ties an identifier to a bag of bits, and yes it specifies what those bits are, but it really does deal only with those bits and not (necessarily) the entire message. Technically. you are correct. Semantically, that's silly. We went through backflips trying to figure out how to design the signatures so that the message modifications they allowed would preserve the same message, for an ill defined but I think well understood version of the same. Yes that was the goal. No that was not the result. Which header fields are essential to protect? How much of the message body is essential to protect? The current DKIM spec does not answer these questions and easily permits protecting very little of the message. Almost certainly too little to ensure the protection you assert. That's an example of what I mean when I says that there are assumptions about DKIM that go beyond what it (always) delivers. I guess I should thank you for demonstrating my point. While it's always been possible to sign messages in ways that allow gross changes, e.g. don't sign the subject or MIME headers, set l=0, if you sign a message using a normal set of options, the idea was always that the message the recipient saw would be the one you signed. Throwing up our hands at the double header trick is, one might say, ahistoric. Claiming it's an MUA problem is simply wrong. 1. Your first sentence concedes my basic point 2. There is no commonly-agreed upon and documented concept of normal set of options that I'm aware of. What is normal for you might or might not be normal for the next person configuring DKIM. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
On 10/16/2010 1:07 PM, MH Michael Hammer (5304) wrote: This is disingenuous on your part. It is akin to saying that although the common usage of hammers is to hit nails, we must accept within the definition of normal the usage of beating people on the head with a hammer simply because some people do and it is not documented through warnings on hammers that this is not normal. There is a subset of headers that the vast majority of informed (even semi-informed) implementers would agree on. Perhaps we need to reach a consensus and document this to protect the children. Wow. From sophistry to disingenuous. Today seems to be when people think that tossing in slams at motives, legitimacy and style somehow facilitates discussion. It invites all sorts of responses in kind, none of which would be constructive. And I've tossed in this comment merely to note how irritating today's vocabulary choices are and suggest folks make more judicious choices. My postings have constructive intent and serious thought behind them. The might be wrong, but they are not naive, frivolous, poorly intentioned, or any of the other things that permit superficial dismissal. Please debate them on substance; if you've missed the substance, please show the courtesy of simply asking for clarification. In any event, it's clear that at least two of you have entirely missed my point. So let's try this again, more carefully: There is a fundamental difference between saying something bad might happen versus do this specific thing to provide this specific protection. One is a generic warning. The other is a spec. The difference is not subtle. Re-read my questions. They werequite precise. The text in the spec does not provide precise answers; when it appears to provide precise answers, they were not the result of informed thought: Which header fields are essential to protect? How much of the message body is essential to protect? Let me emphasize: Most of the advice in the spec is not useful, except as basic reminders to an already-knowledgeable reader. Useful means that someone who does not already knows the answer is able to figure out the answer from the guidance that is given or the guidance tells them how to go about finding out the answer. They can't do that with what is in the spec. I don't mean we should rip out all the advice, merely that we need to distinguish between soft advice and serious, technical specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 10:28 AM, Jeff Macdonald wrote: On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKERd...@dcrocker.net wrote: Although some folk have done a +1 for one (or another) removal, I'd like to get a round of explicit reactions to the specific idea of removing /both/. +1 Folks, The pattern is completely consistent, so I will take this as agreement to remove both. Anyone objecting very strongly needs to speak up. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/15/2010 1:32 PM, Barry Leiba wrote: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds ... Mike, you needn't object unless the chairs put people in our kill-files, and I can assure you that we don't. Folks, (First rule of politics and legal trials: if you can't win on the substance, try to win on the process.) Since this is a formal forum and we're in the middle of a formal act (making a decision) and the mailing list is a formal record, I'm feeling compelled to correct two factual errors, in spite of the potential for this taking us down the rabbit hole: 1. I don't killfile. 2. I reviewed all mailing list postings in the thread that followed my query. d/ ps. However I happen to agree with Barry's note about requirements. But an inaccurate formal record warranted correcting. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/15/2010 2:46 PM, Steve Atkins wrote: I'm not sure whether wildcard records is relevant to the spec - that's more of a development, deployment and operations issue, I think. The degree to which a processing environment is expected to be pure versus potentially noisy might well come into play during the specification phase. For example, it might be why a distinguishing label gets added. In this case, we've gone to some lengths to make the environment pure, by using the underscore branch. And then along come these pesky wildcards. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/14/2010 12:22 PM, Murray S. Kucherawy wrote: Seems OK to me. But doesn't EMAIL-ARCH talk about domain names and ADMDs and all that? Perhaps it's a better reference for this? As much as I like to tout email-arch, the citation here needs to be specifically about the DNS and, for example, not about the DNS for mail. The fact that we hadn't even thought to include such basic citations in the original work on the draft provides good insight about the reader we are adding these for... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
The DKIM public key TXT record MUST not be mixed or merged with other TXT records, i.e. SPF. In addition, make sure other TXT records with Wildcards do not conflict with DKIM public key lookups. That text adds a requirement in an informative note. THat is the least of its problems. DKIM records go into a protected subbrance, given the underscore name. RFC 4871 discusses about DNS in various sections. Unfortunately, there is no reference to the DNS specifications. we've just fixed that during the current edits. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] removing the g= definition?
On 10/14/2010 12:46 AM, Tony Hansen wrote: Another potential option is to remove g= entirely: I'd like to encourage our considering this strongly, for two reasons: 1. Pragmatic -- It's causing confusion and errors, while providing no significant value-add. 2. Theoretical -- The feature recruits receivers to enforce what really are matters of internal controls within the sender. It's one thing to recruit receivers to help deal with attacks by outsiders, but quite another to burden receivers with tasks that are within the signer's control. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/13/2010 1:52 PM, Jim Fenton wrote: I propose removing section 3.6.1.1 in its entirety. Not only do I support this, but I think we can remove all references to DomainKeys, except for the obvious historical reference to its role as input to DKIM. At the time DKIM was developed, worrying about compatibility with, and transition from, DomainKeys was essential. Now it isn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/14/2010 12:45 AM, SM wrote: RFC 4871 discusses about DNS in various sections. Unfortunately, there is no reference to the DNS specifications. OMG. As in, wow. I propose changing from: section title=Introduction tDomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. to: section title=Introduction tDomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name xref target=RFC1034 / with the message. This can be an author's organization, an operational relay or one of their agents. ... Note that the sentence is slightly modified, which is the reason I'm running this past the wg. It defers reference to signing domain until later. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last call comment: Changing the g= definition
On 10/14/2010 9:05 AM, Tony Hansen wrote: Is it still worth changing that section into a WARNING for people upgrading from DomainKeys, saying to make darn sure that they REMOVE g=; in their old DNS records because of interoperability issues? So the question becomes: if we remove the section on how DKIM and DK can play nice together, 1) do we chop out all references to DomainKeys, or 2) do we keep a short warning on what needs to be changed in the DK record to make it work with DKIM? For pragmatic guidance text that is not essential for direct implementation, I'm finding myself increasingly fond of the idea of putting such wisdom into the Deployment document... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records
On 10/14/2010 9:49 AM, Mark Delany wrote: Well, just to create a bit more of a rat-hole, is there any chance you'd like to add a definitional link for the word message as well? The easy and possibly sufficient answer is: RFC 5322. If more precision is required, then Section 3.5 of RFC 5322. Does anyone feel some other citation is necessary? Does anyone feel that the section number citation in 5322 is essential. (I only ask because adding a pure RFC citation to the opening sentence of the Introduction will be somewhat cleaner without it. section title=Introduction tDomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name xref target=RFC1034 / with the message xref target=RFC5322 /. This can be an author's organization, an operational relay or one of their agents. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] layer violations, was detecting header mutations after signing
On 10/14/2010 10:17 AM, John R. Levine wrote: I don't see anyone proposing a deep dive into 5322 validation. But 4871 already says you MUST sign the From: header. Why is that OK, but saying you MUST NOT sign or validate something with two From: headers is not? We're not suggesting anything that would invalidate existing bits on the wire, after all. DKIM is full of layer violations where it tells people how to sign and verify robustly. Protocol specifications should require all of that actions that are essential to correct operation and none of the actions that are not. A DKIM signature verifies or it doesn't. It delivers a signing domain or it doesn't. What is essential is that it perform the task of validating and delivering a signing domain that is associated with a collection of bits. Anything that defines how to do this is essential. Anything that can make this break needs to be covered, especially if there are ways to protect against the breakage. Perhaps surprisingly, having redundant header fields does not make DKIM break. And it is an issue outside of DKIM and, therefore, need not be protected against by DKIM. Also surprisingly, the same holds for more general message conformance checking. The checking does not make DKIM work, and it does not make it work better or worse. So it isn't needed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/13/2010 2:27 PM, Jeff Macdonald wrote: DKIM seems to make assurances to message integrity. But it doesn't. I think the reason why many think it does is because of the body hash. It is trying to do to much. It should just provide an identifier that can be verified. Instead of using the body for hashing, use the Message-ID header along with the Date header and just hash that. That way most folks would understand DKIM is just providing an Identifier. my goodness, but your version of ranting is far too mild and reasonable. which is not to say i agree with you about tossing out the body hash. Although DKIM is not trying to protect the message, it /is/ trying to reduce the ability to take a valid use for one message and apply it to an invalid use with another. From a mathematical standpoint, your suggestion is quite reasonable, given that message ids are supposed to be unique, etc. But the question is whether a verifying can know whether a signature is being replayed -- that is whether it is being reapplied to a different message. Verifiers do not track message ids. So they can't detect a new use. Using the body hash is a convenient hack that is likely to make it nearly impossible to apply valid use of a DKIM identifier to different content. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/13/2010 3:17 PM, John R. Levine wrote: We put a bunch of stuff in DKIM to allow benign modifications of messages, notably relaxed canoncalization. (We can argue about whether l= is useful, but it's easy enough to ignore if one thinks it isn't.) I think it's also reasonable to put stuff in to disallow malevolent modifications. Putting things in to be more robust against vagaries of travel is quite different from adding things to resist actual attack. In particular, note that nothing being discussed, here, invalidates the signature. The topics being discussed concern processing that really is outside of DKIM. Therefore its discussion is outside of DKIM. Most of the confusion is exactly the difference between DKIM as a labeling technology versus DKIM as a message protection technology. On 10/13/2010 3:30 PM, Murray S. Kucherawy wrote: I'm talking about a dual-From: message that wasn't signed at all. An MUA will still show the wrong one. So I fail to see why a DKIM specification needs to make a normative requirement about a problem that's been around since years before the acronym DKIM ever appeared anywhere. +1 On 10/13/2010 3:47 PM, Murray S. Kucherawy wrote: I'm concerned that if we name that specific check, that's all people will do and then think they're safe. Exactly! We are not tasked with dealing with the larger security issues and this is but a piece of it. Tackling only this tiny piece constitutes woefully incomplete work and it's really out of scope. DKIM simply highlights an issue that's been there for a very long time now. Actually, no. DKIM does not highlight this. What is highlighting this is security discusses that come from wanting to apply DKIM to more than it is designed for. It is the /discussions/ that highlight this, not DKIM. (I'm not playing semantics here. I'm playing scope.) Given that DKIM's core algorithms are the same as those used for message security, it's pretty easy to imagine applying DKIM to these other, larger issues, but that's a separate engineering effort. On 10/13/2010 4:09 PM, MH Michael Hammer (5304) wrote: I've said for a long time (from a phishing perspective) that if we let bad stuff (from a brand perspective) get to the enduser ... Having said that, if an MUA is going to present an indication of DKIM PASS to the enduser, ... I understand the issues raised by Murray about the slippery slope. On the other hand, I would rather see an MUA present nothing about DKIM than give a false impression to endusers. Fundamentally, everything in your note suffers from being both valid but irrelevant (to the current discussion about DKIM). It's valid and even essential, to a different, larger discussion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/13/2010 4:59 PM, Mark Delany wrote: I know we're not in the MUA business, but if DKIM makes no difference to what an end-user finally sees, then it serves a very limited purpose indeed. Well, yes. But that's a /good/ thing, as a core capability. More importantly, we are not in the MUA business because we lack the expertise, as a group. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/13/2010 8:56 PM, Mark Delany wrote: If DKIM has any value it's that it ultimately affects the user mail experience for the better. Consequently, to remain silent on matters that we know will adversely affect that experience seems contradictory. Similarly to not offer guidance to implementors on the sorts of things they can do to maximize the value of DKIM seems similarly to miss the point. Mark, First, let's be clear that no one think MUA issues are minor or irrelevant. The question is how DKIM relates to them and what should be said about the topic in the DKIM Signing specification. Everything affects the user experience. IP interpacket arrival times. TCP algorithms responding to congestion. SMTP transaction design. Every f'ing thing. But this does not mean that each of them must make comments about MUA issues. DKIM resolved a massively important problem by defining a validated name-affixing mechanism. But neither Domainkeys nor DKIM specifications demonstrate any of the human factors or usability specialties needed to make serious comments -- nevermind normative directives -- about MUA design. Nor did they need to. What you are calling for would be good to have. It should be done. Just not in the signing spec. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-rfc4871bis-02.txt
On 10/11/2010 11:46 PM, Barry Leiba wrote: Dave: There's an error in the new paragraph in section 5.3; the first sentence appears to have been fragmented. It reads thus: Similarly, a message that is not compliant with RFC5322, RFC2045 correct or interpret such content. Please post the correct version here, so reviewers have it handy, and have it ready for any subsequent update. Oh boy. Very sorry folks. The full text reads: tSimilarly, a message not compliant with RFC5322, RFC2045 and RFC2047, can be subject to attempts by intermediaries to correct or interpret such content. See the Section 8 of [SUBMISSION] for examples of changes that are commonly made. Such corrections may break DKIM signatures or have other undesirable effects. Therefore, a DKIM agent SHOULD confirm that a message is compliant with those specifications prior to processing. /t d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/12/2010 11:05 AM, Ian Eiloart wrote: No Signature, Double From --- Trapped/rejected by mipassoc.org Really? You tested this? I assumed the message was accepted because it contained a From: header belonging to a list member. Not because it was signed. You are correct. The list accepts submissions only from subscribers, as checked in the From: field. This test message failed that stricture. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
On 10/13/2010 1:02 AM, Murray S. Kucherawy wrote: The mixed use of words is a fair complaint. I think we can safely just switch one of those to the other one to make it consistent. gad. you guys have no literary sensibility at all. sigh. a shame this is a spec, which makes you guys right and the current text confusing. sigh. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-rfc4871bis-02.txt
On 10/11/2010 1:44 PM, Jim Fenton wrote: - Continue to direct comments at -01 - Comment on -02 instead - or will the WGLC be restarted on the -02 draft? Just my personal opinion: The revision is based on LC comments so far. Since ultimately the working group has to agree on the document, it's probably more efficient for further comments to be on -02. (Efficient, but not necessary, of course,) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] detecting header mutations after signing
On 10/8/2010 9:28 AM, Murray S. Kucherawy wrote: I'm still cringing at the layering violation of fixing in DKIM the fact that many RFC5322 implementations, MTAs, MSAs and MUAs alike, don't bother to enforce normative portions of that specification. Is there precedent of this being done elsewhere, i.e. compensating in one protocol for abundant lousy implementations of a layer below it? I'm a bit confused. We want to re-submit DKIM Signing to Proposed Standard, in order to fix an edge condition that is only a theoretical issue and only fixes a problem that is actually outside of the scope of what DKIM is trying to achieve? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
On 10/7/2010 1:00 PM, Murray S. Kucherawy wrote: so maybe it's best to fall back to something more generic and say a module can reject instead of naming one or the other specifically. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/7/2010 4:18 PM, SM wrote: RFC 5322 specifies a format for Internet mail. I don't see what could be changed in there as this discussion is not about an issue with the format. 5321 and 5322 are component specifications, although of course they do have /some/ systems integrative text. But their attention to implementation issues is restricted to the scope of their protocol and format work. One might wish for a broader, systems oriented document that discusses how the components fit together and explains where systems-level and end-to-end issues, such as the one being described here, might get resolved. Darn. That would probably require normative status for such a document. Hmmm. I wonder where the closes approximation might be... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
On 10/6/2010 8:23 AM, Murray S. Kucherawy wrote: Of the points I raised, I see that 4.3 still contains the verifier is requested to discard the message. It is, of course, the receiver that actually does any discarding. I don't agree, at least not in the architecture I have in mind. The verifier (e.g. a mail plugin of some kind, or an internal function of an MTA) is in a position to conduct rejections as it sits very near the SMTP portion of a delivery. The receiver, more likely an MUA or such, is less likely to have any direct influence. The verifier might legitimately not be touching the message, nevermind have the authority to discard the message. Just as signing can be done by an independent service that contracts with the author, sender or the like, so can verifying. I suggest saying the holder of the message is requested to discard it. Also, section 5.6 is still entitled Pros and Cons of Signature Removal, and yet the body of that section contains no Cons. The first paragraph describes a pro of leaving them in (i.e., enabling preservation of chain of responsibility), and the second describes a con (i.e., if that's a goal, now the MLM might have to change its behavior to do so). The next paragraph describes a pro of removing them, etc. I'm not a huge fan of having pro con in a title. Perhaps simply: Signature Removal Issues. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/6/2010 8:00 AM, Steve Atkins wrote: It also changes what DKIM means, ... Either the message has a valid DKIM signature, or it does not. If the signature is valid, then the signing domain takes responsibility for the message, subtly malformed or not. Just because the message lacks a Date: header or has bare linefeeds doesn't mean that the signing domain isn't responsible for it. THis is a particularly clean and precise attention to DKIM's job, nicely filtering out issues that are not part of DKIM's job. In particular, it makes the multiple From: issue entirely irrelevant to DKIM. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 10/6/2010 9:17 AM, John R. Levine wrote: Is it DKIM's job to make the verification fail, or is it an MUA's job to do something reasonable with malformed messages? At one level, that's merely an implementation choice. At another level, it is a question of whether conformance enforcement MUST occur at all. The discussions have tended to assume that it MUST occur, by virtue of the DKIM requirement for 'conformant' messages. Steve's point cleverly suggests that DKIM itself can dodge the issue by -- once again -- having things simply rest on verification outcome. I find the simplicity and sufficiency of Steve's point pretty darn appealing. To emphasize: It's sufficient because it focuses on DKIM's actual goal and does not expand that scope. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
On 10/5/2010 8:15 AM, Ian Eiloart wrote: It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to display the signed header? Are there really MUA's that will display the unsigned headers*and* assert that it was validated? If so, that's surely a bug in the implementation of the MUA. Your comments underscore the importance of being careful about what we expect from DKIM. As you note, if software is DKIM-aware, it also needs to be DKIM-intelligent. At a deeper level, there is a continuing problem with casting DKIM as a mechanism to protect a message. That's something that OpenPGP and S/Mime do; it's not something DKIM does. DKIM merely tries to do enough to ensure that the d= is valid, to provide a basis for reputation assessment. Hence, I recommend that this ISSUE be declined and closed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
PS: Note that I'm saying nothing about whether or not this issue should be mentioned in 4871bis. FWIW: Adding to a specification, by trying to protect against behavior that is already illegal is wasteful, redundant and opens the door to an infinite path of similarly unnecessary provisions. Plainly bad specification methodology. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01
On 10/2/2010 5:58 AM, Stephen Farrell wrote: On 01/10/10 18:28, Dave CROCKER wrote: I think the text should therefore be revised from: 1.1. Signing Identity ... INFORMATIVE RATIONALE: The signing identity specified by a DKIM signature is not required to match an address in any particular header field because of the broad methods of interpretation by recipient mail systems, including MUAs. ... to be: 1.1. Signing Identity ... The signing identity specified by a DKIM signature is entirely independent of the identities present in any particular header field. The interpretation of s/identities/identifiers/ above? Well, I did have a similar thought, when writing the proposed change, but that's a more substantial change, since it moves from saying entity to saying reference to the entity. The usage later in the sentence needs to match earlier in the sentence where it says signing identity, which is the term being defined in that subsection. How about: 1.1. Signing Identity ... The signing identity specified by a DKIM signature is entirely independent of the identities referenced in any particular header field. The interpretation of... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Updated implementation report
On 9/29/2010 4:09 PM, MH Michael Hammer (5304) wrote: This isn't particularly surprising to me. I've always believed there is a significantly higher value for 1st party signing compared to 3rd party. The value proposition has always seemed to be much more compelling to me. You automatically jump to the conclusion that a dominance in a statistic means higher importance. There are far more people who are in the average range of intelligence than there are who have an IQ over 140. Are the people with higher IQs less important? In an average audience of 100, I usually found that roughly 3 people had had their house broken into. Since breakins are so rare, does this mean that locking your door really isn't necessary? (The other side of that question is that burglars seem to be able to get into a house if they wish, and does this mean that locking your door really isn't effective?) The nature of statistical analysis inherently constraints their actual meaning. Let's be careful not to go outside those constraints. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01
On 9/30/2010 8:04 PM, Mark Delany wrote: Thanks very much for writing this up, Murray. Very enlightening. And that Alt-N - a relatively small company - hosted an event for the big guys at their expense speaks volumes about the commitment of Arvel and his crew. We are in their debt. +1 And to add to the feel-good moment, I'll note that a relatively obscure technical effort like DKIM would normally be expected to get a very small number of organizations at a first interoperability event. My expectations at the time were that 5 would be a success and 10 would have been a home run. We had 20. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Updated implementation report
On 10/1/2010 9:58 AM, MH Michael Hammer (5304) wrote: You misinterpret what I wrote (or perhaps I wasn't clear enough) or intended to write. Well, I do tend to overinterpret single data points... What I was trying to communicate is that the value proposition for DKIM signing appears (At least to me) stronger for the owner/administrator of a given domain than it would be for a given 3rd party. And my point is that the this set of data don't provide a basis for making such a fundamental assertion. I'm not saying your opinion is wrong -- although I do think it is misguided -- but rather than this data on their own don't substantiate that assessment. There are too many other possible explanations for this data. (As for misguided, I think that it is a mistake to discuss DKIM 'value' in terms of author-vs-non-author, since DKIM is not designed to make assertions about authorship. It is design to enable making assertions about handlers of email and it is designed to make them differentially for different streams.) As far as your example of intelligence, your question regarding importance is incomplete. Important to whom and in what context? Exactly. Please re-apply this point to the current topic... Note, I didn't say that 3rd party signing was less important generally. What I wrote (or intended to write) was that my belief is that 1st party signing represents a higher value proposition to 1st party signers than 3rd party signing represents to 3rd party signers. Oh. Sorry. I didn't get that. It's an interesting idea but I'd want to hear it explored quite a lot, since the idea of value is pretty broad. For example, if 3rd party signatures allow an ESP to get mail delivered better and, therefore, to stay in business, I'd be hard-pressed to call DKIM's 'value' lower than for a first-party signer. Most of the 1st party signers I have spoken with are more focused on abuse issues. Well, it's certainly true that first party signers have an easier opportunity to conflate goals. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-rfc4871bis-01.txt
On 9/27/2010 8:15 PM, John R. Levine wrote: In the informative note at the end of sec 3.1, suggest untangling the last two sentences to : For this reason signers SHOULD NOT reuse selectors with new keys, and SHOULD assign a new selector to each new signing key. In other words, you want the Informative note to become Normative. Does the additional normative language make the protocol work better or add a protocol feature? I tend to expect one of those benefits from normative text. We need to be careful to limit the use of normative language to assertions that really make the protocol work. Does this really rise to that level? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01
On 10/1/2010 10:15 AM, Murray S. Kucherawy wrote: The spec simply states that DKIM doesn't require any binding at all. (Section 1.1) It occurs to me that this language permits a misinterpretation and that stronger and more direct language would be appropriate. By saying is not required to match, the current spec leaves open the possibility that the presence of a match might be taken to be meaningful by DKIM. However the reality is that DKIM is literally blind to the relationship between a d= domain and a domain name in any other field. I think the text should therefore be revised from: 1.1. Signing Identity ... INFORMATIVE RATIONALE: The signing identity specified by a DKIM signature is not required to match an address in any particular header field because of the broad methods of interpretation by recipient mail systems, including MUAs. (hmm. the use of the term 'address' is probably also inappropriate since it means email address in the email world, rather than domain name address.) to be: 1.1. Signing Identity ... The signing identity specified by a DKIM signature is entirely independent of the identities present in any particular header field. The interpretation of a match that is possible between the signing identity and the identifier in another field is outside the scope of DKIM. (I've removed the Informative Rationale label because the proposed text really moves into explanation of the protocol, rather than explanation of its motivation or the like.) d/ ps. just so no one is confused: this does not change the protocol at all; it merely clarifies a point that is often misunderstood. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01
On 10/1/2010 10:20 AM, Murray S. Kucherawy wrote: I should've read the whole thread before replying. If consensus is to keep the statistic in, I'm fine with Jeff's proposed language. As a statistic in a software reporting tool, I think it's a fine a useful tidbit to include. As a part of the IETF implementation report for Draft Standard, I suspect it is distracting or possibly worse, since it implies that that bit of data is relevant to the protocol and its deployment. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01
On 10/1/2010 10:47 AM, Murray S. Kucherawy wrote: As a part of the IETF implementation report for Draft Standard, I suspect it is distracting or possibly worse, since it implies that that bit of data is relevant to the protocol and its deployment. I agree that's true. But on the flipside, this particular statistic pointed out that the slight text change you proposed in your previous message might be a good idea for the DS version. It might therefore actually be useful to include as justification for such an edit should anyone ask. wow. i had entirely missed that you received excellent training as an attorney. (or is this just an artifact of the high quality of Canadian education?) In other words, good point. I withdraw my suggestion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On 10/1/2010 1:27 PM, McCann Peter-A001034 wrote: The fundamental problem with the current situation is that the authenticated identity is not displayed and the displayed identity is not authenticated. Forgive my pursuing it in this fashion, but I'd class that as a first derivative, rather than fundamental. (But, then, first derivatives are important.) Fundamental is that DKIM is not trying to authenticate the message and it is not trying to authenticate any identity such as From: It is merely trying to affix a /separate/ identifier, with a claim that its being affixed is valid, but not that it relates to any other aspect of the message. In other words, it is trying to identify message streams, rather than validate messages or authors. The fact that DKIM uses underlying crypto algorithms keeps confusing people into wanting to use it the way OpenPGP or S/MIME are designed to be used. Ain't gonna work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] end-of-data vs. connect-time
On 9/13/2010 11:58 AM, Murray S. Kucherawy wrote: people believe the cost incurred by switching to end-of-DATA filtering vs. connect-time filtering is a lot larger than I believe. And they [claim to] have the data to support that position from large customers,... This issue keeps popping up. We need to find a way to get some solid data published about the costs and tradeoffs. I wonder whether this is a task best pursued in MAAWG? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
On 9/13/2010 7:19 AM, MH Michael Hammer (5304) wrote: If a domain publishing ADSP discardable has not gotten control of their mailstreams then all I can say is Darwin was right. I agree with you completely. The problem is that customers of a receiving ISP often do /not/ agree with you. When their ISP discards mail the customer wanted, the explanation well, it's what the author told me to do typically does not work. And since the customer's contact is with the receiving ISP, it is the receiving ISP that must alter their activity. Since discarding got them in trouble, they will, at best, start discarding much more selectively. Selectively means using information beyond ADSP. Given sufficient selectivity, the mechanism that defines selective will contain enough information to make ADSP redundant. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs
On 9/27/2010 11:04 AM, Murray S. Kucherawy wrote: From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of John R. Levine ... It is not my impression that they all do the full DKIM validation while the SMTP session is open. Mine doesn't. The milter-based ones like OpenDKIM and dkim-milter do. It's been a significant revelation, for me, to realize how common it is for DKIM processing to occur during the SMTP session. So SMTP issues reduce to finding ways of preventing the cross-net transfer of data or even of preventing the SMTP session. Oddly, I think the latter is more feasible than the former. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Discussion lists and broadcast lists are not the same thing
On 9/24/2010 7:52 AM, Jeff Macdonald wrote: It may be productive if we distinguish between two-way discussion lists where participants send mail to the list, and one-way broadcast lists where only the owner (or their agent) sends mail to the list. The difference between these is to be large enough that the concepts do not generalize that well. Since I work for an ESP, I agree with this statement. In terms of the vocabulary used in the Email Architecture document[1], these two services are completely different. An MLM really is a mailing list [2]. A bulk, one-way sending service is an entirely different kind of entity and service.[3] d/ [1] http://bbiw.net/specifications/rfc5598-email-arch.html#Mediator [2] http://bbiw.net/specifications/rfc5598-email-arch.html#rfc.section.5.3 [3] http://bbiw.net/specifications/rfc5598-email-arch.html#service-mua: One example is a bulk sending service... These services are not to be confused with a Mailing List Mediator, since there is no incoming message triggering the activity of the automated service. (This mode probably should get its own name and should be documented up in the Mediator text, rather than be buried in the MUA text. /d) -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis
Jeff, Thanks... On 9/22/2010 12:18 PM, Jeff Macdonald wrote: Section 3.9: INFORMATIVE DISCUSSION: This document does not require the value of the SDID or AUID to match the identifier in any other message header field. should the identifier be an identifier? pretty subtle, but yeah, more precise/accurate. I cringed at SDID and AUID, but I don't have any better suggestions at the moment. Reviewing the flow of the document, I suggest moving section 2.7-2.11 to be after section 2.2. well, that's a pretty thoughtful suggestion... To make sure I understand the intent: move the set of subsections that introduce higher-level constructs, to come before the sub-sections that define syntactic elements? Sounds like an improvement to me. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis
On 9/23/2010 4:07 PM, John Levine wrote: Seems unanimous. Dave, do you have enough changes to do another version? I was planning on waiting a couple of (work) days. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing list reality check
On 9/19/2010 8:47 PM, John R. Levine wrote: I think these all should be non-controversial. Let me know if I'm mistaken. 1. The overall amount of mail sent through discussion lists is small relative to direct (person-to-person) mail or to broadcast (one-to-many) mail. That depends on the person. In any event, how is the proportion of personal-to-group mail relevant to any topic of the working group? 2. Lists do a good enough job of managing the mail that they forward that recipients generally do not worry about spam filtering mail from lists to which they've subscribed. (Bozo filtering of legit but stupid messages doesn't count as spam filtering.) do not worry...they've subscribed - have not produced a broad requirement for enhanced list performance of spam filtering. 3. The most common way for spam to get into a list in recent years is for a subscriber's account to be stolen by a spammer who sends spam to addresses in the account's address book. I've no idea what the substantiation for this assertion. It well might be true, but I'm not seeing how it is relevant to any topic of the working group. (There is also likely to be a huge difference between lists that restrict posting rights and those that don't.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing list reality check
On 9/20/2010 7:33 AM, John R. Levine wrote: do not worry...they've subscribed - have not produced a broad requirement for enhanced list performance of spam filtering. Sorry, I don't understand what that phrase is supposed to mean. Enhanced how? Better than is generally being done now. 3. The most common way for spam to get into a list in recent years is for a subscriber's account to be stolen by a spammer who sends spam to addresses in the account's address book. I've no idea what the substantiation for this assertion. It well might be true, but I'm not seeing how it is relevant to any topic of the working group. I'm describing what I've seen on the lists I manage and the lists I subscribe to. Lousy sampling methodology. And getting folks on this to agree with something based on the methodology has nothing to do with providing serious substantiation. It may not be statistically significant, but it's what I've got. You are confusing data with information. It's pretending that one person's experience is meaningful for making generalizations. It isn't. Ever. If spam comes from subscribers rather than from bad guys trying to impersonate them, there's no benefit from extra mechanism to keep out the nonexistent impersonators. ack. (There is also likely to be a huge difference between lists that restrict posting rights and those that don't.) Well, there's another reality check: 4. Most (nearly all?) lists restrict posting to addresses known to the list software, such as list subscribers. Mail from other addresses is typically either rejected or sent for manual handling by the list manager. Again, you are offering a reasonable hypothesis in the form of an unsubstantiated conclusion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Who signs what
On 9/16/2010 7:31 AM, MH Michael Hammer (5304) wrote: People should be free to use/sell 3rd party signing but that is outside the scope of DKIM/ADSP by intent. This is a technical group, writing technical specifications. So we need to be extremely careful in being accurate in how we describe things. By its definition, ADSP targets the author's domain (in the From: field.) This means that ADSP cannot be used for other domains. However DKIM says nothing about any other field, author or otherwise. It is equally happy with 1st-, 2nd-, 3rd-, and nth- party signatures. And /that/ really is by intent. (It always was the major enhancement of DKIM over Domainkeys.) ADSP is not DKIM. It relies on it, but it goes far beyond it. DKIM does not require or expect ADSP. You said DKIM/ADSP. The implication is that the constraint you cited is relevant to DKIM. But it isn't. It's relevant (and in fact essential) only to ADSP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Who signs what
On 9/16/2010 8:31 AM, MH Michael Hammer (5304) wrote: You are absolutely correct Dave. My intent was to communicate the combination of DKIM and ADSP (or ADSP layered on top of DKIM if you will). Right. And I was pretty sure that was your intent. (In fact I singled our your note because I was confident that it would be possible to keep the focus on the terminology usage and not worry about mixing it with a misunderstanding of the distinction between DKIM and ADSP...) The problem is that there is a general perception that DKIM cares about the type of the signature. Linking DKIM directly to a discussion about the 'party' of the signature reinforces that misunderstanding. As many of you know, I've recently added a little audience-participation test to my presentations about DKIM. Almost everyone who answers the question What does DKIM do says that it is about verifying the author or the sender. Formally, it does neither. I strongly suggest that when someone is talking about ADSP, they need to say ADSP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Who signs what
On 9/16/2010 8:32 AM, Jeff Macdonald wrote: On Thu, Sep 16, 2010 at 10:31 AM, MH Michael Hammer (5304)mham...@ag.com There was a (hard won) consensus that a signature by the owner/admin of a domain carries more weight than the signature of a 3rd party because the owner/admin of the domain controls the domain and the 3rd party doesn't. I don't think there is a consensus on what a 3rd party signature is. ADSP has a definition that is, I think, pretty clear. The problem is that that definition does not synchronize with many people's expectations of the term, and especially its usage in other circumstances. We could, I suppose, write an ADSP erratum that redefines its usage. I've no idea whether that would be worth the effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis
John, et al, On 8/20/2010 10:31 AM, John Levine wrote: I went through it. It's a very thorough piece of work. So far I only have two comments. I haven't seen any other postings since John's almost a month ago. It would be nice to make progress on this revision, since this ought to be an easy milestone for the working group to meet. * Does anyone else have comments on the draft??? * Section 3.5, near the bottom of page 23: Local- part MAY be drawn from a namespace that does not contain the user's mailbox I'd suggest changing that to Local- part MAY be drawn from a namespace unrelated to any mailbox. Sounds reasonable to me. The document never says who the user is, and I see no advantage to language that implies that there is one. I've scanned through the doc. The word 'user' appears in a variety of contexts, including formal labels that were approved by the working group. Some of the uses define their meaning adequately, IMO, and some could perhaps be a bit more clear. Where the document mean author I suggest it say author. Where the document means end user who is causing a signature to be created it should probably say something like that. I'm not sure what other clarifications make sense, but it doesn't look as if we should try to avoid the word entirely. Section 7: Should this section reiterate all of the stuff in 4871, or since the IANA registry already exists, just say what if anything is different since 4871? I don't know which is better. http://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml I believe there was going to be some background research on this, but the more I've thought about it, the more I believe that the new document should make no reference to the original document, except perhaps as a historical reference. So, IMO, anything the original document defines -- including registries -- should be (re-)defined in the bis verison. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] party list it's whatever
On 9/15/2010 12:32 PM, John Levine wrote: S/MIME has 2nd party signatures, where you encrypt something using the recipient's public key. ADSP has no equivalent. Signatures means authentication. authentication uses the sending-side private key. Receive-side public keys are used for privacy, not authentication. Here's where you get to supply the point that a) defines 2nd party sig for s/mime, and b) makes clear that I'm wrong... As of now, I've no idea what your statement about S/MIME means. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis
On 9/15/2010 1:00 PM, John R. Levine wrote: Has anyone asked IANA which they prefer? This situation, a new RFC replacing the one that defined a registry, surely has come up before. Well, yeah, that was in the pipeline, but your question prompted me to see if it could be resolved trivially, and indeed... http://www.iana.org/protocols/ SMTP Service Extensions RFC 5321 The current registry definition entry has the latest defining draft, not the original. We of course should do the same. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] An implementation of transitive trust
On 9/15/2010 1:20 PM, John R. Levine wrote: It describes the the implementation of certified electronic mail in use in Italy, where certified e-mail is legally equivalent to certified paper mail. FWIW, here's the review I did of that draft: http://www.ietf.org/mail-archive/web/apps-review/current/msg00286.html d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-02 review
Yes, but nobody is trying to change that. We seem to be agreed that what a mailing list sends is, from some POV, a new message, and so logically a new From: is not wholly out of order. What's the benefit to this, though, other than obscuring the original author? If the mailing list system is, really, merely re-posting a message, with only minor annotations, so that the core semantic of the mechanism is address fan-out, then the message is, really, from the original author, and not from the list. If the mailing list system is, really, taking the original message and doing substantial massaging/creating of content, then the message is, really from the mailing list system and not the original author. In the latter case, it makes sense to have a different From: field. Daily digests are an example of this. Note that the decision is ultimately subjective and it pertains to expectations at the human level. It's not simply a mechanical issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposed changes to MLM draft
On 8/30/2010 11:03 AM, Murray S. Kucherawy wrote: I’d like some help tackling the next version of the MLM draft. People seem to have varying ideas about what should be removed and perhaps appear in other documents now. I need some consensus on a direction in which to proceed. So can I please get some +1s/-1s on each of the following: (1) Split the document into three documents: A DKIM MLM BCP that discusses signing and verifying in the context of MLMs with no value-add items addressed, a DKIM MLM Informational that discusses possible value-add enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing lists irrespective of DKIM (Dave’s proposal); +1 I'd suggest that the second item actually be a normative specification of value-added features. This requires a change to the charter, and so it would have to wait until completing the current charter. If you advocate for a general MLM BCP, this will be a non-WG document (it’s outside of our charter) so I’d love to get some MLM operators and developers involved. (Maybe this should take place on ietf-822 or maybe on a new non-WG list; suggestions welcome.) Expressions of interest in that work would be appreciated. I’ll approach the APPS ADs about a venue. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposed changes to MLM draft
On 8/30/2010 11:42 AM, Murray S. Kucherawy wrote: I'd suggest that the second item actually be a normative specification of value-added features. This requires a change to the charter, and so it would have to wait until completing the current charter. If it's a minor charter tweak, maybe we could start that process before then? 'minor' and 'charter change' in the same sentence constitute an oxymoron. it's a formal ietf process. perhaps more importantly, i'll suggest it's a distraction from our current work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposed changes to MLM draft
On 8/30/2010 1:10 PM, Rolf E. Sonneveld wrote: I'd suggest that the second item actually be a normative specification of value-added features. This requires a change to the charter, and so it would have to wait until completing the current charter. can you elaborate on what, in your view, would be part of this normative specification? merely as an example, I'll cite the usage of DKIM for subscription and submission validation that has been mentioned a few times. Formally, using DKIM that way is almost certainly a value-added semantic that goes beyond the semantics of the DKIM signing specification. That's ok to do, but requires a normative spec to define the behavior and meaning. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations
-deployment-11.html#rfc.section.2.4 and http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.section.2.5 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations
On 8/24/2010 11:59 AM, MH Michael Hammer (5304) wrote: Then it would appear that we are substantially in violent agreement. in spite of our best efforts. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing lists and s/mime dkim signatures - mua considerations
On 8/21/2010 6:06 PM, Daniel Black wrote: Taking an approach saying we don't care if DKIM survives MLMs is a step in the opposite direction. This is not a proposal I support. Not really, since it was known from the start that survival through an MLM is highly problematic and the steps towards helping survival were known to be quite limited. Requiring survival is a change in DKIM's goals, as well as raising a massive barrier to adoption, given the history of a) challenge in adoption for any infrastructure sequence, and b) resistance by MLM developers and operators. In other words, this line of efforts is seeking to raise the requirements for DKIM. Absent compelling and demonstrated functional need, that makes it at best a distraction and at worst counter-productive for DKIM's main purpose. DKIM's main purpose is assessment by reputation filtering engines. The most important reputations to assess are the entities that are 'responsible' for message. An MLM creates the message. That the message might look a lot like one sent /to/ it is nice, but it's also confusing. The original author is not, ultimately, responsible for what the MLM chooses to send. S/MIME already does that, with a suitable pointer. S/MIME was design to protect body content, not an entire message. All of this prompts a repeat of an underlying question: What is the purpose of this exercise and how is it justified within the charter? With respect to MLMs, I thought the focus was on documenting realities and passing through MLMs and to explore issues and opportunities better integrate MLMs into DKIM. That's quite different from trying to alter the core DKIM capability to support survival through MLMs. I'm pretty sure that changing DKIM Core is not within our charter. As for MUA considerations, anyone making claims about what is needed for utility in an MUA needs to cite their sources, providing empirical justification, not merely mathematical logic for why utility ought to be improved. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing lists and signatures (fwd)
On 8/21/2010 8:57 AM, John R. Levine wrote: T'bird for some reason doesn't see signatures wrapped inside another part. Try another MUA like Evolution and it should work better. The general form of this issue is that MIME processing varies widely and maybe wildly. This is especially true for matters of nesting. Any design that relies on consistent handling of nested MIME constructions is likely to fail. (I got another example of this earlier in the week, with a multipart message sent through a mailing list, with different forms of the same content. The MLM stripped all but the raw text version. Not nearly as pretty to the recipient.) I don't see this as profound insight, but merely another example of designing with modest expectations for a variable Internet. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing lists and signatures (fwd)
On 8/21/2010 12:57 PM, John R. Levine wrote: You're quite right, and I would extend it to say that any design that relies on MUAs to do anything consistently is in trouble. That level of generalization can't be correct. Otherwise basic interoperability at the MUA level could not exist. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
your poison.) This is hard enough at small end user organisation let alone an ISP. The end user is left with an AR header field, invisibly hidden by the MUA, to try to filtering out forged mail. DKIM has essentially nothing to do with the task of identifying forged mail, nevermind the impossible task of having the end-user doing it. For reputation service providers the assumption that mail serivce providers are going to deploy DKIM for the benefit of reputation service providers seems a little hopeful considering their costs. And yet it is being deployed. Nicely. This suggests rather clearly that your conclusion is wrong. Don't misunderstand me, domain reputation has a role in spam reduction and DKIM contributes to this, there just needs to be more benefit to the sender/receiver without it. At the end of the day the future I currently see for DKIM is the same as SPF. Then you do not understand the superiority of DKIM in a) labeling to distinguish organizations and fine-grained mail streams b) stability of labeling c) ability of the signature to survive MTA relaying and alias-type forwarding Some will deploy it but at the end of the day there will be no-one filtering on its results because of its deficiencies (MLM). You think that having an author-related signature survive mailing list re-posting is critical to the acceptance of DKIM??? I hope you have some industry-derived research data to support that assertion, because there's no indication that you are correct. The progress of deployment will stagnate in the same way as spf because there is no filtering: (compare http://web.archive.org/web/20080130150257/http://spf-all.com/ and http://spf-all.com) After watching folks make these kinds of predictions for a few decades, my observation is that the most reliable prediction about them is that they are wrong. Folks making predictions usually have far too little information or insight for making serious predictions. Your prediction falls into that category, especially since it is based on such a problematic assessment of what DKIM does and how it is intended to be used. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On 8/20/2010 11:18 AM, John Levine wrote: Why isn't a signed 822.From sufficiently accurate sender information from a provider who cares? ... I sign everything, and make no effort to validate stuff on the From: line. They key point is that DKIM makes no statement about the basis by which a given signature is made or not made, AND different signers do indeed have very different criteria. No doubt some do validate the From: field. Others merely mean the message went through my MTA. Any assertion of From: field assessment is therefore far outside the scope of the DKIM base specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] marketing dkim
On 8/19/2010 10:50 AM, Murray S. Kucherawy wrote: I would focus on the fact that it, in addition to being a mechanism to thwart forgeries, is a framework for providing things like domain reputation. Sorry, but you have these priorities and foci confused. dkim's primary use is the attachment of a verifiable label, to be used for assessment. The nature of the design of the mechanism makes its ability to be used for this purpose uncontroversial and very low risk. The risk, now, is all market preference, rather than functional. That is, there is no technical risk to DKIM's ability to satisfy this requirement. The extent to which the market finds it useful for that purpose is still being established. The extent to which dkim can also be used to protect against forgeries is, so far, completely theoretical AND controversial. We've debated this topic many times and I'm not trying to claim a certain outcome for that debate. Merely noting that it has credible people on both sides and no track record. Steve Atkins' summary and the Intro to 4871bis have the focus accurate, IMO. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Fwd: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC
FYI. d/ Original Message Subject: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT) From: IETF Secretariat ietf-secretar...@ietf.org To: IETF Announcement list ietf-annou...@ietf.org CC: ondrej.s...@nic.cz, keyass...@ietf.org A new IETF non-working group email list has been created. List address: keyass...@ietf.org Archive: http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/keyassure Description: This list is for discussion relating to using DNSSEC-protected DNS queries to get greater assurance for keys and certificates that are passed in existing IETF protocols. The main idea is that a relying party can get additional information about a domain name to eliminate the need for using a certificate in a protocol, to eliminate the need for sending certificates in the protocol if they are optional, and/or to assure that the certificate given in a protocol is associated with the domain name used by the application. In all three cases, the application associates the key or key fingerprint securely retrieved from the DNS with the domain name that was used in the DNS query. For additional information, please contact the list administrators. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] draft-ietf-dkim-rfc4871bis
Folks, draft-ietf-dkim-rfc4871bis has been submitted; for some reason the I-D submissions tool needs to process it manually and that might take awhile. Various formats of the draft, along with a diff from the RFC, are located at the DKIM site: http://dkim.org/ietf-dkim.htm#rfc7871bis d/ Original Message Subject: Manual Post Requested for draft-ietf-dkim-rfc4871bis Date: Mon, 16 Aug 2010 08:36:42 -0700 (PDT) From: IETF I-D Submission Tool idsubmiss...@ietf.org To: internet-dra...@ietf.org CC: dcroc...@bbiw.net, tony+dki...@maillennium.att.com, m...@cloudmark.com, stephen.farr...@cs.tcd.ie, barryle...@computer.org Manual Posting Requested for following Internet-Draft: I-D Submission Tool URL: https://datatracker.ietf.org/idst/status.cgi?submission_id=25864 Filename: draft-ietf-dkim-rfc4871bis Version: 00 Staging URL: http://www.ietf.org/staging/draft-ietf-dkim-rfc4871bis-00.txt Title: DomainKeys Identified Mail (DKIM) Signatures Creation_date: 2010-08-15 WG ID: dkim Number_of_pages: 74 Abstract: DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. Submitter: Dave Crocker (dcroc...@bbiw.net) Author(s): Dave Crocker, dcroc...@bbiw.net Tony Hansen, tony+dki...@maillennium.att.com Murray Kucherawy, m...@cloudmark.com -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis
On 8/16/2010 8:50 AM, Dave CROCKER wrote: Various formats of the draft, along with a diff from the RFC, are located at the DKIM site: http://dkim.org/ietf-dkim.htm#rfc7871bis sigh. Sorry. The url is: http://dkim.org/ietf-dkim.htm#rfc4871bis d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations
On 8/15/2010 6:25 PM, Daniel Black wrote: email identity is an ambiguous term. All sorts of value-added enhancements might be possible, on top of DKIM, but protecting email identity isn't really what DKIM is defined to do. rfc4781 Abstract - last sentence. Still abstract however this was a general lead-in discussion. That's why the bis draft uses different language. It's also why wg docs written aftr 4871 have been searching for better language. * end users rely, or should rely, on their MUA to present verified identity information in an easily digestable way. Human usability issues with respect to security is, at best, extremely poorly understood. The state of the design art appears to have no idea what is effective. There are a number of significant papers on the topic available. I've no idea what you mean by this. If you mean that there's been research on security and usability, yeah that's true. So what? My point is that the track record for developing mass-market user interfaces that produce good security-related interactions with end-uses is essentially non existent. My other point is that the level of the research on this topic, to date, is extremely limited and poor. Either way DKIM provides a domain responsibility signature and providing some information to the end user is useful. The assertion that it is useful is different from saying that the information is objectively meaningful. To say it is useful, there must be some basis for knowing that users will actually be able to employ the information to a productive end. The reality is that the minimal research that has been done so far suggests that such information more often confuses uses. Their cognitive model of the system and especially of security issues is far, far more limited that folks tend to realize. In addition, the presentation of the information is usually problematic. As noted, you are seeking to have DKIM perform functions it was not designed to perform. There should be no surprise that it falls shy of your desired mark. While it seems to be the intent of many within this working group to define dkim in such a way that its only plausable use is dkim reputation, a little constructive thought to other benefits for verifiers, filters and recipients would be appreciated. There is a difference between defining new semantics, versus applying existing semantics in new ways. You appear to be doing the former. That, therefore, goes beyond the DKIM Signing specification. Recipients are an important aspect of the message flow and an attempting to define a benefit to them from DKIM is an element of what I'm attempting to define. That's clear. It's also beyond the skillset of this group. It's also not required for DKIM to be useful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists annex MUA considerations
On 8/14/2010 8:50 PM, Daniel Black wrote: I intially saw a need for a MUA considerations because: * I still hope DKIM will help protect email identity email identity is an ambiguous term. All sorts of value-added enhancements might be possible, on top of DKIM, but protecting email identity isn't really what DKIM is defined to do. * end users rely, or should rely, on their MUA to present verified identity information in an easily digestable way. Human usability issues with respect to security is, at best, extremely poorly understood. The state of the design art appears to have no idea what is effective. * MLMs break signatures and MUA will still need to present verified identity As noted, you are seeking to have DKIM perform functions it was not designed to perform. There should be no surprise that it falls shy of your desired mark. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
On 8/9/2010 11:56 PM, Murray S. Kucherawy wrote: It's pretty universal. wow. I had managed to miss this, particularly given the frequent comments from folk that they wished DKIM could operate at SMTP time. (No doubt, they'd much rather have it be useful before data transfer, rather than after. Still, during SMTP is better than later.) This tidbit probably needs to be touted more. Not sure how. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Feedback on draft-ietf-dkim-mailinglists for discussion
On 8/2/2010 11:34 AM, Steve Atkins wrote: A -1 on ever altering the From: field for any reason other than special requirements of the people running a specific mailing list. A +1 in support of that -1. The view that modifying the From: is helpful has no empirical basis. I'll claim that there is a pretty good theoretical basis for believing it makes things worse, not better. As always, the instant the IETF gets into user interface design, it steps out of its group competence. As a group, we do not have the training in cognitive models, UXE, or the rest of what's needed to work in this space. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
On 8/9/2010 11:27 PM, Murray S. Kucherawy wrote: The whole point of this draft is to talk about these things about which the general public has little understanding. There's a lot of collective subconscious out there that has equated bad signature to bad message, and perhaps reasonably so. I think it's better to discuss it in this quasi-BCP than pretend it's not there and expect everyone to figure it out. In reviewing your response to John, I'm thinking that part of the initial 'orientation' work of the draft -- probably in section 3.1 -- should add to the description of the components (origination, MLM, receiver) by documenting the different scenarios that will be covered, primarily to indicate that basic types of choices or effects created by having an MLM in the sequence. The goal would be to give the reader a snapshot of each combination, so that that will be in there head when they read the details. I think much of the challenge of this exercise is deciding how to organize things, so that readers see the problem space partitioned helpfully and, therefore, get useful chunks of guidance. Otherwise it's all overwhelming. The following list is much longer than I'd like, but I think each entry is for a scenario that is distinctive and significant. (For reference, I've left some combinations off, since they didn't seem compelling to me.) DKIM: Broken Broken Signatures: Origination DKIM - Non-participating MLM - Receiving DKIM Submission enhancement: Origination DKIM - Participating MLM List reputation: Participating MLM - Receiving DKIM End-to-End DKIM: Origination DKIM - Participating MLM - Receiving DKIM Besides a discussion of each of these on their own, the possible relationship between Broken Signatures and End-to-End DKIM would be helpful in terms of the Origination signature. I think that, in fact, they produce the same result, namely a broken signature. ADSP: Broken ADSP: Origination DKIM+ADSP - Non-participating MLM - Receiving DKIM+ADSP Submission ADSP: Origination DKIM+ADSP - Non-participating MLM End-to-End ADSP: Origination DKIM+ADSP - DKIM+ADSP Participating MLM - Receiving DKIM+ADSP I don't feel religious about this list. Anything that works is fine. The combinatorials of this problem space are confusing and I'm simply searching for a way to divide into smaller bits that are easier to digest. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Splitting the mailing list document?
On 8/10/2010 9:56 AM, Murray S. Kucherawy wrote: The latter two have emerged. Neither is formally within scope of the working group, although b. is a natural addition. Note, however, that it is formal protocol specification work and we need to worry about adoption first - - who needs to adopt it and why do we think they will? Is that really true? The document is informational and is deliberately avoiding being normative about anything. Its posture is intended to convey experience of the industry so far in deploying DKIM and MLMs in tandem, and provide some suggestions of how that co-operation could be improved. The comment was about b, which specified additional semantics and a set of conventions (that is, a protocol) for achieving it. This is the extra header-field I suggested. The current draft touches this realm, but clearly it's beyond the scope of your current project. Rather, the current effort is prompting us to note some related issues. As for Informational, I'll repeat that the core of your draft -- the part that is entirely withing the direct scope as I understand it -- contains normative language. And I think that's appropriate. But that makes it not Informational, but probably a BCP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
On 8/9/2010 11:27 PM, Murray S. Kucherawy wrote: -Original Message- From: John Levine [mailto:jo...@iecc.com] Sec 3.2 2nd pp on page 9: most direct conflict operationally with DKIM - widest range of possible interactions with DKIM or something like that. I don't see any confict at all. Well the point is to address the fact that a lot of MLM actions disrupt DKIM signature validation. Maybe conflict is too strong a word, but interactions feels too soft as well. Friction feels like the right ballpark, but sounds too negative. How about foil, thwart or frustrate? I'm going to suggest that this sub-thread is pretty silly. I think the existing wording is exactly correct. The quibbling about language is based on a larger context of considerations than applies to the sentence in the draft. DKIM is a particular service. An MLM will typically destroy a DKIM signature. If destruction doesn't count as conflict with then I don't know what does. The sentence in the draft is actually quite carefully to say operationally and that is exactly the right description of the problematic effect of MLMs with respect to the author-to-reader sequence of a DKIM-signed message. Leave the sentence alone. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] what does DKIM do, was draft-ietf-dkim-mailinglists-01 review request
On 8/10/2010 10:52 AM, John R. Levine wrote: In particular, it's not intended to provide long term bullet proof message protection I probably haven't been reading carefully enough (as usual.) Amidst the current discussions, I missed the postings that seemed to be based on this different goal for DKIM. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Straw poll results
On 8/9/2010 11:41 AM, John R. Levine wrote: I hope we all agree that it is a waste of our time to design complicated mechanisms to solve problems that don't actually exist. WTF? I thought that view was 20 years out of date for the IETF. (Much longer for some other, unnamed SDOs, of course.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
or the signature can no longer be verified, the verifier must discard the message. There is no There is no must discard in ADSP. In any event, I thought the 'request' to discard applies only to the more strict setting of discard. the message. Furthermore, authors whose ADSP is published as discardable are advised not to send mail to MLMs as it is likely to be rejected by ADSP-aware recipients. (This is discussed further in Section 5.4 below.) Since this is advice to signers, it should be in the earlier sub-section. Of course, such a policy could be applied after subscription, so this is not a universal solution. An MLM implementation could do periodic checks of its subscribers and issue warnings where such a policy is detected. Concerning ADSP enforcement, the simple form of this is to check for every submission and possibly even reject at submission time if the later receipt will be rejected. It can require that messages using a given RFC5322.From address also have a DKIM signature with a corresponding d= domain. (Note, however, that it is entirely reasonable for an It occurs to me that this model is a variant of the FBL registration model... However as implied by the reference to ADSP, an implication is not being able to submit mail that is posted through alternative ADMD MTAs. This should be noted. This suggestion can be made more general. Mail that is of a transactional or generally end-to-end nature, and not likely to be This sounds interesting, but I don't really know what end-to-end means, here. different mail stream than a stream that serves a broader purpose. broader purpose? perhaps more varied uses? Although it is a common and intuitive conclusion, however, not all however - [deleted] As is typical with DKIM signing, the MLM signature must be generated only after all modifications the MLM wishes to apply have been completed. Failing to do so generates a signature that can not be Typical DKIM signing doesn't involve an MLM. I think the meaning here is something like: As is typical with DKIM signing, the MLM signature MUST be generated immediately prior to sending, and after all other processing has been completed. A signing MLM is advised to add a List-Post: header field (see [LIST-URLS]) using a DNS domain matching what will be used in the d= tag of the DKIM signature it will add to the new message. This could be used by verifiers or receivers to identify the DKIM signature that was added by the MLM. This is not required, however; This advice is predictable, understandable, and wrong. It declares a linkage that DKIM explicitly does not assert -- and in fact this draft earlier notes that it does not. There are some different directions that changes to this text might reasonably go. I'm not sure what I'd recommend. This section also appears to suggest hashing on a series of header-fields based on a belief that the DKIM header hash is protecting or validating those header fields. It doesn't do that. At its core, I believe this line of specification is attempting to creates a value-added meaning of a DKIM signature for an MLM. That seems an entirely worthy goal, but it's a new goal and requires new specification, including some flag that declares the additional semantic. A DKIM-aware resending MLM is encouraged to sign the entire message as it arrived (i.e. the MLM Input from Section 3.2), especially including the original signatures. This appears to run contrary to the earlier advice to sign just before re-posting the message. Some concern has been expressed about an MLM applying its signature to unsigned mail, which some verifiers or receivers might interpret as conferring more authority to the message content. The working group feels this is no different than present-day lists relaying traffic and affixing RFC5322.Subject tags or similar, and thus it doesn't introduce any new concerns. This isn't written in a final form appropriate to an RFC. I suggest: One concern is that having an MLM apply its signature to unsigned mail might cause some verifiers or receivers to interpret the signature as confirming more authority to the message content than is defined by DKIM. This is an issue beyond MLMs and primarily entails receive-side processing outside the scope of the DKIM specification. However it is worth nothing here. In the case of MLMs, the presence of an MLM signature SHOULD be treated as similar to MLM handling that affixes an RFC5322.Subject tag or similar information. Thus it does not introduce any new concerns. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
On 8/9/2010 3:57 PM, John Levine wrote: DKIM and ADSP evaluation are not performed during an SMTP session, unless the session is delayed after the crlf.crlf, and that's not supposed to happen. Why not? My MTA usually does a whole spamassassin run between the end of data and the ack. It adds maybe five seconds, at a point where 5321 says the timeout should be ten minutes. It's considered bad form to hold up senders that way. For one thing, it adds non-determinacy at a point which can produce retransmissions. I'm sure you're not the only one doing it, but as I recall, the standards to no institutionalize anything that forces it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Repeating the SPF/SRS mistakes (was Straw poll results
On 8/9/2010 4:42 PM, Steve Atkins wrote: 4. Write off ADSP as broken, do something useful instead. A less hostile and possibly more productive phrasing of this is: 4. Accept that ADSP has a tightly constrained range of use and that this does not include mail processed through an MLM d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Repeating the SPF/SRS mistakes (was Straw poll results
On 8/9/2010 5:29 PM, Steve Atkins wrote: 4. Accept that ADSP has a tightly constrained range of use and that this does not include mail processed through an MLM Scott already covered that in point 3, I think (Have mail get rejected/discarded/etc.). I didn't read that as the same thing. I think I understand why one might, but the semantics really are different. Reaction versus prevention... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Mailing list reality check
On 8/4/2010 9:51 AM, John Levine wrote: Assuming you do any sorting of inbound mail at all, how do you treat mail from lists to which you have subscribed? A) Use the From: address (or something that identifies the contributor) as the primary sort criterion B) Use the List-ID: (or something that identifies the list) as the primiary sort criterion C) Something else My thunderbird filters vary. Mostly they use to:/cc:, like Murray. Sometimes I've set them to use a List-ID. I typically reserve filters on the From: field for other types of mail that do not circumnavigate a mailing list. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Clarifying DKIM (etc.) expectations for mailing lists in the face of digests
On 8/4/2010 10:16 AM, Murray S. Kucherawy wrote: In the latter case, no one would reasonably expect a DKIM signature from a first (author/originator) sequence to survive. ... In theory they could survive, if the construction of the multipart/digest Yup. But that's why I chose my wording pretty carefully, making a statement about likelihood rather than theory... I'll admit that it was phrased to represent my own judgement of 'reasonable', but I'd claim that anyone disagreeing would have the first task of explaining why it would be a reasonable expectation, before anyone should consider solving it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Clarifying DKIM (etc.) expectations for mailing lists in the face of digests
On 8/4/2010 2:01 PM, John Levine wrote: There's a scenario where a spammer/phisher sets up a mailing list, ... I don't see how this poses any new problems. More to the point is that this attack does not appear to be relevant to the question I asked. Phrased differently, the question I am asking is: A mailing list digest does not preserve DKIM signatures from (any of) the original messages, and this appears to be acceptable to the community. Given that, why is it important to have those same signatures preserved, on the whim of a recipient's happening to decide to receive postings one at a time? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Clarifying DKIM (etc.) expectations for mailing lists in the face of digests
On 8/4/2010 2:44 PM, Rolf E. Sonneveld wrote: Phrased differently, the question I am asking is: A mailing list digest does not preserve DKIM signatures from (any of) the original messages, and this appears to be acceptable to the community. Are you sure it is acceptable to everyone, or does the community take it as it is? That's a fair question, and frankly I doubt much of the community is even aware of the issue. So really I'm making an assumption. Given that it is impossible to preserve the signature, when the message is embedded in another message, I'd be inclined to say that we need to see evidence from the community that that's not acceptable. I agree with you that there should be no difference regarding the treatment of the original DKIM signature, whether the message arrives in digest form or not. I'm still not convinced that the original DKIM signature is not relevant for the verifier of the message at the receiver side. If they cannot verify the signature and the specification says to treat unverified signature the same as having no signature, then anything else the receiver chooses to do is outside of the specification. The tension that there is between the MLM being a User Actor and being a Mediator is illustrated with the following text you wrote in RFC5598: I don't understand what you mean by tension. A Mediator is a type of User Actor. It is not a Relay. RFC5322 http://tools.ietf.org/html/rfc5322.Reply-To: Set by - Mediator or original Author Although problematic, it is common for a Mailing List to assign its own addresses to the Reply-To: header field of messages that it posts. This assignment is intended to ensure that replies go to all list members, rather than to only the original Author. As a User Actor, a Mailing List is the Author of the new message and can legitimately set the Reply-To: value. As a Mediator attempting to represent the message on behalf of its original Author, creating or modifying a Reply-To: field can be viewed as violating that Author's intent. If we look at the MLM as being a User Actor, then I agree that we should not care about the original DKIM signature. If however we consider the MLM as a Mediator, we should probably care about the original DKIM signature. Is there consensus that in the context of an MLM the original DKIM signature can be dropped and we should not care about it? /rolf -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Alternative MAiling List Approach
On 7/30/2010 9:26 AM, Murray S. Kucherawy wrote: No. DKIM doesn't really say much about either the From: address or the Reply-To: address, so such a suggestion for DKIM-friendly behaviour would be nonsensical. It might be a reasonable suggestion for the benefit of other protocols, but that's a different question. Is it not an ADSP issue though? Covering ADSP issues is (at least implicitly) in scope for this document. This purporting to be a technical group, precision in the use of labels is broadly viewed as a Good Thing. If you want to characterize it as ADSP-friendly, that would be precise and possibly accurate. As Steve notes, this has nothing to do with DKIM and therefore must not be labeled DKIM-friendly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] open-source IP Address reputation-building engine?
Does anyone know of an open-source module that is used to develop a reputation table by watching traffic and correlating spamminess with the original IP Address? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Call for agenda items
On 7/9/2010 9:56 AM, Barry Leiba wrote: I'd also like a sort of show of hands to let me know who's going to be attending in person, and who will participate remotely, using the audio stream or jabber. i.p. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Case for ADSP dkim=except-mlist
On 10/16/2009 3:33 PM, Michael Deutschmann wrote: I'd like to more emphatically state the case for adding a dkim=except-mlist policy to ADSP. It will soon become a practical issue for me, since my mailserver software (Exim) is going to support DKIM in its next version. Simple question: why? THe hard part is that I'll ask you to describe the end-to-end scenario that requires this and has Internet scale utility and to do this using no technical language. Remember that DKIM's job is to pass an ID that can be used for reputation. It isn't it's job to 'certify' the validity of message content. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] shared drop lists
On 6/2/2010 9:13 PM, John Levine wrote: At this point my published drop list contains paypal domains, who publish ADSP, and ebay and amazon who don't publish ADSP, but who send transaction mail all of which is as far as I can tell signed. What is the pointer to that list? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 4:08 AM, Ian Eiloart wrote: --On 26 May 2010 14:00:54 -0700 Steve Atkinsst...@wordtothewise.com wrote: You may win the battle of preventing use of the string paypal.com in the non-displayed part of the From: field, yet lose the war of protecting your users from phishers. There's nothing undisplayed about the From header in my mail client. That's nice, but it is no longer typical. Far From: it Mail clients that don't display the From header address probably should not be used. As soon as you convince all of the major MUAs to change and as soon as those changes propagate into the user world, it will be reasonable to worry about whether displaying the information matters. That is, it will be reasonable to then ask whether users will assess the validity of that information and make intelligent decisions based on it. (Hint: user interface works makes pretty clear that they won't...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 4:46 AM, Ian Eiloart wrote: --On 28 May 2010 13:26:28 -0700 Dave CROCKERd...@dcrocker.net wrote: On 5/28/2010 12:07 PM, Jeff Macdonald wrote: But I'd like to see if I understand the difference your are trying to highlight between a manually maintained list and a self published list. There is a key semantic difference which, I believe, makes for a key difference in utility. ... Actually, the difference is less than you think. It's quite possible to combine both models. You do not discuss combining the models. You discuss a tool that supports both. Juggling two things is not the same as combining them. In any event, the scope of this working group does not include design of filtering engines. It stops with providing filtering engines additional information. My previous point was -- and remains -- that the fundamental semantics of self-published information about a signer is entirely different from assessment information about that signer that is published by someone else. No software design eliminates that difference. Effectively, you're applying your own domain reputation system, and using SPF or DKIM published information to make the reputations more usable. That's not a reputation system. It's possibly useful information, but it's not reputation as the term is typically used in the industry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
On 6/2/2010 8:08 AM, Al Iverson wrote: Agree. Discard and silently discard mean the same thing, in my opinion. Though, I am guilty of using the phrase silently discard. Maybe in an attempt to be slightly over-specific. I do not recall seeing a dictionary or technical definition of discard that says anything at all about whether the discarder says anything at all. Taken on its own and without further technical specifications 'discard' does not direct, imply or request that the action be silent or noisy, and if noisy who gets to hear it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 6:33 AM, MH Michael Hammer (5304) wrote: It's really quite simple. This is the crux of the disparity of views. Those of use who note that none of this is simple worry about adoption and success barriers, noting that new services have a long and problematic history and that more efforts fail than succeed. We also note that operational details often are far more complicated and/or costly than designers anticipate. In other words, as soon as the effort moves outside of a few people's minds, nothing about this is simple. (Well, given the track record of new protocols, in general and security-related protocols in particular, I suppose it is simple and reasonable to anticipate failure.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP and Discardable (was Re: Lists BCP draft review)
On 6/2/2010 8:50 AM, Al Iverson wrote: Taken on its own and without further technical specifications 'discard' does not direct, imply or request that the action be silent or noisy, and if noisy who gets to hear it. I'm perfectly fine with being more explicit, but I do think there's an implication of silent by the use of the word discard in the context of email delivery. Among some folk, perhaps. But this is not the sort of issue that should be relied on by implication or statistical likelihood of interpretation, if there is to be productive discussion and use of the term in a standards arena. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
On 6/2/2010 9:12 AM, MH Michael Hammer (5304) wrote: For shame Dave. Taking one sentence out of context is something I would not have expected from you. After all this time, I am glad to hear that I can still surprise you... FWIW I took it out of context entirely knowingly. Frankly, I wasn't interested in the particular topic. As I said, I think that that captures the critical difference in what drives the two sides of these various-but-really-identical debates. The particular context wasn't the point. The difference in attitudes about /any/ of these topics is the point. The whole point of having a standard is to avoid the voodoo and guessing. Right. And a standard that is not adopted or used does not achieve this. Worrying very carefully about adoption barriers -- who will adopt it and why -- is essential to this, but we have not been succeeding in getting answers to hard questions here. You are absolutely correct that we should anticipate failures. That does not mean we should anticipate FAILURE from a reasonably crafted standard. Actually, yes it does. That is exactly my point. A side effect of living in Silicon Valley is seeing how often carefully crafted startups fail. Good ideas and a well-designed product are not sufficient to guarantee success, absent properly matching the /perceived/ needs of the folks who will use it /and/ the folks who will pay for it. We cannot protect foolish people from doing foolish things to themselves. This is another case of King Canute. The benefit of that perspective is acknowledging limitations. The danger is not putting in enough effort to make things appropriately usable and/or not putting enough effort into crafting a value proposition that is compelling to the target audience. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
