Re: The fallacy of perfection (Re: DKIM Signatures now being applied to IETF Email)
Hi Carsten, At 11:46 09-08-2011, Carsten Bormann wrote: For another perspective on this, see section 2.7 The fallacy of perfection in Garrulity and Fluff. (http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf) That's an interesting document. From Section 2.1: The worst source of complexity, however, is the need to appease stakeholders. As the draft points out, the cost of achieving consensus is to accept changes even though it only serves to make the protocol more complex. Some of these changes are not even implemented when they are optional or else they are only actually useful for one implementation. Ignoring MUSTs (Section 2.3) invites long debates. Instead of having the RFC align with implementations in the wild, the situation is such that implementers are pressured to adhere to the RFC. It is quite a feat to make a protocol future-proof (Section 2.5). Unfortunately, the process pushes specifications in such a direction due to the misguided belief that a perfect protocol is an attainable goal. The fact that specifications are initially of a higher quality encourages less flexibility. In other words, the committee is more reluctant to accept changes at a later stage. Section 2.7 discusses about the tendency to ignore aspects of reality that are unpleasant. On an unrelated note, I would like to congratulate NAT operators for the universal deployment of NAT. :-) The reality is whatever the IETF thinks of the principles of Internet architecture, operators will violate those principles when the latter conflicts with their core value; which is about making money. In simple terms, that protocol that has been designed to do almost everything won't gain traction if the input from operators is not taken into account. Quoting Section 2.7: In the IETF, the desire for high quality often leads to a struggle at the end to convince the IESG to accept the result. See appeasing stakeholders, big design up front, check-mark requirement above for some of the results. It may be better for a protocol to leave a flank wide open, and look for the actual requirements to be fulfilled in its actual use, then to design in a half-hearted solution appeasing the blocking IESG member that then quickly becomes a piece of fluff when it is replaced (or, worse, over-painted) by the real thing. (The stick of keeping a protocol experimental instead of standards track is then often used to push those solutions through.) As much as I agree with the above, it in unconceivable that draft-bormann-core-6lowpan-fluff-minus would be considered for publication in the IETF Stream as such an uncomfortable truth might be deemed as unacceptable. Five years ago, a BCP was published to describe the best current practice for a widely deployed Experimental protocol. The working group came up with modifications to the protocol that the WG thought made it better but that implementors didn't see any reasons to deploy. This thread was initially about DKIM Signatures now being applied to IETF Email. Some people from the IETF sausage factory are aware that DKIM is broken; i.e. DKIM signatures will fail to verify when a message goes through a mailing list. Some people might call that a flaw, others might say that it is by design. The point is that it is not possible to address all cases. As Nathaniel Borenstein put it, can we accept the inevitability of a flawed process that lets a few bugs get through? These multi-year big design up front efforts favor high quality of documents at the expense of timeliness. The longer the design effort takes, the shorter the incremental benefit. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The fallacy of perfection (Re: DKIM Signatures now being applied to IETF Email)
SM wrote: Hi Carsten, At 11:46 09-08-2011, Carsten Bormann wrote: For another perspective on this, see section 2.7 The fallacy of perfection in Garrulity and Fluff. (http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf) That's an interesting document. From Section 2.1: Yes, it is a interesting document. In simple terms, that protocol that has been designed to do almost everything won't gain traction if the input from operators is not taken into account. +1 and this, in my opinion, is the blessing and curse of the IETF and when coupled with the outdated Rough Consensus decision making guideline, it can have had a negative impact in the final outcome. I have been part of several open technical standard organizations where the philosophical difference of the mixed discipline environment, i.e. Administrators vs Developers was the source of doom, especially when the art of compromising is lacking or unachievable. My view, it all begins with the main source. It is very important the editor(s) recognize input is coming from all sides. Once they shun one group over another and use Rough Consensus (RC) as the measuring stick to shun others, its over. Everyone loses. RC is ok when everyone in the group (team) have a similar discipline or mindset. But when there extreme mindsets, it simply doesn't work for the benefit of the main WG or protocol goal. This is like prematurely inviting a technical sales team, documentation team or help desk to a project RD effort. They might fit better during a early functional requirement stage or Product RD effort, but when conflicts mindset are smack in the middle of a protocol design, that spells problems. Of course, All input is input so generally, at the end of the day, this is more about a management problem - a.k.a IETF WG Chairs. Ideally, the editors should be very keen to these differences Anyway, today, I don't think Rough Consensus is a good decision making, issues settling tool that can resolve problems by blowing away a good size minority out the door. That causes problems. When there is disperse group, I believe a super majority is a fundamental and statistically correct requirement that have a maximum beneficial outcome. This is akin to adding features to a product; when there is no clear answer - you make it optional. Throwing it away will invite support issues. :) I said more than I wanted to, but its just my opinion. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On Aug 1, 2011, Keith Moore wrote: Perhaps. But it's difficult to escape the impression that this is another example of IETF failing to solve an important problem by focusing on a portion of the problem that's easy to solve, and ruling the difficult part out of scope for the time being. Repeat as needed; you can always partition the remaining part of the problem again. . Does it follow, then, that the Right Thing to do is to avoid building any other parts of the system (even, say, the reputation service query protocol) until the easiest part is finished? No extreme is likely to work, because this is essentially an optimization question for standards processes.We worry too little about the opportunity cost of the passage of time, so we fight time-consuming battles. We should instead be trying to build an optimal pipeline of incremental progress in a generally positive direction, acknowledging inevitable mistakes along the way. I'd like to view the IETF as a standards factory, with a certain optimal level of throughput that we're trying to achieve. As with, say, a sausage factory, you don't just take in a single opinion, chop it up to bits, and deliver a snack-sized bit of RFC before moving on to process the next opinion. The economic benefits of parallelism are so large that they dwarf all but the worst mistakes, so we accept the inevitability of a flawed process that lets a few bugs get through. As a technologist I hate that(*), but it's true. And it means that, if you can look back on a standard you worked on a few years ago and not have any regrets, you spent too much time on it. So while we obviously need to focus on smallish, core chunks of technology like DKIM before devoting a lot of effort to building on top of them, we also need to start the latter before the former are completely finished. If anything, we're late. DKIM is almost a decade old. It's pretty good, and we've long since reached diminishing returns. There's plenty more to do. It's time to move on. -- Nathaniel _ (*) As a vegetarian I just feel smug. :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The fallacy of perfection (Re: DKIM Signatures now being applied to IETF Email)
On Aug 9, 2011, at 20:30, Nathaniel Borenstein wrote: We worry too little about the opportunity cost of the passage of time, so we fight time-consuming battles. We should instead be trying to build an optimal pipeline of incremental progress in a generally positive direction, acknowledging inevitable mistakes along the way. Nathaniel, this (and the rest of your message) is probably the most profound observation I've heard about the IETF process for quite a while. For another perspective on this, see section 2.7 The fallacy of perfection in Garrulity and Fluff. (http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf) Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Murray S. Kucherawy wrote: We are perfectly aware you never believed in policy, never really acknowledge it, fought hard against its progress. I can respect that position. But I am bit vex as to why you are questioning its existence as an original and still current WG work item. Where I come from, personal attacks don't support your position; they degrade your credibility. And with your personal animosity towards me, I'm sure you will repeat this to negate concerns. I don't view expressing a public recorded oppositional stance as an attack. The ongoing claims that the working group was guided by sinister designs to benefit from some specific alternate market are simply absurd. No one stated it was sinister. That blab always came from your description whenever anyone dared to state the obviousness of the conflict of interest in the WG. 1) I always stated both security and trust ideas are necessary and should of been incorporated. I opposed eliminating author domain semantics and security and especially opposed the rewrite and limiting the protocol specification to exclusively only 3rd party TRUST Service Engine integration out of the box, 2) I illustrated two examples of how unrestricted resigner creating mail integration problems, effectively making it impossible for any kind of policy to work reliably outside prearranged known communications. As a DKIM implementor and one of those sinister capitalist creating products that include allowing a business to create trust services as well, the above has made it very difficult and I see little to no payoff in DKIM future - as it currently written in its limited nature to only trust and for writing software with no design considerations for controlling and restricting resigning. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 8/2/2011 1:11 AM, t.petch wrote: When people have a need, and want a technical solution, and then find that what at first sight appeared to be a solution is not one, then they may be disappointed, and be critical. That is human nature. When that happens is a time to reflect, to look at the requirements that were not met. Tom, one of the other, preferred characteristics of human nature is to take constructive action upon identifying a problem. So I look forward to seeing your proposal and pursuit of a solution to this important problem that DKIM does not try to solve. And, as I said before, my criticism is of those who have imposed this technology on the IETF lists, not of the technology itself. Indeed. It really is irresponsible of them to improve the accountability of email going out through the IETF. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Nathaniel Borenstein wrote: I find it amazing how many different ways there are to criticize DKIM for not doing something it was never intended to do. DKIM is a small building block that enables new functionality, but such functionality is beyond the scope of DKIM. Note: We have an advanced implementation of DKIM as a product line so my concerns are not outsider views. My input is 100% based on implementation and field experiences. Policy was very fundamental to the understanding of DKIM, it was part of the original DomainKeys and DKIM expanded this powerful concept with a wider range of Author Domain policies. I never disputed the out of scope 3rd party trust policy model but it addressed a different problem - trust, if any, of a valid signature after the violations are filtered by author domain policies, if any. Two different layers and this was outlined in my 2006 DKIM Signer Authorization Protocol (DSAP) I-D. The problem was a conflict in different market ideas - an unrestricted resigner DKIM mail market which 1st party security controls would conflict with. They simply did not want the 1st party to override any 3rd party signers. This conflict was highlighted in the SSP requirements with the last minute addition in RFC5016: Requirements for a DKIM Signing Practices Protocol when item #10 was added in section 5.3 to appease the opponents of 1st party SSP polices: 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. Refs: Deployment Consideration, Section 4.3. This was unfortunate. On the one hand it suggest we should not meddle in how local receivers will behave yet it imposes a MUST NOT mandate in allowing the 1st party policy to override a 3rd party signature trust policy. DKIM does one thing, and one thing only: It uses a cryptographic signature to associate a domain with a message. It does more than that. DKIM has a fundamental requirement to hash bound the 5322.From field to the signature. Its the only header that MUST be signed. All others are optional. This 5322.FROM bind provide the only anchor possible that can be repudiated. So there are two principal domains associated with a signature: Signerd= value in signature 5322.From DKIM requirement By doing so, it creates strong evidence that the message passed through that domain at some point and has not been significantly modified since. I don't see this. The resigner can be totally opaque with no association with the original domain. The signer::author association begins with the original signature creation by the author domain selecting a signer and/or prearranged with an outsource signing service. Now, what people are looking for as well, is when there is resigner::author association when the author is participating in a resigner network. Currently we call this a 3rd party Authorization. With such an anchor, we can begin to build stronger and more robust systems for analyzing the desirability of messages, as we are now trying to do in the REPUTE work, because it allows us to push our forensic analysis upstream a bit. Heuristic wrappers are interesting but its a different problem. It doesn't adequately address what a deterministic solution can do for you. If, for example, the IETF mailing list software only allows posting by list members, but itself trusts the sender's header fields, then an IETF DKIM signature tells me only that the IETF servers think a message passed that test. There you go, you made an POLICY STATEMENT - translate it into a protocol for everyone to follow and check. That's obviously not perfect, but it's slightly stronger than what came before -- it is still possible to forge a message before sending it to the list, but much harder to forge a message to look as if it came from the list exploder. This is all besides the point. Its all about detection what YOU think is a violation of a protocol logic. Whatever you produce in REPUTE, you are producing a idea for people to follow consistency based on some baseline rules established. We've had a long history of grand plans for user authentication on the Internet. Those plans have largely failed. There are plenty of authentication protocols that works very well, and fundamental to our current network. The issue here is a DKIM signer market run wild uncontrolled and if we don't get our act together soon to put a security wrapper around it, it risk becoming yet
Re: DKIM Signatures now being applied to IETF Email
- Original Message - From: Nathaniel Borenstein n...@guppylake.com To: Hector Santos hsan...@isdg.net Cc: ietf ietf@ietf.org Sent: Monday, August 01, 2011 2:48 PM Subject: Re: DKIM Signatures now being applied to IETF Email I find it amazing how many different ways there are to criticize DKIM for not doing something it was never intended to do. DKIM is a small building block that enables new functionality, but such functionality is beyond the scope of DKIM. I agree that DKIM does exactly what it sets out to do, but am not amazed that it attracts criticism. When people have a need, and want a technical solution, and then find that what at first sight appeared to be a solution is not one, then they may be disappointed, and be critical. That is human nature. When that happens is a time to reflect, to look at the requirements that were not met. If they were captured and rejected, at least for the time being, then noone has any cause to be upset. But if the requirements were not captured, then perhaps it is a time to contemplate that, how were they missed, what else might have been missed and whether or not that should be acted upon in future. And, as I said before, my criticism is of those who have imposed this technology on the IETF lists, not of the technology itself. Tom Petch DKIM does one thing, and one thing only: It uses a cryptographic signature to associate a domain with a message. By doing so, it creates strong evidence that the message passed through that domain at some point and has not been significantly modified since. Whether that domain is good guys or bad guys, senders or resenders, Coke or Pepsi, is completely irrelevant. It is a small nugget of evidence to provide an anchor point for forensics stronger than what have come before. It tells us that the named domain considered the message reasonable to send or resend, for its own reasons -- its own forensic evidence, its nefarious intent, or the phase of the moon. With such an anchor, we can begin to build stronger and more robust systems for analyzing the desirability of messages, as we are now trying to do in the REPUTE work, because it allows us to push our forensic analysis upstream a bit. It does not relieve downstream software of the need to decide how to feel about the signing domain, whether it's a spammer, a copy-cat, or anyone else. If, for example, the IETF mailing list software only allows posting by list members, but itself trusts the sender's header fields, then an IETF DKIM signature tells me only that the IETF servers think a message passed that test. That's obviously not perfect, but it's slightly stronger than what came before -- it is still possible to forge a message before sending it to the list, but much harder to forge a message to look as if it came from the list exploder. That is progress -- very very small, slow, progress. If, at some point, the list exploder starts only passing through messages that themselves have valid DKIM signatures, it will be significantly more progress, but it won't do anything to stop a spammer from subscribing to the IETF list and DKIM-authenticating himself. For that we'll need reputation information -- another small step, which we're trying to initiate with REPUTE. We've had a long history of grand plans for user authentication on the Internet. Those plans have largely failed. I think an incremental approach like DKIM has a better chance, but it is obviously vulnerable to being dismissed by those who see a small improvement as not worth bothering with. The best is the enemy of the good. -- Nathaniel On Jul 31, 2011, at 6:12 AM, Hector Santos wrote: You continue to not comprehend (or rather ignore) what continues to plaque DKIM - the lack of fault detection. Its why it continues to have a hard time and have people who actually believe in this promising protocol bitch about it. If these big email providers (or anyone for that matter) begin to make assertions about what is good about their mail then they better be ready for the violations of such assertions to be rejected. You can't have it just one way and mandate this is the only way to process this overhead - looking for good mail only and ignoring all the violations and illogically treating it like it was never signed or compromised or attempted to be compromised. The overall difficulty is that originality is lost - the original author or dkim signer has lost or lacks any protocol guidance to tell resigners that the mail they are about the process might be bad - according to the original author domain. If the resigner is going to intentionally and neglectfully ignore all original claims about the original domain signing practice, then how do you expect the anonymous copy-cat abuse to be controlled? Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of t.petch Sent: Saturday, July 30, 2011 3:26 AM
Re: DKIM Signatures now being applied to IETF Email
On 02/Aug/11 06:52, Hector Santos wrote: Keith Moore wrote: Repeat as needed; you can always partition the remaining part of the problem again. It was not a difficult problem. [...] how to scale the authorization of 3rd party signer. [...] But there was a fundamental mindset and marketing conflict. It was a conflict of 3rd party resigner market right to exist uncontrolled, unrestricted regardless of originating DKIM message claims. Marketing pressure on IETF protocols may be business as usual, but DKIM managed to come out pretty cleanly neutral in this respect, AFAICS[*]. IMHO, a scenario with a few big re-signers would pose more problems than it can ever solve. I wish they... resign. However, managing reputation without having recourse to a big brother of some sort is no easy problem. Since even governments are being blamed for pursuing personal interests rather than people's needs, solving that will be a major achievement in democracy. -- [*] Let's draw a veil over that somewhat confused patent disclosure https://datatracker.ietf.org/ipr/1547/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DKIM Signatures now being applied to IETF Email
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alessandro Vesely Sent: Tuesday, August 02, 2011 6:28 AM To: ietf@ietf.org Subject: Re: DKIM Signatures now being applied to IETF Email It was not a difficult problem. [...] how to scale the authorization of 3rd party signer. [...] But there was a fundamental mindset and marketing conflict. It was a conflict of 3rd party resigner market right to exist uncontrolled, unrestricted regardless of originating DKIM message claims. Marketing pressure on IETF protocols may be business as usual, but DKIM managed to come out pretty cleanly neutral in this respect, AFAICS[*]. I think the claim that marketing somehow entered into the guidance of DKIM's evolution is specious, and that's being polite. I've yet to see any evidence at all, short of unfounded assertions about the unspoken agendas of the participants, to back it up. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 8/1/2011 8:41 AM, Scott Kitterman wrote: In fairness to Hector, the functionality that he is complaining is missing was part of the original working group charter. please cite the text from the original charter that promises such work and, just to be safe, please cite the current text that claims it should be there. In other words, the current complaint is about something missing. Please quote the specification of that and then the part of the original charter that said we would do it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Dave CROCKER wrote: On 8/1/2011 8:41 AM, Scott Kitterman wrote: In fairness to Hector, the functionality that he is complaining is missing was part of the original working group charter. please cite the text from the original charter that promises such work and, just to be safe, please cite the current text that claims it should be there. In other words, the current complaint is about something missing. Please quote the specification of that and then the part of the original charter that said we would do it. We are perfectly aware you never believed in policy, never really acknowledge it, fought hard against its progress. I can respect that position. But I am bit vex as to why you are questioning its existence as an original and still current WG work item. The DKIM WG always had among its charter work items to produce a Domain Policy standard and even thought the charter was revised over the years, Policy is still today among the WG chartered item today. I personally have not seen or read of any official statement to conclude the WG and stop all remaining work, nor a change in the charter to official remain policy as a work item. Attached is 2005 copy of the charter I have on disk. Please note how reputation was declared of out of scope, yet it continued to disrupt the WG and revamped DKIM to its present condition. Two other WG RFC work items were completed; one directly related to producing the Requirements for a DKIM Signing Practices Protocol RFC5016, and a Threat Analysis RFC4686 which includes among its analysis how policy can mitigate certain security threats using Policy. You, yourself, wrote a RFC5585 called DomainKeys Identified Mail (DKIM) Service Overview with signing practices peppered over all the document as a major piece of the system. This sentence is found in the abstract: DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. And the RFC includes a spiffy process flow illustration titled DKIM Service Architecture with a Checking Signing Practice component as a major piece of this design. So I am scratching my head here wondering why you are now questioning how a framework designed over 5 years had major work productions dismissed, especially those related to security, in the pursuit of the unrestricted resigner and 3rd party trust vendor service market and now seem to suggest the DKIM WG Domain Signing Practices standardization efforts was not a work item and never existed in the first place as a charter item, when in fact, it is still today a WG charter item. Very odd. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com DRAFT IETF WORKING GROUP CHARTER 14 Oct 2005 Domain Keys Identified Message (DKIM) CHAIRS: TBD AREA DIRECTORS: Russell Housley, Sam Hartman AREA ADVISOR: Russell Housley hous...@vigilsec.com MAILING LISTS: General Discussion: ietf-d...@mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ DESCRIPTION OF WORKING GROUP: The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam (when done illegitimately, it's called spoofing). The DKIM working group will produce standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message and to publish policy information about how it applies those signatures. Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain. The DKIM working group will produce summaries of the threats that are addressed by the standards-track specifications, while acknowledging their limitations and scope. The DKIM working group will also produce security requirements to guide their efforts, and will analyze the impact on senders and receivers who are not using DKIM, particularly any cases in which mail may be inappropriately labeled as suspicious or spoofed. While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a valuable tool for defense against them by allowing receiving domains to detect spoofing of known domains. The standards-track specifications will not mandate any particular action by the receiving domain when spoofing is detected. The DKIM working group will not attempt to define such actions, to establish requirements for trust relationships between domains, or to specify reputation or accreditation systems.
RE: DKIM Signatures now being applied to IETF Email
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hector Santos Sent: Tuesday, August 02, 2011 2:33 PM To: ietf@ietf.org Subject: Re: DKIM Signatures now being applied to IETF Email We are perfectly aware you never believed in policy, never really acknowledge it, fought hard against its progress. I can respect that position. But I am bit vex as to why you are questioning its existence as an original and still current WG work item. Where I come from, personal attacks don't support your position; they degrade your credibility. The DKIM WG always had among its charter work items to produce a Domain Policy standard and even thought the charter was revised over the years, Policy is still today among the WG chartered item today. I personally have not seen or read of any official statement to conclude the WG and stop all remaining work, nor a change in the charter to official remain policy as a work item. There is no rule anywhere that I've seen requiring a working group to complete all of its chartered items if one of them turns out to be a bad or dangerous idea, especially if the sponsoring Area Director concurs. It doesn't matter what other informational documents it may have produced prior to that point. This is also true if the working group runs out of steam to keep working on something. All of those things happened here. The ongoing claims that the working group was guided by sinister designs to benefit from some specific alternate market are simply absurd. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
I find it amazing how many different ways there are to criticize DKIM for not doing something it was never intended to do. DKIM is a small building block that enables new functionality, but such functionality is beyond the scope of DKIM. DKIM does one thing, and one thing only: It uses a cryptographic signature to associate a domain with a message. By doing so, it creates strong evidence that the message passed through that domain at some point and has not been significantly modified since. Whether that domain is good guys or bad guys, senders or resenders, Coke or Pepsi, is completely irrelevant. It is a small nugget of evidence to provide an anchor point for forensics stronger than what have come before. It tells us that the named domain considered the message reasonable to send or resend, for its own reasons -- its own forensic evidence, its nefarious intent, or the phase of the moon. With such an anchor, we can begin to build stronger and more robust systems for analyzing the desirability of messages, as we are now trying to do in the REPUTE work, because it allows us to push our forensic analysis upstream a bit. It does not relieve downstream software of the need to decide how to feel about the signing domain, whether it's a spammer, a copy-cat, or anyone else. If, for example, the IETF mailing list software only allows posting by list members, but itself trusts the sender's header fields, then an IETF DKIM signature tells me only that the IETF servers think a message passed that test. That's obviously not perfect, but it's slightly stronger than what came before -- it is still possible to forge a message before sending it to the list, but much harder to forge a message to look as if it came from the list exploder. That is progress -- very very small, slow, progress. If, at some point, the list exploder starts only passing through messages that themselves have valid DKIM signatures, it will be significantly more progress, but it won't do anything to stop a spammer from subscribing to the IETF list and DKIM-authenticating himself. For that we'll need reputation information -- another small step, which we're trying to initiate with REPUTE. We've had a long history of grand plans for user authentication on the Internet. Those plans have largely failed. I think an incremental approach like DKIM has a better chance, but it is obviously vulnerable to being dismissed by those who see a small improvement as not worth bothering with. The best is the enemy of the good. -- Nathaniel On Jul 31, 2011, at 6:12 AM, Hector Santos wrote: You continue to not comprehend (or rather ignore) what continues to plaque DKIM - the lack of fault detection. Its why it continues to have a hard time and have people who actually believe in this promising protocol bitch about it. If these big email providers (or anyone for that matter) begin to make assertions about what is good about their mail then they better be ready for the violations of such assertions to be rejected. You can't have it just one way and mandate this is the only way to process this overhead - looking for good mail only and ignoring all the violations and illogically treating it like it was never signed or compromised or attempted to be compromised. The overall difficulty is that originality is lost - the original author or dkim signer has lost or lacks any protocol guidance to tell resigners that the mail they are about the process might be bad - according to the original author domain. If the resigner is going to intentionally and neglectfully ignore all original claims about the original domain signing practice, then how do you expect the anonymous copy-cat abuse to be controlled? Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of t.petch Sent: Saturday, July 30, 2011 3:26 AM To: Barry Leiba Cc: ietf Subject: Re: DKIM Signatures now being applied to IETF Email Sadly, I do not see it being used in the mailing lists where an organisation is sending me directly data I would like to be able to rely on - which I think fits the applicability well - and instead, I see it being used on a mailing list such as those in the IETF where I believe that the costs outweigh the benefits - and I have no choice about that:-(. There has been some post-DKIM talk recently about the idea of transient trust, wherein (to use this example) ietf.org would verify the signature on an arriving list submission, attach an RFC5451 header field that indicates the results of that verification, then send the message out to the list with that added field and a new ietf.org signature that covered it. Then, if you decide to believe ietf.org's claims about the original signature, you know more than you would otherwise. This hasn't been widely deployed yet, but some big email providers are currently
Re: DKIM Signatures now being applied to IETF Email
On Monday, August 01, 2011 08:48:04 AM Nathaniel Borenstein wrote: I find it amazing how many different ways there are to criticize DKIM for not doing something it was never intended to do. DKIM is a small building block that enables new functionality, but such functionality is beyond the scope of DKIM. DKIM does one thing, and one thing only: It uses a cryptographic signature to associate a domain with a message. By doing so, it creates strong evidence that the message passed through that domain at some point and has not been significantly m ... In fairness to Hector, the functionality that he is complaining is missing was part of the original working group charter. I think it's unfortunate (and I said so at the time) that the group chose to define a core DKIM protocol first and then attempt to bolt a policy mechanism on afterwards. It's rather not suprising it didn't work out well (ADSP). So you are correct, it does one thing and one thing only, but that's because the WG decided to build it that way, not because the WG was limited to that. Of course, now, it is what it is and there's no changing that, but I also think it's reasonable to think it could have been done better. Scott K P.S. It's possible I may mis-remember WG versus pre-WG discussions here, but either way it was a poor (IMO) way to attempt to tackle the work. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DKIM Signatures now being applied to IETF Email
My own recollection is that the working group originally had policy ideas in its charter, but as we went through the work it became evident that doing DKIM policy was increasingly hard to get right without creating something unreliable or even damaging to the current infrastructure. Thus, I think the separation in scope became necessary as the base protocol developed and matured. Unfortunately, there are a those who cling tenaciously to the original view and scope, and thus assert that anything less than the original goal set means DKIM is a failure. But, also unfortunately, no workable solution has yet to be presented. Nathaniel's statement is right on the money: DKIM, in its current form, is an important development enabling some important new functionality. Rather than harping on the cruft that was cut away from DKIM along its path, we should be focusing on the new stuff, as that's what we really need, and that's what stands the greatest chance of success going forward. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On Aug 1, 2011, at 2:50 PM, Murray S. Kucherawy wrote: My own recollection is that the working group originally had policy ideas in its charter, but as we went through the work it became evident that doing DKIM policy was increasingly hard to get right without creating something unreliable or even damaging to the current infrastructure. Thus, I think the separation in scope became necessary as the base protocol developed and matured. Unfortunately, there are a those who cling tenaciously to the original view and scope, and thus assert that anything less than the original goal set means DKIM is a failure. But, also unfortunately, no workable solution has yet to be presented. Nathaniel's statement is right on the money: DKIM, in its current form, is an important development enabling some important new functionality. Rather than harping on the cruft that was cut away from DKIM along its path, we should be focusing on the new stuff, as that's what we really need, and that's what stands the greatest chance of success going forward. Perhaps. But it's difficult to escape the impression that this is another example of IETF failing to solve an important problem by focusing on a portion of the problem that's easy to solve, and ruling the difficult part out of scope for the time being. Repeat as needed; you can always partition the remaining part of the problem again. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On Monday, August 01, 2011 02:50:27 PM Murray S. Kucherawy wrote: My own recollection is that the working group originally had policy ideas in its charter, but as we went through the work it became evident that doing DKIM policy was increasingly hard to get right without creating something unreliable or even damaging to the current infrastructure. Thus, I think the separation in scope became necessary as the base protocol developed and matured. Unfortunately, there are a those who cling tenaciously to the original view and scope, and thus assert that anything less than the original goal set means DKIM is a failure. But, also unfortunately, no workable solution has yet to be presented. Nathaniel's statement is right on the money: DKIM, in its current form, is an important development enabling some important new functionality. Rather than harping on the cruft that was cut away from DKIM along its path, we should be focusing on the new stuff, as that's what we really need, and that's what stands the greatest chance of success going forward. I agree. The one thing I don't agree with in his statement is the never part of ... criticize DKIM for not doing something it was never intended to do. It is what it is, for better or worse and we need to move forward, but I don't think historical revisionism is appropriate (DomainKeys, which is the antecedent to DKIM, had a policy component, so expecting that to have been included in DKIM is not at all unreasonable). We should move forward with what we have, but not forget how we got here. Scott K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Perhaps. But it's difficult to escape the impression that this is another example of IETF failing to solve an important problem by focusing on a portion of the problem that's easy to solve, and ruling the difficult part out of scope for the time being. It's definitely a case of the best being the enemy of the good. There are some basic problems with any system of policy assertions: the people making the assertions may be mistaken or lying (something we've seen with ADSP), and there are precious few assertions that I can make that are of any use to you in deciding how to deal with my traffic. Since you have no reason to believe my assertions unless you already know me, you need mechanisms for third parties that can opine about the credibility of self-assertions. Inventing the mechanism is only medium hard (see RFC 5518) but spinning up vouching services that provide a usefully large amount of information is very hard. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On Aug 1, 2011, at 6:57 PM, John Levine wrote: Perhaps. But it's difficult to escape the impression that this is another example of IETF failing to solve an important problem by focusing on a portion of the problem that's easy to solve, and ruling the difficult part out of scope for the time being. It's definitely a case of the best being the enemy of the good. There are some basic problems with any system of policy assertions: the people making the assertions may be mistaken or lying (something we've seen with ADSP), and there are precious few assertions that I can make that are of any use to you in deciding how to deal with my traffic. Since you have no reason to believe my assertions unless you already know me, you need mechanisms for third parties that can opine about the credibility of self-assertions. Inventing the mechanism is only medium hard (see RFC 5518) but spinning up vouching services that provide a usefully large amount of information is very hard. I buy all of the above. Does it follow, then, that the Right Thing to do is to avoid building any other parts of the system (even, say, the reputation service query protocol) until the easiest part is finished? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Does it follow, then, that the Right Thing to do is to avoid building any other parts of the system (even, say, the reputation service query protocol) until the easiest part is finished? If we knew what to build, we'd build it. We published RFC 5518 for VBR, a reputation system that sits on top of DKIM, two years ago. At this point I know of only one small VBR provider, which I manage. Also, even without general reputation systems, there are special cases that are worth doing, e.g., there's a handful of large heavily phished domains that sign all their mail, notably paypal.com and its ccTLD variants. For a medium or large mail system, it's worth adjusting the spam filters to throw away mail purporting to be from Paypal that doesn't have a signature. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Keith Moore wrote: Perhaps. But it's difficult to escape the impression that this is another example of IETF failing to solve an important problem by focusing on a portion of the problem that's easy to solve, and ruling the difficult part out of scope for the time being. Repeat as needed; you can always partition the remaining part of the problem again. It was not a difficult problem. The issues were well understood long before Murray took over the DKIM specification. The WG security and requirements RFC productions clearly laid it out: RFC4686 Analysis of Threats Motivating DKIM RFC5016 Requirements for a DKIM Signing Practices Protocol The remaining technical problem was how to scale the authorization of 3rd party signer. The proposals ASL Allowed Signer List (good for small systems, does not scale) TPA Third Party Authorization (appear to scale, but complex) ATPS Authorized Third Party Signer (easier version of TPA) But there was a fundamental mindset and marketing conflict. It was a conflict of 3rd party resigner market right to exist uncontrolled, unrestricted regardless of originating DKIM message claims. The WG could not continue to complete RF5017 ADSP when the then out of scope Trust ideas took over and promoted a market of unrestricted resigners. If ADSP became a standard then these resigners would be in violation of a security standard, and it would be a serious problem if they intentionally and neglected a security protocol when they resigned mail potentially distributing harmful mail The easy solution is to toss out ADSP, like it never existed. No one should follow original domain policy declarations. But this only shifted to the problem to the resigner who has no sort of policy wrappers. What happens with resigners resign resigned mail? Who will protect them? Without based line protocol consistent controls and guidelines to follow, I'm afraid DKIM signing is fast becoming is rabid hop to hop message signature stamping broadcasting concept where the only remaining benefit is to make sense of the last signer which is never a problem in the authorized and known mail world. Its a problem with the anonymous world and a DKIM-signature has no value here when the signer is unknown. Since DKIM-signature requires the 5322.From address to be hash bound to the signature, the lost of policy allowed the anonymous abuse of these domains to continue. The issue is straight forward, either resigners support signing controls or not. Obviously the latter was the easy way for THEM but it didn't solve the problem. No matter way a policy concept is required. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
You continue to not comprehend (or rather ignore) what continues to plaque DKIM - the lack of fault detection. Its why it continues to have a hard time and have people who actually believe in this promising protocol bitch about it. If these big email providers (or anyone for that matter) begin to make assertions about what is good about their mail then they better be ready for the violations of such assertions to be rejected. You can't have it just one way and mandate this is the only way to process this overhead - looking for good mail only and ignoring all the violations and illogically treating it like it was never signed or compromised or attempted to be compromised. The overall difficulty is that originality is lost - the original author or dkim signer has lost or lacks any protocol guidance to tell resigners that the mail they are about the process might be bad - according to the original author domain. If the resigner is going to intentionally and neglectfully ignore all original claims about the original domain signing practice, then how do you expect the anonymous copy-cat abuse to be controlled? Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of t.petch Sent: Saturday, July 30, 2011 3:26 AM To: Barry Leiba Cc: ietf Subject: Re: DKIM Signatures now being applied to IETF Email Sadly, I do not see it being used in the mailing lists where an organisation is sending me directly data I would like to be able to rely on - which I think fits the applicability well - and instead, I see it being used on a mailing list such as those in the IETF where I believe that the costs outweigh the benefits - and I have no choice about that:-(. There has been some post-DKIM talk recently about the idea of transient trust, wherein (to use this example) ietf.org would verify the signature on an arriving list submission, attach an RFC5451 header field that indicates the results of that verification, then send the message out to the list with that added field and a new ietf.org signature that covered it. Then, if you decide to believe ietf.org's claims about the original signature, you know more than you would otherwise. This hasn't been widely deployed yet, but some big email providers are currently playing with the idea. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
- Original Message - From: Barry Leiba barryle...@computer.org To: t.petch daedu...@btconnect.com Cc: ietf ietf@ietf.org Sent: Friday, July 29, 2011 5:02 PM I think that it is an error for the IETF to add DKIM signatures. They do indeed tell me which intermediary has sent me the mail, but does nothing for the 'spam' that the intermediary accepted in the first place (albeit there being little of that on the IETF managed lists). ... It functions, but does not work, in that it tells me nothing about the true origin of the communication. What it does is allow you to assure yourself that the message was, indeed, from an IETF mailing list (well, from an IETF email server), and that it wasn't that someone tried to spoof that. That, in turn, allows you to confidently increase your trust that the message is not spam in proportion to your confidence in the IETF's spam-filtering capabilities. Some of us, at least, find that useful. Some of us might even completely white-list IETF-signed messages. You can make your own choice on that. tp Yes, I do understand that - having read the first round of DKIM RFC when they came out all those years ago - and do see it as a useful tool for improving the security of e-mail and I should have made that clearer in my first e-mail. Sadly, I do not see it being used in the mailing lists where an organisation is sending me directly data I would like to be able to rely on - which I think fits the applicability well - and instead, I see it being used on a mailing list such as those in the IETF where I believe that the costs outweigh the benefits - and I have no choice about that:-(. Tom Petch Barry, DKIM WG chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 7/30/2011 6:26 AM, t.petch wrote: Sadly, I do not see it being used in the mailing lists where an organisation is sending me directly data I would like to be able to rely on - which I think fits the applicability well - and instead, I see it being used on a mailing list such as those in the IETF where I believe that the costs outweigh the benefits - and I have no choice about that:-(. Costs? 1. The only place that DKIM information appears in a message is in a special header-field. 2. If your system does not process DKIM and you don't display the full header, you don't even see that it is there; unlike OpenPGP and S/MIME, there is no evidence of DKIM in the body. 3. The increase in size in message size is felt by the industry to be a minor cost, especially given all the other functions that already increase message size. 4. If the extra bytes are such a terrible burden for you, strip the field off. It does seem odd to complain about a mechanism that (finally) provides a certifiably valid identifier on messages, in an environment where 90% of the traffic across the Internet exploits the fact that there hasn't been one... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Dave CROCKER wrote: It does seem odd to complain about a mechanism that (finally) provides a certifiably valid identifier on messages, in an environment where 90% of the traffic across the Internet exploits the fact that there hasn't been one... How it is certified? I haven't seen any DKIM message that comes with a certified identifier. Is there consistency in the certification across all DKIM verifiers? What do you when it isn't certified which is 99% of the DKIM signed mail coming in? And how does one leverage or mitigate this 90% asserted exploitation with DKIM? Should we begin to reject mail that do not have valid signatures? Without a domain policy based security wrapper, DKIM remains an unsecured protocol and currently it is just wasted processing bandwidth with a huge cost in implementation and management, or just plain old getting it right, and even then, most people in our market don't understand what utility it offers them. At present, they believe the new badge will help them look better, but there is no real evidence that it does anything for them. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DKIM Signatures now being applied to IETF Email
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of t.petch Sent: Saturday, July 30, 2011 3:26 AM To: Barry Leiba Cc: ietf Subject: Re: DKIM Signatures now being applied to IETF Email Sadly, I do not see it being used in the mailing lists where an organisation is sending me directly data I would like to be able to rely on - which I think fits the applicability well - and instead, I see it being used on a mailing list such as those in the IETF where I believe that the costs outweigh the benefits - and I have no choice about that:-(. There has been some post-DKIM talk recently about the idea of transient trust, wherein (to use this example) ietf.org would verify the signature on an arriving list submission, attach an RFC5451 header field that indicates the results of that verification, then send the message out to the list with that added field and a new ietf.org signature that covered it. Then, if you decide to believe ietf.org's claims about the original signature, you know more than you would otherwise. This hasn't been widely deployed yet, but some big email providers are currently playing with the idea. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 28/Jul/11 18:34, t.petch wrote: The minor point is that e-mails have just got yet bigger. They are now 100-150% bigger than when first I started following the IETF According to Nielsen's Law, network connection speeds double every 21 months. DKIM is apparently using a quite reasonable fraction of that. But more importantly we have abolished the end-to-end principle. If I am going to benefit from improved security on e-mail, I want to from the originator to me, not some half-way house giving a spurious impression of accuracy. Most users don't want perfect accuracy into the mail system. Not only because of the burden of maintaining keys, but also for concerns about freedom of speech, right to anonymity, possibility to play jokes, and the like. MSA endorsement allows all that, and still delivers some responsibility by leveraging the trust between authors and their mailbox providers. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 7/28/2011 12:34 PM, t.petch wrote: But more importantly we have abolished the end-to-end principle. If I am going to benefit from improved security on e-mail, I want to from the originator to me, not some half-way house giving a spurious impression of accuracy. The end-to-end principle is often cited as an argument for any mechanism that is not the end-nodes. I'm waiting for the day it is applied to a demand that every user's computer, tablet and smartphone be directly connected to every other one, so that we no longer suffer IP relaying by routers, since their presence violates the end-to-end principle. With respect to DKIM, the problem with your concern is that you appear to misunderstand the function DKIM is performing. Since that's well-documented, I suggest you review how it works and what it means. In case that's too much effort, I suggest you take a look at: The Truth About DKIM http://bbiw.net/presentations/DKIM%20Truth.pdf specifically slide 4. The left hand side includes a short list of common mis-assumptions about DKIM's meaning, along with the one correct one. See whether you know which is the right one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On Jul 29, 2011, at 6:18 AM, Dave CROCKER wrote: On 7/28/2011 12:34 PM, t.petch wrote: But more importantly we have abolished the end-to-end principle. If I am going to benefit from improved security on e-mail, I want to from the originator to me, not some half-way house giving a spurious impression of accuracy. The end-to-end principle is often cited as an argument for any mechanism that is not the end-nodes. I'm waiting for the day it is applied to a demand that every user's computer, tablet and smartphone be directly connected to every other one, so that we no longer suffer IP relaying by routers, since their presence violates the end-to-end principle. With respect to DKIM, the problem with your concern is that you appear to misunderstand the function DKIM is performing. Since that's well-documented, I suggest you review how it works and what it means. In case that's too much effort, I suggest you take a look at: The Truth About DKIM http://bbiw.net/presentations/DKIM%20Truth.pdf specifically slide 4. The left hand side includes a short list of common mis-assumptions about DKIM's meaning, along with the one correct one. See whether you know which is the right one. DKIM is not my favorite protocol. But it's not like there haven't been several efforts to define e2e authentication for email, including PEM, S/MIME, PGPMIME, and several others whose acronyms I'm too lazy to look up at the moment. Implementations of email clients that support e2e authentication are not hard to find, and some people do use them. But they've never been widely used. I don't blame the DKIM proponents for wanting to try a different deployment model, for a different use case. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
oh boy... On 7/29/2011 6:36 AM, Keith Moore wrote: The Truth About DKIM http://bbiw.net/presentations/DKIM%20Truth.pdf specifically slide 4. The left hand side includes a short list of common mis-assumptions about DKIM's meaning, along with the one correct one. See whether you know which is the right one. DKIM is not my favorite protocol. But it's not like there haven't been several efforts to define e2e authentication for email, including PEM, S/MIME, PGPMIME, and several others whose acronyms I'm too lazy to look up at Since DKIM's semantic is fundamentally different from PEM, S/MIME and OpenPGP, I don't know why you cited them. For the typically uses of 'authentication' with respect to email, DKIM does not do authentication. Please re-read the preceding sentence 10 times. I really do suggest folks who have comments about DKIM first put some effort understanding what it does and does not do. We've made it easy. There are multiple documents discussion what it is and how to use it. I don't blame the DKIM proponents for wanting to try a different deployment model, for a different use case. DKIM is a different semantic, not just a different implementation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Original Message - From: Dave CROCKER d...@dcrocker.net To: ietf@ietf.org Sent: Friday, July 29, 2011 12:18 PM On 7/28/2011 12:34 PM, t.petch wrote: But more importantly we have abolished the end-to-end principle. If I am going to benefit from improved security on e-mail, I want to from the originator to me, not some half-way house giving a spurious impression of accuracy. The end-to-end principle is often cited as an argument for any mechanism that is not the end-nodes. I'm waiting for the day it is applied to a demand that every user's computer, tablet and smartphone be directly connected to every other one, so that we no longer suffer IP relaying by routers, since their presence violates the end-to-end principle. With respect to DKIM, the problem with your concern is that you appear to misunderstand the function DKIM is performing. Since that's well-documented, I suggest you review how it works and what it means. In case that's too much effort, I suggest you take a look at: The Truth About DKIM http://bbiw.net/presentations/DKIM%20Truth.pdf specifically slide 4. The left hand side includes a short list of common mis-assumptions about DKIM's meaning, along with the one correct one. See whether you know which is the right one. Yes, I know enough about DKIM to identify the right one. I think that it is an error for the IETF to add DKIM signatures. They do indeed tell me which intermediary has sent me the mail, but does nothing for the 'spam' that the intermediary accepted in the first place (albeit there being little of that on the IETF managed lists). And has already been pointed out, the mailing list damages any DKIM signature that is already there. I find it interesting that John Levine lists 'DKIM doesn't work with mailing lists' as one of this three myths. I think that that depends on the interpretation of the word 'work'. I would say that DKIM in this context, of a mailing list, gives a spurious impression of increased security that we would be better off without. It functions, but does not work, in that it tells me nothing about the true origin of the communication. Tom Petch d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DKIM Signatures now being applied to IETF Email
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of t.petch Sent: Friday, July 29, 2011 5:22 AM To: dcroc...@bbiw.net; ietf Subject: Re: DKIM Signatures now being applied to IETF Email It functions, but does not work, in that it tells me nothing about the true origin of the communication. ...but that's not what it's supposed to tell you. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
I think that it is an error for the IETF to add DKIM signatures. They do indeed tell me which intermediary has sent me the mail, but does nothing for the 'spam' that the intermediary accepted in the first place (albeit there being little of that on the IETF managed lists). ... It functions, but does not work, in that it tells me nothing about the true origin of the communication. What it does is allow you to assure yourself that the message was, indeed, from an IETF mailing list (well, from an IETF email server), and that it wasn't that someone tried to spoof that. That, in turn, allows you to confidently increase your trust that the message is not spam in proportion to your confidence in the IETF's spam-filtering capabilities. Some of us, at least, find that useful. Some of us might even completely white-list IETF-signed messages. You can make your own choice on that. Barry, DKIM WG chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 7/29/2011 11:02 AM, Barry Leiba wrote: What it does is allow you to assure yourself that the message was, indeed, from an IETF mailing list (well, from an IETF email server), and that it wasn't that someone tried to spoof that. That, in turn, allows you to confidently increase your trust that the message is not spam in proportion to your confidence in the IETF's spam-filtering capabilities. Some of us, at least, find that useful. Some of us might even completely white-list IETF-signed messages. You can make your own choice on that. An intermediary that signs messages and has a reputation for carrying spam in its stream will have an appropriate reputation. One that signs messages and has a clean message stream will also have an appropriate reputation. The differences between the two will produce very different disposition at the delivery site. All of which is cleaner and safer than is possible today, except with constrained uses of previous-hop IP(v4) addresses. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
t.petch wrote: It functions, but does not work, in that it tells me nothing about the true origin of the communication. Yes and No and that the main problem with DKIM, which I see is the lack of 3rd party signal controls or put another way - anyone, middle ware and especially list servers can blindly DKIM resign mail without restrictions. That lack of control has cause originating authoring domains, copyright holders of mail, all benefits of supporting DKIM. The current approach is that original domains no longer have any rights whatsoever to declare they are the only signers allowed to sign mail and any deviation from that expectation should be indication of protocol failure - Reject it! Unfortunately, in order to allow a list server or any 3rd party middleware to exist with DKIM (re)signing features, it needs to ignore any original DKIM domain signing practice or expectations. No domain that wishes exclusive signing operations should be sending their signed mail to a public service forum. We know this, but we don't have the controls to disallow faults or bad guys attempting to create a facsimile of your domain signed mail in public areas or directly to others. Finally, as DKIM was revamped from secured Author-Domain signing protocol to a anyone can signed 3rd party Trust vendor protocol, the problem we face is we don't have consistency with 3rd party trust tables. For DKIM to work, every validators needs a copy of the same trust tables. DKIM is a protocol that requires Batteries in order to work and everyone must use the same batteries. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Original Message - From: Sean Turner turn...@ieca.com To: ietf@ietf.org Sent: Wednesday, July 27, 2011 2:09 PM On 7/25/11 2:01 PM, Dave CROCKER wrote: On 7/25/2011 1:17 PM, Glen wrote: I am very pleased to report that the IETF is now applying DKIM signatures to all outgoing list email from mailman. I'll be presumptuous and speak on behalf of the DKIM operations community, rather than just myself: Cool! Thanks. +1 to that! -100 The minor point is that e-mails have just got yet bigger. They are now 100-150% bigger than when first I started following the IETF and it is not that people have more to say, but that the junk at the front has expanded out of all recognition. This costs, transmission time, processing storage etc. The transmission time is significant (I imagine) because of POP3 which seems to take 2n+ messages, n round trips, before starting to download anything out of n e-mails. But more importantly we have abolished the end-to-end principle. If I am going to benefit from improved security on e-mail, I want to from the originator to me, not some half-way house giving a spurious impression of accuracy. Tom Petch Personally, I like it when we eat our own dog food ;) spt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
But more importantly we have abolished the end-to-end principle. If I am going to benefit from improved security on e-mail, I want to from the originator to me, not some half-way house giving a spurious impression of accuracy. I can't help but be baffled at the lack of a PGP or S/MIME signature on your message. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On Mon, Jul 25, 2011 at 10:17:48AM -0700, Glen g...@amsl.com wrote a message of 23 lines which said: I am very pleased to report that the IETF is now applying DKIM signatures to all outgoing list email from mailman. What about a RFC 5617 published signing practice? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 26/Jul/11 06:19, Hector Santos wrote: But the original destroyed signature from the author is not stripped. Nor verified, apparently. Authentication-Results: dkim.winserver.com; dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; adsp=fail policy=all author.d=isdg.net asl.d=ietf.org (unauthorized signer); dkim=fail (DKIM_SIGNATURE_BAD) header.d=isdg.net header.s=tms1 header.i=isdg.net; adsp=pass policy=all author.d=isdg.net signer.d=isdg.net (originating signer); My verifier is somewhat more concise than yours. For your message it just reports Authentication-Results: wmail.tana.it; spf=pass smtp.mailfrom=ietf.org; dkim=pass header.i=@ietf.org; dkim-adsp=fail header.from=hsan...@isdg.net It would be nice for the list server to remove original signatures the list will destroy in its resigning process. That implies checking which signatures actually got destroyed. Was the author signature destroyed, on this message? Possibly not, as on my previous message I got Authentication-Results: wmail.tana.it; spf=pass smtp.mailfrom=ietf.org; dkim=pass header.i=@tana.it (The IETF's signature would probably have passed too, but since the author signature was good, this concise verifier didn't bother to report on any other one --a little bit too much concise, perhaps.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 7/25/11 2:01 PM, Dave CROCKER wrote: On 7/25/2011 1:17 PM, Glen wrote: I am very pleased to report that the IETF is now applying DKIM signatures to all outgoing list email from mailman. I'll be presumptuous and speak on behalf of the DKIM operations community, rather than just myself: Cool! Thanks. +1 to that! Personally, I like it when we eat our own dog food ;) spt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
I am very pleased to report that the IETF is now applying DKIM signatures to all outgoing list email from mailman. What about a RFC 5617 published signing practice? That RFC is only useful for a narrow range of heavily phished domains like Paypal's. Fabulous though the IETF is, it's not one of them. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 7/27/2011 4:46 AM, Stephane Bortzmeyer wrote: I am very pleased to report that the IETF is now applying DKIM signatures to all outgoing list email from mailman. What about a RFC 5617 published signing practice? ADSP only works when the domain in the From: field is the same as the signer's domain name. It really is tailored to use by highly phished sites acting as fully-integrated bulk senders. It cannot work with more diverse environments. The IETF email environment qualifies as extremely diverse. Our mailing list operation breaks ADSP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 7/25/2011 1:17 PM, Glen wrote: I am very pleased to report that the IETF is now applying DKIM signatures to all outgoing list email from mailman. I'll be presumptuous and speak on behalf of the DKIM operations community, rather than just myself: Cool! Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Cool beans. Message as verified here. The good thing is that it finally resolved the corruption of distributed original signed mail on the ietf list server with its extra line at the top! Glen wrote: All - I am very pleased to report that the IETF is now applying DKIM signatures to all outgoing list email from mailman. Many thanks to Murray Kucherawy, lead author of OpenDKIM, for doing the work to set up OpenDKIM on the IETF servers and getting it to work. He made the process painless, and we express our thanks to him for his service to the IETF. As always, any questions or issues, please feel free to contact me, or submit to ietf-action. Thank you, Glen Glen Barney IT Director AMS (IETF Secretariat) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
But the original destroyed signature from the author is not stripped. Authentication-Results: dkim.winserver.com; dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; adsp=fail policy=all author.d=isdg.net asl.d=ietf.org (unauthorized signer); dkim=fail (DKIM_SIGNATURE_BAD) header.d=isdg.net header.s=tms1 header.i=isdg.net; adsp=pass policy=all author.d=isdg.net signer.d=isdg.net (originating signer); It would be nice for the list server to remove original signatures the list will destroy in its resigning process. That may be an OpenDKIM option. What I need to do now also is authorized IETF.ORG as a valid 3rd party signer for the ISDG.NET domain. This is done by adding ADSP/ATPS record using this wizard: http://www.winserver.com/public/wcadsp/wcadsp.wct Hector Santos wrote: Cool beans. Message as verified here. The good thing is that it finally resolved the corruption of distributed original signed mail on the ietf list server with its extra line at the top! Glen wrote: All - I am very pleased to report that the IETF is now applying DKIM signatures to all outgoing list email from mailman. Many thanks to Murray Kucherawy, lead author of OpenDKIM, for doing the work to set up OpenDKIM on the IETF servers and getting it to work. He made the process painless, and we express our thanks to him for his service to the IETF. As always, any questions or issues, please feel free to contact me, or submit to ietf-action. Thank you, Glen Glen Barney IT Director AMS (IETF Secretariat) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
